[myhdl-list] Re: inout signals and cosimulation

[Jan D. <ja...@ja...>]

Terry Brown wrote:

> Well, I think that the utility of myhdl as a testbench tool (which is 
> primarily how I am intending to use it) is severely compromised if 
> delays are not allowed at all in the verilog code.  I use many vendor 
> models for things like SSRAM and SDRAM and so on which include delays, 
> and delays are included in most FPGA libraries as well and used in post 
> place and route verilog models produced by Xilinx and other FPGA 
> vendors.  Having to disable these to use myhdl is too much to ask.  And 
> although I don't use post place and route models for timing analysis 
> usually, I do use them for troubleshooting synthesis problems.  To have 
> to maintain a test bench in verilog to do this probably means I should 
> just do the whole thing in verilog.
> 
> Also, I guess I'm not quite clear on which delay might be ok and which 
> not and what you mean by the verilog running faster than myhdl.  Can you 
> clarify?

Yes. In the ideal case, cosimulation should be fully general and both
sides should allow arbitrary delays while staying in sync with each other.
For various reasons, I think this is hard to achieve. A compromise (which
I believe other HVLs use also) is to make one side the "master" of time,
where one simulator decides on when time advances for *both*. In case of
MyHDL, my choice was to make MyHDL the master in a cosimulation.

Now the question is: what restrictions does this imply? The brute-force
approach would be to simply disallow delays in the "slave" simulator.
This is how I currently have it in the documentation.
As you point out, this may be too strong, and in fact, by thinking further
about it, I conclude that it's not necessary to be that restrictive.

Suppose MyHDL is done at time t1 and its next event is at t2. As the
master, it will want to set time to t2 for the slave also before
continuing. But before that, the slave (also at t1) could perfectly
continue to simulate, with delays, if and only if:

1) it doesn't pass time t2 (because MyHDL's event would influence it at that time)
   This is what I meant with "the verilog running faster".
2) the signals that change with a delay don't influence the MyHDL simulation,
   that is, nothing is waiting for them. Note that such signals could
   perfectly be read and used at the MyHDL side - they just shouldn't be in 
   a MyHDL sensitivity list.

So it's not that bad I think. In fact, you could use cosimulation in this
mode with the current version. The only problem is that there is no run-time
check that checks whether you obey the rules - but in the future that should be
perfectly possible.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html