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 112000

Article: 112000
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 14 Nov 2006 18:46:53 GMT
Links: << >>  << T >>  << A >>
Are you transferring data between related time domains either with or 
without a DCM?
Your FPGA and software version could have a slight impact on results.


"Thomas Reinemann" <tom.reinemann@gmx.net> wrote in message 
news:1163529222.557776.216940@k70g2000cwa.googlegroups.com...
Hi,

we are running in trouble with our curent design for a Xilinx Spartan 3
xc3s1500.

It does signal processing and it seems that sample got lost with
increasing temperature. Immediately after power on all works well, some
minutes later, if final temperatures is reach, some samples are missed.
I hadn't a thermometer ready, but I can always touch the FPGA for a
long time, it may be 50°C.
It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
78.777MHz, and logic utilization is about 60%.

One board works as expected and two other show the explained effect,
the boards have the same layout but are made by different
manufacturers. At least the not working are lead free.

Just now, we had a discusion to the influence of temperature to
propagation delay. I don't believe that it influences clock lines and
other logic resources in a (big) different way. Is It true or not?

I read the thread "Propagation delay sensitivity to temperature,
voltage, and manufacturing", but the answers are very related to DCMs.

Tom



Article: 112001
Subject: Re: Compile error by Cadence NC-Sim
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 14 Nov 2006 10:57:25 -0800
Links: << >>  << T >>  << A >>
uvbaz wrote:

> My question are:
> 1. I want to compile "fprint.vhd + fprint_body.vhd" in FPRINT, but it
> didn't. Why?

Until you learn modelsim,
compile everything into the default library "work".

> 2. "$XILINX/verilog/src/simprims/*.v" not recognized, why?

Maybe it is a verilog file and the
script is running vcom.


           -- Mike Treseler

Article: 112002
Subject: Aurora IP core vs. RocketIO wizard
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 14 Nov 2006 13:58:12 -0500
Links: << >>  << T >>  << A >>
Xilinx has lost my account somehow so that I am unable to log on their web
support page... so I thought I'd try it here...

Which of the two should I use if I want to generate simple separate
streaming tx only and rx only cores for V4FX? The RocketIO wizard allows for
choosing silicon step level, while the Aurora core GUI seems to give more
control over some other parameters... I've heard that the calibration block
should be different for different stepping levels. If that's the case how
can it be achieved with the Aurora core?

Thanks,
/Mikhail



Article: 112003
Subject: Re: Xilinx platform cable USB
From: "Alan Nishioka" <alan@nishioka.com>
Date: 14 Nov 2006 11:05:30 -0800
Links: << >>  << T >>  << A >>
Manny wrote:
> It might be a naive question, however, I just want to make sure. Is
> Xilinx new USB JTAG backward-compatible with old parallel port JTAG
> development boards? I'm a bit suspicious as some of the newer Xilinx
> boards say explicitly that the board is compatible with the USB JTAG.

Perhaps you are referring to the Spartan 3E starter kit?

In this case, in addition to the 6 pin JTAG header, it has a USB
connector (and USB chip) on board so you can program it without having
to buy *any* programming cable at all.

Alan Nishioka


Article: 112004
Subject: Re: Why are there ModelSimAltera warning
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 14 Nov 2006 11:09:49 -0800
Links: << >>  << T >>  << A >>
fl wrote:

> I find there are a lot of warning (see below) in the
> first 25 ns. Is it normal? 

They are common at time zero, but they can be eliminated.
Google is your friend.

> I rewrote the program in Xilinx previously
> using my own add subroutine. Although the sum was uncertain (in red) in
> the first 100 ns, there is no such warning. Are there something I can
> do in the ModelSimAltera to suppress these warning?

Add one or more of these the to
your .do script.

set NoVitalCheck 1;
set IgnoreVitalErrors 1;
set StdArithNoWarnings 1;
set NumericStdNoWarnings 1;



          -- Mike Treseler

Article: 112005
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: "John Adair" <g1@enterpoint.co.uk>
Date: 14 Nov 2006 13:15:24 -0800
Links: << >>  << T >>  << A >>
Thomas

