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
2019JanFebMar2019

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 42650

Article: 42650
Subject: Re: Does Vertex II PRO Really work?
From: "Phil Connor" <philip_john_connor@hotmail.com>
Date: Tue, 30 Apr 2002 09:18:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
"Peter Alfke" <palfke@earthlink.net> wrote in message
news:3CCD6747.8421B78A@earthlink.net

> Phil, you have read too many conspiracy stories.
> 
> Peter Alfke
> 

Sorry Peter, it was mischevious of me to stoke the debate.

Apologies,

Phil


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 42651
Subject: Re: Xilinx XC9500XL family - disabling the bus-hold circuits
From: l.l.chisholm@paradise.net.nz (Len Chisholm)
Date: Tue, 30 Apr 2002 11:38:02 GMT
Links: << >>  << T >>  << A >>
On Mon, 29 Apr 2002 17:48:12 -0700, Mark Ng <mark.ng@xilinx.com>
wrote:

>Hi Len,
>
>It is definitely possible to disable the bus-hold circuitry in all 9500XL
>devices.
>

Thanks Mark,

That is definitely the right answer !

I guess I've got to go and see the guy with the F4.2 license and get
him to do me a test JED file to see what happens to the I/Os.

Len Chisholm.


Article: 42652
Subject: Re: Frequency synthesiser
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 30 Apr 2002 14:23:11 +0200
Links: << >>  << T >>  << A >>
Hi Adrian,
I developed a digital PLL some years ago
and found some unknown tricks.
Maybe I can help you.
What is your desired output frequency range ?

-Manfred



"Noddy" <g9731642@campus.ru.ac.za> schrieb im Newsbeitrag
news:1019660268.49750@turtle.ru.ac.za...
> Hi,
>
> I am trying to design a high precision (30 bit) frequency synthesiser
inside
> a Spartan II. Of course, normal way to do this is with a charge pump,
> voltage controlled oscillator and a phase lock loop.
>
> Can anyone point me to some good references? I have a very high precision
> 5Mhz which is generated from a hydrogen maser and will be used as the
input
> clock signal.
>
> thanks
> adrian
>
>
>



Article: 42653
Subject: EDIF parser (perl)
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Tue, 30 Apr 2002 15:03:45 +0200
Links: << >>  << T >>  << A >>
I am searching an EDIF parser for automatic documentation generation.

where can I get some scripts?

Thanks

Laurent - Amontec


Article: 42654
Subject: Re: un-constraint path - from Clock pad to FFS clock pin
From: ospyng@yahoo.com (spyng)
Date: 30 Apr 2002 06:58:02 -0700
Links: << >>  << T >>  << A >>
Bob,
thanks, for your suggestion, that's what I am looking for actually!
(the from to constraint)

I know the clock delay does not really affect the operating freq, and
the delay is working fine for me, just that when they show up as an
un-constraint path, I feel un-easy about it. They should not have
appear as un-constraint path, clock delay should have been included in
the STA of the normal path. you show the clock delay+skew and the data
delay then get the slack.

anyway, I got a feel back from a xilinx support as.

>I was not talking about the IOB registers.  I was talking about the
CLK in to any FF in the device.  90% coverage is very good, and you do
not need to increase this more.  It is completely normal to have these
clock delays listed as unconstrained paths for reasons mentioned in my
last email.  We will have a better way of handling these unconstrained
clock paths in our next major release, but for now you do not need to
worry about them.  They are constrained by the OFFSET IN constraint
even though it doesn't mention it.


>I see what you are saying! This is normal. The path from the CLK pad
to the CLK input on the FF is "analyzed" by the OFFSET constraint. 
However, it is not actually constrained, so it will not show up as a
constrained path.  The reason it is not constrained, is because it is
on global routing, it can not be any faster.  The only way to improve
a time it takes to get FROM the CLK pad to the FF's CLK input is
constrain the data path to the FF so that the path is shorter, and
this is done by the OFFSET.

>You can add a FROM TO constraint on the CLK net (FROM clk_pad TO
clk_FF), however this is not going to improve timing, and it will
lengthen your run time slightly.  The number that is reported for the
max speed of the clock is based on all of your constraints, and
reflects the affect those constraints have on the routing of the CLK
net even though the clock net is not directly being constrained.



thanks and have a nice day
pyng

Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<dtrqcuorukmvnum6usf9perpe0rqg3mat6@4ax.com>...
> On 29 Apr 2002 08:03:18 -0700, ospyng@yahoo.com (spyng) wrote:
> 
> >hi,
> >does anyone have experience these?
> >
> >CLK pad input to FF show up as unconstraint path during timing
> >analysis. and reduce coverage of timing constraint (90.5%). These
> >un-constraint paths are the clock delay from the clk pad to the clk
> >pin of the FFS
> >
> >Clk Pad input goes through a DCM and generate a internal clk to most
> >of the ffs in the design. there is currently a period constraint on
> >the clk pad input and during translate, there is message that show
> >that the period constraint have been push through the DCM and new
> >period constraint had been generated for the internal clock. The
> >internal clock period constraint is working fine.
> >
> >Why are all paths from Clk pad input to all ffs clk pin show up as an
> >unconstraint path?
> 
> Because they're not constrained.
> 
> The delay from the input pin to an internal flip-flop or RAM has no
> effect on the speed at which the device can be clocked internally.  If
> you have a 50 MHz  period constraint, the internal paths do not care
> if the delay from the clock pin to the internal FFs and RAMs is 0.5ns
> or 500ns, as long as that delay is common to all devices; in either
> case, you'll still be able to run at 50 MHz.  (Of course, there is the
> issue of whether a 500ns path could actually pass a 10ns pulse, but
> that's a topic for another day.)
> 
> I always add constraints for the pads-to-internal-devices clock paths,
> because I don't want my unconstrained paths report to be cluttered
> with stuff that's actually OK.  And it's also a good way to confirm
> that the delay is what I expect it to be.  For example, I added the
> following constraint in the ucf file to a 100 MHz clock passing
> through a DCM in a 2V3000:
> 
> TIMESPEC TSCLK04 = FROM PADS(ext_clk100) TO FFS     : 0.5;
> 
> Bob Perlman
> -----
> Cambrian Design Works
> http://www.cambriandesign.com

Article: 42655
Subject: Pb to write on flash with nios on excalibur
From: "Vincent JADOT" <vjadot@digitalsurf.fr>
Date: Tue, 30 Apr 2002 16:42:54 +0200
Links: << >>  << T >>  << A >>
Hi.
I try to send data into the flash memory of the excalibur kit by the nios,
but the
example programs (C program files)  of the kit don't work, i have changed
code and now i can enrase sector of flash but i can't write data.


I'm student and i have basic  knowledges of C programmation.

Thanks;
Vincent



Article: 42656
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 07:48:43 -0700
Links: << >>  << T >>  << A >>



All,

I think everyone is missing the beauty of the EasyPath program.

We run lots of silicon to a specific customer test program, and the yield for
just that functionality is good so that we can offer the parts at a price
competitive with the price of an ASIC.

Thus, no reason to redesign your IP into an ASIC for cost reduction, just
make the exact same decisions you would make anyway:  freeze the program,
stop making changes, and sign up for a big order, with some NRE for the test
program.

The absolutely fabulous part is that there is no risk.  With the ASIC who
knows what will happen?  How it will yield?  What interesting little quirks
it may have that will make it just a little less useful than the FPGA was.

Even better, is if you do suddenly have to make a change, can the ASIC
supplier take back all parts, retest to a new program, and re-issue them?
EasyPath offers opportunities for corrective actions that will make any
manager able to sleep better at night.  Yes, it will cost money to retest.
Yes, it will cost moneyy and take time to test product already shipped.  And
yes, there will be some fallout, depending on the change that was made.  But
look at the bright side:  you will not be stuck with a lot of scrap that
people will be making jewely with.

Do we care where the non-functional parts and pieces are?  No.  Do we want to
spend anytime trying to identify what is broken?  No.  Do we want to fill
experimenter bags with bogus parts that could be remarked, and sold on the
grey market and cause untold grief for our real paying customers?  Absolutely
not.  (anyone remember the grief on bad EPROMs that were re-marked as good,
and resold about twenty years ago?).

This is a revolutionary concept, one that will change the face of the use of
programmable logic.

If you want to experiment, you can go back to University, where we have an
active program for supporting experimental work.  Fill out the request forms
for a grant, and see what happens.  If we like the project, our R&D group may
work with the school and support it.

As someone who once upon a time reviewed all Masters and PhD projects for
their contribution to the state of the art and present technology at one of
the top three Universtities, I can tell you that many projects do not
qualify:  they have been done better by someone else, most often in
industry.  Hopefully today with the internet, it is a lot easier to perform
the same search that I used to do so long ago (i.e. 1975).

Austin


Hal Murray wrote:

> >Aw, come on.  Be serious for a moment.
> >
> >Is 2 Mbytes enough for video, or is that just not even close for
> >something like a high performance MPEG4 coder?  Is 1 Mbyte enough for a
> >packet processor?  What if you are using a 405PPC?  How much code space
> >do you need for a control program?  For a DSP support program (with all
> >of the hard stuff in the FPGA like the FFT cores, etc.)?
> >
> >If you look at SDRAM prices, are you willing to pay twice the commodity
> >price in an FPGA?  Three times?  How much is it worth to you?
> >
> >I already know that programs grow to fit the available memory space, and
> >that data grows to fill the disk.....
>
> There is obviously an chicken and egg problem.  If you put X bytes
> of RAM on the chip, then people will dream up ideas to use it.  Some
> of them won't fit so there will be a market for chips with more RAM.
>
> I remember a story about Motorola...  Nothing firm, just a rumor,
> but it seems reasonable.
>
> They had a good collection of "cores" for their small micro family.
> If you would sign up to purchase enough of them, they would build
> whatever you wanted from their collection of cores and make it into
> a standard product - n A/D, y counters, x ROM, y RAM...  Whatever
> you wanted from their chinese menu.
>
> You got normal product type support and documentation.  They got
> a guaranteed order to cover (some of?) the NRE.
>
> That sort of chinese menu approach might make sense for something
> like Easypath.  For example, you could take chips with broken RAM,
> zap a few links, and sell them as no-RAM (or smaller RAM) versions.
> If volume gets high enough you can make a special/cheaper die.
> Same for multipliers, and maybe PowerPC cores.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.



Article: 42657
Subject: Re: Loading values in Quartus II Waveform editor
From: prashantj@usa.net (Prashant)
Date: 30 Apr 2002 07:53:14 -0700
Links: << >>  << T >>  << A >>
Thanks Paul. I will try the .vec approach. 
You are right Kevin. And I'm in the process of making a transition to
the Modelsim OEM version provided by Altera. Hopefully that should be
an improvement.

Thanks,
Prashant


"Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message news:<3cce43b7$0$8510$cc9e4d1f@news.dial.pipex.com>...
> You can use a .vec or .vwf file which is just a text representation of the
> signal transitions. Edit this and use it as stimulus to your simulation.
> Results will still get displayed.
> (You can start by saving your current waveform as a .vec/.vwf and looking at
> the results/modifying it.
> 
> IMHO however you might want to consider using another simulator that
> supports more functions of a testbench. You write a test bench in your HDL
> which provides the waveforms and/may even check the results of the Device
> Under Test.
> 
> I used to exclusively use waveform entry, but it really becomes limiting for
> larger designs and almost impossible to do hierarchical testing.
> 
> Paul
> 
> "Prashant" <prashantj@usa.net> wrote in message
> news:ea62e09.0204291455.4f95879@posting.google.com...
> > hi,
> > I'm using the Quartus II simulator to simulate my design. My design
> > has grown and reached a point where I need to load up a thousands of
> > different input vectors for a specific input. It would be a waste of
> > time to try and do this manually.
> >
> > Is there a smart way to load many input vector values on a single
> > input in the waveform editor of Quartus II waveform editor ?
> >
> > Thanks,
> > Prashant

Article: 42658
Subject: Re: power supply sequencer for Virtex II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 08:07:08 -0700
Links: << >>  << T >>  << A >>
YD,

Texas Instruments has a web page devoted to powering Virtex and Virtex
E.

National Semi, Linear Tech, Elantec, and many others all make either low
dropout linear regulators, and/or switchers that can be used (and we use
ourselves).

Read app note 158, 450, and 451.

 http://www.support.xilinx.com/apps/appsweb.htm

Look up 158 under Virtex, and 450 and 451 under Spartan II.

Avoid parts that trip, foldback, or shut off.  It is OK to trip,
foldback, or shutoff only after a time delay (say 20 ms) in order to
meet UL or VDE safety requirements.

Many regulator parts today will start turning on, sense the current, and
if the current exceeds some threshold, they will turn off, and then
start up again.  This is exactly the kind of behavior you must avoid.
It will terminally confuse the startup logic of the Virtex, Virtex E,
Spartan II, Spartan IIE, and they will not power ON.

The regulator parts which have thermal shutdowns, and are linear current
limiting all work fine.

Avoid parts that say things like "high speed" as the FPGA is not an
Intel chip, and doesn't require 20 amperes in 100 ns.

Read the data sheet and be sure you can supply at least the minimum
required current for power ON (ie 500 mA for most Virtex C grade parts).

Austin


Deville wrote:

> Hi all,
>
> For Virtex, are there any issues regarding powering up the different
> voltage supplies in different orders?
> What sort of component can be use for supplying the Virtex?
>
> best regards,
>
> YD


Article: 42659
Subject: clock buffer infered on master reset in ISE for spartan2E
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Tue, 30 Apr 2002 11:23:00 -0400
Links: << >>  << T >>  << A >>
Any idea why the ISE software would insist on inserting a clock
buffer
on the master reset line for a spartan2E?  I checked for edge
requirements on the signal and found none.

Also, probably related, why does it not recognize a startup.  Here
is
the code snippet I used.

    u0_startup: startup_virtex PORT MAP
    (gsr=>master_reset
    );

Note Master_reset is a declared port on the top level of the chip.
Is
this the problem?

Also, I have a second input port that is serving as a clock (low
frequency ~100KHz) that also gets a forced clock buffer.  Can I
eliminate this? (Or should I do so?) How?  Please be specific as I
can
be a little dense sometimes.

Thanks,
Theron Hicks


Article: 42660
Subject: Re: clock buffer infered on master reset in ISE for spartan2E
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 30 Apr 2002 17:55:18 +0200
Links: << >>  << T >>  << A >>
"Theron Hicks" <hicksthe@egr.msu.edu> schrieb im Newsbeitrag
news:3CCEB6D4.62126C0@egr.msu.edu...

> Also, I have a second input port that is serving as a clock (low
> frequency ~100KHz) that also gets a forced clock buffer.  Can I

WARNING!!!
Dont be fooled by the low frequency!!!
If you drive clock onto non-clock nets with heavy loads, skew can (and most
probably WILL) kill your design. The clock frequency doesnt matter, since
the FlipFlops ALWAYS run at full speed.

> eliminate this? (Or should I do so?) How?  Please be specific as I
> can
> be a little dense sometimes.

If you have a high speed clock (here >1 MHz), sample this clock (and its
related inputs) and work everything on the fast clock net using clock
enables (derived from the sampled clock)

--
MfG
Falk





Article: 42661
Subject: Re: simultaneous switching of LVPECL outputs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 30 Apr 2002 16:06:24 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
<hicksthe@egr.msu.edu> wrote:

>Hi,
>    I am seriously considering using a spartan2e to serve as a clock
>distribution generator for a lvpecl clock system.  This clock system
>will be driving a total of 17 differential clocks.  When I price the
>LVPECL chips the spartan2e looks very competetive.  Also, it would give
>me the clock DLL to clean up my system clock.  The question is that I
>have a total of 34 output lines that should be switching at the same
>time.  The spec says 12 power and ground pairs in the chip and 3
>simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
>pair for me.)  How do I split these up over the 12 power/ground pairs?
>I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
>I get 12 power/ground pairs from these 24 pins?

If you're using differential outputs, the power and ground di/dt
should be significantly less than what you'd see for single-ended
signals.  Assuming that the true and complementary transitions occur
in unison, one driver should be increasing its ground or VCC current
as the other driver's current is decreasing.  The match isn't perfect,
but it should be pretty good.  

Ask Xilinx for diff pair power/ground guidelines; they should be less
stringent than the  guidelines for single-ended signals.

Bob Perlman
-----
Cambrian Design Works
http://www.cambriandesign.com
  

Article: 42662
Subject: Re: Power-up reset of Xilinx Spartan-II
From: djm@v-integration.com (Dave Matthews)
Date: 30 Apr 2002 09:25:08 -0700
Links: << >>  << T >>  << A >>
I had a problem with the DLL locking in one recent design. I've used
the DLL many times without problem, so I suspect it had something to
do with our strange clocking scheme.  But it was never solved due to
project time constraints.

We did the following, which worked quite well.  I ran the DLL reset
(the "RST" pin on the DLL component if you're instantiating it in your
code) to both a counter and a register bit.  The counter performed an
automatic reset of the DLL after device reset went away.  If software
ever wanted to, they could force a DLL reset via register bit.  Of
course, the host interface in the chip ran from a different clock
domain so I had the luxery of doing this.  If your host interface
clock comes from the DLL then you won't be able to do this (unless you
can still access the CCLK as you could back in the XC4000 days).

  Regards,

  Dave Matthews


Dave Matthews
V-Integration - FPGA and ASIC Design Services
www.V-Integration.com
978-371-4940



"Barry Brown" <barry_brown@agilent.com> wrote in message news:<1020115122.72002@cswreg.cos.agilent.com>...
> My design uses a Spartan-II configured from a PROM, and I'm using a clock
> DLL in the FPGA.  I have had some problems that I believe are due to
> power-up initialization, so I'm trying to come up with a fool-proof scheme
> to handle power-on config and reset.  Here's my plan:
> 
> 1. My board has a power-supply supervisor, which I will connect to the
> PROGRAM input.  This will hold off loading configuration until well after
> the supply is stable, and in case the power ever glitches, the FPGA should
> re-load itself.
> 
> 2. In BitGen, I will set LCK_cycle to 1, so that the startup after
> configuration will wait until the DLL is locked.
> 
> 3. I will connect the DONE signal to an input, where I will invert it and
> synchronize it and use it as the internal reset for my circuits in the FPGA.
> 
> 4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3.  I will set
> DONE_cycle = 6.  Therefore, my internal reset will be asserted until a short
> while after the DLL is locked and the GSR is released.
> 
> Anyone see a problem here?
> 
> Thanks,
> Barry Brown

Article: 42663
Subject: SpartanIIE hold timing
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 30 Apr 2002 12:25:26 -0400
Links: << >>  << T >>  << A >>
I am looking at the timing on the memory bus for the C6711B DSP when
driven from the FPGA and I don't see any data in the SpartanIIE data
sheet for output hold timing.  Am I missing something or is the output
hold time not specified?  

How can you interface to external SDRAM or SBSRAM, both of which have
input hold times greater than zero, if the FPGA output hold time is not
specified?  

Do I have to design the full hold time as routing delay on the PCB?  I
hate doing timing design with FR4!  :(


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42664
Subject: Re: SpartanIIE hold timing
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 30 Apr 2002 09:30:16 -0700
Links: << >>  << T >>  << A >>

I belive there are minimum numbers on the datasheet, I'd
look for minimum clock to out (with or without DLL, based
on your design).  I didn't check, but you may want to.

Eric

rickman wrote:
> 
> I am looking at the timing on the memory bus for the C6711B DSP when
> driven from the FPGA and I don't see any data in the SpartanIIE data
> sheet for output hold timing.  Am I missing something or is the output
> hold time not specified?
> 
> How can you interface to external SDRAM or SBSRAM, both of which have
> input hold times greater than zero, if the FPGA output hold time is not
> specified?
> 
> Do I have to design the full hold time as routing delay on the PCB?  I
> hate doing timing design with FR4!  :(
> 
> --
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42665
(removed)


Article: 42666
Subject: Re: SpartanIIE hold timing
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 30 Apr 2002 09:58:19 -0700
Links: << >>  << T >>  << A >>
Input hold times are ugly, that's why all Xilinx FPGAs have had extra input
delays since the XC3000 days, in order to guarantee a "negative hold time".
When you have to drive a (dumb) chip with a positive hold time requirement, you
need to guarantee a min delay on the driving output ( some people call that an
output hold time).

Such a min delay is usually not specified, since it is very difficult to
measure, and, if guaranteed, would preclude "down-binning" i.e. branding fast
chips as slow.

Here are a few suggestions:
•You can rely on the speed of light, >150 ps per inch on a pc-board.
•For the fastest speed grade, you can assume the min parameter to be >25% of the
specified max value ( for clock-to-out)
•You can deliberately delay the internal clock that drives the output in
question.
•In Virtex-II you can do that with the precision phase-shift in the DCM.
•In slow applications you can use the opposite clock edge.

Positive input hold times are a real pain in the ***. They are an indication
that the chip manufacturer cares more about fancy performance specifications
than about reliable operation in a real system...

Peter Alfke, Xilinx Applications
==========================================
rickman wrote:

> I am looking at the timing on the memory bus for the C6711B DSP when
> driven from the FPGA and I don't see any data in the SpartanIIE data
> sheet for output hold timing.  Am I missing something or is the output
> hold time not specified?
>
> How can you interface to external SDRAM or SBSRAM, both of which have
> input hold times greater than zero, if the FPGA output hold time is not
> specified?
>
> Do I have to design the full hold time as routing delay on the PCB?  I
> hate doing timing design with FR4!  :(
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 42667
Subject: Re: simultaneous switching of LVPECL outputs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 10:01:09 -0700
Links: << >>  << T >>  << A >>
Bob,

Spartan 2 uses external resistor networks to get the LVPECL levels, so there
is no benefit from differential switching as regards to ground bounce.  Each
single ended IO is already switching rail to rail, and driving hard.  Thus
even though some of the current flows out comes back in on the other pin, a
lot of current is flowing through power and ground.

Austin

Bob Perlman wrote:

> Hi -
>
> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
> <hicksthe@egr.msu.edu> wrote:
>
> >Hi,
> >    I am seriously considering using a spartan2e to serve as a clock
> >distribution generator for a lvpecl clock system.  This clock system
> >will be driving a total of 17 differential clocks.  When I price the
> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
> >me the clock DLL to clean up my system clock.  The question is that I
> >have a total of 34 output lines that should be switching at the same
> >time.  The spec says 12 power and ground pairs in the chip and 3
> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
> >pair for me.)  How do I split these up over the 12 power/ground pairs?
> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
> >I get 12 power/ground pairs from these 24 pins?
>
> If you're using differential outputs, the power and ground di/dt
> should be significantly less than what you'd see for single-ended
> signals.  Assuming that the true and complementary transitions occur
> in unison, one driver should be increasing its ground or VCC current
> as the other driver's current is decreasing.  The match isn't perfect,
> but it should be pretty good.
>
> Ask Xilinx for diff pair power/ground guidelines; they should be less
> stringent than the  guidelines for single-ended signals.
>
> Bob Perlman
> -----
> Cambrian Design Works
> http://www.cambriandesign.com
>


Article: 42668
Subject: Re: Power-up reset of Xilinx Spartan-II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 30 Apr 2002 10:04:44 -0700
Links: << >>  << T >>  << A >>
Barry,

If the feedback comes from an external source, then there is the possibility
that the DLL is trying to start up before the feedback signal is present on the
DLL CLKFB pin.

Then there are the usual suspects:  the CLKIN signal isn't really stable
immediately after configuration, when all the design wakes up and starts
switching, the power supplies suddenly sag (bad power regulation) and the DLL
can't accomodate such a large supply shift, or the cross talk induced delay when
things start switching or the jitter pops the DLL out of LOCK.

Austin

Barry Brown wrote:

> My design uses a Spartan-II configured from a PROM, and I'm using a clock
> DLL in the FPGA.  I have had some problems that I believe are due to
> power-up initialization, so I'm trying to come up with a fool-proof scheme
> to handle power-on config and reset.  Here's my plan:
>
> 1. My board has a power-supply supervisor, which I will connect to the
> PROGRAM input.  This will hold off loading configuration until well after
> the supply is stable, and in case the power ever glitches, the FPGA should
> re-load itself.
>
> 2. In BitGen, I will set LCK_cycle to 1, so that the startup after
> configuration will wait until the DLL is locked.
>
> 3. I will connect the DONE signal to an input, where I will invert it and
> synchronize it and use it as the internal reset for my circuits in the FPGA.
>
> 4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3.  I will set
> DONE_cycle = 6.  Therefore, my internal reset will be asserted until a short
> while after the DLL is locked and the GSR is released.
>
> Anyone see a problem here?
>
> Thanks,
> Barry Brown


Article: 42669
Subject: Re: Problems creating a tristated data bus on Spartan-II
From: koziar.pete@orbital.com (Pete Koziar)
Date: 30 Apr 2002 10:07:21 -0700
Links: << >>  << T >>  << A >>
Try setting the port to all 'Z'. You can still use the input side of the port.

I'm assuming the port is defined as "inout" in the port map?

- Pete Koziar
  Principle Engineer, VLU-120
  Orbital Sciences/TMS (http://www.orbtrac.com)

creon100@yahoo.com (Sean) wrote in message news:<b97bab2f.0204251138.12476582@posting.google.com>...
> It's me again, in my ongoing saga and struggle with this ISA bus
> implementation.
> 
> I am communicating over the bus fine now, but am having problem with
> my synthesizable VHDL.
> 
> The way it is working is that we have VHDL modules describing an input
> (as seen by the PC) port and an output ISA port.  We're going to have
> about four input ports and one or two output ports in the description
> of the chip (meaning it will respond to about six I/O address, some
> for read, some for write).
> 
> The input port description synthesizes with a tristate data bus. 
> However, the output port synthesizes with only an input bus since it
> will only be reading the bus, and only doing that when it's address is
> present (hence, no bus contention).  When I do a top-level design
> using one input port and one output port it creates the data bus fine
> and creates iobufs on the bus.  However, for some reason when I have
> one ouput port and two input ports the synthesis tool gives a warning
> saying there is no port type for the data bus and automatically gives
> it only output buffers.
> 
> This results in the following problem.  Once the chip is programmed by
> the PC the data bus automatically causes contention on the bus and so
> the PC goes crazy.
> 
> I just don't understand why it would suddenly not be able to determine
> the my bus needs to be a tristated iobuf instead of just an output
> buffer.

Article: 42670
Subject: Re: simultaneous switching of LVPECL outputs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 30 Apr 2002 18:08:10 GMT
Links: << >>  << T >>  << A >>
Austin - 

On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
<austin.lesea@xilinx.com> wrote:

>Bob,
>
>Spartan 2 uses external resistor networks to get the LVPECL levels, so there
>is no benefit from differential switching as regards to ground bounce.  Each
>single ended IO is already switching rail to rail, and driving hard.  Thus
>even though some of the current flows out comes back in on the other pin, a
>lot of current is flowing through power and ground.
>
>Austin

The original poster wanted to use Spartan IIE which, if I'm reading
the data sheet correctly, supports LVPECL differential outputs
terminated with 100 ohms across the two signals.

The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
1.06-1.43V, or~ 1.25V typical.  This means that the current through
the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.

When the differential signal switches, one driver switches from source
to sink, while the other switches from sink to source.  On the ground
side, one driver slews from sinking 8.5 mA to sinking nothing, while
the other slews from sinking nothing to sinking 8.5mA.  Similar things
happen on the VCC side, except that current is being sourced rather
than sunk.  

Beyond a certain point, the strength of the drivers is moot; the
current into or out of the I/O pin will be limited by the transmission
line impedance.  If we think of the differential lines as two 50-ohm
single-ended lines, the current needed to send a 0.85V delta V down
each line is 17mA, which is exactly the delta you get when you stop
sourcing 8.5mA and start sinking it, or vice versa.

The balance isn't perfect, but the net di/dt on either the VCC or
ground paths should be considerably less than for single-ended
signals.

Bob Perlman
-----
Cambrian Design Works
http://www.cambriandesign.com


>
>Bob Perlman wrote:
>
>> Hi -
>>
>> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
>> <hicksthe@egr.msu.edu> wrote:
>>
>> >Hi,
>> >    I am seriously considering using a spartan2e to serve as a clock
>> >distribution generator for a lvpecl clock system.  This clock system
>> >will be driving a total of 17 differential clocks.  When I price the
>> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
>> >me the clock DLL to clean up my system clock.  The question is that I
>> >have a total of 34 output lines that should be switching at the same
>> >time.  The spec says 12 power and ground pairs in the chip and 3
>> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
>> >pair for me.)  How do I split these up over the 12 power/ground pairs?
>> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
>> >I get 12 power/ground pairs from these 24 pins?
>>
>> If you're using differential outputs, the power and ground di/dt
>> should be significantly less than what you'd see for single-ended
>> signals.  Assuming that the true and complementary transitions occur
>> in unison, one driver should be increasing its ground or VCC current
>> as the other driver's current is decreasing.  The match isn't perfect,
>> but it should be pretty good.
>>
>> Ask Xilinx for diff pair power/ground guidelines; they should be less
>> stringent than the  guidelines for single-ended signals.
>>
>> Bob Perlman
>> -----
>> Cambrian Design Works
>> http://www.cambriandesign.com
>>


Article: 42671
Subject: Re: SpartanIIE hold timing
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 30 Apr 2002 15:19:36 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Input hold times are ugly, that's why all Xilinx FPGAs have had extra input
> delays since the XC3000 days, in order to guarantee a "negative hold time".
> When you have to drive a (dumb) chip with a positive hold time requirement, you
> need to guarantee a min delay on the driving output ( some people call that an
> output hold time).
> 
> Such a min delay is usually not specified, since it is very difficult to
> measure, and, if guaranteed, would preclude "down-binning" i.e. branding fast
> chips as slow.

I guess I am a little confused.  I had the impression that the
SpartanIIE devices (I am not working with VirtexII devices) were
compatible with SDRAM and SBSRAM interfaces.  These interfaces specify
hold times of 0.8/0.5 nS respectively.  How does the SpartanIIE FPGAs
work with these devices if you don't spec a minimum output hold time? 
Do you require the user to add 5 inches of board routing to the data
path?  

Because of the problem caused by the long hold time of the C6711B DSP,
there will likely be an additional route delay of 1 nS to the SBSRAM
which will add to the output hold time requirement of the FPGA unless we
are very careful about clock vs. data routing.  I had hoped that by
keeping the board small and all routing very short, I would minimize the
SI issues involved.  However it is looking like TI is going to torpedo
my efforts in this regard.  

I don't see how spec'ing a min hold time would preclude downbinning. 
For example if you spec'ed 0.8 nS hold time on all of your speed grades,
then you if a chip tested faster in the max clock to out, but met the
min, it could still be used for the slow.  Just because you have a min
spec does not mean it has to change with speed grade.  The max value of
clock to output with the DLL in use is 3.1 nS on the Spartan-IIE -6
grade.  25% of this is just a hair under 0.8 nS.  Couldn't this be
spec'ed at 0.8 nS and easily tested?  IIRC, the 25% estimate is intended
to include the fabrication of faster parts over the forseeable lifetime
of the chip.  Can't Xilinx sign up to this estimate by spec'ing it in
the data sheet?  


> Here are a few suggestions:
> •You can rely on the speed of light, >150 ps per inch on a pc-board.

That would require 5 inches of routing on a 3.6" sq board.  Not an easy
solution without adding a delay line layer. 


> •For the fastest speed grade, you can assume the min parameter to be >25% of the
> specified max value ( for clock-to-out)

This is useful.  But is there a reason that this can not be spec'd in
the data sheet?  How can you work with standard memory parts without
this specification?


> •You can deliberately delay the internal clock that drives the output in
> question.

Can you give details on this?  Does it require the use of a DLL?  Can
the DLL be used independantly of the clock routing, that is, if I
already am using all four clock buffers, can I use the DLL as a fifth,
or do I need to delete one of the other clocks? 


> •In Virtex-II you can do that with the precision phase-shift in the DCM.

We are not using the Virtex-II parts.  We are using the SpartanIIE to
try to make an economical board. 


> •In slow applications you can use the opposite clock edge. 

This is a 100 MHz memory interface.  I think that would prevent meeting
the setup times. 


> Positive input hold times are a real pain in the ***. They are an indication
> that the chip manufacturer cares more about fancy performance specifications
> than about reliable operation in a real system...

Positive input hold times may be a PITA, but they are a part of high
speed digital design in the 21st century.  I don't make the rules,  I
just have to design by them.  If Xilinx does not like positive input
hold times, then they should get on the memory interface spec committees
and change them.  But in the meantime we all have to design with
positive input hold times.  


> Peter Alfke, Xilinx Applications
> ==========================================
> rickman wrote:
> 
> > I am looking at the timing on the memory bus for the C6711B DSP when
> > driven from the FPGA and I don't see any data in the SpartanIIE data
> > sheet for output hold timing.  Am I missing something or is the output
> > hold time not specified?
> >
> > How can you interface to external SDRAM or SBSRAM, both of which have
> > input hold times greater than zero, if the FPGA output hold time is not
> > specified?
> >
> > Do I have to design the full hold time as routing delay on the PCB?  I
> > hate doing timing design with FR4!  :(
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42672
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 01 May 2002 07:47:41 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> All,
<snip> 
> Do we care where the non-functional parts and pieces are?  No.  Do we
> want to spend anytime trying to identify what is broken?  No.  Do we
> want to fill experimenter bags with bogus parts that could be
> remarked, and sold on the grey market and cause untold grief for our
> real paying customers?  Absolutely not.  (anyone remember the grief on
> bad EPROMs that were re-marked as good, and resold about twenty years
> ago?).

 I had seen this as a risk exposure, and since you have now mentioned
it,
what actually stops these devices comming back to bite users ?
  
> This is a revolutionary concept, one that will change the face of the
> use of programmable logic.

 Sorry, but not at the MOQ and NRE's....

 As to revolutionary ? - I've heard stories about russian programmers 
being given chips with an errata tagged to each device. 
They had to work around the errata on a batch basis !

-jg

Article: 42673
Subject: Re: SpartanIIE hold timing
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 30 Apr 2002 19:48:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CCEEE48.1B6EA5BA@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:

>
>> •You can deliberately delay the internal clock that drives the output in
>> question.
>
>Can you give details on this?  Does it require the use of a DLL?  Can
>the DLL be used independantly of the clock routing, that is, if I
>already am using all four clock buffers, can I use the DLL as a fifth,
>or do I need to delete one of the other clocks? 

Ick, if you are using all the clock buffers, this would be
problematic.  Otherwise, you drive the I/O output flip-flops with a 90
degree phase offset from the bus clock, asuming you would still meet
other timing constraints.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42674
Subject: Re: power supply sequencer for Virtex II
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 01 May 2002 07:48:56 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> YD,
> 
> Texas Instruments has a web page devoted to powering Virtex and Virtex
> E.
> 
> National Semi, Linear Tech, Elantec, and many others all make either low
> dropout linear regulators, and/or switchers that can be used (and we use
> ourselves).
> 
> Read app note 158, 450, and 451.
> 
>  http://www.support.xilinx.com/apps/appsweb.htm
> 
> Look up 158 under Virtex, and 450 and 451 under Spartan II.
> 
> Avoid parts that trip, foldback, or shut off.  It is OK to trip,
> foldback, or shutoff only after a time delay (say 20 ms) in order to
> meet UL or VDE safety requirements.
> 
> Many regulator parts today will start turning on, sense the current, and
> if the current exceeds some threshold, they will turn off, and then
> start up again.  This is exactly the kind of behavior you must avoid.
> It will terminally confuse the startup logic of the Virtex, Virtex E,
> Spartan II, Spartan IIE, and they will not power ON.
> 
> The regulator parts which have thermal shutdowns, and are linear current
> limiting all work fine.
> 
> Avoid parts that say things like "high speed" as the FPGA is not an
> Intel chip, and doesn't require 20 amperes in 100 ns.
> 
> Read the data sheet and be sure you can supply at least the minimum
> required current for power ON (ie 500 mA for most Virtex C grade parts).
> 
> Austin

 What about the so called snap-action regulators ?

-jg



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
2019JanFebMar2019

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