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 25125

Article: 25125
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Sat, 26 Aug 2000 17:59:29 -0700
Links: << >>  << T >>  << A >>
On Sat, 26 Aug 2000 22:18:33 GMT, daniel_elftmann@my-deja.com wrote:

>In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>,
>  Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:
>> Hi -
>>
>> Technical issues aside, I'd be curious about just how much demand
>> there'd be for an anti-fuse part that's as large as the biggest Xilinx
>> and Altera SRAM parts.  Although a good economic argument might be
>> made for using such parts, the cringe factor in throwing away
>> expensive parts during debug is not to be underestimated (the cost of
>> removing/replacing them is a good point, too).  Sure, it's cheaper
>> than spinning an ASIC.  But with an ASIC, at least you get a low
>> recurring cost.
>
>Low recurring cost?  Only if you can get an ASIC vendor to give you a
>significant break on the NRE.

Are we talking about the same thing?  Recurring cost and non-recurring
cost are mutually exclusive, by definition.  I assume you're talking
about something akin to effective cost per unit, which is recurring
cost plus the NRE divided by total number of units.

Bob Perlman

Article: 25126
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: rk <stellare@nospamplease.erols.com>
Date: Sat, 26 Aug 2000 21:30:35 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:

           < snip >

> Interesting, so there is a bundle of latch/shift elements 'behind' the
> user
> resource. ( does nudge the die area up towards RAM designs, but you can
> read a cell in a lot fewer latch elements than needed to configure it )
>
> Is this access Read only, or can you Read/Write ?
>
> Can you address READ the elements in any way, or is it just
> a very-long-bitstream ?

In the Actel devices, there is a shift register that is used to command the
parts, and it's not terribly large.  An important part of the contents is
X-Y like addressing information for the two probe points.  Once the part, in
system, is given the proper command, the output of any logic module appears
at the probe point where you can clip on your scope or analyzer.  As Dan
mentioned, you get two probe points per part and these have no effect on
what you want to measure; that is, it doesn't effect either routing or
loading.  I would say it's more on the outside than "behind" the user
resources.

This is read only access.

Reading the modules can be done in any way and in any combination.  Each
time you shift in a new command it is independent of prior commands.

The application note in the data book I have doesn't appear to be on-line
(at least a quick look didn't find it).  I found this, which I skimmed,
which may be of interest:

http://www.actel.com/apps/guru/jul98/hc1708.html

Have a good evening,

rk

Article: 25127
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Sat, 26 Aug 2000 21:36:07 -0400
Links: << >>  << T >>  << A >>
Hi Dan,

Thanks a lot.  This is something that we've asked for and it's nice to see that
it is being done.

And thanks for keeping us all informed in the newsgroup.

Now, being that there are a flurry of concurrent, antifuse threads going on (OK,
two), shall we start an RFD for comp.arch.fpga.antifuse?  :-)

Again, thanks.

Have a nice weekend,

rk

========================================================


Elftmann wrote:

> Rich,
>
> I was able to stop into the product engineering group at Actel this week to
> see how the metastability characterization was going.  I'm happy to report
> that the characterization has been completed for the .45u (MX), .35u(SX),
> .25u/.22u(SXA) and the RTSX devices.  This report is now in the hands of the
> marketing folks to turn it into an application note.  I will continue
> pushing on it to insure it is posted to the web site as soon as possible.
>
> "rk" <stellare@nospamplease.erols.com> wrote in message
> news:39A5D52C.3B54A8A7@nospamplease.erols.com...
> > Hal Murray wrote:
> >
> > > > [1] "Metastability Report for FPGAs," Quicklogic Data
> > > >     Book, 1994, pp. 523-526.
> > >             ^^^^
> > >
> > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
> > >                        ^^^^
> > >
> > > Ugh.  Maybe it's a conspiracy to make Xilinx look good.  :)
> >
> > While I am almost always a believer in conspiracy theories, I can't say
> > that I know of one here.  I just had some old books laying around the
> > study.  Now, I don't recall any of the newer books having any more
> > up to date information.  Perhaps Dan or John can chime in.
> >
> > I did try and hunt for more information on various www sites to update
> > things but couldn't find anything relevant.  Help, anyone?
> >
> > Have a nice evening,
> >
> > rk