Try a rebuild with a tighter frequency. The tools will tend to just
give you what you ask for, not anything much better. There are also
some versions of ISE (i.e. the speed tables) that seem to be a bit
marginal with designs if you are close to the limit like you are. On a
similar vein check you have the latest version and service pack of ISE.

Other things to watch when the unexpected happens are the power
supplies and whether your clock source is stable. Ensure they don't dip
or suffer significant noise (decoupling and power plane strategy)
particularly if you are using a DCM. If using a DCM do have a good look
at the Vccaux.

John Adair
Enterpoint Ltd. - Home of Darnaw1. Spartan-3E in PGA Format.

Thomas Reinemann wrote:
> Hi,
>
> we are running in trouble with our curent design for a Xilinx Spartan 3
> xc3s1500.
>
> It does signal processing and it seems that sample got lost with
> increasing temperature. Immediately after power on all works well, some
> minutes later, if final temperatures is reach, some samples are missed.
> I hadn't a thermometer ready, but I can always touch the FPGA for a
> long time, it may be 50=B0C.
> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
> 78.777MHz, and logic utilization is about 60%.
>
> One board works as expected and two other show the explained effect,
> the boards have the same layout but are made by different
> manufacturers. At least the not working are lead free.
>
> Just now, we had a discusion to the influence of temperature to
> propagation delay. I don't believe that it influences clock lines and
> other logic resources in a (big) different way. Is It true or not?
>
> I read the thread "Propagation delay sensitivity to temperature,
> voltage, and manufacturing", but the answers are very related to DCMs.
>=20
> Tom


Article: 112006
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 14 Nov 2006 14:22:50 -0800
Links: << >>  << T >>  << A >>
Thomas,

Comments below,

Austin

-snip-

> I hadn't a thermometer ready, but I can always touch the FPGA for a
> long time, it may be 50°C.

How much slack does your timing report say it has?

> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
> 78.777MHz, and logic utilization is about 60%.

I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz).  That
is pretty darned small.  If you have 400 ps of jitter on your clock, you
now have 327 - 1/2 (400) = 127 ps of slack ...

If you have 800 ps of jitter, then you are failing (slack less than 0).

If you have any paths that were not constrained properly, then 327 ps of
slack is a fiction, you really may have paths that are failing to meet
timing.

> One board works as expected and two other show the explained effect,
> the boards have the same layout but are made by different
> manufacturers. At least the not working are lead free.

Parts will vary:  some will be faster than specified.  none will be
slower than specified.

> Just now, we had a discusion to the influence of temperature to
> propagation delay. I don't believe that it influences clock lines and
> other logic resources in a (big) different way. Is It true or not?

Temperature affects all delays.  The resource affected may be different,
and may be affected more, or less, but they will all slow down at hotter
temperatures.

> I read the thread "Propagation delay sensitivity to temperature,
> voltage, and manufacturing", but the answers are very related to DCMs.

DCM's vary, too.  So does everything else.
Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a
rule of thumb, not anything we characterize or guarantee.

You are just too close to the edge:  go back and review your constraints
(to see if they cover all the critical paths), and perhaps apply a
smaller clock period as a timing specification.

Article: 112007
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 14 Nov 2006 22:43:42 GMT
Links: << >>  << T >>  << A >>
Inline:

Austin Lesea wrote:
> Thomas,
> 
> Comments below,
> 
> Austin
> 
> -snip-
> 
>> I hadn't a thermometer ready, but I can always touch the FPGA for a
>> long time, it may be 50°C.
> 
> How much slack does your timing report say it has?
> 
>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
>> 78.777MHz, and logic utilization is about 60%.
> 
> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz).  That
> is pretty darned small.  If you have 400 ps of jitter on your clock, you
> now have 327 - 1/2 (400) = 127 ps of slack ...
> 
> If you have 800 ps of jitter, then you are failing (slack less than 0).
> 
> If you have any paths that were not constrained properly, then 327 ps of
> slack is a fiction, you really may have paths that are failing to meet
> timing.

