Shabtay’s take 04/28 - Requires resolution.

Committee agrees. still active

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.