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

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

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

Custom Search

Messages from 77050

Article: 77050
Subject: Re: PLCC84
From: "Sandeep Kulkarni" <sandeep@insight.memec.co.in>
Date: Tue, 21 Dec 2004 10:12:58 +0530
Links: << >>  << T >>  << A >>
Hi,
    Older generation FPGA familes such as XC4000/5000 Spartan/XL have PC84
package but Webpack dosen't support those families.
If you are stuck on using those, you need a synthesis tool from synplicity
or mentor and use the ise classic for the design.
But new families like Spartan2/2E/3 with QFP packages would be a better bet.

Sandeep
"Jon Elson" <jmelson@artsci.wustl.edu> wrote in message
news:41C7375D.4080308@artsci.wustl.edu...
>
>
> Vadim Vaynerman wrote:
>
> >Sorry about that, I missclicked...
> >
> >My question is this: is there ANY Xilinx FPGA that comes in a PLCC84 or
PC84 package that is supported by the WebPck tools? I couldn't find that
package for Spartan II devices, only for CPLDs, and I really want to use an
FPGA. Any Ideas?
> >
> >
> I use the 5V XCS10PC84C.  I don't know if webpack supports it.  I use an
> old version
> of the Xilinx iSE tools which has support for the 5 V devices.  The
> older Foundation
> software also supported these.
>
> Jon
>



Article: 77051
Subject: Re: Memory Controller
From: "Sandeep Kulkarni" <sandeep@insight.memec.co.in>
Date: Tue, 21 Dec 2004 10:16:01 +0530
Links: << >>  << T >>  << A >>
Hello,

To keep it simple you can try using a dual port ram.
Xilinx advantage true dual port ram.

Sandeep
"Tommy Thorn" <foobar@nowhere.void> wrote in message
news:uj8yd.13718$_3.154971@typhoon.sonic.net...
> JTW wrote:
> > If I have two or more sections of logic in my FPGA that need to read and
write
>  > to the same memory, what is the typical/standard approach to control
who
>  > writes/reads when? Is there an example somewhere that I
>  > could look at?
>  > Thanks, JTW
>
> It's a problem more general than just memory, ie. you could be sharing
> other devices.  For the most general case you need some kind of
> interconnect structure and arbitration, like for example Avalon (offered
> by Altera) or WISHBONE (notably used by OpenCores, though I couldn't
> seem find a bus arbiter).
>
> Often however, you can use system specific knowledge to adopt a simpler
> solution, such as running the memory at twice the speed, using odd
> cycles for one device, and even for the other (rarely works for external
> memory though).
>
> Tommy



Article: 77052
Subject: PCI doubt
From: praveenkumar1979@rediffmail.com (praveen)
Date: 20 Dec 2004 23:26:19 -0800
Links: << >>  << T >>  << A >>
Shreyas,

Go through the book 
PCI SYSTEM ARCHITECTURE    by  TOM SHANLEY / DON ANDERSON 

Very good book....you will understand the whole PCI architecture.

Regards
Praveen

Article: 77053
Subject: Re: Programming Virtex II in slave select MAP mode?
From: "Sandeep Kulkarni" <sandeep@insight.memec.co.in>
Date: Tue, 21 Dec 2004 13:45:49 +0530
Links: << >>  << T >>  << A >>
Hello Kiran,
                    You might take a look at app. note Xapp502 to get clues
on how you can do this.
        The commands to load data into registers is embedded in the bit
file, the interface is straight forward.
Two things I would like to mention are:
1. Use bin file instead of bit file
2. Take caution on bit swapping.

Regards
Sandeep Kulkarni
"Kiran M" <kiran@fepis.com> wrote in message
news:1103385687.64ba849840fe6197fd9af706a6e98bcc@teranews...
> Hi everybody,
> I want to program a embedded microcontoller to load a
> configuration bitstream using the slave select MAP mode of virtex II.
> Are there any command words to be issued to commence programming or
> just read the bitstream byte by byte and write it into the select MAP
> data pins.