Article: 25128
Subject: Re: Metastability and antifuze
From: "Elftmann" <elftmann@pacbell.net>
Date: Sat, 26 Aug 2000 19:01:36 -0700
Links: << >>  << T >>  << A >>
"rk" <stellare@nospamplease.erols.com> wrote in message
news:39A87087.C28E751@nospamplease.erols.com...
> Hi Dan,
>
> Thanks a lot.  This is something that we've asked for and it's nice to see
that
> it is being done.
>
> And thanks for keeping us all informed in the newsgroup.
>
> Now, being that there are a flurry of concurrent, antifuse threads going
on (OK,
> two), shall we start an RFD for comp.arch.fpga.antifuse?  :-)

Only if the SRAM guys get upset with us using some of there bandwidth :-)

And don't use that word "flurry" around a guy originally from the great
white north (MN).  I don't know why, but it brought back memories of dipping
Honeywell 10K gate arrays into liquid nitrogen; just to get a CPU running at
7ns.  What ever happened to the Supercomputer capital of the world?

>
> Again, thanks.
>
> Have a nice weekend,
>
> rk
>
> ========================================================
>
>
> Elftmann wrote:
>
> > Rich,
> >
> > I was able to stop into the product engineering group at Actel this week
to
> > see how the metastability characterization was going.  I'm happy to
report
> > that the characterization has been completed for the .45u (MX),
.35u(SX),
> > .25u/.22u(SXA) and the RTSX devices.  This report is now in the hands of
the
> > marketing folks to turn it into an application note.  I will continue
> > pushing on it to insure it is posted to the web site as soon as
possible.
> >
> > "rk" <stellare@nospamplease.erols.com> wrote in message
> > news:39A5D52C.3B54A8A7@nospamplease.erols.com...
> > > Hal Murray wrote:
> > >
> > > > > [1] "Metastability Report for FPGAs," Quicklogic Data
> > > > >     Book, 1994, pp. 523-526.
> > > >             ^^^^
> > > >
> > > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
> > > >                        ^^^^
> > > >
> > > > Ugh.  Maybe it's a conspiracy to make Xilinx look good.  :)
> > >
> > > While I am almost always a believer in conspiracy theories, I can't
say
> > > that I know of one here.  I just had some old books laying around the
> > > study.  Now, I don't recall any of the newer books having any more
> > > up to date information.  Perhaps Dan or John can chime in.
> > >
> > > I did try and hunt for more information on various www sites to update
> > > things but couldn't find anything relevant.  Help, anyone?
> > >
> > > Have a nice evening,
> > >
> > > rk
>
>


Article: 25129
Subject: Re: Balls!
From: Ray Andraka <ray@andraka.com>
Date: Sun, 27 Aug 2000 02:22:33 GMT
Links: << >>  << T >>  << A >>
I've had customers successfully use the BGA and FBGA packages on standard solder
coated boards.  I have gotten the impression that these are actually easier to
do than the fine pitch flat packs, with the only difficulty being that you can't
visually inspect.  I recommend you use a board house that has done them before. 
They should offer xray inspection which will find any defects.

John Larkin wrote:
> 
> Well, I want to do a really cool image-processing gadget, and I'll
> need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to
> send me a couple of sample Xilinx BGA parts. I showed them to my
> manufacturing people and actually escaped with my life.
> 
> So, if any of you have experience with BGAs, I'd appreciate some help:
> 
> 1. Is it necessary to go with gold-plated (or maybe bare copper) pads
> to ensure planarity? Anybody having success with regular FR-4,
> solder-coated SMOBC stuff?
> 
> 2. Assuming I send the boards out for assembly, I'd still like to
> verify that all the BGA soldering is intact. I could code up a special
> FPGA design to just configure the chip as a lot of I/O latches, and
> then run test patterns (from the uP that configures and supervises the
> FPGA). Clearly, I can detect shorts between pins this way. Any ideas
> on how to detect open ball-to-PCB solder joints?
> 
> 3. What sorts of PCB line/spacings are needed for something like a
> 460-ish pin 1.27 mm BGA?
> 
> 4. Any other advice or cautions?
> 
> Thanks,
> 
> John

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25130
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: "Elftmann" <elftmann@pacbell.net>
Date: Sat, 26 Aug 2000 19:29:13 -0700
Links: << >>  << T >>  << A >>
Bob,