Now come, Austin. If the tool tells me I have positive margin (however 
small) I expect that to be true. I've done designs where I calculated 
the worst case and had a _guaranteed_ margin of 8 ps. Note the word 
guaranteed. I thought the post-PAR analysis tools gave me guaranteed 
timings.


> 
>> One board works as expected and two other show the explained effect,
>> the boards have the same layout but are made by different
>> manufacturers. At least the not working are lead free.
> 
> Parts will vary:  some will be faster than specified.  none will be
> slower than specified.

Lead free processes stress a part more than the non-lead free; there is 
also the issue that the joints may not have the same highspeed 
performance; your application is highspeed enough to be susceptible to 
soldering issues. However, I agree with Austin that your margin is sorta 
small.


> 
>> Just now, we had a discusion to the influence of temperature to
>> propagation delay. I don't believe that it influences clock lines and
>> other logic resources in a (big) different way. Is It true or not?
> 
> Temperature affects all delays.  The resource affected may be different,
> and may be affected more, or less, but they will all slow down at hotter
> temperatures.
> 
>> I read the thread "Propagation delay sensitivity to temperature,
>> voltage, and manufacturing", but the answers are very related to DCMs.
> 
> DCM's vary, too.  So does everything else.
> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a
> rule of thumb, not anything we characterize or guarantee.
> 
> You are just too close to the edge:  go back and review your constraints
> (to see if they cover all the critical paths), and perhaps apply a
> smaller clock period as a timing specification.

I would also check to see if you are adding the signal rise/fall (which 
can get quite high for non-rocket IO pins) as temperatures increase.

Cheers

PeteS

Article: 112008
Subject: Pipelining can reduce the slice usage
From: "Patrick Dubois" <prdubois@gmail.com>
Date: 14 Nov 2006 15:00:58 -0800
Links: << >>  << T >>  << A >>
Hello all,

I realized something interesting today, adding registers in your design
can actually reduce the slice usage (in Virtex-II Pro). For example, I
started a design with minimal pilelining to keep it simple at first.

Before pipelining, I had the following usage:
Slices: 2433
Flip Flops: 2287
LUT: 2981 (seems a bit high, might be a typo in my notebook)

After pipelining, I get:
Slices: 1973
Flip Flops: 2615
LUT: 2069

I knew from the begining that pipelining would be needed but I didn't
realize that it could save me some slices (on top of the obvious max
frequency increase).

I might as well throw in a question while I'm at it. Now I need to
pipeline further (need to go from 78 MHz to 100 MHz) but it gets more
complicated, I would need to pipeline the function "to_signed (from
float32)" from the VHDL-200X float_pkg.
Any suggestions on how to do that? I read somewhere that one can add an
extra level of registers, and let the tool figure out how to do the
register retiming. I would use xst with the "register_balancing yes"
flag, but I'm not sure how good xst is at register balancing.


Thanks.

Patrick Dubois


Article: 112009
Subject: In defence of Austin and Xilinx
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 14 Nov 2006 23:03:39 GMT
Links: << >>  << T >>  << A >>
At bottom:

PeteS wrote:
> Inline:
> 
> Austin Lesea wrote:
>> Thomas,
>>
>> Comments below,
>>
>> Austin
>>
>> -snip-
>>
>>> I hadn't a thermometer ready, but I can always touch the FPGA for a
>>> long time, it may be 50°C.
>>
>> How much slack does your timing report say it has?
>>
>>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
>>> 78.777MHz, and logic utilization is about 60%.
>>
>> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz).  That
>> is pretty darned small.  If you have 400 ps of jitter on your clock, you
>> now have 327 - 1/2 (400) = 127 ps of slack ...
>>
>> If you have 800 ps of jitter, then you are failing (slack less than 0).
>>
>> If you have any paths that were not constrained properly, then 327 ps of
>> slack is a fiction, you really may have paths that are failing to meet
>> timing.
> 
> Now come, Austin. If the tool tells me I have positive margin (however 
> small) I expect that to be true. I've done designs where I calculated 
> the worst case and had a _guaranteed_ margin of 8 ps. Note the word 
> guaranteed. I thought the post-PAR analysis tools gave me guaranteed 
> timings.
> 
> 
>>
>>> One board works as expected and two other show the explained effect,
>>> the boards have the same layout but are made by different
>>> manufacturers. At least the not working are lead free.
>>
>> Parts will vary:  some will be faster than specified.  none will be
>> slower than specified.
> 
> Lead free processes stress a part more than the non-lead free; there is 
> also the issue that the joints may not have the same highspeed 
> performance; your application is highspeed enough to be susceptible to 
> soldering issues. However, I agree with Austin that your margin is sorta 
> small.
> 
> 
>>
>>> Just now, we had a discusion to the influence of temperature to
>>> propagation delay. I don't believe that it influences clock lines and
>>> other logic resources in a (big) different way. Is It true or not?
>>
>> Temperature affects all delays.  The resource affected may be different,
>> and may be affected more, or less, but they will all slow down at hotter
>> temperatures.
>>
>>> I read the thread "Propagation delay sensitivity to temperature,
>>> voltage, and manufacturing", but the answers are very related to DCMs.
>>
>> DCM's vary, too.  So does everything else.
>> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a
>> rule of thumb, not anything we characterize or guarantee.
>>
>> You are just too close to the edge:  go back and review your constraints
>> (to see if they cover all the critical paths), and perhaps apply a
>> smaller clock period as a timing specification.
> 
> I would also check to see if you are adding the signal rise/fall (which 
> can get quite high for non-rocket IO pins) as temperatures increase.
> 
> Cheers
> 
> PeteS

You are obviously clocking things from somewhere. A margin of 300 ps or 
so can get lost in the rise/fall times of a hot clock source. Have you 
characterised your clock inputs properly for post-PAR analysis?

Cheers

PeteS

Article: 112010
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 14 Nov 2006 15:15:59 -0800
Links: << >>  << T >>  << A >>
PeteS,

See below,

Austin

-snip-

 > Now come, Austin. If the tool tells me I have positive margin (however
> small) I expect that to be true. I've done designs where I calculated
> the worst case and had a _guaranteed_ margin of 8 ps. Note the word
> guaranteed. I thought the post-PAR analysis tools gave me guaranteed
> timings.

Sure.  For whatever you constrained.  Did everything get constrained
properly?  This is not a trivial task:  verifying timing closure may
sometimes take up huge amounts of time (to verify every critical path
has sufficient slack, and was properly constrained).  And 8ps of margin
means that if you have 16 ps P-P of jitter, you have no slack left, and
errors may occur if the jitter increases by even one ps...

But if you have a clock with 400 ps P-P of jitter (not uncommon), and
you have lots of IOs switching, and you have power supply variations,
and so on, you might be at the edge, or over the edge. (Probably
are...as was obvious in this case)

> I agree with Austin that your margin is sorta
> small.