Article: 77054
Subject: Re: Using low-core-voltage devices in industrial applications
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 21 Dec 2004 21:35:24 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> eliben,
> 
> I was waiting for all responses to trickle in before wading in.
> 
> Why would any technology be less reliable?
> 
> Are you concerned about the robustness of the technology to overvoltages?
> 
> If this is the case, this is beyond the issue of reliability, it is an 
> issue of not liking the absolute maximum ratings, which have gotten 
> lower as the technolgy shrinks.
> 
> Again, this has nothing to do with reliability.

  In my experience, questions like this refer to operational reliability,
not device MTBF.

  So to answer the question in this context : Yes, a lower voltage device
has lower voltage margin, so it is less tolerant of the same ground noise.
  Even worse, from an industrial context, 90nm devices are faster,
so they can 'see' a spike older devices simply miss.

  Some semiconductor vendors graph pulse width / pulse amplitude
for disturbance limits, but I have not seen this for FPGA.

  Thus an industrial user is right to be cautious, and should include
field tests in the design.

  Arcing contacts : Relays, Motor brushes, contactors etc can easily
generate sub-ns wavefronts at hundreds of volts.

  You can run a spice simulation, to see how much coupling C is needed,
to generate (say) a 1V bounce in 10nH of trace inductance.
   A good practical noise generator is a relay that self-commutates, and 
switches mains.  Or Piezo gas lighters...

  -jg



Article: 77055
Subject: Re: Clock Synchronization
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Dec 2004 02:04:58 -0800
Links: << >>  << T >>  << A >>
Neil,
Try this http://www.fpga-faq.com/archives/59400.html#59400
Cheers, Syms.
"Neil" <logblog@gmail.com> wrote in message 
news:1103583946.091639.312550@c13g2000cwb.googlegroups.com...
>
> Not PLL, I am looking at various types of synchronization techniques
> for signals crossing clock boundaries.
>
> - Neil
> 



Article: 77056
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Dec 2004 02:23:34 -0800
Links: << >>  << T >>  << A >>
Hi Glen,
I'm being dense; why would it leave glitches through the routing? Once you 
cascade LUTs without the FFs it could, but the FF fed LUT's output, and 
hence the routing it subsequently feeds, should be glitch free. What am I 
missing?
Cheers, Syms.
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:cq82s3$6n3$1@gnus01.u.washington.edu...
>
> You mean put four FF's on the LUT inputs, instead of one on the
> output?   I suppose that reduces glitching inside the LUT (RAM),
> but it still leaves glitches through the routing.  Also, four
> FF's are likely to take more power than one.
>
> -- glen
> 



Article: 77057
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Dec 2004 02:32:05 -0800
Links: << >>  << T >>  << A >>
Hi Tim,
Thanks for the heads up. Googleing Mr. Trimberger's name, I found this EE 
times article:-

http://www.eet.com/semi/news/showArticle.jhtml?articleId=9900516&kc=2515
quote>

Xilinx has already taken the first steps to raise the awareness of power 
issues by disclosing a study on the hot spots in its latest Virtex 2 
architecture. In the paper, the company showed that 60 percent of the power 
consumption in the Virtex 2 family is from routing while logic and clocking 
account for 16 and 14 percent, respectively. Additionally, Xilinx found that 
the cluster of LUTs, flip-flops and other circuitry that make up its 
configurable-logic blocks take up 5.9 microwatts per MHz for a typical 
design. But this is just for "typical" designs; actual power consumption 
within the configurable logic blocks (CLBs) can change wildly depending on 
the switching activity. This can occur frequently in synchronous circuits, 
where the inputs to the LUTs come in at different times during the same 
clock cycle. This "glitching" effect could contribute up to 70 percent of 
the power dissipation in a CMOS circuit, whether it's an ASIC or FPGA.

<quote

Cheers, Syms.