You are right they are mutually exclusive.  But with sub-micron geometries,
the NRE costs are skyrocketing and it doesn't make sense to keep these two
mutually exclusive cost factors in different rooms, unless the NRE cost is
just a noise factor based on the volume.


"Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message
news:vgpgqs0uakgdfam0a3rceiojkke520qi4m@4ax.com...
> On Sat, 26 Aug 2000 22:18:33 GMT, daniel_elftmann@my-deja.com wrote:
>
> >In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>,
> >  Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:
> >> Hi -
> >>
> >> Technical issues aside, I'd be curious about just how much demand
> >> there'd be for an anti-fuse part that's as large as the biggest Xilinx
> >> and Altera SRAM parts.  Although a good economic argument might be
> >> made for using such parts, the cringe factor in throwing away
> >> expensive parts during debug is not to be underestimated (the cost of
> >> removing/replacing them is a good point, too).  Sure, it's cheaper
> >> than spinning an ASIC.  But with an ASIC, at least you get a low
> >> recurring cost.
> >
> >Low recurring cost?  Only if you can get an ASIC vendor to give you a
> >significant break on the NRE.
>
> Are we talking about the same thing?  Recurring cost and non-recurring
> cost are mutually exclusive, by definition.  I assume you're talking
> about something akin to effective cost per unit, which is recurring
> cost plus the NRE divided by total number of units.
>
> Bob Perlman
>
>


Article: 25131
Subject: Re: Metastability and antifuze
From: "Richard B. Katz" <rich.katz@nospamplease.gsfc.nasa.gov>
Date: Sat, 26 Aug 2000 22:29:55 -0400
Links: << >>  << T >>  << A >>
Elftmann wrote:

> "inertia" and "nervous", not exactly terms taught by the universities :<)
>
> Rather than try to oversimplify the topic of SEU or go way off topic, those
> interested can head to
> Rich Katz's web page which has a good collection of papers and data on SEU:
> http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening%20of%20Flip-Flops

-- Lurk mode off.

I see that the URL has some spaces in it (%20) and that doesn't work with all
systems.  I have updated this URL and several other bookmarks on that page and
will shortly clean up the rest of them.

Here is an updated URL:

  http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening_of_Flip-Flops

There are some good examples of the effects of "inertia" there, using custom
designed flip-flops to illustrate the point.

Sometimes more nervous or "faster" flip-flops perform better with respect to SEU
then "slower" flip-flops.  There are a couple of different factors that come
into play.

Regards,

Richard B. Katz
National Aeronautics and Space Administration

-- Lurk mode on.

=============================================

> "Peter Alfke" <palfke@earthlink.net> wrote in message
> news:39A02C19.20190222@earthlink.net...
> >
> >
> > Elftmann wrote:
> >
> > > Peter,
> > >
> > > The A40MX02 and A40MX04 devices still require the master/slave latch
> > > implementation, we call these CC-Flops.  While the A40MX family is not a
> > > qualified space environment device, it is interesting to note that the
> > > CC-Flops have traditionally had better "Single Event Upset" SEU
> > > characteristics versus the "hard-coded" flops in the RH1280 (same
> > > architecture as A42MX).
> >
> > I believe that. SEU-tolerance gets better when there is a lot of "inertia"
> in
> > the latch, while fast metastable recovery needs a "nervous", very fast
> > feedback loop.
> >
> > Peter Alfke
> >
> >

Article: 25132
Subject: Re: "generate" and instance name indexes in Synopsys
From: "Mikhail Matusov" <matusov@ANNTIsquarepegSPPAMM.ca>
Date: Sun, 27 Aug 2000 05:50:05 GMT
Links: << >>  << T >>  << A >>
I had the same problem as Jens did and I had the labels. In fact Synopsys
will not compile without them so I think Jens simply missed them while
posting. Unfortunately, I was not able to find a solution so I had to unwrap
all my nice constructs into huge amount of repetitive code.

Does anyone know what is going on here? Generate statement is pretty much
useless when it works like that!

Mikhail


