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
MK Yap writes: > Hi!! > " Error: Delay path from '|bsp_in:73|bytedata_2_.Q' to > '|bsp_in:73|intdata_2_.Q' is 4.2ns, but Clock skew is 2.9ns and hold time > required for '|bsp_in:73|intdata_2_.Q' is 1.4ns - circuit cannot operate > because Clock skew plus hold time of destination register exceeds > register-to-register delay " > I encounter this problem when i've finished compiling the project & doing > the timing analysis. Most of the time, my design did not give me this error > mesg but it happened ocassionally. I changed other part of the circuit but > did not make any changes on the bsp_in portion. What can I do to ensure this > won't happen again? How can i put any constraint and where i should put it? > Thanks. > I'm using Maxplus2 9.3 & Synplify 5.3.1 for my VHDL codes, running on PC, > targetted at flex10k30e. > Pls advice Use a different version of Maxplus2. 9.24 (older) and 9.6 (newer) seem to be fine. -- JamieArticle: 23351
In article <8F5A82CB1shivawellcom@207.126.101.100>, shiva@well.com (Kenneth Porter) wrote: > steve@rsn-tech.demon.co.uk (Steve Rencontre) wrote in > <memo.20000615030058.112C@steve.dircon.co.uk>: > > >In article <8F51E72E1shivawellcom@207.126.101.100>, shiva@well.com > >(Kenneth Porter) wrote: > > > >> [posted and mailed] > > > >Mailed? To whom? Oh well, no matter... > > I cc'd to Altera tech support. They responded with a day. > > >The Jam player will do that. I forget the URL, but it's easy to find > on >Altera's web site. > > They also recommended the same. URL is http://www.jamisp.com. > > Any idea how hard this is to set up? I see the .jam file appear as one > of the Altera compiler outputs. Is it just a matter of plugging in the > ByteBlaster and feeding the jam file as a command line argument to some > JAM utility, or is there much more to it? I mostly want to get a feel > for how much setup time is required. > > steve@rsn-tech.demon.co.uk (Steve Rencontre) wrote in > <memo.20000615030058.112C@steve.dircon.co.uk>: > > >In article <8F51E72E1shivawellcom@207.126.101.100>, shiva@well.com > >(Kenneth Porter) wrote: > > > >> [posted and mailed] > > > >Mailed? To whom? Oh well, no matter... > > I cc'd to Altera tech support. They responded with a day. > > >The Jam player will do that. I forget the URL, but it's easy to find > on >Altera's web site. > > They also recommended the same. URL is http://www.jamisp.com. > > Any idea how hard this is to set up? I see the .jam file appear as one > of the Altera compiler outputs. Is it just a matter of plugging in the > ByteBlaster and feeding the jam file as a command line argument to some > JAM utility, or is there much more to it? I mostly want to get a feel > for how much setup time is required. Yep, it's basically as you surmise. The original documentation was a bit poor, and ISTR I had to check the source to work out the proper command line, but that was a long time back. The only other catch is that if you're running NT (or Win2k), you'll need to install a device driver for the ByteBlaster. I don't recall if that's in the Jam package, but if not, you can get it elsewhere on Altera's web site. If you've installed the ASAP package (or the full MaxPlus2) you'll have it already. -- Steve Rencontre http://www.rsn-tech.demon.co.uk //#include <disclaimer.h>Article: 23352
I don't know what to make of this. I think Austin may be pulling your leg. He starts by making a lot of very interesting claims about the future of FPGAs v. ASICs and how they both will fare in performing larger and larger designs. Illan responds with some technical reasons why he disagrees with what Austin said and asks for further explanation. Austin replys with a link to a web page that is vaguely reminisent of Amway marketing. I think Austin is just kidding some more and is still teasing Steve! If not, how about some technical justification for the claims that were made? Austin Lesea wrote: > > Well, > > Look at our customers' success stories. > > http://www.xilinx.com/company/success/index.htm > > Austin > > iglasner@my-deja.com wrote: > > > Hi, > > > > I might missed something but it seem to me as you belive this huge > > chip when target to FPGA take less time than when target to ASIC. and > > more over they have "have inferior tools" > > > > I wonder how did you come to this conclutions ? ...snip a lot of technical explanation... > > have a nice day > > > > Illan > > In article <3952285C.3DFA8EE7@xilinx.com>, > > Austin Lesea <austin.lesea@xilinx.com> wrote: > > > Wake up & smell the silicon, > > > > > > I couldn't resist responding to this. > > > > > > Steve is in the cube across from me, and we teased him on how > > conservative he > > > was. > > > > > > Like Peter says, we have the time to do what is needed to make this > > scale of > > > technology work: the ASIC/ASSP model is probably limited to less > > than 50 > > > million devices. It is too expensive, too risky, takes too long, > > have inferior > > > tools, and is unable to claim the advantages it once did. > > > > > > http://www.support.xilinx.com/xcell/xl30/xl30_10.pdf was written two > > years > > > ago. It is so satisfying to see the team's vision realized. Thank > > you to all > > > of our customers, and we will continue to provide you with the > > solutions you > > > need to succeed. > > > > > > Austin Lesea, ICDES Group, Xilinx -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23353
I agree Peter. The difference between $100 and $0 is virtually $0 for a real project or a real company. But then if that is so, why does Xilinx need to charge the $100? I get pestered all the time by various vendors wanting me to try their "free" software demos, but I don't have the money to pay myself to spend the time on them. It costs me far more than the $100 to evaluate a product. Xilinx has a lot less to lose by giving away the low end software than the users have to lose in spending the time to evaluate it. Peter Alfke wrote: > > Without arguing specifically for Xilinx, Altera, Atmel, or any other: > > The primary consideration should be the silicon performance, availability, and > pricing. > The secondary consideration should be the software learning curve, and ease of > use. > And third you look at software price. > > If you are halfway serious about achieving something meaningful, > and learning something valuable, > the difference between $100 and zero is "peanuts", i.e. irrelevant. > > Peter Alfke -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23354
In article <3952CB49.F5DAEC24@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: >I agree Peter. The difference between $100 and $0 is virtually $0 for a >real project or a real company. But then if that is so, why does Xilinx >need to charge the $100? I get pestered all the time by various vendors >wanting me to try their "free" software demos, but I don't have the >money to pay myself to spend the time on them. It costs me far more than >the $100 to evaluate a product. Xilinx has a lot less to lose by giving >away the low end software than the users have to lose in spending the >time to evaluate it. Every piece of software sold/given away by Xilinx probably end up burning support time. Xilinx probably doesn't want joe-random-user to be taking up time unless they are at least remotely serous about actually buying parts, and charging some money for it serves to prevent the ubercasual person from purchasing the software. I would guess that each development package used results in at least 1 call to tech support. They do have freebee demos which allow all BUT the final mapping, at least according to the web site. In the same way, Sony charges $20K (it might be $40k, not positive, but I think it is $20k) for a PS2 development system. Although it probably represents a minor fraction of the R&D & manufacturing costs (for what amounts to a very low volume, custom computer and compiler toolkit), and at the same time Sony could practically give them away, they still set it to a suitably high value to discourage casual purchases. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 23355
I'm on my 3rd dual processor system, running under NT4.0. The second processor won't speed up a place and route, or for that matter any single threaded operation (I haven't seen any CAE stuff yet that uses both processors). It does however let me work on other things while a place and route or long simulation are in progress. Avoiding the productivity hit is worth the price of admission for me. You will need more cache and more system memory than you would need in a single processor system, and it will still get slow when there is contention for the disk or I/O. Dan Kuechle wrote: > Anyone out there using a dual processor PC for Xilinx? > > My last project takes about 1.5 hours to complie the single > Xilinx chip if I do nothing else, and upwards of 3 hours if I > try and do some work while the Xilinx s/w is running. Since > my PC is only 350mhz (windows 95) its probably time for > an upgrade. I'm wondering about dual processors, thinking > one could run Xilinx while I use the other to get some real > work done while the Xilinx s/w is running. Anyone got > any insights or recomendations? > > Dual processors will force me into windows 2000 or NT. > Any problems with that? > > Others where I work are interested from an Altera point of > view also. > > Thanks > Dan -- -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: 23356
Hi! It still happens in max+plus2 9.62. I was wondering if it is my design problem or VHDL synthesizer or max+plus2 problem. Using quartus fitter solved this problem.... wierd... My question is: Is this error caused by the software(should maxplus2 take care of this?) or design?? I did not put any constraint on my design. MK Jamie Lokier <spamfilter.jun2000@tantalophile.demon.co.uk> wrote in message news:ys2oaegdnw6y.fsf@pcep-jamie.cern.ch... > MK Yap writes: > > Hi!! > > " Error: Delay path from '|bsp_in:73|bytedata_2_.Q' to > > '|bsp_in:73|intdata_2_.Q' is 4.2ns, but Clock skew is 2.9ns and hold time > > required for '|bsp_in:73|intdata_2_.Q' is 1.4ns - circuit cannot operate > > because Clock skew plus hold time of destination register exceeds > > register-to-register delay " > > > I encounter this problem when i've finished compiling the project & doing > > the timing analysis. Most of the time, my design did not give me this error > > mesg but it happened ocassionally. I changed other part of the circuit but > > did not make any changes on the bsp_in portion. What can I do to ensure this > > won't happen again? How can i put any constraint and where i should put it? > > Thanks. > > > I'm using Maxplus2 9.3 & Synplify 5.3.1 for my VHDL codes, running on PC, > > targetted at flex10k30e. > > Pls advice > > Use a different version of Maxplus2. 9.24 (older) and 9.6 (newer) seem > to be fine. > > -- JamieArticle: 23357
Well, nobody is joking or pulling anybody's leg. This thread started by some incredulous amazement about 500 million transistors in next year's FPGA, and I answered that this was actually a conservative extrapolation. ( It's not magic: A good-sized die is 20 x 20 mm, that is 400 square millimeter or 400 million square microns. A transistor uses less than half a square micron, while all interconnect is stacked on top in eight layers of metal) I don't want to parse Illan's syntax here, but I think he tried to challenge our assertion that ASIC designers will have more trouble with deep submicron than FPGA users will. But that is a fact. At the deep submicron level, things are not as clean and digital as they were in the olden days of Mead-Conway. Capacitive loading, fan-out issues, on-chip transmission-line effects, crosstalk, ground bounce, clock-tree balancing, Vcc and ground distribution etc. are getting really demanding, and every ASIC user will be confronted with these ugly issues. The Xilinx chip designers here in San Jose obviously have to fight the same problems, but the FPGA user can largely ignore these problems, since Xilinx designers had the time and money to study and solve these problems once and for all, and document them in speeds files, so that the "analog mess" seems to be digital again. Nobody is forced to believe this, but nobody should be surprised when next year's ASIC NRE is raised ( because of higher mask cost and design effort), minimum order quantities have shot up, or certain ASIC vendors just have given up on deep submicron. Technological progress favors FPGAs more than ASICs, and it thus tilts the playing field. That's all we wanted to say. We preached this in our seminars more than a year ago. If you don't want to believe us now, let's talk again next year, when we're heading for a billion transistors on a chip. Moore's law has a few more years to go... Peter Alfke, Xilinx Applications ================================================== Rickman wrote: > I don't know what to make of this. I think Austin may be pulling your > leg. He starts by making a lot of very interesting claims about the > future of FPGAs v. ASICs and how they both will fare in performing > larger and larger designs. Illan responds with some technical reasons > why he disagrees with what Austin said and asks for further explanation. > Austin replys with a link to a web page that is vaguely reminisent of > Amway marketing. > > I think Austin is just kidding some more and is still teasing Steve! If > not, how about some technical justification for the claims that were > made? > > Austin Lesea wrote: > > > > Well, > > > > Look at our customers' success stories. > > > > http://www.xilinx.com/company/success/index.htm > > > > Austin > > > > iglasner@my-deja.com wrote: > > > > > Hi, > > > > > > I might missed something but it seem to me as you belive this huge > > > chip when target to FPGA take less time than when target to ASIC. and > > > more over they have "have inferior tools" > > > > > > I wonder how did you come to this conclutions ? > > ...snip a lot of technical explanation... > > > > have a nice day > > > > > > Illan > > > > In article <3952285C.3DFA8EE7@xilinx.com>, > > > Austin Lesea <austin.lesea@xilinx.com> wrote: > > > > Wake up & smell the silicon, > > > > > > > > I couldn't resist responding to this. > > > > > > > > Steve is in the cube across from me, and we teased him on how > > > conservative he > > > > was. > > > > > > > > Like Peter says, we have the time to do what is needed to make this > > > scale of > > > > technology work: the ASIC/ASSP model is probably limited to less > > > than 50 > > > > million devices. It is too expensive, too risky, takes too long, > > > have inferior > > > > tools, and is unable to claim the advantages it once did. > > > > > > > > http://www.support.xilinx.com/xcell/xl30/xl30_10.pdf was written two > > > years > > > > ago. It is so satisfying to see the team's vision realized. Thank > > > you to all > > > > of our customers, and we will continue to provide you with the > > > solutions you > > > > need to succeed. > > > > > > > > Austin Lesea, ICDES Group, Xilinx > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 23358
Hi everyone, At risk of starting a religious war, I'd like to ask all you people out there who do _real_ designs with Xilinx FPGA's, what tools do you currently use, and/or recommend? I'm currently in the process (and have been for some time) of trying to use Xilinx's foundation express but I think it has won the battle :) So we're thinking of investing in a less buggy tools suite and I'm looking for any suggestions. Cheers, James. -- James Kennedy Electronics/Computer Design Engineer IntelliDesign Brisbane, Australia james (at) intellidesign dot com dot au Tel: (07) 3366 6478 Fax: (07) 3366 6471Article: 23359
-------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
Worcester Polytechnic Institute
Worcester, Massachusetts, August 17-18, 2000
http://ece.wpi.edu/Research/crypt/ches
for registration information, check CHES web site above
-------------------------------------------------------
LIST OF ACCEPTED PAPERS FOR CHES 2000
(contributions are ordered by date submitted)
-------------------------------------------------------
J. Hoffstein and J. Silverman.
MiniPASS: Authentication and digital signatures in a
constrained environment.
A. Shamir.
Protecting smart cards from passive power analysis with
detached power supplies.
C. Walter.
Data integrity in hardware for modular arithmetic.
S. H. Weingart.
Physical security devices for computer subsystems:
A survey of attacks and defenses.
T. Pornin and J. Stern.
Software-Hardware trade-offs.
C. Patterson.
A dynamic FPGA implementation of the Serpent Block Cipher.
G. Orlando and C. Paar.
A high-performance reconfigurable elliptic curve processor
for GF(2^m).
T. Kato, S. Ito, J. Anzai, and N. Matsuzaki.
A design for modular exponentiation coprocessor in
mobile telecommunication terminals.
W. Schindler.
A timing attack against RSA with the Chinese Remainder Theorem.
H. Leitold, W. Mayerwieser, U. Payer, K. C. Posch,
R. Posch, and J. Wolkerstorfer.
A 155 Mbps triple-DES network encryptor.
S. Okada, N. Torii, K. Ito, and M. Takenaka.
Implementation of elliptic curve cryptographic coprocessor
over GF(2^m) on FPGA.
J.-S. Coron and L. Goubin.
On Boolean and arithmetic masking against differential
power analysis.
C. Clavier, J.-S. Coron, and N. Dabbous.
Differential power analysis in the presence of hardware
countermeasures
A. Dandalis, V. K. Prasanna, and J. D. P. Rolim.
A comparative study of performance of AES final
candidates using FPGAs.
T. S. Messerges.
Using second-order power analysis to attack DPA resistant software.
J. W. Chung, S. S. Gyoo, and L. P. Joong.
Fast implementation of elliptic curve defined over GF(p^m)
on CalmRISC with MAC2424 coprocessor.
J. Goodman and A. Chandrakasan.
An energy efficient reconfigurable public-key cryptography
processor architecture.
M. A. Hasan.
Power analysis attacks and algorithmic approaches to their
countermeasures for Koblitz curve cryptosystems.
E. Savas, A. F. Tenca, and C. K. Koc.
A scalable and unified multiplier architecture for finite
fields GF(p) and GF(2^m).
S. Trimberger, R. Pang, and A. Singh.
A 12 Gbps DES Encryptor/Decryptor core in an FPGA.
J. Groszschaedl.
High speed RSA hardware based on dynamic true single
phase clocked logic.
H. Wu.
Montgomery multiplier and squarer in GF(2^m).
M. Joye, P. Paillier, and S. Vaudenay.
Efficient generation of prime numbers.
G. Hachez and J.-J. Quisquater.
Montgomery exponentiation with no final subtraction:
Improved results.
R. Mayer-Sommer.
Smartly analyzing the simplicity and the power of
simple power analysis on Smartcards
-------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
CHES Workshop Dates: August 17-18, 2000
-------------------------------------------------------
Web: http://ece.wpi.edu/Research/crypt/ches
E-Mail: ches@ece.orst.edu
-------------------------------------------------------
Program Chairs: Cetin Kaya Koc & Christof Paar
koc@ece.orst.edu & christof@ece.wpi.edu
-------------------------------------------------------
Article: 23360I have just saw the latest datasheets I would like to clarify some points. In my previous post I stated that " [...] The asynchronous parallel mode did not had any speed advantage [...]" Compared with slave serial mode. The reason was the CCLK frequency ranges. The CCLK can be generated in the FPGA using an internal oscillator (500kHz to 1.5625MHz for 4000E at slow mode) or can be external (up to 10MHz). In any programming mode (with Express exception) the FPGA programs a single bit for every CCLK. Even does so in asynchronous parallel mode, converting the programmed byte from parallel to serial at CCLK rate. If you supply the CCLK you can be 20 to 6.4 times faster than if you rely on FPGA CCLK oscillator. The asynchronous parallel mode only allows a byte transfer every 8 (maybe 10?) CCLK cycles. And these are cycles from the _internal_ CCLK oscillator. For a 4000E device at slow mode this means a rate between 500kbit/s (2000ns) and 1.5625Mbit/s (640ns). If your parallel interface is faster than 500kHz/8 = 62.5kByte/s, you could end waiting a lot of time for your RDY/BUSY signals. If your _serial_ interface is not able to generate a CCLK faster than 500kHz, probably you could get lower configuration times switching to a parallel one. I believe that the fast CCLK options were not in the datasheets I used a year ago. I do not know if they also could apply to parallel modes. This would favour the balance to parallel modes. " [...] The asynchronous parallel mode [...] and did not allow to verify the bit stream loading with a CRC" Wrong. The statement was true ONLY for Express parallel mode. I cannot find this mode on present datasheets. Express mode was the fastest one (one byte for every CCLK), but I did not considered it due to the lack of support for CRC verification. Did this mode disappear from the datasheets at some time between now and a year ago? Or I am becoming crazy? I don't have here the old datasheets, so I cannot discard my mental illness. > In looking at the timing data on the XC4000E and XL, I see that the CCLK > output (master mode) can be as fast as 80 ns, but the input requirement > is 100 nS at best. According to this spec, you can't daisy chain the > chips and expect them to work reliably in Fast mode!!! Am I missing > something here? I do not see any error in your reasoning. Maybe I am not so crazy and the specs/datasheets are changing. Maybe the fast mode had to be recently added in a rush to allow a reasonable configure time after somebody decided that Express mode had to be removed, maybe because was fast but not reliable. And maybe the fast CCLK had not yet been fully "debugged". Or maybe I am fully wrong :-) Juan-Luis Lopez SpainArticle: 23361
Hi All, Ive started a design of a VirtexE1000. I am looking for advice on how i should control the taking of the device out of reset after a board reset to the FPGA. Here is a summary of my system. 1. a microcontroller delivers an Asynchronous reset signal to the FPGA. 2. it will be active low for 1 us. 3. the purpose of the reset is to return the device to the same state as it was just after configuration. Here are some of my questions. 1. it is my understanding that all FFs in Virtex can be directly Synchronously set or reset i.e. it does not utilise the LUT. Is this true? 2. should i use the reset signal to reset every FF in my design? (i think so) 3. should i perform a synchronous reset or an asynchronous reset of the FFs 4. should i mix it up so that some FFs are rest Synchronously and some asynchronusly? Is there any real advantage/disadvantage to this in Virtex if the FFs can be reset synchronously without using LUT resources. 5. to re-synchronise the asynchronus input reset i plan to put it through 2 FFs for metastability purposes. In some case i have seen people only use a single FF. Is it best to use 1 FF or 2 FFs? 6. how should i drive the reset signal (whether it is async or sync). Should i use a Bufg (can a Bufg connect to Set reset pins of FF?) Or should i use the low skew lines? Thank you for your time Derek Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23362
James Kennedy a écrit : > > Hi everyone, > > At risk of starting a religious war, I'd like to ask all you people > out there who do _real_ designs with Xilinx FPGA's, what tools do you > currently use, and/or recommend? > > I'm currently in the process (and have been for some time) of trying > to use Xilinx's foundation express but I think it has won the battle > :) > > So we're thinking of investing in a less buggy tools suite and I'm > looking for any suggestions. Hi At the moment, we're using Foundation Express because we can't afford any other tool. From what I've read in this newsgroup or discussed with other designers, Synplify or Leonardo Spectrum are the synthesis tools you should go for. Try a search at http://www.deja.com/ to find old discussions about his topic. I'm afraid you won't find any other tool (mapper, p&r...) than Xilinx's -- Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel +33 1 46 67 51 11 92400 COURBEVOIE Fax +33 1 46 67 51 01 FRANCEArticle: 23363
In article <o5x45.5973 $rH5.14532@nntpserver.swip.net>, "Ulf Samuelsson" <ulf@atmel.spammenot.com> wrote: > Hi Peter > If you register at the www.atmel.com home page, > you can get a complete FPGA design kit for free. > There is also a low cost development board (STK40) for about $150 > which includes the FPGA design kit. Contains a synthesizer but no simulator. > You may be able to get hold of a VEriwell Verilog simulator for free > somewhere. > Not so good, buggy, but may serve its purpose for small designs. > The AT40K family is pin compatible with Xilinx 4000, 5200 and low pincount > Spartan. > > -- > 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 > Hi, I have been using the free Atmel IDS system and produced real designs for real products. It works well provided you know VHDL. You need to make sure you download the latest patches from the Atmel website. Unfortunately the synthesiser still has a few bugs (notably in implementing bidirectional pins - if anyone has any solutions I'd like to hear - perhaps I'll make it the subject of a new post). You can get a free text based VHDL simulator from www.symphonyeda.com. You'll need to write your output to the screen or to a file every clock pulse - but it does work well and it is free. Hope this helps Gordon Haddow Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23364
Hi everyone, I've been using the Atmel FPGA integrated development system for some months, including the Everest VHDL synthesiser. Unfortunately it seems to have a bug in the way bidirectional pins are handled. If you look at the .edf netlist the input line does not come from the pin, but from the output line prior to the output tristate. Atmel don't have a fix. Has anyone else come across this? Does anyone have a way of working round this in VHDL - perhaps coding at very low level? Anyway, here's the code that fails: ----------------------------------------------------------------------- -- Description: -- VHDL code to highlight problems in the EDS VHDL synthesiser -- version 4.0.00L -- 1. Bidirectional pins are not synthesised correctly ----------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; use IEEE.std_logic_unsigned.all; entity zoom is port ( pixel_clock : in std_logic; data_in : in std_logic_vector (9 downto 0); data_ram : inout std_logic_vector (9 downto 0); data_out : out std_logic_vector (9 downto 0)); end zoom; architecture behave of zoom is begin gen_data_ram : process(pixel_clock) begin if pixel_clock = '1' then data_ram <= data_in; else data_ram <= "ZZZZZZZZZZ"; end if; end process gen_data_ram; gen_data_out : process(pixel_clock, data_ram) begin if pixel_clock'event and pixel_clock='1' then data_out <= data_ram; end if; end process gen_data_out; end behave; Regards Gordon Haddow Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23365
Peter Alfke wrote: > > Without arguing specifically for Xilinx, Altera, Atmel, or any other: > > The primary consideration should be the silicon performance, availability, and > pricing. > The secondary consideration should be the software learning curve, and ease of > use. > And third you look at software price. > > If you are halfway serious about achieving something meaningful, > and learning something valuable, > the difference between $100 and zero is "peanuts", i.e. irrelevant. > > Peter Alfke Slight disagreement with this point. If it is the _student_ version that ships for $105 then the difference is not necessarily "peanuts". Remembering back to my student days (about 2 years ago) $105 would definately have been the difference between eating for a fortnight and not eating for a fortnight. Just thought that this should be borne in mind when discussing money with relation to student 'specials'. -- Tim Courtney Electrical & Electronic Engineering mobile : +44 (0)7801 250 903 The Queen's University of Belfast tel(wk) : +44 (0)28 9027 4275 Ashby Building, Stranmillis Road fax : +44 (0)28 9066 7023 Belfast, Northern Ireland, BT9 5AH e-mail : t.courtney@ee.qub.ac.ukArticle: 23366
<iglasner@my-deja.com> wrote in message news:8itk7i$ejk$1@nnrp1.deja.com... > Hi, > I might missed something but it seem to me as you belive this huge > chip when target to FPGA take less time than when target to ASIC. and > more over they have "have inferior tools" > I wonder how did you come to this conclutions ? > I would think the design might take even longer in FPGA The FPGA is a number of repeated patterns around the silicon. The patterns consist of CLB's, IOB's, switch matrix etc. There must be far fewer different types of pattern in a FPGA than in most ASIC's. So Xilinx should be at the leading edge of new silicon by comparison with ASIC's. And the ASIC tools by being able to cope with many more different patterns are unlikely to be as good as optimised FPGA Silicon design tools. The fitting of a design into a FPGA is a completely different thing. FPGA's are reconfigurable so only a small fraction of the Transistors within them would actually exist in an ASIC version of the design. So ASICs will always be able to contain more used Transistors than FPGA's. To design into a FPGA must be easier than into an ASIC on the same silicon family as the detailed silicon problems will probably be better hidden from the FPGA designer. So the FPGA design should be quicker per Million gates, and the FPGA normally contains less gates. Andrew InceArticle: 23367
We are using FPGA Compiler II from synopsys for synthesis, and Xilinx Aliance for back end ... Synopsys FPGA compiler sees to do a better job at synthesis and provides a migration path if you want to go to asics or full custom ... bkk In article <3953177F.FB5954E4@dotcom.fr>, Nicolas Matringe <nicolas@dotcom.fr> wrote: > James Kennedy a écrit : > > > > Hi everyone, > > > > At risk of starting a religious war, I'd like to ask all you people > > out there who do _real_ designs with Xilinx FPGA's, what tools do you > > currently use, and/or recommend? > > > > I'm currently in the process (and have been for some time) of trying > > to use Xilinx's foundation express but I think it has won the battle > > :) > > > > So we're thinking of investing in a less buggy tools suite and I'm > > looking for any suggestions. > > Hi > At the moment, we're using Foundation Express because we can't afford > any other tool. From what I've read in this newsgroup or discussed with > other designers, Synplify or Leonardo Spectrum are the synthesis tools > you should go for. > Try a search at http://www.deja.com/ to find old discussions about his > topic. > I'm afraid you won't find any other tool (mapper, p&r...) than Xilinx's > > -- > Nicolas MATRINGE DotCom S.A. > Conception electronique 16 rue du Moulin des Bruyeres > Tel +33 1 46 67 51 11 92400 COURBEVOIE > Fax +33 1 46 67 51 01 FRANCE > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23368
Ok, ok, wait a moment. I think we are forgetting the driving force behind the choice of FPGA vs. ASIC vs. Full Custom. I believe it is and will continue to be cost vs. performance. And that will vary from design to design. If I have a design that must run at 1Ghz, I will not use a FPGA (today), that is simple. If I have a very high volume design, I will most likeley build a Full Custom IC, etc. etc. There are many factors that will stear that decission. One comment that Peter (from Xilinx) made, I dissagree. FPGA users are not compleatly isolated from all the technology introduced constrains. The only thing that I don't have to deal with in a FPGA is the clock tree. Now, that can be good or bad, depending on your requirements. Fan-out and wiring delays, are even worth in an FPGA (in my oppenion). I love FPGAs, there are many applications that would be hard to implemenet without them. But not every application will/can benefit from them, not matter how big ... As for tools, I can't see a difference from a designers point of view. HDL->Synthesis->Back-end. As a designer, it's easier for me to deal with ASICs & Full Custom - I don't have to deal with back- end tools ;*) Cheers ! bkk Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23369
We are buying Active -hdl v4.0XE (OXE=lower cost as it is targeted just for Xilinx) Bye Aldec (they wrote the foundation sw for xilinx) I tryed the 20 day evaluation demo cd and found it very easy to use. Costs a little more than foundation express but you dont have that yearly 100% renewal cost. ps. it still needs foundation for place and route butfor most FPGAs the $100 foundation base will do the trick and it sounds like you already have express so the learning curve would be small. Active hdl is much more easy and adanced than foundation On Fri, 23 Jun 2000 05:30:22 GMT, James Kennedy <spam@this.com> wrote: >Hi everyone, > >At risk of starting a religious war, I'd like to ask all you people out >there who do _real_ designs with Xilinx FPGA's, what tools do you >currently use, and/or recommend? > >I'm currently in the process (and have been for some time) of trying to >use Xilinx's foundation express but I think it has won the battle :) > >So we're thinking of investing in a less buggy tools suite and I'm >looking for any suggestions. > >Cheers, >James. > > >-- >James Kennedy >Electronics/Computer Design Engineer >IntelliDesign >Brisbane, Australia > >james (at) intellidesign dot com dot au > >Tel: (07) 3366 6478 >Fax: (07) 3366 6471Article: 23370
In article <3952F531.69095D19@this.com>, James Kennedy <spam@this.com> wrote: > Hi everyone, > > At risk of starting a religious war, I'd like to ask all you people out > there who do _real_ designs with Xilinx FPGA's, what tools do you > currently use, and/or recommend? > > I'm currently in the process (and have been for some time) of trying to > use Xilinx's foundation express but I think it has won the battle :) > > So we're thinking of investing in a less buggy tools suite and I'm > looking for any suggestions. Have you installed the upgrades from the Xilinx web site? Leon -- Leon Heller, G1HSM Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 Email: leon_heller@hotmail.com Web: http://www.geocities.com/SiliconValley/Code/1835 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23371
myself a écrit : > > We are buying > > Active -hdl v4.0XE (OXE=lower cost as it is targeted just for Xilinx) > Bye Aldec (they wrote the foundation sw for xilinx) > > ps. it still needs foundation for place and route butfor most FPGAs > the $100 foundation base will do the trick and it sounds like you > already have express so the learning curve would be small. > > Active hdl is much more easy and adanced than foundation Active HDL (which we use, too) is only a compiler/simulator. It still needs FPGA Express for synthesis. -- Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel +33 1 46 67 51 11 92400 COURBEVOIE Fax +33 1 46 67 51 01 FRANCEArticle: 23372
In article <39532E20.D816A507@ee.qub.ac.uk>, Tim Courtney <t.courtney@ee.qub.ac.uk> wrote: >Slight disagreement with this point. If it is the _student_ version that >ships for $105 then the difference is not necessarily "peanuts". >Remembering back to my student days (about 2 years ago) $105 would >definately have been the difference between eating for a fortnight and >not eating for a fortnight. Just thought that this should be borne in >mind when discussing money with relation to student 'specials'. The student version is often available at that price with a textbook of some sort, not just standalone. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 23373
Hi James FPGA Design Flow (HDL): --------------------------- Vhdl editor --> synthesis --> P&R ---> Chip For Xilinx FPGAs (HDL): ------------------ Many tools --> many tools ---> Xilinx tools only ---> Xilinx FPGAs Now there are many tool possobilities for le VHDL Editor and Synthesis parts. But, I'm afraid you won't find any other tools for P&R part of your Xilinx FPGAs. Laurent James Kennedy a écrit : > Hi everyone, > > At risk of starting a religious war, I'd like to ask all you people out > there who do _real_ designs with Xilinx FPGA's, what tools do you > currently use, and/or recommend? > > I'm currently in the process (and have been for some time) of trying to > use Xilinx's foundation express but I think it has won the battle :) > > So we're thinking of investing in a less buggy tools suite and I'm > looking for any suggestions. > > Cheers, > James. > > -- > James Kennedy > Electronics/Computer Design Engineer > IntelliDesign > Brisbane, Australia > > james (at) intellidesign dot com dot au > > Tel: (07) 3366 6478 > Fax: (07) 3366 6471Article: 23374
gordon.haddow@eev.com wrote: > > Hi everyone, > I've been using the Atmel FPGA integrated development system for some > months, including the Everest VHDL synthesiser. Unfortunately it seems > to have a bug in the way bidirectional pins are handled. If you look at > the .edf netlist the input line does not come from the pin, but from > the output line prior to the output tristate. > Atmel don't have a fix. Has anyone else come across this? Does anyone > have a way of working round this in VHDL - perhaps coding at very low > level? Anyway, here's the code that fails: ... snip ... > Regards > > Gordon Haddow > > Sent via Deja.com http://www.deja.com/ > Before you buy. Rather than try to infer the tristate buffers, have you tried instantiating the buffers? To the best of my knowledge instantiation essentially bypasses the buggy part of most VHDL compilers and you can get exactly what you want. The downside is that it is usually more work and is not portable across different manufacturers since you have to use a device specific buffer. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.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