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 151275

Article: 151275
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Mar 2011 20:08:07 GMT
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

>On Mar 19, 10:03 am, "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
>wrote:
>> Hi all,
>>
>> I am speculating about starting an FPGA based project soon, which may need
>> to use RAM. So I'd like to leverage the (relative) abundance (and thus,
>> hopefully low price) of desktop (or laptop) PC memory modules for this
>> purpose - and I was wandering if the community had any comments or
>> suggestions.
>>
>> Primary points of interest are:
>>
>> * What is, in your opinion, the cheapest type of DIMM (desktop?) and
>> SO-DIMM (laptop?) modules currently available (2010-2011)? From a quick
>> scan, I can find
>> ** SO DIMM 200-PIN, 1x512 MB module (DDR2 SDRAM) 667 MHz
>> ** DIMM 240-PIN, 1x1GB module (DDR3 SDRAM) 1066 MHz
>> .. for approx the same price ( below 13 Euro per GB). I'm aware this may
>> be location dependent - but would the above represent the (currently)
>> cheapest/most abundant modules on the market? If not, what would you
>> consider cheapest/most abundant - and what would be a good reference
>> (website) to consult?
>>
>> * Do the PCB sockets for the diverse module types differ significantly in
>> price (maybe SO-DIMM sockets usually cost twice as much as DIMM?) Also, any
>> (negative) experiences in soldering any of these by hand?
>>
>> * When they say stuff like "DDR2 SO-DIMM memory modules commonly have clock
>> speeds from 200 MHz up to 800 MHz" (http://en.wikipedia.org/wiki/SO-DIMM),
>> I'd assume they talk of max frequencies - does that still mean, that I can
>> clock the modules with _less_ of a frequency (say 50 MHz)?
>>
>> * Given that, say, "DDR2 is neither forward nor backward compatible with
>> either DDR or DDR3" (http://en.wikipedia.org/wiki/DDR2_SDRAM), obviously
>> there is a need for dedicated hardware signaling interface for each type of
>> RAM. Is there something like a 'base interface' (say, maybe something like
>> SPI), which would be relatively easy to use, and that all RAM modules would
>> support (at the expense of reaching top speeds)?
>>
>> * Assuming that there (most likely) isn't such a 'base interface' for all
>> RAM types, what (of the currently cheapest and most available types of
>> modules) would you feel is easiest to learn to interface with?
>>
>> I'd also love to hear any other considerations in this type of usage that I
>> may have missed - as well as any links to tutorials/previous projects using
>> FPGA and these types of RAM for PCs..
>>
>> Looking forward to any responses - thanks in advance,
>> Cheers!
>
>
>Based on some of the questions you are asking, it appears that you are
>a newbie to working with DRAM.  Each version of DRAM has its own
>characteristics, always optimized for transfer speed.  SDRAM transfers
>one word on each clock cycle.  DDR SDRAM transfers two words on each
>clock cycle.  DDR2 transfers four words on each clock cycle and I
>don't know for sure, but I expect DDR3 transfers eight words on each
>clock cycle.  There are also electrical differences because typical

Wrong. All DDR memories transfer two words for each clock cycle.
Higher versions offer more facilities like on-die-termination, on chip
PLLs, higher speeds and lower voltages.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 151276
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: Gabor <gabor@alacron.com>
Date: Sat, 19 Mar 2011 14:03:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
Don't worry about compatibility between different
RAM types.  Your board will need to be re-designed
to change type.  First of all there are different
core voltages for each type.  Then if you use a
DIMM or SO-DIMM there are differences in the socket
keying.

One thing that would normally point to using
chips rather than SO-DIMM or DIMM is that the
cheapest FPGA families often don't support
DIMM memory.  This is true of Spartan 6 for
example.  So saving a few bucks on DIMM memory
may cost you big bucks going for a higher end
FPGA.  My only reason to go away from chip
memory would be that I need a very large amount
of memory (more than a couple of the densest
chips).

Finally the price sweet spot for memory is a
moving target.  I think right now your best
price per bit is still DDR2, but DDR3 should
take over soon enough.  That being said it
does you no good to decide on DDR3 until you
know your FPGA will support it at a reasonable
speed (watch out - all DDR families have relatively
high minimum operating frequencies).

-- Gabor

Article: 151277
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "scrts" <mailsoc@[remove@here]gmail.com>
Date: Sun, 20 Mar 2011 00:46:35 +0200
Links: << >>  << T >>  << A >>
> Hi,
>
> Yet another newbie question:
> Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or
> DVI output) using a Spartan-3 or -3E FPGA ?
>

