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 125575

Article: 125575
Subject: Is it possible to check how cache memories are mapped to FPGA block rams?
From: Wei Wang <camwwang@gmail.com>
Date: Mon, 29 Oct 2007 16:10:17 -0000
Links: << >>  << T >>  << A >>
Hello, I implemented an ARM1176JZFS on a Virtex 5 FPGA, but it seems
that the
cache memories of the processor are not behaving correctly and I
have to turn off the caches for application programs
to run correctly on the processor. Just wondering whether it is
possible to check whether the processor memories have been mapped
correctly onto the block rams on FPGA. Thanks, -Wei


Article: 125576
Subject: Re: FPGA Configuration
From: MikeShepherd564@btinternet.com
Date: Mon, 29 Oct 2007 16:11:23 +0000
Links: << >>  << T >>  << A >>
>I think we should give any new poster more than only a single chance
>to make a fool of himself, before we start giving funny non-advice.
>Peter Alfke

It depends on how lazy they seem to be.  Where someone clearly has
made no significant effort to discover simple information for
themselves, why should we make a serious reply?  My experience is that
those whose first resort is to ask someone else will continue to do it
until discouraged.  I'd guess they are the people whose parents peeled
apples for them.

Since you work for a vendor, perhaps it's your job continually to
spoon-feed those who find it tiresome to open a book, to spend a few
seconds on Google or, in this case, to download the manufacturer's
data sheet.  The rest of us don't have time for lazy people.  There
are enough serious problems to be addressed.

Article: 125577
Subject: Re: Bitfile checking
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 29 Oct 2007 16:12:15 -0000
Links: << >>  << T >>  << A >>
On 29 Okt., 16:53, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> Antti wrote:
> > On 27 Okt., 12:51, Walters <hps...@gmail.com> wrote:
> >> Assuming a scenario that I have a bit file built for a particular
> >> FPGA, but i don't have a that FPGA device to download it to, Is there
> >> a way to check it works on that particular FPGA?
>
> >> Thanks in advance
> >> Water
>
> > no
>
> I'm not sure that I would answer no to this universally.
>
> The bitstream format should enable you to determine if was made for
> a Xilinx, Altera or Lattice device.  In the case of Xilinx devices, you
> should also be able to determine what family and die it was intended for,
> but not the package, by parsing the bitstream and looking for specific
> fields.  Even, the bitstream file size itself should be a good indicator
> of what device it should work.
>
> Now, whether or not it actually works is a completely different question.
>
> Ed McGettigan
> --
> Xilinx Inc.

Ed the OP wanted to VERIFY device operation using bitstream and no
device.

so he wants a SIMULATOR that can load bistream ;)
those are not generically available ASFAIK

Antti









Article: 125578
Subject: Re: 3 input adder in Spartan 3E
From: "MGT78000" <tricky@jigsawlounge.co.uk>
Date: Mon, 29 Oct 2007 11:12:27 -0500
Links: << >>  << T >>  << A >>
Use a pair of Carry Save adders.

A Carry Save adder takes three inputs, and produces two outputs, a partial
sum, P, and a vector of carry bits, C.  It's actually just an array of
independent full adders, so calculation time is independent of the data
width.  To get the full sum add P to C using a normal adder.

Take two of these in series to add four inputs to two outputs.  Send the
outputs back to the inputs again and accumulate on each clock cycle.  It
only needs two four-input LUTS, one per output, so it's as fast as you
like.  Add up the total sum from the output latch whenever you need to.

Chain several sets of adders in a row, and compute the total sum of each
using separate adders (Carry Lookahead or otherwise) in parallel.



Article: 125579
Subject: Re: Is it possible to check how cache memories are mapped to FPGA block rams?
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 29 Oct 2007 16:17:48 -0000
Links: << >>  << T >>  << A >>
On 29 Okt., 17:10, Wei Wang <camww...@gmail.com> wrote:
> Hello, I implemented an ARM1176JZFS on a Virtex 5 FPGA, but it seems
> that the
> cache memories of the processor are not behaving correctly and I
> have to turn off the caches for application programs
> to run correctly on the processor. Just wondering whether it is
> possible to check whether the processor memories have been mapped
> correctly onto the block rams on FPGA. Thanks, -Wei