Yes, it is.  I recommend having at least the peak to peak worst case
measured jitter as margin (slack).  That means you have a factor of two
for safety.  Considering peak to peak jitter is unbounded (14 sigma
enough?  16 sigma?  20 sigma?), you really do not want to cut things too
close (or you will eventually fail in some
process/voltage/temperature/jitter 'corner'.


> I would also check to see if you are adding the signal rise/fall (which
> can get quite high for non-rocket IO pins) as temperatures increase.

True, if the rise time is long, then you probably also have a lot of
jitter (as a long slow rise time leads to imprecise transitions).

Article: 112011
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 14 Nov 2006 23:23:11 GMT
Links: << >>  << T >>  << A >>
  Inline

Austin Lesea wrote:
 > PeteS,
 >
 > See below,
 >
 > Austin
 >
 > -snip-
 >
 >  > Now come, Austin. If the tool tells me I have positive margin (however
 >
 >> small) I expect that to be true. I've done designs where I calculated
 >> the worst case and had a _guaranteed_ margin of 8 ps. Note the word
 >> guaranteed. I thought the post-PAR analysis tools gave me guaranteed
 >> timings.
 >>
 > Sure.  For whatever you constrained.  Did everything get constrained
 > properly?  This is not a trivial task:

No it isn't. I have spent days on end making sure I have considered 
everything involved.

 > verifying timing closure may
 > sometimes take up huge amounts of time (to verify every critical path
 > has sufficient slack, and was properly constrained).  And 8ps of margin
 > means that if you have 16 ps P-P of jitter, you have no slack left, and
 > errors may occur if the jitter increases by even one ps...
 >
 > But if you have a clock with 400 ps P-P of jitter (not uncommon), and
 > you have lots of IOs switching, and you have power supply variations,
 > and so on, you might be at the edge, or over the edge. (Probably
 > are...as was obvious in this case)
 >
 >

I am anal about my constraints. I've done really high speed stuff 
(10Gb/s) but even the marginal things (DDR above 200/400 comes to mind) 
will bite you if you haven't properly constrained the design. The last 
time I did that I even added the delays (and filter effect) of the bond 
wires from the pad to the die. Perhaps the OP is not so anal about it 
but needs to be. My design worked first time for that, for what it's worth.



 >> I agree with Austin that your margin is sorta
 >> small.
 >>
 > Yes, it is.  I recommend having at least the peak to peak worst case
 > measured jitter as margin (slack).  That means you have a factor of two
 > for safety.  Considering peak to peak jitter is unbounded (14 sigma
 > enough?  16 sigma?  20 sigma?), you really do not want to cut things too
 > close (or you will eventually fail in some
 > process/voltage/temperature/jitter 'corner'.
 >
 >
 >

Deterministic jitter will kill a design, but it's predictable (see my 
comments about being anal). PCB tracks can add enough jitter to swamp 
300ps of margin, especially if there are vias involved. There are 
techniques to alleviate this, of course (maybe I should publish how I 
did it ;)
One can not, however, eliminate it.


 >> I would also check to see if you are adding the signal rise/fall (which
 >> can get quite high for non-rocket IO pins) as temperatures increase.
 >>
 > True, if the rise time is long, then you probably also have a lot of
 > jitter (as a long slow rise time leads to imprecise transitions).
 >
 >
 >
 >

That's my point. A FF will clock at some point in the active region. The 
indeterminacy of this region *must* be added to the error budget if you 
want guaranteed timing.

Cheers

PeteS



Article: 112012
Subject: Re: MPMC2: MPMC2 with DDR2 SDRAM
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Tue, 14 Nov 2006 15:35:57 -0800
Links: << >>  << T >>  << A >>
> I belive that MPMC2 DDR2 works on "Xilinx provided boards" but the
> question is how to make it to work on an "non Xilinx board?"
> 
> I have several custom V4 boards with DDR2 and I have ML501, I assumed
> that as MPMC2 generates UCF file that matches ML501 so first step would
> be to get MPMC2 to work on ML501 and then derive a new design for the
> custom board. I dont have ML410 or any other "xilinx supported board"
> for testing.
> 
> can you tell me why MPMC2 1.7 does not support V5? is it because
> 1) it is not tested (but may work) ?
> 2) IP core just want work for V-5 architecture
> 3) IP core is ok for V-5 but want work on ML501 because of clock buffer
> errata in ES silicon as described in EN049.PDF ?
> 
> Are there any plans to make MPMC2 to support Virtex-5? If yes when can
> we expect this?
> 
> Getting MPMC2 to work on our custom V4 DDR2 boards is really urgent, so
> any help is welcome.
> 
> For now I will drop any MPMC2 testing on ML501 and try to modify some
> MPMC2 archived project for our purpose, so far I did regenerate new
> project (and that failed to workI)
> 

Hi Antti -

Unfortunately I do not have good answers for any of the above questions. 
I do know that the next release of MPMC2 will support V5. I do not know 
the schedules.

/Siva

Article: 112013
Subject: Re: Why 64-bit PLB?
From: "Anonymous" <someone@microsoft.com>
Date: Tue, 14 Nov 2006 23:55:34 GMT
Links: << >>  << T >>  << A >>

"Jeff Cunningham" <jcc@sover.net> wrote in message
news:455927fd$0$5782$4d3efbfe@news.sover.net...
> Antti wrote:
>
> >
> > PPC405 hard macro PLB DBUS *IS* 64 bits
> >
>
> But according to the documentation, the native hard PLB interfaces on
> the PPC core can be configured to operate in 32 bit mode, and they will
> adapt themselves to just use 32 bits (i.e. you don't need any external
> 64 to 32 bit mux). For instance, see the PLBC405DCUSSIZE1 parameter in
> the Power PC 405 Processor Block Reference Guide.
>
> -Jeff

At the EDK level it looks to be hardcoded to 64? Do you know how I would
specify 32 and/or confirm that it is 32?

Thanks,
Clark



Article: 112014
Subject: Re: In defence of Austin and Xilinx
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 14 Nov 2006 23:58:29 GMT
Links: << >>  << T >>  << A >>
Thanks for throwing this back in after your "Now come, Austin" comment.  The 
tools will report what the chip will *absolutely* support under worst case 
conditions as long as none of the input conditions for that specification 
are exceeded.  Maximum acceptable jitter is specified in the data sheet but 
must also be considered *internal* to the device since a poor set of 
switching I/Os and/or improperly bypassed and distributed rails can affect 
the amount of jitter seen by the time it gets to the global clock routing.

- John_H

"PeteS" <peter.smith8380@ntlworld.com> wrote in message 
news:fXr6h.14160$yz3.6788@newsfe4-gui.ntli.net...
> At bottom:
>
> PeteS wrote:
>> Inline:
>>
>> Austin Lesea wrote:
>>> Thomas,
>>>
>>> Comments below,
>>>
>>> Austin
>>>
>>> -snip-
>>>
>>>> I hadn't a thermometer ready, but I can always touch the FPGA for a
>>>> long time, it may be 50°C.
>>>
>>> How much slack does your timing report say it has?
>>>
>>>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of
>>>> 78.777MHz, and logic utilization is about 60%.
>>>
>>> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz).  That
>>> is pretty darned small.  If you have 400 ps of jitter on your clock, you
>>> now have 327 - 1/2 (400) = 127 ps of slack ...
>>>
>>> If you have 800 ps of jitter, then you are failing (slack less than 0).
>>>
>>> If you have any paths that were not constrained properly, then 327 ps of
>>> slack is a fiction, you really may have paths that are failing to meet
>>> timing.
>>
>> Now come, Austin. If the tool tells me I have positive margin (however 
>> small) I expect that to be true. I've done designs where I calculated the 
>> worst case and had a _guaranteed_ margin of 8 ps. Note the word 
>> guaranteed. I thought the post-PAR analysis tools gave me guaranteed 
>> timings.
>>
>>
>>>
>>>> One board works as expected and two other show the explained effect,
>>>> the boards have the same layout but are made by different
>>>> manufacturers. At least the not working are lead free.
>>>
>>> Parts will vary:  some will be faster than specified.  none will be
>>> slower than specified.
>>
>> Lead free processes stress a part more than the non-lead free; there is 
>> also the issue that the joints may not have the same highspeed 
>> performance; your application is highspeed enough to be susceptible to 
>> soldering issues. However, I agree with Austin that your margin is sorta 
>> small.
>>
>>
>>>
>>>> Just now, we had a discusion to the influence of temperature to
>>>> propagation delay. I don't believe that it influences clock lines and
>>>> other logic resources in a (big) different way. Is It true or not?
>>>
>>> Temperature affects all delays.  The resource affected may be different,
>>> and may be affected more, or less, but they will all slow down at hotter
>>> temperatures.
>>>
>>>> I read the thread "Propagation delay sensitivity to temperature,
>>>> voltage, and manufacturing", but the answers are very related to DCMs.
>>>
>>> DCM's vary, too.  So does everything else.
>>> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a
>>> rule of thumb, not anything we characterize or guarantee.
>>>
>>> You are just too close to the edge:  go back and review your constraints
>>> (to see if they cover all the critical paths), and perhaps apply a
>>> smaller clock period as a timing specification.
>>
>> I would also check to see if you are adding the signal rise/fall (which 
>> can get quite high for non-rocket IO pins) as temperatures increase.
>>
>> Cheers
>>
>> PeteS
>
> You are obviously clocking things from somewhere. A margin of 300 ps or so 
> can get lost in the rise/fall times of a hot clock source. Have you 
> characterised your clock inputs properly for post-PAR analysis?
>
> Cheers
>
> PeteS 



Article: 112015
Subject: DSP Library for PPC405?
From: "Anonymous" <someone@microsoft.com>
Date: Tue, 14 Nov 2006 23:58:33 GMT
Links: << >>  << T >>  << A >>
I noticed that the PPC405 in the V4s has a MAC instruction. Does anyone know
if there are optimized filter or fft routines to take advantage of this? I
do my signal procesing in the FPGA but it would be nice to be able to do
some simple procesing with the core.

Thanks,
Clark



Article: 112016
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Wed, 15 Nov 2006 13:21:36 +1300
Links: << >>  << T >>  << A >>
PeteS wrote:

> Now come, Austin. If the tool tells me I have positive margin (however 
> small) I expect that to be true. I've done designs where I calculated 
> the worst case and had a _guaranteed_ margin of 8 ps. Note the word 
> guaranteed. I thought the post-PAR analysis tools gave me guaranteed 
> timings.

As far as I am aware, unless you punch it in, the tools won't take 
account of your input clock jitter, which can get quite large - I think 
that was the point?

The tools have to make some assumptions somewhere - they don't have the 
information :)

Jeremy

Article: 112017
Subject: EDK: command not found
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Tue, 14 Nov 2006 16:32:55 -0800
Links: << >>  << T >>  << A >>
Hi,

I try to build a simple program to run on PowerPC, which is HelloWork. When I compile, the error is:

make: gcc: Command not found make: *** [PortLinux1/HelloWorld] Error 127

I checked the environment variables, which are XILINX_EDK, and Path. Everything is ok. I also did try to set a variable GNU_TOOLS to the gnu, but it still not work.

Please tell me how to set variable to run the compile.

Thanks,

Thang Nguyen

Article: 112018
Subject: Software Compile : gcc command not found
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Tue, 14 Nov 2006 16:43:11 -0800
Links: << >>  << T >>  << A >>
Hi,

I try to build a simple program to run on PowerPC, which is HelloWorld. When I compile, the error is:

make: gcc: Command not found make: *** [PortLinux1/HelloWorld] Error 127

I checked the environment variables, which are XILINX_EDK, and Path. Everything is ok. I also did try to set a variable GNU_TOOLS to the gnu, but it still not work.

Please tell me how to set variable to run the compile.

Thanks,

Thang Nguyen

Article: 112019
Subject: Re: Compile error by Cadence NC-Sim
From: sharp@cadence.com
Date: 14 Nov 2006 16:56:44 -0800
Links: << >>  << T >>  << A >>

uvbaz wrote:
>
> 2. "$XILINX/verilog/src/simprims/*.v" not recognized, why?

