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
Rob Gaddi wrote: > Hey all -- > > So I've got a design, the very vaguest outlines of which are beginning > to gel. But one of the things that's becoming apparent is that it would > benefit from real clock rates somewhere between the obscene and the > unthinkable. > > Throwing lots of money at the problem seems to get me to 500 MHz, yet > more can get me up to 550 MHz, but I could get a lot of other things to > run much more smoothly if I could get clock rates out into the 650 MHz > ballpark. That's for BRAMS and multipliers/DSP slices, not just the flops. > > So I get to thinking about how the clock rate specs get figured out, and > how they have to accomodate the slow silicon at the maximum operating > temperatures. And that thought leads around in circles for a while, and > ultimately leads to the following appalling question: > > Anyone know anything about using Peltier modules, refrigerant pumping > systems, or the like, to cheat up the speed of an FPGA? Is it even > feasible to try to get a 20-30% overclock just from the joys of lower > temperatures? Or do I just suck it up and deal with the rated clock > speeds? That's not a huge increase, so might be chase-able, if you can tolerate the risks/effort. General comments: a) Device specs are corner values, so you want to go to the 'other corner'. That means super-precise, and super-clean, supply designs, and agressive cooling. You will need to measure the Temperatures, and voltages in the system. Be able to control both. Probably include some test cells inside the fabric, that are designed to fail-first. Use those to tell you how close you are to total failure. b) Suppliers bin-select their parts. Look at the speed grades and prices, and plot those on a curve. Some of that is marketing 'what can we get for it', but some is also 'how many do we get' - also if they DO bin, the cheapest grades are rather unlikely to have faster parts in them. c) if there is some benefit to the vendor, you might be able to ask for 'best in class' devices. (if they have more than one fab, it may be a few % can squeeze from the 'better fab' ) d) agressive floor-planning, and speed testing will be needed, but do not overlook 'smarter algorithm' pathways - you can sometimes more than double the speed, by a change of attack. e) or wait for a generation.... ( a new device may release during your development phase) -jgArticle: 132926
Muzaffer Kal wrote: > > What do you do with borrow? The synthesis tool is complaining that you > don't use "borrow" not that you don't assign to it. You can store the > borrow net's value in a register and use it in later instructions. > That way it can not be optimized away. Are you sure borrow is being > used ie, it is on the right side of an assignment? Also remember that > if you're using borrow in combinational logic and it's a real inverse > of carry, as someone else already pointed out, you may not need borrow > at all. Investigate how borrow is used. I think I have figured it out. I have 3 adders which use the MSB as a carry which is unchanged and assigned to COm. I have 5 subtractors which use the MSB as a borrow out. CCOm is the inverse of borrow. The other op-codes do not change borrow or carry. They haven'nt been finished yet. I think that the inversion logic has been pushed inside the subtractor circuit. I tried to do this explicitly a bit like {~COm, Rd_contents}=Rn_contents - shifter_operand; It's not legal syntax. Using the ! operator equally doesn't work. I'll go away and have a think. The simulation does exactly what I want.Article: 132927
Andy Botterill wrote: > I think that the inversion logic has been pushed inside the subtractor > circuit. > I'll go away and have a think. > The simulation does exactly what I want. Since the sim is ok, and synthesis is error free, I would bet a tank of gas that synthesis got it right. Rather than using brain cycles on manual synthesis, I would either 1. Bring "carry" out to a testpoint pin and have a look at the rtl schematic to settle the question, or 2. Assume synthesis is ok and finish the design. -- Mike TreselerArticle: 132928
"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message news:MuCdnaQ2cc-oUNPVnZ2dnUVZ_tyknZ2d@lmi.net... > Hey all -- > > So I've got a design, the very vaguest outlines of which are beginning to > gel. But one of the things that's becoming apparent is that it would > benefit from real clock rates somewhere between the obscene and the > unthinkable. > > Throwing lots of money at the problem seems to get me to 500 MHz, yet more > can get me up to 550 MHz, but I could get a lot of other things to run > much more smoothly if I could get clock rates out into the 650 MHz > ballpark. That's for BRAMS and multipliers/DSP slices, not just the > flops. You might want to talk to these guys, not sure if they have any real silicon, http://www.achronix.com/ Hans www.ht-lab.comArticle: 132929
chrisdekoh@gmail.com wrote: > Hi all, > thanks for your reply. I have tried some suggestions: > > 1) >>>> int timer_value = * (volatile int *) TIMED_REG_ADDRESS; >>>> volatile int result = doSomething(); >>>> timer_value = (* (volatile int *) TIMED_REG_ADDRESS) - timer_value; > > this doesnt work. > > 2) > > Hi David, you said this: > >> You can't make a function itself "volatile", but you can use the >> "noinline" function attribute to ensure it is not inlined - that's >> probably enough to make sure it is called properly. > > how do you make an inline function? can kindly provide give a brief > example? > Making an inline function is easy (assuming you have the compiler flags set to accept the C99 "inline" keyword, or are compiling C++ - I have no idea which version of gcc the Microblaze uses): static inline int doSomething(void) { } If you are compiling with a reasonably recent version of gcc, and have optimisations enabled, then any single-use static function will be inlined automatically. But what you really want here is a non-inlined function: static int attribute((__noinline__)) doSomething(void) { } > kindly help. I have already tried to dump out the assembly > instructions from the compiled binary file beforehand using mb- > objdump. I already know that the smart compiler reorders the timer > enable and puts it some where at the bottom just before the read back > of timer value and timer disabled. > Set your compiler flags to generate a listing file from the C code - it's much easier to follow than using objdump. Alternatively, load the code in the debugger and switch to mixed C and disassembly mode. > > so i get something like this ( in C terms for easy reading): > > void main() { > Xuint32 countvalue; > > > // enable_timer(); <====== it dun do it here :( > // do some stuff on Microblaze > > > ... //some lines of code .... > > > countvalue = readback_timer(); > enable_timer(); <====== the stupid compiler reshuffles the code > here > disable_timer(); > //send count value back to serial port > ... > > > return1; > } > This looks like your enable_timer() and readback_timer() (and probably disable_timer()) definitions are wrong - they should be using volatile accesses to read and write the hardware timer registers. If they were doing that correctly, the compiler would not reorder them. mvh., DavidArticle: 132930
> A White Paper goes through tech-writing and through peer review, and > if somebody does not like it, he can veto and stall the project. > Since I often stick my head out with unconvential solutions, I thus > encounter these problems. Makes you wish for the good old days... > Peter Here is my dilemma, I like to show solutions to unconventional problems. (I started in circuit design before there were Integrated Circuits) What to do when you move data between asynchronous clocks, or how to generate a stable slow clock, or how to double the clock frequency when the DCM cannot do it, or what to do when the incoming clock has hick-ups stemming from pc-board reflections that it is too late to fix. All these are "dirty tricks" that purists frown upon, especially when they have never been in these ugly predicaments. It is fine to be digitally pure, but the world can be dirty and ugly. Band-Aids are not the highest form of medicine, but they are nice to have when you need them... PeterArticle: 132931
"faza" <fazulu.vlsi@gmail.com> wrote in message news:f12c9aaf-9935-4571-8b11-6333b534b37e@f24g2000prh.googlegroups.com... I am planning to support 256-taps with direct form FIR filter ... ====== The question really was to your motivations and design goals. Possible answers might be: "I read somewhere that I could." "I want to build an 8-channel, 16-band graphic equalizer for my home theater." "To make a brick wall filter for my sub-woofer." "To disguise my voice when I call co-workers in the middle of the night." "I love karaoke." In any case, the background and specifics fill multiple chapters in textbooks. I don't expect anyone can condense it down into a digestible newsgroup message for you. The best you'll get is a reading list. Google is your friend there. >>>>>>>>>>>>>>>>>>> I have tested my design with inputs as impulse test,step test,sine,square,sawtooth,pulse and white noise...I dont know how to check for overflow?wat is the test case? ====== Quantization effects is a whole chapter in itself.Article: 132932
On Jun 10, 2:51 pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > Hey all -- > > So I've got a design, the very vaguest outlines of which are beginning > to gel. But one of the things that's becoming apparent is that it would > benefit from real clock rates somewhere between the obscene and the > unthinkable. > > Throwing lots of money at the problem seems to get me to 500 MHz, yet > more can get me up to 550 MHz, but I could get a lot of other things to > run much more smoothly if I could get clock rates out into the 650 MHz > ballpark. That's for BRAMS and multipliers/DSP slices, not just the flops. > > So I get to thinking about how the clock rate specs get figured out, and > how they have to accomodate the slow silicon at the maximum operating > temperatures. And that thought leads around in circles for a while, and > ultimately leads to the following appalling question: > > Anyone know anything about using Peltier modules, refrigerant pumping > systems, or the like, to cheat up the speed of an FPGA? Is it even > feasible to try to get a 20-30% overclock just from the joys of lower > temperatures? Or do I just suck it up and deal with the rated clock speeds? > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order At least for Xilinx and Lattice you can tell the tools what your worst-case operating (die) temperature is if you don't want to use the max rated temperature. In ISE you'll find this under the constraints editor. This should give you a feel for how much extra speed you can get by dialing down the temperature. Peltier coolers require substantial energy, especially if you are cooling a chip that uses a lot of power. An FPGA isn't an image sensor running at a few milliwatts. You may want to look into other refrigeration methods. In any case you would need some good way to extract all the heat from the back side of the Peltier cooler... Regards, GaborArticle: 132933
A working board has been respun to use a FX40 in place of a FX20. For some reason I can't program FPGA on the new board through Impact. I tried both 8.2 and 10.1. It says that Done didn't go high and also on any attempt to assign a new configuration file it generates the following: ERROR:Bitstream:111 - Invalid IDCODE 00000001111010010100000010010011 for write to IDCODE. If I try to read ID I get the following: Validating chain... Boundary-scan chain validated successfully. '2': IDCODE is '00000001111010001100000010010011' '2': IDCODE is '01e8c093' (in hex). '2': : Manufacturer's ID =Xilinx xc4vfx40, Version : 0 So it is 01e94093 vs. 01e8c093... Any ideas on what's going on here?... It's been long since I had such a problem... /MikhailArticle: 132934
Hi... I have a desire to interface some dram to a project and was internet searching for some in depth tutorials on refresh controllers, but haven't found anything that I am happy with. Does anyone know of a good internet link for interfacing to dram? Thanks JimArticle: 132935
"MM" <mbmsv@yahoo.com> wrote in message news:6b8dv2F3ajeb5U1@mid.individual.net... >A working board has been respun to use a FX40 in place of a FX20. For some >reason I can't program FPGA on the new board through Impact. I tried both >8.2 and 10.1. > > It says that Done didn't go high and also on any attempt to assign a new > configuration file it generates the following: > > ERROR:Bitstream:111 - Invalid IDCODE 00000001111010010100000010010011 for > write to IDCODE. > > > If I try to read ID I get the following: > > Validating chain... > Boundary-scan chain validated successfully. > '2': IDCODE is '00000001111010001100000010010011' > '2': IDCODE is '01e8c093' (in hex). > '2': : Manufacturer's ID =Xilinx xc4vfx40, Version : 0 > > So it is 01e94093 vs. 01e8c093... > > > Any ideas on what's going on here?... It's been long since I had such a > problem... > > > /Mikhail > Have you tried recompiling for a FX40? The bit file will be very different!Article: 132936
MM wrote: > A working board has been respun to use a FX40 in place of a FX20. For some > reason I can't program FPGA on the new board through Impact. I tried both > 8.2 and 10.1. > > It says that Done didn't go high and also on any attempt to assign a new > configuration file it generates the following: > > ERROR:Bitstream:111 - Invalid IDCODE 00000001111010010100000010010011 for > write to IDCODE. > > > If I try to read ID I get the following: > > Validating chain... > Boundary-scan chain validated successfully. > '2': IDCODE is '00000001111010001100000010010011' > '2': IDCODE is '01e8c093' (in hex). > '2': : Manufacturer's ID =Xilinx xc4vfx40, Version : 0 > > So it is 01e94093 vs. 01e8c093... > > > Any ideas on what's going on here?... It's been long since I had such a > problem... > > > /Mikhail Have you recompiled the FX20 design for the FX40 package? Hex digits 4-5 (94 vs 8c) are supposed to be the part size. Since the chain report shows the correct size, I've got to assume you have the wrong programming file. If you run the scan on a board with the xc4vfx20, do you get this "other" IDCODE? - John_HArticle: 132937
"Fred" <fred@n0spam.com> wrote in message news:484f0b71$1_2@mk-nntp-2.news.uk.tiscali.com... > > Have you tried recompiling for a FX40? The bit file will be very > different! Yes, the file was built for FX40... unless it is a path problem... but I don't think so... /MikhailArticle: 132938
"John_H" <newsgroup@johnhandwork.com> wrote in message news:d01a8184-3019-4926-bbcb-ef5a929a1ccb@z66g2000hsc.googlegroups.com... > > Have you recompiled the FX20 design for the FX40 package? Hex digits > 4-5 (94 vs 8c) are supposed to be the part size. Since the chain > report shows the correct size, I've got to assume you have the wrong > programming file. Hmm... As I've already said in another post the file has been compiled for FX40... I've checked that several times... But I will check again.... > If you run the scan on a board with the xc4vfx20, do you get this > "other" IDCODE? No, in that case it works fine... /MikhailArticle: 132939
MM wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:d01a8184-3019-4926-bbcb-ef5a929a1ccb@z66g2000hsc.googlegroups.com... >> Have you recompiled the FX20 design for the FX40 package? Hex digits >> 4-5 (94 vs 8c) are supposed to be the part size. Since the chain >> report shows the correct size, I've got to assume you have the wrong >> programming file. > > Hmm... As I've already said in another post the file has been compiled for > FX40... I've checked that several times... But I will check again.... > >> If you run the scan on a board with the xc4vfx20, do you get this >> "other" IDCODE? > > No, in that case it works fine... > > /Mikhail "it works fine" The question was whether the other board returns Validating chain... Boundary-scan chain validated successfully. '2': IDCODE is '00000001111010010100000010010011' '2': IDCODE is '01e94093' (in hex). '2': : Manufacturer's ID =Xilinx xc4vfx20, Version : 0 OR if the IDCODE is something completely different. If you're programming the OLD board with the NEW programming file and "it works fine" then YES you have the old programming file for the new board.Article: 132940
MM wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:d01a8184-3019-4926-bbcb-ef5a929a1ccb@z66g2000hsc.googlegroups.com... >> Have you recompiled the FX20 design for the FX40 package? Hex digits >> 4-5 (94 vs 8c) are supposed to be the part size. Since the chain >> report shows the correct size, I've got to assume you have the wrong >> programming file. > > Hmm... As I've already said in another post the file has been compiled for > FX40... I've checked that several times... But I will check again.... > >> If you run the scan on a board with the xc4vfx20, do you get this >> "other" IDCODE? In some versions of the software the xc4vfx40 idcode was incorrectly coded into the BSDL files which will effect the programming. See this Answer Record for more information. http://www.xilinx.com/support/answers/30095.htm Ed McGettigan -- Xilinx Inc.Article: 132941
>> On Jun 9, 10:32 pm, vikram <vikram...@gmail.com> wrote: >> >>> hi.... >>> how many times cain i download .bit files onto an fpga? i use >>> virtex2pro.... >>> thanks >>> vikram >> Billions of times. Marketing hype, as usual :) If it takes 2 seconds to re-configure the FPGA and you do it 24 hours a day 365 days a year, in 100 years you will only reconfigure it 1,576,800,000 times. Not "billions"! -Alex.Article: 132942
"John_H" <newsgroup@johnhandwork.com> wrote in message news:mtOdnfbIs6u4tdLVnZ2dnUVZ_ovinZ2d@comcast.com... > > The question was whether the other board returns > > Validating chain... > Boundary-scan chain validated successfully. > '2': IDCODE is '00000001111010010100000010010011' > '2': IDCODE is '01e94093' (in hex). > '2': : Manufacturer's ID =Xilinx xc4vfx20, Version : 0 > > OR if the IDCODE is something completely different. Will have to check... > If you're programming the OLD board with the NEW programming file and "it > works fine" then YES you have the old programming file for the new board. No, I am programming the old board with the old file and the new board with the new file... /MikhailArticle: 132943
On Jun 10, 7:25=A0pm, Alex Freed <al...@mirrow.com> wrote: > >> On Jun 9, 10:32 pm, vikram <vikram...@gmail.com> wrote: > > >>> hi.... > >>> how many times cain i download =A0.bit files onto an fpga? i use > >>> virtex2pro.... > >>> thanks > >>> vikram > >> Billions of times. > > Marketing hype, as usual :) > > If it takes 2 seconds to re-configure the FPGA and you do it 24 hours a > day 365 days a year, in 100 years you will only reconfigure it > 1,576,800,000 times. Not "billions"! > > -Alex. Alex, Xilinx is a U.S. company, and your number is called 1.5 billion over here. (Yes, I know Europeans call it a milliard.) You also picked a very long config time. Typical FPGAs can be configured much faster. But it seems that you just want to create some controversy. I am not so sure that you succeeded. Better luck next time! PeterArticle: 132944
"Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message news:484F2F1D.3070201@xilinx.com... > MM wrote: > > In some versions of the software the xc4vfx40 idcode was incorrectly coded > into the BSDL files which will effect the programming. > > See this Answer Record for more information. > http://www.xilinx.com/support/answers/30095.htm > It seemed for a moment that it had to be it, but I've checked the BSDL files and they are correct in both ISE8.2 and 10.1. I have 9.2 installed as well and indeed the file in 9.2 is wrong, however there is no way it gets used as this installation is completely dormant (no paths or environment variables pointing to it)... Very confusing... Here is the beginning of the bitgen report proving that the file is for FX40: Release 8.2.03i - Bitgen I.34 Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved. Loading device for application Rf_Device from file '4vfx40.nph' in environment C:\Xilinx\ISE82. "curc_top" is an NCD, version 3.1, device xc4vfx40, package ff672, speed -10 The STEPPING level for this design is 0. Opened constraints file curc_top.pcf. Tue Jun 10 17:59:41 2008 C:\Xilinx\ISE82\bin\nt\bitgen.exe -intstyle ise -w -g DebugBitstream:No -g Binary:no -g CRC:Enable -g ConfigRate:4 -g CclkPin:PullUp -g M0Pin:PullUp -g M1Pin:PullUp -g M2Pin:PullUp -g ProgPin:PullUp -g DonePin:PullUp -g InitPin:Pullup -g CsPin:Pullup -g DinPin:Pullup -g BusyPin:Pullup -g RdWrPin:Pullup -g TckPin:PullUp -g TdiPin:PullUp -g TdoPin:PullUp -g TmsPin:PullUp -g UnusedPin:PullDown -g UserID:0xFFFFFFFF -g DCIUpdateMode:AsRequired -g StartUpClk:JtagClk -g DONE_cycle:4 -g GTS_cycle:5 -g GWE_cycle:6 -g LCK_cycle:NoWait -g Match_cycle:Auto -g Security:None -g DonePipe:No -g DriveDone:No -g Encrypt:No curc_top.ncd /MikhailArticle: 132945
Peter Alfke wrote: > > Alex, Xilinx is a U.S. company, and your number is called 1.5 billion > over here. (Yes, I know Europeans call it a milliard.) > You also picked a very long config time. Typical FPGAs can be > configured much faster. > But it seems that you just want to create some controversy. I am not > so sure that you succeeded. Better luck next time! > Peter Peter, I was trying to create a smile, not a controversy. That should have been clear from the smiley if nothing else. -Alex.Article: 132946
Thank you for your answers. Rgds AndreArticle: 132947
Leon wrote: > I've just had an email from Altera about the availability of Quartus > Web Edition 8.0. I'm in the process of downloading it. Hopefully > It'll have finished before the system gets overloaded. > > Leon If anyone is curious, there is a newly-removed feature in 8.0: Parallel compiles have been disabled in Web Edition.Article: 132948
On May 31, 8:59=A0pm, "fatf...@googlemail.com" <fatf...@googlemail.com> wrote: > On 29 Mai, 13:48, Brian Drummond <brian_drumm...@btconnect.com> wrote: > > > > > On Wed, 28 May 2008 04:44:40 -0700 (PDT), "fatf...@googlemail.com" > > > <fatf...@googlemail.com> wrote: > > >hi, > > > >does anyone know how to solve this error when selecting 'generate > > >simulation hdl files' in xps (xilinx edk 9.1): > > >Running Data2Mem with the following command: > > > data2mem -bm system_sim.bmm =A0-bd > > /pl/hardware/user-platforms/MySystemV5/fs-boot/executable.elf tag > > microblaze_0 -u =A0-o u tmpucf.ucf > > > >ERROR:MDT - Ucf2Vhdl Conversion Generated Errors. > > > What does this command do on its own? (from a shell) > > Find out why that isn't working, fix it and try again. > > > - Brian > > when paste it into a terminal and run it on its own, there is no > output so i think i does it's job correctly. > but out of the xps-tool it doesn't work... any hints?Article: 132949
On Jun 10, 6:56 pm, Jim Flanagan <jf...@tampaREMOVEbay.rr.com> wrote: > Hi... > I have a desire to interface some dram to a project and was > internet searching for some in depth tutorials on refresh > controllers, but haven't found anything that I am happy with. > Does anyone know of a good internet link for interfacing to dram? > > Thanks > Jim What sort of DRAM? Original asynchronous stuff? Single data rate SDRAM? DDR or DDR 2 or DDR 3? I would think that the refresh control is a very small and simple part of the overall control logic. This of course depends on whether you want to just make sure the memory doesn't "forget" or if you want to increase performance using burst refresh or leaving out unnecessary refresh, or if you want to "scrub" the memory in an ECC system. There are some older DDR SDRAM designs available as reference designs with app notes on the Xilinx site. Again, you need to specify which type of DRAM you are using, because the control will be different for each case. Regards, Gabor
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