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
wudong99_1998@my-deja.com writes: > I read the phase "Partial Evaluation" from many papers but I don't know > the exact meaning of it. Who can tell me the meaning or where I can > find the meaning. Thanks! I'd be interested to know in which papers you've come across this term. I wasn't aware much work had been done on applying partial evaluation in the context of FPGAs, although I know that someone at Xilinx has been working on it, (they presented work at the Partial Evaluation Summer School in 1998). Anyway to answer your question, Partial Evaluation (PE) is a technique, applicable to pretty much any programming language, where you supply some input to the program earlier than other input. An example would be a cryptographic encoder, where you supply the encryption key and the data to encode. A general purpose algorithm will work slowly as it repeatedly consults the key to figure out what it needs to do. Partial evaluation takes the general purpose program and a key but not the data to encrypt and "partially evaluates" it, that is it evaluates the expressions it can and leaves the expressions it cannot. The left over expressions, known as the residual code, then constitutes a program that is dedicated to encrypting data with just that key. This code is thus hard wired to the key that was given to the partial evaluator, many "if" expressions will have already been evaluated during partial evaluation and will not exist in the residual code and the residual code may run many times faster. Partial evaluation can be applied to more complicated programs such as interpreters. Partially evaluating an interpreter with respect to some program can effectively compile that program thus eliminating the interpretive overhead without a compiler ever having been written. FPGAs can also be seen as removing interpretive layers in that they remove the need to have a microprocessor repeatedly interpret its instructions when in a loop. Combining these two ideas together makes it possible to make very much faster solutions to things like encryption where the gates being used in the FPGA will vary dynamically depending on the key being used. I should perhaps mention I don't know very much about FPGAs past the general concept, but as I understand it the length of time taken by the place+route algorithm hinders the application of partial evaluation. The work at Xilinx involved eliminating gates and reducing the number of hops in connecting wires after the place+route algorithm had been applied, thus the resulting circuit may be faster but wouldn't occupy any less space. Perhaps a cheap'n'cheerful place+route strategy would be useful for such dynamically generated circuits. It needn't be as optimal as existing strategies to outperform them, as existing strategies would only be applied to the general solution to the encryption circuit, the cheap'n'cheerful one could be applied dynamically to the residual circuit. Given my relative lack of knowledge of FPGAs you shouldn't construe this paragraph as comming from someone who entirely knows what they are talking about. Mike ps. this book [1] is a good introduction to partial evaluation, I don't believe it mentions FPGAs once though. [1] Partial Evaluation and Automatic Program Generation, Neil Jones, Carsten Gomard and Peter Sestoft, Prentice Hall 1993.Article: 17801
I was afraid of that. Can this bitstream at least be used to recreate the original in case something happens to this part? I.e. can I read this data (assuming the part is not protected) and program it into another part, or is it in the wrong format at that point? smith On Sun, 05 Sep 1999 13:27:49 -0400, Ray Andraka <randraka@ids.net> wrote: >If the protection fuse is 'unblown' then you won't be able to read it >back no matter what. If not, then you could read back the bitstream, but >it is not going to mean much to you. The translation from logic to >bitstream is not generally published, and it is a monumental effort to >reverse engineer. So the short answer is: you're out of luck. > >-- >-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/~randraka > >Article: 17802
On Sun, 05 Sep 1999 14:06:51 GMT, in <37d278ab.211317103@news.pompano.net> bureauc@hotmail.com (X) wrote: >Here's a question that may or may not be an ignorant one (if it is, >just point me to a FAQ that explains it). I have a circuit of unknown >orign containing an Actel A1010B. This is an anti-fuse based part, I >believe, set up to do address decoding. As others have said, even if you can get the fuse map, turning it back into logic is well-nigh impossible. However, if you're correct that this thing is just doing address decoding, why not just cycle the inputs and monitor the outputs? In the general case with sequential logic, this approach is unworkable, but an address decoder is very simple to reverse-engineer as a black box. -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.uk/ -- remember to despam return addressArticle: 17803
X wrote: > > Can this bitstream at least be used to recreate > the original in case something happens to this part? If the FPGA architecture allows you to reconstruct the programming bitstream (not possible in all types!) then you could of course re-use it to make another copy of the device **in an identical part**. A different part, even from the same manufacturer, would map bitstream bits onto logic elements in a different way and you would get chutney. > I.e. can I read > this data (assuming the part is not protected) and program it into > another part, or is it in the wrong format at that point? As I said above - only if you can get another, blank part of the same type as your original. And only if the original actually allows you to read back the bitstream, of course. Ray Andraka said you can do this with Actel 1010 and I'm sure he's right, but there are some families (QuickLogic for example) in which it's in principle impossible to read back the bitstream after complete programming, because of the way the programming is done. In general, copying any programmable device from one part to another is fairly iffy practice. EPROMs are perhaps an exception (just about). The design files that generated the bitstream are likely to contain all kinds of information (device identification, test vectors, version tracking stuff) that can't reasonably go into the device itself, but are important for reliable (quality-controlled) programming. I can understand your wish to protect future supply of a legacy product where the design files are lost, but you need to be aware that the FPGA makers have put a fair amount of effort into making it as hard as possible for people to rip-off FPGA designs by chip copying! Jonathan BromleyArticle: 17804
I wrote: > [blah blah blah] Doing a quick search I found the following URLs which describe work to dynamically generate circuits for FPGAs by partial evaluation, just thought I'd mention them if anyone else is interested. Reconfigurable Architecture Group http://www.dcs.gla.ac.uk/research/fpga/papers.html Dynamic Synthesis of Correct Hardware (including a link to some nice slides) http://www.dcs.gla.ac.uk/~tfm/dynhw/ MikeArticle: 17805
I would like to know which are the major differences between the PLD's of the above companies. I have worked with ALTERA FLEX series. Thanks YannisArticle: 17806
Bruce Nepple wrote: > I just went through a synthesis round with an Insight FAE. He took my > design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA > Express) and compiled it with Synplicity. It would not fit in the Virtex > part (112%), and completely used up the 4020XLA (100%). I'm not sure if it > met speed with Synplicity. Synopsys used 78% of the Virtex, and about 62% > of the 4020 (which is interesting in itself, since the Virtex supposedly has > more gates - HA!). > > It was a pure "logic" design with lots of registers, state machines and a > few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to > 10 or more levels of logic). > > In the process, he uncovered several Synplicity bugs that were no problem > for Synopsys. > > I believed the "Synplicity is better" stuff, and had it do better on a few > state machine test cases (where I had problems with Synopsys), but for the > "big" design, it went south big time. I'll stick with Synopsys, thank you. > > Bruce The mainstream tools are all about the same. One tool might be better at one application than another, but on average they are all about the same. It's best to try them and use the one that gives you the best results. Synplicity seems to be slightly better than the others but it is by no means the best at everything. In my work, I've found that Synplicity has been consistently better-- but not so much better that I'd give a blanket statement like "Synplicity is the absolute best". As for your trial application, I would not trust the Insight FAE. It's not that they are bad, they aren't, but they don't know your design and don't have the time to really play with it. There are many options that can give a significant difference in logic size. As someone else pointed out, I've found at least one application that Synopsis FPGA Express totally died on. Assuming that your Insight FAE was correct, then that just goes to show you that your mileage may vary... David Kessner davidk@free-ip.com http://www.free-ip.com/Article: 17807
On Mon, 6 Sep 1999, Mike Thyer wrote: > I wrote: > > [blah blah blah] > > Doing a quick search I found the following URLs which describe > work to dynamically generate circuits for FPGAs by partial > evaluation, just thought I'd mention them if anyone else is > interested. > > Reconfigurable Architecture Group > http://www.dcs.gla.ac.uk/research/fpga/papers.html > > Dynamic Synthesis of Correct Hardware > (including a link to some nice slides) > http://www.dcs.gla.ac.uk/~tfm/dynhw/ > > Mike > > Thanx, had some problems accessing the sites but did find out something for the second. It seems that this is a good idea because FPGA's do not have such enormous capacity as a gate array might have, and by putting routing in during the hardware runtime some efficiencies could be obtained. The article pointed out that the same software algorightms used to partially evaluate a program at runtime would be used in a hardware compile to lay out the basic logic. But it seems that some performance is lost in the re-routing time that the FPGA must (?) shut down to re-program. But perhaps another part of the board or system might be in operation at that time? BTW, it would seem that a fault modeling of the FPGA would be difficult because it would depend on the system input at the time of the fault. Perhaps a type of structual test of the un-oberserved logic is more feasible, while the system test will verify the dynamic routing. -al toda ########################################################### Alvin E. Toda aet@lava.net sr. engineer Phone: 1-808-455-1331 2-Sigma WEB: http://www.lava.net/~aet/2-sigma.html 1363-A Hoowali St. Pearl City, Hawaii, USAArticle: 17808
Mostly Good experiences especially with support from Quicklogic. I actually liked the 6.3 version of their software tool as compared to the present 8.0 mainly in the area of post layout simulations and cross probing. Also the highest part they have is the 4090 (90,000 gates). Hope that helps! Wayne Miller wrote: > Anyone have any experience (good or bad) with FPGAs from QuickLogic?Article: 17809
Could anyone point me to some websites for people who make TI compatible DSP cores for download to FPGA's. Really appreciate the help and your time.Article: 17810
Hello I have problem when I download to CPLD It's have error with JTAG program. "not found xc9572_ver2.bsd" I can't load to CPLD how can I solve this problem Regard Wannarat Suntiamorntut ksuwanna@kmitl.ac.thArticle: 17811
Wayne Miller wrote: > > Anyone have any experience (good or bad) with FPGAs from QuickLogic? I've used them in the past (last design: approx. 2 yrs) for several small designs (less than 4 K-gates). I've started with schematic, changed to their included Verilog tools and then to 3rd-party VHDL synthesis and simulation tools with the QL P&R. The chips were fast and easily routable; you could get high utilization and high speed without having to fiddle with cell locations and routing like other chips (IIRC, you couldn't change routing manually except for changing pinout or rerunning the P&R). You could normally assign any pinout without P&R problem, which made PCB design much easier. The tools were pretty good, though when I switched to 3rd-party tools I've lost the cross-probing capability of the QL tools. One problem was the manufacturablity of boards with QL chips: these chips are OTP and can't be programmed on board; you must remove them from the tray to program them and then return them to the tray for the the PCB assembly. This caused a high percentage of bad boards which had to be reworked manually, because the fine-pitch pins are bent easily by this programming method. I haven't been using them for a while so I can't tell you if they've added an ISP capability; if not, PCB yield may be a problem. Another problem: their PC-based programmed was very slow (approx. 5 minutes for a 2-K chip). This problem may have been fixed by better programmers and faster PCs. Regards Assaf SarfatiArticle: 17812
In article <37D45F1F.FA0FBF59@fivedots.coe.psu.ac.th>, wannarat <wannarat@fivedots.coe.psu.ac.th> wrote: > Hello > I have problem when I download to CPLD > It's have error with JTAG program. "not found xc9572_ver2.bsd" > I can't load to CPLD how can I solve this problem > Regard > Wannarat Suntiamorntut > ksuwanna@kmitl.ac.th > > The bsd-files are usually in a directory <Xilinx-Dir>\xc9500\data, where <Xilinx-Dir> is the directory you have installed the developement tools into. I would also check if the environment variable XILINX is set correctly. Best regards -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.Article: 17813
I know that the PAR score is the total amount of time (in ps) that the design is missing its timing constraints. What is the placer score? -JeffArticle: 17814
Folks, Sorry for following up to my own posting, but I wanted to both remind you to please fill out our survey and to announce that we've extended the deadline to 15 September. So, please take a few minutes and visit http://www.vhdl200x.org/survey/surveyPart1.html. Thanks, Paul On 1 Sep 1999 17:02:04 -0400, in comp.lang.vhdl mench@mench.com wrote in article <7qk48c$13l$1@mench.mench.com>: > Dear Colleague, > You can provide an important impetus to the enhancement of VHDL by spending > a few minutes of your valuable time completing a survey. The data > collected by this survey will guide the VHDL 200x team in proposing the > next round of extensions and modifications to VHDL. To participate, please > visit http://www.vhdl200x.org/survey/surveyPart1.html. > As you know, the IEEE requires that the VHDL standard be recertified at > least every five years. There is currently underway a recertification and > language refinement as a "maintenance release," which will conclude late > this year or early next. The VHDL standards community is already working > on the subsequent revision, a significant enhancement, entitled VHDL 200x. > The VHDL 200x revision will dramatically reduce the impact of electronic > system obsolescence and pave the way for future generations of CAD/EDA > systems that support rapid and cost-effective development. > The VHDL 200x team is sponsored and supported by the Air Force Research > Laboratory. The work is being done in cooperation with the IEEE DASC VHDL > Analysis and Standards Group (VASG). Team members include University of > Virginia, Virginia Commonwealth University, Menchini & Associates, EDA > Standards Consulting, and the Advanced Technology Institute. > Please help the design community by completing the survey. We are > requesting that the survey be completed by SEPTEMBER 10th. Initial results > will be presented at the 1999 Fall VIUF Workshop. (The Workshop's > preliminary program is at http://www.vhdl.org/viuf/conf/viuf99/index.html.) > Again, the survey web address is: > http://www.vhdl200x.org/survey/surveyPart1.html. > Thanks in advance for participating. > Sincerely, > The VHDL-200x team -- Paul Menchini | mench@mench.com |"The last thing I want to do is Cadence Design Systems | www.orcad.com | spread fear, uncertainty and P.O. Box 71767 | 919-479-1670[v] | doubt in the users' minds." Durham, NC 27722-1767 | 919-479-1671[f] | --Don Jones, MS's Y2K Product MgrArticle: 17815
Armin, [I posted this from my regular server, but am not sure everything I send out of there makes it to the rest of the world, so am posting via deja as well.] I am not familiar with the language of the partial code you've included, but there are applicable comments for FIFOs in video application that go beyond implementation details: If the FIFO is asynchronous, i.e., the input clock writing data into it is not in any way synchronous to the output clock reading data, you cannot use an "empty flag" (EF) for unloading the output _while the input is active_. To do so is an invitation to problems arising from metastability and/or timing divergence. A typical EF will go active synchronous to the FIFO output circuit, and the EF goes inactive synchronous to the FIFO input circuit. The metastability problem arises when the output (read) circuit samples the EF, looking for it to be inactive. Because the EF inactive transition happens anywhere relative to the output clock, the circuit sampling the flag will at some point go metastable. At video rates, this is likely to occur with significant probability, enough to mess up the output circuit operation to the extent of making a very poor image (missed or duplicated pixels). Another problem is what I've called timing divergence, by which I mean that the EF is sampled in more than one point. Due to the routing of the FPGA, the timing delay is going to be different to the two different sampling points. This timing divergence will eventually cause the EF to be sampled true at one point and false at the other point. Depending on what the circuits do, this will lead to varying degrees of trouble. So, how can FIFOs be successfully used in video? The answer is simple: Never look at the EF unless the input is not active, only look at the EF when in a known video blank period. To avoid overflowing the FIFO during active video periods, construct a Half Full flag (HF), double (or even triple) sample it in only one spot to avoid metastability and timing divergence, and design the FIFO output circuit to work in burst mode when video input is active. Four words may be too shallow a FIFO. Sixteen words is a convenient size, the HF indicates to the output circuit to burst 8 words out of the FIFO during video active period. This may seem like a lot of work, but it is necessary. I've seen (commercially released!) IC's with video ports where is is obvious that someone didn't correctly handle the video FIFO flags. Examining your partial code, I'd suggest looking for a problem in the value of word[].q at the time the case statement is evaluated. If word[] is a two-bit counter which increments dependent upon an EF being inactive, that is most likely the problem. Hope this helps, - John In article <37D13395.93321611@rz.uni-karlsruhe.de>, Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote: > Hello, > > I'm just implementing some video stuff on an Altera Flex8000. > At some points the chip behaves unexpected: > > I have a 4 word FIFO. "dblbuf" is the DMA input and has a > constant value for testing pupose, "word" is the FIFO counter, > "buffer" is the FIFO memory. All pins are fixed, but the device > usage is below 50%. "dllc2" is about 7 Mhz. > > When simulating, everything works fine. In practice, the buffer > sometimes drops information which should be static and constant!!! > > Worse, when I shift the buffer contents by 16 bits fixed, > it drops information even during simulation (routing dependent). > > What's wrong? Is the chip so prone to routing? Is the compiler > reducing something to asynchrone logic? Are the LPM modules > more stable? > > Armin > > dblbuf[15..0] : dff; -- constant > buffer[63..0] : dff; > word [1..0] : dff; > > buffer[].clk = dllc2; > case word[].q is > when 0 => buffer[15.. 0].d = dblbuf[]; > buffer[63..16].d = buffer[63..16].q; > when 1 => buffer[15.. 0].d = buffer[15.. 0].q; > buffer[31..16].d = dblbuf[]; > buffer[63..32].d = buffer[63..32].q; > when 2 => buffer[31.. 0].d = buffer[31.. 0].q; > buffer[47..32].d = dblbuf[]; > buffer[63..48].d = buffer[63..48].q; > when 3 => buffer[47.. 0].d = buffer[47.. 0].q; > buffer[63..48].d = dblbuf[]; > end case; > > Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.Article: 17816
a@z.com wrote in message <37D15566.571C649D@z.com>... >Can you share your design with the group so we can have an independent >verification of your reports? If it is true than a huge leap forward has been >made by FPGA Express which until now was trailing badly both Synplicity and >Exemplar LS. I wish I could share the Verilog for the design, but it is pretty proprietary stuff. I did not use the FPGA Express timing constraints (through the XNF) . I put all pin and timing constraints in a .ucf file. I only used Synopsys constraints to assign pullups and to specify the frequency for the 2 clock domains (50Mhz, compile for speed). It took about 5 minutes to compile under Synopsys and the FAE said it took about 5 minutes under Symplicity (which he thought was strange). It's about 6K lines of Verilog and comments in 14 files. All of the state machines (2 have over 20 states) are one hot and are compiled with // synopsys parallel_case full_case pragmas (very important!!). All states are explicity defines as parameters. All 107 of the ram register arrays are instantiated as 16x1 bit cells. There is a BIG internal 32 bit tri-state bus with about 15 read/write registers (some are pretty sparse). It has 167 IO, with 140 IOB Flip flops. 32 pins have input register, output register and input buffer used. Version wise, I am using FPGA Express 1.5i with all service packs, and I assume the FAE used the latest and greatest Symplicity. This is what the FAE told me: <quote> I attached the results. I made the changes we discussed, contacted Synplicity and let them know what to expect (e.g. some bug reports), and have decided that I need to look at this again with v5.2 which is in pre-release now. I think the issues with this code reside in the Verilog compile engine. The way Synplify works is that it first compiles the code into a generic format ready for mapping. The next step is to invoke technology specific mappers to map and optimize that logic into a specific device family. There are different mappers for the 4000E, the 4000XL(A), the Spartan, the Spartan XL, the Virtex, etc. The technology mapping is actually the key to Synplicity's success, since their mappers are the best in the industry today. The problem is, if they do not get a good compile on the input code, there is not much the mapper can do to compensate. They do not necessarily have the best compiler (yet...), but as we pick them apart, they improve. FYI, Synopsys has the industry standard Verilog compiler. All other synthesis engines must comply (resistance is futile). Synopsys lacks in the technology mapping arena. <endquote> I wish there were some simple way to change my code (strip out comments and rename internal nodes) so no one could infer or determine functionality. I don't have the time. Bruce > >On the other hand you could try the FreeDES design at http://www.free-ip.com. >The author was not able to use FPGA Express at all (synthesis took over 6 >hours). > >What were the versions of the FPGA Express and Synplicity tools you used? > >Catalin Baetoniu > >Bruce Nepple wrote: > >> I just went through a synthesis round with an Insight FAE. He took my >> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA >> Express) and compiled it with Synplicity. It would not fit in the Virtex >> part (112%), and completely used up the 4020XLA (100%). I'm not sure if it >> met speed with Synplicity. Synopsys used 78% of the Virtex, and about 62% >> of the 4020 (which is interesting in itself, since the Virtex supposedly has >> more gates - HA!). >> >> It was a pure "logic" design with lots of registers, state machines and a >> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to >> 10 or more levels of logic). >> >> In the process, he uncovered several Synplicity bugs that were no problem >> for Synopsys. >> >> I believed the "Synplicity is better" stuff, and had it do better on a few >> state machine test cases (where I had problems with Synopsys), but for the >> "big" design, it went south big time. I'll stick with Synopsys, thank you. >> >> Bruce >> >Article: 17817
Actually, the Insight FAE is good, and spent quite a bit of time tweaking my code to get it to work with Synplicity. I agree with your conclusion..... My whole point in posting is BE CAREFUL "Your Mileage May Vary". I really expected Synplicity to do better. I've been using (and complaining about) Synopsys (Design Compiler and now FPGA Express) for years, so maybe I unconsciously write "Synopsys Compatible" code. Bruce David Kessner wrote in message <37D3CDFA.7FC48550@free-ip.com>... >Bruce Nepple wrote: > >> I just went through a synthesis round with an Insight FAE. He took my >> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA >> Express) and compiled it with Synplicity. It would not fit in the Virtex >> part (112%), and completely used up the 4020XLA (100%). I'm not sure if it >> met speed with Synplicity. Synopsys used 78% of the Virtex, and about 62% >> of the 4020 (which is interesting in itself, since the Virtex supposedly has >> more gates - HA!). >> >> It was a pure "logic" design with lots of registers, state machines and a >> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to >> 10 or more levels of logic). >> >> In the process, he uncovered several Synplicity bugs that were no problem >> for Synopsys. >> >> I believed the "Synplicity is better" stuff, and had it do better on a few >> state machine test cases (where I had problems with Synopsys), but for the >> "big" design, it went south big time. I'll stick with Synopsys, thank you. >> >> Bruce > >The mainstream tools are all about the same. One tool >might be better at one application than another, but on >average they are all about the same. It's best to try them >and use the one that gives you the best results. Synplicity >seems to be slightly better than the others but it is by no >means the best at everything. > >In my work, I've found that Synplicity has been consistently >better-- but not so much better that I'd give a blanket statement >like "Synplicity is the absolute best". > >As for your trial application, I would not trust the Insight FAE. >It's not that they are bad, they aren't, but they don't know your >design and don't have the time to really play with it. There are >many options that can give a significant difference in logic size. > >As someone else pointed out, I've found at least one application >that Synopsis FPGA Express totally died on. Assuming that >your Insight FAE was correct, then that just goes to show >you that your mileage may vary... > >David Kessner >davidk@free-ip.com http://www.free-ip.com/ > >Article: 17818
Assaf Sarfati <azarfati@bioil.jnj.com> wrote: : Wayne Miller wrote: ... : Another problem: their PC-based programmed was very slow (approx. 5 : minutes for a 2-K chip). This problem may have been fixed by better : programmers and faster PCs. Also, they insist on people using Windows or HP, but no Linux port available... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 17819
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes: > Also, they insist on people using Windows or HP, but no Linux port > available... Because they will only " ... consider to support the Linux platform in the future if such a need becomes strong." So, until you get stronger you are " ... encouraged to use the Windows platform ... ". Regards, Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 17820
Bruce Nepple wrote in message ... > >a@z.com wrote in message <37D15566.571C649D@z.com>... >>Can you share your design with the group so we can have an independent >>verification of your reports? If it is true than a huge leap forward has >been >>made by FPGA Express which until now was trailing badly both Synplicity and >>Exemplar LS. > >I wish I could share the Verilog for the design, but it is pretty >proprietary stuff. > >I did not use the FPGA Express timing constraints (through the XNF) . I put >all pin and timing constraints in a .ucf file. I only used Synopsys >constraints to assign pullups and to specify the frequency for the 2 clock >domains (50Mhz, compile for speed). It took about 5 minutes to compile >under Synopsys and the FAE said it took about 5 minutes under Symplicity >(which he thought was strange). It's about 6K lines of Verilog and comments >in 14 files. I've been using the 2.1i tools for a couple of weeks now. FPGA Express, now at version 3.2, has improved, tho' it's hard to say whether or not some of the improvements are due to the synthesis tool, or the place and route tools, or (as the Insight rep told me), the speed files have changed. My simple example was a 32-bit added. I saw a blurb on the xilinx web site that an XLA part could do a 32-bit adder @ 108 MHz. With the 1.5i SP2 tools, I couldn't get it to go much faster than about 70 MHz if I instantiated a CORE adder. A vhdl sum <= a + b; wouldn't go faster than about 35 MHz. I sent a note pointing this out to the Xilinx hotline, and went back and forth a couple of times (the tech support told me to use a .ucf, etc. etc.). He finally sent me his results with my code, and it turns out he was using the 2.1i tools. well, a couple of weeks later, the 2.1 tools arrive, and I try the sum <= a + b adder, and whaddaya know, over 100 MHz. Go Figure. As I said, it's hard to say what really improved. -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu The Republican Party: "We've upped our standards. Now, up yours!"Article: 17821
Are you sure that Synopsis didn't throw out half of your design. In my experience when one synthesis tool gets results that are twice as good as another it's because of a bug that causes the tool to throw out logic that it shouldn't. I've never seen this happen in Verilog, but I've seen happen several times with VHDL. Josh Rosen, Polybus Systems David Kessner wrote: > > Bruce Nepple wrote: > > > I just went through a synthesis round with an Insight FAE. He took my > > design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA > > Express) and compiled it with Synplicity. It would not fit in the Virtex > > part (112%), and completely used up the 4020XLA (100%). I'm not sure if it > > met speed with Synplicity. Synopsys used 78% of the Virtex, and about 62% > > of the 4020 (which is interesting in itself, since the Virtex supposedly has > > more gates - HA!). > > > > It was a pure "logic" design with lots of registers, state machines and a > > few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to > > 10 or more levels of logic). > > > > In the process, he uncovered several Synplicity bugs that were no problem > > for Synopsys. > > > > I believed the "Synplicity is better" stuff, and had it do better on a few > > state machine test cases (where I had problems with Synopsys), but for the > > "big" design, it went south big time. I'll stick with Synopsys, thank you. > > > > Bruce > > The mainstream tools are all about the same. One tool > might be better at one application than another, but on > average they are all about the same. It's best to try them > and use the one that gives you the best results. Synplicity > seems to be slightly better than the others but it is by no > means the best at everything. > > In my work, I've found that Synplicity has been consistently > better-- but not so much better that I'd give a blanket statement > like "Synplicity is the absolute best". > > As for your trial application, I would not trust the Insight FAE. > It's not that they are bad, they aren't, but they don't know your > design and don't have the time to really play with it. There are > many options that can give a significant difference in logic size. > > As someone else pointed out, I've found at least one application > that Synopsis FPGA Express totally died on. Assuming that > your Insight FAE was correct, then that just goes to show > you that your mileage may vary... > > David Kessner > davidk@free-ip.com http://www.free-ip.com/Article: 17822
Visit the Embedded Web
======================
A major new resource for designers, programmers and developers of
Embedded 8/16 and 32 bit microprocessors has just been launched.
COMSOL provide Europe's widest range of development tools and our site
now includes support for most microprocessors from PIC to PPC's.
To that we have now added hundreds of useful links creating the
"Embedded Web", the best jumping off point for European designers
searching the web.
Our range of ICE, C, C++, RTOS and TCP/IP tools has recently been
enhanced with JTAG & BDM debuggers, Flash programmers and Embedded
Windows GUI's.
Visit us at http://www.computer-solutions.co.uk
<<<<<< If you are UK based >>>>>>
<<<<<< you might even win >>>>>>
<<<<<< a bottle of champagne. >>>>>>
Regards, Chris
-----------------------------
Chris Stephens E-mail: sales@computer-solutions.co.uk
Computer Solutions Ltd. Phone & Fax: +44 (0)1 932 829 460
1a New Haw Road, Addlestone,
Surrey, KT15 2BZ England http://www.Computer-Solutions.co.uk
For the largest range of embedded microprocessor development tools in the UK
Article: 17823Hi, Anyone have any experience with FPGAs from Lucent (ORCA FPGA)? I have a problem with the mapping process because the ORCA's software clips and removes all my output ports, giving error messages like: '<output_register_name>/NEOBUF (NEOINV) undriven or does not drive anything', '<output_register_name>/NEOLATCH (NEOLATCH) undriven or does not drive anything', '<pad_name>.PAD (NEOPAD) undriven or does not drive anything'. Thanks a lot Jose Luis Ayala Electronic Engineering Department Technical University of Madrid Spain Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.Article: 17824
SynaptiCAD timing diagram analysis, HDL test bench generation and Verilog simulation tools are now available direct in the UK and Scandinavia from EuroEDA Limited. Email info@euro-eda.com for information, or visit our web site http://www.euro-eda.com -- EuroEDA Limited Phone: +44 (0)1933 676373 Fax: +44 (0)1933 676372 Email: info@euro-eda.com Web: http://www.euro-eda.com
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