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

Hi Bernard,

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

I didn't think you were doing this kind of thing.  I was trying to
come up with a counter example to the idea that an implementation
would be always correct if it always squashes the multiple calls
potentially generated from combinatorial blocks.  I think the
issue here is that that kind of coding style is not guaranteed to
lead to deterministic and reproducible behavior.

> 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

Unfortunately, I don't think we can include such a statement as
it would preclude SystemVerilog simulators from being able to
act as an implementation of the DPI subset of SCE-MI 2.0.

> 2) that functions called from combo blocks may not have side effects
> 3) that the call argument(s) have to be stable

These two I think we could add.  They are constraints imposed on
the application.  Note, if (2) and (3) are obeyed then (1) is not
necessary for correct and consistent behavior.  Essentially, (1)
is then reduced to a performance issue.

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

I hadn't thought of this.  In that case the local variable is
necessary.  But I still think synthesis should be able to handle
it.

Per



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