A little bit of context: Should a (System)Verilog code generator (I don't want to name the specific one in question) generate code like the example above when generating synthesizable HDL code?
Show this thread
Xilinx Vivado seems to think that this is synthesizable since Vivado 2017.3. Opinions anyone? (SV code, TCL, and Vivado logs at http://svn.clifford.at/handicraft/2018/vivadohier ….)pic.twitter.com/MgpgP76B7g
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
regardless of whether that's actually valid Verilog, isn't it convenient? Migen allows it and I love it.
-
I don't think I'd consider that style good practice but it's handy for debugging and prototyping hacks
- Show replies
New conversation -
-
-
Yeah im OK with this too. If the hierarchy gets flattened in synthesis for performance it's just the same. I do agree with concensus, it's a little lazy.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Usually, it was legal in behavioral but not for synthesizable. (Cross module hierarchy references). Clearly, not portable code
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Is that even part of the synthesizable subset of SV? If not, then Vivado should not allow it. Otherwise, I'd say, like others have, that it's handy but definitely very bad coding practice except for cases such as fault injection or debugging.
-
There is no "synthesizable subset" for SystemVerilog. There was a standard (IEEE 1364.1) that defined the synthesizable subset of Verilog (IEEE 1364). But no such standard exists for SystemVerilog (IEEE 1800). So nobody knows what is to be expected to work in SV synthesis..
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.