I am also interested if SDRAM is sufficient for video streaming? E.g. 
Video-over-IP. 



Article: 151278
Subject: Re: NIOS II license?
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Sat, 19 Mar 2011 16:00:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Maybe you are using the "E"-version of Nios? This low performance-
version became "freeware" some time ago.

Regards,

Thomas

Article: 151279
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 20 Mar 2011 01:49:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
> On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

(snip)
>> It was at FPL1999 that someone presented this as a sidenote in a
>> presentation about some
>> other topic. They said they were able to damage Altera FPGAs by
>> instantiating ring counters.

(snip) 
> What you remember as a ring counter was probably a ring oscillator
> that was used to get a high frequency clock to drive the rest of the
> FPGA logic with a high toggle rate.  Without system level
> considerations and monitoring the power requirements could easily push
> the device into a thermal region that would damage the device.   The
> HDL and bitstream itself is perfectly valid, it is the thermal
> management that is to blame for the destruction.   The failure points
> would likely be wide spread through the device.

The designs that I am interested in have many signals changing
on average every other clock cycle, and clocked as fast as I can
get the design to run.  I have wondered when that will cause thermal
problems, such as requiring a heat sink.
 
> This failure mode isn't the same as a badly constructed bitstream
> violating DRC rules and creating device damage that would be difficult
> to detect as it may only exist at a few points within the device.

Well, a small ring oscillator would cause local heating, which 
may be enough to damage a small portion of the device.
 
> Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
> in the 7 Series families) have the ability to shutdown the device if
> the junction temperature exceeds user defined values.  This can be
> used to prevent this type of thermal damage, but it would not be able
> to prevent localized damage due to bad bitstreams.

That should work for heating over the whole array, but maybe not
good enough for a localized ring oscillator.

Though shouldn't DRC be able to detect ring oscillators?  
Is it that hard to do?

-- glen

Article: 151280
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sat, 19 Mar 2011 22:13:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 19, 6:49=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> > On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
> (snip)
>
> >> It was at FPL1999 that someone presented this as a sidenote in a
> >> presentation about some
> >> other topic. They said they were able to damage Altera FPGAs by
> >> instantiating ring counters.
>
> (snip)
>
> > What you remember as a ring counter was probably a ring oscillator
> > that was used to get a high frequency clock to drive the rest of the
> > FPGA logic with a high toggle rate. =A0Without system level
> > considerations and monitoring the power requirements could easily push
> > the device into a thermal region that would damage the device. =A0 The
> > HDL and bitstream itself is perfectly valid, it is the thermal
> > management that is to blame for the destruction. =A0 The failure points
> > would likely be wide spread through the device.
>
> The designs that I am interested in have many signals changing
> on average every other clock cycle, and clocked as fast as I can
> get the design to run. =A0I have wondered when that will cause thermal
> problems, such as requiring a heat sink.
>
> > This failure mode isn't the same as a badly constructed bitstream
> > violating DRC rules and creating device damage that would be difficult
> > to detect as it may only exist at a few points within the device.
>
> Well, a small ring oscillator would cause local heating, which
> may be enough to damage a small portion of the device.
>
> > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
> > in the 7 Series families) have the ability to shutdown the device if
> > the junction temperature exceeds user defined values. =A0This can be
> > used to prevent this type of thermal damage, but it would not be able
> > to prevent localized damage due to bad bitstreams.
>
> That should work for heating over the whole array, but maybe not
> good enough for a localized ring oscillator.
>
> Though shouldn't DRC be able to detect ring oscillators? =A0
> Is it that hard to do?
>
> -- glen

It sounds like you have a pretty aggressive design and if there is a
lot of logic in the design than it would be possible to exceed Tj
without a heat sink.  The Xilinx XPE (estimator) and XPA (analyzer)
can help you out with determining the expectated power and thermal
requirements.  See http://www.xilinx.com/power for more details.

I wouldn't be worried about a ring oscillator creating any significant
localized heating in an FPGA to the point that it would damage the
device.  Ring oscillator circuits are used extensively in the device
testing and I've never heard of an RMA linked to anything that even
remotely resembled damage due to localized Tj extremes.

If you do have ring oscillators in your design you will get some
warnings in the timing analysis, but otherwise they are permitted as
there isn't anything wrong with a ring oscillator.

Ed McGettigan
--
Xilinx Inc.