"Tim" <tim@rockylogic.com.nooospam.com> wrote in message 
news:cq80ut$681$1$830fa79f@news.demon.co.uk...
> As I understand it (!) Stephen Trimberger (Xilinx and much
> distinguished previous work) presented a paper recently on
> this fairly recently.
>
> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:31qgosF3cc0s9U1@individual.net...
>> Hmm, that's very interesting. I wonder if the FPGA vendors have got their 
>> SLICEs back to front? I.e. the FFs should feed directly into the LUTs 
>> within the SLICEs, instead of the other way round that exists now. If it 
>> saved even 20% of the power, it'd be worth it. Instead of using all the 
>> FFs for pipelining, you use them to replicate signals within the SLICEs 
>> to prevent the glitchy power thing. Hmm, interesting indeed! Thanks Ray.
>> Cheers, Syms.
>
> 



Article: 77058
Subject: MAP failes after inserting ILA and ICON cores to the design
From: "ran" <ranshadmi@walla.co.il>
Date: 21 Dec 2004 06:26:17 -0800
Links: << >>  << T >>  << A >>
I am trying to use the chipscope pro version 6.3 (tried also 6.2 but
results were the same). While mapping the design, I get the following
error messages:

****************************************************
START HERE
****************************************************


...

Phase 1.1



The following components are involved in this logic:

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/3/i_yes_rpm/u_muxh/O

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/2/i_yes_rpm/u_muxh/O

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/0/i_yes_rpm/u_muxh/O

This situation can be resolved by fixing the following issue:



The structured logic could not be placed in the relative placement form

required.  This is due to the fact that the component

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O is already contained in an rpm that
will not

allow the logic to be placed in the legal form.





The following components are involved in this logic:

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/3/i_yes_rpm/u_muxh/O

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/2/i_yes_rpm/u_muxh/O

SLICE

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O

This situation can be resolved by fixing the following issue:



The structured logic could not be placed in the relative placement form

required.  This is due to the fact that the component

i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_

tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O is already contained in an rpm that
will not

allow the logic to be placed in the legal form.



Phase 1.1 (Checksum:a293af) REAL time: 39 secs



Phase 2.2

Pl_Group:: Id=3273 numComps=3 locked=FALSE active=FALSE
level=0

clientId=0

Comp = fifo_over_under_flow type = LUT numpins = 14

Comp = fifo_over_under_flow type = LUT numpins = 0

Comp = fifo_over_under_flow type = FF numpins = 0

.....................................

ERROR:Place:379 - Unable to place the following group for unknown
reason



LUT i_ila/i_no_d/u_ila/idata_24 (0, 0)

FF i_ila/i_no_d/u_ila/idata_24 (0, 1)

ERROR:Place:379 - Unable to place the following group for unknown
reason



LUT i_ila/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4
(0, 0)

FF i_ila/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4
(0, 1)

ERROR:Place:120 - There were not enough sites to place all selected
components

Phase 2.2 (Checksum:1312cfe) REAL time: 1 mins 39 secs



ERROR:Pack:1499 - The timing-driven packing phase encountered an error.



Mapping completed.

See MAP report file "gtw_map.mrp" for details.

Problem encountered during the packing phase.



Design Summary

--------------

Number of errors   :   4

Number of warnings :  10



Time spent in user mode   (CPU seconds) : 198.870s

Time spent in kernel mode (CPU seconds) : 1.970s

Total time                              : 3:21.43s

CPU utilisation (percentage)            : 99.7%

Times the process was swapped           : 0

Times of major page faults              : 6800

Times of minor page faults              : 233235

****************************************************
END HERE
****************************************************


After which the mapper failes. If I remove the "-timing" option of
the MAP, the mapper succeeds but the PAR failes (unrouted signals).
Any suggestions ?

Ran


Article: 77059
Subject: Re: Help with importing a comp. as a netlist, edk6.2i
From: Andi <00andi@web.de>
Date: Tue, 21 Dec 2004 06:29:36 -0800
Links: << >>  << T >>  << A >>
What is the error message. What is your directory structure in your working file. Where did you place the netlist?

