Subject: SCE-MI Proposal Topic #1
From: Matt Kopser (mkopser@cadence.com)
Date: Mon Jan 12 2004 - 12:52:30 PST
All,
This email outlines 'topic #1', as follow-up to the Accellera
meeting on 1/8/04.
This issue is a basic one. From it, more specific, detailed
issues arise. For now, I'd like to get some discussion going
on what the expected impact to users (both end-users and BFM
model-writers) would be for this issue. Specifically, what
percentage of models/systems would we expect to be effected,
and to what degree.
---As stated earlier, the two root areas to be addressed in the proposal from Cadence are:
- Creation of a variable-length message mechanism - Elimination (for the broadest scope of models and verification environments possible) of the uncontrolled clock
A proposed variable-length SCE-MI message would transfer a variable number of fixed-width 'words' on successive user-defined ('controlled', if you will) clocks. Definition of such clock signals would be outside the scope of SCE-MI itself, and the clock signal for each variable-length message port would be an input to the SCE-MI infrastructure.
Hypothetically, the verilog prototype of such an (input) message port macro might look something like this:
====================================================================== module SceMiVarMessageInPort(Clock, ReceiveReady, TransmitReady, TransmitLast, Message);
parameter PortWidth = 1;
input Clock; // data transfers synchronized to this signal input ReceiveReady; // BFM able to consume next message word
output TransmitReady; // Infrastructure presenting valid message word output TransmitLast; // Infrastructure is presenting final word of // (potentially) multi-word message output Message; // message data from infrastructure
endmodule ======================================================================
When 'TransmitReady' is asserted by the infrastructure, and 'ReceiveReady' is asserted by the BFM, a word of 'Message' data is assumed to transfer from the infrastructure side to the BFM, on rising 'Clock'. On a rising 'Clock', with 'TransmitReady', 'ReceiveReady' and 'TransmitLast' all asserted, the final word of the message is transferred to the BFM.
In order to meet the BFM's bandwidth requirements for this message port macro, the BFM-writer has two controls; the width of the 'Message' port, and the frequency of 'Clock'. (Actually, the BFM-writer does not have *direct* control of the 'Clock' frequency, but the required frequency of this clock with respect to the DUT-side interface clock(s) would be specified by the BFM-writer.) For example, if the BFM requires two message 'words' for each DUT clock cycle, then the required BFM/ infrastructure clock frequency would be 2X the BFM/DUT clock frequency.
Implicit in this port macro definition is the fact that 'Clock' cycles occur ('time' advances) as a normal side-effect of the operation of the infrastructure/BFM data transfer. There are two limitations inherent in this mechanism:
1) This interface cannot support a BFM which may require an arbitrary, and potentially unbounded number of 'clocks' to process/organize incoming data from the infrastructure, before applying such data (or a derivative thereof) to the DUT.
2) Even in the cases where the number of 'extra' clocks (above and beyond the DUT-side clock frequency) required by the BFM, to process incoming data is statically known, and specifiable, an overall system performance degradation may be introduced. In particular, if the BFM/DUT interface utilizes the fastest user system clock frequency, and 'oversampling' is required on the infrastructure/BFM side, then a new 'fastest clock' frequency is implicitly created. This can adversely effect emulation system performance.
Thanks in advance for your discussion and feedback,
Matt Kopser Senior Member, Consulting Staff Design & Verification, Cadence Design Systems
This archive was generated by hypermail 2b28 : Mon Jan 12 2004 - 12:52:49 PST