time access proposal

Greetings ITC Techies,

Here's the AI from Russ and myself for time access. It is mainly
a writeup of the proposal we discussed verbally last meeting
and, I think, got more of less of a consensus on.

Proposal:

----------------------------------------------------------
Part 1: C-Side Time Access

Assuming a pure SCE-MI 2.0 environment, it shouldn't be necessary
to force  the user to instantiate the SCE-MI object from SCE-MI 1.1
to get time  information from the HDL side. To do so would
unnecessarily damage the SCE-MI 2 goal of being able to design
and run the testbench environment in pure simulation, and have
that port fairly seamlessly to emulation (or H/W acceleration).

For this example, we'll neglect the VHDL case and look at only
the Verilog/SystemVerilog case. Actually, this example will work
even for VHDL as long as the simulator supports mixed language
(and therefore VPI) which all of them that I'm aware of do.

To access time in Verilog/SystemVerilog simulations we use two
calls from VPI to get current time and global precision:

- void vpi_get_time( vpiHandle obj, s_vpi_time *time_p );
   - This can be used to obtain current time expressed in simulation units

- int vpi_get( int prop, vpiHandle obj );
   - This can be used to obtain global precision units in which
     current time is expressed

Given the ability to obtain current time in simulation units
and the precision of those simulation units, one can easily
derive current time expressed in any units desired.

Here is an example of a small "reference library" that
can return current time in NS in any environment
that supports the two VPI calls mentioned above:

static double timescale_factor = 1.0;
static double precision_conversion_factors[] = {
           1.0, //   1  s (0)
           1.0, // 100 ms (-1)
           1.0, //  10 ms (-2)
           1.0, //   1 ms (-3)
           1.0, // 100 us (-4)
           1.0, //  10 us (-5)
           1.0, //   1 us (-6)
           1.0, // 100 ns (-7)
           1.0, //  10 ns (-8)
           1.0, //   1 ns (-9)
          10.0, // 100 ps (-10)
         100.0, //  10 ps (-11)
        1000.0, //   1 ps (-12)
       10000.0, // 100 fs (-13)
      100000.0, //  10 fs (-14)
     1000000.0, //   1 fs (-15)
};

// Call this at init time.
void init_time_library(){
   int precision_code = -vpi_get( vpiTimePrecision, NULL );

   if( precision_code < 9 )
     Error( "Precisions courser than 1 ns not handled" )

   timescale_factor = precision_conversion_factors[precision_code];
}

// Call this whenever you want time in NS
unsigned long long time_in_ns() {
   static s_vpi_time time = { vpiSimTime, 0, 0, 0.0 };

   vpi_get_time( NULL, &time );

   unsigned long long ret =
       ( ((unsigned long long)time.high) << 32 ) | time.low;

   return (unsigned long long)( (double)ret/timescale_factor+.5 );
}

We propose SCE-MI 2 would require vendors to provide, in one
form or another, at least the functionality described above
in these two calls even if no other aspect of VPI is supported.

Of course if VPI is supported already, no extra work has to be
done by the vendor to provide SCE-MI 2 compliant time access
capability !

In in emulation environment it will be up to the vendor's
infrastructure to keep the C side's internal notion of time
properly updated with the emulator's notion.

This can be done by carrying something like the old "cyclestamp"
along with each internal output transaction associated with
an alternating implementation of imported and exported calls.

For streaming threads, the current time access would only be
guaranteed at "synchronization points" defined by flushes of
DPI pipes.

----------------------------------------------------------
Part 2: Establishing Time Base on H/W side

Currently in the SCE-MI 1.1 specification, since all clock
definitions are ratio based, there is no way of specifying the
time base on the H/W side.

In order for to be able to implement time accesses from the C
side (as described in Part I above), there must be a way of
fixing the H/W side time base.

The easiest way to do this is to specify the period of at least
the fastest user cclock. By doing this, the cyclestamp can
be associated directly with actual absolute time units.

Do do this, we propose a variant of the SceMiClockPort macro that
allows specification of a clock period. This new form of the macro
is called SceMiClockPortP defined as follows:


     module SceMiClockPortP( Cclock, Creset );
         parameter ClockNum=1;
         parameter ClockPeriod = "1 ps";
         parameter DutyHi=0, DutyLo=100, Phase=0;
         parameter ResetCycles=8;
         output Cclock, Creset;
     endmodule

     component SceMiClockPortP
         generic(
             ClockNum         : natural := 1;
             ClockPeriod      : string  := "1 ps";
             DutyHi           : natural := 0;
             DutyLo           : natural := 100;
             Phase            : natural := 0;
             ResetCycles      : natural := 8 );
         port(
             Cclock        : out std_logic;
             Creset        : out std_logic) ;
     end component;

The clock period specification is given as a string which will
be parsed by the infrastructure to establish the period
of that clock.

The default period shall be 1 ps. Notice that the period
specification replaces the ratio specification in the
current SceMiClockPort macro.

A typical application can specify the fastest clock in the system
with this macro then, specify all other clocks in the usual way
as ratios of this clock. Or, alternatively, all clocks can be
specified with periods using SceMiClockPortP macros in which case,
ratios between them are implied and easily derived.

-- johnS

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_