real world threading model

Calvin Wong (cawong) cawong at cisco.com
Tue Aug 21 17:59:39 EDT 2007


See comments below.
 
----- Original Message ----- 
From: "Suraj N. Kurapati" <sunaku at gmail.com>
To: "Discussion list for the Ruby-VPI project"
<ruby-vpi-discuss at rubyforge.org>
Sent: Thursday, August 16, 2007 9:11 PM
Subject: Re: real world threading model

> 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.
> 
 
There also may be cases where the IP you are instantiating have a
smaller
timescale than what you are currently working on.  And that means that
you may have to decrease the timescale on the advance_time method which
in turn will increase the number of posted events to the verilog
simulator as
well.

> 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.
> 
 
Each thread executes within their own timestep.  The scheduler only
ensures that each thread executes in the proper order.  For cases where
two threads needs to respond to the same triggering event, then those
two threads can operate in parallel till another blocking event such as
atXEdge
or a simTimeWait occurs.

>  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?
 
To answer the race condition issue, the verilog simulator itself should
resolve any race conditions.  In our testbench environment, all signal
changes always occurs with some time delay after the atXEdge statement.
This insures that other threads will sample the same value at the same
edge.

> 
>> 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.
> 
 
To handle multiple DUT, one can employ the same idea of using the
global thread manager.  Each prototype will just have to execute
the simulation in a thread using the common atXEdge, atPosEdge,
atNegEdge,
and wait routines.
 
The main thrust behind using this model is that I was trying to use
Ruby as an extension of Verilog while keeping most of the Verilog
behavioral framework intact.

>> 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.
>
 
I was hestitant to learn Ruby at first coming from a PERL background,
but
after 2 days I consider myself pretty proficient at it.  It's a really
good object
oriented language and I hope more people will adopt it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070821/135b3dfa/attachment-0001.html 


More information about the Ruby-VPI-discuss mailing list