Article: 77060
Subject: DSOCM BRAM I/F Controller
From: "Voxer" <wesley.mowat@baesystems.com>
Date: Tue, 21 Dec 2004 14:57:45 -0000
Links: << >>  << T >>  << A >>
I have read the literature on the the Xilinx DSOCM IF Controller but have a
question.

Does this piece of IP need to be connected to the DCR Bus in order to get at
the DCR
registers - currently in my EDK graphic I only have it attached to the BRAM
it controls
and straight into the PPC.

If not how do I access the DCR regs for this IP - I have tried mfdcr and
mtdcr before
from within my software but cannnot compile as there appears to be no ".obj"
for
them.

AM I being daft ?



Article: 77061
Subject: Re: Using low-core-voltage devices in industrial applications
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 21 Dec 2004 07:30:43 -0800
Links: << >>  << T >>  << A >>
Gary,

As I said in my post, if one follows the foundry rules, there is no 
reason why 90nm should not last at least as long as any earlier technology.

Heat is the enemy for all silicon devices, so keeping power dissipation 
down is always a good thing.

That is why we are quite happy with the advantages we gained from the 
triple oxide technology in V4:  half to 1/3 the leakage of other large 
90nm FPGAs, 40% the dynamic power of the 130 nm Xilinx V2 Pro (fabric), 
and no start up surges.

Austin

Gary Pace wrote:
> I use a Cyclone on a gate drive for a high power IGBT - a VERY noisy 
> environment. The precautions I took were :
> 
> - Convert I/O to/from 5v directly adjacent to the device. The higher voltage 
> signals then proceed around the PCB
> - Around the FPGA itself, create multiple ground/power planes - including 
> one on an external layer to serve as a shield
> - Make provision for additional shielding (i.e. copper planes mounted above 
> the FPGA sub-system) - didn't use this in the end.
> - Use an accurate linear reg. and set the internal voltage at the upper end 
> of the tolerance
> 
> I don't know which of these were important, but the device has performed 
> like a champ
> 
> I do have a concern concerning longevity (often much more important in 
> industrial stuff than commercial). This is to do with the stability of the 
> sub-micron geometries used in devices such as this. To alleviate these 
> concerns, I make sure it runs really cool. I don't know if anyone else can 
> comment on this concern.
> 
> Gary
> 
> <eliben@gmail.com> wrote in message 
> news:1103526760.055590.264630@z14g2000cwz.googlegroups.com...
> 
>>Hello,
>>
>>We're employing FPGAs in industrial conditions
>>(wide temperature range, noise). Currently we
>>are using ACEX1K. Some people are reluctant to
>>move to the new technologies (Stratix, Stratix II)
>>because of their low core voltage.
>>
>>Are there are articles about the reliability of
>>various FPGAs in industrial applications ? Any
>>information about the lower reliability of 1.8
>>and 1.5 volt core devices ?
>>
>>Tx
>>
> 
> 
> 

Article: 77062
Subject: Re: DSOCM BRAM I/F Controller
From: Andi <00andi@web.de>
Date: Tue, 21 Dec 2004 07:32:00 -0800
Links: << >>  << T >>  << A >>
You can connect the on port of the BRAM to the DSOCM interface of the ppc. That enables you to direcly read and write to the BRAM on one port. On the other port you can connect the BRAM to any other stuff µC or VHDL-process. I did not use the DCR registers. What do you plan to do with them?

Article: 77063
Subject: Re: Programming Virtex II in slave select MAP mode?
From: "johnp" <johnp3+nospam@probo.com>
Date: 21 Dec 2004 08:10:48 -0800
Links: << >>  << T >>  << A >>
Kiran -

There are no magic tricks to using the select map mode.
I've used it several times to allow downloading of
byte-wide data via a parallel port though some
level shifters into the FPGA.

The things to be aware of are:
a) make sure you have the 3 mode pins strapped
properly.
b) make sure you have the CS/ and RDWR pins properly
set.
c) you need to assert PGM/ pin to start and wait for
INIT/ to be released before sending data.
d) be careful about voltage levels - some signals
can't be 3.3V without some conditioning.