Article: 151281
Subject: Re: pcb&bitstream
From: rickman <gnuarm@gmail.com>
Date: Sat, 19 Mar 2011 23:17:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 19, 3:59=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
> > On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > > You can fry an FPGA with VDHL and vendor synthesis software.
> > > > This has been demonstrated at the FPL conference a decade ago.
>
> > > I am quite surprised about this. Can you provide any additional
> > > material on how this was achieved?
>
> > > There aren't any scenarios, other than internal tri-state contention,
> > > that I can come up with to make this happen with a proven tool chain.
>
> > It was at FPL1999 that someone presented this as a sidenote in a
> > presentation about some
> > other topic. They said they were able to damage Altera FPGAs by
> > instantiating ring counters.
> > This resulted in spontaneous applause by the Xilinx crowd in the
> > audience but the presenter
> > made clear that this attack also applies to Xilinx Fpgas and that it
> > is computationally infeasible
> > to detect such attacks.
>
> > I just browsed through the list of papers of that conferencehttp://www.=
informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html
> > but can't remember, which paper it was.
>
> > There were some prominent people from Xilinx present (Peter Alfke,
> > Steve Trimberger, Steve Guccione and some other Steve). Maybe one of
> > them remembers.
>
> > Kolja Sulimma
> > cronologic
>
> What you remember as a ring counter was probably a ring oscillator
> that was used to get a high frequency clock to drive the rest of the
> FPGA logic with a high toggle rate. =A0Without system level
> considerations and monitoring the power requirements could easily push
> the device into a thermal region that would damage the device. =A0 The
> HDL and bitstream itself is perfectly valid, it is the thermal
> management that is to blame for the destruction. =A0 The failure points
> would likely be wide spread through the device.
>
> This failure mode isn't the same as a badly constructed bitstream
> violating DRC rules and creating device damage that would be difficult
> to detect as it may only exist at a few points within the device.

Maybe I am not familiar with the damage you are referring to.  If you
send a badly constructed bit stream to a part that violates DRC rules,
how does it damage a part other than causing overheating?  Are you
saying that there exists configuration settings that do damage through
over voltage application to some feature in the chip?


> Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
> in the 7 Series families) have the ability to shutdown the device if
> the junction temperature exceeds user defined values. =A0This can be
> used to prevent this type of thermal damage, but it would not be able
> to prevent localized damage due to bad bitstreams.

Has Xilinx been able to cause this damage?

Rick

Article: 151282
Subject: Re: Alternative To Altera's Cyclone III Starter Board
From: Anssi Saari <as@sci.fi>
Date: Sun, 20 Mar 2011 09:13:07 +0200
Links: << >>  << T >>  << A >>
"Abby Brown" <abbybrown@charter.net> writes:

> Hi,
>
> Does someone produce a cheaper and simpler substitute for 
> Altera's Cyclone III starter board?  It needs to connect to a 
> laptop to download configuration and test cases and upload 
> results (ICT).  A driver that connects to Windows .Net would be 
> ideal.

Terasic makes a cheap Cyclone III board, model DE0. They have academic
pricing too if it's for school. Don't know anything about connecting
to .net though.

Article: 151283
Subject: Re: NIOS II license?
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 20 Mar 2011 10:23:41 +0100
Links: << >>  << T >>  << A >>
Thomas Entner wrote:

> Maybe you are using the "E"-version of Nios? This low performance-
> version became "freeware" some time ago.

Yes, it is the "E" version. Using the "S" or "F" version, it creates
encrypted VHDL. Thanks for the information, I missed it on the web,
because it was not on the NIOS II overview page, only a link to "Buy a
License", but on the detailed page for the Economy CPU it is written:

http://www.altera.com/products/ip/processors/nios2/cores/economy/ni2-economy-core.html

-- 
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Article: 151284
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 20 Mar 2011 03:36:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Using standard DIMMs or SODIMMs is good for cost but only for a
limited period until the next speed garde or type takes over in
popularity. The choice of vendors is good as well and these can be big
advantages over discrete memory chips. At the moment the memory of
choice is DDR3. Price per bit is best and density is also a big
winner. However some FPGA families cannot support this memory type and
your PCB design needs to be fairly good to run at these speeds.

Note that DDR2/3 do have minimum speeds if you are going to use DLL/
PLLs that they use internally. You may be operate them out of this
mode but I have never seen anyone do that and there will be very in
examples out there to reference.

There may be other things to consider. DIMMs and SODIMMs need a lot of
I/O to use them. Probably 80-100 depending on a few things. That can
impact the size of FPGA packacge you use and that is a cost as well if
you go up in package size because of it.

