Notice on Vivado simulation

[dzx-dzx]

SpinalHDL can neither add macro definition to Verilog source nor add flags when invoking Xsim.

[dzx-dzx]

When simulating with iverilog, dumpWave enables waveform output. But the very same function will cause Vivado to fail:

Exception in thread "main" java.lang.Exception: basic_string::_M_construct null not valid

[dzx-dzx]

Errr...The auto-generated project cannot be simluted or synthesized in Vivado IDE. One workaround is to update the IP.

[dzx-dzx]

DO NOT forget to add the macro SIM_SPEED_UP! It's not fun waiting hours after hours as the rx data waveform was in the state of stasis...

[dzx-dzx]

Errr...The auto-generated project cannot be simluted or synthesized in Vivado IDE. One workaround is to update the IP.

Can we update it prior to the simulation? At least files extracted from./TopLevel_xsim.srcs/sources_1/ip doesn't work.

[dzx-dzx]

clk in udp_40G_TOP should be redundant, but without it there would be an error message saying key not found.

[dzx-dzx]

When simulating with iverilog, dumpWave enables waveform output. But the very same function will cause Vivado to fail:

Exception in thread "main" java.lang.Exception: basic_string::_M_construct null not valid

Trying to replace loop driven clock logic by reconfiguring SpinalConfig's defaultFrequency and adding

ClockDomain(dut.io.gt_ref_clk_p_40MAC_0).forkStimulus(19200000) 
      // 156.25 MHz on base frequency 3e3 GHz
      ClockDomain(dut.io.sys_clk_p).forkStimulus(1000000) 
      // 600 MHz

Results in the very same error message... What a surprise, verilator can accept that.

[dzx-dzx]

The frequency configuration for gt_ref_clk and sys_clk borrowed from the original Verilog testbench(rewritten as:

fork {
        while (true) {
          dut.clockDomain.waitRisingEdge(48)
          dut.io.gt_ref_clk_p_40MAC_0 #= !dut.io.gt_ref_clk_p_40MAC_0.toBoolean
        }
      }
      fork {
        while (true) {
          dut.clockDomain.waitRisingEdge(25)
          dut.io.sys_clk_p #= !dut.io.sys_clk_p.toBoolean
        }
      }

) will render the module inoperative. No signs of data exchange on any port.(Always assert f)

[dzx-dzx]

Can't see signals from submodules in wdb, like EthernetTx.

[dzx-dzx]

The simulation takes forever...no less that half an hour, it must.

[dzx-dzx]

for (_ <- 0 until 1000000) {
    dut.packetClockDomain.waitRisingEdge()
    ...
}

One would expect the code after the waitRisingEdge to be executed right after the rising edge? No, it also waits for clk's edges. The signals don't align. There might be something to do with its non-integer frequency.

• ClockingArea in sim and in TopLevel doesn't help.
• Take control of pkt_clk and ethernet module doesn't work. (gt_txp_out_40MAC almost always asserts x)
• Combining ClockingArea and RegNext cause the same as the last attempt.

[dzx-dzx]

ClockDomain(dut.io.gt_ref_clk_p_40MAC_0).forkStimulus(19200000) // 156.25 MHz on base frequency 3e3 GHz ClockDomain(dut.io.sys_clk_p).forkStimulus(1000000) // 600 MHz

Oh the number is too large. Now implemented in cfddf82943564e7930f185a99761ecda1f040cb7.

[dzx-dzx]

My…I've upgrade the xci.

1. Start the simulation, and then open the generated project.
2. Correct the part version and upgrade IP.
3. Disable core containers.
4. Find xci in srcs, and source code in gen.
5. Overwrite. (Don't add l_ethernet_0_gt)

[dzx-dzx]

You only need .xci files to boot up the simulation, but ALL of them. Some could be inside another IP's folder.

[dzx-dzx]

Hmm...

[dzx-dzx]

.addSimulatorFlag("-d SIM_SPEED_UP") doesn't do its job. Only .withSimScript.

[dzx-dzx]

You only need .xci files to boot up the simulation, but ALL of them. Some could be inside another IP's folder.

No that's not the problem...

The following IPs are either missing output products or output products are not up-to-date for Simulation target. Since these IPs are locked, no update to the output products can be done.

Maybe?