Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 136750

Article: 136750
Subject: Re: Relationship between high and low speed clocks
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 3 Dec 2008 19:03:27 -0500
Links: << >>  << T >>  << A >>
Slight correction to the previous post.  Any change in the output of the 
toggle flop would indicate that the previous 100 MHz clock edge corresponded 
to a rising edge on the 25 MHz, not just a 0->1 transition on the flop.

KJ 



Article: 136751
Subject: Re: Relationship between high and low speed clocks
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 3 Dec 2008 19:12:02 -0500
Links: << >>  << T >>  << A >>
> One clean way is to look at a FF clocked by the 25 MHz clock
> rather than the raw 25 MHz clock.  You can either find an edge
> and just keep counting from there or make a FF that toggles
> on each 25 MHz clock and restart your state machine each toggle.
>

Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
to be a free running toggling flop.

KJ 



Article: 136752
Subject: Re: Relationship between high and low speed clocks
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 03 Dec 2008 16:17:07 -0800
Links: << >>  << T >>  << A >>
KJ wrote:
>> One clean way is to look at a FF clocked by the 25 MHz clock
>> rather than the raw 25 MHz clock.  You can either find an edge
>> and just keep counting from there or make a FF that toggles
>> on each 25 MHz clock and restart your state machine each toggle.
> 
> Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
> to be a free running toggling flop.
> 

I actually have one handy anyway (part of a counter in the 25 MHz domain.)

	-hpa

Article: 136753
Subject: Re: Relationship between high and low speed clocks
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 4 Dec 2008 00:59:09 -0000
Links: << >>  << T >>  << A >>

"H. Peter Anvin" <hpa@zytor.com> wrote in message 
news:gh6tkh$s08$1@terminus.zytor.com...
> Hello,
>
> I have a design which I am porting to a Cyclone II FPGA.  This design
> includes two clocks, one at 25 MHz and one at 100 MHz, currently
> generated from the Cyclone II PLL from a common clock (and thus
> synchronous.)  I have avoided it so far, but I'm running into a
> situation where the high-speed logic would like to understand where it
> is in relation to the low-speed clock cycle, in order to generate clock
> enables.
>
Hi H.,
Is it not possible to ditch the 25MHz clock and use only the 100MHz clock 
for all the synchronous elements? Just enable it once every four goes.
HTH HPA, Syms. 



Article: 136754
Subject: Query on Xilinx Nomenclature
From: Venkat <venkat.japan@gmail.com>
Date: Wed, 3 Dec 2008 21:17:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello all,

I was wondering what is signified by the number suffix that comes with
each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For
example xc5vfx130t, I know t stands for Rocket IO Capability.

Could anyone clarify me the number 130 suffixed to the name?

Thanks in advance for your patient response.

regards,
Venkat.

Article: 136755
Subject: Re: Relationship between high and low speed clocks
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 03 Dec 2008 23:44:21 -0600
Links: << >>  << T >>  << A >>

>> Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
>> to be a free running toggling flop.

>I actually have one handy anyway (part of a counter in the 25 MHz domain.)

FFs are generally plentiful in FPGAs.  The routing from where you 
have a FF over to where you need it may be more valuable than a FF.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 136756
Subject: Re: Relationship between high and low speed clocks
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Thu, 04 Dec 2008 00:38:53 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:
>>> Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
>>> to be a free running toggling flop.
> 
>> I actually have one handy anyway (part of a counter in the 25 MHz domain.)
> 
> FFs are generally plentiful in FPGAs.  The routing from where you 
> have a FF over to where you need it may be more valuable than a FF.
> 

Yes.  Fortunately the compiler takes care of that (it will split and
merge identical registers as routing warrants.)  I guess one can
override that, but that's hard to know without knowing where things end
up anyway.

	-hpa

Article: 136757
Subject: Re: Query on Xilinx Nomenclature
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 04 Dec 2008 08:38:57 +0000
Links: << >>  << T >>  << A >>
On Wed, 3 Dec 2008 21:17:34 -0800 (PST), Venkat wrote:

>Hello all,
>
>I was wondering what is signified by the number suffix that comes with
>each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For
>example xc5vfx130t, I know t stands for Rocket IO Capability.

