FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-25-2006, 03:07 PM
oopere
Guest
 
Posts: n/a
Default Simulated Quartus II delays are much greater than measured

I working on a design that uses an altera APF10K10ATC144-3 device. I
have discovered some unusual long delays in a configuration where the
input clock (50ns period ) signal at a global clock pin:

a) directly feeds an output A
b) passes through an inverter and feeds and output B

According to the quartus II v4.2 sp1 simulator, the delay between the
rising flank of the clock at the input and the rising edge of the
output A is 15.3 ns (!) and, surprise, between rising clock and the
falling edge of output B is 14.9 ns, i.e. output B is even faster (!).
Since 15ns is an unusual delay I took the scope and measured,
approximately 5 ns in both cases, the delay being obviously slightly
less to output A than to output B.

The question is, why is the simulation wrong? (Yes, I have selected the
correct device in the assignments). I can understand that reality is
always worse than simulation but have almost never the opposite! In
any case, the simulator is almost useless in this case.

Any suggestion is appreciated

Pere

Reply With Quote
  #2 (permalink)  
Old 04-25-2006, 04:05 PM
Kolja Sulimma
Guest
 
Posts: n/a
Default Re: Simulated Quartus II delays are much greater than measured

oopere schrieb:

> The question is, why is the simulation wrong? (Yes, I have selected the
> correct device in the assignments). I can understand that reality is
> always worse than simulation but have almost never the opposite!


Wrong. Always the opposite.
The delay values given by the manufacturer (and used in simulation) are
guaranteed values under worst case conditions. For CMOS these usually are:
- worst case input rise time (yes, gate delays depend on input slope)
- The lowest allowed VCC
- A rather high output loading (e.g. 50pF for PCI compliant outputs)
- The highest allowed temperature
- slowest chip on a wafer
- slowest wafer produced over time

If you have flip flops in your design:
- worst case clock arrival time for on chip clock skew and jitter

additionally for SOI chips:
- worst case signal history (delay depends on the last couple of
transitions)

You are probably far away from worst case for most of these parameters,
so you will always be faster in reality than in a worst case simulation.

> In any case, the simulator is almost useless in this case.


On the contrary. For virtually all applications the slowest edge
behaviour is what you want to simulate.
For all other applications you need to do monte carlo simulation.

Kolja Sulimma
Reply With Quote
  #3 (permalink)  
Old 04-25-2006, 05:02 PM
oopere
Guest
 
Posts: n/a
Default Re: Simulated Quartus II delays are much greater than measured


Kolja Sulimma wrote:

> oopere schrieb:
>
> > The question is, why is the simulation wrong? (Yes, I have selected the
> > correct device in the assignments). I can understand that reality is
> > always worse than simulation but have almost never the opposite!

>
> Wrong. Always the opposite.
> The delay values given by the manufacturer (and used in simulation) are
> guaranteed values under worst case conditions. For CMOS these usually are:
> - worst case input rise time (yes, gate delays depend on input slope)
> - The lowest allowed VCC
> - A rather high output loading (e.g. 50pF for PCI compliant outputs)
> - The highest allowed temperature
> - slowest chip on a wafer
> - slowest wafer produced over time
>
> If you have flip flops in your design:
> - worst case clock arrival time for on chip clock skew and jitter
>
> additionally for SOI chips:
> - worst case signal history (delay depends on the last couple of
> transitions)
>
> You are probably far away from worst case for most of these parameters,
> so you will always be faster in reality than in a worst case simulation.
>
> > In any case, the simulator is almost useless in this case.

>
> On the contrary. For virtually all applications the slowest edge
> behaviour is what you want to simulate.
> For all other applications you need to do monte carlo simulation.
>
> Kolja Sulimma


Thank you. I understand your points. I did not take into account that I
am simulating the worst case scenario. However,

a) I still wonder if 15ns is a reasonable worst-case delay for a direct
input to output connection (or for an input->not gate->output
connection) for this kind of device. I have been trying to figure out
which combination of t_xyzk?#? from the datasheet I should be adding in
this case (have to say, without success)

b) It is surprising that the simulator tells that the direct connection
exhibits greater delay than the inverted one. Perhaps this depends on
which particular output pin is driven?

Any comments, anyone?

Pere

Reply With Quote
  #4 (permalink)  
Old 04-25-2006, 05:04 PM
oopere
Guest
 
Posts: n/a
Default Re: Simulated Quartus II delays are much greater than measured


> I working on a design that uses an altera APF10K10ATC144-3 device...

Sorry, this should be a Flex10K "EPF 10K10ATC144-3" device

Reply With Quote
  #5 (permalink)  
Old 04-26-2006, 03:46 AM
Jim Granville
Guest
 
Posts: n/a
Default Re: Simulated Quartus II delays are much greater than measured

