Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
The global reset nets in FPGAs are generally too slow to use in systems that are using the clock rate
capability of the FPGA. In those cases, you need to assume the reset is asynchronous to your clock
anyway because the propagation time on the net can exceed the clock cycle making its release
indeterminate relative to the clock, and possibly on different clock cycles in different places on the
design. All that really needs to be reset is critical circuits on the FPGA. For the most part, this
means you just need something to force any feedback loops to a known state so that after some known
number of cycles with reset asserted, you know the state of all the registers in the design without
having to do an explicit reset on more than a small portion of the design. FPGAs do come out of
configuration in a known state, however you should hold the reset on critical items like state machines
for a clock or two to make sure everything starts cleanly. Sometimes, even that is unnecessary other
than for simulation purposes if you have a state machine with no illegal states, for example a counter
that only needs to produce an output at some interval for which you do not care about the phasing.
Assaf Sarfati wrote:
> paulw@mmail.ath.cx (Paul) wrote in message news:<3ba4d769.0401040319.40ffdbcd@posting.google.com>...
> > Hi
> >
> > I know that the "reg"'s are all zeroes when powered on (on Xilinx
> > FPGAs). Is this a good idea (assumption) to work on? Can I assume the
> > same for ASIC development? that is I don't have to change my codes
> > later on?
> >
> > Thanks.
>
> This is a very bad idea. Bad/no design for exiting reset state will
> cause your ASIC/FPGA to be unreliable - sometimes it will start
> working, sometimes not.
>
> In addition, most simulators HATE it - they will start with everything
> in "unknown" state. Reset-recovery problems are very hard to simulate
> (same category as meta-stability problems - not really deterministic),
> so that the design appears to be OK in simulation.
>
> Best practice:
> * EVERY flip-flop should be explicitly reset (including FFs in I/O
> pads).
>
> * Resets are global nets, treated exactly like clocks. Most FPGAs
> allow using dedicated clock nets for reset - recommended.
>
> * Each clock-domain should have its own reset. The trailing edge of
> the reset signal should be synchronous to the clock and shouldn't
> violate reset-recovery timing for any FF. (use a synchronizer for
> reset - the probability of two FFs stuck in meta-stable state is much
> lower than one or two of a set including tens of thousands FFs in the
> clock-domain).
>
> * Just to make your design clear, use the same signal-name everywhere
> for every reset net (also good practice for clock nets).
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65301Austin Lesea wrote: > Pablo, > > Thanks for the opportunity to let us brag a bit: <snip interesting info> > Xilinx Advanced Technology > > Our advanced readback and internal access configuration port allows us > to actually check all memory cell states to see if anything anywhere has > flipped. We can then locate the exact cell that flipped (ie LUT, BRAM, > config latch, etc. and from than know what the susceptibility of each > one really is). We can identify if that bit is used in the customer's > design, and what it does. Because we have had to do this for the > military/aerospace community for years, we are able to do this for > everyone else who may suspect that they have soft errors. How much of this is non-invasive - ie can be done with the device operating, and how much needs it to be halted/paused ? -jgArticle: 65302
Austin - Thanks for the feedback. I REALLY appreciate the feedback from you and Peter in this newsgroup. My local FAE is nervous about using the internal DT terminating resistors at 800 MHz input (400MHz DDR). He says he's seen external resistors work fine at this speed, so why tempt fate? Have you had good performance with the DT style termination at these speeds? I'd sure like to get rid of the stubs at these frequencies! Thanks! John P Austin Lesea <austin@xilinx.com> wrote in message news:<bupm6q$8dh2@cliff.xsj.xilinx.com>... > John, > > This is a true differential termination (a resistor) that is switched in > between + and - inputs. > > No 'issues'. > > Enjoy, > > Austin > > John Providenza wrote: > > I'm doing a high speed design with 800 MHz LVDS data input into > > a Virtex2-Pro V2P7 part. I've looked at the new 'DT' input > > termination mode for the LVDS standard and looked at the > > Xilinx Answer Record 17244 for further info. > > > > It sounds like this mode may not have the issues that DCI had. > > > > Does anyone know of any issues with using this input termination > > mode? > > > > Thanks! > > > > John ProvidenzaArticle: 65303
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:<4002b0a7$0$227$fa0fcedb@lovejoy.zen.co.uk>... > Ben Popoola <b.popoola@ntlworld.com> wrote in message > news:qmkMb.4126$OA3.1018845@newsfep2-win.server.ntli.net... > > > I think that you can also program the EPCS1 via the Cyclone chip itself > > but I do not know how off head. > > > > This might work: > > > > (1) Configure the FPGA through the JTAG port. > > (2) If you have an I/O connection between your logic in the Cyclone and > > a PC, download your configuration bitstream into the EPCS1 via your > > logic in the Cyclone. > > (3) Turn the power off then on. The Cyclone should boot from the EPCS1. > > > I don't think it's as easy as this. > > There's an IP block AMSI which a NIOS processor can use to > acesss/reconfigure an AS device, but this can't easily be > accessed without the NIOS. > > Details of how it's driven aren't published so it's probably > not impossible to use, but not easy. > > This seems a daft move by Altera as easy access to the AS > device allowing in system up-dates would be a good marketing > point. > > Altera has example designs demonstrating EPCS configuration using Nios in a Cyclone device. These designs come with the Nios Development Kit and include the software drivers. Mr. Stewart - I will contact you directly to provide those example files via email or ftp. Sabrina Raza sraza@altera.comArticle: 65304
Jim, It is true in the past that readback while operating caused some issues (pre-Virtex). And even today, LUTRAM is disturbed by readback if it is being used at the same time (address is changing). With Virtex II, II Pro, Spartan 3 we can readback all memory excepting LUTRAM/SRL16 while it is operating and not disturb the static values, nor disturb the customer design. In the next generation we have also fixed that, and allow for readback while LUTRAM/SRL16 are operating. Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help you, as you do not know what it is supposed to be (as it just might be changing). But you can readback the rest of the config memory. That covers 90% of the static cells (excluding BRAM which has a parity bit that can be used to see when the BRAM has been upset). BRAM is also more than 8 times less likely to be upset than a static config latch (from actual data in Rosetta). In fact, you can in your design check that all static config bits are unchanged by simply reading all of them back and comparing a checksum with one calculated when first powered on. Or, you can imagine making an error check AND correcting "crawler" that goes around and fixes any soft errors that might have occurred before they affect the customer design..... Spirit and Opportunity use an even simpler method, which is they continually re-program all static memory cells (skipping LUTRAM/SRL16, BRAM if necessary) while operating. Of course they also used full triple modular redundancy with voting, too. That level of reliability is only required for applications where it can absolutely NOT ever fail! If you can integrate these self-test and monitoring features with the rest of the system, you can even check BRAM and LUTRAM by stopping the processing at strategic moments. Austin jim granville wrote: > Austin Lesea wrote: > >> Pablo, >> >> Thanks for the opportunity to let us brag a bit: > > <snip interesting info> > >> Xilinx Advanced Technology >> >> Our advanced readback and internal access configuration port allows us >> to actually check all memory cell states to see if anything anywhere >> has flipped. We can then locate the exact cell that flipped (ie LUT, >> BRAM, config latch, etc. and from than know what the susceptibility of >> each one really is). We can identify if that bit is used in the >> customer's design, and what it does. Because we have had to do this >> for the military/aerospace community for years, we are able to do this >> for everyone else who may suspect that they have soft errors. > > > How much of this is non-invasive - ie can be done with the device > operating, and how much needs it to be halted/paused ? > > -jg >Article: 65305
We looked at the DCI for an SDRAM interface. The DCI slowed down the pins too much to be useful
in that application. At 400MHz, I suspect you will find the same thing.
John Providenza wrote:
> Austin -
>
> Thanks for the feedback. I REALLY appreciate the feedback
> from you and Peter in this newsgroup.
>
> My local FAE is nervous about using the internal DT terminating
> resistors at 800 MHz input (400MHz DDR). He says he's seen
> external resistors work fine at this speed, so why tempt fate?
>
> Have you had good performance with the DT style termination at
> these speeds? I'd sure like to get rid of the stubs at these
> frequencies!
>
> Thanks!
>
> John P
>
> Austin Lesea ?austin@xilinx.com? wrote in message news:?bupm6q$8dh2@cliff.xsj.xilinx.com?...
> ? John,
> ?
> ? This is a true differential termination (a resistor) that is switched in
> ? between + and - inputs.
> ?
> ? No 'issues'.
> ?
> ? Enjoy,
> ?
> ? Austin
> ?
> ? John Providenza wrote:
> ? ? I'm doing a high speed design with 800 MHz LVDS data input into
> ? ? a Virtex2-Pro V2P7 part. I've looked at the new 'DT' input
> ? ? termination mode for the LVDS standard and looked at the
> ? ? Xilinx Answer Record 17244 for further info.
> ? ?
> ? ? It sounds like this mode may not have the issues that DCI had.
> ? ?
> ? ? Does anyone know of any issues with using this input termination
> ? ? mode?
> ? ?
> ? ? Thanks!
> ? ?
> ? ? John Providenza
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65306
For the configuration bits, most of it can be read while the device is being
clocked. The exception is the block ram contents, and in Virtex, columns
containing SRL16's or CLB RAM. Not sure if they fixed the problem reading
back the SRL16/CLB Ram columns in VirtexII. The discovery was close to
virtexII tape-out IIRC.
jim granville wrote:
> Austin Lesea wrote:
> ? Pablo,
> ?
> ? Thanks for the opportunity to let us brag a bit:
> ?snip interesting info?
> ? Xilinx Advanced Technology
> ?
> ? Our advanced readback and internal access configuration port allows us
> ? to actually check all memory cell states to see if anything anywhere has
> ? flipped. We can then locate the exact cell that flipped (ie LUT, BRAM,
> ? config latch, etc. and from than know what the susceptibility of each
> ? one really is). We can identify if that bit is used in the customer's
> ? design, and what it does. Because we have had to do this for the
> ? military/aerospace community for years, we are able to do this for
> ? everyone else who may suspect that they have soft errors.
>
> How much of this is non-invasive - ie can be done with the device
> operating, and how much needs it to be halted/paused ?
>
> -jg
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65307So here's the scenario: Virtex 2 6000 1152 board (dual Xeon 2.6 Win2k w/ 4GB RAM) Slice usage: 95% IOB,BRAM usage: 50% ISE 6.1 Mapper with -timing, -pr b, -k 8, -ol med as the only params: 39 hr until the mapper was done, then 1 hr in Par -ub -ol med All eight timing constraints were met. ISE 5.2 with the same parameters: 1 hr in Mapper and 17 hr in Par All eight timing constraints were met. So the 6.1 tools take twice as long to meet the same timing constraints. I recognize that on average the 6.1 tools have much better timing because of the timing in the mapper, and it's impressive that they ran for 40 hours without crashing, but is it worth the time cost? We've made great strides in Map/Par time, but 39 hours for one (non-reentrant) file on a fast machine? Is that average? In that the timing constraints aren't overly rigorous, what can I do to speed up the Map/Par time? How come no one has written these tools to run in the Xilinx hardware? Or with some kind of accelerator board? Thanks for your time.Article: 65308
> Does a way exist for resolving this? I have tried to disable from the PC > BIOS, the Hypertheading, also this doesn't resolve the problem . The hyper-threading "problem" is a red herring -- once you disable hyper-threading in the BIOS, your machine will not use any hyper-threading functionality and is in effect just a normal P4 processor. There must be some other problem with your compile -- see Subroto's post. Regards, Paul Leventis Altera Corp.Article: 65309
Let me answer this in more general terms: Anything that is stable can be reliably included in the readback, i.e. configuration bits, LUTs, flip-flops that happen not to change., etc. For stuff that toggles, it is even conceptually difficult to envision what to do, and how to interpret the result.Especially with multiple clock domains. So, even if we do a prefect job in designing the part, the user would still be faced with a complex job to specify the capture moment, and then to interpret the result. But the simple answer is: you can read all static data, without interfering with the operation of the FPGA... Peter Alfke ======================== Austin Lesea wrote: > > Jim, > > It is true in the past that readback while operating caused some issues > (pre-Virtex). And even today, LUTRAM is disturbed by readback if it is > being used at the same time (address is changing). > > With Virtex II, II Pro, Spartan 3 we can readback all memory excepting > LUTRAM/SRL16 while it is operating and not disturb the static values, > nor disturb the customer design. In the next generation we have also > fixed that, and allow for readback while LUTRAM/SRL16 are operating. > > Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help > you, as you do not know what it is supposed to be (as it just might be > changing). > > But you can readback the rest of the config memory. That covers 90% of > the static cells (excluding BRAM which has a parity bit that can be used > to see when the BRAM has been upset). BRAM is also more than 8 times > less likely to be upset than a static config latch (from actual data in > Rosetta). > > In fact, you can in your design check that all static config bits are > unchanged by simply reading all of them back and comparing a checksum > with one calculated when first powered on. > > Or, you can imagine making an error check AND correcting "crawler" that > goes around and fixes any soft errors that might have occurred before > they affect the customer design..... > > Spirit and Opportunity use an even simpler method, which is they > continually re-program all static memory cells (skipping LUTRAM/SRL16, > BRAM if necessary) while operating. Of course they also used full > triple modular redundancy with voting, too. That level of reliability > is only required for applications where it can absolutely NOT ever fail! > > If you can integrate these self-test and monitoring features with the > rest of the system, you can even check BRAM and LUTRAM by stopping the > processing at strategic moments. > > Austin > > jim granville wrote: > > Austin Lesea wrote: > > > >> Pablo, > >> > >> Thanks for the opportunity to let us brag a bit: > > > > <snip interesting info> > > > >> Xilinx Advanced Technology > >> > >> Our advanced readback and internal access configuration port allows us > >> to actually check all memory cell states to see if anything anywhere > >> has flipped. We can then locate the exact cell that flipped (ie LUT, > >> BRAM, config latch, etc. and from than know what the susceptibility of > >> each one really is). We can identify if that bit is used in the > >> customer's design, and what it does. Because we have had to do this > >> for the military/aerospace community for years, we are able to do this > >> for everyone else who may suspect that they have soft errors. > > > > > > How much of this is non-invasive - ie can be done with the device > > operating, and how much needs it to be halted/paused ? > > > > -jg > >Article: 65310
Peter,
My understanding is that there is a readback bug for SRL16/CLBRAM
that causes corruption of the user circuit if the column is read while
those elements are being clocked in Virtex, VirtexE, and possibly
VirtexII. As I recall, it was found right about the time VirtexII was
going into tape-out, and it didn't sound like it would be fixed for
VirtexII. We had to avoid readback during operation of columns
with SRL16s in it on one of my customer's projects that was destined
for space. The work-around included clustering the SRL16s to specific
columns and using a different approach to discover configuration faults
in those columns. My paper "A Low Complexity Method for Detecting
Configuration Upset in SRAM Based FPGAs" goes into a little bit more
detail (the paper is available on my website for download at no charge)
as to the problem and the technique I used to be able to still use the
SRL16's without compromising upset detection. As I recall, there was
also an issue reading BRAM columns while they were being clocked
because the readback circuits shared some of the user circuit in Virtex.
IIRC, that one was corrected in VirtexII.
The caveat to your statement is then, configuration bits can be read back
while the circuit is operating except for SRL16's CLB_RAM and in
virtex, block RAM as reading columns with those elements while they are
being clocked can corrupt the state of the user circuit.
Peter Alfke wrote:
> Let me answer this in more general terms:
> Anything that is stable can be reliably included in the readback, i.e.
> configuration bits, LUTs, flip-flops that happen not to change., etc.
>
> For stuff that toggles, it is even conceptually difficult to envision
> what to do, and how to interpret the result.Especially with multiple
> clock domains.
> So, even if we do a prefect job in designing the part, the user would
> still be faced with a complex job to specify the capture moment, and
> then to interpret the result.
>
> But the simple answer is:
> you can read all static data, without interfering with the operation of
> the FPGA...
> Peter Alfke
> ========================
> Austin Lesea wrote:
> >
> > Jim,
> >
> > It is true in the past that readback while operating caused some issues
> > (pre-Virtex). And even today, LUTRAM is disturbed by readback if it is
> > being used at the same time (address is changing).
> >
> > With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
> > LUTRAM/SRL16 while it is operating and not disturb the static values,
> > nor disturb the customer design. In the next generation we have also
> > fixed that, and allow for readback while LUTRAM/SRL16 are operating.
> >
> > Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
> > you, as you do not know what it is supposed to be (as it just might be
> > changing).
> >
> > But you can readback the rest of the config memory. That covers 90% of
> > the static cells (excluding BRAM which has a parity bit that can be used
> > to see when the BRAM has been upset). BRAM is also more than 8 times
> > less likely to be upset than a static config latch (from actual data in
> > Rosetta).
> >
> > In fact, you can in your design check that all static config bits are
> > unchanged by simply reading all of them back and comparing a checksum
> > with one calculated when first powered on.
> >
> > Or, you can imagine making an error check AND correcting "crawler" that
> > goes around and fixes any soft errors that might have occurred before
> > they affect the customer design.....
> >
> > Spirit and Opportunity use an even simpler method, which is they
> > continually re-program all static memory cells (skipping LUTRAM/SRL16,
> > BRAM if necessary) while operating. Of course they also used full
> > triple modular redundancy with voting, too. That level of reliability
> > is only required for applications where it can absolutely NOT ever fail!
> >
> > If you can integrate these self-test and monitoring features with the
> > rest of the system, you can even check BRAM and LUTRAM by stopping the
> > processing at strategic moments.
> >
> > Austin
> >
> > jim granville wrote:
> > > Austin Lesea wrote:
> > >
> > >> Pablo,
> > >>
> > >> Thanks for the opportunity to let us brag a bit:
> > >
> > > <snip interesting info>
> > >
> > >> Xilinx Advanced Technology
> > >>
> > >> Our advanced readback and internal access configuration port allows us
> > >> to actually check all memory cell states to see if anything anywhere
> > >> has flipped. We can then locate the exact cell that flipped (ie LUT,
> > >> BRAM, config latch, etc. and from than know what the susceptibility of
> > >> each one really is). We can identify if that bit is used in the
> > >> customer's design, and what it does. Because we have had to do this
> > >> for the military/aerospace community for years, we are able to do this
> > >> for everyone else who may suspect that they have soft errors.
> > >
> > >
> > > How much of this is non-invasive - ie can be done with the device
> > > operating, and how much needs it to be halted/paused ?
> > >
> > > -jg
> > >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65311Raivo Nael wrote: > > As much as i know ATT never made their own software for Xilinx > compatible chips. Why? Do they considered it too costly or got only > rights to deal with silicon, not the soft? > > It seems to me that in this case software problems were reasons why > ATT droped this product line. As soon as Xilinx ceased to support 3000 > series, ATT chips also became useless. > > Interesting to know what happened first: ATT deciding that 3000 is too > oldfashioned to make profit of it or Xilinx droping non-A series > support and so making ATT chips useless? I don't think Xilinx "dropped" the XC3000 family, they still sell them today, AFAIK. They don't provide design software unless you really need it. I believe someone posted here recently that they needed this software and they got help to reach the right person at Xilinx for this. But you may be partly right about them dropping support for the 3000 to cut ATT out of *new* Xilinx business. But then with *every* new generation, all the FPGA companies want you to design in the latest parts rather than the old ones. They know the competition also has new parts and the old ones won't get design wins... mostly. In one case, Altera has a part that is still fully supported for new designs and has full 5 volt tolerance without having high startup current issues. I don't think Xilinx has any current parts like that. So I guess an old part could get a design win over even the latest parts since they no longer have 5 volt tolerance (they almost don't have 3 volt tolerance).Article: 65312
Mike Treseler wrote: > > > Ralph Malph wrote: > > >>logic cell count. The last time I checked, counting involved actually > >>counting things. Xilinx seems to think that counting logic cells > >>involves counting and then multiplying by 1.125. > > Why would an engineer be concerned > about such estimates when he can run a > synthesis on his design and > get the *exact utilization* ? > > -- Mike Treseler Because some engineers have to consider costs and need to know how large a part is before it is designed into a board. Not all FPGAs are used like ASICs. Often they are used like FPGAs where designs are added to the board well after it is in the field. So the only analysis that can be done at the time of part selection is paper design based on the *published* information. If no one ever needed the info in the data sheets, why would they publish them?Article: 65313
>sorry...i mean i use the rocket IO as receiver only If you are going to receive something, something else has to transmit it. The simplest transmitter you are going to find is probably on the board you already have. You may have to build a loop-back connector. Anyway, I suggest looking for a self-test setup rather than just something to test the receiver. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 65314
Khim Bittle wrote: > hi folks ... when using the Cyclones with the EPCS4 flash > configuration chip and active serial mode ... I'd like to use the > extra memory space to store a memory image ... so all I need to do is > read or write it in a big block .. so yes i have done this with Nios > but this is too much overhead in a small cyclone device simply to copy > an image from the flash to an external ram .. anyone know how to read > the flash without using nios ? kb > > Hi Khim, As I understand things, the Altera flash memory devices are based upon standard serial flash devices (ST microelectronics ?). Hence you would program these devices as you would any normal serial memory device. You only have yo be careful that you do not overwrite your configuration data. The Altera Cyclone data sheets have the relevant information you are looking, including the memory maps of the configuration and user spaces. BenArticle: 65315
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<c57110htvcsi0vlcjcc13cjdsde1rpfage@4ax.com>... > On Thu, 22 Jan 2004 10:19:12 -0800, Peter Alfke <peter@xilinx.com> > wrote: > > >David Nyberg wrote: > >> > >> Anybody ever come accross a way to design and build a random high speed > >> data pattern generator? It just dawned on me that I'm going to need a > >> way to test the MUX design I posted to 300MB/s! > These LFSRs have been designed for testing *serial* data links. > Experience gained when I was at Agilent indicated that they don't have > enough transitions to properly stress wide parallel interfaces. > > A combination of LFSR and an alternating all ones / all zeros pattern > seemed ok. Lot's of simultaneous transisitions are good for testing against timing problems due to ground bounce, cross talk and the like. Another problem you should be aware of, is that for some circuits a random pattern with 50% propability for one and zero on each bit might not be a good test. A PCI core with 16 active bits in it's address decoder for example will only be selected once out of 64k cycles. But one' can very easily produce random bit's of different propabilities: Just make the shift register longer and AND or OR together multiple shift register bits to produce a single output bit. AND3 for example gives you a 12.5% prob. for 1. Kolja SulimmaArticle: 65316
Hi, all: I am using a DCM to multiply my clock by 2.5...In the UCF file, do I define a Period constraint for the 2.5X clock or the original input clock? Thanks for your comments. Best Regards, KelvinArticle: 65317
Ray Andraka wrote: > Peter, > > My understanding is that there is a readback bug for SRL16/CLBRAM > that causes corruption of the user circuit if the column is read while > those elements are being clocked in Virtex, VirtexE, and possibly > VirtexII. As I recall, it was found right about the time VirtexII was > going into tape-out, and it didn't sound like it would be fixed for > VirtexII. We had to avoid readback during operation of columns > with SRL16s in it on one of my customer's projects that was destined > for space. The work-around included clustering the SRL16s to specific > columns and using a different approach to discover configuration faults > in those columns. My paper "A Low Complexity Method for Detecting > Configuration Upset in SRAM Based FPGAs" goes into a little bit more > detail (the paper is available on my website for download at no charge) > as to the problem and the technique I used to be able to still use the > SRL16's without compromising upset detection. As I recall, there was > also an issue reading BRAM columns while they were being clocked > because the readback circuits shared some of the user circuit in Virtex. > IIRC, that one was corrected in VirtexII. > > The caveat to your statement is then, configuration bits can be read back > while the circuit is operating except for SRL16's CLB_RAM and in > virtex, block RAM as reading columns with those elements while they are > being clocked can corrupt the state of the user circuit. Sounds like that one, if true, needs a fix.... ( and an alert -> someone might think they are increasing reliability by reading back all nodes, and ignoring the 'might change' ones ) - >>Austin Lesea wrote: >> >>>Jim, >>> <snip> >>>With Virtex II, II Pro, Spartan 3 we can readback all memory excepting >>>LUTRAM/SRL16 while it is operating and not disturb the static values, >>>nor disturb the customer design. In the next generation we have also >>>fixed that, and allow for readback while LUTRAM/SRL16 are operating. So this fixed, 'next generation' is not Spartan 3, but whatever is comming after that ? >>>Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help >>>you, as you do not know what it is supposed to be (as it just might be >>>changing). If that BRAM was storing constants/lookup info (read only), then I can see a need to verify the table is actually still correct ? -jgArticle: 65318
I am using this DCM module, It is supposed to generate a 36MHz clock, however NGDBuild gave me this message...How do I explain this strange behavior? Best Regards, Kelvin INFO:XdmHelpers:851 - TNM "clock", used in period specification "TS_clock", was traced into DCM instance "DCM0". The following new TNM groups and period specifications were generated at the DCM output(s): CLKFX: TS_clk_36m_tmp_0=PERIOD clk_36m_tmp_0 TS_clock/4.000000 HIGH 50.000000% IBUFG CLOCK_IN ( .I(clk_40m), .O(clock) ); DCM DCM0 ( .CLKFB(clock_out), .CLKIN(clock), .DSSEN(low), .PSCLK(low), .PSEN(low), .PSINCDEC(low), .RST(low), .CLK0(), .CLK90(), .CLK180(), .CLK270(), .CLK2X(clk0), .CLK2X180(), .CLKDV(), .CLKFX(clk_36m_tmp), .CLKFX180(), .LOCKED(dcm0_locked), .PSDONE(), .STATUS() ); BUFG CLK_BUF0( .I(clk0), .O(clock_out) ); //synthesis translate_off defparam DCM0.DLL_FREQUENCY_MODE = "LOW"; defparam DCM0.DUTY_CYCLE_CORRECTION = "TRUE"; defparam DCM0.STARTUP_WAIT = "TRUE"; defparam DCM0.DFS_FREQUENCY_MODE = "LOW"; defparam DCM0.CLKFX_DIVIDE = 10; defparam DCM0.CLKFX_MULTIPLY = 9; defparam DCM0.CLK_FEEDBACK = "2X"; defparam DCM0.CLKOUT_PHASE_SHIFT = "FIXED"; defparam DCM0.PHASE_SHIFT = 0; //synthesis translate_onArticle: 65319
"Jerry" <nospam@nowhere.com> wrote in message news:<vvhf7ii29ntnbf@corp.supernews.com>... > "Paul" <paulw@mmail.ath.cx> wrote in message > Watch your simulator. It should have unknown in registers that were not > initialized. No, at least for VHDL it should not. For STD_LOGIC types it should have "uninitialized"=U if no initial value was given. This is different from "unknown"=X. As all xilinx flip-flops have an initial value, the VHDL code should explicitly initialize the registers to '0'. (Or '1', if you use a register with preset or initialize it to 1 in the UCF file) For an asic design the registers should be initialized explicitly to 'X'. That way your simulation should match the behavour of the FPGA/ASIC. BTW: As a CAD developer I do not really understand, why I have to set the power up value in the UCF file when the VHDL line signal register : std_logic := '1'; tells the synthesis tool all that it needs to know. Kolja SulimmaArticle: 65320
To all,
Does anyone know if you can use the EDK with Webpack. I currently have
6.1 release of the ISE environment at work but use the WebPack SW at home
for testing things out. I'd like to evaluate the EDK at home but I
installed the 6.x version of it and the 6.1 version of Webpack but I get an
error when I start up the EDK XPS about a missing dll and then the GUI will
allow me to go all the way through a tutorial I downloaded setting up a
Microblaze Processor on a Mimic protocard but at the last step the XPS dies
and locks up??
I initially installed a trial version of the EDK Version 3.1 that I had
on CD and then upgraded from the Website to 6.1. There was some weirdness
doing that but I don't recall details. The trial version had a trial
version of 5.1 or so of the ISE included but I want to run the latest and
greatest stuff.
Thanks,
CTW
Article: 65321
Austin Lesea wrote:
[ snip ]
> We are presenting papers at conferences (MAPLD 2003, for example)
> detailing our results for .5u, .35u, .22u. .18u, .15u, .13u and 90
> nanometer. If interested, email me directly, and I will send you the
> MAPLD ppt presentation.
Here's the presentation, on-line (no paper available that I know of):
"NSEU Sensitivity of SRAM-based FPGAs"
Joe Fabula, Austin Lesea, Carl Carmichael, and Saar Drimer
Xilinx Corp.
http://klabs.org/richcontent/MAPLDCon03/presentations/c/c5_fabula_s.ppt
--
rk, Just an OldEngineer
"For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled."
-- R. Feynman, Appendix F.
Article: 65322Hello all, I have a basic question. 1. How do you find out power consumption (dynamic) of a memory unit? Specifically, if I have a DPRAM (one port Write only @ X MHz, other Read only @ Y MHz), of depth D and width W, what is the power consumption equation? Now one additional question. 2. Does the power consumption depend on memory organization? (Rows and columns can be organized as ... (D/2)x2W, DxW, 2Dx(W/2), ...). My input data width is always W and output data width is also W. In this case if the memory organization is other than DxW, extra circuitry is required for converting W bits to memory width at the input and memory width to W bits conversion at the output. Also, memory write and read frequencies have to be appropriately scaled according to memory organization. So for answering the second question, you have to consider "equivalent systems" and compare apples with apples. I do not know whether the problem I have is trivial. In that case can somebody give me a good reference book where I can get information about these? Thanx in advance, Nagaraj C SArticle: 65323
> I am using a DCM to multiply my clock by 2.5...In the UCF file, do I define > a Period constraint for > the 2.5X clock or the original input clock? > Kelvin - You specify the input clock period in the DCM attributes. You can/should also specify the output clock period in a timespec to constrain your logic. Like this: # for the DCM INST "dcm_inst" CLKIN_PERIOD=25; # for your logic NET "clk_out" TNM_NET = "clk_out"; TIMESPEC "TS_CLKOUT" = PERIOD "clk_out" 10 ns HIGH 50 %; RobertArticle: 65324
Hello, I started now with VHDL....so maybe itīs a stupid Question.... but is there an easy way to increment a bitvector? For example something like this: SIGNAL nano_bin : std_ulogic_vector(31 downto 0); IF....THEN nano_bin <= nano_bin +1 ; END IF; THX Trent
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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