depends on the definition of "correct"
you can use FPGA editor to see the mapping to device primitives if you
wish
but that want tell you why your design is not working

Antti


Article: 125580
Subject: registers are not shown in waveform (xilinx microblaze)
From: dartanian <dartanians@gmail.com>
Date: Mon, 29 Oct 2007 16:18:42 -0000
Links: << >>  << T >>  << A >>
Hello fpga community

I try to compile a testbench in order to observe the waveforms of the
registers of microblaze. The problem is that i cannot see any set of
MicroBlaze register waves (32 assigned mb registers) after the
generation of the waveform screen (compile, simulate, run.. ).

Initializing a project in EDK, input microblaze and memory type ip's
and trying to input adress values to be inserted from memory into
Microblaze processor. I follow the standard procedure.. compiling,
generating addresses - libraries - netlist, assign drivers, and
heading to simulation through modelsim. Rest of waveforms are there
(sets of mb, opb, lmb, debug, bram...). Can anyone provide me some
help.

Thank you very much in advance.


Article: 125581
Subject: Re: 2 FPGAs /w programming FLASH in one JTAG chain
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 29 Oct 2007 16:23:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Toni Merwec <mistertorpedo@freenet.de> wrote:
> Hi there,

> currently I am designing an FPGA board, featuring two Xilinx 
> Virtex-4 FPGAs. It should be possible to program them with 
> onboard Xilinx Platform FLASH PROMs as well as via JTAG with 
> the IMPACT software. For ease of use and debugging all 
  components should be part of one coherent JTAG chain.
> 
> Now I'd like to know HOW to connect two FPGAs and two 
> Platform FLASH devices in one JTAG chain so that each 
> FPGA can be programmed through the associated FLASH? 
> How is the identification done (i.e. which FLASH is 
> associated with which FPGA?!)?

Argh: a crosspost to many groups!

What's wrong with Figure 8 of the DS123 datasheet?

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 125582
Subject: Re: kicad or orcad virtex5 symbol
From: schsym <support@schematicsymbol.com>
Date: Mon, 29 Oct 2007 09:43:41 -0700
Links: << >>  << T >>  << A >>

Orcad symbols of Xilinx FPGAs are available from this site:
http://www.schematicsymbol.com
and specifically, the Virtex-5 LX family Orcad schematic symbol is
available on this page:
http://www.schematicsymbol.com/xc5vlx.htm



Article: 125583
Subject: Xilinx, MIG, UCF: timing constraints for DDR2 DRAM
From: "Simon Heinzle" <sheinzle@inf.ethz.ch>
Date: Mon, 29 Oct 2007 17:58:17 +0100
Links: << >>  << T >>  << A >>
Hi FPGA Group!

I'm struggling to get a fast speed (~ 200 MHz) for the DDR2 DRAM interface, 
generated with the Xilinx Memory Interface Generator. The complete system 
consists of a PCI interface, an I/O DMA buffer, a burst module bursting from 
DMA buffer to the DDR2 DRAM interface.

What is the best way to define setup/hold times for the I/O pads (UCF)? 
(the RAM interface consists of a bi-dir data bus DQ, some output signals 
e.g. A and the DRAM clocks CK)
1. Using the OFFSET = OUT 5 ns AFTER "SYS_CLK_P"? Unfortunately, this does 
only work using the Input Clock Pin, but it should probably better be in 
reference to the DRAM clocks CK)
2. Using TIMESPEC "TS_DDR_OUT" = FROM FFS TO "DDR_OUT" 5 ns; ? Is probably 
better, but I'm not exactly sure.

Furthermore, how would you tackle the problem if the timing at the pads 
cannot be met?

