Weird ClockCycles behaviour / Verilator issues with Edge
See original GitHub issueHey everyone,
I’m having an unexpected behaviour during execution of a test using ClockCycles to do the reset in my dut. My design+tb has two clocks, one that’s faster than the other and I always use the slowest one to hold the reset of both segments of the design for 2 cc. Although I use the correct signal to wait for the slowest clock, it seems that the simulation is using always the same clock (in this case noc_clk) as reference to wait inside the ClockCycles. Please check the snippet below:
Based on the option used in the regression, I invert the clocks that I’m using in the dut. https://github.com/aignacio/ravenoc/blob/master/tb/common_noc/testbench.py#L123-L130
async def setup_clks(self, clk_mode="NoC_slwT_AXI"):
self.log.info(f"[Setup] Configuring the clocks: {clk_mode}")
if clk_mode == "NoC_slwT_AXI":
cocotb.fork(Clock(self.dut.clk_noc, *noc_const.CLK_100MHz).start())
cocotb.fork(Clock(self.dut.clk_axi, *noc_const.CLK_200MHz).start())
else:
cocotb.fork(Clock(self.dut.clk_axi, *noc_const.CLK_100MHz).start())
cocotb.fork(Clock(self.dut.clk_noc, *noc_const.CLK_200MHz).start())
…and the reset method does the same, checking what’s the slowest one to hold for 2cc https://github.com/aignacio/ravenoc/blob/465a5eb2bf0c242c0af5f9f4c1e3169324d89f51/tb/common_noc/testbench.py#L139-L149
async def arst(self, clk_mode="NoC_slwT_AXI"):
self.log.info("[Setup] Reset DUT")
self.dut.arst_axi.setimmediatevalue(0)
self.dut.arst_noc.setimmediatevalue(0)
self.dut.axi_sel.setimmediatevalue(0)
self.dut.arst_axi <= 1
self.dut.arst_noc <= 1
if clk_mode == "NoC_slwT_AXI":
await ClockCycles(self.dut.clk_noc, noc_const.RST_CYCLES)
else:
await ClockCycles(self.dut.clk_axi, noc_const.RST_CYCLES)
here’s what I got when I run the regression In this image it’s pretty clear it’s always using clk_noc as reference on the trigger. (ClockCycles(self.dut.clk_noc, noc_const.RST_CYCLES))
From my understanding the simulation should always take the same amount of time for the reset in both cases, right?
Cocotb - v1.5 Verilator - 4.106
Issue Analytics
- State:
- Created 3 years ago
- Comments:14 (6 by maintainers)
Top GitHub Comments
For now, only 4.106 “works”. There are a couple bugs in Verilator that need to be fixed.
If the value is 0, and the if statement is followed, and the waiting for edge occurs, what’s the problem? Are you saying that
Edge
is returning immediately?yeap, timeouts are not expected…np @ktbarrett, for the moment I’m going to proceed with this workaround, anyway tks a lot for the support! Just before closing the issue, from your understanding arrays on top are still not supported on the latest Verilator? I’m asking cause I needed to encapsulate my dut in a muxed wrapper to talk with different axi channels i/fs