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
>Any 16 bit DOS app is going to run much slower under NT. Not necessarily *noticeably* so. I run most of my 50 (yes, fifty) or so ex-win3.x apps under NT4 (I have a dual-boot NT/WFWG system), and while there is a noticeable slowdown in some operations (e.g. file open speed in Protel PCB) most things are just as quick. But this assumes you have RAM appropriate to NT, i.e. at least 32 megs. >The next release of the Xilinx tools will be made to run under NT. This >current release does run, at least all the DOS tools do. I don't know if >the number I get is 30 times slower, it may be 2-4 times slower. The only way PPR will be 2-4 times slower is if it is set-up to get say 50% of CPU time. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4501
>I need a RS-232 interface for XILINX FPGAS. You need a RS232-TTL converter first, e.g. a MAX232, to take care of the voltage levels. >I need a ready and tested UART-DESIGN for quick implementation. If anyone finds a *decent* UART schematic, I would be very interested to see it. The best I have seen to date is a cut-down UART in an old Actel app note book. Now, if someone published a 16550, complete with the FIFOs... I did a design (not a UART) a while ago, with a 24-byte FIFO in it, and after heavy layout tweaks it filled a 3020. A 16550 in a FPGA would be the world's most expensive UART :) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4502
In article <55clpn$dod@news2.Belgium.EU.net>, Vincent.Himpe@ping.be says... > I have a fairy simple circuit : a 24 bit counter with parallel load > The counter is hooked to a comparator which can either reset the counter , or > make it load a new value. In this way it forms a sequencer. This should be easy. > > now comes the tricky part: This counter needs to run at at least 60MHZ !. > > I tried synthesizing it into a xilinx Xc4003 and XC4004 : no luck. > It fits all right. But the maximum speed i can get is around 25 MHz. > > Are there any components out there that can do this ? There are several options for addressing this design problem, some of which have already been described by Ray Andraka and others. When you're pushing the edge (any edge, be it density, heat, speed, etc.) your design time tends to increase exponentially; and the design tools aimed at speeding up design time (at the expense of performance, density, power, etc.) become inappropriate. So let's set the synthesis tools aside, for now. This isn't the sort of problem that is gracefully handled by synthesis tools. Here are some approaches you can take for this problem: 1. Pick the fastest component available for the job. This may be a Xilinx 4Kex, it may be a Lucent (formerly ATT) 2cXX ORCA. Both have dedicated carry acceleration facilities. Traditionally, the ORCA parts have been faster and lower power than their Xilinx 4K equivalents. This may not be the case right now, I haven't compared the latest available parts recently, so I can't speak with certainty on this. [Note: There *are* other FPGA vendors out there. I mentioned the two with which I am most familiar, and which I think are most likely to provide a reasonable solution. Comments are always welcome!] 2. Is this a one-off product that only has to work in a single instance (rather than a volume-manufactured device)? If so, then you can be less concerned with worst-case timing across process, temperature, and voltage. If the timing verifier says it works at 55 MHz, it will usually work at 60 MHz with nominal voltage, and 25 deg C ambient air (with circulation). This approach is totally unacceptable for a device that will be duplicated many times over. But that may not be your situation, and you don't want to fight battles that don't really concern you. 3. Design architecture, specifically parallelism, should be able to get you to your target. How much parallelism needs to be applied depends very much on the specific minimum requirements of your application. Without insight into these details, the casual observers (and experts) in this newsgroup are handicapped. Tradeoffs in the logic feeding this counter, or responding to the counter, can be helpful in minimizing the design problem. 4. Get some help. If this is a commercial product, rather than a "term paper" for an academic program, then it often pays to get help from either an FPGA design hotshot in the company, or a "hired gun" such as Ray Andraka, Phil Freidin, or one the many others who contribute to this newsgroup (including myself, of course!). The cost of the hired help is often tiny compared to the benefits, which include... a. a more reliable design b. cheaper (smaller, slower, more available) FPGA, cheaper product c. shorter schedule (get the design done on time, more predictably) d. gain expertise from the expert, for next project(s) As an added note, you may be able to get free design help from either Xilinx or Lucent, if they think that your company's business is worth their effort, and if they think you might otherwise go elsewhere. Are you (potentially or currently) a key account? I wouldn't recommend "overstaying your welcome", but if you are in a position of influence amongst your colleagues, then your satisfaction may be a valuable asset to either vendor. I hope this has helped. Please follow up with the outcome of your project. These sorts of real-world problems are interesting to many people, and posting the results is a genuine service to the FPGA (and others) design community. -- Bob Elkind ************************************************************************** Bob Elkind mailto:eteam@aracnet.com CIS:72022,21 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ******** Video processing, R&D, ASIC, FPGA design consulting *************Article: 4503
Manolis Stratakis <strataki@ics.forth.gr> writes: |> |> We are using Allegro to make several complicated PCBs for |> our designs. We use extensively Xilinx FPGAs and other chips but up |> to now we take care our chips not to exceed ~ 100 pins. Actually when |> the package comes in any PGA we can handle it easily with our layout |> software and our lab's facilities. But when it comes to greater chip |> packages we do not have the necessary experience. |> |> Are there any pointers to info about the handling of these |> monster chips? How about the PCB manufacturers, do they normally support |> them? How does the package choice affect the total cost of the PCB? |> It is true that at least for the Xilinx FPGAs the PGA packages tend to |> be a lot more expensive than the respective PLCCs. I would expect this |> to be especially true with the more complicated packages. |> |> Also are there any converter sockets available that would |> convert a xxx (xxx = a difficult to handle) package to PGA? 1 - We have been using Allegro for years with 200+ pin packages. I have never had a problem with a pin limit. 2 - Pin count should not matter at all to a PCB manufacturer. Artwork is just lines, vias, and pads. Vendors here price PCB's based on total area, number of layers, and design rules, but _not_ on the kind of IC's on the board. 3 - There are convertor sockets from surface mount to PGA for many packages. Try Emulation Technology, Advanced Interconnections, and Ironwood, or whomever you typically buy sockets from. With some vendors you can send them your surface mount IC's and they will send them back soldered to their PGA adaptor. We sometimes create a PCB with both the PGA and surface mount pattern. That way we can use the PGA or the surface mount with adaptor during debug and then switch to the surface mount part for production without changing the PCB. -- Ken Goldman kgold@watson.ibm.com 914-945-1466Article: 4504
Peter, > But this assumes you have RAM appropriate to NT, i.e. at least 32 > megs. I have 80M, priorities are fine. It's just that NTVDM (NT Virtual DOS Machine) is a layer within NT that are not in 3.1, 95, WFW, DOS etc. This overhead is there because NT is a protected environment, and this is what causes this stuff to run slower. > The only way PPR will be 2-4 times slower is if it is set-up to get > say 50% of CPU time. I have two identical (hardware wise, same CPU, disk, controller, video card etc.) one running 3.1 and one running NT 4.0. I ran PPR with the same design, same seed as follows: (no other significant tasks were running) The design is ~%65 of a 4013. NT - CPU time taken for Partition: 0 hrs 18 mins 49 secs CPU time taken for Placement: 0 hrs 34 mins 35 secs CPU time taken for Routing: 0 hrs 46 mins 42 secs Win 3.1 - CPU time taken for Partition: 0 hrs 6 mins 30 secs CPU time taken for Partition: 0 hrs 29 mins 43 secs CPU time taken for Routing: 0 hrs 33 mins 53 secs This is pretty conclusive to me, and is quite explainable. As others have said, WIR2XNF is really quite a bit slower. This is because all I/O instructions are emmulated and have to go through the 16-bit MS-DOS emmulator. I haven't timed that yet.......I just read my e-mail.... There's a lot of information on NTVDM in the Windows NT 4.0 Resource Kit. A bargain at $69! Austin Franklin darkroom@ix.netcom.comArticle: 4505
Craig Slorach craigs@elec.gla.ac.uk wrote: >I'm looking for info on any FPGA's currently available where the internal >architecture and programming information is known (ie. where I can write to >programming registers myself instead of having to use manufacturers own >tools). Try Xilinx 6000. According to one sales guy, specifiactions for their internal architecture are available because they are intended to be used for on-the-fly reconfigurability and things like genetic algorithms.Article: 4506
If you have experience with any of the many FPGA to ASIC conversion vendors and are willing to share your experiences, good or bad, I would greatly appreciate a reply. Reply directly to me, and I will summarize (anonymously, if you like) to the group. We have two small Xilinx designs, XC5202-5 and XC4003E-3, that we are considering converting, for lower cost. Currently, our favorite vendors are ATS/Microchip, and SiQuest. Anybody? /kehArticle: 4507
Well, well. Some people see a conspiracy at every corner. But reality is different. Designing place-and-route tools is a very demanding task. We have a large software R&D group who has been working for years on the development of such tools, and some of you may think that they still are not quite perfect :-). Our developers have of course access to all the detailed chip information, and Xilinx puts many millions of dollars every year into the development effort. I don't think we would do anybody a favor if we encouraged him ( or her ) to embark on an individual, underfunded development effort in an area as difficult as this. Just my opinion. Peter AlfkeArticle: 4508
In article <01bbc12f$d4b55d60$34c220cc@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes: >every time if given the SAME inputs....but...how do you know what that >logic is going to be? Different compilers compile down to different logic. > Since you don't know what it is going to compile down to, you don't know >if it's good or bad...With a schematic, what you see is what you get... I disagree. Once a VHDL module has been synthesized, you get a structural net list which can be either read textually, or better yet, seen as a schematic. I believe both Viewlogic and Exemplar provide you with such capability (So does Synopsys, Mentor, etc.). So if your timing analysis shows that your design isn't making it, then you can analyze the quality of the synthesis. > >I agree too. But how do you know what the compiler is going to do with the >case statement, since different compilers will generate different results >with the same VHDL code... > I guess that the crux of the matter is that you are worried about having your HDL code be implemented differently by moving across compilers. I believe that in most cases, aside from consultants ;-), a company sticks to one compiler, not a variety and thus your issue becomes irrelevant. But even in your case, as I stated before, you can tell the quality and type of synthesis obtained by the compiler. How hard is it to determine that the code synthesized into a CLA counter vs. a ripple one? Or how hard can it be to be able to tell that the case statement has "ancillary" stuff which should've been removed?. My experience in the synthesis arena doesn't agree with your complain against the HDLs. I've been able to determine the quality of the synthesis without much trouble. >> Floorplanning is needed independent of the design entry method. > >Agreed, but with VHDL, you don't get intellegible names out of the code. >Also, when you change the design, the names change too. At least that's >the experience I have had. There is a way around that....and when we do >VHDL for designs, or our clients do, we do the design so it will give us >consistent naming. > > >There are a lot of self proclaimed Xilinx gurus out there, and self >proclaimed gurus in general, but a bad engineer, with any tool, VHDL or >schematic, is going to get bad results. I spend half my life cleaning up >other peoples bad engineering, and the other half doing what I believe to >be good engineering from scratch (I don't get much sleep...). The real >truth is you have to know the device and the tools in order to do a good >job. BTW, who was this guru? (email, not in group please) > Agree 100%. >schematics, or whatever, will lead to better results. The tools for VHDL >for FPGAs have been pretty poor until recently. The EDA vendors have done >a good job making their tools work with FPGAs recently. I do believe that My experience on the VHDL camp has been that my "efficiency" has increased to the point that I can turn around a new design at a much higher rate than a previously all schematic approach. The point I like to make is, that if the design fits within the same size FPGA, and it meets the same system performance, then I couldn't care if you got there by schematic or by HDL, and I also couldn't care how the synthesizer translated my HDL code, since I've met the design criteria. I would pick the HDL path because it is more maintainable than the schematic, and easier to "read" for a lot bigger audience than the schematic. Also, not all schematics are created equal. If the schematic is drawn such that it is a collection of gates, it is unreadable, period. My experience has been that I find the same idiosyncracies in the way designers draw schematics, as I see designers write HDL code. In fact, you can tell if the HDL coder was a previous schematic kind of guy, or a software-kind of guy by the code they produce. One is more incline to write structural code than the other. :-) >today, you can do a pretty good (near minimum resource utilization, and >somewhat fast timing) design with VHDL. Previously, VHDL used to cap out >at 10Mhz (in a Xilinx 4k). Today, because of better VHDL compilers, and >faster parts, you can get 25+Mhz out of it. I still don't think, nor have >I seen, anyone be able to get near 33Mhz out of VHDL in a Xilinx 4k FPGA. > It depends on the type of application. I've done Xistink applications which do operate on the 33MHz range, but were heavily pipelined. On the other hand, I don't think that a random control logic design, either schematic or HDL based would run in a Xistink any higher than upper 20s. >I also think that data path in schematics (there is no optimization in data >path...) is far better than in VHDL because you can see it. You don't have >to sift through pages and pages of code to figure it out. > I don't know what type of coding you've seen or used, but my experience with VHDL is that if your code is hierarchical, then you can see the data path in an even easier manner than with schematics since it is concen- trated in one place. The same applies to schematics, in that if it is hierarchical, then you can tell of all of the places that the data paths reach, if not, then you have to sift through pages and pages of schematic to tell where is the data path reaching. >This appears to have been the liveliest discussion in this >newsgroup....It's like the Mac is better than PC thing.... I'm glad that you've enjoyed the discussion, but I think that it is more like assembler vs. C stuff. Both do the job, the question is which one lets the designer be more efficient overall. > ErasmoArticle: 4509
I just saw a press release from Xilinx. They are discontinuing some old XC4000 devices and the press release explains their "customer-friendly product discontinuation policy". Xilinx provides 12 to 24 months notice for last-time orders of various products. The section I like is "In addition, Xilinx will use an after-life supplier that specializes in obsolete products to aid customers after the discontinuation date". I guess you place your order with the Psychic Friends Hotline. Michael Holley holley@data-io.comArticle: 4510
>NT - CPU time taken for Partition: 0 hrs 18 mins 49 secs > CPU time taken for Placement: 0 hrs 34 mins 35 secs > CPU time taken for Routing: 0 hrs 46 mins 42 secs > >Win 3.1 - CPU time taken for Partition: 0 hrs 6 mins 30 secs > CPU time taken for Partition: 0 hrs 29 mins 43 secs > CPU time taken for Routing: 0 hrs 33 mins 53 secs Austin, The Partition time difference would suggest that this part of the program is doing a lot of e.g. keyboard checking. If a prog has a very tight loop, and within that loop is doing an INT21 call to see if ctrl-c has been pressed, then that may well run very much slower under NT. Actually PPR also does the INT21 check, but apparently not so often. I cannot account for the PPR slow-down any other way, because it really is just CPU activity. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4511
Peter, Yes, one could just reconfigure the FPGA to change the # of bits/word etc. But there are lots of combinations 7,n 7,e 7,o 8,n 8,e 8,o and then you have 1 or stop bits. That makes 16 different configs And what about baud rate? You generally need at least 300/600/1200...115200 for modern comms products. You would end up with an EPROM packed with different FPGA config files. I really wish somebody did a proper UART, even if it had just the standard 2-byte buffers. Actually, the Zilog SIO was a very efficient design, which is why it is such a pig to get it to work. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4512
The Xilinx XC6200 is a fine grain SRAM FPGA optimized for dynamic reconfiguration. Internal architecture and complete programming info can be found in the datasheet... http://www.xilinx.com/products/fpgaspec.htm Craig Slorach wrote: > I'm looking for info on any FPGA's currently available where the internal > architecture and programming information is known (ie. where I can write to > programming registers myself instead of having to use manufacturers own > tools). > > Does anyone know of such an FPGA (from what I've found in the data books so > far, they talk only about the tools supplied by vendors to produce the > programming code). --------------------------------------------------------------------- / /\/ Colin Carruthers E-mail: cc@xilinx.com \ \ Xilinx Scotland Tel: +44 131 666 2600 x201 / / 52 Mortonhall Gate Fax: +44 131 666 0222 \_\/\ Edinburgh EH16 6TJ, ScotlandArticle: 4513
Peter Alfke peter@xilinx.com wrote: > Well, well. Some people see a conspiracy at every corner. > But reality is different. > Designing place-and-route tools is a very demanding task. We have a > large software R&D group who has been working for years on the > development of such tools, and some of you may think that they still are > not quite perfect :-). > Our developers have of course access to all the detailed chip > information, and Xilinx puts many millions of dollars every year into > the development effort. > I don't think we would do anybody a favor if we encouraged him ( or her > ) to embark on an individual, underfunded development effort in an area > as difficult as this. > Just my opinion. On the other hand, we have one example of a company that made the effort to derive the "dark secrets" of xilinx internals and wrote their own place and route tool. Xilinx bought them out -- ostensibly because the tools were BETTER than Xilinx's own tools, but probably equally as likely to quash the competition. There are a lot of good hackers out there and they produce a lot of good usable software. For example the Gnu C compiler is pretty much an industry standard now, it's better than much of the comptetition, and it's free. There's no reason to assume that a similar effort couldn't produce a good place and route tool. A free place and route tool would shut down a lot of Xilinx's business. The word "conspiracy" has a lot of bad connotations, so maybe a better phrase might be "conservative business practices".Article: 4514
We are looking at doing more VHDL synthesis and are therefore looking at tools. We are interested in using VHDL for everything from simple PAL designs to complex FPGAs. We would prefer to only use one tool to do all (or most) of our parts and we would like the tool to be PC based and interface with ViewLogic which we currently use for all schematic capture. We have the ViewLogic WVOffice ViewSynthesis but have not yet used it. Can anyone comment on how well it performs? Any suggestions as to vendors to particularly look at? -- Mike Kopp GTRI/ELSYS/SENArticle: 4515
I apologize if this is not the proper newsgroup for this posting but I have a 2-month Altera contract in Orange County but you need to be familiar with AHDL. If interested please email me at neilh@tlcsd.com or call at 800/275-4852x228 Thanks. Neil Hutchison/Technology Locator Corporation Regina Steurer-Hall, Resource Manager Technology Locator Corporation 6480 Weathers Place San Diego, CA 92121-3912 Voice: (800)275-4852 Fax: (619)552-6820 Email: reginas@tlcsd.com http://www.tlcsd.comArticle: 4516
In article <32803DAE.167EB0E7@ics.forth.gr>, Manolis Stratakis
<strataki@ics.forth.gr> writes
>Hello,
>
> We are using Allegro to make several complicated PCBs for
>our designs. We use extensively Xilinx FPGAs and other chips but up
>to now we take care our chips not to exceed ~ 100 pins. Actually when
>the package comes in any PGA we can handle it easily with our layout
>software and our lab's facilities. But when it comes to greater chip
>packages we do not have the necessary experience.
>
> Are there any pointers to info about the handling of these
>monster chips? How about the PCB manufacturers, do they normally support
>them? How does the package choice affect the total cost of the PCB?
>It is true that at least for the Xilinx FPGAs the PGA packages tend to
>be a lot more expensive than the respective PLCCs. I would expect this
>to be especially true with the more complicated packages.
From the perspective of PCB manufacture, we make pretty much whatever
you design, and 256 pin devices are not unusual.
PCB manufacturing costs are determined by:
Number of layers
Board Size
Track Width + Gap
Minimum drill size
Roughly in that order. So the impact on cost will depend on your design.
It is possible htat the cost of the test fixture can increase.
Cheers!
Calum MacGregor
Electroconnect Ltd. + 44 (0)1294 221360 <calum@econnect.demon.co.uk>
Design . Fast turn PCB . Flexi-rigid PCB . SMT Assembly . Laser Stencils
Article: 4517This article is devoted to explain the problems I had to submit an article to Integration, the VLSI journal. I write it in those newsgroups because I mailed my complain to the managing editor who does not seem to care about it. If this topic, does not interest you, please skip. If you have remarks, please better e-mail me to "Yannick.Saouter@irisa.fr" since I am not a regular reader of this newsgroup. I do not like the proceeding of multiple crosspostings but I find it here necessary. The newsgroups were chosen for their subject of VLSI architectures and parallelism in general. I would like to tell you about a story which happened to me. In August 1994 I sent an article for submission at "Integration the VLSI journal". The subject was about VLSI systolic arrays. The script was sent to Marion de Vlieger who routed it to Ed Depreterre, who is in charge of the architecture topic in this journal. For those who do not this journal, the typical deadline between submission and first reading report is about 6 or 8 months. After one year I e-mailed a message to Marion de Vlieger in which I ask her to inform me about the status of the referee process. She replied me that she will look after the problem. I had then no answer from her. Six months later I e-mailed a new letter in which I asked her again about the referee process. This time she simply ignores my e-mail. Three months later I e-mailed her again this time being much more insisting. Always no reply. Two months later, I sent an e-mail message to Ed Depreterre, in which I also ask for information about the referee report. He said to me that he was going to see what was going wrong and that I will have soon information. One month later (this lead here to two years delay from first submission), since I still have no information I wrote an energetic e-mail to him in which I was demanding information. He replied then that the report was ready and that he would post it before the end of the week. I effectively received it several weeks later. He was signed by professor Otten managing editor of Integration. The main conclusion of the report was that it was refused to submission and in fact definitively (i.e. no corrections suggested). However the problem is not here: I may accept that some of my articles are immature to be submitted. The real problem is the invoked reasons for that. The main reproaches were: - My article was illegible and contains many english errors (English is not my natural language). To my knowledge my english expression might be heavy but Integration and other publications are not supposed to be written in pure shakespearian style. In anyway, my article before being sent was read and corrected by a professional translator. - Some references of previous works were missing. Although this remark was legitimate, the referee cited some persons who never worked on the precise topic investigated by my article. - My article was out of date because the solution of one problem that I was heuristically investigated is in fact well known. At first the problem I was dealing and the problem treated by the article cited were not exactly the same and thus this article, although legitimate to be cited in my article was in fact useless for my problem. Moreover, the first version of this article was published as technical report in May 1996, so nearly two years after my submission! - Some of the theorems I claimed in my article were in fact false. At no place in the report, I had a mention such that "this theorem is false because ...". Moreover, several reproaches can still be made about Integration: - My script was seemingly read by a unique referee that is contrary to most rules in scientific publication. - The referee seemingly waited two years before to make the report (since he was aware of the work of May 1996) and was not hunted out by the editors. - The referee was likely of bad will or absolutely incompetent: he cannot understand "optimization of number of processors of VLSI arrays" as "minization", seem to ignore that euclidean spaces may contain points as well as vectors, etc ... So my global conclusion is the following one: if you want that your work is published in the scientific community: DO AVOID INTEGRATION THE VLSI JOURNAL, ESPECIALLY IN THE AREA OF VLSI ARCHITECTURES. Its staff seems to do his work in spite of the common sense. At least in my personal case it seems that Marion de Vlieger, Ed Deprettere and Pr. Otten did not have the faintest will to deal seriously my request of submission.Article: 4518
>>>>> "tendy" == tendy the <tthe@aesprodata.com.au> writes:
tendy> Dear all,
tendy> Could any one please advise me about the most compact and fastest
tendy> implementation / algorithm of 16 bit-integer-multiplier. I intend to use
tendy> the Xilinx XC4000 series or the Altera Flex10K. Many thanks !
Your requirements are contradictory.
Article: 4519Hi, Does anyone have some information about simple behavioural VHDL description of "bus matching" (32 bit to 8 bit and viceversa)device? I use a Flex 10K50. Thank you. Matteo Mascagni I.N.F.N. Roma1Article: 4520
Jeffrey C. Marden wrote: > > Hello: > > Is anybody using the Actel Designer tools with Windows NT v4.0 I assume you mean Designer 3.1. We had to get some info from their apps group to set it up properly, though. Special attention needs to be given to the setup of the ObjectStore Server in order to make it available as a service. I suggest calling them. The number's on the back of any of their manuals. -TBBArticle: 4521
Rick Filipkiewicz wrote: > > As far as I'm aware > all FPGA manufacturers still seem to treat this info as a dark > secret. This probably stems from the early days of FPGAs where the > market was so small that the vendors thought the only way to make any > money was to charge the earth for highly vendor specific tools. I would have to disagree with this. I think primarily it comes of the fact that if a vendor releases a specification for programming a device, that specification would necessarily contain enough information for a competitor to be able to fairly easily reverse-engineer the device and come up with a clone and steal sockets. -TBBArticle: 4522
Vincent Himpe wrote: > > hi > > I have a small problem. > > I have a fairy simple circuit : a 24 bit counter with parallel load > The counter is hooked to a comparator which can either reset the counter , or > make it load a new value. > In this way it forms a sequencer. > This should be easy. > > The entire design has some additional registers but these are very low speed. > A Verilog (Synopsys) file is available. > > now comes the tricky part: This counter needs to run at at least 60MHZ !. > > I tried synthesizing it into a xilinx Xc4003 and XC4004 : no luck. > It fits all right. But the maximum speed i can get is around 25 MHz. > > Are there any comonents out there that can do this ?. > After all , i can make the entire circuit with some 74Fxxx series ttl chips.... Vincent, I can't tell you the fastest FPGA - all the leading FPGA vendors offer some very fast devices. In fact I got 69MHz performance for a circuit like the one you described in an ORCA 2ca-4 device. The load to the counter was registered - I doubt you could do it otherwise. This is NOT a benchmark, and I am not saying this device is fastest, but it is more than enough for the circuit you described. In this design, Exemplar's Leonardo detects a loadable counter and a 24 bit comparator. And implements a very fast one of each for the technology you select. I you are interested in the design file I used, or the AT&T foundry script, timing report, etc. - send me email by 11/15/96 - I won't keep this stuff long. Regards, David Emrich Exemplar LogicArticle: 4523
: In article <32803DAE.167EB0E7@ics.forth.gr>, Manolis Stratakis : <strataki@ics.forth.gr> writes : >Hello, : > : > We are using Allegro to make several complicated PCBs for : >our designs. We use extensively Xilinx FPGAs and other chips but up : >to now we take care our chips not to exceed ~ 100 pins. Actually when : >the package comes in any PGA we can handle it easily with our layout : >software and our lab's facilities. But when it comes to greater chip : >packages we do not have the necessary experience. We're using the Xilinx XC3090A with 160 pins and the XC3042A 100 pins quad flat package without any problem (a few of each on the same board). There are no major design problems and manufacturers do not get excited from the .25mm gaps anymore..... You might want to pay attention to the width of the power and ground traces if it gets too dense, but other than that... it is 'a walk in the park'.... well..... ************************************************************************* * Desire, Discipline, | Ron Spiegel, a.k.a. iRon * * Dedication, Determination, | System Administrator & a Design Engineer * * No Excuses..... | RSES - Cutting Edge Design Technologies * * Shut Up and Train! | Washington DC, U.S.A. * *----------------------------+------------------------------------------* * ronxs@dgsys.com | ron@rses.com | http://www2.dgsys.com/~ronxs * *************************************************************************Article: 4524
Systems Pros, Inc. is looking for ASIC & FPGA Engineers. If you are interested or know of someone who may be, I can be contacted as follows: Kevin T. Hawes, Direct Placement Manager Systems Pros, Inc. 164 Westford Road, Suite 2 Tyngsboro, MA 01879 Phone: (508)649-2210 FAX: (508)649-4213 E-mail: khawes@tiac.net If sending a resume to my e-mail, please send a TEXT formatted file.
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