I've found notes on the web on the format of .bit files,
so my s/w uses those data files to download to the FPGA.
NOTE you can't just send the .bit file to the FPGA, there
is header info that needs to be stripped off.  Be aware
of bit ordering, each file format seems to treat MSB
or LSB first differently.

John Providenza


Sandeep Kulkarni wrote:
> Hello Kiran,
>                     You might take a look at app. note Xapp502 to get
clues
> on how you can do this.
>         The commands to load data into registers is embedded in the
bit
> file, the interface is straight forward.
> Two things I would like to mention are:
> 1. Use bin file instead of bit file
> 2. Take caution on bit swapping.
>
> Regards
> Sandeep Kulkarni
> "Kiran M" <kiran@fepis.com> wrote in message
> news:1103385687.64ba849840fe6197fd9af706a6e98bcc@teranews...
> > Hi everybody,
> > I want to program a embedded microcontoller to load a
> > configuration bitstream using the slave select MAP mode of virtex
II.
> > Are there any command words to be issued to commence programming or
> > just read the bitstream byte by byte and write it into the select
MAP
> > data pins.


Article: 77064
Subject: low cost Altera MAX II development kit with more I/O pins?
From: "vax, 9000" <vax9000@gmail.com>
Date: Tue, 21 Dec 2004 11:55:39 -0500
Links: << >>  << T >>  << A >>
Hi, group,
  I am looking for one piece of low cost alterma MAX II (EPM1270)
development kit. What I need is basically the chip mounted on a small board
with JTAG pins and almost all I/O pins available. The $150 Altera kit
provides only some 40+ I/O pins, with many features that I don't need. Does
such a kit exist? I'd expect lower cost than $150. $80(with shipping) is
OK, $50 is prefered. If you know of this product, please let me know.
Thanks.

vax, 9000

Article: 77065
Subject: Re: Clock Synchronization
From: "Peter" <peter@xilinx.com>
Date: 21 Dec 2004 09:32:01 -0800
Links: << >>  << T >>  << A >>
Look at the TechXclusives article
"Moving Data Across Asynchronous Clock Boundaries"

Click at

http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp
and scroll down to  7-10-2001

Peter Alfke


Article: 77066
Subject: Re: Using low-core-voltage devices in industrial applications
From: David Colson <dscolson@rcn.com>
Date: Tue, 21 Dec 2004 13:00:52 -0500
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Austin Lesea wrote:
> 
>> eliben,
>>
>> I was waiting for all responses to trickle in before wading in.
>>
>> Why would any technology be less reliable?
>>
>> Are you concerned about the robustness of the technology to overvoltages?
>>
>> If this is the case, this is beyond the issue of reliability, it is an 
>> issue of not liking the absolute maximum ratings, which have gotten 
>> lower as the technolgy shrinks.
>>
>> Again, this has nothing to do with reliability.
> 
> 
>  In my experience, questions like this refer to operational reliability,
> not device MTBF.
> 
>  So to answer the question in this context : Yes, a lower voltage device
> has lower voltage margin, so it is less tolerant of the same ground noise.
>  Even worse, from an industrial context, 90nm devices are faster,
> so they can 'see' a spike older devices simply miss.
> 
>  Some semiconductor vendors graph pulse width / pulse amplitude
> for disturbance limits, but I have not seen this for FPGA.
> 
>  Thus an industrial user is right to be cautious, and should include
> field tests in the design.
> 
>  Arcing contacts : Relays, Motor brushes, contactors etc can easily
> generate sub-ns wavefronts at hundreds of volts.
> 
>  You can run a spice simulation, to see how much coupling C is needed,
> to generate (say) a 1V bounce in 10nH of trace inductance.
>   A good practical noise generator is a relay that self-commutates, and 
> switches mains.  Or Piezo gas lighters...
> 
>  -jg
> 
> 
I always wondered about the volatile configuration memory getting 
corrupted. Any comments on that issue?

