[myhdl-list] Re: inout signals and cosimulation

[Terry B. <tt...@ve...>]

Jan Decaluwe wrote:
> Terry Brown wrote:
> 

> 
> Looking through the code, I think the difference is the delay in the 
> Verilog
> code - probably you have run into a cosimulation restriction.
> 
> Please read the section "Restrictions" in the chapter on cosimulation
> in the manual. It describes some background on the difficulties of PLI
> programming and the resulting compromise. Here is a relevant quote:
> 
> """
> As explained before, co-simulated Verilog should not contain delay
> statements. Ideally, there should be a run-time check to flag
> non-compliant code. However, there is currently no such check in the
> Icarus module.
> 
> The check can be written using the \code{cbNextSimTime} VPI callback
> in Verilog. However, Icarus 0.7 doesn't support this callback. In the
> meantime, support for it has been added to the Icarus development
> branch.  When Icarus 0.8 is released, a check will be added.
> 
> In the mean time, just don't do this. It may appear to ``work'' but it
> really won't as events will be missed over the co-simulation
> interface.
> """
> 
> This seems to describe the problem that you are facing.

Well, it does describe the problem, but I don't think the delay you 
refer to is the problem.  This delay was added in an attempt to define 
and understand the problem.  I wanted to move the position of the signal 
around to be sure I was sampling at the right time with the print 
statement.  The problem originated with this delay present.  And, 
although I understand this problem is with myhdl, is there any 
difference in behavior with cver as opposed to icarus?  I am using cver.

For what it's worth, using that delay does indeed move the signal as 
expected but I still don't see it in myhdl.

I also had tried sampling the signal within myhdl at the negative edge 
of clock and had no luck.

I removed the delay and also removed a ram model which contained delays 
from the verilog simulation and I still get the same problem--the signal 
doesn't make it across the interface

> It's of course disturbing that the run-time check isn't there and I
> will see if I can add it. However, your example got me thinking:
> while it may be reasonable to disallow delays over the cosimulation
> interface, it may be too severe to disallow them at all in the
> Verilog - as long as Verilog doesn't run "faster" than the MyHDL side.
> In that case, you could still have delayed signals internally.
> What do you think?

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?

Thanks,

Terry
> 
> Regards, Jan
>