Thanks in advance for helpful answers and pointers in the right direction!

Best regards,
Simon




Article: 125584
Subject: Re: FPGA vs ASIC
From: Philip Potter <pgp@see.sig.invalid>
Date: Mon, 29 Oct 2007 17:09:15 +0000
Links: << >>  << T >>  << A >>
Andrew FPGA wrote:
> Are Asics and FPGA's really that close?
> 
> The following paper by Kuon and Rose compares a 90nm standard cell
> asic technology with a 90nm FPGA, and shows that the FPGA takes a 40x
> density hit (only 20x if include FPGA hard macros), critical path
> delay 3-4x slower, and dynamic power 12x more.

The FPGAs and ASICs compared have the same feature size, in which case 
it is to be expected that the ASICs will outperform. But the point being 
made was the following:

>>> This is only true when working in the same feature size.  FPGAs tend to be
>>> on the bleeding edge of process where ASIC starts usually lag behind by at
>>> least one or two process generations.  Generally speaking, a lag of 2
>>> generations puts a reasonably carefully executed FPGA design pretty much
>>> on par with an ASIC design in terms of the speed/power/density.

IIRC Xilinx Virtex-5 is on a 45nm process. This allows for 4 times the 
effective area that a 90nm process allows. It seems that if we scale the 
results from the quoted paper, a 45nm FPGA will take only a 5x density 
hit (allowing hard macros) compared to a 90nm ASIC. I don't know how 
critical path delay or dynamic power scale with process size, but once 
you get small enough static power becomes at least as important as 
dynamic power due to leakage currents etc.

Phil

Article: 125585
Subject: Re: FPGA vs ASIC
From: mk <kal*@dspia.*comdelete>
Date: Mon, 29 Oct 2007 17:15:32 GMT
Links: << >>  << T >>  << A >>
On Mon, 29 Oct 2007 17:09:15 +0000, Philip Potter
<pgp@see.sig.invalid> wrote:

>IIRC Xilinx Virtex-5 is on a 45nm process.

No, Virtex-5 is 65nm. No foundry is selling 45nm production wafers
yet.
http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/overview/v5v4features.htm

Article: 125586
Subject: Re: FPGA Configuration
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 29 Oct 2007 10:16:25 -0700
Links: << >>  << T >>  << A >>
Good apple-peeling analogy.
Spoiled brats, too lazy to think, read, or google...
Peter

On Oct 29, 9:11 am, MikeShepherd...@btinternet.com wrote:
> >I think we should give any new poster more than only a single chance
> >to make a fool of himself, before we start giving funny non-advice.
> >Peter Alfke
>
> It depends on how lazy they seem to be.  Where someone clearly has
> made no significant effort to discover simple information for
> themselves, why should we make a serious reply?  My experience is that
> those whose first resort is to ask someone else will continue to do it
> until discouraged.  I'd guess they are the people whose parents peeled
> apples for them.
>
> Since you work for a vendor, perhaps it's your job continually to
> spoon-feed those who find it tiresome to open a book, to spend a few
> seconds on Google or, in this case, to download the manufacturer's
> data sheet.  The rest of us don't have time for lazy people.  There
> are enough serious problems to be addressed.



