SystemVerilog "program" scope

[BigSteve]

Hi all,

I use SystemC quite extensively to validate verilated SystemVerilog code. Verilator, produces a SystemC wrapper around a model that when evaluated behaves like the equivalent SystemVerilog RTL.

Within the context of my surrounding verification environment, I instantiate the Verilated module and clock it. My associated SystemC is driven off this same clock and consists of a range of SC_METHODS and SC_THREADS. At present, to sample the output of my Verilated module, I am forced to introduce a very small delay after the rising edge of the clock to ensure that the SystemC environment evaluates after the Verilated module. Without this small delay, the SystemC will often sample stale state before it evaluates before the Verilated module.

I understand that in an event-driven model such as SystemC it is not possible to determine the order in which proceses evaluate, you may recall however from SystemVerilog that a "program" scope exists where a UUT can be evaluated before the surrounding code evaluates. This avoids the sequencing issues between RTL and the TB, and drastically simplifies the code. My question is this: what is the established technique to achieve the same behavior in SystemC? Is there a more sophisticate synchronizing scheme other than simply introducing some arbitrary sampling delay?

Steve

[Roman Popov]

I don't know much about SystemVerilog scheduling, but in SystemC there is no difference between RTL code and testbench code.  So you should not rely on order of process evaluation inside a single delta cycle.  

In practice, I also use Verilator for verification of HLS-generated Verilog designs, but I've never needed a delayed sampling. Verilator does not introduce any additional delays to model so I can use original SystemC testbench as is.

Why do you need delayed sampling?

[Bas Arts]

From a hardware verification point of view, a simple solution would be to let the SC TB sample on the falling clock edge i.s.o. the same rising edge.

[BigSteve]

Basarts, this is indeed a very valid solution; however, I am more interested in the correct, canonical method - I've always viewed this approach as a bit of a hack.

Roman: Consider two processes, clocked from the same clock. One a Verilated module; Two some sampler that samples the output of the Verilated module. If Two runs before One, Two sees the old data. Is there no way to enforce that One be evaluated before Two? It appears that SystemC has no notion of this; whereas SystemVerilog does. 

[Roman Popov]

53 minutes ago, BigSteve said:

Roman: Consider two processes, clocked from the same clock. One a Verilated module; Two some sampler that samples the output of the Verilated module. If Two runs before One, Two sees the old data. Is there no way to enforce that One be evaluated before Two? It appears that SystemC has no notion of this; whereas SystemVerilog does. 

You can create a delayed clock signal that can be used to synchronize testbench threads. With a delta cycle delay you can achieve a behavior you want (enforce all testbench processes to be evaluated on next delta cycle after DUT process).

However, such a test environment won't be reusable for non-verilated code (RTL simulation with commercial Verilog simulators, Gate-level simulation, etc).  

In a RTL design with a single clock domain Verilator converts all Verilog processes into a single SystemC clocked SC_METHOD. This SC_METHOD executes in a single delta cycle. However, in other Verilog simulators each Verilog process will be executed separately. For example, there can be a combinatorial logic process that can introduce arbitrary number of delta-cycle delays between clocked process in DUT and testbench. So sampling with a delta-cycle delay will not work.

In a timing-aware gate-level simulation delay can be any time period less then a clock period (if design meets timing constraints). In that case sampling on a falling edge of a clock may not work. 

Canonical solution to this problem is to sample output on the next clock cycle. So, for example, to test a single D flip-flop you will need 3 clock cycles: On a 1st clock cycle test sets input data, on a 2nd cycle DFF captures input data, on a 3rd clock cycle test verifies DFF output data.

[BigSteve]

Roman, 

Thanks for your reply. It would appear that at some point the notion of PHASE_CALLBACK was introduced into SystemC as an experimental feature. This would appear to be the precise feature that I am looking for. It allows for callbacks to be introduced that are then called on the various simulator phases (before_timestep, update_done, simulation_paused). It would appear that the update_done phase callback could be used to sample all the Verilated module outputs. This is in sc_simcontext.cpp. 

Will this ever been introduced into SystemC, or will it always remain an experimental feature?

 

 

[maehne]

It is up to the IEEE P1666 working group to decide, which currently experimental SystemC API features become official part of a future IEEE Std 1666 revision. The companies/people involved in the maintenance of the SystemC PoC simulator are also actively involved in this standardisation effort. The implementation of experimental features into the PoC implementation serve as a testbed to gain experience with them and collect feedback on their functionality, usability, and usefulness and real world applications. That is important input for the standardisation process.