Article: 77067
Subject: Memory Controller
From: JTW <>
Date: Tue, 21 Dec 2004 10:23:38 -0800
Links: << >>  << T >>  << A >>
If I have two or more sections of logic in my FPGA that need to read and write to the same memory, what is the typical/standard approach to control who writes/reads when? Is there an example somewhere that I could look at? Thanks, JTW

Article: 77068
Subject: Re: Using low-core-voltage devices in industrial applications
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 21 Dec 2004 10:35:58 -0800
Links: << >>  << T >>  << A >>
David,

This issue is at least as old as the static configuration latches that 
are used to hold the configuration:

what will cause config bits to change?

In order to make FPGAs work (at all), one has to start with a very 
robust memory cell design.  NOT SRAM!

We use specially engineered (for the myriad of requirements we have) 
cross coupled CMOS latches.

They can be slow.

They can be heavily loaded (the more loads the better).

They must run at the highest internal voltage we have to be used to 
control the pass gates (also good for stability).

They must be immune to read disturb (as we can readback while operating).

They must be easy to write.

They must be very low leakage.

They must meet our SEU (soft error upset) reliability criteria.

If the power supply itself glitches, the POR (power on reset) circuit 
uses dummy memory cells to detect if they can be upset (selected sizes 
of loads to mimic the most sensitive memory cell).  So, if there is 
enough of a power supply glitch to flip a memory cell used for 
configuration, the POR will trip, and the device will reconfigure (as it 
lost it memory from the glitch).

How else can you flip those bits?

1) Place in nuclear reactor
2) Inject massive amounts of current into the substrate by excessive 
undershoot (as in many many amperes from a bunch of IOs switching at 
once -- exceeds the Latch up spec, but no latch up will occur, just 
de-programming)
3) exceeding the absolute maximum specifications in other ways we 
haven't dreamed of (yet)

Austin

Article: 77069
Subject: Re: making an fpga hot
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 21 Dec 2004 10:41:36 -0800
Links: << >>  << T >>  << A >>
I wrote:

 >>You mean put four FF's on the LUT inputs, instead of one on the
 >>output?   I suppose that reduces glitching inside the LUT (RAM),
 >>but it still leaves glitches through the routing.  Also, four
 >>FF's are likely to take more power than one.

Symon wrote:

> I'm being dense; why would it leave glitches through the routing? Once you 
> cascade LUTs without the FFs it could, but the FF fed LUT's output, and 
> hence the routing it subsequently feeds, should be glitch free. What am I 
> missing?

I didn't try to figure all possibilities, but it would be a rare
design that used a FF on each LUT output, so I would expect some
LUT without FF's on the inputs.   The arrival time will be different
for the different inputs, so there may (depending on logic) still be
glitches left.

I do agree, though, that for many designs it could greately reduce
glitches propagating through logic.  I have done designs with at most
two LUT between FF's, highly pipelined for high speed.

I do agree that it could be an interesting addition to FPGA
architecture, and you might want to patent it.  (If you do,
it will probably never get into any FPGA's though.)

-- glen


Article: 77070
Subject: Re: FIFO WREN RDEN and missing clock cycle
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 21 Dec 2004 11:09:30 -0800
Links: << >>  << T >>  << A >>
Hi Brad,

There is a FIFO overflow, I think. Let me explain wht I think I see:

When valid frame data is available (vframe_2 = '1'), you start saving data
on the rising edge of the line indicator (vline1 = '1' AND vline_2 = '0').
Once the second line starts, you start reading out the FIFO. If a frame has
H lines, you will have stored H lines, but only read out (H - 1)!

[ASCII graph, use fixed font]
           ______________________     ______________________
FRAME  ___/                      \___/                      \___
              __     __     __           __     __     __
LINE   ______/  \___/  \___/  \_________/  \___/  \___/  \______
              ___________________        ___________________
WRITE  ______/                   \______/                   \___
                     ____________               ____________
READ   _____________/            \_____________/            \___

The fix is to start reading out the FIFO at the same time as you start
writing it, except for the very first line that you store (because you have
to fill the FIFO with 1 line of data). You can use the same starting
condition, except that you have to check the FIFO for not being empty before
launching the reads. There are 2 possibilities to do this:
1) check the FIFO's empty flag
2) have a register that is reset along with the other registers and only set
by the write enable (less resources if the FIFO hasn't the empty flag by
default).

