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
Richard Rooney wrote: > Any ideas on how to solve this - without re-writing 1000's of lines if code Write a wrapper that connects the buses your way to the busses that Xilinx tools write: Entity foo... busa : in std_logic_vector(3 to 17); -- your way ... component x_foo ... busa : in std_logic_vector(17 downto 3); -- Xilinx default ... x: x_foo port map ( busa(3) <= busa(3), -- all the busa signals must be listed in one group busa(4) <= busa(4), busa(5) <= busa(5), busa(6) <= busa(6), ... -- Phil HaysArticle: 27226
The Virtex DLLs can operate in either of two modes. One expects the feedback clock to be running at the input frequency. The other expects it to be running at 2x. The software figures out which mode to use. There is a description of this in XAPP132 on page 5. I'd expect this mode bit to be visible in FPGAEditor, but I can't find it there. Anybody know where to find this flag/bit? How can I verify that the (magic) software did what I expect? -- These are my opinions, not necessarily my employers. I hate spam.Article: 27227
I just found out that Synopsis wants $80K for a one year license of their Mot 5307 or 8260 instruction set model! I consider this an ARM and a leg!! My client will never go for this. I guess I'm back to just simulating the FPGAs and memories on the board, unless one of you out there knows of a cheaper alternative. -Simon Ramirez, Consultant Synchronous Design, Inc. ******************************************************************** > Does anyone here know of sources for microprocessor Verilog or VHDL > behavioral models? > I am doing a board level simulation that involves FPGAs, memories, > peanut components, and a Mot ColdFire microprocessor. I checked with Mot > about providing a C behavioral model or an encrypted Verilog/VHDL behavioral > model, and they referred me to the Big S -- Synopsis. This means that it > will cost an ARM and a leg, and I'm not talking about an ARM processor! > Does anyone know of alternatives? > -Simon Ramirez, Consultant > Synchronous Design, Inc.Article: 27228
Is there a mailing list for this newsgroup ? regards _______________________________________________________ Tired of slow Internet? Get @Home Broadband Internet http://www.home.com/xinbox/signup.html -- Posted from kuku-rwcmta.excite.com [198.3.99.63] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 27229
Michael Barr <mbarr@netrino.com> writes: >This is a cryptographically signed message in MIME format. >--------------ms4B962FB2094CDF47ED9278AE >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit >I've just (finally) gotten around to posting a three-part article I >wrote about a year ago on computing checksums and CRCs and the source >code that goes with it. The URLs of the three articles are: > http://www.netrino.com/Connecting/1999-11/ > http://www.netrino.com/Connecting/1999-12/ > http://www.netrino.com/Connecting/2000-01/ >If you're new to the subject, I recommend reading them in order. If, >however, you are familiar with the theory of checksums and CRCs and just >want to get directly into the CRC implementation, you can just read the >third. First of all, the aforementioned piece of code appears to be needlessly slow; the reflect() function will just nuke performance. To avoid nuking performance, nay, if you just want a piece of code that will BOMB performance, insteead of NUKING performance, see the fast table-based lookup algorithm in the appendix for the PPP protocol spec: http://www.cis.ohio-state.edu/htbin/rfc/rfc1331.html However, even this table lookup-based CRC algorithm will BOMB performance, and if you want a decent checksum that won't destroy your CPU, and have any freedom of design choice, YOU SHOULD DEFINITELY PICK A NON-GENERATOR POLYNOMIAL CHECKSUM. It just turns out that the typical 8-bit generator polynomial checksum, even with a table lookup implementation, requires 5 memory fetches to checksum each 32-bit word. Morevoer, the algebraic instructions to do this checksum HAVE NO DATAFLOW PARALLELISM, meaning a superscalar processor cannot achieve ANY speedup, and so you gigahertz pentium will run the checksum loop like an 8080 at 50 Mhz. If you compare this to the Internet's TCP/IP CRC (1's complement addition - a single memory fetch & add), you'll understand why we're throwing out telecom networks and installing Internet networks all over the earth... :) :) While it a 1's complement CRC-32 will not detect byte reordering, there are similar CRC's (Fletcher's Algorithm) that still run 10x faster than any generator polynomial checksum, and they detect byte reordering. Don Gillies - gillies@netapp.com - Network Appliance, Inc. Adjunct Professor of Computer Engineering, UBC, Vancouver BC Canada V6T 1Z4 http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.htmlArticle: 27230
I'm sure you get much better performance with the methods you suggest, provided that you don't count undetected errors as reducing performance. However, if undetected errors are important in your application, then those arithmetic checks suck badly compared to real CRC. I, in particular, have the misfortune to be working with a satellite communications provider that uses the Fletcher checksum for error control. We get corrupted data constantly. It only takes two "well-placed" bit errors to fool the Fletcher checksum. CRCs are bit-oriented, and so may not use a Pentium to its best advantage, but they're not that bad. My 16-bit CRC routine for the 8051 (idata), IIRC, takes 17 instruction cycles per bit (shift and XOR, not table lookup). And you get a lot more error detection power for your extra CPU cycles. I'm sure there are applications where speed is more important than correctness, but, for most embedded applications, I'd recommend CRCs over arithmetic checksums. -Dan PS: The word "cyclic" in "CRC" generally refers to a linear code which is invariant under cyclic shifts (although in error detection they are "shortened", and then no longer cyclic). Such a code necessarily has a generator polynomial. Calling arithmetic checksums CRCs is misleading, in my opinion. They are not in the same league. On 15 Nov 2000 20:14:39 -0800, gillies@cs.ubc.ca (Donald Gillies) wrote: > >First of all, the aforementioned piece of code appears to be >needlessly slow; the reflect() function will just nuke performance. >To avoid nuking performance, nay, if you just want a piece of code >that will BOMB performance, insteead of NUKING performance, see the >fast table-based lookup algorithm in the appendix for the PPP protocol >spec: > > http://www.cis.ohio-state.edu/htbin/rfc/rfc1331.html > >However, even this table lookup-based CRC algorithm will BOMB >performance, and if you want a decent checksum that won't destroy your >CPU, and have any freedom of design choice, > > YOU SHOULD DEFINITELY PICK A NON-GENERATOR POLYNOMIAL CHECKSUM. > >It just turns out that the typical 8-bit generator polynomial >checksum, even with a table lookup implementation, requires 5 memory >fetches to checksum each 32-bit word. Morevoer, the algebraic >instructions to do this checksum HAVE NO DATAFLOW PARALLELISM, meaning >a superscalar processor cannot achieve ANY speedup, and so you >gigahertz pentium will run the checksum loop like an 8080 at 50 Mhz. > >If you compare this to the Internet's TCP/IP CRC (1's complement >addition - a single memory fetch & add), you'll understand why we're >throwing out telecom networks and installing Internet networks all >over the earth... :) :) > >While it a 1's complement CRC-32 will not detect byte reordering, >there are similar CRC's (Fletcher's Algorithm) that still run 10x >faster than any generator polynomial checksum, and they detect byte >reordering. > > >Don Gillies - gillies@netapp.com - Network Appliance, Inc. >Adjunct Professor of Computer Engineering, UBC, Vancouver BC Canada V6T 1Z4 >http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.html >Article: 27231
Dan Kotlow <dank@micrologic.com> wrote in message news:3a138b05.91598579@news.ma.ultranet.com... > > I'm sure you get much better performance with the methods you suggest, > provided that you don't count undetected errors as reducing > performance. However, if undetected errors are important in your > application, then those arithmetic checks suck badly compared to real > CRC. > > I, in particular, have the misfortune to be working with a satellite > communications provider that uses the Fletcher checksum for error > control. We get corrupted data constantly. It only takes two > "well-placed" bit errors to fool the Fletcher checksum. > I agree with you completely, that the previous poster was misleading everyone by implying that the IP checksum is as good as a CRC (and Michael's articles referenced in the original post explain all that in detail). My question is that I am curious if a CRC would solve your specific problem. When you say that you get corrupted dataconstantly, do you mean that you get data with a valid checksum, even though it has been corrupted? Mathematically CRC is definitly better than a checksum, I have just not come across a real practical case where the difference could be identified. I suspect that it is a function of how large the packets are - 16 bits as a check on 100 bytes seems reasonable, but as a check on 10000 bytes seems riskier to me (but I do not know if there is a simple mathematical justification of that) - what is the ratio on your appication. If anyone knows a recommended ratio where you should switch to CRC I would be curious. Niall Murphy (http://www.panelsoft.com)Article: 27232
Hi all, I am rookie in programmable logic and I have just started getting in this subject. My question is: what is the difference between PLD, CPLD and FPGA? If I have a logical circuit and want to implement it in programmable chip what circumstances should I consider to choose a proper kind of chip? Is it so that PLD and CPLD are used for large combinational projects while FPGA are used for register-based circuits? Thank you in advance. DanielArticle: 27233
Hi, V Ram wrote: > I have a quick question... > > What third-party tools offer "good" schematic entry combined with the > ability to graphically hook up VHDL blocks? I have MaxPlusII which allows > this, but I'm using some outside tools for the VHDL synthesis and didn't > know if better third-party schematic entry tools existed. > > As far as I know, things like Renoir & Active HDL are only meant for > "block" diagrams and VHDL entry, not providing the ability to tack down a > DFF and some combinational logic, etc. > > I know Aldec has such a program and I think that's what is bundled with > the Xilinx Foundation tools and I wasn't too impressed. Any others? Anyone > use ViewDraw? > You may take a look at part 3 section 5 of the VHDL FAQ (http://www.vhdl.org/comp.lang.vhdl/). It lists some free and commercial VHDL <-> Schematic/FSM Translators. -- EdwinArticle: 27234
Hello!!! Iīm student and I still working on my diploma. In addition to the line up of my hardeware, I need support for configuring the JTAG-chain. My Boundary-Scan chain is built up with a Spartan XCS40 and an ISP XC18V512. The configuration of the FPGA via the ISP is established, but the direct JTAG download with the parallel Xilinx cable (required for JTAG-Programmer with XC18V00 devices) doesnīt work. Whenever I try to download the following messages appear: JTAGProgrammer:Release WebPACK 3.2WP3.x - JTAG Boundary-Scan Download D.23 Copyright:1991-1999 JTAG Programmer Started 2000/11/16 10:37:06 Loading Boundary-Scan Description Language (BSDL) file 'xc18v512_so20.bsd'.....completed successfully. Loading Boundary-Scan Description Language (BSDL) file 'C:/Xilinx_WebPACK/spartan/data/xcs40_pq208.bsd'.....completed successfully. Checking boundary-scan chain integrity...done. Verifying device positions in boundary-scan chain... Instance 'design_level_1_fpga4(Device1)' at position '1'...verified. Verification completed. Boundary-scan chain validated successfully. 'design_level_1_fpga4(Device2)': Checking boundary-scan chain integrity...done. 'design_level_1_fpga4(Device2)': Reading bit-stream file...done. 'design_level_1_fpga4(Device2)': Programming device.....done. 'design_level_1_fpga4(Device2)': Programming completed successfully. Oh fine, it should work, but on my hardware, the DONE-pin never changes to HIGH (also no changes on /INIT). The input TDI receives data via the TDO of the XC18V512. By the way, the JTAG-Programmer canīt read the ID from the Spartan FPGA. Whatīs wrong? Is that the reason for the failure? ChristianArticle: 27235
Hi, PLD/CPLDs: They use a 'crossbar' in connecting the different logical elements, each of them containing a FF and some simple logic. Classical application : state machine. In general: no additioal elements ( like memory ). Example: lattice/cypress/.. The difference between CPLDs and FPGAs are now disappearing :The new Cypress chip is another game. ( it is with memory ) FPGAs: The logical elements are connected via channels, so there structure is more like an asic than a cpld ( with all pros and cons ). Example: Xilinx ( often disscussed in this news ), Altera,Quicklogic,.. regards michael Daniel Hanczewski schrieb: > Hi all, > > I am rookie in programmable logic and I have just started getting in > this subject. > My question is: what is the difference between PLD, CPLD and FPGA? If I > have a logical circuit and want to implement it in programmable chip > what circumstances should I consider to choose a proper kind of chip? Is > it so that PLD and CPLD are used for large combinational projects while > FPGA are used for register-based circuits? > > Thank you in advance. > DanielArticle: 27236
Hi, if you want a low-cost tool and you are a friend of xilinx-chips you would probably be happy with their wep-pack 3.2i. (vhdl and verilog included, prob. as a beginner you need a textbook on synthesis) In this news wep-pack32i is often classified as useless, -i am using it without any relevant fault - it is with spartan2 and Virtex300 and download is free. As an alternate you may also concern the other big player Altera and there student edition. regards michael djley schrieb: > Would some one be interested in answering questions on this software. > I'm not a student but would like to learn and there is no support for this > product by Xilinx.Article: 27237
Niall Murphy <nmurphynews@panelsoft.com> wrote: > Mathematically CRC is definitly better than a checksum, I have just not come > across a real practical case where the difference could be identified. I > suspect that it is a function of how large the packets are - 16 bits as a > check on 100 bytes seems reasonable, but as a check on 10000 bytes seems > riskier to me (but I do not know if there is a simple mathematical > justification of that) - what is the ratio on your appication. If anyone > knows a recommended ratio where you should switch to CRC I would be curious. Well, let us start with the well known mathematical properties of a correctly implemented 16-bit CRC (e.g. CRC-CCITT or CRC-16), courtesy of Tanenbaum. It will detect errors as follows: - All single bit errors (as does a simple checksum) - All double bit errors - All errors with an odd number of bits - All burst errors of 16 bits or less - 99.997% of 17 bit burst errors - 99.998% of 18 bit or longer burst errors A "burst error" is one in which the first and last bits are wrong, and all the bits in between may be right or wrong. (If there are two or more burst errors in the message, they must be treated as a single burst error starting at the first bit of the first burst and ending at the last bit of the last burst.) These percentages assume the corruption pattern of burst errors are completely random. If not, these percentages may need to be reduced. An interesting example of this: if a CRC is preset to zero and transmitted without being complemented, then any message consisting of 16 or more zero bits will be regarded as correct. (A "burst error" which forces all bits to be zero.) I haven't seen the corresponding stats for a 32-bit CRC, but I expect the last three statements are simply replaced with 32, 33 and 34, with even higher percentages in the last two cases. Looking at random single bit errors, assume there is a very low probability P of an error occuring for each bit in the message. The longer the message, the higher the probability that there will be at least one error. For N bits, the probability of at least one error is (1-(1-P)^N). If this number is too large, then you are not likely to get very many messages through, so in a relatively noisy environment it is a good idea to keep N as low as possible by limiting the maximum message length. For the CRC to fail (i.e. pass a erroneous message without flagging a CRC error), you need a minimum of four single bit errors, and the first and the last error must be at least 17 bits apart. As it is after midnight and my brain has switched off, I don't want to go through the maths for this right now, but you should be able to see that the longer the message, the higher the probability of this occurring. We then have to take the 99.998% figure into account (i.e. 0.002% of burst errors will slip through) to calculate the probability of an undetected error. There are also real burst errors to consider, i.e. a short burst of completely random noise which ends up corrupting a consecutive range of bits in the message. These are harder to analyse and depend to some extent on what sort of bursts might be expected on a particular transmission medium (e.g. colliding transmissions from other stations, power surges, or whatever). The likelihood of multiple burst errors needs to be considered as well, as well as the likelihood of one or more random single bit errors in the same message as a real burst error. Assuming you can pick some reasonable figure for the probability of a burst error and its possible length, you should be able to calculate the probability of it passing undetected, and add this to the above figure for random single bit errors to determine the total probability of an undetected error. Good luck! The decision about a reasonable "maximum length" may be influenced by the expected probability of errors (of either type). On a relatively error-free link it may be acceptable to send quite long messages with a 16-bit CRC to detect the occasional error. If the error probability is high enough then the maximum message length should be reduced so that the number and length of retransmissions can be kept to a minimum. If there is a reasonable possibility of getting at least four errors in a single message then there is a slim chance of an erroneous message slipping through; reducing the maximum message length may help to reduce the likelihood of this.Article: 27238
Hi, by default FGPA Express will init all Registers in my Spartan device to zero. How can I change this default? When doing schematic entry this was easyly done by adding "INIT=S" But how can I do this with VHDL? Thanks peterArticle: 27239
Tom Branca wrote: > > Hello Utku, > I think I would use the area group constraints in this situation, > rather than the LOC range constraints. Area groups allow you to define > groups of logic by assigning logical instance to a specific area group, > then you can assign this area group to a specific range in the device. > There is more flexibility with area groups because you can specify the > type of resource that you want constrained to the area via the RANGE > constraint. I have included some syntax and usage information for the > area group constraint below. > > Cheers, > Tom Tom, thank you for your response. The AREA_GROUP is not supported by M2.1i SP6. As I stated in my first posting, I am using M2.1i SP6. UtkuArticle: 27240
Daniel - A bit of a gray definition, but . . . PLD - Macrocell (product term) architecture, rich in combinatorial logic, not too many flops. Do a good job with state machines, arbiters / address decoders, etc. Claim to fame is speed from input to output (as little as 4 ns) and non-volatility (PROM or flash based) CPLD - Altera terminology (complex PLD), associate this with FPGA FPGA - Typically lookup table architecture (4-input lut with a flop is prevalent architecture, although others use more of a mux - 8 inputs in some Actel devices). These devices go up into the 40-50k luts & flops with internal memory. Applications tend to be more data / data path oriented due to large FLOP resources. The big boys (Xilinx and Altera) are SRAM based (i.e. volatile, need to be programmed at power up with an external prom or flash), other variations are OTP or flash-based. In a nutshell, you'll see PLDs in smaller, fast applications, FPGAs where more resources are needed - I don't mean to denigrate the FPGA's on speed, though - they're extremely fast these days, too. I see CPLD's more in glue logic applications and FPGAs where you're doing data manipulations. If you really want to get a thread started, ask which one is best!!! Steve "Daniel Hanczewski" <danhan@wp.pl> wrote in message news:3A13A3EE.7CD09B9C@wp.pl... > Hi all, > > I am rookie in programmable logic and I have just started getting in > this subject. > My question is: what is the difference between PLD, CPLD and FPGA? If I > have a logical circuit and want to implement it in programmable chip > what circumstances should I consider to choose a proper kind of chip? Is > it so that PLD and CPLD are used for large combinational projects while > FPGA are used for register-based circuits? > > Thank you in advance. > Daniel >Article: 27241
Peter Lang wrote: > > Hi, > by default FGPA Express will init all Registers in my Spartan device to > zero. > How can I change this default? > When doing schematic entry this was easyly done by adding "INIT=S" > But how can I do this with VHDL? Try: signal widget: std_logic_vector(7 downto 0); -- my register Reg: process (Clk,Reset) begin if Reset = '1' -- If asynchronous reset then widget <= (others => '1'); -- then set flop to one elseif rising_edge(Clk) -- else if clock then -- then whatever ... end if; end process; ---- KeithArticle: 27242
Well, in the olden days of mainframe computers, the larger IBM systems came with a memory that read something like 32 bits of data and 8 bits of crc with each memory reference. There was a special trick that the service people did to find out if the memory controller was seeing (and correcting) errors. Never did a day go by that there was not an error. Simple parity checks helped, but did not allow correction of the data. If the bit in question did something serious, like say "dump the air from the space station" or "reset and reboot all the flight contorl logic in the aircraft" the problems could be quite spectacular. There are hardware implementations for crc in existance, for those who need speed. I guess it just depends on how important the accuracy offthe data is. After all, in the telephone networkm if Aunt Minnie sounds a little off, nobody will likely care. OTOH, if a missile gets launched at the wrong country because a bye gets exchanged with another, I suspect a lot of folks would care, at least for a short time. Speaking only for myself, Joe Durusua Niall Murphy wrote: > > Dan Kotlow <dank@micrologic.com> wrote in message > news:3a138b05.91598579@news.ma.ultranet.com... > > > > I'm sure you get much better performance with the methods you suggest, > > provided that you don't count undetected errors as reducing > > performance. However, if undetected errors are important in your > > application, then those arithmetic checks suck badly compared to real > > CRC. > > > > I, in particular, have the misfortune to be working with a satellite > > communications provider that uses the Fletcher checksum for error > > control. We get corrupted data constantly. It only takes two > > "well-placed" bit errors to fool the Fletcher checksum. > > > I agree with you completely, that the previous poster was misleading > everyone by implying that the IP checksum is as good as a CRC (and Michael's > articles referenced in the original post explain all that in detail). My > question is that I am curious if a CRC would solve your specific problem. > When you say that you get corrupted dataconstantly, do you mean that you get > data with a valid checksum, even though it has been corrupted? > > Mathematically CRC is definitly better than a checksum, I have just not come > across a real practical case where the difference could be identified. I > suspect that it is a function of how large the packets are - 16 bits as a > check on 100 bytes seems reasonable, but as a check on 10000 bytes seems > riskier to me (but I do not know if there is a simple mathematical > justification of that) - what is the ratio on your appication. If anyone > knows a recommended ratio where you should switch to CRC I would be curious. > Niall Murphy (http://www.panelsoft.com)Article: 27243
So Can i lock the pin number in the VHDL file? If yes what is the syntax? Dan <daniel.deconinck@sympatico.ca> wrote in message news:OqVN5.26401$1C6.1280515@news20.bellglobal.com... > My pin locs are based on my PCB needs. > > I like the PCB routing to flow out radially away from the FPGA in all > directions. I can route directly to memory/ buses / ADCs/ DACs etc. with > next to no vias. Its a beautiful thing. > > Only if the design is going to challenge the FPGA do I reconsider this > approach. > > Dan > > >Article: 27244
Tim Jaynes wrote: > > The problem essentially boils down to the fact that you've used: > > > > > CLB/Slice Constraint: CLB_RnCm > > > > But should have used: > > > TBUF: TBUF_RnCm > > > > a LOC is fine, you just need to use the right element group. > Tim When you use LOC=TBUF_* then FMAP and HMAP will conflict with LOC=CLB_*. When you use LOC=CLB_* then TBUF elements will conflict with LOC=TBUF_* You must use both commands at the same time (Xilinx support): INST "..." LOC=CLB_* INST "..." LOC=TBUF_* But when a INST "..." contains TBUF, CLB and RAMB4_* elements at the same time, there is no solution yet announced by Xilinx. MAP always gives an error, if you use three LOC: INST "..." LOC=CLB_* INST "..." LOC=TBUF_* INST "..." LOC=RAMB4_* Isn't there anybody in the world who has tried this? UtkuArticle: 27245
HI All, Here's a seemingly easy problem that has me running for the hills!!! Using Synplify to construct edif listings that are later pulled into Actel's designer. Problem seems to be that Synplify is using pre-define MACROS that construct an HCLK like architecture. Problem is that I am NOT using this HCLK architecture for the overall design. Thus, Synplify constructs an FPGA using macros that construct this HCLK stuff that I am NOT using. Granted, I am using the high performance IOCLKs, but NO WHERE do I use this HCLK. THE PIN IS EMPTY!!! THE VHDL DOES NOT CALL FOR THEM!!! HELP!!! HELP !!!!! HELP!!!!!! jhbuchanan@west.raytheon.comArticle: 27246
You need to set the start-up clock to the JTAG clock in the configuration options during bitstream generation. That should fix your problem. Christian Reichherzer wrote: > > Hello!!! > > Iīm student and I still working on my diploma. In addition to the line up of > my hardeware, I need support for configuring the JTAG-chain. > My Boundary-Scan chain is built up with a Spartan XCS40 and an ISP XC18V512. > The configuration of the FPGA via the ISP is established, but the direct > JTAG download with the parallel Xilinx cable (required for JTAG-Programmer > with XC18V00 devices) doesnīt work. Whenever I try to download the following > messages appear: > > JTAGProgrammer:Release WebPACK 3.2WP3.x - JTAG Boundary-Scan Download D.23 > Copyright:1991-1999 > JTAG Programmer Started 2000/11/16 10:37:06 > Loading Boundary-Scan Description Language (BSDL) file > 'xc18v512_so20.bsd'.....completed successfully. > Loading Boundary-Scan Description Language (BSDL) file > 'C:/Xilinx_WebPACK/spartan/data/xcs40_pq208.bsd'.....completed successfully. > Checking boundary-scan chain integrity...done. > Verifying device positions in boundary-scan chain... > Instance 'design_level_1_fpga4(Device1)' at position '1'...verified. > Verification completed. > Boundary-scan chain validated successfully. > 'design_level_1_fpga4(Device2)': Checking boundary-scan chain > integrity...done. > 'design_level_1_fpga4(Device2)': Reading bit-stream file...done. > 'design_level_1_fpga4(Device2)': Programming device.....done. > 'design_level_1_fpga4(Device2)': Programming completed successfully. > > Oh fine, it should work, but on my hardware, the DONE-pin never changes to > HIGH (also no changes on /INIT). The input TDI receives data via the TDO of > the XC18V512. > By the way, the JTAG-Programmer canīt read the ID from the Spartan FPGA. > Whatīs wrong? Is that the reason for the failure? > > Christian -- -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 or http://www.fpga-guru.comArticle: 27247
Yes, but it is quite a bit easier to do it in a UCF file. TO do it in VHDL, you need to create an attribute called LOC and attach it to each IOB, which means you also have to instantiate the IO buffers rather than letting the tool infer them attribute LOC:string; attribute LOC of iob_name:label is "P111"; begin iob_name:OBUF port map( ... Qian Zhang wrote: > > So Can i lock the pin number in the VHDL file? > If yes what is the syntax? > Dan <daniel.deconinck@sympatico.ca> wrote in message > news:OqVN5.26401$1C6.1280515@news20.bellglobal.com... > > My pin locs are based on my PCB needs. > > > > I like the PCB routing to flow out radially away from the FPGA in all > > directions. I can route directly to memory/ buses / ADCs/ DACs etc. with > > next to no vias. Its a beautiful thing. > > > > Only if the design is going to challenge the FPGA do I reconsider this > > approach. > > > > Dan > > > > > > -- -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 or http://www.fpga-guru.comArticle: 27248
On Wed, 15 Nov 2000 21:41:34 +0000 (UTC), V Ram <ipickledthefigsmyeslf@mrbourns.com> wrote: >I have a quick question... > >What third-party tools offer "good" schematic entry combined with the >ability to graphically hook up VHDL blocks? I have MaxPlusII which allows >this, but I'm using some outside tools for the VHDL synthesis and didn't >know if better third-party schematic entry tools existed. > >As far as I know, things like Renoir & Active HDL are only meant for >"block" diagrams and VHDL entry, not providing the ability to tack down a >DFF and some combinational logic, etc. You _can_ do that in Renoir; at the gate/VHDL level if you so wish (after making components for your DFF's etc) or by inserting a text block containing combinatorial expressions. It's not as convenient a way to build a complete schematic but it's fine for augmenting a block diagram with moderate quantities of glue logic. - BrianArticle: 27249
I have a Xilinx Parallel Cable III, model DLC5, labeled as operating at 5v. Does anyone know if this will work with a 2.5vccint/3.3vcco Spartan II board? I'm using the Insight Electronics Spartan II board. - Cotton
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