How do you introduce delays into 3-state (bi-dir) lines?

[valtih1978]

This is needed for bus simulation

 

[KJ]

This is needed for bus simulation

Check out Ben Cohen's model at the link below

http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/de067db014e088d7/7d14832588a0cabb

Kevin Jennings

 

[KJ]

This is needed for bus simulation

Take a look at Ben Cohen's model at the link below

http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/de067db014e088d7/7d14832588a0cabb

Kevin Jennings

 

[valtih1978]

This is fine. But have you seen how it works?

Given
process begin
c <= '1'; wait for 3 ns;
c <= '0'; wait for 3 ns;
c <= '1'; wait for 3 ns;
end process;
a <= c;
I: entity ZeroOhm port map(a, b);

it produces

https://lh4.googleusercontent.com/-grNH7UAwVBw/Tjfe1819oII/AAAAAAAAADs/3jX6VMhFojA/s800/0ohm.png

The problem is those transitions of the order of the delays. That is,
listeners will not see your signal if the clock period is the same order
as the line delay. Though, the bus driver may produce a perfect signal.

 

[KJ]

This is fine. But have you seen how it works?

Given
        process begin
                c <= '1'; wait for 3 ns;
                c <= '0'; wait for 3 ns;
                c <= '1'; wait for 3 ns;
        end process;
        a <= c;
        I: entity ZeroOhm port map(a, b);

it produces

https://lh4.googleusercontent.com/-grNH7UAwVBw/Tjfe1819oII/AAAAAAAAAD...

The problem is those transitions of the order of the delays. That is,
listeners will not see your signal if the clock period is the same order
as the line delay. Though, the bus driver may produce a perfect signal.

This isn't a problem with the VHDL model of a delay, it's a problem
with the design.

Kevin Jennings

 

[valtih1978]

What is wrong with my "design"?

 

[KJ]

What is wrong with my "design"?

You said it yourself..."That is, listeners will not see your signal if
the clock period is the same order as the line delay." This implies
that your design is such that the clock and the data are in a race
condition at the 'listener' and some bad thing will occur due to the
data delay being on the order of the clock period.

You started that post with "The problem is...'. You said it's a
problem, so therefore it's a problem. My point is simply that the
'problem' has nothing to do with the VHDL model for a delay.
Therefore, it must be a problem with what that VHDL model is actually
modelling. Assuming that your VHDL model is modelling your design,
then the problem is with your design.

Precisely what that problem may be and how to address, I don't know
since I don't have access to your design. Your original question was
simply for a VHDL model for a bi-directional delay line presumably to
model either a long printed circuit board delay, or perhaps a cable or
something that is in your design. Now you have such a model.

Kevin Jennings

 

[valtih1978]

"That is, listeners will not see your signal if
the clock period is the same order as the line delay." This implies
that your design is such that the clock and the data are in a race
condition at the 'listener' and some bad thing will occur due to the
data delay being on the order of the clock period.

1) Wherever you have clock and data there is always race between them.
2) It definitely makes sense to simulate the board delays when they are
substantial compared to the clock period.

SDRAM access is a perfect example where you need to simulate the long
delays on a 3-state bus. If you want to match the simulation with
reality, you need to use them. SDRAM interface employs the
source-synchrony. Is it a bad design?

Also, it makes sense to simulate with delays even when they are short
but accumulate and risk to exeed the clock period. Yes, delays are used
right to simulate the race conditions. The delay simulation is a sign of
bad design!

 

[KJ]

On 14.08.2011 19:32, KJ wrote:

With each post you go off on a tangent that is unrelated to anything
you posted previously, so this will be my last response on this
thread. Good luck on whatever it is you are working on.

1) Wherever you have clock and data there is always race between them.

Are you trying to make a point with your statement? Other than
stating the obvious?

2) It definitely makes sense to simulate the board delays when they are
substantial compared to the clock period.

It makes more sense to perform static timing analysis...which is not
done with a VHDL simulator nor will it need a VHDL model.

SDRAM access is a perfect example where you need to simulate the long
delays on a 3-state bus. If you want to match the simulation with
reality, you need to use them. SDRAM interface employs the
source-synchrony. Is it a bad design?

'Bad' is a value judgment that is best left out of any technical
discussion.

As for SDRAM being a perfect example of where you need to simulate to
account for timing delays, I disagree. A functional simulation and
timing analysis are what you need for any design...not just SDRAM.
There is nothing inherently *worse* about an SDRAM interface timing
failure than any other sort of timing failure.

Also, it makes sense to simulate with delays even when they are short
but accumulate and risk to exeed the clock period. Yes, delays are used
right to simulate the race conditions.

As I said, it makes *more* sense to perform timing analysis.

The delay simulation is a sign of
bad design!

This statement makes no sense.

Kevin Jennings

 

[valtih1978]

'Bad' is a value judgment that is best left out of any technical

discussion.

We should keep talking about "a problem with the design" and "wrong
design" instead. They are more technical. Right?

Are you trying to make a point with your statement? Other than
stating the obvious?

I'm observing that somebody, who stated that "simulation of long delays
implies the races between clock and data and, thus, is a sign of
'untechnical' design" is unable to remember this previous statement he
made and uses it as a good pretext to shame the other party as being
inconsistent.

It makes more sense to perform static timing analysis...which is not

done with a VHDL simulator nor will it need a VHDL model.

Good luck with simulating "the timing analysis"

There is nothing inherently *worse* about an SDRAM interface timing

failure than any other sort of timing failure.

*Worse* is a from of 'untechical bad'. I never stated that. I simulate
the whole FPGA design without delays and synthesis will tell me if
timing problems exist. There is no problem.

Now, you communicate with external device. You check your basic
(calibration) design with functional model with no delay between them.
This will work at low speeds. Then, you increase speeds and calibrate
the fpga model so that it samples sdram responses at in the middle of
the data valid window. You end up with fpga design that can communicate
with ram at ultra high speed. But, functional simulation will fail.

When the board works in reality with this fpga design but memory model
connected to it responds differently in simulation, this does not mean
that there are races or design is "intechnical". It only means that the
board delays are so long that they must be taken into account and
adjusted to put simulation in correspondence with reality. You cannot do
functional simulation without introducing these delays.

 

[KJ]

 > It makes more sense to perform static timing analysis...which is not
done with a VHDL simulator nor will it need a VHDL model.

Good luck with simulating "the timing analysis"

Just in case you want to actually learn something rather than just
rambling on which I won't engage you in any longer...
- Research the term 'static timing analysis' which is what I said
needed to be performed.
- Then learn how to perform this type of analysis
- Then tell us how important a simulator was to you in performing that
analysis (Hint: the answer is 'none')

KJ

 

[valtih1978]

Thanks to you, I've learned a lot of interesting things:
1) long delays necessarily imply the clock race with data
2) 'bad' is untechnical word and simulating with board-long delays
implies untechnical design
3) simulating with delays becomes less important when you reach the
board level.
4) and timing analysis must be preferred instead.

Thanks.