My next comment is on the robustness of your design: what happens when you
switch on the video source or when you reset your design while the source is
running? There is no reason you will start saving the data from the first
line in a frame: if you see the 3th line pulse in a frame first after reset,
the you will currently start storing there. The solution is to have an
additional enable register that is reset like the others and is set when
frame is low: as such, no line will be stored before you have seen frame
going low.

Combining my remarks should give you the following waves:

[ASCII graph, use fixed font]
       ___
RESET
\_____________________________________________________________________
       _______________     ______________________     ______________________
FRAME                 \___/                      \___/
\___
          __     __           __     __     __           __     __     __
LINE   __/  \___/  \_________/  \___/  \___/  \_________/  \___/  \___/
\______

________________________________________________________
FRMen+ ________________/
                              ___________________        ___________________
WRITE  ______________________/                   \______/
\___

_________________________________________________
nEMPT+ _______________________/
                                     ____________        ___________________
READ   _____________________________/            \______/
\___

Summarised:
  WRITE start at the first line of a frame
  READ  start at the first line of a frame that the FIFO is not empty

If you're still up to some comments: the delay of the signal driving the mux
of vin_3 and the "10101010" constant puzzles me: assuming 1 cycle delay
between fiforden and the data coming out of the FIFO, then vin_3 and
fifodout are nicely aligned. But you add 2 more delays in process v5 by
using video_bits_2. Is this what you need (you're shifting the decision 2
pixels)?
Likewise, when you're checking for the treshold of the lines (current - 2)
and (current - 3), did you consider the wrapping from the bottom line to top
line in the next frame?

Some very last suggestion: do you check the timing of your asynchronous
reset? Without a flipflop clocking this signal, you will have no control
over it and you risk all kind of trouble (meta-stability when violating
setup/recovery timing of the resetable flipflops, flipflops coming out of
reset in a different clock cycle). In an FPGA, it's safer to use a
synchronous reset and it won't cost you any more resources (see the FPGA
registers).

Kind regards,
Alvin.




Article: 77071
Subject: Re: Using low-core-voltage devices in industrial applications
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 22 Dec 2004 08:27:28 +1300
Links: << >>  << T >>  << A >>
David Colson wrote:
> Jim Granville wrote:
> 
>> Austin Lesea wrote:
>>
>>> eliben,
>>>
>>> I was waiting for all responses to trickle in before wading in.
>>>
>>> Why would any technology be less reliable?
>>>
>>> Are you concerned about the robustness of the technology to 
>>> overvoltages?
>>>
>>> If this is the case, this is beyond the issue of reliability, it is 
>>> an issue of not liking the absolute maximum ratings, which have 
>>> gotten lower as the technolgy shrinks.
>>>
>>> Again, this has nothing to do with reliability.
>>
>>
>>
>>  In my experience, questions like this refer to operational reliability,
>> not device MTBF.
>>
>>  So to answer the question in this context : Yes, a lower voltage device
>> has lower voltage margin, so it is less tolerant of the same ground 
>> noise.
>>  Even worse, from an industrial context, 90nm devices are faster,
>> so they can 'see' a spike older devices simply miss.
>>
>>  Some semiconductor vendors graph pulse width / pulse amplitude
>> for disturbance limits, but I have not seen this for FPGA.
>>
>>  Thus an industrial user is right to be cautious, and should include
>> field tests in the design.
>>
>>  Arcing contacts : Relays, Motor brushes, contactors etc can easily
>> generate sub-ns wavefronts at hundreds of volts.
>>
>>  You can run a spice simulation, to see how much coupling C is needed,
>> to generate (say) a 1V bounce in 10nH of trace inductance.
>>   A good practical noise generator is a relay that self-commutates, 
>> and switches mains.  Or Piezo gas lighters...
>>
>>  -jg
>>
>>
> I always wondered about the volatile configuration memory getting 
> corrupted. Any comments on that issue?

  There have been other threads on that. The config RAM is slower, and 
