stekern has quit [Remote host closed the connection]
kuldeep has joined #m-labs
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined #m-labs
_whitelogger has joined #m-labs
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined #m-labs
<cr1901_modern>
sb0: That comment you linked- I don't understand how you get "c is stuck at 0" w/ blocking assignments. Is this from testing on a simulator (which I haven't yet. Will prob do that next)?
<cr1901_modern>
I would expect that always block to be evaluated in order
kuldeep has quit [Ping timeout: 240 seconds]
<sb0>
cr1901_modern: the assignments to 0 at the beginning cause the if conditions to be always false
<cr1901_modern>
Oh, right I can't read
<cr1901_modern>
Then I wonder why presentations go on about "use blocking for always @(*)"
rohitksingh_work has joined #m-labs
<cr1901_modern>
sb0: Is that an example of a so-called "combinatorial loop" that you linked me to?
<cr1901_modern>
I recall that the Verilog spec says "If a variable used on both the RHS and LHS of expressions in a block changes value, reevaluate the entire block with the new variable value".
<sb0>
cr1901_modern: he probably didn't think of this detail. VHDL is better designed there, with the variables instead of this blocking/nonblocking nonsense
kuldeep has joined #m-labs
<cr1901_modern>
I don't know VHDL, so I can't comment. I agree that block/nonblocking bites though and doesn't seem to really help Migen
<cr1901_modern>
from what I can tell, blocking is useful for modeling delays, which is something (thank goodness :P?) Migen opts not to model
<cr1901_modern>
sb0: Btw, `ifdef SYNTHESIS is part of the synthesized Verilog spec now. I can't check Altera, but at least Vivado and yosys support it (and Diamond will as well b/c it uses Synposys like Vivado does).
<cr1901_modern>
Any compiler that targets something that Migen reasonably supports prob supports it. And it'll make yosys stop bitching :).
kuldeep has quit [Ping timeout: 252 seconds]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 246 seconds]
kuldeep has joined #m-labs
rohitksingh_wor1 has quit [Quit: Leaving.]
rohitksingh_work has joined #m-labs
tinyfpga has joined #m-labs
<cr1901_modern>
sb0: I think this might be a case of Mandela effect for me, but... was the default value for asic_syntax _ever_ True?
<sb0>
no
<cr1901_modern>
sb0: Huh, well... I know the default Migen output gets "most of the way there" for generating ASIC-friendly verilog code. >>
<cr1901_modern>
Perhaps instead of getting rid of asic_syntax, it's just used to disable initial values loaded from the bitstream?
<cr1901_modern>
s/it's just used/we keep it around/
<cr1901_modern>
In any case, I think I understand PR #127 now and your comment. It's unfortunate, but looks like users who want to simulate a Migen design using a Verilog sim will have to eat the performance penalty of >>
<cr1901_modern>
comb always blocks being repeatedly evaluated
<sb0>
simulators should be able to optimize that
<cr1901_modern>
Also, tonight I learned "reg a = 1'b0;" is _not_ semantically equivalent to "reg a; initial a = 1'b0;": https://stackoverflow.com/a/38446236
<cr1901_modern>
Based on this answer, I would think "reg a = 1'b0;" is the desirable behavior (at least for simulation). I'm surprised (symbi)yosys chokes on it
kuldeep has quit [Ping timeout: 272 seconds]
kuldeep has joined #m-labs
<attie>
Who actually managed to type this sentence with a straight face: "In most design flows HDL code is not only processed by the synthesis tool but also by one or more simulators and sometimes even a formal verification tool. It is key for this verification process that all these tools use the same interpretation for the HDL code."