I don't have the bandwidth right now to minimize an example, so I'm reporting this for future me:
In the context of fusesoc, I have a target which generates an iverilog testbench. vlog_tb_utils requires a timescale to be defined for the timeout functionality to work.
The testbench depends on the vlog_tb_utils core as well asmy fork of the verilog-axis core. I also brought the source up to date with upstream.
I understand not hardcoding a timescale into this core, relying on, say, fusesoc's iverilogtimescale option to prepend a source file with your desired timescale. Unfortunately, every source in Verilog AXIs nowadays uses the resetall directive.
Depending on the source file order that fusesoc decides, this means that vlog_tb_utilsand any source file from any core in the list after verilog-axis core will lose the injected timescale information, leading to warnings from iverilog at best, and my simulations just plain never timing out (without extra code/me redefining the timescale directive locally).
Is there a way to influence core order? If this is too invasive, is it possible to add, say, a define that indicates I'm running the verilog-axis core under fusesoc to remove the resetalls? I am definitely open to options here.
I don't have the bandwidth right now to minimize an example, so I'm reporting this for future me:
In the context of
fusesoc, I have a target which generates aniverilogtestbench.vlog_tb_utilsrequires atimescaleto be defined for the timeout functionality to work.The testbench depends on the
vlog_tb_utilscore as well as my fork of theverilog-axiscore. I also brought the source up to date with upstream.I understand not hardcoding a
timescaleinto this core, relying on, say,fusesoc'siverilogtimescaleoption to prepend a source file with your desired timescale. Unfortunately, every source in Verilog AXIs nowadays uses theresetalldirective.Depending on the source file order that
fusesocdecides, this means thatvlog_tb_utilsand any source file from any core in the list afterverilog-axiscore will lose the injectedtimescaleinformation, leading to warnings fromiverilogat best, and my simulations just plain never timing out (without extra code/me redefining thetimescaledirective locally).Is there a way to influence core order? If this is too invasive, is it possible to add, say, a define that indicates I'm running the
verilog-axiscore underfusesocto remove theresetalls? I am definitely open to options here.