Mike Treseler <mike.treseler@flukenetworks.com> wrote in message
news:39A6C0CE.DC04BD84@flukenetworks.com...
> Jens Hildebrandt wrote:
>
> > I have a problem with the names Synopsys_1999.10 uses for multiple
> > instances of a component created using the VHDL "generate" construct.
> > For instance, when using a construct like
> >
> > for i in 0 to 7 generate
> >   instance_name: component_name port map (
> >                                         ...
> >                                           );
> > end generate;
>
>
> You need a label.
>
> It should have been a syntax error without one.
>
>
> MY_LABEL:for i in 0 to 7 generate
> ...
> end generate MY_LABEL;
>
>
>
> --    mike.treseler@flukenetworks.com or
> --             tres@tc.fluke.com


Article: 25133
Subject: Re: Balls!
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 27 Aug 2000 18:06:27 +1200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> I recommend you use a board house that has done them before.
> They should offer xray inspection which will find any defects.

 Can anyone comment on what happens when you X-ray inspect a
factory, or pre- programmed EPLD in BGA ?
 ie is the XRay enough to erase ( or reduce the margin) of the 
FLASH cells ?

-jg
Article: 25134
Subject: Re: Non-disclosures in job interviews, Round Two
From: Jerry Avins <jya@ieee.org>
Date: Sun, 27 Aug 2000 12:05:38 -0400
Links: << >>  << T >>  << A >>
Neil Nelson wrote:
> 
  ...
> I am here.
> I have not bailed out.
> 
> Regards,
> 
> Neil Nelson

Bail out! Chris clearly doesn't want to finger the perpetrator. Thank
him for the advance notice and move on.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Article: 25135
Subject: Re: Non-disclosures in job interviews, Round Two
From: Neil Nelson <n_nelson@pacbell.net>
Date: Sun, 27 Aug 2000 10:20:40 -0700
Links: << >>  << T >>  << A >>
Jerry Avins wrote:

> Neil Nelson wrote:
> >
>   ...
> > I am here.
> > I have not bailed out.
> >
> > Regards,
> >
> > Neil Nelson
>
> Bail out! Chris clearly doesn't want to finger the perpetrator. Thank
> him for the advance notice and move on.

I did not object to Chris' reasons as to why he would not give any
names.  He asked, rather determinedly, why I felt names were important.
I had, in my post previous to the one quoted, attempted to move on.

Regards,

Neil Nelson

Article: 25136
Subject: Re: Why Aren't Anti-Fuse FPGAs The Biggest FPGAs In The World?
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 27 Aug 2000 20:34:25 GMT
Links: << >>  << T >>  << A >>
Daniel,
     I am glad that you admitted that you are an Actel FAE!  We need more
vendor representation here than just Peter Alfke!
     Now we have Peter (Xilinx) and Daniel (Actel).  Are there any others?
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


Sent By Daniel Eltmann on comp.arch.fpga:
     The logic modules in the Actel antifuse devices are all tested via
     dedicated circuitry, which designers can also utilize for real time
     debug.  Designers can access internal nodes in the device after
     programming via the Silicon Explorer tool without having to further
     program the device.  Silicon Explorer has saved the day in many cases
     in my personal experience as an Actel FAE.  All Actel antifuse devices
     offer two probe pins.  Via these probe pins the output of all logic
     modules can be observed at the probe pins.  When needed for user I/O
     these two probe pins can also be used in the customers design.  This
     same circuitry is utilized during the testing of un-programmed devices
     to guarantee 100% functionality of the modules in the device prior to
     shipment of the blank devices


Article: 25137
Subject: FPGA power pins decoupling <-> PCB autorouting
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Mon, 28 Aug 2000 01:10:41 +0400
Links: << >>  << T >>  << A >>
Dear colleagues,

   Could you please share experience on auto-routing
PCB's with large FPGA packages (PQFP, BGA).

The problem I encountered:
there is no way to tell PCB autorouter, that it should connect each power
pin with appropriate decoupling capacitor!
Instead, PCB autorouter tends to connect a group of power pins with a group
of decoupling capacitors  by a single wire. Of course, such connection
minimizes the wire length, but it makes all decoupling capacitors senseless
...

Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to
avoid improper connection with decoupling capacitors?