Article: 125587
Subject: Re: FPGA Configuration
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 29 Oct 2007 10:16:47 -0700
Links: << >>  << T >>  << A >>
<MikeShepherd564@btinternet.com> wrote in message 
news:refbi3lc7d4i9ied5r673sc4bg2d1ucgv9@4ax.com...
> >Hello VLSI Engineers.
>>
>>     Its is true that FPGA boots its program from an external PROM.
>>How external eproms are connected to FPGA. Is there any requirement in
>>making PCB with FPGA.
>>
>>Thanks
>
> First make sure you have a stable 6.3V AC heater supply (50Hz or 60Hz
> is fine). The configuration bit stream is modulated onto this using
> QPSK (http://en.wikipedia.org/wiki/Phase-shift_keying).
>
> You don't need HT during configuration, but a negative grid bias will
> keep down leakage currents.

Hi Mike,
As it happens, this came up at the weekend in a discussion with some old 
friends I hadn't seen for a while. I agree with you that it's a good idea to 
configure the FPGA with a valves. (Tubes in the US). The bits are warmer and 
more rounded. (This latter property is useful in fixed point DSP 
implementations). Although transistor fed bits are cleaner, the valve fed 
bits have more air. It is absolutely vital that, whether using solid state 
or vapour state programming, the configuration traces on the PCB are made of 
oxygen free copper. Otherwise, the bits get too much air. I expect.
HTH., Syms.

p.s. http://www.randi.org/jr/2007-09/092807reply.html#i4



Article: 125588
Subject: Re: Bitfile checking
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 29 Oct 2007 11:37:29 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
> On 29 Okt., 16:53, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>> Antti wrote:
>>> On 27 Okt., 12:51, Walters <hps...@gmail.com> wrote:
>>>> Assuming a scenario that I have a bit file built for a particular
>>>> FPGA, but i don't have a that FPGA device to download it to, Is there
>>>> a way to check it works on that particular FPGA?
>>>> Thanks in advance
>>>> Water
>>> no
>> I'm not sure that I would answer no to this universally.
>>
>> The bitstream format should enable you to determine if was made for
>> a Xilinx, Altera or Lattice device.  In the case of Xilinx devices, you
>> should also be able to determine what family and die it was intended for,
>> but not the package, by parsing the bitstream and looking for specific
>> fields.  Even, the bitstream file size itself should be a good indicator
>> of what device it should work.
>>
>> Now, whether or not it actually works is a completely different question.
>>
>> Ed McGettigan
>> --
>> Xilinx Inc.
> 
> Ed the OP wanted to VERIFY device operation using bitstream and no
> device.
> 
> so he wants a SIMULATOR that can load bistream ;)
> those are not generically available ASFAIK
> 

Antti,

If I was a lawyer I would respond with "assuming facts not in evidence".
Was there another thread on this subject that I missed?

Ed McGettigan
--
Xilinx Inc.

Article: 125589
Subject: Re: Power supply filter capacitors
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 30 Oct 2007 07:41:11 +1300
Links: << >>  << T >>  << A >>
Nevo wrote:
>>True, we have done some CMOS Triac designs, powered from a dropper, and
>>there power matters a lot.
>>With a zero cross the gate trigger pulse can be required wider than 5us, 
>>as it need to be applied until past the Triac Holding current.
>>
>>That's also why burst trigger is sometimes used - saves power and
>>tolerates some current phase shifts, and you can be lazier around
>>zero cross.
> 
> 
> This is definitely on my list of improvements to make in the future.  I'm 
> going to build the first unit with the brute force approach and add in 
> refinements.  (Christmas 2008 should be killer!) :)
> 
> Not only will this change reduce total power through the circuit, it'll 
> allow me to use a smaller transformer, which is one of the costliest parts 
> in the design. 

It's only about half a page of code :) - do it now!

  A 3 or 4 bit timeslot counter(probably already there), and a 1:8 or 
1:16 timeslot decode, which is 8 or 16 lines. Then you spread
the power the best way. How fast are your gate optos ?

-jg


