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
In article <8m7u19$qq2$1@nnrp1.deja.com>,
clean_living@my-deja.com wrote:
> I have a design that I inherited from a foundation 2.1i sp1 user.
> Whenever I fix something in one module, something else breaks that
> was working before. I'm using 2.1i sp5. The local xilinx rep thinks
> the problem is the result of the way the designer copied design files
> rather than use the library manager.
>
> Has anyone else had a similar problem? What did you do to fix it.
>
> -Sue R.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
You did not explain what exactly does not work, but I assume you have a
top level scematics and some HDL modules.
IMHO you could convert (export) your scematics to HDL and create a new
project only in HDL.
In HDL you have a much better control about the relations between your
modules.
Hope this helps a little bit
Klaus
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24301ytou might want to check out the Free Model Foundation: http://www.vhdl.org/vi/fmf/ or the Hamburg University Archive: http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html I'm not sure if they have what you're looking for. Also, IC vendors often have models of their own parts. -Kent lamb_baa@hotmail.com (Eric L) wrote in >Are there any archives of digital ICs available? <snip> >Thanks >ericArticle: 24302
steve (Steve Rencontre) writes: > I've been thinking about QuickLogic, but past experience with Actel has > put me off OTP technologies. What was the problem ? We use Actels and had no problems with them. Regards, -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 24303
Yes, they are GPIO from the FPGA, but the socket is hard to find, at least in my area. I would recommend to use the PCI reverser and using the PCI pins (if you don't use the PCI.) for adding your components. - starry. "K. Orthner" wrote: > This is just an educated (?) guess, but I would assume that GPIO simply > stands for General Purpoose I/O, and isn't really a bus, per se. I would > think that it's just a bunch of wires running from the FPGA out to a > connector that easily allows you to connect other things, be it boards, > chips, or otherwise. > > -Kent > > muzaffer@kal.st (Muzaffer Kal) wrote: > >I have an Avnet Virtex Development Board. This has a bus interface > >which they call GPIO. Does anyone know if there are any boards which > >plug into this GPIO to add some chips? Basically I am looking for a > >board which would let me do some wire-wrap or soldering area. > > > >thanks, > > > >Muzaffer > > > >Article: 24304
On Wed, 2 Aug 2000 22:15:45 -0400, "Geoffrey G. Rochat" <geoff@pkworks.com> wrote: >"The Verilog Hardware Description Language", 2nd Ed., by Donald E. >Thomas and Philip R. Moorby, 1995, Kluwer Academic Publishers, ISBN >0-7923-9523-9, uses an 8251 design as an example. The book isn't bad, but I wouldn't recommend buying it. You can get the 8251A source bits from: http://www.angelfire.com/in/verilogfaq/moorby.html I don't know if it's legal or not, and I don't know of a VHDL source. EvanArticle: 24305
On Tue, 01 Aug 2000 13:43:35 GMT, s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb) wrote: >After the long suppositions and wondering "will they, wont they, can >they, cant they?", we finally see an IPO filing from Synplicity. > >You can read the filing with all the juicy financial detail through >www.ipo.com. Once you've read it (and deciphered it?), as informed >observers of the synthesis market space (Exemplar/Synopsys/Synplicity >etc.) tell me: > >On balance, would you invest? > >Cheers >Stuart >An employee of Saros Technology: >Model Technology, Exemplar Logic, TransEDA, Renoir. >www.saros.co.uk Or see the EEtimes article at: http://www.eoenabled.com/edtn/out.asp?n=33586385&i=synplicity&a=EET&url=http%3A%2F%2Fwww%2Eeet%2Ecom%2Fstory%2FOEG20000726S0025&title=Synplicity+makes+IPO+bid for the short story. Synplicity describes itself as a "provider of software products for Internet infrastructure, including next-generation networking and communications equipment and various electronic devices." This reminds me of the South Sea bubble company that advertised itself as being on a "great undertaking, not to be disclosed". Surely there aren't still people around who are stupid enough to invest in something just because the word 'Internet' appears in the offer? Certify's getting some good press, and Synplicity seems to be ahead of the game on FPGA physical synthesis. My money is on everyone moving to physical synthesis over the next few years, and FPGAs taking an increasing slice of the ASIC market, so it might be worhtwhile putting a few beads in. On the other hand, the short-term prospects may depend very much on what Xilinx decides to do with XST, so I may just hang on to those beads... EvanArticle: 24306
On Mon, 31 Jul 2000 16:39:23 GMT, erika_uk@my-deja.com wrote: >hey, > >what are the advantages and disadvantages from using TBUFs( e.g : for >multiplixer purpose ) > >anticipated thanks > >--Erika + potentially better for large muxes, in some cases + synth tools can generally recode combinatorially if there's a problem - potentially difficult to move to an ASIC process - may force use of an asynchronous reset - potentially very slow - can cause placement problems: as a (xilinx) rule, you will probably want your logic blocks arranged vertically, but a bus line implemented with tristates will run horizontally. The speed issue now seems to be historical. 4K TBUFs got *very* slow with larger devices, but Virtex TBUFs are relatively fast and the speed appears to be independent of device size. This is apparently because there aren't actually any tristate buffers on Virtex; they're actually implemented as combinatorial muxes and just pretend to be tristates. As a rule, I'd say forget it. TBUFs are fine for small FPGAs, where you have to use every trick you can to squeeze performance out of them. For 'big' devices, the issues are completely different - design management, timing closure, getting a design done in a reasonable timescale. I'd say the days of the TBUF are numbered (at least until someone gives us the 10GHz 100-CLB FPGA, then we can start all over again...) EvanArticle: 24307
I agree that the XCV50 is too much for this applicatiopn, but the board will be used for teaching, and it's important for us to have some extra space in the FPGA in order to use it in different labs. In addition, it's important to have a long life board. We don't need a board to use just for a couple of years. The problem of using, for example, an XC4010XL FPGA is the cost: > XC4010XL-09PC84C (10K gates, 244 CLBs) - 24 units - US$109.00 / unit > > XCV50-4BG256C (50K gates, 384 CLBs) - 24 units - US$55.40 / unit > I couldn't find at http://www.optimagic.com a board suitable for our design. We need something very simple and cheap. Basically, we need a board with an FPGA, a serial PROM socket, an RS-232 connector, a MAX232 chip, and prototyping area. At the moment I'm using an XS40 board from Xess Corporation (donated by Xilinx) to develop the prototype. The surface mount package may be a problem. I'll investigate some alternatives. Thanks Eduardo. Dave Vanden Bout wrote: > > > My design will have, basically, an 8251 and a manchester > > encoder/decoder. It'll be used to teach concepts of data > > communications to undergraduate students. We're considering > > the use of the same board (with the same FPGA) to implement > > different UARTs and USARTs. Do you think the Xilinx XCV50 > > FPGA is a good option? We're going to build 30 kits and the > > cost of the FPGAs (XCV50) + serial PROMs will be something > > around US$1,500.00. Is it the best option for this design? > > Is there a less expensive solution? > > The XCV50 is overkill for just an 8251 and a Manchester encoder/decoder, > but it makes sense if you want to work with a current FPGA family. The > older Xilinx XC4000 family will also suit your application. > > Remember that the XCV50 only comes in a surface mount package so you will > need to build a PCB to hold it. You will spend several times your $1500 > building and supporting the lab infrastructure that surrounds the FPGA and > serial PROM. You might want to check the list of FPGA boards at > www.optimagic.com to see if there is a one that will suit your needs. > > > > > > > Thanks > > > > Eduardo. > > > > Peter Alfke wrote: > > > > > > Eduardo Augusto Bezerra wrote: > > > > > > > Hi > > > > > > > > Does anybody know the price of a synthesizable 8251A core? I'm also > > > > looking for a Manchester encoder/decoder. Is there a place where I > > > > can find these cores for free? I'll decide which FPGA to use in my > > > > design as soon as I find the cores. > > > > > > > > > > A Manchester encoder is trivial, essentially an XOR. > > > A Manchester decoder is described in the Xilinx XCell magazine in > > > 1995. > > > The design uses only three XC3000 or XC4000 or Spartan CLBs. > > > > > > http://www.xilinx.com/xcell/xl17/xl17-30.pdf > > > > > > Peter Alfke, Xilinx Applications > > > > -- > > Eduardo Augusto Bezerra > > Space Science Centre > > School of Engineering and Information Technology > > University of Sussex > > Brighton, BN1 9QT > > England, UK > > > > Phones: +44 (0)1273 877086 or +44 (0)700 5568783 > > Fax: +44 (0)1273 678399 > > EIT II, room 4B11 > > > > *** UK *** > > mailto:E.A.Bezerra@sussex.ac.uk - http://www.sussex.ac.uk/~tapu9 > > Space Group's web site: http://www.sussex.ac.uk/engg/research/space > > *** Brasil *** > > mailto:eduardob@inf.pucrs.br - http://www.inf.pucrs.br/~eduardob > > GAPH's web site: http://www.inf.pucrs.br/~gaph > > *** ACM *** > > mailto:eduardob@acm.org > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || -- Eduardo Augusto Bezerra Space Science Centre School of Engineering and Information Technology University of Sussex Brighton, BN1 9QT England, UK Phones: +44 (0)1273 877086 or +44 (0)700 5568783 Fax: +44 (0)1273 678399 EIT II, room 4B11 *** UK *** mailto:E.A.Bezerra@sussex.ac.uk - http://www.sussex.ac.uk/~tapu9 Space Group's web site: http://www.sussex.ac.uk/engg/research/space *** Brasil *** mailto:eduardob@inf.pucrs.br - http://www.inf.pucrs.br/~eduardob GAPH's web site: http://www.inf.pucrs.br/~gaph *** ACM *** mailto:eduardob@acm.orgArticle: 24308
XESS Corp. is releasing the sixth section of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html. We will release a new section each week. Each section describes a design example for the Triscend configurable system-on-chip device (CSoC). The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both reprogrammable. The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 24309
Peter Alfke wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: 7bit Grumble ... I hate that kind of messages. (cut...paste) "I have a 30-year tradition of fighting for complete IC documentation. But that started when the parts were simple, and the designers worked with pencil and paper. Today, nobody designs with pencil and paper, the parts are very complex, and the software accurately computes any on-chip delay for you, using hundreds of "atomic" incremental values, carefully derived from extensive measurements, and carried forward with picosecond accuracy. What benefit is there in publishing a select subset of these values in the data sheet, necessarily excluding most routing delays ? " It is still useful for order of magnitude comparisons. Still the data sheets don't tell you how slow your FPGA logic compares with raw gates. picosecond accuracy!? Does that include 10% margin for things like power supply ripple,clock jitter,and the phase of the moon. While it not Practical to design using pencil and paper, I think we have lost something by having designs so complex that knowbody really knows just what is in the hardware. The one advantage of pencil and paper is what you see is what you get. FPGA hardware is real black box inside, and don't like black boxes,black holes,or block hole diodes or software with out source. Ben. Ps what little FPGA design I have done I find in many cases the much of the logic FPGA block goes to waste because the #of inputs to a block is limited.I need a 9 input and gate - 3 blocks. A 4:1 multiplexer - 3 blocks.Actel's logic blocks are not as in/out bound as the other companies bocks, but fewer the blocks used the better.I like anti-fuse as it is one less chip. I would have to be able to do FPGA's logic programing by hand,not because it easier but because I can SEE just what the chip is doing. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24310
Thanks, have you actually used this chip? Mark Korsloot <markk@alcom.nl> wrote in article <39880AE9.305845C9@alcom.nl>... > Galileo Technology has standard 64-bit 66MHz PCI Interface chips (eg. > GT64121). > > See www.galileot.com > > Mark > > Austin Franklin wrote: > > > > I have a design that currently uses a PLX 9080, and I need to move it to a > > 64 bit and/or 66MHz PCI interface... PLX does not currently offer a > > solution, that I can find...neither does AMCC. Any suggestions for off the > > shelf chips to do this, or any experience with the QuickLogic QL5064 > > interface chip? > > > > Thanks! > >Article: 24311
eml@riverside-machines.com.NOSPAM wrote: > > On Mon, 31 Jul 2000 16:39:23 GMT, erika_uk@my-deja.com wrote: > > >hey, > > > >what are the advantages and disadvantages from using TBUFs( e.g : for > >multiplixer purpose ) > > > >anticipated thanks > > > >--Erika > > + potentially better for large muxes, in some cases > + synth tools can generally recode combinatorially if there's a > problem > > - potentially difficult to move to an ASIC process > - may force use of an asynchronous reset > - potentially very slow > - can cause placement problems: as a (xilinx) rule, you will probably > want your logic blocks arranged vertically, but a bus line implemented > with tristates will run horizontally. > > The speed issue now seems to be historical. 4K TBUFs got *very* slow > with larger devices, but Virtex TBUFs are relatively fast and the > speed appears to be independent of device size. This is apparently > because there aren't actually any tristate buffers on Virtex; they're > actually implemented as combinatorial muxes and just pretend to be > tristates. > > As a rule, I'd say forget it. TBUFs are fine for small FPGAs, where > you have to use every trick you can to squeeze performance out of > them. For 'big' devices, the issues are completely different - design > management, timing closure, getting a design done in a reasonable > timescale. I'd say the days of the TBUF are numbered (at least until > someone gives us the 10GHz 100-CLB FPGA, then we can start all over > again...) > > Evan I would quibble with the last two disadvantages you mention. In many cases the speed will be fine since it does not slow as appreciably with size compared to a LUT mux. I doubt that the tbufs are really muxes, but I can't say for sure. Of course it can't be pipelined for speed the way a LUT solution can. The placement issue is often perfect for placement. If you are muxing many registers onto a wide bus, then the registers will be vertically arranged and the mux *should* be horizontal. Of course if you are muxing one wide register to a single signal the arrangement is not good. A barrel shifter still works out since it has to be a 2D array. The input data lines run diagonal, the enables run vertical and the output data is horizontal. This is what I used and it had no problems routing at all. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24312
In article <8mb71e$8v8$1@nnrp1.deja.com>,
Klaus Falser <kfalser@durst.it> wrote:
> In article <8m7u19$qq2$1@nnrp1.deja.com>,
>
> You did not explain what exactly does not work, but I assume you have
a
> top level scematics and some HDL modules.
>
> IMHO you could convert (export) your scematics to HDL and create a
new
> project only in HDL.
> In HDL you have a much better control about the relations between
your
> modules.
>
> Hope this helps a little bit
> Klaus
>
Thanks Klaus. Let me clear this up. The project is schematic capture.
There are no hdl modules. One module, a bit error rate test (bert),
was ported over from another fpga design. The design works in the
other fpga. There are two instantiations of the bert. The bert uses
an m2_1 mux in the incoming serial data path.
While bert1 works bert2 will not. I fix bert2 by deleting the mux and
reinstantiating it. This fixes the problem and bert2 now works,
however, bert1 now fails.
I have considered the following:
1.) a library problem for the 2-1 mux
2.) the next-higher level in the hierarchy is not correct
3.) the software is not properly configuring the fpga
4.) the fpga needs to be replaced
5.) the schematic capture tool is not working properly
6.) the implemenation tool is not working properly
I have concluded the following:
1.) all the other instantiations of the m2_1 work properly. This is
not a library problem.
2.) The hierarchy has been reviewed many, many times. I have triple
checked signal & pin names, their spelling and verified signal
connectivity by "selecting the entire net" and "dragging" the
mux around to see if the nets drag as well. I have also used
these techniques at all levels of the hierarchy. The schematic
appears to be intact.
3.) The software does not change from implementation to
implementation. At least that's what the software guy claims ;-)
4.) I have duplicated the problem on many different boards.
5.) This is still questionable. I can see from the map report that
the mux is being optimized out. Yet the schematic shows all
the proper connections to the mux. I have seen the mapper delete
muxes - if the inputs are present but the select line(s) are left
floating. This is not the case here.
6.) I can't isolate the problem to the implementation tool until I can
verify the schematic capture tool is working properly. Xilinx
tech support suggested running a post-par timing sim on the
circuit. They feel if the circuit simulates properly after par,
the .ncd file good and the implementation is correct. This would
validate the schematic capture tool as well. The simulation
worked!
So what's the difference between the simulation the the real-life
application? Good question. I'll find out. Also, could this be a
problem with limitations of my machine? I am running on a 200MHz
pentium, NT and 96M ram. The device is a spartan 20xl and is only
being 35% utilized.
Thanks in advance,
-Sue
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24313Hi Ken... Sounds to me like you should be looking at PLDs, which can be thought of as a large number of wide input AND gates feeding a number of wide input OR gates, with all intersections programable. I am aware of common 5nsec CMOS PLDs, and seem to remember a Galium Arsenide PLD, but a visit to the vitesse web site didn't reveal anything. Good luck in your hunt Eric Pearson Ken Christensen wrote in message <8ma4e0$62v$1@news.usf.edu>... >Hello, FPGA's are not my area. so, my apologies if this is a really stupid >(or textbook) question. What size AND and OR arrays are available in >existing devices? If I want arrays of 32 input ANDs and 100 input ORs, can >I do this in *two-levels*? If so, what is the gate delay of the 32 input >AND and 100 input OR? I want to implement some rather complex two-level >logic equations with delay of less than 1 nanosecond. is this achievable >with FPGA technology? If yes, which technology/vendor? If not with FPGA's, >how could I implement this? > >Thank you! > > >Ken Christensen >=============================================================== >= Kenneth J. Christensen (Assistant Professor) >= Department of Computer Science and Engineering >= University of South Florida >= (813) 974-4761 >= http://www.csee.usf.edu/~christen >=============================================================== > >Article: 24314
Eduardo Augusto Bezerra wrote: > > I agree that the XCV50 is too much for this applicatiopn, but the > board will be used for teaching, and it's important for us to have > some extra space in the FPGA in order to use it in different labs. > In addition, it's important to have a long life board. We don't need > a board to use just for a couple of years. If you are building a board, then you can use the surface mount packages just fine. TQFPs can be hand soldered if you have a little skill (I don't, but many do). The new Spartan II is functionally the same as the Virtex parts and come in sizes from 15 K gates (vendor gates) to 200 K gates. The cost is very low on this line. I would suggest either the TQ 144 pin package or the PQ 208 pin package depending on how many IOs you think you will need in the future. I would also suggest that you leave off the PROM socket. The PROMs are not terribly cheap parts and for education, you will likely want to just download directly from the development station. You can either use the serial port, the parallel port or an X-checker cable. Either a CPLD or a small simple single chip micro will do the programming very nicely. I think you may not need any logic if you use the PC parallel port. But as others have suggested, check for an existing product. There is no point in designing your own when others are available and likely cheaper. There was a ad in this newsgroup from a company in Austraila (IIRC) that had a board for under $100. I don't think you can build you own this cheaply. > The problem of using, for example, an XC4010XL FPGA is the cost: > > > XC4010XL-09PC84C (10K gates, 244 CLBs) - 24 units - US$109.00 / unit > > > > XCV50-4BG256C (50K gates, 384 CLBs) - 24 units - US$55.40 / unit > > > > I couldn't find at http://www.optimagic.com a board suitable for > our design. We need something very simple and cheap. Basically, we > need a board with an FPGA, a serial PROM socket, an RS-232 connector, > a MAX232 chip, and prototyping area. At the moment I'm using an > XS40 board from Xess Corporation (donated by Xilinx) to develop > the prototype. > > The surface mount package may be a problem. I'll investigate some > alternatives. > > Thanks > > Eduardo. Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24315
rickman a écrit : > The new Spartan II is functionally the same as the Virtex parts and > come in sizes from 15 K gates (vendor gates) to 200 K gates. The cost > is very low on this line. I would suggest either the TQ 144 pin > package or the PQ 208 pin package depending on how many IOs you think > you will need in the future. The problem (at the moment) is that they are REALLY hard to find because they're not in full production yet. However, if your board (talking to Eduardo, here) can wait a bit, I'd recommend SpartanII (but I'd order them now) -- Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel +33 1 46 67 51 11 F-92400 COURBEVOIE - FRANCE Fax +33 1 46 67 51 01 http://www.dotcom.fr/Article: 24316
Hello FPGA users, Can someone suggest a good approach for implementing PWM modulation in a Spartan-XL FPGA ? The goal is to generate a 200KHz carrier with 10KHz PWM; the input clock at 40MHz should be ample. The output will be aplied to a half-H power driver and filtered. I also need to be able to control the amplitude of the 10KHz component at a slow rate. My thought for a possible approach is to build a small lookup table in a dual-port RAM block. An external CPU would compute the pulse widths appropriate for the desired 10KHz amplitude, then download the table into FPGA RAM. Then FPGA hardware cycles through the table, generating pulses of the appropriate width every 5us. A table of 20 entries with even 4 bit resolution seems reasonable. Is there some whiz-bang approach that makes better sense than the obvious one I've suggested ? Any thoughts on resource usage ? Your comments would be most welcome. Thanks, George Pontis (Please edit return address if replying by email.)Article: 24317
In article <398894A9.3E02E759@GoodWare.com>, Wayne@GoodWare.com (Wayne) wrote: > > I've been using QuickLogic for about a year now and have had good luck > with > them. What sort of problems did you have with Actel ? Not Actel per se, but OTP. It's not so bad if you have a PLCC chip that you can socket easily, but the burn/chuck cycle is still an expensive pain in development. Higher-density packages are just not practical unless you are pretty certain that your first version will be near-as-dammit the final one. There may be some projects where the FPGA functionality is completely and accurately specified in advance, and the simulation is absolutely correct and exhaustive, but I've yet to see one. A big problem I've always had, and I don't expect it to go away any time soon, is that the documentation for the surrounding circuitry is /never/ sufficient to simulate it with 100% confidence. Now having said that, it should be qualified by the fact that I mostly use FPGAs as glue and peripherals. If I was making standalone functional blocks, I'd have a lot more control of my destiny and might feel differently. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 24318
In article <8ma4e0$62v$1@news.usf.edu>, christen@csee.usf.edu (Ken Christensen) wrote: > Hello, FPGA's are not my area. so, my apologies if this is a really > stupid > (or textbook) question. What size AND and OR arrays are available in > existing devices? If I want arrays of 32 input ANDs and 100 input ORs, > can > I do this in *two-levels*? If so, what is the gate delay of the 32 > input > AND and 100 input OR? I want to implement some rather complex two-level > logic equations with delay of less than 1 nanosecond. is this achievable > with FPGA technology? If yes, which technology/vendor? If not with > FPGA's, > how could I implement this? Large sum-of-products arrays are really the more the domain of PLDs than FPGAs, although the dividing lines are pretty blurred. Some Altera and Xilinx devices have embedded RAM arrays which can be used to implement wide logic functions, but 1ns is pushing things to put it mildly! When you say 'gate' delay, I presume you mean pin-pin, rather than within-chip propagation. If so, I don't think even simple 22V10 chips can run that fast, let alone anything with the complexity you want. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 24319
Philip Freidin <philip@fliptronics.com> wrote: > Which would work only if you knew how to generate the security number > on the K line. I have no idea how to calculate it. Last time I checked, you could give every file the same K-line since Viewlogic no longer checks the name on the K-line against the file name. Your post-processor can simply overwrite the existing K-line with a known valid one. It's probably best to comment-out the old one in case you need it later. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 24320
> "K.Orthner" wrote: > > > As the subject says, I fell like I'm at the end of my rope, here. ( I get > > the feeling I'm mixing metaphors, but I haven't actually had an english > > conversatoin for so long, I forget.) > > > > This is (was?) related to the coregen thread, except that now, I have > > completely removed everything Coregen-related. > > > > I have the simple problem of: > > > > My code simluates fine, I get exactly the answers that I expect. Then I put > > it throught the Xilinx mapper, it "optimizes" out some signals that are > > rather important. It then falls over saying that there are components who's > > input signals have been optimized. > > > > If I select the "Don't trim logic"option it seems to work fine; but I > > haven't tested it on a real board yet. (It's PnR'ing as I type.) > > > > Anyone have a suiggestion for how to track this problem down? > > > > I've been tracing nets with the EDIF file/FPGA Express Schematic viewer, and > > as far as I can tell, the output of the synthesizer is just fine. > > > > ------------ > > Kent Orthner > > Kent, I am currently having a similar problem with a schematic project I inhereted (see thread "foundation 2.1i problem"). The mapper declares nets unloaded, optimizes them out and anything in either direction (upriver or down). Even funnier was the fact I could not find the nets being optimized out. Ver-r-r-r-ry late last night, I decided to shut down project manager & the pc and try again. I couldn't get project manager to respond then the pc got hung up on task manager. I powered down, rebooted, and relaunched 2.1i. When I opened the schematic editor, some bus taps were unamed! I had named them earlier in the day, created a netlist and printed a copy of the sheet. When I checked their net numbers, sure enough they were the elusive nets being optimized out! Once again I edited the schematic and created a netlist. This time everything worked. . . . except for the design of course. I had chalked this up to a schematic tool problem until I read your post. One thing I did last night that may have helped. . . I cleared the transcript window's huge file by selecting file -> preferences -> clear messages. I can't think of anything else, if you figure this out I'd like to know too. regards, -SueR Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24321
--------------FCEE0EFB74776E8D3BA5944F Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Let me pose a provocative question to this smart, diverse, and vocal audience. (Shameless flattery might help me get a few additional answers...) Why do we ( Xilinx, etc) print and publish all those detailed ac parameters describing on-chip performance ? (Let's exclude I/O parameters from this question) I have a 30-year tradition of fighting for complete IC documentation. But that started when the parts were simple, and the designers worked with pencil and paper. Today, nobody designs with pencil and paper, the parts are very complex, and the software accurately computes any on-chip delay for you, using hundreds of "atomic" incremental values, carefully derived from extensive measurements, and carried forward with picosecond accuracy. What benefit is there in publishing a select subset of these values in the data sheet, necessarily excluding most routing delays ? How would you react if we reduced the published on-chip delay parameters to a limited number of relevant performance values, and then referred you to the software tool for the detailed, complete and very accurate analysis ? Wouldn't you be better off ? This was triggered by the recent debate over the delay differences between the 4 different LUT inputs. I feel strongly that the designers should not be bothered with such details. The software should analyze and synthesize this for you. This is Peter speaking. It is not an official Xilinx proposal. It is also not an attempt to save cost and paper, although it would do that as a side benefit. It is just a fresh look at a 40-year old habit. Every couple of dozen years one should clean out the closet :-) Please let me know what you think. I know I can count on your opinionated response ! Peter Alfke --------------FCEE0EFB74776E8D3BA5944F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Let me pose a provocative question to this smart, diverse, and vocal <br>audience. (Shameless flattery might help me get a few additional answers...) <p><b>Why do we ( Xilinx, etc) print and publish all those detailed ac</b> <br><b>parameters describing on-chip performance ?</b> <br>(Let's exclude I/O parameters from this question) <p>I have a 30-year tradition of fighting for complete IC <br>documentation. But that started when the parts were simple, and the <br>designers worked with pencil and paper. <br>Today, nobody designs with pencil and paper, the parts are very <br>complex, and the software accurately computes any on-chip delay for <br>you, using hundreds of "atomic" incremental values, carefully <br>derived from extensive measurements, and carried forward with <br>picosecond accuracy. <p><b>What benefit is there in publishing a select subset of these values</b> <br><b>in the data sheet, necessarily excluding most routing delays ?</b><b></b> <p>How would you react if we reduced the published on-chip delay <br>parameters to a limited number of relevant performance values, and <br>then referred you to the software tool for the detailed, complete <br>and very accurate analysis ? <br>Wouldn't you be better off ? <p>This was triggered by the recent debate over the delay differences <br>between the 4 different LUT inputs. I feel strongly that the <br>designers should not be bothered with such details. The software <br>should analyze and synthesize this for you. <p>This is Peter speaking. It is not an official Xilinx proposal. <br>It is also not an attempt to save cost and paper, although it would <br>do that as a side benefit. <p>It is just a fresh look at a 40-year old habit. <br>Every couple of dozen years one should clean out the closet :-) <p>Please let me know what you think. <br>I know I can count on your opinionated response ! <p>Peter Alfke <br> <br> </html> --------------FCEE0EFB74776E8D3BA5944F--Article: 24322
I saw a reference to XST in an earlier post. Could someone please explain to me what is XST? I'm running Xilinx 2.1i software and I've never heard of XST. Thanks, -- Pete Dudley Arroyo Grande SystemsArticle: 24323
All well and good for the average user. Still for the expert, it helps to have this information available in some form that is easier to access than going into the chip editor as an aid for development of highly optimized blocks. Surely it doesn't need to be in the data book, but how about in an app note where he who wants it can get it. Peter Alfke wrote: > > Let me pose a provocative question to > this smart, diverse, and vocal > audience. (Shameless flattery might > help me get a few additional > answers...) > > Why do we ( Xilinx, etc) print and > publish all those detailed ac > parameters describing on-chip > performance ? > (Let's exclude I/O parameters from > this question) > > I have a 30-year tradition of fighting > for complete IC > documentation. But that started when > the parts were simple, and the > designers worked with pencil and > paper. > Today, nobody designs with pencil and > paper, the parts are very > complex, and the software accurately > computes any on-chip delay for > you, using hundreds of "atomic" > incremental values, carefully > derived from extensive measurements, > and carried forward with > picosecond accuracy. > > What benefit is there in publishing a > select subset of these values > in the data sheet, necessarily > excluding most routing delays ? > > How would you react if we reduced the > published on-chip delay > parameters to a limited number of > relevant performance values, and > then referred you to the software tool > for the detailed, complete > and very accurate analysis ? > Wouldn't you be better off ? > > This was triggered by the recent > debate over the delay differences > between the 4 different LUT inputs. I > feel strongly that the > designers should not be bothered with > such details. The software > should analyze and synthesize this for > you. > > This is Peter speaking. It is not an > official Xilinx proposal. > It is also not an attempt to save cost > and paper, although it would > do that as a side benefit. > > It is just a fresh look at a 40-year > old habit. > Every couple of dozen years one should > clean out the closet :-) > > Please let me know what you think. > I know I can count on your opinionated > response ! > > Peter Alfke > > -- -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: 24324
SueR, Thanks a lot for the advice/suggestion. I ended up taking a different route . . . I kind of redesigned the block that was giving me problem from the groud up. What I *was* doing was, I had a RAM with a feedback loop. The ram was 16 bits wide, and everytime you accessed the RAM, it foud feed "output+1" back to "input". In that was, I can have 16x 16bit counters, using 16 LUTs as RAMs. What I *think* I did, but I'm not sure, is that I had no way to force my RAM input's to zero . . . It so happenned that I didn't really care what the default value was. I think what happaned was that since there was no way to initialise the RAM inputs, it figured the inputs and outputs would always be 'X', and therefore unuseabe, and therefore trimmable. But that is a *very* shaky theory on my part! >Ver-r-r-r-ry late last night, I decided to shut down project manager & >the pc and try again. I couldn't get project manager to respond then >the pc got hung up on task manager. I powered down, rebooted, and >relaunched 2.1i. Well, I use windows, see, so that happens to me on a daily basis. <growl> >When I opened the schematic editor, some bus taps >were unamed! I had named them earlier in the day, created a netlist >and printed a copy of the sheet. I'm not exactly sure wqhat you mean by "Bus taps were unnamed". That sounds as though it's schematics realted. I'm using purely HDL, so it's impossible to have a net without a name. Or was it after the synthesis stage the the names seemed to be lost? When I looked at the post synthesis results, everything seemed to be connected nicely. It wasn't until the mapper went on a trimming spree that I ran into trouble. >I had chalked this up to a schematic tool problem until I read your >post. One thing I did last night that may have helped. . . I cleared >the transcript window's huge file by selecting >file -> preferences -> clear messages. I can't think of anything else, >if you figure this out I'd like to know too. Like I said, instead of getting past the problem, I went around it, so there probably won't be anything I can say to help. I'll make a point of doing the 'clear messages' thing, though. Which brings me to a question . . . whenever I look at the post synthesis report files in Foundation 2.1 (FPGA Express 3.3), it's as though the top half (quarter? seven eights?) of the file is missing, and I'm only getting the last bit. Anyone else get this? -Kent
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