Yes, that's right.  In fact it explains the name "Virtex":
'V' stands for the family name (Virtex);
'i' indicates that it has Integer multipliers on-chip;
'r' shows it's Reconfigurable (have you noticed that all
    Xilinx parts have an R in their name - spaRtan, viRtex,
    coolRunner?)
't' - as you say - indicates the RocketIO capability;
'e' shows that Extended temperature range is available;
'x' is a warning that the largest parts are quite eXpensive.

As far as the other stuff is concerned, I must admit that
I have the rather dull and old-fashioned habit of consulting
manufacturers' data sheets for that kind of information.  I 
am aware, though, that this is a very outmoded approach that
doesn't fit well in the modern Web2.0 world, which explains
why you young chaps are so much better at all this than we
old fellers.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 136758
Subject: Timing analysis of related clocks
From: "ALuPin@web.de" <ALuPin@web.de>
Date: Thu, 4 Dec 2008 00:48:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi newsgroup,

please consider the following scenario:

One design block "core_xy" is clocked with a clock coming from a FPGA
internal PLL.
That PLL shifts the incoming clock (from external).
A second design block "ctrl_core_xy" controls the first block and is
clocked directly
by the external clock.

My question:
Do FPGA timing analysis tools imply the PLL phase shift in their
timing calculation ?
If "timing is met" can I be sure that both clock domains have been
treated correctly ?
Or do I face asynchronous clock domains which have been blocked in
timing
calculation ?


Rgds,
ALuPin

Article: 136759
Subject: Xilinx-ISE nets names after placement & routing
From: Giorgos_P <giorgos.puiklis@gmail.com>
Date: Thu, 4 Dec 2008 01:25:09 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

Can Xilinx-ISE produce a report correlating the names of the signal of
the source code (VHDL) to the names of the nets after placement &
routing or viseversa? If not how can I perform a back-annotated
simulation without knowing the names of the signals I want to debug?

Thank you in advance

Giorgos P.

Article: 136760
Subject: Re: Hold Time Requirement
From: carl.horton08@gmail.com
Date: Thu, 4 Dec 2008 01:26:20 -0800 (PST)
Links: << >>  << T >>  << A >>
1. Thanks Eilert,

>In that case it might happen,
>that the first FF changes its output line before the hold time required
>for the second FF is over(tCO < tH). Changing a FFs input between start
>of setup time and end of hold time causes unpredictable results or even
>metastability.

To check my understanding, between the two statements above,
are you trying to say: ?

Since the output of the 1st FF feeds to the D input of 2nd FF,
inequality (tCO of 1st FF < tH of 2nd FF) means that the
signal value on D input changes before the end of hold time
for the 2nd FF.

>May be a rare case, but formally correct.
>Inside FPGAs, where all the FFs are the same, this should not be an
>issue at all.

Could you please elaborate on this?

2. Thanks Muzaffer,

>The more accurate equation is
>tCK1 + tCO >  tCK2 + tH ie the clock arrival time to the the source
>clock plus the clock to output delay should be greater than clock
>arrival time to the target flop plus the hold time.

Thanks for adding clock arrival into the picture (Eilert also
indicated
it) Could you please formally define the clock arrival time? From when
to when?

3. Thanks Hal,

>It's not that the FFs are the same, it's that the hardware designers
>decided to simplify things for the software guys by making all
>FFs appear to have 0 hold time.

>It's actually more complicated than that.  The hardware guys have to
>promise that min clock-out and min routing has to cover the
>max hold time and any clock skew using the normal clock distribution
>network.

You seem to suggest that FPGA hardware guarantees the hold time
requirement tH always *appear* to the FPGA application designer
to be 0? And, is this why the FPGA vendors never have to check the
hold time requirement?

4. Thanks Gabor,

>Actually tCO in the above equation needs to include the minimum
>routing delay as well as the clock to output time of the flop.  In
>an FPGA, the routing delays are often longer than the logic delays.

Thanks for adding routing delay and logic delay into the picture.
To check my understanding, the hold time requirement becomes:

tCK1 + tCO + tRouting + tLogic > tCK2 + tH

