IM217 - Ability to query time on hardware side:

Hi Brian, ITC Techies,

 

In the last meeting I took the action item send a restatement of IM217 -
Ability to query time on hardware side.

 

Enclosed are both the statement of the issue and also a proposed
specification of the solution. 

 

Regards,

 

Shabtay

 

Statement of the problem:

 

Transactors need to be able to provide to the SW side the output
transaction begin time and transaction end time attributes to support
debugging and transaction recording w/o paying a performance penalty or
extremely complicating the modeling of the transactor. To align with
SCE-MI terminology, the term output transaction defines a DUT interface
sequence that is converted into one or more scemi messages (calls)
delivered by the HDL side producer into the scemi pipe using the
scemi_pipe_hdl_send task.

 

To avoid performance penalty, the storing of transaction begin time and
transaction end time attributes should not force synchronization between
HW side and SW side. When buffering is used the producer may deliver m
messages corresponding to n transactions, where for each transaction,
begin time and end time attributes must be stored w/o stoppage. The C
side should be able to retrieve the transaction begin time and end time
attributes associated for each transaction (should it wish to retrieve
these attributes) at the time that the HDL side yielded control to the
SW side. 

 

It is important to note that having the C side read the value of the
current simulation time will not provide the output transaction begin
time and transaction end time as the later happened in the past wrt to
current time.

 

Proposed specification of the solution:

 

1.	Only output scemi pipes will provide facilities to convey
transaction begin time and end time attributes. (Jason, we didn't see
why we would need this on input scemi pipe). 
2.	Time will be recorded into a 64 bit word register to provide
adequate accuracy and be consistent with SCEMI 1.1 cycle stamp. 
3.	When SCE-MI 1.1 is used, time will be updated by the 1/1 cclock
per SCE-MI 1.1 semantics. 
4.	In pure SCE-MI 2.0, time will be updated by the fastest clock
available on the HW side. 
5.	Time will start incrementing on the HW side only on the first
fastest/ 1/1 cclock pos edge after the HW side has reached point of
alignment. For SCE-MI 2.0, the definition of point of alignment has not
been defined and needs to be settled (may require an IM - see my email
sent on 4/25/06). 
6.	The semantics of storing the values is as follows: 

	*	Clear transaction begin time and end time on init 
	*	Store transaction begin time on the first call to
scemi_pipe_hdl_send() following init or on the next call following a
call to scemi_pipe_hdl_send() where eom flag was set. 
	*	Store transaction end time when scemi_pipe_hdl_send() is
called and eom is set. 

7.	To cover the case that BFM might not have yet an element to
deliver at output transaction begin time, scemi_pipe_hdl_send() could be
called with bytes_per_element and num_elements being 0.  Example: 

scemi_pipe_hdl_send(1, 0, 0, scemiData, 0) - will store the current time
when the task is being called as transaction begin time. The BFM is
actually posting a 'dummy' call in this case to initiate the storing of
the begin time attribute w/o sending any elements.

8.	The transaction begin time and end time will be stored as 2 64
bit word struct. The transaction begin time will be provided as an
address pointer to the begin time register location. The address of the
transaction end time could be calculated by the C side by incrementing
the begin time address. 
9.	The pointer will be provided as a CycleStamp pointer being the
last argument of sce_pipe_c_receive() after the eom flag. For example it
may look like, 

scemi_pipe_c_receive(1, 32, 4, &num_read, scemiData, &eom , CycleStamp).


Note that CycleStamp has an output direction.

10.	The SCE-MI infrastructure will update the CycleStamp pointer
address to the next cycle stamp value after scemi_pipe_c_receive()
returns with eom flag being set. 
11.	The transaction end time may not be correct if its value is
retrieved when calling scemi_pipe_c_receive() if the eom flag was not
set (as the transaction end time has not occurred yet). It will be a
good practice for the c side modeler to retrieve the transaction end
time value only when eom flag is set. 
12.	The SCE-MI infrastructure should store the values for all
current transactions but will be allowed to delete the cycle stamp
values of the previous transaction after scemi_pipe_c_receive() returned
with eom flag set. 

 

 

-------------------------------------

 

Shabtay Matalon

Solution Architect

R&D, CVA

Phone: (408) 428 5081

email: shabtay@cadence.com