Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > How do you introduce delays into 3-state (bi-dir) lines?

Reply
Thread Tools

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

 
 
valtih1978
Guest
Posts: n/a
 
      06-30-2011
This is needed for bus simulation
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      07-01-2011
On Jun 30, 12:36*pm, valtih1978 <(E-Mail Removed)> wrote:
> This is needed for bus simulation



Check out Ben Cohen's model at the link below

http://groups.google.com/group/comp....14832588a0cabb

Kevin Jennings
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      07-01-2011
On Jun 30, 12:36*pm, valtih1978 <(E-Mail Removed)> wrote:
> This is needed for bus simulation


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

http://groups.google.com/group/comp....14832588a0cabb

Kevin Jennings
 
Reply With Quote
 
valtih1978
Guest
Posts: n/a
 
      08-02-2011
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/-g.../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.
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-11-2011
On Aug 2, 7:38*am, valtih1978 <(E-Mail Removed)> wrote:
> 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/-g...oII/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
 
Reply With Quote
 
valtih1978
Guest
Posts: n/a
 
      08-14-2011
What is wrong with my "design"?
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-14-2011
On Aug 14, 3:57*am, valtih1978 <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
valtih1978
Guest
Posts: n/a
 
      08-15-2011
On 14.08.2011 19:32, KJ wrote:
> "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!
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-15-2011
On Aug 15, 1:05*pm, valtih1978 <(E-Mail Removed)> wrote:
> 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.

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


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
 
Reply With Quote
 
valtih1978
Guest
Posts: n/a
 
      08-16-2011

On 15.08.2011 22:40, KJ wrote:

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


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

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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
I am glad to introduce you a place which you can get free certification resources alexma Microsoft Certification 0 02-09-2010 08:46 AM
Delays-delays-delays Colin Palmer Computer Support 5 02-26-2008 04:41 AM
Very sorry for bother you all, I want to introduce my watch to you 123820711@163.com Computer Support 3 11-16-2005 03:23 AM
delays: inertial delays vs. transport delays Neil Zanella VHDL 2 10-20-2003 07:27 AM



Advertisments