Article: 125590
Subject: Re: FPGA Configuration
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 29 Oct 2007 12:23:08 -0700
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fg54ik$ltu$1@aioe.org...
> <MikeShepherd564@btinternet.com> wrote in message 
> news:refbi3lc7d4i9ied5r673sc4bg2d1ucgv9@4ax.com...
>> >Hello VLSI Engineers.
>>>
>>>     Its is true that FPGA boots its program from an external PROM.
>>>How external eproms are connected to FPGA. Is there any requirement in
>>>making PCB with FPGA.
>>>
>>>Thanks
>>
>> First make sure you have a stable 6.3V AC heater supply (50Hz or 60Hz
>> is fine). The configuration bit stream is modulated onto this using
>> QPSK (http://en.wikipedia.org/wiki/Phase-shift_keying).
>>
>> You don't need HT during configuration, but a negative grid bias will
>> keep down leakage currents.
>
> Hi Mike,
> As it happens, this came up at the weekend in a discussion with some old 
> friends I hadn't seen for a while. I agree with you that it's a good idea 
> to configure the FPGA with a valves. (Tubes in the US). The bits are 
> warmer and more rounded. (This latter property is useful in fixed point 
> DSP implementations). Although transistor fed bits are cleaner, the valve 
> fed bits have more air. It is absolutely vital that, whether using solid 
> state or vapour state programming, the configuration traces on the PCB are 
> made of oxygen free copper. Otherwise, the bits get too much air. I 
> expect.
> HTH., Syms.
>
> p.s. http://www.randi.org/jr/2007-09/092807reply.html#i4

I can understand the differences in air, but as much as the marketers and 
"electrophyles" talk about it, I just can't tell any difference in bit 
roundness. 



Article: 125591
Subject: Re: Is it possible to check how cache memories are mapped to FPGA block rams?
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 29 Oct 2007 12:42:01 -0700
Links: << >>  << T >>  << A >>
Wei Wang <camwwang@gmail.com> writes:
> Hello, I implemented an ARM1176JZFS on a Virtex 5 FPGA, but it seems
> that the
> cache memories of the processor are not behaving correctly and I
> have to turn off the caches for application programs
> to run correctly on the processor. Just wondering whether it is
> possible to check whether the processor memories have been mapped
> correctly onto the block rams on FPGA. Thanks, -Wei

Perhaps if you post the actual project (or put a copy on a web site and
post a URL), some of us can take a look at it and try to help debug
it.  Otherwise we don't have very much to go on.

Eric

Article: 125592
Subject: Re: Bitfile checking
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 29 Oct 2007 19:43:26 -0000
Links: << >>  << T >>  << A >>
On 29 Okt., 19:37, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> Antti wrote:
> > On 29 Okt., 16:53, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> >> Antti wrote:
> >>> On 27 Okt., 12:51, Walters <hps...@gmail.com> wrote:
> >>>> Assuming a scenario that I have a bit file built for a particular
> >>>> FPGA, but i don't have a that FPGA device to download it to, Is there
> >>>> a way to check it works on that particular FPGA?
> >>>> Thanks in advance
> >>>> Water
> >>> no
> >> I'm not sure that I would answer no to this universally.
>
> >> The bitstream format should enable you to determine if was made for
> >> a Xilinx, Altera or Lattice device.  In the case of Xilinx devices, you
> >> should also be able to determine what family and die it was intended for,
> >> but not the package, by parsing the bitstream and looking for specific
> >> fields.  Even, the bitstream file size itself should be a good indicator
> >> of what device it should work.
>
> >> Now, whether or not it actually works is a completely different question.
>
> >> Ed McGettigan
> >> --
> >> Xilinx Inc.
>
> > Ed the OP wanted to VERIFY device operation using bitstream and no
> > device.
>
> > so he wants a SIMULATOR that can load bistream ;)
> > those are not generically available ASFAIK
>
> Antti,
>
> If I was a lawyer I would respond with "assuming facts not in evidence".
> Was there another thread on this subject that I missed?
>
> Ed McGettigan
> --
> Xilinx Inc.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

LOL, eh yes it depends on "it works" ...

if we assume a bitstream for a given FPGA always works on the given
FPGA then its sufficient to look file header
if we assume "it works" as it functions as expected, then well we most
certainly need the FPGA and target system and load the bitstream

but a FPGA BITFILE simulator would be funny toy ;)

Antti






















Article: 125593
Subject: Free & open source USB STAPL Player
From: Wojciech Zabolotny <wzab@ipebio15.ise.pw.edu.pl>
Date: Mon, 29 Oct 2007 20:26:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi All,