more immune to radiation upset, than the smaller/nimble logic.
  But it can still happen, so the mission critical systems usually have 
the ability to re-config.
-jg


Article: 77072
Subject: Re: low cost Altera MAX II development kit with more I/O pins?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Tue, 21 Dec 2004 19:30:51 -0000
Links: << >>  << T >>  << A >>
"vax, 9000" <vax9000@gmail.com> wrote in message 
news:cq9kds$334$1@charm.magnus.acs.ohio-state.edu...
> Hi, group,
>  I am looking for one piece of low cost alterma MAX II (EPM1270)
> development kit. What I need is basically the chip mounted on a small 
> board
> with JTAG pins and almost all I/O pins available. The $150 Altera kit
> provides only some 40+ I/O pins, with many features that I don't need. 
> Does
> such a kit exist? I'd expect lower cost than $150. $80(with shipping) is
> OK, $50 is prefered. If you know of this product, please let me know.

I'll design and make you one for $80, if you can supply me with a couple of 
the chips (one for me and one for you). They are only available by the tray 
(90 pcs), AFAIK.

Leon 



Article: 77073
Subject: Re: Using low-core-voltage devices in industrial applications
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 21 Dec 2004 11:56:32 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> writes:
> That is why we are quite happy with the advantages we gained from the
> triple oxide technology in V4:  half to 1/3 the leakage of other large
> 90nm FPGAs,

The "other large 90mm FPGAs" being Spartan 3?

> and no start up surges.

I thought Spartan 3 already had that?  If so, how is it a feature
of "triple oxide technology"?

Article: 77074
Subject: Re: Using low-core-voltage devices in industrial applications
From: David Colson <dscolson@rcn.com>
Date: Tue, 21 Dec 2004 16:39:38 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> David,
> 
> This issue is at least as old as the static configuration latches that 
> are used to hold the configuration:
> 
> what will cause config bits to change?
> 
> In order to make FPGAs work (at all), one has to start with a very 
> robust memory cell design.  NOT SRAM!
> 
> We use specially engineered (for the myriad of requirements we have) 
> cross coupled CMOS latches.
> 
> They can be slow.
> 
> They can be heavily loaded (the more loads the better).
> 
> They must run at the highest internal voltage we have to be used to 
> control the pass gates (also good for stability).
> 
> They must be immune to read disturb (as we can readback while operating).
> 
> They must be easy to write.
> 
> They must be very low leakage.
> 
> They must meet our SEU (soft error upset) reliability criteria.
> 
> If the power supply itself glitches, the POR (power on reset) circuit 
> uses dummy memory cells to detect if they can be upset (selected sizes 
> of loads to mimic the most sensitive memory cell).  So, if there is 
> enough of a power supply glitch to flip a memory cell used for 
> configuration, the POR will trip, and the device will reconfigure (as it 
> lost it memory from the glitch).
> 
> How else can you flip those bits?
> 
> 1) Place in nuclear reactor
> 2) Inject massive amounts of current into the substrate by excessive 
> undershoot (as in many many amperes from a bunch of IOs switching at 
> once -- exceeds the Latch up spec, but no latch up will occur, just 
> de-programming)
> 3) exceeding the absolute maximum specifications in other ways we 
> haven't dreamed of (yet)
> 
> Austin
Thanks for the info. Now I fell better. We are using Spartan II, IIe and 
IIIs in out brusless motor drives. Which have large voltage and current 
swings up to 340 volts and 18 amps, and only inches away form the FPGA!


Dave Colson



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

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

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

Custom Search