Hard memory cores are also another thing to consider. All of our
Spartan-6 based development boards have a x16 DDR3 on board and that's
because there is hard memory controller in the FPGA. That means we are
not using FPGA fabric for a memory controller that is in itself a
cost. The hard controller will have a cost that is advertised into the
FPGA cost but it will be a small fraction of the equivalent soft core
fabric approach. Big upside of the hard memory controller is that it
is relatively easy to get going. Note that the Spartan-6 controller
will only go to x16 data and won;t support a DIMM/SODIMM.

DIMM/SODIMM are different for each memory type. Usually there is a
different polarisation notch. Pinout and operating voltages are also
different.

For simplicity don't ignore conventional SDRAM. Personally if I don't
have a high performance, density, issue or even a hard controller
available this is my memory type of choice. No minimum frequency on
this either. I certainly won't bother with DDR1 and would only use
DDR2 things like Cyclone IV boards as we have done in our Raggedstone3
product because the DDR3 isn't really an option.

John Adair
Enterpoint Ltd. - Home of Merrick1. The cost effective HPC board.

On Mar 19, 2:03=A0pm, "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
wrote:
> Hi all,
>
> I am speculating about starting an FPGA based project soon, which may nee=
d
> to use RAM. So I'd like to leverage the (relative) abundance (and thus,
> hopefully low price) of desktop (or laptop) PC memory modules for this
> purpose - and I was wandering if the community had any comments or
> suggestions.
>
> Primary points of interest are:
>
> * What is, in your opinion, the cheapest type of DIMM (desktop?) and
> SO-DIMM (laptop?) modules currently available (2010-2011)? From a quick
> scan, I can find
> ** SO DIMM 200-PIN, 1x512 MB module (DDR2 SDRAM) 667 MHz
> ** DIMM 240-PIN, 1x1GB module (DDR3 SDRAM) 1066 MHz
> .. for approx the same price ( below 13 Euro per GB). I'm aware this may
> be location dependent - but would the above represent the (currently)
> cheapest/most abundant modules on the market? If not, what would you
> consider cheapest/most abundant - and what would be a good reference
> (website) to consult?
>
> * Do the PCB sockets for the diverse module types differ significantly in
> price (maybe SO-DIMM sockets usually cost twice as much as DIMM?) Also, a=
ny
> (negative) experiences in soldering any of these by hand?
>
> * When they say stuff like "DDR2 SO-DIMM memory modules commonly have clo=
ck
> speeds from 200 MHz up to 800 MHz" (http://en.wikipedia.org/wiki/SO-DIMM)=
,
> I'd assume they talk of max frequencies - does that still mean, that I ca=
n
> clock the modules with _less_ of a frequency (say 50 MHz)?
>
> * Given that, say, "DDR2 is neither forward nor backward compatible with
> either DDR or DDR3" (http://en.wikipedia.org/wiki/DDR2_SDRAM), obviously
> there is a need for dedicated hardware signaling interface for each type =
of
> RAM. Is there something like a 'base interface' (say, maybe something lik=
e
> SPI), which would be relatively easy to use, and that all RAM modules wou=
ld
> support (at the expense of reaching top speeds)?
>
> * Assuming that there (most likely) isn't such a 'base interface' for all
> RAM types, what (of the currently cheapest and most available types of
> modules) would you feel is easiest to learn to interface with?
>
> I'd also love to hear any other considerations in this type of usage that=
 I
> may have missed - as well as any links to tutorials/previous projects usi=
ng
> FPGA and these types of RAM for PCs..
>
> Looking forward to any responses - thanks in advance,
> Cheers!
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 151285
Subject: Re: Video Framebuffer using Nexys2 (Spartan-3E)
From: Joel Williams <nospamwhydontyoublogaboutit@nospamgmail.com>
Date: Mon, 21 Mar 2011 00:32:07 +1030
Links: << >>  << T >>  << A >>
> Hmmm...let me just recap to make sure I understand everything thus
> far. Okay, so the general strategy is to sequentially push/pull the
> data to/from DDR memory while using some BlockRAM to hold data
> between bursts.  Also, some logic will be needed to determine when
> would be the best time to switch between reading and writing.
> Normally, one would create a DDR memory controller using the MIG in
> Xilinx's Core Generator.  However, my board doesn't have a standard
> DDR memory module and instead has a PseudoSRAM (which the MIG doesn't
> support).  This particular external RAM has a mode that acts like
> asynchronous SRAM which is slow but easy to write a controller for.
> It also has a burst mode that acts like synchronous DRAM, which is
> fast but needs a more complicated controller.  All Digilent supplies
> you with is a VHDL module that probably doesn't even support burst
> mode.  I have a textbook that explains how to use the slow
> asynchronous mode, but of course that won't cut it.

