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
Oh, synplicity certainly does find the sync reset/set. The hard part is trying to keep it form inferring it if that is not what you want eml@riverside-machines.com.NOSPAM wrote: > > On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez" > <sramirez@deleet.cfl.rr.com> wrote: > > >Andy, > > The ultimate and most elegant fix is to switch to Synplicity. > >-Simon Ramirez, Consultant > >-Synchronous Design, Inc. > > Except that, last time I looked, Synplify didn't know that Virtex had > a sync reset. This can really mess up your CLB calculations. Don't > know if this has been fixed. Anyone feel brave enough to run up a web > page comparing different synthesisers? -- -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: 25626
eml@riverside-machines.com.NOSPAM wrote: > > On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez" > <sramirez@deleet.cfl.rr.com> wrote: > > >Andy, > > The ultimate and most elegant fix is to switch to Synplicity. > >-Simon Ramirez, Consultant > >-Synchronous Design, Inc. > > Except that, last time I looked, Synplify didn't know that Virtex had > a sync reset. This can really mess up your CLB calculations. Don't > know if this has been fixed. Anyone feel brave enough to run up a web > page comparing different synthesisers? Anyone rich enough to own copies of all of the synthesizers? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25627
4 bit adders in Atmel aren't bad. As you are probably aware by now, the AT40K doesn't have a fast carry chain, so if you are looking to do fast adds of more than a few bits you wind up learning about fast adder structures and the area consequences for using them. If you are not speed critical, a ripple carry adder works fine in AT40K. When you start pushing the performance, unlike FPGAs with fast carry chains, you need to start looking at fast carry schemes. Paul Maddox wrote: > > Ben, > > > > > One thing I found useful is to print out a copy of > > data sheet of the family of FPGA's you are using and any data > > libraries and data macro function descriptions. > > sadly the Atmel website is a bit lacking in .PDF files for these chips.. > Im hopeingtheres stuff onthe CD with the IDS software I have. > > > Also if your software is time limited it might be wise to > > wait until you got back and you install the software on a virgin > > PC. > > > > Its not time limited, and Ive not installed it yet.. I panic everytime I > install new software > incase it screws up my PC. > > > > > Many FPGA's are similar in design so general design ideas apply > > to many devices. FPGA's in general don't map well to wide simple > > gates like a 12 input NAND gate but map better to functions of 3 > > or 4 variables like a 2 input multiplexer or ripple carry adder > > cell.Registers are often free with every logic cell as well. > > Small ram like 16xN may have to synthesized taking up a large > > number of logic blocks. > > the Atmel has distributed RAM so Im hopeing I can use that... > > > The other thing is to understand the design you are creating > > well in advance.Some logic layouts don't work well and others do > > often with re thinking of the layout. KISS allways works best. > > (Keep It Simple Stupid ). Good luck on your project. > > > > Ive done the design I want using discrete logic, but its 26 odd logic chips > mostly 4 bit adders and latchs (with a bit of SRAM).. > I like to keep stuff simple, it helps when it comes to debugging! > > Thanks for the advice > > Paul > > > Ben. > > -- > > "We do not inherit our time on this planet from our parents... > > We borrow it from our children." > > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk -- -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: 25628
david lindauer <dlindauer@notifier-is.net> writes: > David Kessner wrote: > > They patented what the instruction did. One could argue that they didn't > > patent an algorithm-- only a way of doing an algorithm. These instructions > > are basically do a load-shift-and-or. We could do these instructions using > > those standard 4 instructions, but the patent covers doing them in a single > > instruction. > > um... doesn't motorola have such an instruction in the 680x0 series? The 68030 (and some others) do an automatic alignment via hardware. It's a "simple" rearrange the bytes operation. ---------------------------------------------------------------------- Everett M. Greene (The Mojave Greene, crotalus scutulatus scutulatus) Ridgecrest, Ca. 93555 Path: mojaveg@IWVISP.comArticle: 25629
bjolin@lin.foa.se (Björn Lindgren) writes: > Intel also managed to get a patent on something published by another company > several years earlier and thereby could be considered as common knowledge. Lots of patents are this way. It depends upon how you phrase the patent (obfuscation, adding novel twists, etc). At an old company I was at, there was a push to get software to submit more patents (hardware was already good at this, as should be the case). One of the ideas they suggest was to take an _existing_idea_, and apply it to our company's line of work. Ie, to use broad strokes, take an idea of "mirrored backups of data to removeable media", and turn into "mirrored backups of data in a medical ultrasound machine". It seemed absurd, but that's exactly what our competitors were doing, and it was in a way self-defense. While I agree that hardware people do seem more attuned to noticing when things are patentable, on the other hand I don't believe most software and algorithms should be patentable. (ie, the set-uid bit fits my notion of something patentable, the XOR for moving a GUI's cursor is borderline, and having a Start menu is plainly not justifiably patentable)Article: 25630
Paul Hovnanian ® <hovnania@bcstec.ca.boeing.com> writes: > I don't think that any system that depends on a small group of > patent examiners, no matter how smart or well paid they are, can > keep up with developments in all areas of industry. Alot of 'prior > art' exists but is not known well enough outside of a specific > industry where an examiner might be aware of it. In some cases, > someone may have incorporated some technique or idea into a product > for years without considering it to be patentable. What about a form of peer-review? The drawback being you've got to show your idea to competitors, but maybe that snag can be ironed out.Article: 25631
You could contact the local Altera sales rep and/or distributor. They have evaluation dongles for short-term (30/60 day) licensing, which they might well loan you out of compassion for your plight. By the way (oops, BTW), I agree with another respondent, you should do the multi-device partitioning yourself (pencil and paper). You understand the logical grouping of functions and interconnect (and critical timing paths) *much* better than any SW tool might. Consider this an extension of the "floorplanning" step in your design. Good luck, Bob Elkind gk7eong wrote: > > Hi, > > I'm a final year electrical electronics engineering student. I'm using > Max Plus 2 Baseline 9.6 to do my final year project. Is there anyone out > there with full licences? Can you send me a copy of your license.dat or > can anybody tell me how to get the partitioner features from it. Thanks > in advance.Article: 25632
Darin Johnson wrote: > > Paul Hovnanian ® <hovnania@bcstec.ca.boeing.com> writes: > > > I don't think that any system that depends on a small group of > > patent examiners, no matter how smart or well paid they are, can > > keep up with developments in all areas of industry. Alot of 'prior > > art' exists but is not known well enough outside of a specific > > industry where an examiner might be aware of it. In some cases, > > someone may have incorporated some technique or idea into a product > > for years without considering it to be patentable. > > What about a form of peer-review? The drawback being you've got to > show your idea to competitors, but maybe that snag can be ironed out. That's my understanding of how its done in other countries. Following an initial application (which establishes who was first in line) members of industry (maybe any interested person) can submit a review of the patent. Generally, these reviews have to be backed by careful analysis and data (not just an opinion for or against) and they are used by the patent examiners to asist in thei research. I'm not sure if there is a 'pull' or 'push' system to get these reviews. It might be possible to put your name on a mailing list for certain subject areas. -- Paul Hovnanian | (here) mailto:hovnania@bcstec.ca.boeing.com Software Conflagration | (there) mailto:Paul@Hovnanian.com Control | (spam) mailto:postmaster@mouse-potato.com -----------------------+--------------------------------------------- I lost my emotional baggage on my last flight of fancy.Article: 25633
The maximum clock period is derived from the maximum path delay (including setup time) between edge-triggered storage elements in single-clock synchronous systems. This assumes the simplest design methodology. Period. If you want to keep life simple, this is what time and experience has proven works well. If you want to complicate your life, there are lots of ways to do it: 1. consider minimum as well as maximum path delays, plus maximum clock distribution skews, and use these to derive maximum clock frequency. You will probably need to derive a *minimum* clock frequency as well, since depending on minimum path delays implies this requirement. 2. you could try multiple clock phases, possibly combined with latch based storage elements (rather than edge-sensitive "flip-flops"), and you still need to consider maximum and minimum path delays and maximum clock skews (between all clock phase distribution networks). This generally removes the need for minimum clock frequency, but does have a cost in terms of design maintainability, design time, design verification, designer life expectancy, designer marriage life expectancy (e.g. "Darling, put the scope probe down and COME HOME!!"), etc. In any case, don't take anyone's word that single-clock synchronous design is safe and simple. Do the investigation yourself. Every digital system designer needs to do this once in their lives (it's like building your own light sabre, if you want to become a jedi). In the process you gain necessary insight into clock distribution, clock theory, etc.; *AND* you gain an understanding of the potential risks and benefits of straying from the simple path (which is sometimes-but-rarely a genuinely good idea). The other half of the "build your own light sabre" exercise is figuring out if synchronizers to avoid meta-stable conditions are *really* necessary... but that's another discussion thread! Good luck! -- Bob Elkind erika_uk@my-deja.com wrote: > > Hey, > > Could someone of you explain me PHYSICALLY why the path delay between > two synchronous components is considered as the maximum clock period. > > The logic levels are1 and 0. > so if i send a pulse 1 and later 0 in less than the path delay, from > where comes the problem > dV=-E.dx, and the electrons have the same speed, so why the conflict > occurs? > > --Erika > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 25634
Your design is going into an infinite loop at that point. You can go to Options > Simulation Options in MTI and increase the iteration limit. But even if hte default iteration limit is reached (5000), it probably means that there is an infinite loop at that time in simulation. What you might wanna do is to run simulation for maybe 1 ns less than at the time when this error happens. Then step through the simulator and see which line in the source code MTI hangs at. Mujtaba Tomasz Brychcy wrote: > Hello, > > Simulation of model before synthesis is correct. When i simulate the same > model but after synthesis during simulation in MTI 5.2c occur the problem: > > iteration limit reached. Possilbe zero delay oscillation. > > I do not know what do? > > Please about help > > I attach files: > > file before synthesis: controllogic(synth).v > file after synthesis: controllogic.v > testbench: tb_controllogic.v > > P.S I know that the problem occur exactly when signal ReadCn goes to high > state. > > Tomek > > -- > Department of Electrical Metrology > Technical University of Zielona Gora > > T.Brychcy@ime.pz.zgora.plArticle: 25635
Dan/Ben,
In general, as Ben said, both caps are a very good and much better
decoupling method than just 0.1uF.
I have seen both used and both work. The 0.01uF/0.1uF combination is a
more conservative and relaible design for high frequency designs. I have
never seen quantitative results, though, to determine just how much better
it really is. I have seen analytical results that say it is better.
I think Ben meant "power distribution system" rather than "power
supplies." The power distribution system includes but isn't limited to the
connector power and ground pins, the power and ground plane design, and the
decoupling caps.
The way I see it is that 0.01uF caps are cheap. If you have the real
estate and a few bucks to spare, why not use them?
-Simon Ramirez, Consultant
Synchronous Design, Inc.
> > Is such a recomendation useful ?
> >
> > Dan
>
> That is true, it is better than a cap of .11 uf?
> For the high frequencies the .01 cap has less
> inductance and is able to respond power supply fluctuations quickly until
> the .1 cap can catch up. With transistors switching in ps range you need
> very good high freq response on the power supplies.
>
> --
> "We do not inherit our time on this planet from our parents...
> We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>
Article: 25636We have a design that, in its present configuration, uses a Virtex internal DLL to phase lock some external chips to the (input) Xilinx PCI core clock. I send a clock feed out one of the Virtex pins and present it to a clock buffer which does the fanout. I feed back one of the clock copies to the Virtex and present it to the feedback input of the DLL. The clock buffer we are using has a maximum skew of 1 ns between outputs. We are considering moving the fanout functionality inside the Virtex, to save on external parts count. The issue I have a question about is the following. When one sets up the constraints for the P&R tool (Alliance in this case), is there a way of doing this so that one can specify the **maximum skew** between any 2 clock outputs? In other words, is it possible to fan out a clock inside the Virtex for external use and simultaneously approximate (dare I say guarantee?) the low skew among all clock outputs that is characteristic of an external buffer? Thanks for any response. Lawrence lperegrim@ksa1.comArticle: 25637
On Thu, 14 Sep 2000 07:06:16 +0000, Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote:
>Well most programers program at the C level... some even make it
>to C++ :)
You mean 'D' ?
sdb
--
| Sylvan Butler | Not speaking for Hewlett-Packard | sbutler-boi.hp.com |
| Watch out for my e-mail address. Thank UCE. #### change ^ to @ #### |
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. --Benjamin Franklin, 1759
"Don't Tread On Me!"
Article: 25638This is a multi-part message in MIME format. --------------FBEC8FD144DD41A19592D688 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "Paul Hovnanian ®" wrote: > all areas of industry. Alot of 'prior art' exists but is not known well enough > outside of a specific industry where an examiner might be aware of it. In some > cases, someone may have incorporated some technique or idea into a product > for years without considering it to be patentable. Now, unaware of this (or worse > yet, with full knowledge) a competitor 'discovers' this idea and applies for a > patent. If the prior use of this isn't obvious to an outsider (you might have > to reverse engineer a product or examine a manufacturing process), the first > person has no defense in our patent system unless he(she) is lucky enough > to intervene in the application prior to its final decision. Surely there must be some appeal process available after this 'final' decision. Are you saying that if I've been building widgets for twenty years, and someone comes along, reverse engineers and patents a doohickey that is part of the widget, that person now has the right to ask me for royalties? If I can prove that I designed the doohickey twenty years ago, it _must_ be possible to overturn the patent examiner's decision to grant that patent!?!? Just because the patent office doesn't know about my use of it, and I don't know the application is in process, makes it legal to steal it!?!? --------------FBEC8FD144DD41A19592D688 Content-Type: text/x-vcard; charset=us-ascii; name="jsmith.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John L. Smith Content-Disposition: attachment; filename="jsmith.vcf" begin:vcard n:Smith;John L. tel;work:858-320-4102 x-mozilla-html:FALSE url:http://www.visicom.com org:Visicom;Imaging Products adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA version:2.1 email;internet:jsmith@visicom.com title:Principal Engineer x-mozilla-cpt:;30864 fn:John L. Smith end:vcard --------------FBEC8FD144DD41A19592D688--Article: 25639
"Darin Johnson" <darin@usa.net> wrote in message news:uaed9o4fn.fsf@nokia.com... > bjolin@lin.foa.se (Björn Lindgren) writes: > > > Intel also managed to get a patent on something published by another company > > several years earlier and thereby could be considered as common knowledge. > > Lots of patents are this way. It depends upon how you phrase the > patent (obfuscation, adding novel twists, etc). > ARM Ltd has some key patents that probably would not hold up in court. One of the key requirements of any interrupt processing in a CPU is that it must be able to execute the interrupt and return without destroying the current context. In ARM , there is no specific interrupt handling except that the CPU executes intstructions. The it follows logically that the context must be protected from another interrupt until the CPU has saved the current context. Yet they patent it. Ridiculous..... Another patent is that they figured out that people are interested in good code density. The "thumb" patent is having two possibly totally unrelated instruction sets execute on the same pipeline using a mode bit. The only thing the instruction sets should have in common is that the data path of both instruction sets are of the same size. Like noone knew that 32 bit RISC instructions had poor density. The classical book on RISC (KAtevenis) states that "Garrison and VanDyke havbe studied how much RISC code size would be reduced by encoding the same instruction set vith variable length fields and instructions [GaVD81]". In the light of the ARM threats to the "www.open-cores.com" activity it would be interesting to see how easy the ARM patents would fall down in court...." > While I agree that hardware people do seem more attuned to noticing > when things are patentable, on the other hand I don't believe most > software and algorithms should be patentable. (ie, the set-uid bit > fits my notion of something patentable, the XOR for moving a GUI's > cursor is borderline, and having a Start menu is plainly not > justifiably patentable) -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel SwedenArticle: 25640
The trick to good designing with the AT40K is to use the RAM blocks. Have been working on a few design. 48 12 bit PWM timers running at 10 kHz PWM output frequency implemented in a 5 k FPGA is not too bad. 8 x 8 bit PWM timers with a PWM output frequency of 120 kHz in the also in a 5k gate FPGA. Both designs use the SRAM extensivly instead of logic and the same design would be much larger using a "normal" FPGA architecture. Time domain multiplexing is also used. I.E: Run the SRAM much faster than the actual logic and conext switch between the different instances. This way you only need to implement logic once for each type of peripheral instead of once for every instance. If you want to implement multiple UARTs, you could do the same. I think a 5k AT40K FPGA easily could do 8 UARTs at a VERY low cost and have plenty of room to spare. -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "Ray Andraka" <ray@andraka.com> wrote in message news:39C25EAB.6F90DA0@andraka.com... > 4 bit adders in Atmel aren't bad. As you are probably aware by now, the AT40K > doesn't have a fast carry chain, so if you are looking to do fast adds of more > than a few bits you wind up learning about fast adder structures and the area > consequences for using them. If you are not speed critical, a ripple carry > adder works fine in AT40K. When you start pushing the performance, unlike FPGAs > with fast carry chains, you need to start looking at fast carry schemes. > > Paul Maddox wrote: > > > > Ben, > > > > > > > > One thing I found useful is to print out a copy of > > > data sheet of the family of FPGA's you are using and any data > > > libraries and data macro function descriptions. > > > > sadly the Atmel website is a bit lacking in .PDF files for these chips.. > > Im hopeingtheres stuff onthe CD with the IDS software I have. > > > > > Also if your software is time limited it might be wise to > > > wait until you got back and you install the software on a virgin > > > PC. > > > > > > > Its not time limited, and Ive not installed it yet.. I panic everytime I > > install new software > > incase it screws up my PC. > > > > > > > > Many FPGA's are similar in design so general design ideas apply > > > to many devices. FPGA's in general don't map well to wide simple > > > gates like a 12 input NAND gate but map better to functions of 3 > > > or 4 variables like a 2 input multiplexer or ripple carry adder > > > cell.Registers are often free with every logic cell as well. > > > Small ram like 16xN may have to synthesized taking up a large > > > number of logic blocks. > > > > the Atmel has distributed RAM so Im hopeing I can use that... > > > > > The other thing is to understand the design you are creating > > > well in advance.Some logic layouts don't work well and others do > > > often with re thinking of the layout. KISS allways works best. > > > (Keep It Simple Stupid ). Good luck on your project. > > > > > > > Ive done the design I want using discrete logic, but its 26 odd logic chips > > mostly 4 bit adders and latchs (with a bit of SRAM).. > > I like to keep stuff simple, it helps when it comes to debugging! > > > > Thanks for the advice > > > > Paul > > > > > Ben. > > > -- > > > "We do not inherit our time on this planet from our parents... > > > We borrow it from our children." > > > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk > > -- > -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: 25641
erika_uk@my-deja.com wrote: >Hey, > >Could someone of you explain me PHYSICALLY why the path delay between >two synchronous components is considered as the maximum clock period. > >The logic levels are1 and 0. >so if i send a pulse 1 and later 0 in less than the path delay, from >where comes the problem >dV=-E.dx, and the electrons have the same speed, so why the conflict >occurs? > >--Erika Yes you can use multiple wave fronts in a single path and this is a (albeit more recently invented) way to do logic design. But this is not what we usually do. The EDA tools we use are not designed for that methodology. Assume you can have only one wavefront in a path and you can see why the min period is the clk->q + path delay + setup. Muzaffer Sender: eric@ruckus.brouhaha.comArticle: 25642
"John L. Smith" <jsmith@visicom.com> writes: > Surely there must be some appeal process available after this 'final' > decision. Are you saying that if I've been building widgets for > twenty years, and someone comes along, reverse engineers and patents > a doohickey that is part of the widget, that person now has the right > to ask me for royalties? If I can prove that I designed the doohickey > twenty years ago, it _must_ be possible to overturn the patent > examiner's > decision to grant that patent!?!? Yes. Shipping a product that embodies an invention is considered to be prior art for patent purposes. If you invented it, kept it secret, built four units, kept three on a shelf, and gave one to your brother-in-law, that probably would NOT count as prior art.Article: 25643
"John L. Smith" <jsmith@visicom.com> writes: > If I can prove that I designed the doohickey > twenty years ago, it _must_ be possible to overturn the patent > examiner's > decision to grant that patent!?!? But if you're a small time doohickey manufacturer, can you afford the legal fees to overturn the patent? Large corporations often just give each other blanket cross-licenses for patents, so it's just the small guys who end up worrying about such things.Article: 25644
FPGA 2001: Call for Papers
Ninth ACM* International Symposium on Field-Programmable Gate Arrays
Monterey, California
February 11-13 2001
Submissions due: September 29, 2000
web site: http://www.ecs.umass.edu/ece/fpga2001
The annual ACM/SIGDA International Symposium on Field-Programmable
Gate Arrays is the premier conference for presentation of advances
in all areas related to FPGA technology. For FPGA 2001, we are
soliciting submissions describing novel research and developments
in the following (and related) areas of interest:
* FPGA Architecture: Logic block & routing architectures, I/O
structures and circuits, new commercial architectures,
Field-Programmable Interconnect Chips and Devices (FPIC/FPID),
Field-Programmable Analog Arrays (FPAA).
* CAD for FPGAs: Placement, routing, logic optimization,
technology mapping, system-level partitioning, logic generators,
testing and verification, CAD for FPGA-based accelerators.
* Applications: Innovative use of FPGAs, exploitation of FPGA
features, novel circuits, high-performance and
low-power/mission-critical applications, DSP techniques,
uses of reconfiguration, FPGA-based cores.
* FPGA-based computing engines: Compiled accelerators, reconfigurable
computing, adaptive computing devices, systems and software.
* Rapid-prototyping: Fast prototyping for system-level design,
Multi-Chip Modules (MCMs), logic emulation.
Authors are invited to submit PDF of their paper (12 pages maximum) by
September 29, 2000 via E-mail to fpga2001@cse.ucsc.edu. Notification of
acceptance will be sent by November 22, 2000. The authors of the accepted
papers will be required to submit the final camera-ready copy by
December 6, 2000. A proceedings of the accepted papers will be published
by ACM, and included in the Annual ACM/SIGDA CD-ROM Compendium publication.*
Address questions to:
Martine Schlag, Program Chair, FPGA 2001
Dept. of Computer Engineering,
University of California, Santa Cruz
Santa Cruz, CA 95064
phone: (831) 459-3243
fax: (831) 459-4829
Email: martine@cse.ucsc.edu
General Chair: Scott Hauck, U. of Washington
Program Chair: Martine Schlag, UCSC
Publicity Chair: Russ Tessier, U. Mass.-Amherst
Finance Chair: Steve Trimberger, Xilinx
Program Committee
Ray Andraka, Andraka Consulting Arun Kundu, Actel
Mike Bershteyn, Quickturn Miriam Leeser, Northeastern U.
Richard Cliff, Altera Wayne Luk, Imperial College
Jason Cong, UCLA Margaret Marek-Sadowska, UCSB
Andre DeHon, Caltech Jonathan Rose, U. Toronto
Eugene Ding, Lucent Martine Schlag, UCSC
Carl Ebeling, U. Washington Herman Schmit, CMU
Scott Hauck, U. Washington Charles Stroud, UNC-Charlotte
TingTing Hwang, Natl. Tsing Hua U. Russ Tessier, U. Mass.-Amherst
Sinan Kaptanoglu, Adaptive Silicon Steve Trimberger, Xilinx
Tom Kean, Algotronix Steve Wilton, U. British Columbia
Sponsored by ACM SIGDA, with support from industry.*
Please visit the web site <http://www.ecs.umass.edu/ece/fpga2001> for
more information.
*Pending approval
Article: 25645http://www.xess.com claims to have it in stock. > is the Xilinx Student Edition 2.1 actually available from anywhere > or is it still on the way? > Last I heard was on 24/7/00:Article: 25646
Hello, a few months back I purchased an XS40-010XL+ from XESS
corporation (http://www.xess.com.) The board is populated with an
8051uC and Xilinx XC4010XL ("10k system gates") FPGA, with a 128k X 8
async SRAM chip. The board has its own VGA connector (you are
responsible for implementing the display controller circuit), a PS/2
keyboard connector, and standard connector headers giving access to all
84 I/O pins of the FPGA.
Initially, the board was great, but I've since discovered 10k gates
isn't a whole lot at all! So now I'm looking to move up to a larger
FPGA board.
XESS's next higher board is a Virtex (XCV-50) product, but it costs
$699. Considering the XS40-010XL+ was only $239, this seems like a huge
price jump. XESS's Virtex boards come with much more memory and
circuitry (RAMDAC, stereo audio codec, video capture, etc.) but I don't
need a lot of it. Does anyone know of a similar FPGA board which costs
less?
Article: 25647I am not rich, but do have FPGA Express v3.4 (with Foundation v3.1) and Synplicity Pro v6.0. Overall, I like to use Synplicity much more. Its schematic view and critical path analysis are very helpful. The performance of systhersized results are almost always better than Synopsys. Only one design forced me to switch back to Synopsys. It has 12 125MHz/16bit Serdes inputs (12 Rx clocks routing locally) across to a global 133MHz clock domain. Synplicity failed. wq998 In article <8ptmo6$1pvu$2@noao.edu>, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: > eml@riverside-machines.com.NOSPAM wrote: > > > > On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez" > > <sramirez@deleet.cfl.rr.com> wrote: > > > > >Andy, > > > The ultimate and most elegant fix is to switch to Synplicity. > > >-Simon Ramirez, Consultant > > >-Synchronous Design, Inc. > > > > Except that, last time I looked, Synplify didn't know that Virtex had > > a sync reset. This can really mess up your CLB calculations. Don't > > know if this has been fixed. Anyone feel brave enough to run up a web > > page comparing different synthesisers? > > Anyone rich enough to own copies of all of the synthesizers? > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25648
<eml@riverside-machines.com.NOSPAM> wrote in message
news:39c205c4.14815385@news.dial.pipex.com...
> Except that, last time I looked, Synplify didn't know that Virtex had
> a sync reset.
As someone who's just fixed a bunch of code to deal with this supposed
"problem," I can tell you that actually, Synplify DOES know about
synchronous resets. HOWEVER... it DOES NOT know about GSR. As you're
aware, the 'flops in a Virtex CLB can have an asynchronous or synchronous
set/reset -- but not both. So guess what happens with this code --
process(Clk,Reset)
begin
if Reset='1' then
q<=(others=>'0');
elsif rising_edge(Clk) then
if r='1' then -- This is supposed to be synchronous reset
q<=(others=>'0');
else
q<=d;
end if;
end if;
end process;
?????
That's right... Synplify happily decides to route RESET to the CLB's "reset"
input (and configures the 'flop for asynchronous resets), and muxes what was
supposed to be your synchronous reset in with the data path. Blecch.
But, before you thing this is that awful, consider:
1) Synplicity is following Xilinx's recommendation to use general routing
resources instead of GSR for reset. I don't like the fact that you have no
choice in the matter, but I can't blame them too much for toeing the Xilinx
party line.
2) You often don't really need an asynchronous reset anyway. Change the
code above to:
process(Clk)
begin
if rising_edge(Clk) then
if r='1' then -- This is supposed to be synchronous reset
q<=(others=>'0');
else
q<=d;
end if;
end if;
end process;
...and you WILL get a synchronous reset. Woo hoo! Yes, in the words of Ray
Andraka, not having a global async. reset will "make an ASIC designer's
blood curdle," but just don't mention what you've done at your next design
review, and you'll be fine.
In fact, if I recall correctly, the Xilinx power-on resetwill (in this case)
reset the 'flop anyway.
(BTW, this is all in Synplify 6.0.0, which -- despite some bugs -- is a nice
improvement over 5.3.1.)
> This can really mess up your CLB calculations.
We have an XCV400 that went from 61% CLB usage to 58% just by spending 15
minutes running around ditching unneeded async resets.
> Don't
> know if this has been fixed. Anyone feel brave enough to run up a web
> page comparing different synthesisers?
We've got Synplify and FPGA Express (but both are the Xilinx-only licensed
versions) at work... anybody have Spectra?
---Joel Kolstad
Article: 25649<wq998@yahoo.com> wrote in message news:8pus5o$km1$1@nnrp1.deja.com... > I am not rich, but do have FPGA Express v3.4 (with Foundation v3.1) and > Synplicity Pro v6.0. Overall, I like to use Synplicity much more. Its > schematic view and critical path analysis are very helpful. If you can believe it... in my experience it's timing estimates are pretty far off. It tends to overestimate logic delay and underestimate route delay. Our current design has a 53MHz clock running around, and meets PAR timing just fine, even though Synplify claims the timing margin is -5.6ns. Yeah, right. > The > performance of systhersized results are almost always better than > Synopsys. FPGA Express is pretty dismal. People who bitch about how buggy Microsoft's operating systems are should try FPGA Express for awhile... > Only one design forced me to switch back to Synopsys. It has 12 > 125MHz/16bit Serdes inputs (12 Rx clocks routing locally) across to a > global 133MHz clock domain. Synplicity failed. [Cough] We've got an HP, I mean Agilent, HDMP-1536 running at fiber channel speeds. The '1536 needs byte-wide data feed to it at 106.25MHz, and spits out 2 bytes of data with two clocks 180 degrees out of phase. We had to build the ROM32x1's ourselves to make timing. Synplify would have met the timing, but the ROM it inferes exposes a bug in Xilinx PAR that causes PAR to error out. Specifically, the 6B->5B decoder needs a 64 entry ROM, and the mux Synplify builds to route the outputs of two ROM32x1's together causes the problem. ---Joel Kolstad
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