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
chi wrote: > Hello, > > Can i get a sample XSVF file or SVF file? > > Thanks and Regards, > Srilekha Just do a simple VHDL design, synthesize for a Coolrunner or other FPGA and generate the corresponding SVF file with the FREE Xilinx Webpack. Note you can do that with Aletra tools too. Laurent www.amontec.comArticle: 64826
Need 20 of them ASAP, possibly 50. Also interested in service bureaus with experience migrating designs from Xilinx to Altera and back. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 64827
Sorry, make that 25 pieces. "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:U0kNb.1018$pp4.325@newssvr29.news.prodigy.com... > Need 20 of them ASAP, possibly 50. > > Also interested in service bureaus with experience migrating designs from > Xilinx to Altera and back. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > >Article: 64828
Peter Alfke wrote: > > That posting suggested to deduce the max operating power backwards from > the package thermal resistance. > Do NOT do that ! > Package choice is dominated by cost and price consideration, both on the > part of the chip manufacturer and on the part of the user. > To make the assumption "because it comes in this high thermal resistance > package, it will never dissipate more than x Watts" is, excuse the > word, silly. > Most FPGAs these days can be melted down by a crazy (but legitimate) > design running at an outrageous ( but legitimate) clock frequency. > It's up to the user to keep the junction temperature within spec. All we > manufacturers can do is give you the best analysis tools we can come up with... > Peter Alfke, Xilinx > ============================= > Ralph Malph wrote: > > But one way you can set a ceiling is to figure > > out the maximum dissipation the package can provide and assume that can come from either of the two supplies. The may be very conservative, but > > it will give you a *maximum*. No one said that Peter. The termal characteristics limit the power that can be used in a given chip. So if you are sizing the power supply, then this is a realistic number to go by. If a user wants to put a higher power design in the FPGA, then it might even be a good idea for the power supply to limit the power at the package level. Keep in mind the purpose of the discussion, to size the power supply.Article: 64829
On Wed, 14 Jan 2004 12:19:46 -0500, Ray Andraka <ray@andraka.com> wrote: Hi Ray, >Which is a big problem if you are structurally instantiating inside a generate. VHDL lets you >use a generate to plunk down multiple instances, and you can use a function in the RLOC string >so that the instances are not placed atop one another. As far as I can tell, you still can't >do that with verilog2001. Yes, that's right. Martin Euredjian did have a ugly hack that works under certain conditions though: http://groups.google.com/groups?selm=mO8gb.12043%24iG.9361%40newssvr25.news.prodigy.com Regards, Allan.Article: 64830
Rene Tschaggelar wrote: > > > Thanks Peter, > the first sensible answer. What is wrong with a simple formula ? > Eg Imax = Io + 4mA/Mhz + I/O_load. > > It'd help specifying the power supply as well as the heatsink. > Rene, unfortunately it is not that simple. • Io is just the static leakage current, which tends to be junction-temperature dependent, and unfortunately has increased dramatically with 130 and 90 nm technology. Like a hundred times :-( • mA per MHz depends on the frequency of each node, times the capacitance of that node, and all this accumulated over the whole chip. Some people (notably our friendly A competitor) make the tacit assumption that everything behaves like a 16-bit counter, But that can lead to very optimistic results, compared to a real DSP-like circuit where everything is clocked at 300 MHz, and half the flip-flops and interconnects change each clock period. • I/O load is usually not static, but rather a load driving board- and input capacitances. So you again need the capacitance and average frequency of each pin. This is why power calculation is such a chore. On top of this, a 50% tolerance guess is no good. You don't want to guardband your supply by a factor 2, and you definitely cannot be wrong by a factor 2 when you calculate the junction over-temperature. Theoretically, you have only between 50 (?) degrees max inside the box, and 85 degrees at the junction. There is not much room to make a mistake and accept an error or even a widetolerance. That's why I have recommended for years to "try it out". With FPGAs (but not with ASICs) that is relatively easy, and you can be within a few percentage points. You will see hardly any variation between speed grades in this respect... This is not a pretty story, but it might help when you understand the difficulties. Peter Alfke, Xilinx ApplicationsArticle: 64831
Ralph Malph wrote: > No one said that Peter. The termal characteristics limit the power that > can be used in a given chip. So if you are sizing the power supply, > then this is a realistic number to go by. If a user wants to put a > higher power design in the FPGA, then it might even be a good idea for > the power supply to limit the power at the package level. > > Keep in mind the purpose of the discussion, to size the power supply. Still, if you say: "The packages only tolerate a total power consumption of 20 W, so that will be my power supply", you either end up with an overly expensive power supply (in the 10-W case), or with a power supply that shuts down the devices, since they need 25 or 30 W (in the other case). You are not really any wiser. Maybe you are protected from burning up the chips, but that is all. PeterArticle: 64832
On Wed, 14 Jan 2004 18:50:37 GMT, "Jean Nicolle" <j.nicolle@sbcglobal.net> wrote: >Allan, did you get my email yesterday? I sent you a few screenshots. Oops, sorry, forgot to respond. >Anyway: >1. is fixed. > >2. and 3. >Looks like the way to meet the spec is to buy an isolation transformer and >follow the apps notes, a good source seems to be http://www.pulseeng.com/, >so it should be just a matter to buy these. Also try Prem, Pico, Midcom, Halo, Gowanda, etc. Note that these transformers will be designed to work with different PHYs, and each PHY will require a different turns ratio (which determines the impedance ratio, and is sometimes not 1:1) and can tolerate a different amount of leakage inductance. This means that pulling a transformer out of any old 10Base-T Ethernet card isn't guaranteed to give good results with your design. (Of course, you can get the part number of the PHY from the Ethernet card and look up its specs to find out what the transformer is like.) If your design already works with a direct connection to the cable, I suggest starting with a 1:1 transformer. >4., I did more experiments with a longer (30m) cable, and the results are >surprisingly good. Reflection from a terminated cable (connected to an >Ethernet switch) are low, even when driving directly from the FPGA. Putting >50ohms or 100ohms series resistors doesn't have much influence besides >attenuating the incident signal. >In all cases, I did not seem to experience any packet drops. Ummm, those reflections are a function of the terminating impedance (i.e. the Ethernet switch), so you'd expect them to be low. The comment in my earlier post about terminating impedance was to do with the input of your circuit, which affects the reflections of the signal coming from the other end. A resistor across RD-/RD+ should make this better. Regards, Allan.Article: 64833
Peter Alfke wrote: > > Ralph Malph wrote: > > No one said that Peter. The termal characteristics limit the power that > > can be used in a given chip. So if you are sizing the power supply, > > then this is a realistic number to go by. If a user wants to put a > > higher power design in the FPGA, then it might even be a good idea for > > the power supply to limit the power at the package level. > > > > Keep in mind the purpose of the discussion, to size the power supply. > > Still, if you say: > "The packages only tolerate a total power consumption of 20 W, so that > will be my power supply", > you either end up with an overly expensive power supply (in the 10-W case), > or with a power supply that shuts down the devices, since they need 25 > or 30 W (in the other case). > You are not really any wiser. Maybe you are protected from burning up > the chips, but that is all. That is one of the problems with Xilinx, they often seem to think that there is only one type of customer who picks an app and designs the FPGA like an ASIC. There are boards with FPGAs where you have no idea of what range of applications will ultimately be done in the device. Think reprogrammable! In those cases you can only design to the thermal limit of the package. No one is recommending that this is an optimal method of sizing a power supply. It would be foolish for anyone to think that sizing a supply this way was anything but a ceiling given no knowledge of the design. And as someone else pointed out, there may be applications which run in a pulsed mode where even this is not a ceiling. So it is always good to know as much as possible about your FPGA design. But you don't always know as much as you would like.Article: 64834
Hi Martin, > Does Altera have devices with I/O that can drive (or be driven) at 300 to > 400MHz? Internal logic would have to run at 1/2 that frequency. RLDRAM II > is the application. From our documentation, I see that Stratix devices can support up to 200 Mhz RLDRAM II using 1.8V HSTL signaling. RLDRAM runs at DDR, so that equates to 400 Mb/s per pin. I'm not sure if that answers your question -- I'd suggest contacting Altera (Altera Applications/Sales, that is...) to find out more. Regards, Paul Leventis AlteraArticle: 64835
RLDRAM II can (will) hit 400MHz (2.5ns cycle) actual clock rate. Of course, still DDR, so 800Mb/s/pin peak. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Paul Leventis (at home)" <paul.leventis@utoronto.ca> wrote in message news:4EmNb.28970$ZuL1.1332@twister01.bloor.is.net.cable.rogers.com... > Hi Martin, > > > Does Altera have devices with I/O that can drive (or be driven) at 300 to > > 400MHz? Internal logic would have to run at 1/2 that frequency. RLDRAM II > > is the application. > > From our documentation, I see that Stratix devices can support up to 200 Mhz > RLDRAM II using 1.8V HSTL signaling. RLDRAM runs at DDR, so that equates to > 400 Mb/s per pin. I'm not sure if that answers your question -- I'd suggest > contacting Altera (Altera Applications/Sales, that is...) to find out more. > > Regards, > > Paul Leventis > Altera > >Article: 64836
Barry wrote: > > I would like to try DCI with my Virtex II LVDS inputs with Vcco = 3.3V, and > have it work correctly. Can this be done? Or is there a typo in the User's > Guide. > The documentation is wrong; the V2 LVDS DCI input terminators only work at 2.5V, as they are implemented as a split termination between VCCO/GND on each side of the pair- the common mode LVDS offset voltage will be way off at VCCO=3.3V See Xilinx Answer Record 15633 ( but ignore the incorrect 62.5 mW number ) For a handy list of other LVDS_xx_DCI 'features' that await, see also: http://www.fpga-faq.com/archives/61300.html#61312 BrianArticle: 64837
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:r2nNb.1094$746.125@newssvr29.news.prodigy.com... > RLDRAM II can (will) hit 400MHz (2.5ns cycle) actual clock rate. Of course, > still DDR, so 800Mb/s/pin peak. > Martin - Virtex-II (and Pro) should be able to handle that. Xilinx's SPI-4.2 and HyperTransport cores run up to 400MHz DDR (800Mbps per pin). I assume RLDRAM has separate (uni-directional) read and write paths? I can't imagine anything running bi-directional at those rates. RobertArticle: 64838
Hi Srilekha, A deatiled SVF and XSVF file format is available on the xilinx website at the following link, http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf hope this helps RamArticle: 64839
Hi Ben Mine is nios v.3.10. that's what it says on the label on the board. another problem is I got this kit as a prize from altera session info and they only gave me the guard ID with no dongle. How can I actually get the license for quartus ii? do you know? since on the altera.com/licensing website, it needs NIC ID that was used to buy the kit. i won the kit, didn't buy it. any clue? thanks! > Jack wrote: > > > # [nios-gdb-server] accepting gdb connection > > # [nios-gdb-server] connecting to OCI, ocibase 0x00920800 > > # [nios-gdb-server] ...using byteblaster (altLPT1) > > # [nios-gdb-server] mdi error: found 0 devices instead of 1 > > # [nios-gdb-server] failed to connect > > Are you using the NIOS 3.0 or the NIOS 3.10 kit? I've seen this happen a lot > with the 3.0 kit, a lot less with the 3.10. Altera is a bit vague about the > reason though. > > Best regards, > > > BenArticle: 64840
Hi Edward. ModelSIm XE supports only 500 lines of code, so you need to get ModelSim SE/PE to run MicroBlaze simulation. bye RamArticle: 64841
Peter Alfke wrote: > That posting suggested to deduce the max operating power backwards from > the package thermal resistance. > Do NOT do that ! Well, I thought that was what thermal resistance was for, though it must be done right. You either need the thermal resistance junction to air, or you need to add a heat sink and include the thermal resistance to air for that heat sink. Then you need the maximum junction temperature and the maximum air temperature. Now, there is probably also an assumption that the heat generation is uniform across the chip, and if that isn't true you would have to correct for that. I believe what you are saying is, if you don't know what you are doing, don't do the calculation, and I agree with that... (snip) > Most FPGAs these days can be melted down by a crazy (but legitimate) > design running at an outrageous ( but legitimate) clock frequency. > It's up to the user to keep the junction temperature within spec. All we > manufacturers can do is give you the best analysis tools we can come up with... Has this changed over the years? I thought I asked it some years ago, and got the opposite answer. Well, it might have been for a more ordinary design, but at the highest clock rate that it could run at. OK, say for a synchronous design, all FF's have the same clock, and 2CLB delay plus routing for the critical path. Signals changing on the average every two clock cycles, and around 80% of CLB occupied. That is about what I had some years ago, and may be a reasonably typical design. -- glenArticle: 64842
Hello, I can download a program to memory using "nios-run my_prog.srec" and it works fine. However, when I write the program into the same memory manually (ie. memory fill command), nios will not wrong the program properly. I verified that both methods write exactly the same program bytes into memory, but nios-run does something with the memory AFTER the program end. This must be the source of my problems. Why are bytes changed after the end of the program? I verified every byte up until the last byte written as defined by the S-Record. Any ideas on what steps nios-run goes through? Help is greatly appreciated.Article: 64843
This is a question related to input pin on 1.8V Spartan IIE. Datasheets said it is "5V tolerant with external resistor." What should the value of this external resistor be? What value in the datasheet are you based on to calculate the necessary voltage drop on this resistor? I am mainly a firmware person, just start looking into FPGAs... Thanks!Article: 64844
Peter Alfke wrote: > This is why power calculation is such a chore. Agree. > On top of this, a 50% tolerance guess is no good. In my _all_ recent designs the ¨real¨ FPGA on the board consumes much less than calculated in advance. This means the on-board core voltage converters on are all oversized - often more than 200%. No big problem, but shows the difference between the design and reality. I think the problem is to estimate the real occupancy, the ¨average percent of Logic Cells toggling at each clock¨. This might strongly depend on the input data. > That's why I have recommended for years to "try it out". This means a prototype board with final FPGAs and realistic environment - realistic input data included. The funny side of the case is: when you finish to build and test a prototype before designing the production version, already new FPGAs are available. The new ones are cheaper and with HDL based design you can port your design easily. Just the power calculation and the prototype´s power measurement will not be applicable :-))) Janos EroArticle: 64845
dreamguy007@hotmail.com (Jack) writes: > altera.com/licensing website, it needs NIC ID that was used to buy the > kit. i won the kit, didn't buy it. any clue? It's the NIC ID of your license server host, or the host where you will run the software if you don't have a dedicated license server. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 64846
Hello all, I have a FSM with 6 states: IDLE, and S0-S5. Transitions are synchronized with the system clock, but next state might be determined by signals which are asynchronous to that clock. The FSM is normally at state IDLE. If certain signals are active, it will go from IDLE to S0, then go through some intermediate states, and finally back to IDLE. Here's a list of possible transitions: Current state Possible next states ------------- -------------------- IDLE IDLE, S0 S0 S1 S1 S2, IDLE S2 S3, IDLE S3 S4, IDLE S4 S4, S5, IDLE S5 IDLE I would like to use Gray encoding for this FSM but I'm not sure how it should be done. Using Gray encoding is straightforward for things like counters and such where there's only one possible next state for each current state. However, is it possible in a case like this? Thanks, Guillermo RodriguezArticle: 64847
Ralph Malph wrote: > Peter Alfke wrote: > >>That posting suggested to deduce the max operating power backwards from >>the package thermal resistance. >>Do NOT do that ! >>Package choice is dominated by cost and price consideration, both on the >>part of the chip manufacturer and on the part of the user. >>To make the assumption "because it comes in this high thermal resistance >>package, it will never dissipate more than x Watts" is, excuse the >>word, silly. >>Most FPGAs these days can be melted down by a crazy (but legitimate) >>design running at an outrageous ( but legitimate) clock frequency. >>It's up to the user to keep the junction temperature within spec. All we >>manufacturers can do is give you the best analysis tools we can come up with... >>Peter Alfke, Xilinx >>============================= >>Ralph Malph wrote: >> >>> But one way you can set a ceiling is to figure >>>out the maximum dissipation the package can provide and assume that can come from either of the two supplies. The may be very conservative, but >>>it will give you a *maximum*. > > > > No one said that Peter. The termal characteristics limit the power that > can be used in a given chip. So if you are sizing the power supply, > then this is a realistic number to go by. If a user wants to put a > higher power design in the FPGA, then it might even be a good idea for > the power supply to limit the power at the package level. > > Keep in mind the purpose of the discussion, to size the power supply. I can see that it has some validity to use the device Power MAX, but keep in mind that this is an AVERAGE value, and so can only give you the AVERAGE power value ( and thus is mainly usefull for thermal budgeting ). It is possible to have burst operations that have much higher peak currents, and the power supply should have the dynamic ability to deliver that, even tho the average and thermal budget is lower. There is also the FPGA startup, which can be an issue for power supply budgets. -jgArticle: 64848
guille wrote: > Hello all, > > I have a FSM with 6 states: IDLE, and S0-S5. Transitions are > synchronized with the system clock, but next state might be determined > by signals which are asynchronous to that clock. Sounds like thin ice. Can you not sync these to the opposite clock edge ? > > The FSM is normally at state IDLE. If certain signals are active, it > will go from IDLE to S0, then go through some intermediate states, and > finally back to IDLE. Here's a list of possible transitions: > > Current state Possible next states > ------------- -------------------- > IDLE IDLE, S0 > S0 S1 > S1 S2, IDLE > S2 S3, IDLE > S3 S4, IDLE > S4 S4, S5, IDLE > S5 IDLE > > I would like to use Gray encoding for this FSM but I'm not sure how it > should be done. Using Gray encoding is straightforward for things like > counters and such where there's only one possible next state for each > current state. However, is it possible in a case like this? A formal Gray code may be impossible, but you may be able to find a 'single bit change' pattern using pencil and paper. It can also help, if you allow IDLEa, IDLEb,(etc) for example - these are extra states added purely to ensure single-bit state jumps can be met. -jgArticle: 64849
Generating clock delays I am relatively new to VHDL so pleas excuse me if this is too easy a question. I need to be able to generate a time shifted version of the clk signal for control purposes in an Xilinx based project. There are several options that I have come across: -Using the after ??n, but this dose not seem to generate any difference -using the wait until statement though this is not supported by Xilinx for some reason -using the dll (is this the most efficient manor?) I would like someone to tell me which is the best and most controllable manor of generating a clock delay. Thanks
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