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
On Fri, 3 Mar 2000 20:33:48, "John Janusson" <jjanusson@nospami-o.com> wrote: > In my experience with this design, the three things that caused long P&R > times were lack of horsepower and/or memory on the PC (256MB, PII 450MHz, > NT4.0 performed great), My "KeithKit" is a PII-333 w/160MB (also NT). I also threw it at a PIII-600 (128MB) that we had sitting in a closet. Tomorrow I'll gather more memory from the other "servers" the widget is supposed to go into and see what happens. I'm not convinced I'm memory bound though. There is little or no paging going on. > inefficient use of FPGA global resources (ie. use > only global clocks and resets, enable flipflops at the right frequency), I've moved clocks and write/read enables to global nets. What a pain! Synplify understood the clocks were global until I added other globals. It took some time to figure out why they dropped the clocks. I ended up instantiating all globals. BTW, how do you do an inverting BUFG?. I don't like the way the HDLanalyzer looks. > and > having many constraints on the Xilinx tools (timespecs, routing placement, > etc). In fact, I found overall P&R performance usually was usually better > if I didn't use constraints (other than pinout constraints). But again, > this design didn't push any sort of speed limit... No speed limit here, but how to guarantee any timing without constraints? Again, I only told Synplify about the clock periods. > > So assuming you have enough memory in your PC and your design effectively > uses global routing resources, I would guess the problem is that Symplicity > is annotating constraints to the synthesized netlist (EDIF file read by > Xilinx tools). There should be an option to turn this off in Symplicity... > If you really have to use constraints for performance reasons, enter them > directly (and sparingly) into the Xilinx tool using the constraint editor. I'm figuring this one out. Synplify isn't all that great passing constraints to Alliance. I've ended up putting some pin locks in each place because it doesn't like them otherwise. OTOH, Synplify does use timing for synthesis, so it's a two-edged sword. > > Good Luck, Thanks I'll need it, though haven't had any so far (once upon a time this was a DynaChip design). I got to board fab when that plank was suddenly drawn in. ...blub. ---- KeithArticle: 21101
Ian, A suggestion: Protection shouldn't prevent a copy from working; that's too obvious. Protection should make a copy unreliable. JohnArticle: 21102
On Fri, 3 Mar 2000 22:00:35, Ray Andraka <randraka@ids.net> wrote: > The XCS40 is equivalent to an XC4020E. The routing in the 4020E and > 4025E is relatively sparse. The 4KXL and 4KXLA have additional routing > resources to combat this problem. Additionally, the automatic placement > does not do a very good job. You can probably get much better results > as well as a much quicker place and route if you floorplan the design. > Historically, lots of people had trouble with the routing in the larger > 4KE devices simply because the routing resources are not sufficient for > a reasonably congested randomly placed design. I haven't seen a > spartan40/4020/4025 design yet that wouldn't route with some > floorplanning and perhaps a little tailoring. As a first step, you > might look at the placed design in the floorplanner. Turn on the > routing congestion and see where it is badly congested, then try moving > stuff around to reduce the congestion. Thanks Ray. I've been lurking in this group for a year (give or take) and have appreciated your wisdom (though sometimes scared by the impending doom ;-). I've looked in the floorplanner, but this tool is not intuitive. I see where the problems are, but am not sure what to do about them. I am just baffled why a 20-25% full device is causing me so much lost sleep. I believe I've narrowed it down to the constraints that Synplify is adding in, but they seem perfectly reasonable (one clock setup up on driven nets and zero hold on received nets - at least as I understand the constraints). I *have* learned that I'll have to take time out for a class on this tool before the next step. That Virtex is going to be a mother for timing, though the logic I would call simple. It's mostly data paths. The only "arithmetic" is a few address comparitors. > For the speed of the PAR, the speed and size of your memory is probably > more important than the processor speed. For example, My office machine > is a dual pentium pro200 with 256MB of fast EDO. My laptop is a > PIII-366 Tecra with 64MB. Place and route takes about 8-10 times longer > on the laptop than it does on the slower desktop (and place and route > does not take advantage of multiple processors). Ok. If the system doesn't page, is there any benefit in more memory? These systems aren't paging, at least not much. The only disk access I see is when the log files are written. I'll steal some more memory tomorrow and see, but I'd like to know why more memory would help (limiting paging is obvious). > Bottom line: design to the architecture and do some floorplanning paying > attention to the routing congestion. Sure, but I didn't expect these problems for this trivial design. ---- KeithArticle: 21103
Having just used a PCI prototype board to design and test our fpga co-processor for a PC, the next question is: what is the breakeven number for just distributing our design to various departments with more expensive prototype boards versus getting some custom boards made in an attempt to make the project cheaper? A few facts: the PCI interface logic is implemented by the FPGA on board. We use almost none of the "extras" on the board ( such as I/O connectors, LEDs, etc ).We will not be sure of even approximate numbers until this thing is demo'ed to the departments, but they will surely ask about ballpark numbers. So what kinds of numbers are we talking about to get a PCI PC board with little more than the fpga device & its supporting circutry on it? 10? 25? 100? 1000? Or is something like this already available off-the shelf? TIA.Article: 21104
Dear All Please tell me : 1. How different between Hardware debugger and JTAG programmer in Xilinx Software when I want to download the design into FPGA? 2. How different between the usage of (DONE, DIN, PROGRAM ...) pins and (TSK,TCK...)pins for programming cable? Best Regard mail to me at: ksuwanna@kmitl.ac.th -- Wannarat Suntiamorntut Computer System Design Laboratory (CSDL) Computer Engineering Department Prince of Songkla University, Hatyai, Songkla 90112 Thailand Tel. 66-074-212895 ext.311 Fax. 66-074-212895Article: 21105
"Keith R. Williams" wrote: > Possibly, but a UNIX make isn't going to help much. This is NT, > sorry to say. There are make utilities for NT as well. -- Phil Hays "Are you willing to vote for funding the completion of the third report of the IPCC"? Ask the question!Article: 21106
**** REMINDER ****
Call for Papers
The Second NASA/DoD Workshop on Evolvable Hardware
July 13 - 15, 2000
Silicon Valley, California, USA
http://ic.arc.nasa.gov/ic/eh2000
Sponsored by:
National Aeronautics and Space Administration (NASA)
Defense Advanced Research Projects Agency (DARPA)
Hosted by:
NASA Ames Information Sciences and Technology Directorate
JPL Center for Integrated Space Microsystems (CISM)
Evolvable hardware is an emerging field that applies simulated
evolution to the design and adaptation of physical structures,
particularly electronic systems. The Second NASA/DoD Workshop on
Evolvable Hardware (EH-2000) will bring together leading researchers
and technologists from academia, government, and industry to discuss
advances and the state-of-the-art in this field.
Evolvable hardware techniques enable self-reconfigurability and
adaptability of programmable devices and thus have the potential to
significantly increase the functionality of deployed hardware systems.
Moreover, these techniques have the potential to reduce costs by
automating numerous design and optimization tasks encountered in
engineering design.
A focus of this year's workshop is on real-world applications of
evolvable hardware. Current application areas include adaptive and
reconfigurable computing, circuit and antenna design, and evolutionary
robotics. Evolvable hardware methods could also be effective in
dealing with increased complexity and reliability requirements in
areas such as sensors, MEMS, biomolecular design, quantum computing,
and nanoelectronics.
Topics to be covered include, but are not limited to:
- Evolutionary hardware design (including mechanical and robotic
systems, electronic circuit synthesis)
- Real-world applications of evolvable hardware
- Co-evolutionary methods
- Online and offline evolution methods
- Hardware/software co-evolution
- Testbeds and evolutionary design automation tools
- Self-repairing hardware
- Self-reconfiguring hardware
- Embryonic hardware
- Morphogenesis
- Novel devices and hardware platforms suitable for evolution
- Adaptive hardware, adaptive computing
- Adaptive flight hardware
Important Dates:
Submission deadline: March 17, 2000
Author notification: April 17, 2000
Camera ready manuscript deadline: May 15, 2000
Workshop: July 13-15, 2000
Submission of Papers:
Please see the workshop web page at http://ic.arc.nasa.gov/ic/eh2000
Chair: Jason Lohn, NASA Ames Research Center
Co-Chair: Adrian Stoica, Jet Propulsion Laboratory
Program Co-Chairs:
Silvano Colombano, NASA Ames Research Center
Didier Keymeulen, Jet Propulsion Laboratory
Program Committee:
Leon Alkalai, Jet Propulsion Laboratory (USA)
Forrest H Bennett III, FX Palo Alto Laboratory (USA)
Neil Bergmann, Queensland University of Technology (Australia)
Hugo de Garis, Starlab (Belgium)
Stuart J. Flockton, University of London (UK)
Terry Fogarty, South Bank University (UK)
David B. Fogel, Natural Selection, Inc. (USA)
James A. Foster, University of Idaho (USA)
Pauline Haddow, Norwegian University of Science and Technology (Norway)
Inman Harvey, University of Sussex (UK)
Hitoshi Hemmi, NTT Communication Science Labs (Japan)
Tetsuya Higuchi, Electrotechnical Laboratory (Japan)
Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
Alan Hunsberger, National Security Agency (USA)
Rich Katz, NASA Goddard Space Flight Center (USA)
John Koza, Stanford University (USA)
Daniel Mange, Swiss Federal Institute of Technology (Switzerland)
Pierre Marchal, Swiss Center for Electronics & Microtechnology (Switzerland)
Meyya Meyyappan, NASA Ames Research Center (USA)
Julian Miller, University of Birmingham (UK)
Jose Munoz, Department of Energy (USA)
Masahiro Murakawa, Electrotechnical Laboratory (Japan)
Jordan Pollack, Brandeis University (USA)
Edward Rietman, Lucent Technologies (USA)
Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland)
Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
Adrian Thompson, University of Sussex (UK)
Anil Thakoor, Jet Propulsion Laboratory (USA)
Benny Toomarian, Jet Propulsion Laboratory (USA)
Annie Wu, University of Central Florida (USA)
Ricardo Zebulum, Jet Propulsion Laboratory (USA)
Steven Zornetzer, NASA Ames Research Center (USA)
In Cooperation With:
Numerical Aerospace Simulation (NAS) Systems Division, NASA Ames
Computational Sciences Division, NASA Ames
Integrated Product Team, NASA Ames
Research Institute for Advanced Computer Studies (RIACS)
GECCO-2000: Genetic and Evolutionary Computation Conference
For further information please check the workshop web site or contact:
Jason Lohn
NASA Ames Research Center
MS 269-1
Mountain View, CA 94035, USA
jlohn@ptolemy.arc.nasa.gov
Tel: +1 (650) 604-5138
Fax: +1 (650) 604-3594
Article: 21107Seriosuly getting off topic, but: > Ther "real" risk isn't from the sophisticated engineering team capable > of reverse engineering your design, but rather from the fellow who > finds an application with only an IC or two, i.e. an FPGA and a config > prom... His boards don't work, of course, but he knows your tech > support and warranty policy are good. Are they? I don't know what the policy of the company I work at is, but I would imagine most companies, as soon as they discover counterfeit parts being made, would send out a notice to their customers and not support the conterfeit parts. I suppose some people unsuspectingly purchase counterfeit equipment and get screwed with this approach, but I think most people who have been around the block a few times know when a deal is "too good to be true" and suspect the obvious. Interesting link from Asus (the motherboard guys) on counterfeit motherboards: http://www.asus.com/company/right.html I was in Singapore a couple of years ago, and one of the friendly merchants on Orchard Row took me up to his counterfeit Rolex room. They actually had a side by side comparison of their counterfeit Rolex "guts" (the mechanism inside the watch) next to some (Chinese, I think it said) conterfeit guts, and were pointing out on a sign why _their_ counterfeits were so much better than those of the Chinese...! :-) I didn't buy any coutnerfeit Rolexes, but I did buy some counterfeit Nike apparel to give to a friend who owns a chunk of Nike stock. ---Joel KolstadArticle: 21108
I've recently become interested in microprocessor architecture and have adopted as a personal project to implement a simple processor of some sort in an Altera FPGA. I'd like to learn about the architectures and implementations of various processors in use today and from the past. I'm familiar with the general "big ideas" such as load-store architectures, accumulator-architectures, etc, but I'd like to see some real world designs. I'd like to find some information on the early Intel and Motorola processors; where can I find data on the Intel 4004 and 8080? How about the Motorola 6800? Is there some book or website that offers a comparison of various designs? I'm also interested in seeing a comparison of modern designs, such as x86, Alpha, MIPS, ARM, PA-RISC, PowerPC, etc. Thanks, TobinArticle: 21109
"Keith R. Williams" wrote: > > > Virtex and Virtex-E devices have very rich routing resources. > > Some engineer told here that he achieved more than 90% > > routing resource usage of Virtex. I know another engineer > > personally who showed me that their team have successfully > > used 94% routing resources of Virtex XCV1000. > > Ok, but 22-24% on a Spartan?? Look at the routing resources in the data sheet. There's not a whole lot there for the spartan/4KE parts. If you have a high fan-in, you will need enough routing to get the signals in there. You should probably take another look at how those high fan-in nodes are designed and perhaps find alternative designs that distribute the connections a little better. Floorplanning can reduce the congestion by a ton. -- -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: 21110
I don't know what your design is, but I kinda suspect you are not registering at the IOBs. I push registers into the IOBs whenever I can because it makes the external timing independent of the internal implementation. It also takes those offset thingies and makes them all affect just the pin to IOB (which is fixed), so you can s**tcan them. You can turn off the generation of the xilinx constraints file in synplicity while still using hte synplicity constraints while in synplicity (it is under the options menu I think). The things that add to delay are levels of logic (as a rule of thumb, allot half the clock period to CLB logic delay, the other half leave for routing), high fan-outs, and routes to geographically distant places. Being a first timer, you've probably got all these. You can try relaxing the time constraints some, then looking in the timing analyzer to see which are the mean spirited signals which are giving you the most grief. With that knowledge, and perhaps some knowledge gleaned from looking at the ratsnest in the floorplanner you should get an idea on how to fix up the design. Typical tricks are pipelining, duplicating high fan-out signals, strategic placement and others. Spartan is nowhere near as fast as VIrtex, nor is it anywhere near as rich in routing. Where you are really struggling with the spartan, you will likely have very little problem with the virtex (Xilinx, for a long time wouldn't even put out a floorplanner for Virtex...they told everyone it wasn't necessary). 33 MHz, while not blazingly fast, can be aggressive for a first timer in a Spartan device, especially if it is one of the slower 5v devices. Please don't get scared off by my rants. Most of the stuff I am doing really is pushing the envelope of the device either in density, speed or both. I tend to find the problems with the devices and tools that no one else notices because they never go in those corners. "Keith R. Williams" wrote: > On Fri, 3 Mar 2000 22:00:35, Ray Andraka <randraka@ids.net> > wrote: > > > The XCS40 is equivalent to an XC4020E. The routing in the 4020E and > > 4025E is relatively sparse. The 4KXL and 4KXLA have additional routing > > resources to combat this problem. Additionally, the automatic placement > > does not do a very good job. You can probably get much better results > > as well as a much quicker place and route if you floorplan the design. > > Historically, lots of people had trouble with the routing in the larger > > 4KE devices simply because the routing resources are not sufficient for > > a reasonably congested randomly placed design. I haven't seen a > > spartan40/4020/4025 design yet that wouldn't route with some > > floorplanning and perhaps a little tailoring. As a first step, you > > might look at the placed design in the floorplanner. Turn on the > > routing congestion and see where it is badly congested, then try moving > > stuff around to reduce the congestion. > > Thanks Ray. I've been lurking in this group for a year (give or > take) and have appreciated your wisdom (though sometimes scared > by the impending doom ;-). I've looked in the floorplanner, but > this tool is not intuitive. I see where the problems are, but am > not sure what to do about them. I am just baffled why a 20-25% > full device is causing me so much lost sleep. I believe I've > narrowed it down to the constraints that Synplify is adding in, > but they seem perfectly reasonable (one clock setup up on driven > nets and zero hold on received nets - at least as I understand > the constraints). > > I *have* learned that I'll have to take time out for a class on > this tool before the next step. That Virtex is going to be a > mother for timing, though the logic I would call simple. It's > mostly data paths. The only "arithmetic" is a few address > comparitors. > > > For the speed of the PAR, the speed and size of your memory is probably > > more important than the processor speed. For example, My office machine > > is a dual pentium pro200 with 256MB of fast EDO. My laptop is a > > PIII-366 Tecra with 64MB. Place and route takes about 8-10 times longer > > on the laptop than it does on the slower desktop (and place and route > > does not take advantage of multiple processors). > > Ok. If the system doesn't page, is there any benefit in more > memory? These systems aren't paging, at least not much. The > only disk access I see is when the log files are written. I'll > steal some more memory tomorrow and see, but I'd like to know why > more memory would help (limiting paging is obvious). > > > Bottom line: design to the architecture and do some floorplanning paying > > attention to the routing congestion. > > Sure, but I didn't expect these problems for this trivial design. > > ---- > Keith -- -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: 21111
We seem to be going round in circles. I claim that a digital DLL can do its job with a certain granularity = error of say 50 ps. The error is more or less fixed, definitely not cumulative. But a VCO output frequency must be perfect ( in the long run ). That means, any error must be corrected immediately, since it is cumulative. The DLL eror i not cumulative. That's why DLL can be implemented with purely digital circuitry. Maybe I have said all this before. Peter Alfke ======================= Don Husby wrote: > Maybe, but I think the noise sensitivity for this kind of > limited-adjustable-threshold buffer is about the same as for > the pure digital buffer used in a digital delay line whose > threshold may be fixed, but is still subject to noise on Vcc > and ground. This is especially true when you consider that > the "analog" buffer can (must) have a leisurely rail-to-rail > rise time of >1.0ns, while the digital delay must switch > in < 0.1ns. > > The analog control signal (and its amplifier) has a fairly > large low-pass filter, so is also tolerant of noise. > > -- > 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: 21112
> Spartan is nowhere near as fast as VIrtex, nor is it anywhere near as rich in > routing. Where you are really struggling with the spartan, you will likely > have very little problem with the virtex (Xilinx, for a long time wouldn't > even put out a floorplanner for Virtex...they told everyone it wasn't > necessary). "wasn't necessary"??? Wow. How could they be that far out of touch? What fraction of the posts to this newsgroup say (roughly) "Have you tried floorplanning yet?" I wonder if there is a good story behind that decision. > Please don't get scared off by my rants. Most of the stuff I am doing really > is pushing the envelope of the device either in density, speed or both. I > tend to find the problems with the devices and tools that no one else notices > because they never go in those corners. Funny. All the people I know tend to do that. I suppose it's possible to use an FPGA for an easy project. I've never seen one though. -- These are my opinions, not necessarily my employers.Article: 21113
Hal Murray wrote: > > > Please don't get scared off by my rants. Most of the stuff I am doing really > > is pushing the envelope of the device either in density, speed or both. I > > tend to find the problems with the devices and tools that no one else notices > > because they never go in those corners. > > Funny. All the people I know tend to do that. I suppose it's possible > to use an FPGA for an easy project. I've never seen one though. Whether it is easy or not depends on the designer now, doesn't it. -- -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: 21114
Hi folks; some days ago i tried to start a discussion about experiences with antifuse fpgas. May be it's been the wrong subject ... I know two vendors actel and quicklogic. As far as I know, both of them are much lower in power consumtion than sram- based fpga's and this is exactly what I need. We want to replace our digital board with Virtex and SpartanXL with antifuse fpga's to solve our temperature problem. We are still in discussion whats better to use quicklogic or aldec antifuse FPGAs to replace the xilinx heater. May be someone can give me an any good arguments? I am interested in following questions: 1.How are your experiences with unsing sysnopsys and aldec or quicklogic? 2.Did someone ever ported a vhdl- source made for xilinx spartan to any of this antifuse devices? Any problems (might have an other timing for sure) 2.5 We want to use synopsis fc2... is it really a good idea? Or should we use other eda tools? 3.How about the eda tool provides by quicklogic and aldec 4.How many FPGAs has to go until you will hav one workin' 5.Did someone made experiences with programming services for higer values of these devices? I hope there is someone to find who knows some answers, even if my questions are in a rusty english .... ffArticle: 21115
"Keith R. Williams" wrote: > > > I *have* learned that I'll have to take time out for a class on > this tool before the next step. That Virtex is going to be a > mother for timing, though the logic I would call simple. It's > mostly data paths. The only "arithmetic" is a few address > comparitors. > > > FoSure, but I didn't expect these problems for this trivial design. > > ---- > Keith I wouldn't worry about Virtex - I suspect you will have an order of magnitude less trouble. As an example we did an ASIC prototype last year in an XCV300-4. It used 90% LUTs, 57% CLB registers, 14/16 BlockRams and got to 66MHz fairly easily unfloorplanned [because back in May last year there wasn't one!! Also the 300-4 was the only part we could get]. Each P&R pass was taking about 1.25 hrs on a PII-450+512MBytes. Relaxing the constraints to 50MHz took the time down to less than 45 min. A couple of possibilities not yet mentioned: o Have you tried setting the Synplify ``max fanout'' parameter to something lower than the Xilinx default of 100 ? My normal setting is 32 and in some circumstances I take it down as far as 8. o Have you checked the parameters that Foundation passes to MAP/PAR ? Some of these are really for non-HDL designs & should be switched off. o You have tripped over some subtle and brand new bug in the Xilinx tools. If so join the club. In order to really find out what's going on I think you'll have to make your move out of the GUI playground sooner than you expected.Article: 21116
I am developing an interface to configure a 4000E Xilinx Virtex FPGA through the Select-Map paralell configuration method. Can anyone direct me to a Xilinx document that illustrates the necessary setup and hold times for Data with respect to CCLK? I coulnd't find anything in their online documentation (configuration documents and electrical specifications), nor could I find anything in their tech. support answer database. I would appreciate any info. Thanks. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21117
On Tue, 07 Mar 2000 06:57:25 GMT, Tobin Fricke <tobin@cory.eecs.berkeley.edu> wrote: >I've recently become interested in microprocessor architecture and have >adopted as a personal project to implement a simple processor of some >sort in an Altera FPGA. I'd like to learn about the architectures and >implementations of various processors in use today and from the past. >I'm familiar with the general "big ideas" such as load-store >architectures, accumulator-architectures, etc, but I'd like to see some >real world designs. I'd like to find some information on the early >Intel and Motorola processors; where can I find data on the Intel 4004 >and 8080? How about the Motorola 6800? Is there some book or website >that offers a comparison of various designs? I'm also interested in >seeing a comparison of modern designs, such as x86, Alpha, MIPS, ARM, >PA-RISC, PowerPC, etc. > >Thanks, >Tobin Datasheets for the 8080 can ge had here: ftp://www.jameco.com/jameco_gifs/gallery2/000646/Article: 21118
Jim Stewart <jstewart@jkmicro.com> schrieb in im Newsbeitrag: 7371799D6336F608.6C99816437643EFF.3312317873E61B1F@lp.airnews.net... > I've been working my way through learning the Xilinx Foundation software > and I can't find out where the physical pins get assigned to the pin > labels. Schematic : Just add a property like LOC=P7 to the IPAD, OPAD or IOPAD VHDL : Search all *.UCF Files inside the project directory and add the line NET "MYNETNAME" LOC "P7"; Thats all ! HolgerArticle: 21119
Hans Holm wrote: > Hi folks; > > some days ago i tried to start a discussion about experiences with > antifuse fpgas. > May be it's been the wrong subject ... In this group, probably, not that many posts with respect to antifuse. I can add a few comments. Please see below. ========================== > I know two vendors actel and quicklogic. As far as I know, both of them > are much lower in power consumtion than sram- based fpga's and this is > exactly what I need. We want to replace our digital board with Virtex and > SpartanXL with antifuse fpga's to solve our temperature problem. One thing that you may find is that the available antifuse parts do not have the same density as Virtex parts. One can start a gate counting "discussion," which I will not, but there is about an order of magnitude difference in gates per device (and neglecting boot PROMs). ========================== > 2.Did someone ever ported a vhdl- source made for xilinx spartan to any > of this antifuse devices? Any problems (might have an other timing for > sure) I find that "VHDL-source" is a meaningless term. While having code in VHDL makes it sound like it's portable (just like writing in C [discussion of that language's portability goes to another group]), if there is any instantiated macros you have your work cut out. This is equivalent to having in-line assembly code inside of your C program. An additional issue is whether the architectural features match up. For example, if you need a DLL or more than three low-skew clocks or ... it just might not be a good match. Lastly, as I'm sure R.A. will remind us, to get a good result, the design should be well matched to the architecture. There have also been studies that show that coding style of an HDL can have a very large impact on performance. ========================== > 4.How many FPGAs has to go until you will hav one workin' One. ========================== > 5.Did someone made experiences with programming services for higer > values of these devices? Perhaps a language thing, I did not quite understand this question. ========================== > I hope there is someone to find who knows some answers, even if my > questions are in a rusty english .... Except for question 5, your English is fine, and, of course, my English is a bit less then stellar, too. ---------------------------------------------------------------------- rk History will remember the twentieth stellar engineering, ltd. century for two technological stellare@erols.com.NOSPAM developments: atomic energy and Hi-Rel Digital Systems Design space flight. -- Neil Armstrong, 1994Article: 21120
palfke@earthlink.net wrote: > We seem to be going round in circles. I guess we are. You seem to be debating the merits of DLL vs PLL while I'm off debating the merits of having some analog control over the delay elements of a delay line which may be used to implement either a DLL or PLL. > ... > But a VCO output frequency must be perfect ( in the long run ). That means, > any error must be corrected immediately, since it is cumulative. > The DLL eror i not cumulative. > That's why DLL can be implemented with purely digital circuitry. I fully agree. A DLL is better for most applications, whether the delay is fully digital or has some analog control. The Lucent clock circuit supports a DLL mode as well as a PLL mode which allows you to do things such as clock multiplication and extracting a clock from a serially encoded bit stream. It is my conjecture that a partially-analog implementation has better performance, is cheaper, more flexible, and has similar noise immunity compared to the fully digital implementation. -- 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-5406 Reply-To: "Ron" <skalarv@hotmail.com>Article: 21121
Hello all, I'm going to create a large design when one of the options is using Altera - APEX working with Quartus. I'm looking for the "cons and pros" of Quartus especialy pit falls that u faced during the work. Regards Ron skalarv@hotmail.comArticle: 21122
The first FPGAs I used were Actel's due to the equipment final destination being a satellite. I've since used Xilinx for prototypes and test equipment. The insides of Actel chips are quite different from Xilinx chips. When I did a Xilinx based prototype that later became Actel based flight equipment I was very careful to check that the synthesis tool (Synplify) didn't do anything special in the Xilinx that couldnt be reproduced in the Actel chip. I knew when I started that the design would finish up in an Actel. Synplify takes about 6 times as long to target the same design to Actel compared to Xilinx. Reported device usage 85% A14100 (actually pessimistic) 30% XC4028 (optimistic) One advantage with the Actel place and route tool is the ability to set operating voltage and temperature range. You can then check "best" as well as "worst" case timings. It will also generate an sdf file with min and max timings so you can simulate your placed and routed design at "best" and "worst" case timings. This is useful when you have a 256pin surface mount one-time-programmable chip, you really do want to try your best to get it right first time. I once had a design that simulated fine interfacing to external circuitry at maximum timings but didn't work at minimum timings. (Compiling Actels libraries for back annotated simulation is a lot easier than the Xilinx libraries.) When it doesn't work first time Actels Silicon Explorer is a handy gadget. It allows you to monitor any two signals inside the chip. The software makes it like a logic analyser. I didn't notice a significant difference in power consumption between the A14100A and XC4028EX. Have you done a dynamic power estimate with that big long formula Actel provide? My company usually does one offs so investment in an Actel programmer with the necessary adaptors was considered uneconomic. Apparently our local Actel distributor is the biggest provider of programming services in Europe. If you buy your chips from them they will programme at no extra cost. They are Gothic Crellon Ltd, tel UK +1189 788878. Kate Hans Holm <ff@sigcom.de> wrote in message news:38C4CFD5.F007E949@sigcom.de... > Hi folks; > > some days ago i tried to start a discussion about experiences with > antifuse fpgas. > May be it's been the wrong subject ... > > I know two vendors actel and quicklogic. As far as I know, both of them > are much lower in power consumtion than sram- based fpga's and this is > exactly what I need. > We want to replace our digital board with Virtex and SpartanXL with > antifuse fpga's > to solve our temperature problem. > > We are still in discussion whats better to use > quicklogic or aldec antifuse FPGAs to replace the xilinx heater. > > > May be someone can give me an any good arguments? > > I am interested in following questions: > > 1.How are your experiences with unsing sysnopsys and aldec or > quicklogic? > > 2.Did someone ever ported a vhdl- source made for xilinx spartan to any > of this antifuse devices? Any problems (might have an other timing for > sure) > > 2.5 We want to use synopsis fc2... is it really a good idea? Or should > we use other eda tools? > > 3.How about the eda tool provides by quicklogic and aldec > > 4.How many FPGAs has to go until you will hav one workin' > > 5.Did someone made experiences with programming services for higer > values of these devices? > > I hope there is someone to find who knows some answers, even if my > questions are in a rusty english .... > > ff > > > >Article: 21123
Jim Stewart wrote in message
<7371799D6336F608.6C99816437643EFF.3312317873E61B1F@lp.airnews.net>...
>I've been working my way through learning the Xilinx Foundation software
>and I can't find out where the physical pins get assigned to the pin
>labels.
If you don't explicity assign pin numbers - either on your schematics, or in
your VHDL code, or in a user-constraint file (.ucf), then the tools will
assign them for you. If you let the tools assign the pin numbers, then
there is an option somewhere called "pinlocking" that sticks the assignments
in the UCF.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21124My 2 cents... -- Keith F. Jasinski, Jr. kfjasins@execpc.com > 1.How are your experiences with unsing sysnopsys and aldec or > quicklogic? We use Symplify-Lite and the Silos III simulator included with Quicklogic's tool suite. I have had very good results with very dense designs. Our designs typically use >90% of the logic cells. We use a mixed schematic/Verilog design environment. > > 3.How about the eda tool provides by quicklogic and aldec Quicklogic's tools set is quite good. I am not familiar with Actel's tool set or Aldec simulation. > > 4.How many FPGAs has to go until you will hav one workin' This is a loaded question. It really depends on the designer. If you are thorough, have a clear set of specifications, and simulate it thoroughly, you can do it in one chip. Most of my designs take 3-5 revisions due to my mistakes, lack of clear definition, and the theory that it can take longer to simulate some things than just to try them out. > > 5.Did someone made experiences with programming services for higer > values of these devices? We have our distributor program in production, but have our own programming tools for develpment. > > I hope there is someone to find who knows some answers, even if my > questions are in a rusty english .... > > ff > > > >
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