Are there any methods with commonly used PCB autorouters - to autoroute
power network with variable width traces?

Thanks,
   Alex Sherstuk
     sherstuk@iname.com



Article: 25138
Subject: Re: FPGA power pins decoupling <-> PCB autorouting
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 28 Aug 2000 09:43:15 +1200
Links: << >>  << T >>  << A >>
Alex Sherstuk wrote:
> 
> Dear colleagues,
> 
>    Could you please share experience on auto-routing
> PCB's with large FPGA packages (PQFP, BGA).
> 
> The problem I encountered:
> there is no way to tell PCB autorouter, that it should connect each power
> pin with appropriate decoupling capacitor!
> Instead, PCB autorouter tends to connect a group of power pins with a group
> of decoupling capacitors  by a single wire. Of course, such connection
> minimizes the wire length, but it makes all decoupling capacitors senseless
> ...
> 
> Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to
> avoid improper connection with decoupling capacitors?

Yes, you just place the Capacitors around the FPGA - most CPLD.FPGAs
have pin-pair
type arrangements, and if a Cap is placed close to this, you by nature
have a 
very low 'cost' path to the Cap. ( this for QFP type packages )

If your autorouter is finding a shorter path somewhere else, you
probably have the
CAPs placed non optimially.

 
> Are there any methods with commonly used PCB autorouters - to autoroute
> power network with variable width traces?

 Some Autorouters can neck-down the last segment(s), but with plane
PCB's the
plane stubs are normally very short.

-jg
Article: 25139
Subject: Re: FPGA power pins decoupling <-> PCB autorouting
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Sun, 27 Aug 2000 16:55:22 -0700
Links: << >>  << T >>  << A >>
On Mon, 28 Aug 2000 01:10:41 +0400, "Alex Sherstuk"
<sherstuk@iname.com> wrote:

Hi - 

The common widsom is that the best way to connect bypass capacitors to
chips is to run very short traces between the capacitors and the power
and ground pins of the chip being bypassed.  Unfortunately, the
inductance of such an interconnect often greatly reduces or outright
eliminates the effectiveness of the capacitor.

For a while now, many people in the signal integrity world have been
suggesting a different approach: sink vias directly from the capacitor
pads to the power and ground planes; do the same for the chip power
and ground pins, of course.  If done carefully, this creates a very
low inductance path.  I've worked on large, fast boards where this
approach was used (we couldn't get vias in the bypass cap pads, but
used short, thick traces to the vias instead); the Vcc and ground
planes were quite clean.

But don't take my word for it.  Read the following paper by the folks
at Sun:

ftp://ftp.qsl.net/pub/wb6tpu/si_documents/epep-98.pdf

Take care,
Bob Perlman


>Dear colleagues,
>
>   Could you please share experience on auto-routing
>PCB's with large FPGA packages (PQFP, BGA).
>
>The problem I encountered:
>there is no way to tell PCB autorouter, that it should connect each power
>pin with appropriate decoupling capacitor!
>Instead, PCB autorouter tends to connect a group of power pins with a group
>of decoupling capacitors  by a single wire. Of course, such connection
>minimizes the wire length, but it makes all decoupling capacitors senseless
>...
>
>Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to
>avoid improper connection with decoupling capacitors?
>
>Are there any methods with commonly used PCB autorouters - to autoroute
>power network with variable width traces?
>
>Thanks,
>   Alex Sherstuk
>     sherstuk@iname.com
>
>

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 25140
Subject: Re: FPGA power pins decoupling <-> PCB autorouting
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sun, 27 Aug 2000 18:36:53 -0700
Links: << >>  << T >>  << A >>
On Mon, 28 Aug 2000 01:10:41 +0400, "Alex Sherstuk"
<sherstuk@iname.com> wrote:

>Dear colleagues,
>
>   Could you please share experience on auto-routing
>PCB's with large FPGA packages (PQFP, BGA).
>
>The problem I encountered:
>there is no way to tell PCB autorouter, that it should connect each power
>pin with appropriate decoupling capacitor!
>Instead, PCB autorouter tends to connect a group of power pins with a group
>of decoupling capacitors  by a single wire. Of course, such connection
>minimizes the wire length, but it makes all decoupling capacitors senseless
>...
>
>Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to
>avoid improper connection with decoupling capacitors?
>
>Are there any methods with commonly used PCB autorouters - to autoroute
>power network with variable width traces?
>
>Thanks,
>   Alex Sherstuk
>     sherstuk@iname.com
>
>

