# Modeling bidirectional propagation delays

I'd like to build a VHDL model of the propagation delays on my board. For unidirectional signals, that is easy:

u1_pinb3 <= transport u2_pin3 after 10 ps;     -- todo replace by actual delay from board model
u2_pin4 <= transport u1_pinb4 after 10 ps;


However, for bidirectional signals that would obviously create a loop:

u1_pinb5 <= transport u2_pin5 after 10 ps;
u2_pin5 <= transport u1_pinb5 after 10 ps;


If I have simulation models of two components that talk to each other over a bidirectional bus, can I somehow generate a full system simulation that lets me inspect bus turnaround?

• Is u1_pinb5 an inout port? Jul 30, 2021 at 11:13
• @MituRaj, yes, both u1_pinb5 and u2_pin5 are inout ports on components that are simulation models of ICs that are at some distance to each other, hence the desire to simulate transmission delays. Jul 30, 2021 at 11:51
• So you don't have access to the internal of the components which have these two ports? Jul 30, 2021 at 14:42
• @MituRaj, no, these are encrypted models of FPGA hard IP blocks. Jul 30, 2021 at 15:12
• Tricky scenario. But what I feel is that you need to put the delay 10 ps only on one side of the bidirectional line. Say, on path A-->B, where A drives the line . Then automatically B-->A path also becomes 10 ps delayed. Because ideally when B drives the line, A should be driving it Z at the same time. So the driver's (B's) value 'reaches' A after and can be resolved at A, only when A drives the line to 'Z'. But A drives 'Z' with a 10 ps delay. Jul 30, 2021 at 16:07

Typically inout ports have controls that enable the drivers.

u1_pinb5 <= u2_pin5 after 10 ps when Control = '1' else 'Z' after 10 ps ;

• I don't have access to those, the signals in question are DQ lines from a DDR3 hard IP block where the simulation model is available only as an encrypted file. Jul 30, 2021 at 13:12

If you "know" when each chip is driving the bus you could try something like:

   p_delays : process(ic1_drive, ic2_drive, ic1_pin_io, ic2_pin_io)
begin
ic1_pin_io <= transport 'Z' after (12 ps);
ic2_pin_io <= transport 'Z' after (13 ps);

if(ic1_drive) then
ic2_pin_io <= transport ic1_pin_io after 9 ps;
ic1_pin_io <= transport 'Z' after 12 ps;
end if;
if(ic2_drive) then
ic1_pin_io <= transport ic2_pin_io after 11 ps;
ic2_pin_io <= transport 'Z' after 13 ps;
end if;
end process p_delays;


With:

• U1 having: any-to-data delay of 10 ps, data-to-Z delay of 13 ps
• U2 having: any-to-data delay of 11 ps, data-to-Z delay of 12 ps

To create ic1_drive and ic2_drive the test bench must look at the control signals in the transaction, and determine what is happening (this may be non trivial).

Maybe, but it’s not trivial. I believe it is better to model the transmission line with the Dk or ps/mm, and all impedances. Then with path length the trace ringing from risetime and return loss or impedance mismatch with an understanding of the metastable margins for synchronous transfer and voltage margins with component tolerances , path skew etc, are more useful.

Verification requires adding mismatch tolerances to impedance and path skew to determine the timing margin variations with temperature and supply tolerances.

https://www.researchgate.net/publication/224238992_Formal_verification_of_timed_VHDL_programs

If you can imagine it, you can synthesize it!

Notice what happens when you use 3V logic ungerminated with a short ohm strip loaded by input capacitance at 500 MHz or any speed for that matter if the risetime is faster than delay time.

• Simulation time is abysmal as it is, with three hours for 100 µs, but yes, that would be the next step after that, but it can be simplified to generating 'X' for the time where the signal cannot be reliably read -- that should be doable by resolving the signal with a delayed version of itself. In the first iteration, being able to simulate bus turnaround and inspect waveforms at the connection points for each component at all would be a good start. Jul 30, 2021 at 14:35
• I added a great simulator that will do any sampling rate and trace speed independently with your accurate model of impedance. Jul 30, 2021 at 18:50
• Then see a different model with slew rate limiting and 50 Ohm load on 75 Ohm load. tinyurl.com/yj33s49w Not ideal, but then your model is unknown! Jul 30, 2021 at 18:58