<sb0>
GTGREFCLK is supposed to be fed by internal logic...
<cr1901_modern>
Is SynthesisDirective being removed completely from migen?
<sb0>
cr1901_modern, yes that sounds desirable, why?
<cr1901_modern>
sb0: Oh, I think it's a good thing too. Will stop yosys from bitching.
<cr1901_modern>
Just I thought the synthesis directives were the only way to prevent a simulation/synthesis mismatch and that's why they're kept
<sb0>
I'm not talking about translate_on/off
<sb0>
those stay
<cr1901_modern>
Oh, then I have no opinion on whether they're kept or not :P. I don't use them. I imagine most things we care about can be reimplemented using attributes anyway.
<cr1901_modern>
That reminds me, I still have to talk to clifford about that simulation/synthesis mismatch. He might know an alternate solution, but idk
<sb0>
an alternate solution is to run the migen simulator to determine the initial values of all comb regs and then use the "reg XXX = VVV" syntax
<sb0>
but it's a bit heavy handed
<cr1901_modern>
"reg XXX = VVV" <-- this is ASIC friendly? And if so, how does it differ from initial?
<sb0>
you could use initial as well+
<sb0>
but it's longer
<sb0>
none are asic friendly
<sb0>
though for comb regs it doesn't matter
<sb0>
and this is simply for fixing the simulation here anyway
<whitequark>
why can't you initialize with `initial` ?
<cr1901_modern>
How would an ASIC know on power on what values it should take (without extra logic)?
<cr1901_modern>
At least that's how I understand it
<whitequark>
an ASIC always needs an explicit reset
<cr1901_modern>
I guess synthesis doesn't specify this, but I've always thought as initial as "values that are just assumed to exist at the beginning of time", whereas the "always @ reset initial begin" provides the actual reset logic
<cr1901_modern>
So initial reg XXX = VVV; is FPGA bitstream friendly, but not-much else
<sb0>
so to clarify things
<sb0>
if you do this:
<sb0>
reg foo;
<sb0>
always @(*) foo <= 0;
<sb0>
the value of foo is undefined in simulation and 0 in synthesis (both FPGA and ASIC)
<sb0>
this is the problem, and its variants, that the synthesis comments in migen are fixing
<sb0>
so I'm not going to remove those comments just because yosys complains, fixing the simulation issue is far more valuable
<cr1901_modern>
That's fine. I was just wondering
<cr1901_modern>
I'm surprised always @(*) foo <= 0; works at all, tbh. You didn't provide any signals for which foo should change
<cr1901_modern>
(Which I suppose is why it's undefined in simulation)
<cr1901_modern>
But synthesis "does the right thing", whatever that is
<sb0>
make it "foo <= 0 & bar" if you wish, same problem
<sb0>
either way I don't want to bother with verilog event idiosyncrasies when writing combinatorial logic, which is why i use migen
<cr1901_modern>
I understand that. I'm simply asking "why it works"
<cr1901_modern>
Is the idea that "always @(*) foo <= 0;" during SYNTHESIS, will generate logic that will immediately set the register to 0, and always 0, regardless of the undefined power-on value?
<whitequark>
synthesis doesn't have x
<whitequark>
x is like undefined behavior: unless you are specifically hunting for it with e.g. ubsan (the equivalent of which is iverilog), it will result in "something happening"
<whitequark>
actually I'm wondering if doing what migen currently does is technically illegal
<cr1901_modern>
whitequark: I meant literal power-on, before voltages have stabilized.
<whitequark>
it's unlikely to ever be miscompiled regardless...
<whitequark>
cr1901_modern: once you upload a bitstream the states are defined...
<cr1901_modern>
foo is going to be some memory cell that holds state in an ASIC, and some block RAM location in an FPGA. What does "always @(*) foo <= 0;" do in the context of both? B/c it's not a legal simulation statement AFAICT
<cr1901_modern>
I guess I shouldn't worry about it
<cr1901_modern>
whitequark: actually I'm wondering if doing what migen currently does is technically illegal <-- willing to elaborate?
<whitequark>
well, if you have an x in simulation anywhere then the synthesizer is not obliged to guarantee any sort of sensible behavior at all
<cr1901_modern>
whitequark: I don't think I've ever seen Migen output "x". Can you coerce it to output "x"?
<cr1901_modern>
"regardless of the undefined power-on value?" <-- this was sloppy terminology by me. I was not referring to Verilog UB here.
sandeepkr has quit [Ping timeout: 260 seconds]
fengling has joined #m-labs
<cr1901_modern>
sb0: Do comb regs actually hold state? Comb reg is just "reg used in an always block without posedge", correct?
<GitHub126>
[migen] sbourdeauducq pushed 2 new commits to master: https://git.io/vXLUV
<cr1901_modern>
"Initially, Verilog used the keyword reg to declare variables representing sequential hardware registers. " Idk how accurate it is, but...
<GitHub90>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vXLU6
<GitHub90>
migen/master 160cf5f Sebastien Bourdeauducq: build: remove sim (needs refactoring as per my email from Nov 12 2015)
<sb0>
who cares. hdls are full of garbage.
<cr1901_modern>
Well maybe it wasn't at one point ;)
<cr1901_modern>
Last q for now: For comb regs, the idea is that an initial value is "the value the register takes when no other conditions are satisfied", correct?
<sb0>
try writing a FSM without comb regs and talk to me again
<cr1901_modern>
conditions == "anything in the corresponding sensitivity list for that comb register that MAY update the value"
<cr1901_modern>
And no, I'm not going to take you up on that offer
<sb0>
and no, HDLs were even worse before
<cr1901_modern>
"try writing a FSM without comb regs and talk to me again" <-- the fact that Migen automates this is one of the biggest time/hassle-savers
<cr1901_modern>
Writing a FSM in Verilog is just a royal pain if you do it the "right" way.
<sb0>
and about holding state: comb regs, in simulation, hold state between runs of their always blocks (ie changes of the inputs)
<sb0>
but this distinction is just pedantry and a waste of time
<sb0>
you can also model latches and other asynchronous components by tweaking sensitivity lists and testing certain conditions. but this is useless in practice.
<sb0>
synthesis of asynchronous logic doesn't really work
<sb0>
sigh, vivado completely removed support for "// synthesis attribute" it seems
<sb0>
what the hell? the vivado garbage is complaining about a hold violation between rsys_clk and rio_clk, and there's a false path constraint between the two
<sb0>
oh, the vivado garbage simply ignored all my false path constraints because it didn't find the signals for some reason.
<sb0>
rjo, why does XilinxVivadoToolchain.add_false_path_constraint take migen signals, get their net names and passes them to vivado's get_clocks, which doesn't operate on nets?
<sb0>
this make add_false_path_constraint work only when the clock has been created by chance with the same name as the net, e.g. when you have passed it to add_period_constraint() before
<sb0>
this is wrong
<GitHub0>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vXLWf
<GitHub0>
migen/master 002850b Sebastien Bourdeauducq: vivado: use get_nets for add_false_path_constraint
<cr1901_modern>
sb0: Is misoc_extra_software_packages linked into the bios in MiSoC? I can't find any indication that it is.
<cr1901_modern>
(Assuming the extra packages are enabled)
<sb0>
CRITICAL WARNING: [Constraints 18-611] set_false_path: list of objects specified for option 'from' contains '1' objects of types '(net)' other than the types '(port,pin,cell,clock)' supported by the constraint. These objects will not be used for this constraint.
<sb0>
fuck you xilinx
<sb0>
fucking garbage
* cr1901_modern
withdraws his question for now. Will ask later
<sb0>
UCF sucked enough already and yes, they made it worse