Is this correct and complete?

>Xilinx has an appnote on how their timing analyzer calculates
>setup and hold times.  For me it's a little like looking at
>accounting methods, because although the calculated answer is
>correct, the way they present the arithmetic is not the way
>you would normally think of the problem.

Are you talking about the white paper entitled "What Are PERIOD
Constraints? (WP257)" ? If yes, the presentation of this paper
really confused me, especially page 10 of it.

5. Thanks all again!
The difficulty with me to understand the hold time requirement
is that I am trying follow the same way to understand the setup
time requirement:

Setup Slack = (Tclock  - tCLK_Skew) - (tCO + tData) - tS

Which can be thought through by
1) tracing the data path from clock source's 1st clock edge through
the 1st DFF tCO, combinational logic data path delay, required setupt
time tS, to the D input of 2nd DFF: (tCO + tData + tS)
2) tracing the clock path from the clock source through clock path
delay (causing clock skew) to get clock arrival time at 2nd DFF for
the *next* active clock edge.

The Setup Slack is the difference between Clock Arrival and Data
Arrival:

Setup Slack = ClockArrival - DataArrival - tS
= (Tclock  - tCLK_Skew) - (tCO + tData) - tS    ---------- (1)

Now, to derive the Hold Slack, one has to look at the *same* clock
edge for both DFFs:

Hold Slack = DataArrival - ClockArrival - tH
= (tCO + tData) - tCLK_Skew - tH               ----------- (2)

The difference for ClockArrival in (1) and (2) is the thing that
bothers me. Could you please help me out on this?

Thanks all, gentlemen!

Carl


Article: 136761
Subject: Which terms include the setup time and hold time in Xilinx ISE timing
From: carl.horton08@gmail.com
Date: Thu, 4 Dec 2008 02:02:59 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello, All,

As I understand it, ISE Timing Analyzer does setup time analysis for
PERIOD, OFFSET IN and OFFSET OUT constraints as follows:

PERIOD
slack = (requirement - (data path - clock path skew + uncertainty))

OFFSET IN
slack = (requirement - (data path - clock path - clock arrival +
uncertainty))

OFFSET OUT
slack = (requirement - (clock arrival + clock path + data path +
uncertainty))

Q1: My impression is that "setup time" is included in the "data
path".
Is this correct? If yes, where is this documented?

Q2: Which term includes "hold time" in the analysis?
If yes, where is this documented? If no, why?

Thanks.

Carl Horton

Article: 136762
Subject: Re: Timing analysis of related clocks
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 4 Dec 2008 05:16:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 3:48=A0am, "ALu...@web.de" <ALu...@web.de> wrote:
> Hi newsgroup,
>
> please consider the following scenario:
>
> One design block "core_xy" is clocked with a clock coming from a FPGA
> internal PLL.
> That PLL shifts the incoming clock (from external).
> A second design block "ctrl_core_xy" controls the first block and is
> clocked directly
> by the external clock.
>
> My question:
> Do FPGA timing analysis tools imply the PLL phase shift in their
> timing calculation ?

That is a tool dependent question, some do and some do not.

> If "timing is met" can I be sure that both clock domains have been
> treated correctly ?

Only if you know for certain that they are correctly handling any
phase shift between the two domains and that the tool is actually
performing the analysis between signals that cross domains.

> Or do I face asynchronous clock domains which have been blocked in
> timing
> calculation ?
>
Since the clock domains are related, treating them like asynchronous
domains might be worse depending on what the PLL is doing in the
frequency domain.  As an example, if the PLL does a 2:1 multiply but
not totally in phase then the input clock and the PLL output clock
will be clashing 100% of the time and any timing problems will quickly
show up.  Timing problems with a PLL multiplier of 7:3 would take
longer to show up.

The short answer though is simply to correctly perform the timing
analysis in the first place which is what it sound like you're trying
to do by questioning whether phase shifts get correctly handled by the
timing analysis tool.  Create a simple test design that simply clocks
something in with the input clock and then transfers it over to the
PLL out clock domain and bring that signal to an output pin and run
that design through the tools.  Vary the PLL phase and run it through
again.  You might also want to bring the PLL output to an output pin
as well since many times other external devices base their timing on
such a signal (like a DDR controller inside an FPGA that talks to an
external DDR).  That should give you the background needed to insure
that you're using the tools in a way that is properly analyzing the
clock domain transfers.