Hi,

what we do is make sure that there's a solid Vcc plane under the chip,
at least as big as the chip itself, with just a few (typically 4-8)
bypass caps per chip. The Vcc plane is ideally as big as the whole
PCB, but may have to be just an island on a multiple-voltage (split)
power plane. What's important is to minimize the spacing between the
power plane/island and the ground plane (3-5 mils is nice) to use the
plane as an area capacitor (or you can think of it as a very low-Z
transmission line). The plane capacitance handles the fast stuff, and
the discrete caps supply longer-term energy storage.

We've TDR'd such structures at 20 GHz bandwidth, and they look like
essentially ideal capacitors. It doesn't seem to matter much where you
place the discrete caps... just scatter them around.

John




Article: 25141
Subject: Re: Non-disclosures in job interviews, Round Two
From: Jerry Avins <jya@ieee.org>
Date: Sun, 27 Aug 2000 22:22:34 -0400
Links: << >>  << T >>  << A >>
Sorry. I evidently missed that. (I had stopped reading assiduously.)

Jerry

Neil Nelson wrote:
> 
> Jerry Avins wrote:
> 
> > Neil Nelson wrote:
> > >
> >   ...
> > > I am here.
> > > I have not bailed out.
> > >
> > > Regards,
> > >
> > > Neil Nelson
> >
> > Bail out! Chris clearly doesn't want to finger the perpetrator. Thank
> > him for the advance notice and move on.
> 
> I did not object to Chris' reasons as to why he would not give any
> names.  He asked, rather determinedly, why I felt names were important.
> I had, in my post previous to the one quoted, attempted to move on.
> 
> Regards,
> 
> Neil Nelson
Article: 25142
Subject: Re: Problem instantiating Xilinx primitives in FPGA Express
From: "disk" <personne@microsoft.com>
Date: Mon, 28 Aug 2000 08:55:40 +0200
Links: << >>  << T >>  << A >>
Hi,
As the error message said, the component LDCE uses ULOGIG type, so prefer :

component LDCE
 port (
 Q : out STD_ULOGIC;
 D : in   STD_ULOGIC;
...
);

That will be better.

Next, if you want to create latches, you have to prefer instanciate RAM
element used like latches more than a flip-flop...You can find more details
in Xilinx site, on topic : optimizing vhdl for Xilinx.

CU,
Paul

Bob Perlman <bobperl@best_no_spam_thanks.com> a écrit dans le message :
pgofqs0foh8qeit8ets319h171916svqi3@4ax.com...
> Hi -
>
> For reasons too complicated to explain, I temporarily took leave of my
> senses and agreed to synthesize a VHDL design in FPGA Express (I
> usually rely on Synplicity and Verilog).  Because FPGA Express has
> some problems with building latch enables sensibly, I decided to
> directly instantiate the latches, as follows:
>
> architecture RTL of mystery_module is
>
> component LDCE
>    port(
>       Q        : out   STD_LOGIC;
>       D        : in    STD_LOGIC;
>       G        : in    STD_LOGIC;
>       GE       : in    STD_LOGIC;
>       CLR      : in    STD_LOGIC);
> end component;
>   .
>   .
>   .
> begin
>   .
>   .
>   .
>     r_nw_latch: LDCE port map (Q => R_nW,
>                                D  => io_dr,
>                                G => iosd_set,
>                                GE => r_nw_latch_ge,
>                                CLR => r_nw_clr);
>
> All of my signals are declared std_logic.
>
> When I run "update," the line with the LDCE instantiation throws error
> VSS-543 (Actual designator not of correct type - STD_ULOGIC expected).
>
> Here's where I get confused.  Absolutely every direct instantiation
> example I've encountered in the Xilinx documents suggests that modules
> for primitives use data types std_logic and std_logic_vector; that's
> why I declared the component as I did.  However, when I look in
> Xilinx's VHDL-related unisim files--unisim_VCOMP.vhd and
> unisim_VPKG.vhd--it appears as if the LDCEs in those files expect
> input and output types STD_ULOGIC.   (I'm not including these files in
> my compiles; I just used them as a reference.)
>
> Can someone tell me what I'm doing wrong?
>
> Thanks,
> Bob Perlman
>
>
>
>


