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
jerry1111 wrote: > > But if you don't have the budget to support IP cores, how will you have > > the budget to roll your own MCU? I think all of the things you list as > > being able to add to the CPU, you can still add in the FPGA even if the > > CPU is not in the FPGA. > > But when you want to use 5*uart, 5*timer, 5*edge-sensitive PIO how to connect > it to uC without making glue-logic as for, well, Z80? > You are buying IP-cpu ONCE. So choose it well ;) > > jerry As long as your IP-cpu comes with a decent port of the Gnu-C compiler which is either (a) well supported or (b) You have access to the source and have a GCC guru on hand to fix it. As rickman said, the lack of a good, well sorted, C compiler/assembler/linker/libc toolchain is a major obstruction. For embedded apps you'll want remote debug as well.Article: 43851
> As long as your IP-cpu comes with a decent port of the Gnu-C compiler which is > either (a) well supported or (b) You have access to the source and have a GCC > guru on hand to fix it. As rickman said, the lack of a good, well sorted, C > compiler/assembler/linker/libc toolchain is a major obstruction. For embedded > apps you'll want remote debug as well. I got it ;) I would never try to make OWN core with OWN gcc toolset ! Why? Because time-to-market would be a year or more. But when you can buy good core with good toolset, it is much more useful (at least for me) that making hybrids from various standard uC with some logic to generate additional timers, PWMs, etc... Nios fits my needs (as for now) and I won't change it for other micro controller/processor for nearest 3 or 5 years. jerryArticle: 43852
Thanks for your answer. As you said it seems that the header of the .rbt file is ignored by the FPGA. The header consists of a series of fields followed by a synchronisation word (0xFFFFFFFFaa995566). When the FPGA is programmed it ignores everything until is received the sync word. This means we can add to the header as long as our additons dont match the sync word :o) Regards. "Philip Freidin" <philip@fliptronics.com> wrote in message news:mfpbfu0g8unu2vahafsg0nfempvaacnco5@4ax.com... > On Thu, 30 May 2002 07:42:18 +0100, "Ulises Hernandez" > <ulises@britain.agilent.com> wrote: > >Hello, > > > >I guess you can help me with this one, can we put our own strings into the > >header of the RBT file in place of Design name, Arch, Part, etc (replace it > >with something like, Name of > >project, Clearcase Label, Release Number...)? > >I know the header is automatically generated by the Xilinx tools but I don't > >know if is part of the CRC Check during the download process. > >It could be quite useful for some Software guys here. > > > >Thanks for your help. > > > Yes. The CRC is calculated on the data that loads into the FPGA. Typically > you would have written your own program that has as input the .RBT file, > and skips the text header section, and gets to the bitstream part for > actual down loading. Providing it can deal with your modified header, > there should be no problem. > Adding lines should also not cause problems, assuming the following > sw is looking for the line that starts with "11111111" > > You should be able to change the lines marked with "<<<<<<" > > Xilinx ASCII Bitstream <<<<<< > Created by Bitstream E.35 <<<<<< > Design name: zzz.ncd <<<<<< > Architecture: xc4000e <<<<<< > Part: 4013epq208 <<<<<< but bad idea > Date: Thu May 16 23:14:07 2002 <<<<<< but bad idea > Bits: 247968 <<<<<< but bad idea > 1111111100100000001111001000100110011111 > 01010111111111101 etc 1110101111111011111111011 > > > Philip Freidin > > > Philip Freidin > FliptronicsArticle: 43853
--------------8B21530FD17A0424A1205C71 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ray, Here is a white paper in progress. Seems like you (and others), might have some suggestions to make regarding its contents, since it seems to fit in with the thread that is going on. Commments may be emailed directly to me, or posted here if they are of general interest, Thanks, Austin Designing for Power in FPGAs Austin Lesea 5/6/2002 Rev 0.2 Introduction In a FPGA there are a number of design choices one can make to reduce the power consumption, as well as a few techniques that can be used to reduce overall power dissipation. In the standard CMOS process, power is generated in relation to the clock frequency, and the capacitance of the nodes that are driven. Lately, with the ultra deep sub micron processes and increased clock frequency that we are presently enjoying, another source of power dissipation has become more significant: ‘glitch’ power. Glitch power is due to the settling of logical node as all inputs to a logical function arrive at various times. The variation in arrival times, say at the input to a 4 input LUT, may result in the output changing state as fast as the smallest time skew difference in the arriving signals. Glitch power increases the toggle rate for these logical function nodes. Leakage current results in static power dissipation. Knowing the sources of power dissipation, there are the following techniques to minimize the power: - Reduce the toggle rate, - Reduce the number of elements being clocked, - Disable logic that is not being used for a specific operation if possible, - Match the arrival time of signals at a logic function to reduce the glitch power (not practical in FPGAs), - Insert registers to reduce the toggling of logical inputs. - Encode buses or states to transition less often. - Choose the correct static logic state to minimize static power dissipation. Discussion Reducing the toggle rate is only possible if the design architecture is flexible. Separating clock domains, and operating some areas at a lower speed, and other means may be possible. Reducing the number of elements being clocked takes advantage of the nature of the clock trees in Virtex II and Virtex II Pro: unused pieces of the clock H-tree are not enabled. Placing clocked logic all along the same H tree clock bus corridor will allow most efficient use of the clock resource. If possible, identify blocks of logic that can be disabled while other blocks are operating. Judicious use of the clock enables is also useful in reducing power. Glitch power is the result of disparate delays in the arrival times of signals to a logic function. As each signal arrives, the output node changes state, and has to charge and discharge the capacitance at that node. Registering the output of the logic function before sending it on to more logic is the most effective at reducing the capacitance of the node that is toggling. Delay matching the arrival times of the logic inputs also will reduce the effects of the glitches, but is difficult to do, as the tools do not provide for automatic delay matching. Sometimes minimizing the delays (maximizing the frequency) by over constraining the design will lead to short overall delay times, and less glitching at the inputs. Pipelining and retiming are generally the best means of reducing glitch power. Registering inputs to the logic is a similar method to registering the output of the logic, except that here one solves the skew in delays before the logic, as opposed to after the logic. If all inputs change on the same clock from immediately adjacent registers, the glitch power is reduced. To evaluate a design for reduced glitch power: 1) simulate the design in Xpower, 2) identify the high activity nets, 3) modify the PAR constraints, and 4) reroute the circuit and examine the result. If one chooses to encode an address bus using a gray code, the transitioning of the bus is lessened due to the encoding. Encoding finite state machines (FSM) to provide fewer transitions will also reduce toggling, and reduce power. In Virtex II and Virtex II Pro, low threshold (Vt) NMOS transistors are used to buffer the outputs of the pass gate multiplexers. The low Vt NMOS transistors are leakier than the higher threshold PMOS transistors. Choosing a logic high as the “normal” or “static” state (e.g. using inverted sense logic signal states) causes the NMOS to be ON, and the PMOS to be OFF, which exhibits less power than the other way around. Summary The benefits of these techniques could result in a 30% power savings, at the expense of increased logic and register usage. Most designs will not exhibit this much of an improvement. Some of the above techniques may actually lead to more power, as more nodes added by registers and associated interconnect add more power to the design while reducing the glitch power. If the glitch power was small to start, the cost-benefit tradeoff may be worse that it was before. My thanks to Alireza Kaviani, and the other members of Xilinx Labs (R&D) for their assistance in creating this note, and reviewing it. Copyright 2002, Xilinx, Incorporated. Ray Andraka wrote: > Falk Brunner wrote: > > > "Michael Boehnel" <boehnel@iti.tu-graz.ac.at> schrieb im Newsbeitrag > > news:3CFB4771.F64A2370@iti.tu-graz.ac.at... > > > Hello! > > > > > > Is it possible to kill (thermically destroy) an FPGA by a highly > > > optimized design (hand-placed; high-density; litte unrelated logic) > > > > ;-)))) Nice phrase. (My design is too good for the technology nowadays ) > > If you have a good (optimized) design, wouldnt it dissipate LESS power?? > > Floorplanning does reduce power for a given clock rate, however the decreased > propagation times can lead to higher possible clock rates. It is possible to > overheat the larger parts with a dense high performance design. The average > user won't get to that point though. I have one design on the bench that has to > have heatsinks on V2000E's, but that is a design that is being internally > clocked at 160 MHz, is 85% full, and has some 70% of the LUTs used as SRL16's. > The bottom line is that it is possible to make the bigger parts pretty hot, but > you'll have to work at it to do it. > > > > > > > > assuming that interface lines are OK/room temperature? > > > > > > Did anybody observe such a behavior? > > > > Hmm, no. The IOs of FPGAs are really though guys, even a short for hours > > doest damage them too much, I heard. > > But for a medium sized (lets say 200k gates) FPGA, its hard to overheat them > > with a normal design, unless you turn them into a 10.000 stage shift > > register and clock them with 200 MHz. I did this with a Spartan-II 100, > > draws ~2.7 W, gets real hot in a PQ208 but doesnt melt (at least not after > > 30s of my testing) > > With the big guys (1M gates++), there are good chances to fry the FPGA, > > since power density is much bigger. > > > > -- > > MfG > > Falk > > -- > --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, 1759Article: 43854
First, thanks to all for the interesting feedbacks!! Ray Andraka wrote: > Floorplanning does reduce power for a given clock rate, however the decreased > propagation times can lead to higher possible clock rates. It is possible to > overheat the larger parts with a dense high performance design. The average > user won't get to that point though. I have one design on the bench that has to > have heatsinks on V2000E's, but that is a design that is being internally > clocked at 160 MHz, is 85% full, and has some 70% of the LUTs used as SRL16's. > The bottom line is that it is possible to make the bigger parts pretty hot, but > you'll have to work at it to do it. I am currently investigating a switch design which uses many LUTs as SRL16's, target XCV-600E-6 (package HQ240). 86% of LUT used (25% as SRL16). 99% of slices used, unrelated logic about 10%. But clock rate is below 50 MHz. So the conditions are much lighter than you describe. But the design operates permanently with maximum throughput (about GBit/s). What I am more concerned about than by optimization is what techniques and (software)tools to use to detect hot spots. With a DSP I can be sure, that if no overclocking takes place, no special care has to be taken whatever program I use. The DSP is designed for a special operating frequency (@ room temperature). The temperature problem is left to the DSP manufacturer and is tested by benchmarks. Further, temperature can be measured and the processor halted in case of overtemperature. How can FPGA manufacturers guarantee me, that no hot-spots destroy the device? Is there something such as a worst case design which is used to test the FPGA? AFAIK power estimation tools (such as the one provided with Xilinx Fnd ISE) only estimate the average power and can not be used to model thermal behavior for certain regions precisely (please correct me if I am wrong). Is it enough to take the average power to dimension the heat sink or can single hot spots still damage the silicon? Is the only way to take a thermal camera and a radiation thermometer to measure the prototype? Maybe for many designs, thermal conditions are not an issue. But as FPGA designs get smaller and faster it could be for more users. Regards, MichaelArticle: 43855
Think of it in the "other" base of decimal. The reason we get the repeats is that we end up at some
point in our long division with a remainder of 1 when we do 1/N. with 1/7 you will repeat a sequence
of 7 digits. For a given N you'll always end up with either an even fraction (1/8 for instance) or
you'll get the remainder of 1 within N digits, whether those digits are decimal, hex, or binary.
look at 1/7 for binary (just for kicks)
_____
111)1 000
- 111
1
That was quick!
1/7 in fractional binary is 0.001001001...
The repeat is every 3 bits.
Rick Filipkiewicz wrote:
> Nice find.
>
> If I've got my maths right in general 1/N can be expressed as a repeating pattern in radix 2**r if
> there is a K such that
>
> N * K = 2**r -1
>
> so N = 11 works with K = 93, r = 10. Is it always possible to do this ?
Article: 43856I did and it doesn't work at all. I tried 3 different converters. "Laurent Gauch" <laurent.gauch@amontec.com> wrote in message news:3CFC73DE.5060300@amontec.com... > May try to use a USB to parallel port cable, there are for $49. > > Laurent Gauch > > Kyle Davis wrote: > > > Hi folks, > > I am looking for FPGA board that use USB port or IEEE 1394 (Firewire) for > > downloading to the chip. My notebook only comes with USB and IEEE1394 port > > so using FPGA board that only use parallel or serial port won't work! > > > > Thanks in advance! > > > > > > > > >Article: 43857
Check out my senior project at Xess's page. http://www.xess.com/ho03000.html#Examples. Interfacing to the image sensor was fairly easy. I used a modified version of the Opencores simple I2C controller. Doing something with the data that comes off it is the challenge. I set up some Async FIFOs so I could read and write to the SDRAM on the XSA-100 like it was dual port ram. It uses a parallel port to upload video to a little windows app. It was a really fun project... Check out my pdf on that page. Let me know if you need any advice on where to start. -Ryan "Roger King" <roger@king.com> wrote in message news:iz4K8.173716$t8_.157445@news01.bloor.is.net.cable.rogers.com... > I want to try to interface a digital CMOS camera with a computer. Anyone > thinks this is possible by using an FPGA chip from the Max 7000 Series? For > example. The CMOS camera will be connected to the FPGA then into the > microcontroller or computer? I don't know where to start! > > I would appreciate your responses. Thank you. > > > >Article: 43858
"John Eaton" <johne@vcd.hp.com> schrieb im Newsbeitrag news:adh2p5$38c$1@news.vcd.hp.com... > > I have it on good authority that connecting a 3.3 volt 1M gate part to a > flakey connector that shorts I/O pads to 5 volts WILL destroy the FPGA. > > > And in the true interest of science the folks that performed that little > experiment then verified that it was reproduceable. So they are real scientists. They have reproducable results ;-) More serious, I think overvoltage was not the question here, was it? -- MfG FalkArticle: 43860
"harkirat" <i1073@yahoo.com> schrieb im Newsbeitrag news:e3e8e2b7.0206031501.1b67fdb9@posting.google.com... > Hi:) > Im trying to implement a Genetic algorithm on the FPGA board which > will do control computations based on parameters fed to it by the > 68HC11EVB(which inturn takes the input from a motor which is the motor > speed) via the serial interface and the sends the control signal back > to the EVB(and hence to the motor) Ok, you want a serial interface between the FPGA and the 68HC11, right? > The FPGA board doesnt have any facility for doing this.I was wondering ??? The only thing you need is to take a piece of ribbon cable, attatch some connectors on both sides and plug the two modules together. > what components i need to make it communicate with the EVB via its > serial interface Nothing but some bell wire, if you just want to go 1m (SPI I would guess). If you need higher distance between the uC and FPGA, go for RS232, maybe 422. > I found this peripheral connector > http://www.burched.com.au/B5PeripheralConnectors.html > on the FPGA manufacturers website.Im not too familiar with electronics > im a mechanical guy..:o)Could you tell me if that would do the trick? I dont think you will need this connector. -- MfG FalkArticle: 43861
"Ken Morrow" <kenm@morro.co.uk> schrieb im Newsbeitrag news:3cfbce87_1@mk-nntp-1.news.uk.worldonline.com... > Sometimes it IS neccessary to run post place and route timing simulatuion to > verify the functionality. > One of my customers requires me to use some auto-generated VHDL which I am > not allowed to change. Hmm, this is more a policy question, not a technical. > This code contains a multi-cycle path (as may other code originally designed > for ASIC). This path requires upto 8 clock cycles from input to output. > The post P&R sim is required to verify that the data strobe is delayed in > its pipeline by more than the data is delayed in the multi-cycle path. ??? Would a timing constaint do the same? -- MfG FalkArticle: 43862
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:3CFCB85D.8007CA80@andraka.com... > The skew between clock domains can be significant, as it is not just > the DLL, but also loading and clock jitter that contribute to the > skew. I had a problem a few years ago with a virtex design where data > crossing from a 1x to a 2x (or vice versa) domain was beating the > skewed clock. The biggest contributor turned out to be clock jitter. > > I do not advocate direct transfer between the clock domains because of > the potential for design killing skew. You'll have to come up with a > safer transfer mechanism. Ahhhm I think you got it wrong somehow. He has not two clock domains, he has 2 FPGAs. If the signal delay from the clock source to the two inputs is well matched (hmm, lets say +/- 500ps), then the two clocks inside the FPGAs are aligned by the use of DLLs. Thats the way to deskew clock when interfacing SDRAM etc. -- MfG FalkArticle: 43863
Falk Brunner wrote: > "John Eaton" <johne@vcd.hp.com> schrieb im Newsbeitrag > news:adh2p5$38c$1@news.vcd.hp.com... > > > > I have it on good authority that connecting a 3.3 volt 1M gate part to a > > flakey connector that shorts I/O pads to 5 volts WILL destroy the FPGA. > > > > > > And in the true interest of science the folks that performed that little > > experiment then verified that it was reproduceable. > > So they are real scientists. They have reproducable results ;-) > More serious, I think overvoltage was not the question here, was it? > > -- > MfG > Falk This is a different type of destruction than overheating the die. If the "experimental" connections were to the 5V power source then 5 - clamp diode drop - VCCO = 5 - 0.7 - 3.3 = 1V across sweet FA resistance => melted IO pads ... unless the bond wires acted as fuses first.Article: 43864
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CFC89ED.FEC72059@algor.co.uk>... > John wrote: Same as others when I saw no one had yet posted the recursive method ... > Nice find. > > If I've got my maths right in general 1/N can be expressed as a repeating pattern in radix 2**r if > there is a K such that > > N * K = 2**r -1 > > so N = 11 works with K = 93, r = 10. Is it always possible to do this ? Every rational number can be expressed as a repeating expansion ( I recall from the dimness of a high school math course, don't ask me to dig deep and prove it, I just build the stuff now ) 1/11 is an interesting case, the repeating pattern is .0001011101 0001011101 0001011101 0001011101 ... Here the sequence would start with two subtractions to give the first 10 bits precision, ( 1/8 - 1/32 - 1/1024) then the shifts/adds give 20, 40, 80 bits precision... it converges faster than 1/5 when the base pattern is properly Booth re-coded. I wonder if anyone has a table for optimum fixed divisor encoding? It would make a nice app note... I think someone referred to this as "Russian recursive division", but would be hard pressed to find a reference. A Google search for "Russian division" doesn't work.Article: 43865
I was ready to underscore about how all Ray's points still applied, but then I realized: the output delay should far outstrip any the skew and jitter associated with the DLLs on the different chips. They are different clock domains - synchronous clock domains - given that they've each been DLLed but the problems with the output from the earlier clock domain (lighter clock loading, jitter earlier than the other device's jitter) getting to the later clock domain are outdone by the pin delays. Falk Brunner wrote: > Ahhhm I think you got it wrong somehow. He has not two clock domains, he has > 2 FPGAs. > If the signal delay from the clock source to the two inputs is well matched > (hmm, lets say +/- 500ps), then the two clocks inside the FPGAs are aligned > by the use of DLLs. Thats the way to deskew clock when interfacing SDRAM > etc. > > -- > MfG > FalkArticle: 43866
Hello, I would like to 'isolate' part of my project in a 'hard macro', or something similar that would be compiled only once, and then could be used directly by other project without the need for the others peoples to have access to the source, or the need to recompile the code (like a static library in software). I was told that this could be done using .edif files (I am using Xilinx tools), but I have no idea what this is or how to do it. Does anybody have an idea, or point to an how-to that I can use? Regards, CyrilleArticle: 43867
Edif will give you a 'soft macro', as it does not contain routing information
and includes only placement information that ws present in your source. Compile
the code as a separate design taking care to turn off clock buffer and i/o
insertion. The output from your synthesis is an edif netlist. You can then
instantiate that design as a black box in your top level design. The xilinx
tools will look first in the working directory then in the path set for the
macros for edif files for any components not in the top level edif netlist. If
you want your users to be able to simulate it, you will also need some sort of
simulatable design be it behavioral or a structural netlist. The easiest way to
obtain that is to turn on the mapped output from your synthesizer, which will
then produce a structural VHDL or verilog file made up of xilinx primitives that
can be simulated.
"Cyrille de Brébisson" wrote:
> Hello,
>
> I would like to 'isolate' part of my project in a 'hard macro', or something
> similar that would be compiled only once, and then could be used directly by
> other project without the need for the others peoples to have access to the
> source, or the need to recompile the code (like a static library in
> software).
>
> I was told that this could be done using .edif files (I am using Xilinx
> tools), but I have no idea what this is or how to do it. Does anybody have
> an idea, or point to an how-to that I can use?
>
> Regards, Cyrille
--
--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: 43868
Right you are. I must have read it too fast or had something else on my mind.
The I/O setup and clock to out are sufficient to ensure enough margin with any
skews you are likely to encounter with carefully matched clocks. Internally,
this can be a different story, but outside it shuldn't be a problem.
Falk Brunner wrote:
> "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
> news:3CFCB85D.8007CA80@andraka.com...
> > The skew between clock domains can be significant, as it is not just
> > the DLL, but also loading and clock jitter that contribute to the
> > skew. I had a problem a few years ago with a virtex design where data
> > crossing from a 1x to a 2x (or vice versa) domain was beating the
> > skewed clock. The biggest contributor turned out to be clock jitter.
> >
> > I do not advocate direct transfer between the clock domains because of
> > the potential for design killing skew. You'll have to come up with a
> > safer transfer mechanism.
>
> Ahhhm I think you got it wrong somehow. He has not two clock domains, he has
> 2 FPGAs.
> If the signal delay from the clock source to the two inputs is well matched
> (hmm, lets say +/- 500ps), then the two clocks inside the FPGAs are aligned
> by the use of DLLs. Thats the way to deskew clock when interfacing SDRAM
> etc.
>
> --
> MfG
> Falk
--
--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: 43869
At clock rates below 50 MHz in a 600E, I doubt you will have any problems.
Michael Boehnel wrote:
> First, thanks to all for the interesting feedbacks!!
>
> Ray Andraka wrote:
>
> > Floorplanning does reduce power for a given clock rate, however the decreased
> > propagation times can lead to higher possible clock rates. It is possible to
> > overheat the larger parts with a dense high performance design. The average
> > user won't get to that point though. I have one design on the bench that has to
> > have heatsinks on V2000E's, but that is a design that is being internally
> > clocked at 160 MHz, is 85% full, and has some 70% of the LUTs used as SRL16's.
> > The bottom line is that it is possible to make the bigger parts pretty hot, but
> > you'll have to work at it to do it.
>
> I am currently investigating a switch design which uses many LUTs as SRL16's, target
> XCV-600E-6 (package HQ240).
> 86% of LUT used (25% as SRL16). 99% of slices used, unrelated logic about 10%. But
> clock rate is below 50 MHz. So the conditions are much lighter than you describe.
> But the design operates permanently with maximum throughput (about GBit/s).
>
> What I am more concerned about than by optimization is what techniques and
> (software)tools to use to detect hot spots. With a DSP I can be sure, that if no
> overclocking takes place, no special care has to be taken whatever program I use.
> The DSP is designed for a special operating frequency (@ room temperature). The
> temperature problem is left to the DSP manufacturer and is tested by benchmarks.
> Further, temperature can be measured and the processor halted in case of
> overtemperature.
>
> How can FPGA manufacturers guarantee me, that no hot-spots destroy the device? Is
> there something such as a worst case design which is used to test the FPGA? AFAIK
> power estimation tools (such as the one provided with Xilinx Fnd ISE) only estimate
> the average power and can not be used to model thermal behavior for certain regions
> precisely (please correct me if I am wrong). Is it enough to take the average power
> to dimension the heat sink or can single hot spots still damage the silicon?
>
> Is the only way to take a thermal camera and a radiation thermometer to measure the
> prototype?
>
> Maybe for many designs, thermal conditions are not an issue. But as FPGA designs get
> smaller and faster it could be for more users.
>
> Regards,
>
> Michael
--
--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: 43870
--------------4135B21046789D9FE9BEEB09
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
For FPGAs, floorplan to keep the routing short. That
minimizes the number of switches toggling in the routing
matrix. As I mentioned before, the Virtex and VirtexE seem
to routinely get about 15-20% power savings from
floorplanning (these are in data flow type designs).
A second point: there has been much written about glitch
power recently. Deeply pipelining the design goes a long
way toward reducing the power due to glitching because the
pipeline registers stop the glitch propagation. Even
without the deep pipelining, proper level compression can go
a long way toward reducing glitch power. Note that all of
the things I've mentioned are tricks that have already been
in a good FPGA designer's tool kit for maximizing
performance and minimizing density. We also force zeros
into the data path when there is no or invalid data at the
input. In bit serial (and distributed arithmetic) designs,
even constant values can cause considerable power
dissipation since they result in bit transitions.
Austin Lesea wrote:
> Ray,
>
> Here is a white paper in progress. Seems like you (and
> others), might have some suggestions to make regarding its
> contents, since it seems to fit in with the thread that is
> going on. Commments may be emailed directly to me, or
> posted here if they are of general interest,
>
> Thanks,
>
> Austin
>
> Designing for Power in FPGAs
> Austin Lesea
> 5/6/2002
> Rev 0.2
>
> Introduction
>
> In a FPGA there are a number of design choices one can
> make to reduce the power consumption, as well as a few
> techniques that can be used to reduce overall power
> dissipation.
>
> In the standard CMOS process, power is generated in
> relation to the clock frequency, and the capacitance of
> the nodes that are driven. Lately, with the ultra deep
> sub micron processes and increased clock frequency that we
> are presently enjoying, another source of power
> dissipation has become more significant: ‘glitch’ power.
>
> Glitch power is due to the settling of logical node as all
> inputs to a logical function arrive at various times. The
> variation in arrival times, say at the input to a 4 input
> LUT, may result in the output changing state as fast as
> the smallest time skew difference in the arriving
> signals. Glitch power increases the toggle rate for these
> logical function nodes.
>
> Leakage current results in static power dissipation.
>
> Knowing the sources of power dissipation, there are the
> following techniques to minimize the power:
>
> - Reduce the toggle rate,
> - Reduce the number of elements being clocked,
> - Disable logic that is not being used for a specific
> operation if possible,
> - Match the arrival time of signals at a logic function to
> reduce the glitch power (not practical in FPGAs),
> - Insert registers to reduce the toggling of logical
> inputs.
> - Encode buses or states to transition less often.
> - Choose the correct static logic state to minimize static
> power dissipation.
>
>
> Discussion
>
> Reducing the toggle rate is only possible if the design
> architecture is flexible. Separating clock domains, and
> operating some areas at a lower speed, and other means may
> be possible.
>
> Reducing the number of elements being clocked takes
> advantage of the nature of the clock trees in Virtex II
> and Virtex II Pro: unused pieces of the clock H-tree are
> not enabled. Placing clocked logic all along the same H
> tree clock bus corridor will allow most efficient use of
> the clock resource.
>
> If possible, identify blocks of logic that can be disabled
> while other blocks are operating. Judicious use of the
> clock enables is also useful in reducing power.
>
> Glitch power is the result of disparate delays in the
> arrival times of signals to a logic function. As each
> signal arrives, the output node changes state, and has to
> charge and discharge the capacitance at that node.
> Registering the output of the logic function before
> sending it on to more logic is the most effective at
> reducing the capacitance of the node that is toggling.
> Delay matching the arrival times of the logic inputs also
> will reduce the effects of the glitches, but is difficult
> to do, as the tools do not provide for automatic delay
> matching. Sometimes minimizing the delays (maximizing the
> frequency) by over constraining the design will lead to
> short overall delay times, and less glitching at the
> inputs.
>
> Pipelining and retiming are generally the best means of
> reducing glitch power.
>
> Registering inputs to the logic is a similar method to
> registering the output of the logic, except that here one
> solves the skew in delays before the logic, as opposed to
> after the logic. If all inputs change on the same clock
> from immediately adjacent registers, the glitch power is
> reduced.
>
> To evaluate a design for reduced glitch power: 1) simulate
> the design in Xpower, 2) identify the high activity nets,
> 3) modify the PAR constraints, and 4) reroute the circuit
> and examine the result.
>
> If one chooses to encode an address bus using a gray code,
> the transitioning of the bus is lessened due to the
> encoding. Encoding finite state machines (FSM) to provide
> fewer transitions will also reduce toggling, and reduce
> power.
>
> In Virtex II and Virtex II Pro, low threshold (Vt) NMOS
> transistors are used to buffer the outputs of the pass
> gate multiplexers. The low Vt NMOS transistors are
> leakier than the higher threshold PMOS transistors.
> Choosing a logic high as the “normal” or “static” state
> (e.g. using inverted sense logic signal states) causes the
> NMOS to be ON, and the PMOS to be OFF, which exhibits less
> power than the other way around.
>
> Summary
>
> The benefits of these techniques could result in a 30%
> power savings, at the expense of increased logic and
> register usage. Most designs will not exhibit this much
> of an improvement. Some of the above techniques may
> actually lead to more power, as more nodes added by
> registers and associated interconnect add more power to
> the design while reducing the glitch power. If the glitch
> power was small to start, the cost-benefit tradeoff may be
> worse that it was before.
>
> My thanks to Alireza Kaviani, and the other members of
> Xilinx Labs (R&D) for their assistance in creating this
> note, and reviewing it.
>
> Copyright 2002, Xilinx, Incorporated.
>
>
>
>
> Ray Andraka wrote:
>
>> Falk Brunner wrote:
>>
>> > "Michael Boehnel" <boehnel@iti.tu-graz.ac.at> schrieb
>> im Newsbeitrag
>> > news:3CFB4771.F64A2370@iti.tu-graz.ac.at...
>> > > Hello!
>> > >
>> > > Is it possible to kill (thermically destroy) an FPGA
>> by a highly
>> > > optimized design (hand-placed; high-density; litte
>> unrelated logic)
>> >
>> > ;-)))) Nice phrase. (My design is too good for the
>> technology nowadays )
>> > If you have a good (optimized) design, wouldnt it
>> dissipate LESS power??
>>
>> Floorplanning does reduce power for a given clock rate,
>> however the decreased
>> propagation times can lead to higher possible clock
>> rates. It is possible to
>> overheat the larger parts with a dense high performance
>> design. The average
>> user won't get to that point though. I have one design
>> on the bench that has to
>> have heatsinks on V2000E's, but that is a design that is
>> being internally
>> clocked at 160 MHz, is 85% full, and has some 70% of the
>> LUTs used as SRL16's.
>> The bottom line is that it is possible to make the
>> bigger parts pretty hot, but
>> you'll have to work at it to do it.
>>
>> >
>> >
>> > > assuming that interface lines are OK/room
>> temperature?
>> > >
>> > > Did anybody observe such a behavior?
>> >
>> > Hmm, no. The IOs of FPGAs are really though guys, even
>> a short for hours
>> > doest damage them too much, I heard.
>> > But for a medium sized (lets say 200k gates) FPGA, its
>> hard to overheat them
>> > with a normal design, unless you turn them into a
>> 10.000 stage shift
>> > register and clock them with 200 MHz. I did this with
>> a Spartan-II 100,
>> > draws ~2.7 W, gets real hot in a PQ208 but doesnt melt
>> (at least not after
>> > 30s of my testing)
>> > With the big guys (1M gates++), there are good chances
>> to fry the FPGA,
>> > since power density is much bigger.
>> >
>> > --
>> > MfG
>> > Falk
>>
>> --
>> --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
>
--
--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: 43871
SpartanII comes in other than BGA. The TQ144, PQ208 and PQ240 packages come to
mind. I wouldn't use the Spartan based on a 4K device for a new design at this
point.
Falk Brunner wrote:
> "Børge Strand" <borge.strand.remove.if.not.spamming@sintef.no> schrieb im
> Newsbeitrag news:1022512364.16393@halvan.trd.sintef.no...
>
> > actually minimal. The reason I wrote Spartan instead of SpartanII is that
> > I'm a little afraid of BGA mounting. That's one thing I can't do with my
> SMD
> > iron and microscope.
>
> Spartan-II is available up to 200k in PQ208. Spartan-IIE even 300k
>
> --
> MfG
> Falk
--
--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: 43872
Allan,
The mapped output from Synplicity is RTL code. It does in fact simulate quite a
bit faster than the simprims generated by either the mapped output or the post PAR
output from the xilinx tools. I think there might have been some confusion here as
to which mapped output I was referring to. We distribute the Synplicity mapped
VHDL output as a simulation model for customers who choose not to buy source for
our macros. It is reasonably fast and can be integrated into the pre-synthesis
functional sim for a higher level design fairly easily.
Allan Herriman wrote:
> On Mon, 03 Jun 2002 02:46:57 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >Main reason is just that you have the mapped output without going through the
> >Xilinx tools too. A functional sim using the timing output is about the same
> >simulation time from what I have seen (I don't often go either place).
>
> Thanks Ray, I thought they'd be about the same speed.
>
> Our standard build scripts generate the post-PAR VHDL, so that's why
> I've only ever used that.
>
> Regards,
> Allan.
>
> >Allan Herriman wrote:
> >
> >> On Sat, 1 Jun 2002 17:18:03 +0000 (UTC), nweaver@CSUA.Berkeley.EDU
> >> (Nicholas Weaver) wrote:
> >>
> >> >In article <3cf8fc35.13519329@netnews.agilent.com>,
> >> >Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote:
> >> >>>Ray Andraka proposed to do post-mapping simulation to veryfy the sythesis
> >> >>>result, since a post-maping is (much?) faster than post P&R.
> >> >>
> >> >>Why is it faster? The simprim blocks take most of the simulation
> >> >>time, and these will be the same post map and post PAR.
> >> >>(Note that you *don't* have to load the SDF if you are doing a post
> >> >>PAR functional simulation.)
> >> >
> >> >I think because you end up ignoring all the timing info (which ends up
> >> >being pretty substantial post-routing.
> >>
> >> I thought it was possible to ignore all timing in the post-PAR VHDL.
> >> You don't have to load the SDF and (in Modelsim) you can use the
> >> +notimingchecks command line option to turn off the VITAL timing.
> >>
> >> I haven't ever done a post-map sim to know if there's a difference or
> >> not. Does anyone have any quantitative results?
> >>
> >> Allan.
> >
> >--
> >--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
> >
> >
--
--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: 43873On Tue, 04 Jun 2002 23:15:10 GMT, Ray Andraka <ray@andraka.com> wrote: >Allan, > >The mapped output from Synplicity is RTL code. It does in fact simulate quite a >bit faster than the simprims generated by either the mapped output or the post PAR >output from the xilinx tools. I think there might have been some confusion here as >to which mapped output I was referring to. We distribute the Synplicity mapped >VHDL output as a simulation model for customers who choose not to buy source for >our macros. It is reasonably fast and can be integrated into the pre-synthesis >functional sim for a higher level design fairly easily. Sorry, my mistake. I thought we were referring to the Xilinx tool "map". No wonder it didn't seem to make sense. Bye, Allan. >Allan Herriman wrote: > >> On Mon, 03 Jun 2002 02:46:57 GMT, Ray Andraka <ray@andraka.com> wrote: >> >> >Main reason is just that you have the mapped output without going through the >> >Xilinx tools too. A functional sim using the timing output is about the same >> >simulation time from what I have seen (I don't often go either place). >> >> Thanks Ray, I thought they'd be about the same speed. >> >> Our standard build scripts generate the post-PAR VHDL, so that's why >> I've only ever used that. >> >> Regards, >> Allan. >> >> >Allan Herriman wrote: >> > >> >> On Sat, 1 Jun 2002 17:18:03 +0000 (UTC), nweaver@CSUA.Berkeley.EDU >> >> (Nicholas Weaver) wrote: >> >> >> >> >In article <3cf8fc35.13519329@netnews.agilent.com>, >> >> >Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote: >> >> >>>Ray Andraka proposed to do post-mapping simulation to veryfy the sythesis >> >> >>>result, since a post-maping is (much?) faster than post P&R. >> >> >> >> >> >>Why is it faster? The simprim blocks take most of the simulation >> >> >>time, and these will be the same post map and post PAR. >> >> >>(Note that you *don't* have to load the SDF if you are doing a post >> >> >>PAR functional simulation.) >> >> > >> >> >I think because you end up ignoring all the timing info (which ends up >> >> >being pretty substantial post-routing. >> >> >> >> I thought it was possible to ignore all timing in the post-PAR VHDL. >> >> You don't have to load the SDF and (in Modelsim) you can use the >> >> +notimingchecks command line option to turn off the VITAL timing. >> >> >> >> I haven't ever done a post-map sim to know if there's a difference or >> >> not. Does anyone have any quantitative results? >> >> >> >> Allan. >> > >> >-- >> >--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 >> > >> > > >-- >--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: 43874
When you burn a design on an FPGA(Altera 7000) is it hard-wired? Can it be changed internally, without the assistance of a PC? Like can one design some circuit that can change itself? Maybe like neural networks... or some other AI stuff... Thanks
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