Kevin Jennings

Article: 136763
Subject: Re: Timing analysis of related clocks
From: Gabor <gabor@alacron.com>
Date: Thu, 4 Dec 2008 06:13:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 3:48=A0am, "ALu...@web.de" <ALu...@web.de> wrote:
> Hi newsgroup,
>
> please consider the following scenario:
>
> One design block "core_xy" is clocked with a clock coming from a FPGA
> internal PLL.
> That PLL shifts the incoming clock (from external).
> A second design block "ctrl_core_xy" controls the first block and is
> clocked directly
> by the external clock.
>
> My question:
> Do FPGA timing analysis tools imply the PLL phase shift in their
> timing calculation ?
> If "timing is met" can I be sure that both clock domains have been
> treated correctly ?
> Or do I face asynchronous clock domains which have been blocked in
> timing
> calculation ?
>
> Rgds,
> ALuPin

You don't mention which tools you are using.  I have found for
example that the Lattice tools (from NeoCad) try to analyze the
timing on related clocks, but don't always do it right.  For
example I had a PLL generating both 0 shift and 270 degree
shifted clock.  Calculating the setup to the shifted clock
on a signal generated on the non-shifted clock you would expect
that the path needs to meet 3/4 cycle time from clock to clock.
In fact the tools treated this as 1 and 3/4 cycles available
for the signal path from clock to clock!

I would suggest looking at a timing report to see if you
can find coverage for cross clock-domain paths.  If you
use Xilinx tools you can also get a report of uncovered paths
to see if your cross clock-domain paths fall into this
category.

Cheers,
Gabor

Article: 136764
Subject: Re: Timing analysis of related clocks
From: "ALuPin@web.de" <ALuPin@web.de>
Date: Thu, 4 Dec 2008 06:53:18 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

thank you for your answers.

I am using ispLEVER 7.1 from Lattice. Maybe having a look at the
coverage reports
will shed some light on it.

Rgds
ALuPin




Article: 136765
Subject: Re: Xilinx-ISE nets names after placement & routing
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 04 Dec 2008 06:55:32 -0800
Links: << >>  << T >>  << A >>
Giorgos_P wrote:

> Can Xilinx-ISE produce a report correlating the names of the signal of
> the source code (VHDL) to the names of the nets after placement &
> routing or viseversa? If not how can I perform a back-annotated
> simulation without knowing the names of the signals I want to debug?

I do my debugging with source code.
A back-annotated gate sim is a double check
on synthesis and static timing, not functionality.

       -- Mike Treseler

Article: 136766
Subject: Preventing PAR from routing signals in closed area groups
From: Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com>
Date: Thu, 4 Dec 2008 07:05:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello group,

I'm trying to implement a simple design that uses partial
reconfiguration, and for testings I'm beginning with a modular
implementation that still has the bus macros.

I use an AREA GROUP constraint to pack all the reconfigurable logic
into a rectangular region of the FPGA. This works for logic (the
constraint successfully moved the static design slices out of the
reconfigurable area), but apparently not with signals, as PAR routed a
static wire in the middle of my reconfigurable area (troublesome
signal is in red) :
http://lekernel.net/routing_problem.png

The design is very simple, it is just supposed to blink two LEDs
(blinking enabled with DIP switches) with one controlled by the static
design and the other with a reconfigurable area. I am using the ML401
board which has a Virtex 4.

Top-level Verilog code is:

module top(input clk, input en1, output led1, input en2, output led2);
blink_static static(.clk(clk), .en(en1), .blink(led1));
wire led2_prr, en2_prr;
busmacro_xc4v_l2r_async_narrow busmacro_fromprr(.input0
(led2_prr), .output0(led2));
busmacro_xc4v_r2l_async_narrow busmacro_toprr(.input0(en2), .output0
(en2_prr));
blink_prm prr(.clk(clk), .en(en2_prr), .blink(led2_prr));
endmodule

