Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
ibaggett@bagotronix.com wrote in message <36d5f498.70312347@news.nettally.com>... > I have yet to find a good >tutorial on VHDL - the textbooks I've seen are written by people who >are gurus but obviously have never designed actual hardware to fit >into real FPGAs to go into real products. It is difficult to learn VHDL from many textbooks. There are some decent textbooks aimed at VHDL for beginers, and then there are some decent textbooks aimed at experts, but briding the gap can be difficult if you don't already know some VHDL expert or have some format instruction. >Supposedly VHDL has applicability to other areas besides digital >logic, so is touted as the "holy grail" of description languages. Some people would tout Verilog as the holy grail. :-) > All I want to do is synthesize digital logic for real parts. How complex are those parts? One of the really significant benefits of VHDL is that you can write very sophisticated test benches within VHDL itself. It is far more powerful than the simple "test vector" facility that ABEL provides. (I realize that most vendors can provide some other means more sophisticated than this for testing, but do you really want to learn another tool to do it?) I can't begin to imagine doing something like a PCI master in ABEL -- testing it would be a nightmare. >Just remember, market forces are bigger than you are, and the market >forces say "VHDL" :-( I really think this is because designers are being asked to design more and more complex designs, and ABEL just can't handle those "million gate designs" that the trade magazines like to reference. ---Joel KolstadArticle: 14951
I stared at the data sheet [1] for the Virtex long enough to figure out
how the Carry Chain works on the Logic Cell (hint for anyone who has as
much trouble as I did: configure the LUT as an XOR of F1 and F2, then
look carefully at the mux labelled "CY" in figure 5).
Now I'd like to understand how this part is supposed to do multiplications
effectively. They say it several times.
On page 1:
"* Flexible architecture that balances speed and density
- Dedicated carry logic for high-speed arithmetic
- Dedicated multiplier support
- Cascade chain for wide-input functions"
On page 2 (Table 2):
"Pipelined Multiplier 8 x 8 5.1 ns
16 x 16 6.0 ns"
On page 8:
"The arithmetic logic includes an XOR gate that allows a
1-bit full adder to be implemented within an LC. In addition,
a dedicated AND gate improves the efficiency of multiplier
implementation."
On page 30:
"Multiplier Operation TBYP 0.1 0.2 0.2 ns, max
F1/2 operand inputs to XB output via AND TFANDXB 0.4 0.5 0.6 ns, max
F1/2 operand inputs to YB output via AND TFANDYB 0.5 0.6 0.6 ns, max
F1/2 operand inputs to COUT output via AND TFANDCY 0.5 0.5 0.6 ns, max
G1/2 operand inputs to YB output via AND TGANDYB 0.4 0.4 0.5 ns, max
G1/2 operand inputs to COUT output via AND TGANDCY 0.4 0.4 0.5 ns, max"
That last section give some clues, but I don't have the big picture yet.
Has anyone else looked at this?
- Larry Doolittle <ldoolitt@jlab.org>
[1] http://www.xilinx.com/partinfo/virtex.pdf, January 27, 1999 (Version 1.2)
Article: 14952I have heard that for some reason, pulling both TMS and TCK low can also cause a problem (not sure why or how). If I remember correctly, it's best to pull TCK low and TMS high to prevent false clocking. Ying In article <36D5EEBD.EEC7DCA@erols.com>, Jim <jok@erols.com> wrote: >I think in this particular glitch the part relied on a >power up reset based on ramp voltage of the Vdd. I will not mention >vendor, but it appears to save pins they neglected to provide >a specific reset pin, but recomend pulling both clk and data high. >But, if race between clk and data... and clk wins we get 0 into >jtag controller. The solution was to pull them low during power >up. > >Mike H. wrote: >> >> Jim wrote in message <36D4AA69.E95CB74@erols.com>... >> >Any folks run into any JTAG gotchas with pulling up the >> >tdi and tclk pins? >> >> The only problems I've experienced have been with the >> /TRST pin, which seems to be interpreted differently >> by different devices. Some like it pulled up when the >> JTAG port isn't being used, some like it pulled down. >> Can lead to operational inconsistencies. >> >> Mike H.Article: 14953
Bill wrote: > I'm using 95144XLTQ100 and have found that 1.5i+sp1+cpld_020799 still don't > produce correct jedec files. Simulation and verification produce OK results. > > The main problem is that FDCE is now a primitive in XL (it wasn't in the 5V > parts)and when loaded into an XL produces a 1 on the ouput continuously. > Implementing FDCE using an FD and M2_1 is OK. > > Anybody else got this problem and are there any more I don't know about ? > > Bill Bill, There is currently a fix being tested that will have what you need for the 95144XL jedec creation. This will be available by the end of next week. The known issue addressed with this upcoming patch as you mentioned affects only the new 9500XLs and not the 9500 family. M2_1 also has these changes. Best Regards, Stephanie -- _____________________________________________________________ | _ | | / /\/ Stephanie Tapp (stapp@xilinx.com) | | \ \ / Xilinx | | / / \ 2100 Logic Drive | | \_\/\ San Jose, California 95124-3450 USA | | phone:408-559-7778 | | fax:408-879-4442 | |_____________________________________________________________|Article: 14954
> I can't begin to imagine doing something like a PCI master in ABEL -- > testing it would be a nightmare. Why do you say that? The state machines are very simple, in fact, I've done it with no problem at all in ABEL, VHDL, and schematic. It is the timing of the PCI input signals that makes ANY PCI master difficult...and you will have that same problem no matter what the design tool you choose. That may be a bad example. > I really think this is because designers are being asked to design more and > more complex designs, and ABEL just can't handle those "million gate > designs" that the trade magazines like to reference. I don't know about you, but no matter WHAT tool I am using, I try to break down the task in to smaller pieces, so they are less complex and easier to implement. I think 100 pages of VHDL is easily as obtuse (if not more so ;-) than 100 pages of ABEL. VHDL is tremendously more powerful than ABEL, but that doesn't mean you can't do a very good job with ABEL, if you use the tool appropriately. Austin Franklin austin@darkroom.comArticle: 14955
If you look at the carry chain, that little AND gate that can be selected for the carry is not needed for addition/subtraction and increment/decrement. Program the LUT with A xor B. That provides the partial bit sum, which is then summed with the carry in by the dedicated XOR. The partial sum also operates the carry mux: if it is a 1 it selects the carry chain input (if the partial sum is 1 then one and only one of the A and B inputs are 1, so the carry out is the same as carry in). If the partial sum is zero, then either both A and B are 0 or both A and B are 1, so one of them (it doesn't matter which) is fed to the carry out so that if it is one there is a carry out generated. So that little AND gate is not needed for regular operations. Now, that AND gate is added to 'make multiplication more efficient'. It does that if you are implementing an array multiplier in row ripple form (which is probably what you will get if you give a synthesizer A*B). In that case, the LUT should be programmed with (X&Y)^S where X and Y are the bit inputs to be multiplied and S is the partial sum from the previous row. If that gate were not there, then it would have to be implemented in another LUT, which would be quite inefficient. OK, so that is how a multiplier is supposed to be more efficient in virtex. You can still improve on that multiplier's area and performance by going with a computed partial product multiplier implemented as shown on my web-site. Funny thing, is last time I looked at the LogicCore output for 4K, the tool generates the computed partial product multiplier. That means that someone in Xilinx understands the efficiencies. Whoever designed the Virtex carry chain probably didn't though. The pipelined partial product multiplier has similar speed characteristics and a log(n) clock latency instead of an n-clock latency. The fact of the matter is either type of multiplier can be constructed in xilinx 4K...The array multiplier uses a conditional adder that either adds the row or passes the partial sum unchanged instead of an adder with an AND gate on the input. This still only requires a logic depth of 1 CLB per row! The worst part, is Xilinx apparently rearranged the carry chain in order to be able "support efficient multipliers". Unfortunately, they lost a lot of non-arithmetic capability in the process (see my previous post), including a very compact bargraph circuit (used in priority encoding and framing logic). The new carry architecture also forces you to use the LUT if you want to use the carry chain. The 4K carry chain can be used independently of the LUT, which is handy for a compare like that used in doing a limiter or 2's complement. Larry Doolittle wrote: > I stared at the data sheet [1] for the Virtex long enough to figure out > how the Carry Chain works on the Logic Cell (hint for anyone who has as > much trouble as I did: configure the LUT as an XOR of F1 and F2, then > look carefully at the mux labelled "CY" in figure 5). > > Now I'd like to understand how this part is supposed to do multiplications > effectively. They say it several times. > On page 1: > "* Flexible architecture that balances speed and density > - Dedicated carry logic for high-speed arithmetic > - Dedicated multiplier support > - Cascade chain for wide-input functions" > On page 2 (Table 2): > "Pipelined Multiplier 8 x 8 5.1 ns > 16 x 16 6.0 ns" > On page 8: > "The arithmetic logic includes an XOR gate that allows a > 1-bit full adder to be implemented within an LC. In addition, > a dedicated AND gate improves the efficiency of multiplier > implementation." > On page 30: > "Multiplier Operation TBYP 0.1 0.2 0.2 ns, max > F1/2 operand inputs to XB output via AND TFANDXB 0.4 0.5 0.6 ns, max > F1/2 operand inputs to YB output via AND TFANDYB 0.5 0.6 0.6 ns, max > F1/2 operand inputs to COUT output via AND TFANDCY 0.5 0.5 0.6 ns, max > G1/2 operand inputs to YB output via AND TGANDYB 0.4 0.4 0.5 ns, max > G1/2 operand inputs to COUT output via AND TGANDCY 0.4 0.4 0.5 ns, max" > > That last section give some clues, but I don't have the big picture yet. > Has anyone else looked at this? > > - Larry Doolittle <ldoolitt@jlab.org> > > [1] http://www.xilinx.com/partinfo/virtex.pdf, January 27, 1999 (Version 1.2) -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14956
Holding either one high during configuration prevents the JTAG controller being accidentally activated. If TMS is low and TCK is toggled, the controller could activate and screw up the configuration. Ying C. wrote: > I have heard that for some reason, pulling both TMS and TCK low can also > cause a problem (not sure why or how). If I remember correctly, it's best > to pull TCK low and TMS high to prevent false clocking. > > Ying > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14957
Well, Looks like I was all wet on this one! The AND gate doesn't buy you anything in the row ripple form except on the first row. In the row ripple form, each full adder has an AND gate on one input. If you put that on the A input and feed the B input to the carry MUX, the AND gate is not needed. So why is it there? Well, it turns out (which I finally realized after a gentle prod from a person polite enough not to flame me here) that if you use the AND in the carry logic, you can sum two bit products in half a slice. The first product's AND is buried in the LUT as mentioned above. The second has to go on the B input. If the AND weren't there, then the second AND would have to be in another LUT. With it there, the LUT should be programmed with (X1&Y1)^(X0&Y0) so that the column of LUTs sums two 1xN partial products (rows) to arrive at a 2xN partial product. These partials are then combined in an adder tree the same way I do for the computed partial product multiplier I described previously. The efficiency comes in when you realize that the mux in my computed partial product design requires a 5 LUT to implement, which means that it takes up more than half a slice (or 4K CLB). The little AND gate and the new carry architecture allow you to compute each bit of the 2xN partial product in a 4LUT, so the size of the partial products is halved. Computing the partial products is a little more than half the multiplier's overall size in the 4K, so cutting the PP size in half is worth quite a bit. So there is the real truth about the efficient multiplier. Mrrmmph. I hear crow might taste good cooked like buffalo wings. I still will miss the flexibility of the 4K carry chain though (whining mode). Ray Andraka wrote: > A major rant about the virtex carry chain with a hastily drawn conclusion. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14958
Hello, I am new to this program, so maybe you can tell me what I'm doing wrong. Each and every time I run the MAP program (by hitting the Implementaton button) I get the GPF error. See log excerpt below. It doesn't matter which project I'm running. The PC is a Pentium 166 with 128 Meg. Many thanks, David Langmann david@dalanco.com NGDBUILD Design Results Summary: Number of errors: 0 Number of warnings: 4 Writing NGD file "filter.ngd" ... Writing NGDBUILD log file "filter.bld"... NGDBUILD done. ================================================== map -p xc4003e-4-pc84 -o map.ncd filter.ngd filter.pcf map: version M1.5.25 Copyright (c) 1995-1998 Xilinx, Inc. All rights reserved. PROGRAM ABNORMALLY TERMINATEDArticle: 14959
OK, here are some REALLY basic questions I have about programmable logic. What is the difference between an FPGA and a CPLD? I know that with schematic capture or VHDL software, one can compile code and download it into a programmable logic device through a parallel port, but what sort of additional hardware is needed to interface between the port and chip? Lastly, what other good sources (urls or book titles would be much appreciated) would you recommend for learning more about programmable logic and VHDL. Thanks in advance... --------------------------------------------- Francesco Spadini Department of Electrical and Computer Engineering University of IIlinois at Urbana Champaign spadini@uiuc.edu "Nec vitia nostra nec remedia pati possumus" ---------------------------------------------Article: 14960
Sergio A. Cuenca Asensi wrote: > Yes, I've synthesized all three as top-level modules. I want three independent > modules but without starpup blocks, the problem is that I can't find any option > in FPGA express to avoid startup adding to them. Do you know where is it? I'm not sure you can have a chip with more than one top-level module! Why would you want to do that???? -andyArticle: 14961
Joel Kolstad wrote: > From what you say, it sounds safe to do any of the following: > > -- Ground the reset pin on the macro > -- Leave it floating (probably a bad practice, though, from the > documentation point of view) > -- Connect it to the reset output of the startup block > > In the first two instances, nothing will get routed to the 'flops reset/set > line and only GSR will be able to reset/set it. In the last instance, PAR > should be smart enough to figure out that resetting/setting a flop from GSR > itself is redundant and realize that actually consuming routing resources to > connect to the reset/set on the 'flop is unnecessary. Connecting the macro's reset line to the GSR output tells PAR to use the global reset nets for all flops connected to that reset line. > If I did have an external reset, I believe the correct thing to do would be > to connect it to the startup block. The wrong thing to do would be to > connect it directly to the macros' reset inputs, since then the reset > connections would consume routing resources. > > Is that correct? that is correct. aArticle: 14962
David Langmann wrote: > > Hello, > > I am new to this program, so maybe you can tell me > what I'm doing wrong. > > Each and every time I run the MAP program > (by hitting the Implementaton button) I get the GPF > error. See log excerpt below. It doesn't matter which > project I'm running. A-ha! I've had the same problem. There's a bug somewhere. Once I got ahold of the right tech support person at Xilinx, I was able to get a patch. If you can wait until Monday, I will e-mail the patch to you. I was able to find a workaround, which was simply changing the order of parameters passed to the map program. The patch fixes it. -andyArticle: 14963
This particular article has really made the rounds! I have received it from several sources now, so there must be something here that everyone feels important. What is the message in this article, the imminent demise of the FPGA industry? I think not. The fact one person from one customer, Cisco, thinks that in the future Cisco will use a higher ratio of ASICs to FPGAs then it does at present does not spell the end of an industry. It only stands to reason and should not come as a great surprise that Cisco is projecting this change. Cisco is a classic Silicon Valley success story. When the market was small but very dynamic FPGAs were the best answer to the problem of how to get new innovative solutions out the door quickly. As Cisco develops more of it's products will be very high volume standard products, a natural ASIC situation. So because one very high volume FPGA customer is going to be buying ASICs in the future does this mean the end of programables? What about the other start-ups? Will Cisco be the last Silicon Valley start up? Will these start-ups open their shops and immediately have the kind of volumes and product sophistication to go to market with ASICs? No they won't, rather they will follow the same path as others to very high volume, they will start with programables. So there are new customers coming every day, the fact that one matured to ASICs is not a bad thing for the industry rather it should be taken as a fantastic example of how using FPGAs can lead to industry domination. For that matter while Cisco will have a higher percentage of very established standard products built from ASICs in their product mix, I do not see them giving up on attempts to innovate within the industry and what technologies will they first test out their innovations with??? Programables. My personal bet is that Cisco will be a high volume buyer of programmable logic for a long time. In the future it is possible that as a percentage of Cisco’s total semi conductor purchases the ratio could change more to ASICs, Cisco will still buy a whole lot of programables. The article also brings up the possibility that in the future programmable logic will have different and improved functionality then it does now? Of course it will! The I/C industry is the fastest changing most dynamic industry ever seen in this world, as part of the IC industry programmable logic has lead even this dynamic industry in innovation. So to say that there is change on the horizon in the FPGA market is equivalent to making an announcement that the sun will come up in the east tomorrow. It is correct statement but with enough past history that this should not come as a surprise to even the most casual observer. The only real question of interest in the whole article is the projections of the future of programables. Programables has gotten to the point where past practice of product innovation, adding more logic then the last generation of the product, is not enough to maintain industry leadership. Features such as clock control circuits and embedded memories are becoming standard in the latest programables. This trend of increasing features as well as increasing speed and density is bound to continue. Many companies are talking about hard microprocessor cores within an FPGA part; Lucent is all ready offering a hard PCI core with their FPGAs. What is the right mix? A little bit of hard logic and a lot of programmable logic on a chip, or the alternative that is mentioned in this article mostly custom hard ASIC with a small programmable core on the die? Is this even practical? Process technology drives everything in the semiconductor industry; I have seen comments stating that from a process point of view hard ASICs with FPGA blocks on board could be a non-cost effective solution. I am sure I can find some proponent to argue each and every side of this technology debate, as the future of the industry is something that will effect us all and future is very hard to be sure of in something as dynamic as the high tech biz. I still have not figured out why this particular story went around like it did. Maybe we all just like to hear that the superstar has something bad in their future. Doom and gloom sells a lot of TV time after all. Have FUN!!!! Nick Zhen Luo wrote: > Hi, > > I read the following article on EE times today. What do you think about > it? I think the problems they mention in this article have always been > there, but it seems that this is the first time people really use the > word "dark future" for programmable logic. What do you think? > > -- Zhen > > FPGA'99: Panel glimpses dark future for > programmable silicon > > By Ron Wilson > EE Times > (02/23/99, 11:19 a.m. EDT) > > MONTEREY, Calif. — A panel at FPGA'99 here Monday > (Feb. 22) > peered into the future of FPGAs in the era of > system-level ICs and saw > deep shadows. While FPGA-vendor panel members touted > the ability of > huge new FPGAs to easily absorb large pieces of > intellectual property (IP), > or for hard IP macros to be integrated onto FPGA > dice, panelists from the > research and user communities saw things very > differently. > > In opposition to the notion that you can simply put > an entire system-level > design into an FPGA, University of Washington > professor Carl Ebeling > warned, "If all you have is a hammer, everything > looks like a nail. But if we > keep thinking that everything looks like it has an > FPGA solution, we could > get screwed." > > Beyond the initial levity, Ebeling warned that for > many applications, it is > simply not good enough for an FPGA to do tomorrow > what an ASIC can > do today. "The gaps in power consumption and > performance between > FPGAs and ASICs aren't narrowing, they are growing > wider," he said. > "And those gaps are pushing more and more high-end > applications not > toward FPGAs, but toward ASICs." > > Admitting that not everything can be done well in an > FPGA, University of > California Los Angeles professor Jason Cong said even > adding some > diffused hard cores to a chip doesn't solve the > problems. Cong, whose > influential work produced some of the first tools > that could systematically > map logic into the SRAM blocks on Altera Corp.'s Flex > devices, warned > that "the devil is in the software." > > "There are very substantial problems in creating > design software for devices > that include both FPGA and hard blocks," Cong said. > "Among them, it is > quite difficult to automatically partition an > algorithm among heterogeneous > resources, even such common resources as programmable > logic and > SRAM. If you can do the partitioning, it is difficult > to optimize the > implementation of parts of the algorithm on each kind > of resource. And if > you solve that problem, there are still very hard > problems involved in > run-time communication between different kinds of > blocks, scheduling and > the like." > > But if the arguments against incorporating either > soft or hard IP into FPGAs > were strong, the most sobering statements of the > night came from a > customer — a very influential customer. > > "We are a major consumer of FPGAs," said Bill Harris > of Cisco Systems > Inc. And Harris' data showed he was being modest. > Cisco claims to be > currently the largest single user of programmable > logic, shipping over one > million PLDs of various sorts per month. > > Once he had the audience's attention, Harris lowered > the boom. "Despite > that, I have to say that for large systems our trend > is to ASICs, not to > programmable-logic devices. On the systems that make > up our platforms, > we will spin an ASIC rather than use an FPGA." > > Harris explained that a major phase was over in the > halcyon relationship > between the networking industry and the FPGA > business. "In the beginning, > it was a small Cisco competing against other small > companies. > Time-to-market was everything, and cost wasn't an > issue. If we could get > the latest speed grade of an FPGA, we'd throw it in > just so we could start > shipping." > > But times are very different now in the industry, > Harris said. "Now, we > have established market share and established > platforms. Customers aren't > going to pull out our gear just because it takes a > while for us to support a > new feature. But there is intense price competition. > We have the luxury of > longer development times, but not the luxury of > naming our own prices." > > These factors, Harris said, were gradually weaning > Cisco from use of > programmable logic in complex or high-volume > applications. This, if it > proves generally true, could be an enormous challenge > to the growth of an > FPGA industry that has been feasting at the table of > the networking and > communications companies for several years. > > But Harris wasn't through spoiling the evening for > the FPGA vendors. "We > have the resources and the tools now to do very > high-performance, > multi-million gate designs on single chips. One > design we have in progress is > approaching 20 million gates. FPGAs have neither the > speed nor the > density to approach this level. > > "When we need field programmability, what we would > prefer is not to have > a huge programmable device, or even a programmable > device with a huge > piece of hardware set down beside it. We would prefer > to have an FPGA > core to drop into our ASIC. We typically need small > amounts of > reconfigurable logic beside the fixed hardware. > > "Unfortunately, that doesn't seem to be the way the > industry is moving," > Harris said. "I think first we will see FPGA vendors > try to provide IP on > their devices. But that's not what we'd like. If we > could get an FPGA core > for use in our ASICs today, we would be doing that > already." > > The sum of the university and industry inputs from > this very small but > undeniably influential sample suggested bad news for > the FPGA business. > The strongest high-volume customers for FPGAs appear > to be changing > their buying habits. Increasingly, they are using > ASICs instead of FPGAs. > And when they need programmable logic, they intend to > get it, if not from > their ASIC vendor, at least as third-party IP, not as > silicon. If this > foreshadowing becomes a trend, it could force a major > shift in business > models for the largest programmable-logic vendors.Article: 14964
I had the same problem. The order of operators following 'map' is what's doing it. Instead of: map -p xc4003e-4-pc84 -o map.ncd filter.ngd filter.pcf Use: map -p xc4003e-4-pc84 filter.ngd filter.pcf -o map.ncd In other words, just move the -o outfile.ncd to the end of the statement. I'm not sure how to do this under the GUI, since I quickly gave up on it and just run the whole thing from the command line with a make file. -- JeffArticle: 14965
Hello, I have two altera devices on a board, one MAX7000S and one 10K50E. Both are on the JTAG chain (max7000 tdo feeds 10k tdi - ie the MAX7000 is the first device in the chain). I'm using the JAM language to program the 10k upon power-up. What I can't figure out is how to creat the jam byte code file to do this. Do I have to create a Multi-jtag chain file and if so, then how do I insert instructions into the file so as NOT to program the MAX7000S? All help at this point is greatly appreciated! -- Bill MoffittArticle: 14966
Please visit http://www.boin-gmbh.com/linkpage/linkpage.htmArticle: 14967
francesco l spadini wrote: > OK, here are some REALLY basic questions I have about programmable > logic. What is the difference between an FPGA and a CPLD? I know that > with schematic capture or VHDL software, one can compile code and > download it into a programmable logic device through a parallel port, but > what sort of additional hardware is needed to interface between the port > and chip? Lastly, what other good sources (urls or book titles would be > much appreciated) would you recommend for learning more about programmable > logic and VHDL. Thanks in advance... > > --------------------------------------------- > Francesco Spadini > Department of Electrical and Computer Engineering > University of IIlinois at Urbana Champaign > spadini@uiuc.edu > > "Nec vitia nostra nec remedia pati possumus" > --------------------------------------------- VHDL for programmable logic. Kevin Skahill (Addison Wesley) The practical Xilinx designer handbook. Dave Vanden Bout (Prentice Hall) Very good books for beginners. -- =================================================================== Sergio A. Cuenca Asensi Dept. Tecnologia Informatica y Computacion (TIC) Escuela Politecnica Superior, Campus de San Vicente Universidad de Alicante Ap. Correos 99, E-03080 ALICANTE ESPAÑA (SPAIN) email : sergio@dtic.ua.es Phone : +34 96 590 39 34 Fax : +34 96 590 39 02 ===================================================================Article: 14968
Andy Peters wrote: > Sergio A. Cuenca Asensi wrote: > > > Yes, I've synthesized all three as top-level modules. I want three independent > > modules but without starpup blocks, the problem is that I can't find any option > > in FPGA express to avoid startup adding to them. Do you know where is it? > > I'm not sure you can have a chip with more than one top-level module! > > Why would you want to do that???? > > -andy I am using FPGA Express v2.0 and Xilinx Foundationv1.4. We use mixed mode entry (schematic+vhdl), really I don't want three top-level modules but it is the only way to synthetize an independent module in Express. The idea is create a "library" of synthesized vhdl modules, then I could instantiate the macros like a component from the schematic. But the problem is that every module synthetized include a startup, so I only can instatiate a module. I have to integrate all vhdl files of the design in a top-level module and sinthesize again. Regards =================================================================== Sergio A. Cuenca Asensi Dept. Tecnologia Informatica y Computacion (TIC) Escuela Politecnica Superior, Campus de San Vicente Universidad de Alicante Ap. Correos 99, E-03080 ALICANTE ESPAÑA (SPAIN) email : sergio@dtic.ua.es Phone : +34 96 590 39 34 Fax : +34 96 590 39 02 ===================================================================Article: 14969
Brian Schott wrote: >SNIP > What's up? I can target a 4085, but can't target anything bigger? What's > the trick? I've been all over the Xilinx and Synopsys pages with no luck. I had a similar problem, the Xilinx FAE told me to use the 4085 libraries, I've been doing this, and have produced real chips which are working on the bench - so give that a shot. I'm also using the Synopsys/Alliance route, and targetting an XC40150XV-09. RobertArticle: 14970
The IEEE spec for JTAG (1149) says that devices should pull up the JTAG pins internally (to be compliant). Pulling them down externally could cause problems if you are not carefull. Shame on the vendor for not holding the TAP in reset until after power is stable! Ying C. wrote: > > I have heard that for some reason, pulling both TMS and TCK low can also > cause a problem (not sure why or how). If I remember correctly, it's best > to pull TCK low and TMS high to prevent false clocking. > > Ying -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14971
The problem is not during the powerup sequence, it is after the power is stable while the device is re/configuring. Xilinx correctly holds the TAP in reset until the power is stable. The devices are designed to allow the configuration to be done in the conventional manner or through the JTAG controller. The problem comes in if you allow the TMS and TCK pins to toggle during a conventional configuration, you could trigger the JTAG controller and end up corrupting the bit stream. Those pins are internally pulled up in the Xilinx device, but they can be used as general purpose I/O after the device is configured. It is incumbent upon the user to make sure that if these pins are used for general I/O in the design, that they are held at a logic 1 during configuration to avoid activating the internal JTAG controller. Note that the xilinx parts are often used in applications with no JTAG, and even (or especially) in those cases the levels on these two pins need to be accounted for. Brian Boorman wrote: > The IEEE spec for JTAG (1149) says that devices should pull up the JTAG > pins internally (to be compliant). Pulling them down externally could > cause problems if you are not carefull. > > Shame on the vendor for not holding the TAP in reset until after power > is stable! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14972
You might find the links on The Programmable Logic Jump Station useful at http://www.optimagic.com. For example: =========== CPLD/FPGA Comparison: http://www.optimagic.com/comparison.html General overview of architectures: http://www.optimagic.com/faq.html#What_Kinds Books: http://www.optimagic.com/books.html ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- francesco l spadini wrote in message ... > OK, here are some REALLY basic questions I have about programmable >logic. What is the difference between an FPGA and a CPLD? I know that >with schematic capture or VHDL software, one can compile code and >download it into a programmable logic device through a parallel port, but >what sort of additional hardware is needed to interface between the port >and chip? Lastly, what other good sources (urls or book titles would be >much appreciated) would you recommend for learning more about programmable >logic and VHDL. Thanks in advance... > > >--------------------------------------------- >Francesco Spadini >Department of Electrical and Computer Engineering >University of IIlinois at Urbana Champaign >spadini@uiuc.edu > >"Nec vitia nostra nec remedia pati possumus" >--------------------------------------------- >Article: 14973
Has anyone in the UK purchased Virtex development boards + associasted software, under educational purchase terms? Does anyone have any suggestinos of companies that will supply the products in the UK? Many thanks Daryl Bradley Dept. Electronics University of YorkArticle: 14974
Greetings This is semimonthly announcement of Verilog FAQ. Verilog FAQ is located at http://www.angelfire.com/in/verilogfaq/ Alternate Verilog FAQ is an attempt to gather the answers to most Frequently Asked Questions about Verilog HDL in one place. It also contains list of publications, services, and products. Alternate Verilog FAQ is divided into three logical parts. Part 1 : Introduction and misc. questions Part 2 : Technical Topics Part 3 : Tools and Services What's New section outlines the changes in different versions and announcements. Links connects you to related informative links in internet. Rajesh Bawankule (Also Visit Verilog & EDA Page : http://www.angelfire.com/in/rajesh52/verilog.html ) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
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