real world threading model

Suraj N. Kurapati sunaku at gmail.com
Fri Aug 17 00:11:46 EDT 2007


Calvin Wong (cawong) wrote:
> Here is a real world example where this scheme is important.  In
> your ASIC, you might instantiate multiple Intellectual Properties
> (IP) RTL.  Each of these IP has a source synchronous clock and
> each of these clocks are asynchronous to each other with jitters.
>  You need these clocks as reference for data sampling.  So, there
> might not be an accurate sampling point for each of these
> interfaces.

Ah, thanks for this background.  I now understand that you based
your threading model on VPI callbacks because that would allow you
to run some code at the precise moment that a certain value had changed.

In contrast, my threading model assumed that we only want to run
some code (in response to a value change) at the *end* of a time
step--rather than at the precise moment when the value had changed.

The main reason for this assumption is that it makes the threading
model simpler:

  1. All threads execute in parallel within the *same* time step.

  2. We only advance the entire simulation to the next time step
     when *all* threads are finished with the current time step.

In your threading model, the rules are:

  1. All threads (effectively) execute in parallel within the
     *same* time step.

  2. Any thread may advance the entire simulation to the next time
     step, without having to wait for the other threads to finish.
     This may cause race conditions where some threads initially
     see one picture of the simulation database (the current time
     step) and later see another picture (a future time step)--all
     the while thinking that they are executing inside the same
     time step.

Any thoughts on this?

> We have many of these cases in our designs.  We currently use C++
> for the full chip verification language and we implemented the
> posedge/negedge/wait in a similar fashion using threads.

Excellent.  Your experience with such system level modeling via pure
emulation will come in handy when I start working on supporting >1
Ruby DUT prototypes.  I'll discuss my ideas on this topic in the
near future, once the threading model is finished.

> But I believe C++ is an overkill for unit level testing, Verilog
> doesn't have enough constructs, and SystemVerilog is still
> inconsistent between the different simulation vendors.  But ...
> vpi and verilog 95/2001 seems to be the lowest common
> denominator.

Agreed.

> So ... writing my testbench in ruby will definitely be the 
> ultimate time saver to verify my designs.

Although I'm biased to say this, I certainly think you've made a
good decision on choosing the Ruby language.  With your support, I
am confident that Ruby-VPI can be improved to meet this challenge.


More information about the Ruby-VPI-discuss mailing list