The signal that causes the problem is named en2_IBUF in FPGA Editor. I
am using the following area constraints in the UCF file :

INST "busmacro_fromprr" LOC=SLICE_X20Y122;
INST "busmacro_toprr" LOC=SLICE_X20Y124;
AREA_GROUP "AG_pr" RANGE = SLICE_X16Y98:SLICE_X21Y131;
AREA_GROUP "AG_pr" GROUP = CLOSED;
AREA_GROUP "AG_pr" PLACE = CLOSED; # tried with and without this one,
no change
INST "prr" AREA_GROUP="AG_pr";

How to prevent static signals from crossing my reconfigurable area ?
Perhaps I should not connect I/O signals directly to busmacros (but
why ?) ? Or did I misunderstand something and this signal is not going
to be a problem ?

Thanks.

Sebastien

Article: 136767
Subject: Re: Query on Xilinx Nomenclature
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Thu, 4 Dec 2008 08:09:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 3, 9:17=A0pm, Venkat <venkat.ja...@gmail.com> wrote:
> Hello all,
>
> I was wondering what is signified by the number suffix that comes with
> each of Xilinx FPGAs along with their Family Names (v2p,v4,v5). For
> example xc5vfx130t, I know t stands for Rocket IO Capability.
>
> Could anyone clarify me the number 130 suffixed to the name?
>

AFAIK, each family has its own rules.  The nomenclature for Virtex-5
is spread throughout the following document.
http://www.xilinx.com/support/documentation/data_sheets/ds100.pdf

In specific, check out Table 1 on page 2.

Example:  XC5VSX35T

All device codes have the followign formats.

                 XC5V ff iii T

"XC5V" =3D Virtex-5 FPGA family

ff =3D device sub type

LX =3D Logic-only, general-purpose family.

SX =3D Signal processing heavy,  more DSP48 DSP blocks at the expense of
general-purpose logic.

FX =3D Full-featured family including PowerPC processing blocks along
with all the other bells and whistles.

TX =3D Devices with enhanced GTX transcievers capable of 6.5 Gbps.

iii =3D Logic capacity

The integer number is a gross approximation at the number of "logic
cells" (which is an entirely different discussion).  The larger the
number, the more logic capacity the device has.


T =3D Transceivers (optional suffix)

High-speed serial I/O. All SX, FX, and TX devices have transcievers.
The LX versions include devices with or without transceivers.  Also,
the TX devices have a different, higher-performance tranceiver than
the others.

Steve Knapp
Prevailing Technology, Inc.
www.prevailing-technology.com

Article: 136768
Subject: Project/File corruption problem with ISE 10.1
From: Dale <dale.prather@gmail.com>
Date: Thu, 4 Dec 2008 09:45:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,
I'm experiencing some aggravation with ISE 10.1.  I'm trying to add an
existing vhd file to my project.  When I try to add it ISE freezes and
I have to go to the task manager to shut it down.  If I try to
recreate the project, using the same folder and same project name as
soon as I try to add a file to the project it does the same thing.

If I recreate the project using a project name other than the original
name, it works fine.  I have no idea what's going on.  If you have any
ideas, please share.

Thanks,
Dale

Article: 136769
Subject: Re: Relationship between high and low speed clocks
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 04 Dec 2008 11:52:10 -0600
Links: << >>  << T >>  << A >>

>>> I actually have one handy anyway (part of a counter in the 25 MHz domain.)
>> 
>> FFs are generally plentiful in FPGAs.  The routing from where you 
>> have a FF over to where you need it may be more valuable than a FF.

>Yes.  Fortunately the compiler takes care of that (it will split and
>merge identical registers as routing warrants.)  I guess one can
>override that, but that's hard to know without knowing where things end
>up anyway.

If the counter is on the opposite side of the chip from the place
where you want your 25/100 logic, you have to route the signal
across the chip.

What I was trying to suggest is changing the source text to create
a new FF in order to avoid that routing.

It all depends...

I'd probably start with the extra FF just to keep the source code clean.
Why add an obscure dependency if you don't need it.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 136770
Subject: Re: Hold Time Requirement
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 04 Dec 2008 11:57:28 -0600
Links: << >>  << T >>  << A >>

