Confusing output of GCD midasexamples

[caizixian]

Background Work

• Yes, I searched the mailing list
• Yes, I searched prior issues
• Yes, I searched the documentation

FireSim Version and Hash

1.17.1

OS Setup

N/A

Other Setup

Current Behavior

I was following the documentation for midasexample. https://docs.fires.im/en/1.17.1/Advanced-Usage/Generating-Different-Targets.html#midas-examples-midasexamples-project and run make DESIGN=GCD TARGET_PROJECT=midasexamples with the following output.

Picked up JAVA_TOOL_OPTIONS: -Xmx16G -Xss8M -Djava.io.tmpdir=/home/zixianc/firesim/sim/.java_tmp
[AutoCounter] There are 0 counterAnnos available for selection in the following modules:
[AutoCounter] selected modules for cover-function based annotation:
[AutoCounter] selected 0 signals for instrumentation
[Golden Gate] total # of assertions synthesized: 1
[Golden Gate] total # of printf instances synthesized: 1
[MIDAS 2.0] RAM Models To Extract: 0
Instantiating bridge RationalClockBridge of type midas.widgets.ClockBridgeModule
  With constructor arguments: ClockParameters(List(RationalClock(BaseClock,1,1)))
Instantiating bridge peekPokeBridge of type midas.widgets.PeekPokeBridgeModule
  With constructor arguments: PeekPokeKey(List(SerializableField(io_v,SerializableType(UInt),1), SerializableField(io_z,SerializableType(UInt),16)),List(SerializableField(reset,SerializableType(UInt),1), SerializableField(io_e,SerializableType(UInt),1), SerializableField(io_b,SerializableType(UInt),16), SerializableField(io_a,SerializableType(UInt),16)),2)
Instantiating bridge midasAsserts_RationalClockBridge_clocks_0_asserts of type midas.widgets.AssertBridgeModule
  With constructor arguments: AssertBridgeParameters(midasAsserts_RationalClockBridge_clocks_0_asserts,midasAsserts_RationalClockBridge_clocks_0_globalResetCondition,List(module: GCDDUT, path: GCD.dut]
Assertion failed: Outputs do not match!
    at GCD.scala:76 assert(!done1 || !done2 || (result1 === result2), \"Outputs do not match!\")
))
Instantiating bridge synthesizedPrintf of type midas.widgets.PrintBridgeModule
  With constructor arguments: PrintBridgeParameters(synthesizedPrintf_RationalClockBridge_clocks_0_globalReset,List(PrintPort(synthesizedPrintf_dut_printf_wire,List((enable,UInt<1>), (args_0,UInt<1>), (args_1,UInt<1>), (args_2,UInt<16>), (args_3,UInt<16>)),SYNTHESIZED_PRINT done1: %d, done2: %d, result1: %d, result2: %d)))
Bridge Streams To CPU:
  Name: PRINTBRIDGEMODULE_0_to_cpu_stream, Idx: 0, FPGA Buffer Depth: 6144, FPGA Buffer Width: 64
Bridge Streams From CPU:
  None
Simulator Memory Map:
  [   0,   3f]: PeekPokeBridgeModule_0
  [  40,   5f]: ClockBridgeModule_0
  [  60,   7f]: AssertBridgeModule_0
  [  80,   9f]: PrintBridgeModule_0
  [  a0,   af]: SimulationMaster_0
  [  b0,   b3]: CPUManagedStreamEngine_0
Total Host-FPGA DRAM Allocated: 0.000 KiB of 64.000 GiB available.
Auto ILA: Sample depth = 1024, trigger comparators = 2
Auto ILA: Generated 2 probes:
  ila_top_sim_target_GCD_dut_inner1__x, width: 16
  ila_top_sim_target_GCD_dut_inner2__x, width: 16

It gives me the impression that the test itself was run and an assertion failed. So I tried to insert some SynthesizePrintf, but couldn't find the output.

After some searching, #150 hinted that I actually need to provide some make targets to run the test. And sure enough, run-verilator does the trick.

* EXPECT GCD.io_z -> 0x10 ?= 0x10 : PASS
[GCD]PASS Test
SEED: 0

Simulation complete.
*** PASSED *** after 12 cycles

Emulation Performance Summary
------------------------------
Wallclock Time Elapsed: 0.0 s
Host Frequency: 86.180 KHz
Target Cycles Emulated: 12
Effective Target Frequency: 6.306 KHz
FMR: 13.67
Note: The latter three figures are based on the fastest target clock.

With hindsight, the make documentation is in the doc https://docs.fires.im/en/stable/Advanced-Usage/Debugging-in-Software/RTL-Simulation.html?highlight=verilator#running-metasimulations-through-make , but it wasn't very obvious to me. You will first need to know there's a verilator for make before you can effectively search the documentation. Perhaps some cross references could clarify this.

After all these, I still don't know why the assertion error is there (perhaps it's just an artifact of how assertion endpoints are generated?), so perhaps the documentation can also clarify this.

Expected Behavior

Improved documentation

Other Information

No response