I have just released a free & open source USB STAPL Player - a small
device which may control multiple JTAG chains (up to 8, but only 2
implemented in current hardware) playing the STAPL (JAM) files. All
information is available at
http://www.ise.pw.edu.pl/~wzab/usb_stapl_player/index.html

The design is heavily based on the wonderful PIC USB Framework (
http://vasco.gforge.enseeiht.fr/ ) written by Pierre Gaufillet.
The USB firmware is compiled with the SDCC ( http://sdcc.sf.net ) compiler.
I've also made use of the Altera Jam STAPL Player - which is used on the
PC side of the system.
The USB protocol on the PC side is serviced with the libusb library.
Many thanks to all providers of the above open solutions!

The hardware is based on our didactical board:
http://www.ise.pw.edu.pl/~wzab/opiclab/index.html

This is the first release, so the design is not very clean yet, but it
works (at least for me  ;-)  ).
I hope, that you'll find it useful.
-- 
Regards, 
Wojtek Zabolotny
wzab@ise.pw.edu.pl 

Article: 125594
Subject: Re: FPGA Configuration
From: KJ <Kevin.Jennings@Unisys.com>
Date: Mon, 29 Oct 2007 13:33:28 -0700
Links: << >>  << T >>  << A >>
On Oct 29, 3:23 pm, "John_H" <newsgr...@johnhandwork.com> wrote:

>
> I can understand the differences in air, but as much as the marketers and
> "electrophyles" talk about it, I just can't tell any difference in bit
> roundness.- Hide quoted text -
>

0 is the round bit
1 is the pointy bit

KJ


Article: 125595
Subject: Re: FPGA Configuration
From: Andy <jonesandy@comcast.net>
Date: Mon, 29 Oct 2007 13:38:05 -0700
Links: << >>  << T >>  << A >>
On Oct 29, 2:23 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:fg54ik$ltu$1@aioe.org...
>
>
>
> > <MikeShepherd...@btinternet.com> wrote in message
> >news:refbi3lc7d4i9ied5r673sc4bg2d1ucgv9@4ax.com...
> >> >Hello VLSI Engineers.
>
> >>>     Its is true that FPGA boots its program from an external PROM.
> >>>How external eproms are connected to FPGA. Is there any requirement in
> >>>making PCB with FPGA.
>
> >>>Thanks
>
> >> First make sure you have a stable 6.3V AC heater supply (50Hz or 60Hz
> >> is fine). The configuration bit stream is modulated onto this using
> >> QPSK (http://en.wikipedia.org/wiki/Phase-shift_keying).
>
> >> You don't need HT during configuration, but a negative grid bias will
> >> keep down leakage currents.
>
> > Hi Mike,
> > As it happens, this came up at the weekend in a discussion with some old
> > friends I hadn't seen for a while. I agree with you that it's a good idea
> > to configure the FPGA with a valves. (Tubes in the US). The bits are
> > warmer and more rounded. (This latter property is useful in fixed point
> > DSP implementations). Although transistor fed bits are cleaner, the valve
> > fed bits have more air. It is absolutely vital that, whether using solid
> > state or vapour state programming, the configuration traces on the PCB are
> > made of oxygen free copper. Otherwise, the bits get too much air. I
> > expect.
> > HTH., Syms.
>
> > p.s.http://www.randi.org/jr/2007-09/092807reply.html#i4
>
> I can understand the differences in air, but as much as the marketers and
> "electrophyles" talk about it, I just can't tell any difference in bit
> roundness.

The more round the bits, the better they take the corners...

Andy


Article: 125596
Subject: Re: FPGA vs ASIC
From: Andrew FPGA <andrew.newsgroup@gmail.com>
Date: Mon, 29 Oct 2007 15:13:24 -0700
Links: << >>  << T >>  << A >>
>. It seems that if we scale the
> results from the quoted paper, a 45nm FPGA will take only a 5x density
> hit (allowing hard macros) compared to a 90nm ASIC.

I was not sure how gate size scales with silicon area used so I did
not do your calculation - but I certainly did not think 2 process
generations would give a 20x density improvement.  Do you not think a
5x density difference is significant?

Also, they compared the FPGA to a standard cell asic. Presumably with
full custom the difference would be even greater. (and the NRE FPGA
advantage would be even greater too of course.)



Article: 125597
Subject: Re: 2 FPGAs /w programming FLASH in one JTAG chain
From: "David Spencer" <davidmspencer@verizon.net>
Date: Mon, 29 Oct 2007 22:30:07 GMT
Links: << >>  << T >>  << A >>

"Toni Merwec" <mistertorpedo@freenet.de> wrote in message 
news:4725fc31$0$16670$9b4e6d93@newsspool3.arcor-online.net...
> Hi there,
>
> currently I am designing an FPGA board, featuring two Xilinx Virtex-4 
> FPGAs. It should be possible to program them with onboard Xilinx Platform 
> FLASH PROMs as well as via JTAG with the IMPACT software. For ease of use 
> and debugging all components should be part of one coherent JTAG chain.
>
> Now I'd like to know HOW to connect two FPGAs and two Platform FLASH 
> devices in one JTAG chain so that each FPGA can be programmed through the 
> associated FLASH? How is the identification done (i.e. which FLASH is 
> associated with which FPGA?!)?
>
> Thanks alot in advance...
>
> Regards
>
> Toni
Since you want one Flash per FPGA, you just connect the Flashes to the FPGAs 
as if there was only one of each. You can then connect the JTAG chain 
through all four devices in whatever order you want.



Article: 125598
Subject: Re: registers are not shown in waveform (xilinx microblaze)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 29 Oct 2007 15:33:46 -0700
Links: << >>  << T >>  << A >>
dartanian wrote:

> I try to compile a testbench in order to observe the waveforms of the
> registers of microblaze. The problem is that i cannot see any set of
> MicroBlaze register waves (32 assigned mb registers) after the
> generation of the waveform screen (compile, simulate, run.. ).

"Free" vendor IP is usually provided as a black box netlist.
Unless I buy the source code, or write my own, all I can see
is the top port pins.

         -- Mike Treseler

Article: 125599
Subject: Re: Changing refresh rate for DRAM while in operation?
From: sendthis@gmail.com
Date: Mon, 29 Oct 2007 15:37:07 -0700
Links: << >>  << T >>  << A >>
On Oct 28, 10:18 pm, davewang202 <davewang...@gmail.com> wrote:
> On Oct 25, 4:20 pm, sendt...@gmail.com wrote:
>
>
>
>
>
> > > Since the OP seems to have disappeared to wherever OPs go, I
> > > suspect we will never find out.
>
> > I didn't disappear, I posted a reply but for some reason it didn't
> > show up... I didn't want to accidentally spam the newsgroups by
> > reposting and figured I'd wait to make sure it wasn't just my
> > newsreader or ISP causing the problem.
>
> > Anyway, I guess I'll answer the reason why I want to do this in the
> > same post.
>
> > I'm trying to characterize a DRAM device in certain environmental
> > (radiation) conditions and see how that effects the retention
> > characteristics. I'm not sure if there tests the industry uses to do
> > this, but I needed to evaluate it realtime.
>
> > I'm using the core Altera provided but all the code is there (except
> > for the NIOS II cpu). So I have direct access to the SDRAM
> > controller.
>
> I think it would be really tough to do what you want to do.  The
> reason is that DRAM cell retention time charcteristics are not always
> deterministic.  Some cells will retain data for hundreds of
> milliseconds, while other cells will retain data for tens of seconds,
> and they don't always stay in the "hundreds of millisecond" bit or the
> "tens of seconds" bin.
>
> Ravi Venkatesan's paper has some numbers of DRAM cell retention time
> characteristics [Venkatesan2006].
>
> What this paper doesn't talk about, and what will hurt you is the
> Variable Retention Time (VRT) characteristics of DRAM cells. That is,
> a given DRAM cell can retain data for tens of seconds most of the
> time, but once in a while, it can become a leaky cell that only
> retains data for tens of milliseconds. End users sometimes refer to
> this as being a "weak bit".
> [Yaney1987,Restle1992,Ueno1998,Mori2005,Kim2004]
>
> Now, if you're trying to use the DRAM device as a SEU detector of some
> sort, it depends on how much radiation you expect.  If there are a lot
> of radiation in your environment, then you don't need to do a lot of
> work beforehand to prepare your sample. If, however, you want to
> measure something that's very subtle, and maybe someone that would
> occur no more frequent than once per X minutes, then you'd really have
> to spend a couple of months with a DRAM device and a tester in a cave
> 50 feet below ground (need to make sure that there are no neutrons
> hitting the DRAM while you're characterising it), then characterise it
> to the level so that you'll be able say with some level of
> mathematical confidence that you know where all the weak bits in the
> DRAM device are.
>
> Then, once you know what your device looks like, then you take it to
> the environment where you want to use it to measure your SEU rate,
> then you'd be able to (to some degree) distinguish between a cell that
> failed "early" because it has some built-in VRT characteristic, as
> opposed to a cell that failed because of a SEU.
>
> Good luck
> David
>
> @INPROCEEDINGS{Venkatesan2006, author = {Ravi K. Venkatesan, Stephen
> Herr, Eric Rotenberg}, title = {Retention-Aware Placement in DRAM
> (RAPID):Software Methods for Quasi-Non-Volatile DRAM}, booktitle =
> {Proceedings of the 12th International Symposium on High Performance
> Computer Architecture}, year = {2006}, pages = {157-167}}
>
> @INPROCEEDINGS{Yaney1987, author = {D. S. Yaney, C. Y. Lu, R. A.
> Kohler, M. J. Kelly, J. T. Nelson}, title = {A Meta-Stable Leakage
> Phenonmenon in DRAM Charge Storage - Variable Hold Time}, booktitle =
> {International Electron Devices Meeting Technical Digest}, year =
> {1987}, pages = {336-338}}
>
> @INPROCEEDINGS{Restle1992, author = {P. J. Restle, J. W. Park, B. F.
> Lloyd}, title = {DRAM Variable Retention Time}, booktitle =
> {International Electron Devices Meeting Technical Digest}, year =
> {1992}, pages = {807-810}}
>
> @INPROCEEDINGS{Ueno1998, author = {S. Ueno, T. Yamashita, H. Oda, S.
> Komori, Y. Inoue, T. Nishimura}, title = {Leakage Current Observation
> on Irregular Local Pn Junction Forming the Tail Distribution of DRAM
> Retention Time Characteristics}, booktitle = {International Electron
> Devices Meeting Technical Digest}, year = {1998}, pages = {153-156}}
>
> @INPROCEEDINGS{Mori2005, author = {Yuki Mori, Kiyonori Ohyu, Kensuke
> Okonogi, Ren-ichi Yamada}, title = {The Origins of Variable Retention
> Time in DRAM}, booktitle = {International Electron Devices Meeting
> Technical Digest}, year = {2005}, pages = {1057-1060}}
>
> @INPROCEEDINGS{Kim2004, author = {Y. I. Kim, K. H. Yang, W. S. Lee},
> title = {Thermal Degradation of DRAM Retention Time: Characterization
> and Improving Techniques}, booktitle = {Proceedings of the 42nd Annual
> International Reliability Physics Symposium}, year = {2004}, pages =
> {667-668}}- Hide quoted text -
>
> - Show quoted text -

You brought up some interesting points that I didn't know. I knew that
different cells had different retention times but I was not aware
there was variation in the same cell. That's definitely a problem...





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