>You seem to suggest that FPGA hardware guarantees the hold time
>requirement tH always *appear* to the FPGA application designer
>to be 0? And, is this why the FPGA vendors never have to check the
>hold time requirement?

Yes.  That's my understanding, but I don't work for the vendors
so I'm reading between the lines.  It seems pretty obvious.



>tCK1 + tCO + tRouting + tLogic > tCK2 + tH

>Is this correct and complete?

It's not quite complete.  You need a bunch of min/max-es in there.

For setup times, you want the max time of everything.  For hold
times, you want the min times on getting the signal to the target
FF and the max hold time it needs after you get there.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 136771
Subject: Re: Relationship between high and low speed clocks
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Thu, 04 Dec 2008 11:15:58 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> If the counter is on the opposite side of the chip from the place
> where you want your 25/100 logic, you have to route the signal
> across the chip.
> 
> What I was trying to suggest is changing the source text to create
> a new FF in order to avoid that routing.
> 
> It all depends...
> 
> I'd probably start with the extra FF just to keep the source code clean.
> Why add an obscure dependency if you don't need it.
> 

My point was mostly that the compiler will treat two FFs with identical
clocks and identical inputs as a single FF, and then will split that
single FF if warranted.

This is actually the right thing for the compiler to do, as it has
information the programmer generally does not in this instance.  I'll
just do in my source what ends up looking cleanest.

	-hpa

Article: 136772
Subject: Re: Project/File corruption problem with ISE 10.1
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 4 Dec 2008 11:30:36 -0800
Links: << >>  << T >>  << A >>
> When I try to add it ISE freezes and
> I have to go to the task manager to shut it down.

Must be something in the VHDL file.
Perhaps there is something that conflicts
with the heirarchy? Like a module with the
same name as your top module.

Brad Smallridge
Ai Vision



Article: 136773
Subject: Re: Project/File corruption problem with ISE 10.1
From: Gabor <gabor@alacron.com>
Date: Thu, 4 Dec 2008 11:55:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 2:30=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> > When I try to add it ISE freezes and
> > I have to go to the task manager to shut it down.
>
> Must be something in the VHDL file.
> Perhaps there is something that conflicts
> with the heirarchy? Like a module with the
> same name as your top module.
>
> Brad Smallridge
> Ai Vision

I've found that ISE 10.1 tries to be very smart about detecting the
hierarchy, and runs into trouble when there are errors in a source
file, sometimes ripping out entire sections of the design and asking
for a new top level module assignment when certain errors confuse it.

There are also conflicts with other programs including some virus
scanners and backup software like Carbonite that cause confusion
with ISE's underlying database software.

If ISE hasn't completely trashed the old project, you could try
"cleanup project files" before adding the new source.  It seems
that ISE is not good at cleaning up after itself.  This often
appears in things like .ucf file entries that don't go away
when you delete them from the file.  Sometimes you have to find
the temp folders under your main project directory with a name
containing the project name and delete everything in them.

When all else fails, file a web case.  I know it's a headache
but otherwise how is Xilinx to know just how buggy their software
is?

Regards,
Gabor

Article: 136774
Subject: Re: Xilinx-ISE nets names after placement & routing
From: Giorgos_P <giorgos.puiklis@gmail.com>
Date: Thu, 4 Dec 2008 12:08:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 =C4=E5=EA, 16:55, Mike Treseler <mtrese...@gmail.com> wrote:
> Giorgos_P wrote:
> > Can Xilinx-ISE produce a report correlating the names of the signal of
> > the source code (VHDL) to the names of the nets after placement &
> > routing or viseversa? If not how can I perform a back-annotated
> > simulation without knowing the names of the signals I want to debug?
>
> I do my debugging with source code.
> A back-annotated gate sim is a double check
> on synthesis and static timing, not functionality.
>
> =A0 =A0 =A0 =A0-- Mike Treseler

I agree, but if this double check fails, you need to go and see where
it failed. You can't do this without knowing what the names of the
nets correspond to (to the initial source code).

Any ideas?



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search