[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 #40 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #23)
> (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".
I didn't use reset_less=True because that way we can prevent "optimizations"
that depend on the values being X and going to town removing critical logic. If
nmigen can somehow guarantee that those undesired optimizations aren't
occurring, then I agree that reset_less=True should be the default.
> 
> 
>  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.
that's an nmigen bug then. If you find any particular cases, report them to the
nmigen project.

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