Re: more on Bernard's SCE-MI 2.0 issue

Hi Bernard,

> 1) efficiency issues when using function calls in combo-blocks
> -----------
> 
> Johns email addressed this issue.  Yes, our response lookup functions 
> are 'safe' in that they don't cause side effects in the testbench. With 
> a small caveat about the synthesizable sub-set of Verilog used by 
> emulators, I agree that in principle the transactors will function 
> correctly, and that the implementation can hide a lot of the work and 
> can potentially handle these calls efficiently PROVIDED IT CAN RECOGNIZE 
> OR CAN BE TOLD THAT THE FUNCTION ONLY NEEDS TO BE PERFORMED ONCE PER 
> CONTROLLED CLOCK CYCLE.

Somehow I don't think this will be a big issue.  Implementations
based on FPGAs are likely to naturally implement any imported
function calls in combinatorial blocks this way since the function
call probably will be implemented by some clocked logic using an
equivalent of an uncontrolled clock so the combinatorial signals
that feed into this will naturally settle out and lead to only
one call of the imported call.  Other implementations which rely
on delta-cycles may need to do some extra work to ensure the call
only happens once, but it will be worth doing in order to improve
performance.

There is one question that is worrying me, though.  What if the
inputs to the combinatorial block feed into the imported call
as arguments?  Then you can have each of the potentially multiple
calls per clock cycle have different values of its arguments as
the combinatorial block settles.  I am wondering if the optimization
of squashing the multiple calls to one is safe in this case?
It will be safe if the imported call has no side effects and there
is no asynchronous logic involved, I guess, but we can't expect
the implementation to be able to do such an analysis automatically.

So I am not sure if we can off hand state that it is safe for the
implementation to always squash the multiple calls.  Perhaps one
way out of this is to add language to the standard that puts it
on the user to make sure his calls are without side effects.  We
could say that if the calls have side effects then the implementation
will no longer guarantee equivalent behavior with another implementation
such as a SystemVerilog simulator.

> iii) I have some nervousness about two of the Verilog code constructs 
> we've been forced to use, both of which I've been discouraged from using 
> in synthesis - I freely admit I'm not a synthesis guru and may be 
> worrying un-necessarily here:
>    a) the return value of the SetResponse function has to be assigned to 
> local storage which is used later in the combo block
>    b) the clocked block contains both blocking and non-blocking assignments

In my experience these constructs are not a problem for synthesis.
I have used this on multiple emulator platforms, but local variables
with block assigns can always be rewritten by substituting the
right-hand side where the variable is used.  This would obviously
lead to SetResponse() being mentioned multiple times although it
may or may not mean it will be called more than it was before.  That
would depend on the control flow through the code.  For example:

   a = SetResponse();

   if (b)
     c <= a;
   else
     d <= a;

would turn into:

   if (b)
     c <= SetResponse();
   else
     d <= SetResponse();

In this example SetResponse() would only get called once even though
the call occurs twice.

Per



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