Article: 25143
Subject: Guide revision in 2.1i
From: Alexandr V Shuvalov <a_shuvalov@mail.ru>
Date: Mon, 28 Aug 2000 16:31:22 +0400
Links: << >>  << T >>  << A >>
Hellow!

 I've encountered with the following problem: I try to set a guide
revision in the Xilinx Foundation 2.1i. It leads to "windows general
protection fault".I tried to do it in the Xilinx Foundation 1.4 and
there was the same problem.
Does anybody use this option, and does anybody know about the problem?
Please explane me how to workaround it.

Thanks.
                                                           Alexandr.




Article: 25144
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: dan.hopper-N0SPAM@N0SPAM.ericsson.com (Dan Hopper)
Date: 28 Aug 2000 15:27:26 GMT
Links: << >>  << T >>  << A >>
On Wed, 23 Aug 2000 08:26:45 -0600, David Kessner <davidk@free-ip.com> wrote:
>I've seen multiple problems with 3.1i that I'm still trying to sort
>out.  Some of the problems are:
>
>	- FF's not being put into IOB's when F2.1i successfully put 
>	  them there (Spartan-II).  This was not fixed with SP2.

Also, 3.1i was supposed to address the issue of tristate FFs not
being placed in IOBs as directed.  It doesn't, unfortunately.

Dan
Article: 25145
Subject: Re: availability of Spartan II
From: Duane <junkmail@junkmail.com>
Date: Mon, 28 Aug 2000 11:12:31 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Simon is of course right, in general. But Spartan-II is a special case:
> It is derived from "good old Virtex", which has been around for well over a
> year.
> From a software point ov view, there is no big difference. The speedsfile
> numbers differ, there is no temp-measuring diode in Spartan-II, and, perhaps
> most importantly for your projects, the packages differ. And Spartan-II extends
> the Virtex family downwards to '30 and '15, devices that will never exist in
> Virtex.
> "Besides that..." there is no difference. So you can definitely start the
> software portion of your design without any worry. I have tried to get a
> realistic availability answer out of Spartan marketing. Let's see.
> 
> Peter Alfke, Xilinx Applications

Just a little nudge. Were you still trying to get a realistic
availability answer? I at the very least am very interested in the
answer.

--
My real email is akamail.com@dclark (or something like that).
Article: 25146
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: Bret Wade <bret.wade@xilinx.com>
Date: Mon, 28 Aug 2000 12:52:00 -0600
Links: << >>  << T >>  << A >>
Hello Dan,

I know of no Map problems involving the packing of tristate FFs into Virtex IOBs
and have just successfully tested this functionality. Could this be a problem
with the front end tool not passing IOB constraints as in Xilinx Answer #9071?

If instead you are speaking of 4KXLA IOBs, then this is a known issue. There are
currently no plans for the mapper to support the tristate FFs in the 4KXLA IOBs.
If there is some documentation that states otherwise, please point me to it and
I'll see that it is corrected. See Xilinx Answer #5140 for a work around to the
Map limitation.

Regards,
Bret Wade
Xilinx Product Applications

Dan Hopper wrote:

> On Wed, 23 Aug 2000 08:26:45 -0600, David Kessner <davidk@free-ip.com> wrote:
> >I've seen multiple problems with 3.1i that I'm still trying to sort
> >out.  Some of the problems are:
> >
> >       - FF's not being put into IOB's when F2.1i successfully put
> >         them there (Spartan-II).  This was not fixed with SP2.
>
> Also, 3.1i was supposed to address the issue of tristate FFs not
> being placed in IOBs as directed.  It doesn't, unfortunately.
>
> Dan

