DUT Model synchronization

[c4brian]

Let's say that I have a VHDL DUT which is a state machine driven by a 50MHz clock (20 ns period).

This state machine has 5 states which advance on every clock, and loops after the final state.

On the final state, it reads an external counter.

 

Now let's say I want to create a "golden reference" model for the DUT (using SystemC).

Ok so let's see, the only way this would work is if I code a looping thread, that simply waits 100 ns, then reads the counter, and repeats.  Agree?

 

Now fast forward a few months, and the DUT has grown exponentially; it's now a 2000-state state machine, it processes input messages, waits on interrupts, etc.

Yet somewhere buried in it's multi-branch state tree, it still needs to grab the contents of this counter.

 

Since I have to guarantee they grab the counter value at the same time, am I supposed to inject the actual delay values of the DUT's state machine branches into the reference model?

This sounds like the WRONG thing to do.  Thoughts?

 

 

 

[David Black]

Could you elaborate on the statement, "they grab the counter value at the same time"?

Who is "they"?

How are you modeling the FSM behavior? Are you using an inferred FSM perhaps?

Have you considered temporally decoupling your model and performing synchronization only when the timer needs to be read?

[tudor.timi]

As David already mentioned, you don't have to keep your model and the DUT in exact lockstep. Most of the times you don't need to care about such micro-architectural aspects that can be verified through other means (like SVAs). Your goal isn't to re-implement the design in all its glory in your testbench.

[karandeep963]

Adding some thoughts , 

 

I am using this multi-language (UVM- SV-SC) TB in many projects and I feel its best method than anything.

 

See your model not run on its own(as you think like DUT) in this case its not the RTL dont imagine it like RTL, it should ideally be supplied the request transaction when their is response from DUT. In this case your model will take a call and execute in zero time so you will be getting the updated response which should ideally be the same as that of RTL.

 

There would be some grey areas such as when you have parallel accesses, for an instance one bus is reading/writing FIFO's and you are monitoring the status on other bus(register access) in that case you would probably need to modify your sequences in such a way that you should be monitoring the status after your vectors done.

 

These sought of some grey areas will created if user doesn't think the overall scenarios carefully.

 

Anyway Modeling is an art of imagination this is what I feel

[c4brian]

David; yes my model is temporally decoupled from the DUT.  It's a single thread, untimed, and purely event driven.  This is of course, was also the source of my synchronization problems.  Since the decision branches chosen by the real state machine depend on WHEN the decisions are made.  The model can zip through a whole branch of functionality in a single time slice.

 

What I ended up doing was... at key decision points, I had to detect (for example, that the RTL FSM was in state 5, where it makes a branch decision), send a generic payload over to my SystemC model, who is pending on that transaction to arrive.