[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #92 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #91)

> > basically there's some definite corruption going on from BLIF to VST.
> 
> Yes and no (Normand response).
> 
> I've found similar problem in sm0, and that is what was causing the lvx
> problem. An output was connected to "one" which is vdd and the
> intermediate cell "one" was not inserted (you cannot directly connect
> vdd to logical signal). I'm about to correct that.
> 
> The problem you found is different. It is is the "one internal signal
> for two external connectors". In the blif file, the lines:
> 
> .names mask[1] mask[0]
> 1 1
> 
> means that mask[0] is an alias of mask[1] (it copies it's truth table).
> So Coriolis *merge* the two signals, leaving only mask[0], hence the
> "hole" in the vector as mask[1] is destroyed.

and on the current version i am looking at, at the moment:

.model sm2
.inputs gates
.outputs mask[0] mask[1] mask[2]
.names $false
.names $true
1
.names $undef
.subckt inv_x1 i=gates nq=mask[2]
.names mask[2] bit0
1 1
.names mask[2] bits
1 1
.names $true mask[0]
1 1
.names $true mask[1]
1 1
.end

and this results in this:

  subckt_54_sm1 : sm1
  port map ( gates => pmask(2 downto 1)
           , mask  => sm1_mask(2)
           , vdd   => sm1_mask(1)
           , vss   => vss
           );

so there are quite a lot of those overwrites

> Would it be possible for this to not happen in the nMigen description?

it's waaay beyond what nmigen is doing: it's what yosys is doing with the ilang
file.  i did "read_blif part_sig_add.blif" then "show" and also "write_ilang
part_sig_add2.il" and it's radically different.

basically, the output from yosys is so "optimised" (so much removed and
topologically changed) that even attempting to "stop" nmigen from doing
this, i am overwhelmed even just considering the task.

honestly i suspect that trying the route of modifying nmigen, there would
be so many holes that it would be virtually impossible to cover all of them.


> One dirty fix to keep the interface untouched would be for Coriolis
> to insert a buffer between those two signals, so the become identical
> but different net (and with some delay addes).

if that gets us something "working" so that later it can be fixed /
optimised, *great*.

even if that doesn't happen, honestly i do not feel it is critical
(not unless it increases the overall chip size by more than... 60%
to put a finger-in-air number).

-- 
You are receiving this mail because:
You are on the CC list for the bug.