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

Hi Per,

Please see my comments in-line:


Per Bojsen wrote:
> 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.
First, our transsctors don't do this - they're passing over a latched 
"current transaction value" so there's no possibility of the call 
argument changing until the next clock edge.  If any other design of 
transactor were to include live signals in the call argument, then it 
would certainly be a problem.


> 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.

I wouldn't have a problem with statements in the standard that:

1) the implementation should never make more than one call per clock cycle
2) that functions called from combo blocks may not have side effects
3) that the call argument(s) have to be stable

If the user and implementor obye these rules then you'll get consistent 
behavior between simulation and emulation, though these have then become 
"special" DPI functions.

Slightly off topic here, it's irritating that Verilog requires you to 
assign the return value of the function to a variable even if you're 
simply exporting data.


>> 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.

Actually I tried this but the problem I got into is Verilog won't allow 
me to slice the return value of a function call, for example I can't do:

c <= SetResponse( argument )[ `my_slice ]


Thanks for your comments,

Bernard




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


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




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