[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)
> > * Signal(1, reset=0), both width 1 and reset=0 are the defaults and may
> >   be removed
> I'd like reset=0 to be left as it makes it explicit that the reset value
> actually matters whereas most other signals the reset value doesn't really
> matter.
> so Signal(reset=0)

 ok - yes, the usual convention there is to add a comment, so that people
 are not caught out by surprise at the explicit mention of something that's
 known to be a default value.

 which is ok with me, if you feel it helps readability, to do that.

 however... this masks something that's really important: if the reset value
 doesn't matter, it's *really important* to put "reset_less=True" to not only
 make that absolutely clear, but to *STOP* nmigen from generating unnecessary
 gates that the optimiser will in *no way* be able to spot.

 which is why i mentioned in an earlier comment that reset_less=True should,
 really, be the preferred... what's the word... "pattern" / "distinguisher".


 in addition, one thing that i've found you really *really* have to watch
 out for: if the width is not equal to 1, sometimes setting an integer
 constant is NOT ACCURATE.

 it results in assignment of the WRONG NUMBER OF BITs.  i have seen only
 the LSB(s) get set due to incorrect (implicit) width detection that goes
 wrong.

 you can see evidence of having to work around this bug in the FPU exponent
 handling, where i have to create Const() objects of specific lengths
 to match what the exponent's bitwidth is *SUPPOSED* to be.

 basically what i am saying is: be careful here! :)

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