Article: 25147
Subject: Re: Xilinx 3.1i ISE
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Mon, 28 Aug 2000 12:29:19 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> "K. Orthner" wrote:
> 
> > I've received my copy of the Xilinx 3.1i software, and installed it this
> > morning.
> >
> > It seems to me that it doesn't support multiple entities in a single file!
> > I just want to check to see if anyone's run into the same thing.  This is
> > what I did:
> >
> > 1. Installed it.
> > 2. Created new project (Since it doesn't seem to read 2.1i projects)
> > 3. Added all my source files from an old project.  this includes "Ram.vhd",
> > which has a bunch'o'entities for different RAM constructs.
> > 4. Looked at the "Modules" window, where I found only the last entity in
> > any given file was displayed.
> 
> You are getting the "default configuration" for the
> last entity/architecture in the file. This is a VHDL rule.
> 
> You need to write and compile specific configurations for
> the specific entity/arch combinations you want to use.
> Then you can put everything in one file if you like.
> 
> Otherwise, you need separate files for each default configuration.

'cept FPGA Expess doesn't know about configurations (boo, hiss), so he's
stuck.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25148
Subject: Re: Large amout of Interconnect between FPGAs
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Mon, 28 Aug 2000 12:34:49 -0700
Links: << >>  << T >>  << A >>
Steven DeLong wrote:
> 
> I have an application that requires the connection of a large amount of
> I/O between multiple FPGAs on a single PCB. The application requires one
> type of device to fan in/out to 8 each of a second type of device. Each
> connection requires about 6.4 Gbit of bandwidth in each direction.
> 
> One connection scheme could use two 32 bit buses (one bus in each
> direction) between each of the eight devices and the one device. The bus
> bits would each run at 200 Mb/s. That's 64 single ended
> drivers/receivers on each of the eight devices and 512 single ended
> drivers/receivers on the other device.
> 
> Does anyone have any experience with anything similar to the above
> and/or large amounts of high-speed interconnect between chips? What type
> of I/O was used (LVTTL, LVDS, HSTTL, etc.) What, if any type of
> terminations were used? Any other suggestions?
> 
> I would like to avoid external terminations and reduce as much as
> possible the number of physical routes between the devices because of
> PCB real estate limitations.

Wow.  Lots of routes.  Do yourself a big favor and get a copy of
Hyperlynx BoardSim, or some other post-layout PCB simulation tool.  That
way, you'll have some idea what the board is doing to you before you
build it.  Given good IBIS models for your FPGAs (and the Xilinx ones
work well), the simulation should be accurate.

You probably won't be able to discard the terminations.  You should
check out http://www.signalintegrity.com/ and the mailing list there for
more help.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25149
Subject: Re: make for design flow (was: Deterministic FPGA routing?)
From: com@mail.cmautner (Christian Mautner)
Date: Mon, 28 Aug 2000 22:23:41 +0200
Links: << >>  << T >>  << A >>
On Fri, 25 Aug 2000 09:14:49 +0200, Andreas Doering wrote:
>Hal Murray wrote:
>> 
>> > Please, Altera and Xilinx, never give up the command line interface to
>> > your tools.
>> 
>> I'd like to second that.  Good documentation is important too.
>> 
>> What I really want is something that cooperates with make.
>> Aside from all the options that I can specify on the command
>> line, I need to understand the sequence of steps to go through
>> and I need to know what files each step produces.
>> 
>> I consider the Makefile to be a critical part of the documentation.
>
>For larger designs "make" does not fit very well, unless you build 
>wrappers around the tools. It is very design specific what is 
>considered a severe problem (with the consequence, make should stop) 
>and what is ok. Just yesterday someone complaint that certain IOs
>were not put into the IOBs. Hence, the number of "IOB FFs" reported 
>by make is crucial for this design. The same number will be irrelevant
>for 
>other designs. 

Hm. wrapper is too big a word for that, I think. Something like

${DESIGN}.ncd ${DESIGN}.pad: map.ncd
	par -w -pl ${PLACER_EFFORT} -rl ${ROUTER_EFFORT} -d ${CLEANUP_PASSES} \
                map.ncd ${DESIGN}.ncd ${DESIGN}.pcf
	perl ./local_lint par.rpt

should actually do, local_lint being a perl script in the build directory that
checks anything you want it to (timing, IOB FF usage, you name it).

[rest of dreaming snipped (but shared - I'd love to see embedded perl there,
and NOT tcl)]

chm.

-- 
cmautner@  -  Christian Mautner
mail.com   -  Vienna/Austria/Europe


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