All sounds right!

> Since I know nothing about VHDL (I'm a Verilog boy), should I even
> attempt learning VHDL to analyze the above sample code or should I
> just jump straight into writing it in Verilog from scratch?

It's been a few weeks since I looked at the module, but from memory it
wouldn't have been too difficult to convert it from VHDL to Verilog. I
would probably do this just so that I can attempt to understand what
it's doing, by analysing it line by line.

The OPB_PSRAM_CONTROLLER code looks quite a lot nicer, though you'd need 
to implement an OPB bus to use it without modification 
(http://www.xilinx.com/support/documentation/ipembedprocess_coreconnect_opbbusstruct.htm)

> If I were to create a VHDL controller based on the links above, can
> I even instantize a VHDL module from my Verilog top module?

Yes, there shouldn't be any problem doing that.

> Because I know nothing about DDR style memory controllers, is there
> anything else you guys can point me to for help in designing a burst
> mode controller from scratch (preferably more concepts than code)?
> Or am I just stuck with what that datasheet gives me?

I've never tried doing it, but the data sheet should hopefully tell you 
everything you need to do! :) Basically, work out what the sample code 
is doing and match it up to the data sheet. Then work out what you need 
to do differently for burst mode.

Joel


Article: 151286
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sun, 20 Mar 2011 10:16:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 19, 11:17=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 19, 3:59=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
> > > On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > > > You can fry an FPGA with VDHL and vendor synthesis software.
> > > > > This has been demonstrated at the FPL conference a decade ago.
>
> > > > I am quite surprised about this. Can you provide any additional
> > > > material on how this was achieved?
>
> > > > There aren't any scenarios, other than internal tri-state contentio=
n,
> > > > that I can come up with to make this happen with a proven tool chai=
n.
>
> > > It was at FPL1999 that someone presented this as a sidenote in a
> > > presentation about some
> > > other topic. They said they were able to damage Altera FPGAs by
> > > instantiating ring counters.
> > > This resulted in spontaneous applause by the Xilinx crowd in the
> > > audience but the presenter
> > > made clear that this attack also applies to Xilinx Fpgas and that it
> > > is computationally infeasible
> > > to detect such attacks.
>
> > > I just browsed through the list of papers of that conferencehttp://ww=
w.informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html
> > > but can't remember, which paper it was.
>
> > > There were some prominent people from Xilinx present (Peter Alfke,
> > > Steve Trimberger, Steve Guccione and some other Steve). Maybe one of
> > > them remembers.
>
> > > Kolja Sulimma
> > > cronologic
>
> > What you remember as a ring counter was probably a ring oscillator
> > that was used to get a high frequency clock to drive the rest of the
> > FPGA logic with a high toggle rate. =A0Without system level
> > considerations and monitoring the power requirements could easily push
> > the device into a thermal region that would damage the device. =A0 The
> > HDL and bitstream itself is perfectly valid, it is the thermal
> > management that is to blame for the destruction. =A0 The failure points
> > would likely be wide spread through the device.
>
> > This failure mode isn't the same as a badly constructed bitstream
> > violating DRC rules and creating device damage that would be difficult
> > to detect as it may only exist at a few points within the device.
>
> Maybe I am not familiar with the damage you are referring to. =A0If you
> send a badly constructed bit stream to a part that violates DRC rules,
> how does it damage a part other than causing overheating? =A0Are you
> saying that there exists configuration settings that do damage through
> over voltage application to some feature in the chip?
>
> > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
> > in the 7 Series families) have the ability to shutdown the device if
> > the junction temperature exceeds user defined values. =A0This can be
> > used to prevent this type of thermal damage, but it would not be able
> > to prevent localized damage due to bad bitstreams.
>
> Has Xilinx been able to cause this damage?
>
> Rick- Hide quoted text -
>
> - Show quoted text -

This is well off the original topic....

If "this damage" refers to localized thermal issues then not to the
best of my knowledge.  Hot spot (localized) thermal imaging analysis
is done on new parts to determine if any issues exist and occasionally
something in a hard block (PowerPC, BlockRAM, PCIe, etc) is found and
corrected in a mask step before production.

If "this damage" refers to exceeding the junction temperature then yes
this is a real issue and high temperatures with voltage will damage
the part.  This is a common technique used for device lifetime
reliability testing with both over voltage and over temperature
conditions used as acceleration factors to reduce the time required
for testing.

Ed McGettigan
--
Xilinx Inc.