oopere wrote:
> Kolja Sulimma wrote:
>
>
>>oopere schrieb:
>>
>>
>>>The question is, why is the simulation wrong? (Yes, I have selected the
>>>correct device in the assignments). I can understand that reality is
>>>always worse than simulation but have almost never the opposite!

>>
>>Wrong. Always the opposite.
>>The delay values given by the manufacturer (and used in simulation) are
>>guaranteed values under worst case conditions. For CMOS these usually are:
>>- worst case input rise time (yes, gate delays depend on input slope)
>>- The lowest allowed VCC
>>- A rather high output loading (e.g. 50pF for PCI compliant outputs)
>>- The highest allowed temperature
>>- slowest chip on a wafer
>>- slowest wafer produced over time
>>
>>If you have flip flops in your design:
>>- worst case clock arrival time for on chip clock skew and jitter
>>
>>additionally for SOI chips:
>>- worst case signal history (delay depends on the last couple of
>>transitions)
>>
>>You are probably far away from worst case for most of these parameters,
>>so you will always be faster in reality than in a worst case simulation.
>>
>>
>>>In any case, the simulator is almost useless in this case.

>>
>>On the contrary. For virtually all applications the slowest edge
>>behaviour is what you want to simulate.
>>For all other applications you need to do monte carlo simulation.
>>
>>Kolja Sulimma

>
>
> Thank you. I understand your points. I did not take into account that I
> am simulating the worst case scenario. However,
>
> a) I still wonder if 15ns is a reasonable worst-case delay for a direct
> input to output connection (or for an input->not gate->output
> connection) for this kind of device. I have been trying to figure out
> which combination of t_xyzk?#? from the datasheet I should be adding in
> this case (have to say, without success)
>
> b) It is surprising that the simulator tells that the direct connection
> exhibits greater delay than the inverted one. Perhaps this depends on
> which particular output pin is driven?


That sounds like a bug - if you have checked that's what the design
tools actually created.

ie What may have actually been created is a nett-non-inv path, and an
nett-inv-path, and if the latter can be made by _removing_ an inverter,
then the delays you report make sense. ( 400ps faster )

You can reality check your silicon, with a ring oscillator design.
That can indicate how Vcc and Temperature affect delays, for example.
Process variations are harder to get a handle on, but 3:1 ratios
you seem to have, would be at the conservative (pessimistic) end of the
range.

What can also result in that, is if vendors have faster speed grades
and the slow one is a 'yield safety net', plus they round-up to the
nearest 5ns, and they can also meet some competition point ( 15ns
was a common spec point, years ago ) - combine all that, and
you can get what looks like a very fat margin, especially on the
trail-end devices.

Sometimes vendors have to keep labeling (eg) -15 parts, because that's
what purchasing depts have 'locked in', and not because it has
much to do with what the FABs produce

-jg

Reply With Quote
  #6 (permalink)  
Old 04-26-2006, 03:24 PM
Kolja Sulimma
Guest
 
Posts: n/a
Default Re: Simulated Quartus II delays are much greater than measured

Jim Granville schrieb:

>> a) I still wonder if 15ns is a reasonable worst-case delay for a direct
>> input to output connection (or for an input->not gate->output
>> connection) for this kind of device. I have been trying to figure out
>> which combination of t_xyzk?#? from the datasheet I should be adding in
>> this case (have to say, without success)

For what load are these delays specified? (Datasheet)
What drive strength are you using? (Constraints File)
Do the math: Driving a 50pF standard PCI load with a 2mA driver from 0
to 1.6V will take 40ns without any internal delay.
Most FPGAs have programmable output drive strengths and logic families.
Try changing your output to LVDS or GTL and see what delays you get.

>> b) It is surprising that the simulator tells that the direct connection
>> exhibits greater delay than the inverted one. Perhaps this depends on
>> which particular output pin is driven?

>
>
> That sounds like a bug - if you have checked that's what the design
> tools actually created.

Not at all.
Because NMOS transistors are faster than PMOS transistors the fastest
overall speed for a CMOS device is achieved if the falling transition of
each gate is made faster than the rising transition.
http://www-md.e-technik.uni-rostock....icalEffort.pdf
(Page 2/11)
This probably is the case for your output buffers.
Try out what delays you get when simulating the opposite transition.

Also, for higher loads, circuits actual can get faster by adding gates
to the path.
http://bwrc.eecs.berkeley.edu/Classe...e7-invsize.PDF

Kolja Sulimma
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

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 On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Code not being simulated by Modelsim kb33 Verilog 4 05-03-2007 07:51 PM
always blocks and delays Strake Verilog 14 01-06-2007 08:44 PM
about relational greater operator jitendra Verilog 5 10-11-2005 09:31 PM
delays [email protected] FPGA 5 05-18-2005 11:11 AM
# delays gurvin Verilog 2 01-09-2004 09:55 PM


All times are GMT +1. The time now is 03:59 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved