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
2017JanFebMarApr2017

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 34300

Article: 34300
Subject: Re: Internal clock skew when using DLL
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Mon, 20 Aug 2001 13:56:51 +0100
Links: << >>  << T >>  << A >>
In article <3B7D55C5.52ED77F1@xilinx.com>, Peter Alfke
<peter.alfke@xilinx.com> writes

>> It doesn't help that I've also heard claims from certain Xilinx personnel
>> that their internal flip-flops are virtually metastable-proof...
>
>I really hope that nobody has said it that way. Metastability will be forever
>with us, like death and taxes.

For sure.  As will the occasional mangling of well-meant technical 
advice by over-enthusiastic sales persons :-)

>But, the recovery from a metastable situation has become much faster, now that
>we have a much higher gain-bandwidth product in the master latch. So we can
>count on metastability being resolved earlier, but the timing is still
>statistical, non-deterministic....

AIUI people have designed "metastable-hardened" FFs:  naturally, no-one
can avoid the extended clock-to-output delay that goes with 
metastability, but it *is* possible, I think, to side-step the worst
other effects:  oscillating outputs, runt pulses, all that kind of 
junk.  Philips offered a "metastable hardened" FF in the 74F series
some years ago (74F5074???) which claimed these properties IIRC.

It may well be that these improvements were achieved at the cost
of other performance figures - particularly clock-to-output delay 
in the normal case when Tsu/Th are met - which are likely to be 
much more important for FFs within a typical FPGA.
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 34301
Subject: Some questions about Spartan2 (& a bug report for XST sp8)
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Mon, 20 Aug 2001 12:57:32 GMT
Links: << >>  << T >>  << A >>
Dear Sir,
	I am sending you (as the sane technical voice of Xilinx) a few
questions
 and one bug report.
 I approve in advance should you wish to post any part of this or subsequent
emails
onto the comp.arch.fpga newsgroup to assist others.

Questions mainly about Spartan2...

1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set
   for a wide data configuration?
  (ie presumably the output signals can skip 4 levels of multiplexers)
2) is the carry out pin of a CLB in a LOW/HIGH/TRI STATE if not selected to
   be used in a 1 CLB hard macro?
3) whats the point of the CIN pins in the lowest row of slices?
   (ie with highest row index)
4) if the answer to the 3rd question is NONE then you might be amused
    to try smart-placing (within FPGA_EDITOR) a hard macro which uses a CIN
   (seems to like the lowest row for some reason!)

5) The Spartan2 databook is very unclear about IO banks & PQ packages.
    Presumably the Vref & Vccio arrangements are as with the Virtex? 
    (which was at least clearly documented)

6) Any chance of filling in some of the blank fields for Spartan2 -6
timing?

7) How about guaranteed best case timings as well ?
   ( specifically for BRAM access)

8) Would it be possible to sacrifice a BRAM   & use a DLL to lock onto the
Tbcko , or would the delay of other BRAMS not track? 
(even though being guaranteed to have the same Vccint & presumably
approximately the same temperature?)
(bearing in mind question 1, I would only be applying this to identical
data width BRAMS)
 If this approach is possible which data bit should I route through? 

9) Do the industrial versions draw more startup current than the commercial
devices at any given temperature,
  or is it only at extremely low temperatures (below the commercial range)
  that the current increases?

10) Using XST VHDL (SP8, on both WebPACK & ISE3.3i)
    RLOCS are lost on all but the first instance of a component containing
    RLOCS.
    This is BAD , especially when Carry logic and / or  MUXF5 is involved,
    because what creeps into the wrong CLB makes no sense at all
    (as regards timing/space) . 
   I originally thought this was a problem with MAP, but then examined the
   EDN file & found  that MAP hadn't been told to cluster components within
   a CLB. (for any except the first instance)
   "Preserve Heirarchy" had been SET (as a synthesis option).
   Presumably the only way around this is to use "Incremental Synthesis"? 
   (Apart from hacking the edn file to ensure all instances refer to the
   first cell definition,which does indeed work, but surely can't be 
   considered a standard flow!)
    but incremental synthesis doesn't work for any OTHER component!
   I haven't tried using the XILFILE attribute which could be a way to
   enforce the correct hierarchy.

11)The P&R tools seem to consider (single port) RAM address lines to be
   unswappable.
   Is there any way around this, because almost invariably I find that
   swapping  (ie deleting net pins  then adding net pins)
   the two highest net delay address inputs improves the timing on BOTH lines.

12) Any chance of a job at Xilinx?
 (I can write tools. I can design hardware. I like Xilinx hardware.)
  I'm afraid that jobs locally to me are of the sort 
 "You've got to use ACTEL" (probably something to do with the name of their
 main product line.)
 or "You've got to use Virtex" ( note not Virtex-E, Spartan2 or Virtex2 but
 Virtex).
 or "You've got to use ALTERA" or "You've got to have marketing experience".
I can supply the names of the guilty parties, but I don't think that would
help.
   
Respectfully yours,
	Mark Taylor
Mark_Taylor_Chess@compuserve.com
101551.3434@compuserve.com


  
       

Article: 34302
(removed)


Article: 34303
Subject: Re: Internal clock skew when using DLL
From: hamish@cloud.net.au
Date: Mon, 20 Aug 2001 13:19:01 GMT
Links: << >>  << T >>  << A >>
Falk Brunner <Falk.Brunner@gmx.de> wrote:
> Lets say you have a design running at 333 MHz (3ns period). All decoding
> logic between the FF of your design just needs has 3 ns propagation
> delay. Now you need to synchronize asynchronous signals, requireing
> additional 3ns of time. Now your slowest path is 6 ns, slowing down your
> system to around 160 Mhz (6ns). How to slove this problem?
> Simply insert a second FF close after the first synchronizing FF. Now
> the synchonizing FF will settle within 3 ns, just right to be (now
> synchronous) clocked in by the second FF. 

Really? If your clock period is 3 ns, don't you only have 1.5 ns
to the falling edge for the first synchronizer to settle, not 3 ns?


cheers,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 34304
Subject: Re: Spartan2 5V PCI IO
From: hamish@cloud.net.au
Date: Mon, 20 Aug 2001 13:23:45 GMT
Links: << >>  << T >>  << A >>
Eric Crabill <eric.crabill@xilinx.com> wrote:
> your design must have an individual TFD flop for each OFD.
> If you instantiate them, it works great.  If you are using
> a synthesis tool, you must code up the appropriate number
> and then be sure to disable duplicate register merge or
> whatever your favorite synthesis tool calls it...  Otherwise
> it will tend to optimize all but one of them away, and the
> packing will fail.

BTW, recent Synplify seems quite good about this; I've seen
it generate enough duplicates of the enable so that they can
be mapped into the IOBs. At least, I think I have. Version 6.2.x.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 34305
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Mon, 20 Aug 2001 13:23:45 GMT
Links: << >>  << T >>  << A >>
Sorry for the double post.
This was a copy of an email to Peter Alfke  Peter.Alfke@Xilinx.com
I didn't get a reply, so I'm hoping some answers might be available from this
newsgroup.



Article: 34306
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 20 Aug 2001 07:42:43 -0700
Links: << >>  << T >>  << A >>
Right,

It isn't a question of damaging the metal interconnect (not enough current),
or of damaging the transistors (again, not enough current); it is a question
of creating many millions of uA loads, that together cause the chip to
overheat.

I have often wondered what all the fuss is about:  use a power controller to
sense the temperature from the temp diode in Virtex (or Virtex E, or Virtex
II), or use a series current sensor in the Vccint line.  If in the process
of programming, either the temperature starts to rise, or the current is
over the limit, you try the next configuration.

Austin

Reinoud wrote:

> Eric Smith wrote:
> >
> > Reinoud <dus@wanabe.nl> writes:
> > > A circuit like you have drawn above will oscillate at a fairly high
> > > frequency.  If there are many loops, or if a lot of logic is driven
> > > at high frequency by such loops, this may draw a lot of power.  Many
> > > boards out there with large FPGAs were not designed to handle such
> > > power.  This is not a flaw of Virtex (actually, Xilinx documents
> > > power issues quite clearly), it's more a board/system design issue
> > > with current generation (high power density) chips.
> >
> > I appreciate the insight.  However, I'm still curious as to whether
> > such things are likely to damage the chip.  I suppose the answer
> > may depend on how many such circuits one manages to configure.
>
> It depends on how hot the chip can get when downloading such
> problematic designs.  This depends on FPGA technology, die size,
> packaging and cooling - and the capacity of the power supply.  The
> combination of a huge modern FPGA, strong power supply, and no
> heatsink has high potential for smoke emissions.  With a tiny FPGA or
> weak power supply, no sweat.  Otherwise, cooling or power/temperature
> monitoring can keep things within safe limits.
>
> You can get an idea of these power issues by playing with the power
> estimator on the Xilinx website, and calculating die temperatures
> with the package thermal data.
>
> - Reinoud
>
> (Spam goes to wanabe, mail to wanadoo.)


Article: 34307
Subject: Re: Virtex-II and 5V devices
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 20 Aug 2001 07:43:46 -0700
Links: << >>  << T >>  << A >>

--------------2C597F5A0EFBD37388CCEA9C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hal,

hyperlynx.com

Austin

Hal Murray wrote:

> > There are other SI tools available, that are more (from Mentor, Cadence, Avanti,
> > etc.) but I find Hyperlynx to be completely adequate for a lot of designs.  It
> > has a spice extraction mode to extract spice models from the pcb layout that is
> > particularly useful, too.  Maybe I just like its user interface.  Any SI tool is
> > a worthwhile investment.
>
> Thanks.
>
> What sort of "pcb layout" database/file can it read?
>
> --
> These are my opinions, not necessarily my employeers.  I hate spam.

--------------2C597F5A0EFBD37388CCEA9C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hal,
<p><a href="http//www.hyperlynx.com">hyperlynx.com</a>
<p>Austin
<p>Hal Murray wrote:
<blockquote TYPE=CITE>> There are other SI tools available, that are more
(from Mentor, Cadence, Avanti,
<br>> etc.) but I find Hyperlynx to be completely adequate for a lot of
designs.&nbsp; It
<br>> has a spice extraction mode to extract spice models from the pcb
layout that is
<br>> particularly useful, too.&nbsp; Maybe I just like its user interface.&nbsp;
Any SI tool is
<br>> a worthwhile investment.
<p>Thanks.
<p>What sort of "pcb layout" database/file can it read?
<p>--
<br>These are my opinions, not necessarily my employeers.&nbsp; I hate
spam.</blockquote>
</html>

--------------2C597F5A0EFBD37388CCEA9C--


Article: 34308
Subject: Need help: CLKDLLE.v does not work in simulation.
From: johnsonw10@hotmail.com (Johnsonw10)
Date: 20 Aug 2001 08:16:53 -0700
Links: << >>  << T >>  << A >>
According to Xilinx app. note 132, the feedback clock input of CLKDLLE
can be clk0 or clk2x. But in the functional simulations the CLKDLLE
doesn't work (all clock outputs remain 0's) if clk0 output is directly
connected to the clkfb input. Everything works fine if a bufg is
inserted between clk0 and clkfb. Does anybody know if this is just a
simulation issue or it is how clkdlle logic actualy works (clkfb input
has to be driven by a some form of bufg). I am using vcs and the
clkdlle.v model revision is 1.4.20.2.

Thanks,

Article: 34309
Subject: Re: Spartan2 5V PCI IO
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Mon, 20 Aug 2001 16:21:02 +0100
Links: << >>  << T >>  << A >>

> Eric Crabill <eric.crabill@xilinx.com> wrote:
> > your design must have an individual TFD flop for each OFD.
> > If you instantiate them, it works great.  If you are using
> > a synthesis tool, you must code up the appropriate number
> > and then be sure to disable duplicate register merge or
> > whatever your favorite synthesis tool calls it...  Otherwise
> > it will tend to optimize all but one of them away, and the
> > packing will fail.

Also (maybe this is obvious), Virtex/VirtexE/SpartanII PCI designs
should use the 'magic' logic block, as discussed in various old
posts to this newsgroup.





Article: 34310
Subject: Xilinx XC18V PROM problem
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Mon, 20 Aug 2001 18:20:18 +0200
Links: << >>  << T >>  << A >>
Hi all
I've just finished a little PCB to replace an XC17S (DIP8) with an XC18V
(VQ44) but the whole thing doesn't work.
When I plug an XC17S100A in the socket, everything works fine but when I
put my adapter, either the clock won't run or /rst will remain low.
The JTAG part works fine, the PROM is programmed and verified so I think
it is correctly powered and soldered.
What am I doing wrong?
-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/

Article: 34311
Subject: Re: JTAG
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 20 Aug 2001 09:23:53 -0700
Links: << >>  << T >>  << A >>
Are you aware that all of Xilinx FPGAs since the XC4000 (1990) have
included a TAP controller, and give access to it inside the FPGA.
I am currently doing several designs, where after the FPGA is
configured, I use the JTAG system to read and write registers in
the FPGA.

If you really want to design it your self, it isn't that complex. The
schematic for it is included in the JTAG spec. It is about 100 gates
(and 6 ? FFs)

Philip


Philip

On Mon, 20 Aug 2001 10:54:33 +0200, "Hans" <hans@rohill.nl.nospam> wrote:
>Hello group!
>
>Does anyone know of a way to do JTAG TAP controller within FPGA?
>
>Gr, Hans
>

Philip Freidin
Fliptronics

Article: 34312
Subject: Re: Virtex-II and 5V devices
From: Kolja Sulimma <kolja@sulimma.de>
Date: Mon, 20 Aug 2001 18:23:59 +0200
Links: << >>  << T >>  << A >>


Marc Battyani wrote:

> "Andy Peters <andy [@] exponentmedia com >" <".> wrote
>
> > There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap.
> > Basically, they're the usual sort of buffer types: '245, '541, '573,
> > '573, '823.  They're in various logic families: LPT, FCT, etc.  See the
> > Pericom or IDT web sites for examples.  Look for devices that have 3.3V
> > power rails and are 5V tolerant.
>
> Yes, but I have not found small devices. Well in fact there are small
> devices (TVSOP48 for a X16 buffer) but they are still bigger than the device
> I want to connect to the Virtex-II. And I don't have enough room on the
> board to put them.

You could use the XC95XL family as buffers.
0.8mm pitch chip scale packaging gives you 19 buffers at 7x7 square mm, 58
buffers at 12x12 square mm and 96 buffers at 16x16 square mm. Thats a density of
2.5 to 3 sqaure mm per buffer. This is probably pretty close to what you can do
with resistor arrays.
Maybe you can find 0.5mm CSP  CPLDS?

Kolja Sulimma






Article: 34313
Subject: Re: Internal clock skew when using DLL
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 20 Aug 2001 09:38:11 -0700
Links: << >>  << T >>  << A >>
On Mon, 20 Aug 2001 13:56:51 +0100, Jonathan Bromley
<Jonathan.Bromley@doulos.com> wrote:
>AIUI people have designed "metastable-hardened" FFs:  naturally, no-one
>can avoid the extended clock-to-output delay that goes with 
>metastability, but it *is* possible, I think, to side-step the worst
>other effects:  oscillating outputs, runt pulses, all that kind of 
>junk.  Philips offered a "metastable hardened" FF in the 74F series
>some years ago (74F5074???) which claimed these properties IIRC.

You may want to have a look at the following:

   http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

where I go on at some length on the topic. The last section specifically
deals with the oscillation vs. delayed output, where I explain that masking
oscillation (and runts) as delayed clock-to-out is no fix at all. In my book
they are just as bad. The only place where inhibiting oscillations or
runts would have any effect would be if you were using the signal as
a clock, and that would be crazy.

>It may well be that these improvements were achieved at the cost
>of other performance figures - particularly clock-to-output delay 
>in the normal case when Tsu/Th are met - which are likely to be 
>much more important for FFs within a typical FPGA.

right, except I dont think they are improvements.

Philip Freidin

Philip Freidin
Fliptronics

Article: 34314
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 20 Aug 2001 10:15:44 -0700
Links: << >>  << T >>  << A >>


Eric Smith wrote:

>
> I appreciate the insight.  However, I'm still curious as to whether
> such things are likely to damage the chip.  I suppose the answer
> may depend on how many such circuits one manages to configure.

If you ( accidentally ) create a lot of internal oscillators or glitch
generators, these circuits will consume Icc, and thus heat up the chip.
But, by its nature, the local current is small, in the mA range. If total heat
is a problem, the current will be widely distributed, and thus benign.
You only have to worryabout chip temperature, not metal migration.
Put your fingertip on the package: If you can keep it there, the package surface
is below 65 degrees C, if it sizzles, it is above 100 degrees C.  Ouch!

Peter Alfke, Xilinx Applications



Article: 34315
Subject: Re: connected "not connect" pins on Xilinx
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 20 Aug 2001 10:24:31 -0700
Links: << >>  << T >>  << A >>
I checked with product engineering: These two pins are definitely unbonded, so
connecting them to anything you want is ok.
But in general, I would not recommend to connect something to pins labeled n.c.
It can cause you grief when you have to migrate the design to a larger part in
the same package. For that larger die, the pins may then not be n.c.
So the best interpretation is:
n.c. = not connected by Xilinx, and also n.c. = not to be connected on your
pc-board.

Peter Alfke, Xilinx Applications.
======================================
Hayden So wrote:

> Hi All,
>
> Anyone knows what will happen to the
> Xilinx Spartan2 if I have
> accidentally connected the "not
> connected" (e.g. P55, P56 on a
> PQ208) pins externally on the PCB?
>
> My PCB maker has actually connected
> all the pins that I marked as NC (no
> connection)...
>
> Thanks for any advice.
>
> Hayden


Article: 34316
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: "Bryan" <bryan@srccomp.com>
Date: Mon, 20 Aug 2001 12:05:29 -0600
Links: << >>  << T >>  << A >>
Just for fun I created a full loaded virtex-II 1000 part which toggled all
of the luts in the chip as fast as the routing would support.  It draws
about 10A of 1.5V for the core.  Kind of fun test, just don't leave it
plugged in very long.  This was in the 256 pin package.

Bryan


"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3B8145C0.3D5547D3@xilinx.com...
>
>
> Eric Smith wrote:
>
> >
> > I appreciate the insight.  However, I'm still curious as to whether
> > such things are likely to damage the chip.  I suppose the answer
> > may depend on how many such circuits one manages to configure.
>
> If you ( accidentally ) create a lot of internal oscillators or glitch
> generators, these circuits will consume Icc, and thus heat up the chip.
> But, by its nature, the local current is small, in the mA range. If total
heat
> is a problem, the current will be widely distributed, and thus benign.
> You only have to worryabout chip temperature, not metal migration.
> Put your fingertip on the package: If you can keep it there, the package
surface
> is below 65 degrees C, if it sizzles, it is above 100 degrees C.  Ouch!
>
> Peter Alfke, Xilinx Applications
>
>



Article: 34317
Subject: Re: Internal clock skew when using DLL
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 20 Aug 2001 23:11:52 +0200
Links: << >>  << T >>  << A >>
K.O schrieb:
> 
> >This is possible too. You can also drive your 2x Clock with falling
> >edges (in the HDL description)
> >Or drive it on the same edge and just insert a synchronizer (running on
> >the falling edge).
> 
> Please Falk could you tell me how to implement this synchronizer, i am
> interested in high speed design, or at least describe its function

It is simply a FF, that is running (in this case) on the opposite clock
edge. Lets say your 2x clock runs everything on the rising edge, as well
as the the 1x clock. Then just insert a FF between the 1x and 2x clock
domian which is clocked on the falling edge of the 2x clock. In our case
with the DLL working not so perfect,we have the 

half clock cycle of 2x clock - maximum skew - jitter - duty cycle error
of 2x clock

for timing budget. This means if this number is positiv under worst case
conditions, the design will work reliable.

In general, you use a FF to synchronize datas which are asynchronous to
the digital design by inserting a FF on this input. As long as the
asynchronous data is stable during the setup and hold time of the FF,
everything works fine.
But when the data is changing just in the moment the FF is clocked
(which is possible, because the data is asynchronm to your clock), the
output of this FF will not go into a stable state just like normal. It
will go metastable. This means, is takes some time to settle on a stable
state. This time is called resolution time. It depends on the FF
technology (manufacturing process). The older 4k series of Xilinx had
something like 2-3ns. This means, if you let the FF 2-3ns to settle, it
will settle stable with a probability of 1 failure in 1000 years. That
means, your decoding logic, following this FF need 2-3ns more time.
An example.
Lets say you have a design running at 333 MHz (3ns period). All decoding
logic between the FF of your design just needs has 3 ns propagation
delay. Now you need to synchronize asynchronous signals, requireing
additional 3ns of time. Now your slowest path is 6 ns, slowing down your
system to around 160 Mhz (6ns). How to slove this problem?
Simply insert a second FF close after the first synchronizing FF. Now
the synchonizing FF will settle within 3 ns, just right to be (now
synchronous) clocked in by the second FF. This second FF delivers the
formerly asynchronous syignal to the decoding logic of your design,
which can now utilize the full 3ns cycle time. The drawback of this
design is, that it takes 2 clock cycles for the asynchronous signal to
get to the logic (latency). But noting is perfect in this world ;-)

OK, this is a VERY simple and not fully correct description of
metastability of FFs. But I hope it gives a first impulse on thinking
about metastability. There are some application notes from various
companys (Xilinx, A**** and others ;-) about this topic.

-- 
MFG
Falk


Article: 34318
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 20 Aug 2001 22:20:57 GMT
Links: << >>  << T >>  << A >>
In a discussion something like:

>> Can a combinatorial loop cause hardware damage to a Virtex or Spartan-II?
>> I thought the only internal condition that was potentially damaging was
>> an internal driver conflict.  I thought logic like:
>> 
>>            --------------+-----------
>>           |              |
>>           |              |
>>           |     |\       |
>>            -----| >O-----
>>                 |/
>> 
>> would probably not work too well, but can it actually cause damage?

>The same paragraph on that page explains:
>    Resulting oscillations may cause widespread high frequency
>    switching and this may draw more power than your hardware was
>    designed to handle.

It would seem that the oscillations wouldn't be much faster than
the highest frequency that the device can run at.  I was once working
on a design in which a large fraction of the gates/ff would change
state each clock cycle.  Well, random would say 50% and it might have
done that.  I asked in this group, wondering if there would be any
Icc/heat related problems.  As far as I understood at the time
(XC4000 series days), and assuming ordinary free-air cooling, it would
be fine.  If it was 100% of the gates changing at twice the clock rate,
that would be four times the power, and it might get a little warmer.

The path through CLBs and routing to make an oscillator like that
shown should be long enough to keep the frequency relatively low,
compared to discrete logic.

-- glen

Article: 34319
Subject: Re: Slowing PCI for FPGA
From: "Joseph Oravec" <joey@sun.science.wayne.edu>
Date: Tue, 21 Aug 2001 00:41:22 GMT
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroom99.com> wrote in message
news:9lh1e7$hqi$1@slb6.atl.mindspring.net...
> There is really no reason you can not make 25MHz, much less 33MHz with
your
> FPGA...if you're in an appropriate part, and your logic is "correct".
>
> What part are you using, and what is causing your PCI interface to be so
> slow?  Please be very specific in this answer if you could, and I might be
> able to help you.

Sorry this took a few days to get back... My main news server wasn't getting
articles for some reason, so I had to switch servers. I'd still love some
comments! Here's some responses and updates:

- The goal is to prototype an ASIC in an FPGA. The extremely deep logic
causes a problem. Even with floorplanning and synthesis optimizations,
calculating an address pointer in half the cycle is trivial with ASIC gate
delays but very difficult with FPGA gate delays. With the design partitioned
across several virtexE 2000 -6 chips, even with floorplanning and synthesis
improvements, I can hardly get the design above 12-14 MHz which is not even
close to the 25 constraint.

- I appreciate other people's suggestions for using a builtin PCI core, but
the deep logic elsewhere is more of a problem which I can't get around.
Redesigning so PCIclk doesn't equal localbus clk would be a great idea, but
the workload is impractical for a prototype that just verifies the RTL code.
Therefore slowing down the PCIclk sounds much more attractive right now.

- Most machines seem to use some sort of clock chip (often Cypress) running
off a 14.3 oscillator. Swapping that seems like it would certainly cause
problems for the computer (dram, video, etc), correct? I'm not in modern
motherboard design so I'm not sure what would happen. I looked at the CPU
Cool program a little this afternoon. My primary computer wasn't supported
(no big deal), so in the mean time I checked some other datasheets. It
looked to me like most PLLs can easily adjust the CPU FSB, but keep the PCI
clock fixed which is still a prob.

Thanks for the ABIT suggestion, 15 MHz is much more realistic to reach on
fpga! Of course it's not as good as the 2.75 MHz that the $3000 DINI card
gets, but its hard to justify that much higher cost unless you design a lot
of PCI cards. Would be nice to spread the cash around for tools on other bus
technologies.

All that being said, any other comments or suggestions would be much
appreciated! I'd still love to solve this problem some way other than
waiting for $3000 to become available for that nice 2.75 MHz card. Thanks a
lot!

-joey



Article: 34320
(removed)


Article: 34321
Subject: Set up!
From: tonyz <zhaihj_0@hotmail.com>
Date: Mon, 20 Aug 2001 19:54:03 -0700
Links: << >>  << T >>  << A >>
How to resolve the problem that the virtex1000e can't set up after power up some times?

Article: 34322
Subject: Re: connected "not connect" pins on Xilinx
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Tue, 21 Aug 2001 06:51:38 +0100
Links: << >>  << T >>  << A >>


"Hayden So" <haydenso@yahoo.com> wrote in message
news:ee7207c.-1@WebX.sUN8CHnE...
> Hi All,
>
> Anyone knows what will happen to the
> Xilinx Spartan2 if I have
> accidentally connected the "not
> connected" (e.g. P55, P56 on a
> PQ208) pins externally on the PCB?
>
> My PCB maker has actually connected
> all the pins that I marked as NC (no
> connection)...

I don't think they are actually bonded to the chip. You could always check
this by measuring the resistance to ground (on an unmounted chip, of
course).


Leon
--
Leon Heller, G1HSM leon_heller@hotmail.con
http://www.geocities.com/leon_heller
Low-cost Altera Flex design kit: http://www.leonheller.com




Article: 34323
Subject: Re: Slowing PCI for FPGA
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 21 Aug 2001 08:18:58 +0100
Links: << >>  << T >>  << A >>


Joseph Oravec wrote:

> "Austin Franklin" <austin@darkroom99.com> wrote in message
> news:9lh1e7$hqi$1@slb6.atl.mindspring.net...
> > There is really no reason you can not make 25MHz, much less 33MHz with
> your
> > FPGA...if you're in an appropriate part, and your logic is "correct".
> >
> > What part are you using, and what is causing your PCI interface to be so
> > slow?  Please be very specific in this answer if you could, and I might be
> > able to help you.
>
> Sorry this took a few days to get back... My main news server wasn't getting
> articles for some reason, so I had to switch servers. I'd still love some
> comments! Here's some responses and updates:
>
> - The goal is to prototype an ASIC in an FPGA. The extremely deep logic
> causes a problem. Even with floorplanning and synthesis optimizations,
> calculating an address pointer in half the cycle is trivial with ASIC gate
> delays but very difficult with FPGA gate delays. With the design partitioned
> across several virtexE 2000 -6 chips, even with floorplanning and synthesis
> improvements, I can hardly get the design above 12-14 MHz which is not even
> close to the 25 constraint.
>

I'm with Austin on this. It *is* possible to get a Virtex-E to meet 33MHz PCI
timing. I was in a similar position ~2.5 years ago when (1) I had to proto a PCI
i/f destined, ultimately, for an ASIC and (2) a bought in IP solution was not
acceptable to the client.

I never quite got the all-important 7nsec Tsu but the proto board ran quite
happily at the 8-8.5nsec I could achieve with a -4 (non-E) Virtex. It wasn't
easy since this was in the days of Xilinx's "who needs a Floorplanner for
Virtex" so it had to be done with some very careful coding & attention so what
the synth tool was doing. Migrating to the -6 E parts & all the hard work paid
off since Tsu is now comfortably  ~6ns, with some floorplanning I could get it
down to 5nsec if need be.

The basic trick I discovered (although I'm not claiming any originality) is to
strip the master/target core statemachines down to the absolute minimum and
"offline" everything that doesn't absolutely *have* to be driven direct out of
them [6/5 states resp.]. Only these core machines + the outgoing data pipe
control should use the raw, unregistered, PCI signals as inputs.

One question I might ask is what Synth tool are you using ? We use Synplify.




Article: 34324
(removed)




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
2017JanFebMarApr2017

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