Article: 151287
Subject: Re: pcb&bitstream
From: geobsd <geobsd.os@gmail.com>
Date: Sun, 20 Mar 2011 10:43:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 20, 6:16=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> This is well off the original topic....
not so far ed, you stated that bit-stream spec published will make bad
bit-streams in use and that will damage fpgas
so the discuss went on fpgas damages
and this is interesting !
so please continu all

Article: 151288
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Mon, 21 Mar 2011 15:11:54 +0100
Links: << >>  << T >>  << A >>
"PovTruffe" <PovTache@gaga.invalid> a écrit :
> Hi,
>
> Yet another newbie question:
> Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or
> DVI output) using a Spartan-3 or -3E FPGA ?

No response  :-((
Maybe my question was not very clear. Let me paraphrase it:
What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
Or would either type of RAM work ?



Article: 151289
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 21 Mar 2011 09:56:53 -0500
Links: << >>  << T >>  << A >>
>"PovTruffe" <PovTache@gaga.invalid> a �crit :
>> Hi,
>>
>> Yet another newbie question:
>> Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or
>> DVI output) using a Spartan-3 or -3E FPGA ?
>
>No response  :-((
>Maybe my question was not very clear. Let me paraphrase it:
>What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
>Or would either type of RAM work ?
>
>
>

For any application you must calculate what size and speed of ram you
require. So for your application you must determine the memory bandwidth
and the size of memory needed to fit the data into the memory. You know
what your application is and the relevan parameters so you just need to
match those to the standard ram available. You may find that it is not
possible to with the fpga you want to use and you need to choose a higher
spec device.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151290
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Mon, 21 Mar 2011 16:28:40 +0100
Links: << >>  << T >>  << A >>
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit :
>>No response  :-((
>>Maybe my question was not very clear. Let me paraphrase it:
>>What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
>>Or would either type of RAM work ?
>
> For any application you must calculate what size and speed of ram you
> require. So for your application you must determine the memory bandwidth
> and the size of memory needed to fit the data into the memory. You know
> what your application is and the relevan parameters so you just need to
> match those to the standard ram available. You may find that it is not
> possible to with the fpga you want to use and you need to choose a higher
> spec device.

Thank you for your response. However I was in fact expecting more a rule
of thumb response such as for example "SDRAM would probably work for
VGA resolution at 30Hz rate no more...".

I am still choosing the right components for my first FPGA design that is just
a learning project with no other specific purpose. If I can generate a video
stream thats fine, if not I will do something else (or lower the frame size,
refresh rate, etc).

The challenge is also to design a working Spartan-3 FPGA board with the
largest non BGA package and with only 2 layers. The risk of course is the
board will never work.



Article: 151291
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "Phil Jessop" <phil@noname.org>
Date: Mon, 21 Mar 2011 17:28:44 -0000
Links: << >>  << T >>  << A >>

"PovTruffe" <PovTache@gaga.invalid> wrote in message 
news:4d876ea8$0$19933$426a74cc@news.free.fr...
> "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit :
>>>No response  :-((
>>>Maybe my question was not very clear. Let me paraphrase it:
>>>What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
>>>Or would either type of RAM work ?
>>
>> For any application you must calculate what size and speed of ram you
>> require. So for your application you must determine the memory bandwidth
>> and the size of memory needed to fit the data into the memory. You know
>> what your application is and the relevan parameters so you just need to
>> match those to the standard ram available. You may find that it is not
>> possible to with the fpga you want to use and you need to choose a higher
>> spec device.
>
> Thank you for your response. However I was in fact expecting more a rule
> of thumb response such as for example "SDRAM would probably work for
> VGA resolution at 30Hz rate no more...".
>
> I am still choosing the right components for my first FPGA design that is 
> just
> a learning project with no other specific purpose. If I can generate a 
> video
> stream thats fine, if not I will do something else (or lower the frame 
> size,
> refresh rate, etc).
>
> The challenge is also to design a working Spartan-3 FPGA board with the
> largest non BGA package and with only 2 layers. The risk of course is the
> board will never work.
>
>

For a full HD display running at 60Hz frame rate you need about 125Mpix/s x 
24 or 30 bits. Easily within the lowest spec DDR SDRAM as you only need 
sequential access. You can always up the bitwidth of the memory to increase 
bandwidth if access time proves inadequate but obviously you'll need to 
determine that at the outset.

Phil 



Article: 151292
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 21 Mar 2011 14:34:31 -0500
Links: << >>  << T >>  << A >>
If I was you I would have a look at some of Xilinx boards. Download the
schematics and gerbers to see how they have designed them. From your
comments you dont seem to have much knowledge about designing boards. There
is no way that you can use two layers for a bga design. The minimum would
be 4 and this would have to be a fairly low frequency design.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151293
Subject: Re: Finding cheap PCI-E FPGA board for a student
From: Sebastian Urban <surban84@googlemail.com>
Date: Mon, 21 Mar 2011 13:16:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
You could buy directly from devboards GmbH for 133 EUR (excl. VAT).
http://devboards.de/shop/artikeldet.php?proid=6852&bez=DB4CGX15&sid=917d6d818f1b75509a705942b8de4f00&PHPSESSID=917d6d818f1b75509a705942b8de4f00

Article: 151294
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: gtwrek@sonic.net (Mark Curry)
Date: 21 Mar 2011 20:17:04 GMT
Links: << >>  << T >>  << A >>
In article <8JKdnaSMPotTFxrQnZ2dnUVZ8qOdnZ2d@brightview.co.uk>,
Phil Jessop <phil@noname.org> wrote:
>
>"PovTruffe" <PovTache@gaga.invalid> wrote in message 
>news:4d876ea8$0$19933$426a74cc@news.free.fr...
>> "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit :
>>>>No response  :-((
>>>>Maybe my question was not very clear. Let me paraphrase it:
>>>>What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
>>>>Or would either type of RAM work ?
>>>
>>> For any application you must calculate what size and speed of ram you
>>> require. So for your application you must determine the memory bandwidth
>>> and the size of memory needed to fit the data into the memory. You know
>>> what your application is and the relevan parameters so you just need to
>>> match those to the standard ram available. You may find that it is not
>>> possible to with the fpga you want to use and you need to choose a higher
>>> spec device.
>>
>> Thank you for your response. However I was in fact expecting more a rule
>> of thumb response such as for example "SDRAM would probably work for
>> VGA resolution at 30Hz rate no more...".
>>
>> I am still choosing the right components for my first FPGA design that is 
>> just
>> a learning project with no other specific purpose. If I can generate a 
>> video
>> stream thats fine, if not I will do something else (or lower the frame 
>> size,
>> refresh rate, etc).
>>
>> The challenge is also to design a working Spartan-3 FPGA board with the
>> largest non BGA package and with only 2 layers. The risk of course is the
>> board will never work.
>>
>>
>
>For a full HD display running at 60Hz frame rate you need about 125Mpix/s x 
>24 or 30 bits. Easily within the lowest spec DDR SDRAM as you only need 
>sequential access. You can always up the bitwidth of the memory to increase 
>bandwidth if access time proves inadequate but obviously you'll need to 
>determine that at the outset.

The original question is too ill-posed - I wouldn't take any "rule of thumb" 
type response with respect to video - the numbers add up too fast.

One would assume you're not just reading or writing to the DDR - you probably
need to do (at least one) of both a frame-buffer read, and a frame-buffer write.
So 2X (at least) the BW requirements there.  How are you going to pack 
(20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit)
memory interface?  Pack it, or throw away bandwidth?

Reads and Writes at same time? - can you still guarantee "sequential access"
enough so you don't lose bandwidth efficiencies to the DRAM?  Is there
anything else (a CPU?) using the DRAM too that throws this off?

To the OP - there's no "rule of thumb".  Sit down with a pen and paper,
or excel spreadsheet, and calculate you're requirements. 

--Mark
 


Article: 151295
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 21 Mar 2011 20:39:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mark Curry <gtwrek@sonic.net> wrote:
(snip)

> The original question is too ill-posed - I wouldn't take any 
> "rule of thumb" type response with respect to video - the 
> numbers add up too fast.
 
> One would assume you're not just reading or writing to the DDR - 
> you probably need to do (at least one) of both a frame-buffer read, 
> and a frame-buffer write.  So 2X (at least) the BW requirements there.
> How are you going to pack (20-bit, 24-bit, 30-bit and/or 32-bit?) 
> pixel data onto a (16/32/48/64 bit) memory interface?  Pack it, 
> or throw away bandwidth?

There is the old trick (IBM CGA days) of doing the writes during
refresh times.  For the CGA, I believe that there was an interrupt
on vertical refresh, such that you do all the writes then.
 
> Reads and Writes at same time? - can you still guarantee "sequential access"
> enough so you don't lose bandwidth efficiencies to the DRAM?  Is there
> anything else (a CPU?) using the DRAM too that throws this off?

-- glen

Article: 151296
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: gtwrek@sonic.net (Mark Curry)
Date: 21 Mar 2011 21:12:30 GMT
Links: << >>  << T >>  << A >>
In article <im8d2q$um6$2@news.eternal-september.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Mark Curry <gtwrek@sonic.net> wrote:
>(snip)
>
>> The original question is too ill-posed - I wouldn't take any 
>> "rule of thumb" type response with respect to video - the 
>> numbers add up too fast.
> 
>> One would assume you're not just reading or writing to the DDR - 
>> you probably need to do (at least one) of both a frame-buffer read, 
>> and a frame-buffer write.  So 2X (at least) the BW requirements there.
>> How are you going to pack (20-bit, 24-bit, 30-bit and/or 32-bit?) 
>> pixel data onto a (16/32/48/64 bit) memory interface?  Pack it, 
>> or throw away bandwidth?
>
>There is the old trick (IBM CGA days) of doing the writes during
>refresh times.  For the CGA, I believe that there was an interrupt
>on vertical refresh, such that you do all the writes then.

That's implied now anyway - the one response gave the number of ~125Mpixels/sec.
That implies using the blanking time to do something "useful".  The actual
pixel clock for 1080P is around 145MHz.

--Mark

 



Article: 151297
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Mon, 21 Mar 2011 23:08:32 +0100
Links: << >>  << T >>  << A >>
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit :
> If I was you I would have a look at some of Xilinx boards. Download the
> schematics and gerbers to see how they have designed them.

I already have several schematics but I am not yet working on the memory and video
circuits. I asked a question because I saw people talking about DRAM there...

> From your comments you dont seem to have much knowledge about designing
> boards. There is no way that you can use two layers for a bga design.
> The minimum would be 4 and this would have to be a fairly low frequency design.

I wrote: "largest NON-BGA package". That is a PQ208 one. I am mostly worried
by the lack of power planes and higher pin capacitance. By the way I have a
significant experience about PCB design but never with a FPGA.



Article: 151298
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Tue, 22 Mar 2011 00:08:32 +0100
Links: << >>  << T >>  << A >>
> The original question is too ill-posed - I wouldn't take any "rule of thumb"
> type response with respect to video - the numbers add up too fast.

OK but I have the freedom to choose whatever video size, rate, # of bits I like.
If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine.

> One would assume you're not just reading or writing to the DDR - you probably
> need to do (at least one) of both a frame-buffer read, and a frame-buffer write.
> So 2X (at least) the BW requirements there.  How are you going to pack
> (20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit)
> memory interface?  Pack it, or throw away bandwidth?

Yes I am aware of the multiple accesses, read and write, that will be required.
Because of the PQ208 package the memory interface will probably be limited
to 16 bit. And some address lines may not be used as well. I am mainly worried
about the PQ208 high pin capacitance.

> Reads and Writes at same time? - can you still guarantee "sequential access"
> enough so you don't lose bandwidth efficiencies to the DRAM?  Is there
> anything else (a CPU?) using the DRAM too that throws this off?

I will probably include a CPU later and try to access the RAM as a learning
exercise.

> To the OP - there's no "rule of thumb".  Sit down with a pen and paper,
> or excel spreadsheet, and calculate you're requirements.

I will do that later. I tryed to make it clear that for this project I do not have
the professional / engineering approach that most of you in this group are
used to. There are no predefined and rigid features for the board. I will just
choose a FPGA, throw a RAM and a few peripherals, then play with the board.
However the PCB will be designed as optimally as possible (shortest trace
lengths, equal length for buses, etc). Later things will become clearer and I will
get a much better feel about the capabilities of a FPGA. Because of the steep
learning curve, if I begin working with all the details, the board will never be
finished this year and I would probably run out of motivation...



Article: 151299
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 21 Mar 2011 23:52:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
PovTruffe <PovTache@gaga.invalid> wrote:
(snip)

> OK but I have the freedom to choose whatever video size, rate, # 
> of bits I like.
> If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine.
> 
>> One would assume you're not just reading or writing to the 
> DDR - you probably
>> need to do (at least one) of both a frame-buffer read, and 
> a frame-buffer write.
>> So 2X (at least) the BW requirements there.  How are you going to pack
>> (20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data 
> onto a (16/32/48/64 bit)
>> memory interface?  Pack it, or throw away bandwidth?

You might look at some of the Digilent boards.  The Spartan3E board
has on-board DDR, and a VGA connector, though only one bit per color.
(It should be possible to dither, though, otherwise only eight colors.)

There are other boards with FPGA, RAM, and VGA connector, too.

That will get you practice with the RAM interface.  Then you
can start your own board design.  The FPGA has pretty strong
drivers, the RAM might not be so strong, though with only one
module it should be fine.  Many systems won't run at full
speed with all modules in place.

-- glen



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