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
"Brannon King" <bking@starbridgesystems.com> wrote in message news:fqudnURdQ-3vLcLdRVn-vw@comcast.com... > I hear the V2Pro was known at various locations internally as the V3. To > avoid the confusion they just skipped to V4. > > I don't understand the clock issue. Mine lookes like this all the way > around: > > /^^\__/^^\__/^^\__/^^\........ > > And I assume they will add an Over-Score key about the time I get my clock > looking smooth on top. As a help to get your clock looking cleaner: /ŻŻ\__/ŻŻ\__/ŻŻ\__/ŻŻ\........ (the clock issue was roman numeral IIII rather than IV on decent wall clocks)Article: 67951
Better than that: The FPGA can be reprogrammed an unlimited number of times (same as flip-flops in a computer can be e an unlimited number of times), and the EEPROM or FlashPROM can also be read an unlimited number of times.(There may be a limitation on write cycles, but not on read operations). Don't worry, be happy! Peter Alfke, Xilinx Applicationas > From: Ray Andraka <ray@andraka.com> > Organization: Andraka Consulting Group, Inc > Newsgroups: comp.arch.fpga > Date: Tue, 23 Mar 2004 09:22:39 -0500 > Subject: Re: How many times can I burn an FPGA? > > There is no limit to the reconfiguration on FPGAs. The configuration is held > in > registers similar to the flip-flops in the design (although the registers are > designed to be slower and therefore more robust against unintended upsets). > They won't wear out. The only life limited item would be the EPROM you load > the > FPGA from. > > Hendra Gunawan wrote: > >> Hi folks, >> typically how many times can I burn/download an FPGA before it becomes >> unreliable. I read Xilinx FPGA datasheets and couldn't find the answer. >> I am asking because I am wondering if someone is going to make a commercial >> FPGA product that need to be frequently turned on and off, this can be an >> issue. Every time the device is turned on, the FPGA chip need to be >> redownloaded from an EPROM. If the device is turned on and off 3 or 4 times >> a day and the device is used every day, and if the device can only be >> reprogrammed 1000 times, then in less than a year the device can not be used >> anymore. >> >> Thanks! >> >> Hendra > > -- > --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: 67952
I'm sure I've read here about problems running Quartus with one/some of AMD's 64 bits processors. I think the problem was a script checking the processor and crashing out because it didn't recognise the AMD64. Does anyone know if this has been fixed? Do all versions of Quartus work with 64 bit processors (specifically Athlon64s)? My main machine's a bit old and tired and I'm thinking of building myself a new one, but need it to be able to run tools from A and X. Thanks for any pointers, Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone based 'Easy PCI' proto board www.nialstewartdevelopments.co.ukArticle: 67953
Kevin Neilson wrote: > Man, you're hardcore--soldering wires to balls and wire-wrapping. I hope > the savings are worthwhile. > -Kevin > Digikey says something like 2000$ for xcv2000e, so for 49$ and three hours work it can't be that bad :) -Lasse > "Antti Lukats" <antti@case2000.com> wrote in message > news:80a3aea5.0403220442.1e9d0756@posting.google.com... > >>interesting - while doing wire wrapping to create a development board >>with XCV2000E (BGA FG860) I accidently connected VCCINT to 3.3V supply >>- I would guessed to see smoke or at least dead FPGA (the power supply >>did deliver full 3.3V to VCCINT), but no! The FPGA was a little warm, >>but not hot. After fixing the VCCINT back to 1.8V I did get long time >>the famous error >> >>"DONE DID NOT GO HIGH" >> >>but after reading the datasheet and pulling PROGRAM to high the >>XCV2000E did come fully alive, i.e. it really survived several minutes >>of 3.3V on VCCINT. >> >>Antti Lukats >> >>PS if i get some time to breathe I will upload the picture of this 2M >>Gate development board (my self-costs $49!! ) >> >>just clarification: I am using a FPGA in BGA package that is removed >>from equipment and I am soldering wires directly to BGA pads. >>The FG860 is actually really easy to handle, and if I dont need many >>IO pins such a wire wrap development board can be made in 3 hours max. > > >Article: 67954
Altera FPGA devices can be programmed any number of times, But be aware that Altera' spec sheets say that CPLD devices can only be programmed 100 (one hundred) times only. Don't know about Xilinx. "Hendra Gunawan" <u1000393@email.sjsu.edu> wrote in message news:<c3oh3k$6eb27$1@hades.csu.net>... > Hi folks, > typically how many times can I burn/download an FPGA before it becomes > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer. > I am asking because I am wondering if someone is going to make a commercial > FPGA product that need to be frequently turned on and off, this can be an > issue. Every time the device is turned on, the FPGA chip need to be > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times > a day and the device is used every day, and if the device can only be > reprogrammed 1000 times, then in less than a year the device can not be used > anymore. > > Thanks! > > HendraArticle: 67955
Yes. Although the PCI spec indicates that PCI 2.2 motherboards should have both 5V and 3.3V supplies on the bus, that is not what industry has generally implemented. When implementing a universal PCI card, ensure that your card can operate with and without a 3.3V supply present, and with and without a 5V supply present on the bus. That is, be sure to have 5V-to-3.3V regulation on board, as well as means for operating from only a 3.3V supply. The PCI specs from PCI-sig are about all the documentation I'd been able to find. It's comprehensive, but unfortunately it can't cover what is actually being implemented in industry. Avoid the I/O scheme where the host computer master-initiates burst reads from your PCI core operating as a target. That particular I/O scheme is not supported by standard PCI bridge chips. The standard alternatives are to either perform single DWORD reads from your PCI core operating as target, or to have your PCI core become bus master and burst write data to the host PC's memory. Pre-plan how to establish the Vendor ID and Device ID that you will be slipping into your PCI core's configuration space. If you want your own Vendor ID, PCI-sig will reserve one to you as long as you pay an annual membership fee. Otherwise, Altera can most likely provide you with one that you can use, and can likely reserve a block of Device IDs for you as well. We're using a Xilinx PCI core, and Xilinx has provided us with their umbrella Vendor ID and a block of Device ID's reserved for our use. I'm quite sure Altera will provide similar service. We've used 5V-tolerant FPGAs for universal PCI cards and 3.3-V tolerant FPGAs for 3.3V PCI cards, so we haven't had to concern ourselves with clipping or converting 5V signaling for 3.3V compatibility so far. Those are most of the issues we've dealt with regarding PCI design so far. There are likely conflicting notions out there. I hope that we'll see some in this thread. Best regards and good luck, Dwayne Surdu-Miller SED Systems --------------------------------------------------- Neven Colak wrote: > HI, > > I am designing a PCI card which will have a Stratix FPGA as the PCI > controller. The Stratix will have a PCI-X core with PCI backwards > compatibility. Now from my readings, PCI-X is 3.3V only signalling, > whereas today the majority of PC motherboards (pre PCI 2.3 spec) are > 5V signalling. For obvious reasons I will have to make my PCI card a > universal card (keyed to both 5V and 3V3) in order to accept present > day common motherboards (PCI 5V) and future motherboards (PCI-X/PCI > 3V3). > Is there anything special I need to consider? > > Does anybody know where I can find info on making my universal card. > Any good books or App notes. > > Thanks, > NevenArticle: 67956
Ray Andraka <ray@andraka.com> wrote in message news:<4060482F.8F69BB5@andraka.com>... > There is no limit to the reconfiguration on FPGAs. The configuration is held in > registers similar to the flip-flops in the design (although the registers are > designed to be slower and therefore more robust against unintended upsets). > They won't wear out. The only life limited item would be the EPROM you load the > FPGA from. This is not completely correct, Xilinx and Altera (and others) are SRAM based and can be reprogrammed infinitely, but others are FLASH or Anti-fuse based and thus can only be programmed a limited number of times. Flash can be reprogrammed a large number of times in the range 10,000 to 100,000 (see the datasheet for details). Anti-fuse types are like blowing a fuse and you can program one time only and if there is a mistake or an upgrade is wanted it is now only a not so heavy paperwieght. > Hendra Gunawan wrote: > > > Hi folks, > > typically how many times can I burn/download an FPGA before it becomes > > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer. > > I am asking because I am wondering if someone is going to make a commercial > > FPGA product that need to be frequently turned on and off, this can be an > > issue. Every time the device is turned on, the FPGA chip need to be > > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times > > a day and the device is used every day, and if the device can only be > > reprogrammed 1000 times, then in less than a year the device can not be used > > anymore. > > > > Thanks! > > > > Hendra > > -- > --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: 67957
Make sure you're putting it in the correct location in your file. See http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0124_77.html "Chris Cheung" <chris_cheung66@hotmail.com> wrote in message news:1HF7c.268115$Hy3.236086@edtnps89... > hi, > I am doing the IOSTANDARD attribute for my lvds buffer: See the > following: > > attribute IOSTANDARD : string; > attribute IOSTANDARD of databuf : label is "LVDS_25"; > attribute IOSTANDARD of framebuf : label is "LVDS_25"; > > Of course, there is syntax error above. Could anyone help me to correct > it? > > Thanks > > Chris > >Article: 67958
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> writes: > I'm sure I've read here about problems running Quartus with > one/some of AMD's 64 bits processors. I think the problem > was a script checking the processor and crashing out > because it didn't recognise the AMD64. This was the case running the Linux version of Quartus on AMD64 systems. I don't have access to Windows based AMD64 based systems. > Does anyone know if this has been fixed? Do all versions of > Quartus work with 64 bit processors (specifically Athlon64s)? I don't think so. Maybe somebody from Altera could confirm this. I still get the same message: $quartus_sh -h Unknown Linux processor MWARCH: Undefined variable. MWCURRENT_LIBPATH: Undefined variable. This is very sad news since the AMD64 based systems are one of the best price/performance systems available today, e.g. see http://tinyurl.com/234d8 Not only that, but it seems like it got even worse. It wont even run on my old Athlon system: The Quartus II software is optimized for the Intel Pentium III processor and newer processors. The required extensions were not found on: 'AMD Athlon(tm) Processor' :-( On a Xeon based system I get: quartus_sh -h Quartus II Shell Version 4.0 Build 190 1/28/2004 SJ Full Version ... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 67959
bob <bob@bob.com> wrote in message news:<405F6DAD.2B7CDE60@bob.com>... <...> > Has anyone seen strange loading faults where CONF_DONE goes high BUT the > FPGA is not operating properly? It > happens to us only every few thousand loads. > > I am keen to resolve this in some way. Bob, Indeed yes. Don't know if you've seen this thread, or if you find it of any use (Aug 18,2003 "Altera JTAG Verification") http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=c0f37b00.0308180607.97eec69%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Drajeev%2BJAM%2BACEX%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dcomp.arch.fpga My personal advice is to use any scheme other JTAG for Altera configuration, at least in a production situation. Regards, -rajeev-Article: 67960
Can someone point me to some documentation explaining the map file. I have taken the EDK tutorial sample on a memec board and I want to expand it to do more stuff. It looks like i need more addressable memory to do this. The memec board ccomes with a SDRAM chip that I would like to use as memory but I can't find much documentation about the map file to make use of this. Thanks for your help MattArticle: 67961
Hendra Gunawan wrote: > Hi folks, > typically how many times can I burn/download an FPGA before it becomes > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer. > I am asking because I am wondering if someone is going to make a commercial > FPGA product that need to be frequently turned on and off, this can be an > issue. Every time the device is turned on, the FPGA chip need to be > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times > a day and the device is used every day, and if the device can only be > reprogrammed 1000 times, then in less than a year the device can not be used > anymore. Homework perhaps ? Burn and Download are two distinct operations. Not every type of FPGA has a Download phase, but all require some non volatile storage of the bit stream, either on-chip, or off-chip. Where Download is done, it is NV memory -> RAM storage, so has no wear-out mechanism. Pgm of the NV storage itself, can have cycle limits from once for Anti-fuse style chips, to > 100,000 for FLASH. There is a general tendancy to quote small cycle numbers (100-1000), as that can give a testing saving. -jgArticle: 67962
I assumed he was talking about XILINX FPGAs since his post indicated he read teh XILINX data sheet and couldn't find a life limit. I apparently was not clear on the EPROM life limit either (the number of write cycles, actually more specifically the number of erase cycles for and EPROM are limited, reads are not). Just for the record: so called SRAM FPGAs have no limit on the number of reconfigurations. The configuration is held in flip-flops (granted, they are slow fat flip-flops for robustness), not in any non-volatile storage. These include Altera FPGAs (10K, 20K, mercury, stratix, stratixII, cyclone), Xilinx FPGAs, Lucent, Atmel etc. Other FPGAs (Actel, Quicklogic) are anti-fuse based, and can only be programmed once. Non-volatile technologies, including the flash technologies used in many CPLDs do have a limit on the number of times they can be reprogrammed, as do EPROMs. The mainstream FPGAs however are either SRAM based and are infinitely reprogrammable, or they are anti-fuse and are one-time programmed. I can't think of any FPGAs (not CPLDs) that are not one of these and are still available today. Mark Sandford wrote: > Ray Andraka <ray@andraka.com> wrote in message news:<4060482F.8F69BB5@andraka.com>... > > There is no limit to the reconfiguration on FPGAs. The configuration is held in > > registers similar to the flip-flops in the design (although the registers are > > designed to be slower and therefore more robust against unintended upsets). > > They won't wear out. The only life limited item would be the EPROM you load the > > FPGA from. > > This is not completely correct, Xilinx and Altera (and others) are > SRAM based and can be reprogrammed infinitely, but others are FLASH or > Anti-fuse based and thus can only be programmed a limited number of > times. Flash can be reprogrammed a large number of times in the range > 10,000 to 100,000 (see the datasheet for details). Anti-fuse types > are like blowing a fuse and you can program one time only and if there > is a mistake or an upgrade is wanted it is now only a not so heavy > paperwieght. > > > > Hendra Gunawan wrote: > > > > > Hi folks, > > > typically how many times can I burn/download an FPGA before it becomes > > > unreliable. I read Xilinx FPGA datasheets and couldn't find the answer. > > > I am asking because I am wondering if someone is going to make a commercial > > > FPGA product that need to be frequently turned on and off, this can be an > > > issue. Every time the device is turned on, the FPGA chip need to be > > > redownloaded from an EPROM. If the device is turned on and off 3 or 4 times > > > a day and the device is used every day, and if the device can only be > > > reprogrammed 1000 times, then in less than a year the device can not be used > > > anymore. > > > > > > Thanks! > > > > > > Hendra > > > > -- > > --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, 1759Article: 67963
Hi all ! Thank you for reading this message ! I would like to know how width are the busses between the registers of an IIR filter (ie implemented in a FPGA), because these filters have coeffs > 1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a simple sin as input signal ! Could anybody help me ?? thanks in advance ! SamArticle: 67964
Ray Andraka wrote: > I assumed he was talking about XILINX FPGAs since his post indicated he read teh XILINX > data sheet and couldn't find a life limit. I apparently was not clear on the EPROM life > limit either (the number of write cycles, actually more specifically the number of erase > cycles for and EPROM are limited, reads are not). Just for the record: > > so called SRAM FPGAs have no limit on the number of reconfigurations. The configuration > is held in flip-flops (granted, they are slow fat flip-flops for robustness), not in any > non-volatile storage. These include Altera FPGAs (10K, 20K, mercury, stratix, stratixII, > cyclone), Xilinx FPGAs, Lucent, Atmel etc. Other FPGAs (Actel, Quicklogic) are anti-fuse > based, and can only be programmed once. Non-volatile technologies, including the flash > technologies used in many CPLDs do have a limit on the number of times they can be > reprogrammed, as do EPROMs. The mainstream FPGAs however are either SRAM based and are > infinitely reprogrammable, or they are anti-fuse and are one-time programmed. I can't > think of any FPGAs (not CPLDs) that are not one of these and are still available today. The ProASIC perhaps ? The distinction between CPLD and FPGA is getting 'fuzzier', with latest Lattice and Altera devices using a single chip, flash transfer approach, and the MAX II has a FPGA LE fabric... -jgArticle: 67965
To find the known path. I run the design without the UCF. Once processed through par, bring the design up in FPGA editor. You can find all known components with instance paths. Tony wrote: > I probably should have been more explicit... > > That <Insert attempted path here> is what i added in to indicate a > wildcard that NONE of my attempted paths worked... I get a series of > those exact messages containing the paths i tried. I.e. > > ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find > instance(s) > 'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the > design. > To suppress this error specify the correct instance name or remove > the > constraint. > ERROR:NgdBuild:753 - Line 1075 in 'system.ucf': Could not find > instance(s) > 'system/plb_gigacore_1/auroracore_i/aurora_lane_0_ii' in the > design. > To suppress this error specify the correct instance name or remove > the > constraint. > ERROR:NgdBuild:753 - Line 1076 in 'system.ucf': Could not find > instance(s) > 'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the > design. > To suppress this error specify the correct instance name or remove > the > constraint. > .... > > > > Thanks, > Tony > > > On Mon, 22 Mar 2004 18:49:05 -0800, Paulo Dutra > <Paulo.Dutra@xilinx.com> wrote: > > >>It looks like ngdbuild is finding the wrong UCF. I think xps copies the >>UCF from the >><proj>/data directory into <proj>/implementation directory. This wrong UCF >>contains "<INSERT ATTEMPTED PATH HERE>" in the hierarchy path. >> >>Tony wrote: >> >> >>>I am constructing a user aurora protocol core based on the PLB SSP1 >>>reference. It utilizes the MGT on a V2P-7. >>>I am having difficulty setting the "INST" parameters in the ucf file. >>>I do not know the path to the MGT parameters. >>>I've tried many locations... a subset of the attempts is: >>> >>>INST plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>LOC=GT_X0Y1; >>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>ALIGN_COMMA_MSB = ...; >>>INST "plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i" >>>CHAN_BOND_MODE = ...; >>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>CHAN_BOND_ONE_SHOT = ...; >>>INST system/plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>CHAN_BOND_SEQ_1_1 = ...; >>> >>> >>>My core is instantiated in the EDK as plb_gigacore_1. >>>the path to the aurora core in the VHDL files is as follows: >>> >>> >>>plb_core_ssp1_ref.vhd defines USER_LOGIC_I : user_logic >>>user_logic.vhd defines auroracore_i : auroracore >>>auroracore.vhd defines lane_0_mgt_i : GT_CUSTOM >>>and global_logic_i : GLOBAL_LOGIC >>> >>>The error I receive is always: >>>ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find >>>instance(s) >>> '<INSERT ATTEMPTED PATH HERE>/auroracore_i/aurora_lane_0_i' in the >>>design. >>> To suppress this error specify the correct instance name or remove >>>the >>> constraint. >>> >>> >>> >>> > > -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 67966
Petter Gustad wrote: > "Nial Stewart" <nial@nialstewartdevelopments.co.uk> writes: > >> I'm sure I've read here about problems running Quartus with >> one/some of AMD's 64 bits processors. I think the problem >> was a script checking the processor and crashing out >> because it didn't recognise the AMD64. > > This was the case running the Linux version of Quartus on AMD64 > systems. I don't have access to Windows based AMD64 based systems. > >> Does anyone know if this has been fixed? Do all versions of >> Quartus work with 64 bit processors (specifically Athlon64s)? > > I don't think so. Maybe somebody from Altera could confirm this. I > still get the same message: > > > $quartus_sh -h > Unknown Linux processor > MWARCH: Undefined variable. > MWCURRENT_LIBPATH: Undefined variable. What happens if you define these? > > This is very sad news since the AMD64 based systems are one of the > best price/performance systems available today, e.g. see > http://tinyurl.com/234d8 Not only that, but it seems like it got even > worse. It wont even run on my old Athlon system: > > The Quartus II software is optimized for the Intel Pentium III processor > and newer processors. The required extensions were not found on: > 'AMD Athlon(tm) Processor' > > :-( > > On a Xeon based system I get: > > quartus_sh -h > Quartus II Shell > Version 4.0 Build 190 1/28/2004 SJ Full Version > ... Quartus II might be compiled with the Intel compiler... Opteron / Athlon 64 has SSE2 but the Intel produced code checks if the processor is an _Intel_ with SSE2 - if not it refuses to run... There was a long thread on comp.arch about this issue... Patcing the binary to remove the check got it to run. /RogerL -- Roger Larsson Skellefteċ SwedenArticle: 67967
Hi Peter, I realize now what you were doing wrong. In the command line help for logiclock back-annotate it says: "-routing: Back-annotate the LogicLock region's routing. Must use -lock, -no_demote_lab. Must not use -no_contents" So when you want to back annotate routing, you should type: logiclock_back_annotate -routing -lock -no_demote_lab -region my_region_name Now for your question about export. Yes export generally does very little to the ESF. However, in cases where the project has multiple ESFs then export will merge them all into one. However, export does make significant changes to the RCF. The exported RCF is different from the back annotated RCF. The back annotated one is suitable in a flow where you are trying to preserve routing within a project. While the exported RCF is more suitable to an export/import flow. The differences are due to VQMs and routing to and from IO pins. Unfortunately, there is not specific TCL guide to using LogicLock. I would recommend: 1) read the handbook. (I believe you said you already did) 2) go to www.altera.com and search for TCL. There are some general TCL guides here but nothing specific to LogicLock 3) quartus_sh --qhelp is the official help. The TCL interface is geared towards the advanced user, so the help is really meant for the GUI user. Please continue asking questions here in the newsgroup, and I will try to answer them for you. Thanks Przemek Guzy Altera Corp.Article: 67968
Hello, I have a UCF problem regarding pin locations. I am creating a custom PLB core that utilizes the MGT on an XV2P7. I have dug my way through and up into the NgdBuild stage. The system is using the system_hello EDK 6.1 ML300 reference design with audioðernet stripped out to make room for the MGT core. We are trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S). Errors are generated when using either B14/C14 or AD14/AE14. I am not sure what to do to fix the problem. Somehow IBUF's are being instantiated, but nowhere in my code indicates this(maybe in EDK it throws it in there?). There are similar tech solutions on xilinx.com that tell you how to fix Synplicity problems that would create a IBUFDS and IBUF on the same pad (and generate a similar problem to mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2. Thanks, Tony PLB Core MPD file: ... PORT RXP = "", DIR = I, IOB_STATE=BUF PORT RXN = "", DIR = I, IOB_STATE=BUF PORT TXP = "", DIR = O, IOB_STATE=BUF PORT TXN = "", DIR = O, IOB_STATE=BUF PORT TOP_BREF_CLK_P = "", DIR = I PORT TOP_BREF_CLK_N = "", DIR = I The port list in EDK ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to BREF_CLK_P/BREF_CLK_N external output pins. I believe I have correctly defined the VHDL instances of the entity user_logic is ... RXP : in std_logic; RXN : in std_logic; TXP : out std_logic; TXN : out std_logic; TOP_BREF_CLK_P : in std_logic; TOP_BREF_CLK_N : in std_logic ); end entity user_logic; architecture IMP of User_Logic is signal TOP_BREF_CLK_i : std_logic; -- FAST reference clock going to MGT xcvr & buffered Ref clock signal USER_CLK_i : std_logic; -- Buffered FAST reference clock for user and MGT logic ... begin -- Differential Clock Buffers for top clock input diff_clk_buff_i : IBUFGDS_LVDS_25 port map ( I => TOP_BREF_CLK_P, IB => TOP_BREF_CLK_N, O => TOP_BREF_CLK_i ); -- Bufg used to drive user clk on global clock net user_clock_bufg_i : BUFG port map ( I => TOP_BREF_CLK_i, O => USER_CLK_i ); The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes anywhere user logic requires the fast clock. UCF settigns: ... # 156.25 MHz Diff Crystal Connection #same errors generated with/without IOSTANDARD spec. NET BREF_CLK_P IOSTANDARD = LVDS_25; NET BREF_CLK_N IOSTANDARD = LVDS_25; NET BREF_CLK_P LOC=AD14; NET BREF_CLK_N LOC=AE14; Error Output: ... ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple drivers. The possible drivers causing this are: pin O on block ibuf_245 with type IBUF, pin PAD on block BREF_CLK_N_IBUF with type PAD WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal input buffer ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal connection. Possible pins causing this are: pin O on block ibuf_245 with type IBUF ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple drivers. The possible drivers causing this are: pin O on block ibuf_244 with type IBUF, pin PAD on block BREF_CLK_P_IBUF with type PAD WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal input buffer ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal connection. Possible pins causing this are: pin O on block ibuf_244 with type IBUFArticle: 67969
Wow! Thanks! Excellent advice and was able to find the correct path. Regards, Tony On Tue, 23 Mar 2004 13:22:51 -0800, Paulo Dutra <paulo.dutra@xilinx.com> wrote: >To find the known path. I run the design without the UCF. >Once processed through par, bring the design up in FPGA editor. >You can find all known components with instance paths. > >Tony wrote: >> I probably should have been more explicit... >> >> That <Insert attempted path here> is what i added in to indicate a >> wildcard that NONE of my attempted paths worked... I get a series of >> those exact messages containing the paths i tried. I.e. >> >> ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find >> instance(s) >> 'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the >> design. >> To suppress this error specify the correct instance name or remove >> the >> constraint. >> ERROR:NgdBuild:753 - Line 1075 in 'system.ucf': Could not find >> instance(s) >> 'system/plb_gigacore_1/auroracore_i/aurora_lane_0_ii' in the >> design. >> To suppress this error specify the correct instance name or remove >> the >> constraint. >> ERROR:NgdBuild:753 - Line 1076 in 'system.ucf': Could not find >> instance(s) >> 'plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i' in the >> design. >> To suppress this error specify the correct instance name or remove >> the >> constraint. >> .... >> >> >> >> Thanks, >> Tony >> >> >> On Mon, 22 Mar 2004 18:49:05 -0800, Paulo Dutra >> <Paulo.Dutra@xilinx.com> wrote: >> >> >>>It looks like ngdbuild is finding the wrong UCF. I think xps copies the >>>UCF from the >>><proj>/data directory into <proj>/implementation directory. This wrong UCF >>>contains "<INSERT ATTEMPTED PATH HERE>" in the hierarchy path. >>> >>>Tony wrote: >>> >>> >>>>I am constructing a user aurora protocol core based on the PLB SSP1 >>>>reference. It utilizes the MGT on a V2P-7. >>>>I am having difficulty setting the "INST" parameters in the ucf file. >>>>I do not know the path to the MGT parameters. >>>>I've tried many locations... a subset of the attempts is: >>>> >>>>INST plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>>LOC=GT_X0Y1; >>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>>ALIGN_COMMA_MSB = ...; >>>>INST "plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i" >>>>CHAN_BOND_MODE = ...; >>>>INST system/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>>CHAN_BOND_ONE_SHOT = ...; >>>>INST system/plb_gigacore_1/plb_gigacore_1/auroracore_i/aurora_lane_0_i >>>>CHAN_BOND_SEQ_1_1 = ...; >>>> >>>> >>>>My core is instantiated in the EDK as plb_gigacore_1. >>>>the path to the aurora core in the VHDL files is as follows: >>>> >>>> >>>>plb_core_ssp1_ref.vhd defines USER_LOGIC_I : user_logic >>>>user_logic.vhd defines auroracore_i : auroracore >>>>auroracore.vhd defines lane_0_mgt_i : GT_CUSTOM >>>>and global_logic_i : GLOBAL_LOGIC >>>> >>>>The error I receive is always: >>>>ERROR:NgdBuild:753 - Line 1074 in 'system.ucf': Could not find >>>>instance(s) >>>> '<INSERT ATTEMPTED PATH HERE>/auroracore_i/aurora_lane_0_i' in the >>>>design. >>>> To suppress this error specify the correct instance name or remove >>>>the >>>> constraint. >>>> >>>> >>>> >>>> >> >>Article: 67970
Tony, I had similiar pin issues when I switched my design from the ml300 to a memec board. I am a little new to MGTs so bear with me. When instantianting a MGT you have two places you have to tell it which clock inputs you are using. 1. in the UCF file under a parameter that looks similiar to INST instname*mgt REF_CLK_V_SEL = 1 2. in your HDL instantiation of your MGT you should have a parameter that looks similiar to REFCLKSEL => '1' Between the two places for each of those parameters there are 4 options you can send the clock input into the MGT. So there are 4 locations you can send a clock into a MGT REFCLK, REFCLK2, BREFCLK and BREFCLK2 and these inputs can only be mapped to certain pins on the fpga so if your inputs are coming in on B14 and C14 you have to determine which location on the MGT to send that too. You need to determine which pin locations can go to which clock input and set all the values appropriately. I hope this helps Matt ---------- Forwarded message ---------- Date: Tue, 23 Mar 2004 21:52:27 GMT From: Tony <tonym_98@nospam> Newsgroups: comp.arch.fpga Subject: IBUFDS -> BUFG Hello, I have a UCF problem regarding pin locations. I am creating a custom PLB core that utilizes the MGT on an XV2P7. I have dug my way through and up into the NgdBuild stage. The system is using the system_hello EDK 6.1 ML300 reference design with audioðernet stripped out to make room for the MGT core. We are trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S). Errors are generated when using either B14/C14 or AD14/AE14. I am not sure what to do to fix the problem. Somehow IBUF's are being instantiated, but nowhere in my code indicates this(maybe in EDK it throws it in there?). There are similar tech solutions on xilinx.com that tell you how to fix Synplicity problems that would create a IBUFDS and IBUF on the same pad (and generate a similar problem to mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2. Thanks, Tony PLB Core MPD file: ... PORT RXP = "", DIR = I, IOB_STATE=BUF PORT RXN = "", DIR = I, IOB_STATE=BUF PORT TXP = "", DIR = O, IOB_STATE=BUF PORT TXN = "", DIR = O, IOB_STATE=BUF PORT TOP_BREF_CLK_P = "", DIR = I PORT TOP_BREF_CLK_N = "", DIR = I The port list in EDK ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to BREF_CLK_P/BREF_CLK_N external output pins. I believe I have correctly defined the VHDL instances of the entity user_logic is ... RXP : in std_logic; RXN : in std_logic; TXP : out std_logic; TXN : out std_logic; TOP_BREF_CLK_P : in std_logic; TOP_BREF_CLK_N : in std_logic ); end entity user_logic; architecture IMP of User_Logic is signal TOP_BREF_CLK_i : std_logic; -- FAST reference clock going to MGT xcvr & buffered Ref clock signal USER_CLK_i : std_logic; -- Buffered FAST reference clock for user and MGT logic ... begin -- Differential Clock Buffers for top clock input diff_clk_buff_i : IBUFGDS_LVDS_25 port map ( I => TOP_BREF_CLK_P, IB => TOP_BREF_CLK_N, O => TOP_BREF_CLK_i ); -- Bufg used to drive user clk on global clock net user_clock_bufg_i : BUFG port map ( I => TOP_BREF_CLK_i, O => USER_CLK_i ); The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes anywhere user logic requires the fast clock. UCF settigns: ... # 156.25 MHz Diff Crystal Connection #same errors generated with/without IOSTANDARD spec. NET BREF_CLK_P IOSTANDARD = LVDS_25; NET BREF_CLK_N IOSTANDARD = LVDS_25; NET BREF_CLK_P LOC=AD14; NET BREF_CLK_N LOC=AE14; Error Output: ... ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple drivers. The possible drivers causing this are: pin O on block ibuf_245 with type IBUF, pin PAD on block BREF_CLK_N_IBUF with type PAD WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal input buffer ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal connection. Possible pins causing this are: pin O on block ibuf_245 with type IBUF ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple drivers. The possible drivers causing this are: pin O on block ibuf_244 with type IBUF, pin PAD on block BREF_CLK_P_IBUF with type PAD WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal input buffer ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal connection. Possible pins causing this are: pin O on block ibuf_244 with type IBUFArticle: 67971
"Spike" <me.hates:spam@me.net> wrote in message news:<YgD7c.53175$mU6.222519@newsb.telia.net>... > Thanks for you tip, I'll take it under consideration. > > Has anyone tried this one: http://www.plxtech.com/tools/rdk/9030rdk-lite.htm I didn't use the RDK, but I did do a board based on the 9030. I wrote a pretty damn complete bus-functional model of the 9030's local bus (PLX wanted it but we wouldn't give it to 'em). It all came together quite easily. > Does PLX PCI chips require some sort of EEPROM to store PCI configuration > space or any other information, if so what kind of ROM is needed? Yes, you'll need a serial EEPROM. It holds not only the PCI configuration info, but some other configuration info used by the chip (things like local-bus sizes, wait state info, chip-select info, etc.) Download the data sheets from PLX and everything will be revealed. -aArticle: 67972
Sam (rép. sans -no-sp-am) wrote: > Hi all ! > > Thank you for reading this message ! > > I would like to know how width are the busses between the registers of an > IIR filter (ie implemented in a FPGA), because these filters have coeffs > > 1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a > simple sin as input signal ! > > Could anybody help me ?? > > thanks in advance ! > > Sam FPGA stands for field-programmable gate array. With one, you implement whatever circuit you design (or choose). The number of bits in a design is whatever the designer decides. In parallel designs, the width of the busses is the bit count. In bit-serial designs, those numbers are uncoupled. With proper scaling, the size of a number and the bit count aren't necessarily related. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 67973
Thanks for the reply Matt, I took a look again at the ug024 pdf, and while REFCLKSEL was = 0 (to select brefclk, not brefclk2) and the ucf had REF_CLK_V_SEL=>1 (select brefclk_x and not refclk_x), i think the MGT instantiation was messed up. I relooked at the ML300 CPU schematics and GIGE0 uses pin A6/A7/A4/A5 for its RX/TX. I didnt readily find it in the V2P User Guide so I guessed it used MGT X0Y1... it was actually the other side of the chip, X3Y1, and since the brefclks could only be used in that same quadrant, I have a feeling that this may have played a role. I'll repost with my results after the changes. Tony On Tue, 23 Mar 2004 17:27:18 -0500 (EST), Matthew E Rosenthal <mer2@andrew.cmu.edu> wrote: >Tony, >I had similiar pin issues when I switched my design from the ml300 to a >memec board. >I am a little new to MGTs so bear with me. When instantianting a MGT you >have two places you have to tell it which clock inputs you are using. >1. in the UCF file under a parameter that looks similiar to >INST instname*mgt REF_CLK_V_SEL = 1 >2. in your HDL instantiation of your MGT you should have a parameter that >looks similiar to >REFCLKSEL => '1' > >Between the two places for each of those parameters there are 4 >options you can send the clock input into the MGT. > >So there are 4 locations you can send a clock into a MGT >REFCLK, REFCLK2, BREFCLK and BREFCLK2 > >and these inputs can only be mapped to certain pins on the fpga >so if your inputs are coming in on B14 and C14 you have to determine which >location on the MGT to send that too. > >You need to determine which pin locations can go to which clock input and >set all the values appropriately. > >I hope this helps > >Matt > >---------- Forwarded message ---------- >Date: Tue, 23 Mar 2004 21:52:27 GMT >From: Tony <tonym_98@nospam> >Newsgroups: comp.arch.fpga >Subject: IBUFDS -> BUFG > >Hello, > >I have a UCF problem regarding pin locations. >I am creating a custom PLB core that utilizes the MGT on an XV2P7. I >have dug my way through and up into the NgdBuild stage. The system is >using the system_hello EDK 6.1 ML300 reference design with >audioðernet stripped out to make room for the MGT core. We are >trying to use either the 125 MHz clock on Ppin-B14/Npin-C14 (4S/5P) or >the 156.25 MHz clock on Ppin-AD14/Npin-AE14 (6P/7S). > >Errors are generated when using either B14/C14 or AD14/AE14. I am not >sure what to do to fix the problem. Somehow IBUF's are being >instantiated, but nowhere in my code indicates this(maybe in EDK it >throws it in there?). There are similar tech solutions on xilinx.com >that tell you how to fix Synplicity problems that would create a >IBUFDS and IBUF on the same pad (and generate a similar problem to >mine), but I am using ISE 6.1.03 to work with EDK 6.1 sp2. > >Thanks, > >Tony > >PLB Core MPD file: >... >PORT RXP = "", DIR = I, IOB_STATE=BUF >PORT RXN = "", DIR = I, IOB_STATE=BUF >PORT TXP = "", DIR = O, IOB_STATE=BUF >PORT TXN = "", DIR = O, IOB_STATE=BUF >PORT TOP_BREF_CLK_P = "", DIR = I >PORT TOP_BREF_CLK_N = "", DIR = I > >The port list in EDK ties TOP_BREF_CLK_P/TOP_BREF_CLK_N to >BREF_CLK_P/BREF_CLK_N external output pins. > >I believe I have correctly defined the VHDL instances of the >entity user_logic is >... > RXP : in std_logic; > RXN : in std_logic; > TXP : out std_logic; > TXN : out std_logic; > TOP_BREF_CLK_P : in std_logic; > TOP_BREF_CLK_N : in std_logic > ); >end entity user_logic; > >architecture IMP of User_Logic is > >signal TOP_BREF_CLK_i : std_logic; -- FAST reference clock going >to MGT xcvr & buffered Ref clock >signal USER_CLK_i : std_logic; -- Buffered FAST >reference clock for user and MGT logic >... >begin > > -- Differential Clock Buffers for top clock input > diff_clk_buff_i : IBUFGDS_LVDS_25 > port map ( > I => TOP_BREF_CLK_P, > IB => TOP_BREF_CLK_N, > O => TOP_BREF_CLK_i > ); > > > -- Bufg used to drive user clk on global clock net > user_clock_bufg_i : BUFG > port map ( > I => TOP_BREF_CLK_i, > O => USER_CLK_i > ); > >The TOP_BREF_CLK_i goes direct to the MGT, while the USER_CLK_i goes >anywhere user logic requires the fast clock. > > > >UCF settigns: >... ># 156.25 MHz Diff Crystal Connection >#same errors generated with/without IOSTANDARD spec. >NET BREF_CLK_P IOSTANDARD = LVDS_25; >NET BREF_CLK_N IOSTANDARD = LVDS_25; >NET BREF_CLK_P LOC=AD14; >NET BREF_CLK_N LOC=AE14; > > >Error Output: >... >ERROR:NgdBuild:455 - logical net 'BREF_CLK_N_IBUF' has multiple >drivers. The > possible drivers causing this are: > pin O on block ibuf_245 with type IBUF, > pin PAD on block BREF_CLK_N_IBUF with type PAD >WARNING:NgdBuild:463 - input pad net 'BREF_CLK_N_IBUF' has an illegal >input > buffer >ERROR:NgdBuild:466 - input pad net 'BREF_CLK_N_IBUF' has illegal >connection. > Possible pins causing this are: > pin O on block ibuf_245 with type IBUF >ERROR:NgdBuild:455 - logical net 'BREF_CLK_P_IBUF' has multiple >drivers. The > possible drivers causing this are: > pin O on block ibuf_244 with type IBUF, > pin PAD on block BREF_CLK_P_IBUF with type PAD >WARNING:NgdBuild:463 - input pad net 'BREF_CLK_P_IBUF' has an illegal >input > buffer >ERROR:NgdBuild:466 - input pad net 'BREF_CLK_P_IBUF' has illegal >connection. > Possible pins causing this are: > pin O on block ibuf_244 with type IBUFArticle: 67974
Depends on your filter design. Implementing an IIR filter in fixed point usually has to use a rather wide word, and care needs to be taken in the selection of the coefficients in order to avoid nasty quantization effects. Implementation in an FPGA has little to do with the filter design other than the physical realization of it. "Sam (rép. sans -no-sp-am)" wrote: > Hi all ! > > Thank you for reading this message ! > > I would like to know how width are the busses between the registers of an > IIR filter (ie implemented in a FPGA), because these filters have coeffs > > 1. I have seen that the result of b0*x(n-1) can be as large as 5e5 with a > simple sin as input signal ! > > Could anybody help me ?? > > thanks in advance ! > > Sam -- --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
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