>From what you wrote, it appears that you are using an input script
file, and running the tool with the -f option to feed it in.  I notice
that you have //comments in your script file.  I suspect that the /* in
your pathname is being interpreted as a start of a block comment in the
script file.  This would mean that the path stops at simprims, followed
by the start of a block comment /*.v.  So you are trying to compile
simprims, which is a directory.  Note that the path printed by your
error message ends at simprims.

There is probably some way to escape the * character to prevent this
from happening, but I don't know what it is.


Article: 112020
Subject: Re: How to control the running of NC-Sim and Xilinx ISE under Unix?
From: sharp@cadence.com
Date: 14 Nov 2006 17:02:46 -0800
Links: << >>  << T >>  << A >>

uvbaz wrote:
> I've write a script for this, but with no control statement. How can i
> control the running flow, namely:
>
> if (NCVLOG ERROR) then ERROR REPORT and STOP THE RUNNING....

ncvlog and ncelab return an exit status, like many executables under
UNIX.  I don't know about the other tools you mentioned.

With csh, you can test this with something like

ncvlog -f ncvlog.args
if ($status != 0) then
  echo "ncvlog failed"
  exit
endif

Other UNIX shells may use different mechanisms, but they should all
provide access to the exit status.


Article: 112021
Subject: Re: xupv2p
From: "vbcity" <chenxiang.xu@gmail.com>
Date: 14 Nov 2006 17:27:39 -0800
Links: << >>  << T >>  << A >>
Maybe you need a SATA connection to get a ultra high speed link. The IP
Core for that is called Aurora. You can get a reference design from
http://www.xilinx.com/univ/xupv2p.html

On Nov 14, 9:22 pm, "nana" <nmic...@utk.edu> wrote:
> Helllo,
> Does anyone know about transfering data between two xupv2p boards, that
> is from one board to another?
> I appreciate your help
> 
> nmichou


Article: 112022
Subject: Re: Influence of temperature and manufacturing to propagation delay
From: Ray Andraka <ray@andraka.com>
Date: Tue, 14 Nov 2006 21:56:13 -0500
Links: << >>  << T >>  << A >>
PeteS wrote:


> Now come, Austin. If the tool tells me I have positive margin (however 
> small) I expect that to be true. I've done designs where I calculated 
> the worst case and had a _guaranteed_ margin of 8 ps. Note the word 
> guaranteed. I thought the post-PAR analysis tools gave me guaranteed 
> timings.
> 
> 

That is true provided you have a jitter-free clock.  The tools do not 
know, nor can they predict how much jitter is on your clock.  You need 
to consider a jitter margin in your clock constraints, as any jitter 
erodes the minimum clock period.  Keep in mind that you not only have 
the jitter introduced by the DCMs if you use them, but also jitter 
inherent in your clock source plus jitter added by noise on the board 
and more importantly by modulation of the VCC-IOs of the clock pins by 
other pins switching on the bank or by fluctuations in the power rails. 
  If you subtract your cycle-to-cycle max jitter from the clock 
constraint, then you wind up with guaranteed operation.

In a lab environment, you can usually get away with ignoring the jitter, 
as you usually won't be anywhere near the slow corner of voltage, 
process and temperature.  In the field though, not allowing for 
sufficient jitter tolerance is likely to come back and bite you hard in 
the shorts.

Article: 112023
Subject: Programming model on FPGA
From: "awa" <ameliaw.azman@gmail.com>
Date: 14 Nov 2006 18:59:28 -0800
Links: << >>  << T >>  << A >>
Hi,

I am new in this area and would be happy to have some feedbacks.


Does anyone have a clear cut answer as to what really low level
programming model in image processing is? I have found different
definitions and getting confused.


My other question is, why does FPGA is said to  have major disadvantage
in modelling at low level? 


Thank you.


Article: 112024
Subject: Re: xupv2p
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Tue, 14 Nov 2006 22:09:06 -0600
Links: << >>  << T >>  << A >>
I did this by defining my own MGT protocol and connecting the board with a 
short SATA cable.  It took a little bit of learning and then some coding but 
once I was done it worked with no problems.  The corgen makes it pretty easy 
to setup.  The hardest part is setting up the physical constraints.


---Matthew Hicks


"vbcity" <chenxiang.xu@gmail.com> wrote in message 
news:1163554058.869484.20650@b28g2000cwb.googlegroups.com...
> Maybe you need a SATA connection to get a ultra high speed link. The IP
> Core for that is called Aurora. You can get a reference design from
> http://www.xilinx.com/univ/xupv2p.html
>
> On Nov 14, 9:22 pm, "nana" <nmic...@utk.edu> wrote:
>> Helllo,
>> Does anyone know about transfering data between two xupv2p boards, that
>> is from one board to another?
>> I appreciate your help
>>
>> nmichou
> 





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