Re: time access proposal

Greetings ITC Techies,

The more I think about it, the more I'm thinking
a string attribute approach might be the best after all.

This is kind of an offshoot of Duaine's idea.

Think about this:

Both VHDL and SystemVerilog accept the following syntax
for literal values of type 'time'

   <# units> <unit specifier>

Furthermore the unit specifier is the same for both.

So, since this is already a standard syntax in two
languages, why not just say our string syntax for
the 'ClockPeriod' parameter must conform to it ?

I'm not sure what the issue is with parsing here.
And, it is a solution that will carry over to all
3 languages supported by SCE-MI 1 since all three
support string parameters(generics).

-- johnS

John Stickley wrote:
> 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             \_
> 

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________