Re: Follwup from Bernard Deadman

Hi Bernard,

some quick comments/answers to your email:

> I can see how we can use a function-based interface to calculate the 
> next state correctly, however I'm still at a loss to understand how the 
> semantics work with synthesizable Verilog to support the sequence I've 
> described where we get the output signals set correctly.

What you may not be aware of is that the SCE-MI implementation is free
to insert as many `uncontrolled' clock cycles as it needs under the
hood to allow the code to work.  The advantage of the DPI support in
SCE-MI is that the user is freed from having to worry about controlling
clocks.  It is the job of the implementation to map the DPI calls
to whatever it needs to realize it on the underlying platform.  You
should be able to write your transactor as John outlined and the
SCE-MI implementation is responsible for turning it into synthesizable
Verilog if that is what the underlying platform requires (not all do,
e.g., simulators).

 > It's certainly
> feasible if the transactor is able to stall the clock in the same manner 
> as allowed in SCE-MI 1.1 however without that feature I'm pretty sure we 
> are going to 'lose' a controlled clock cycle, thereby potentially 
> violating protocol rules in some designs.

You should be able to write your transactor in a way that you do not
lose a `controlled' clock cycle.  That would be a serious problem as
it would amount to loss of coverage in the stimulus your transactor
would be able to provide.  I am struggling with how to provide a
convincing argument as to why this shouldn't be an issue.  Perhaps
the best way is to write up a complete example?  John, do we have
something available that would illustrate back-to-back transactions
without dead cycles?

Per



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.