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
Hello, I posted this question a while back but I'm hearing the rumor again from people attending Altera's Quartus workshops. The rumor is that Altera may eventually phase out their support of AHDL in their Quartus development software. Does anyone know what's in the future for AHDL? Thanks, joeArticle: 103676
jjlindula@hotmail.com wrote: > Hello, I posted this question a while back but I'm hearing the rumor > again from people attending Altera's Quartus workshops. The rumor is > that Altera may eventually phase out their support of AHDL in their > Quartus development software. Does anyone know what's in the future for > AHDL? > > Thanks, > joe Hi Joe, AHDL support will be there in Quartus for a long long time.The AHDL language, is fully maintained and supported for reasons of backwards compatibility. There are lots of legacy Max+Plus II designs which customers are migrating to Quartus for use in both existing and new projects. We are sensitive to our customers needs and will not do anything to jeopardize their productivity. Hope this helps, Subroto Datta Altera Corp.Article: 103677
jjlindula@hotmail.com wrote: > Hello, I posted this question a while back but I'm hearing the rumor > again from people attending Altera's Quartus workshops. The rumor is > that Altera may eventually phase out their support of AHDL in their > Quartus development software. Does anyone know what's in the future for > AHDL? I can see that they would move AHDL to "maintenance mode", but I doubt they would kill it entirely. Altera took some trouble to keep the MAX +II interface option, and CPLDs must still be a sizeable chunk of their business. I liked what Xilinx did with ABEL : that now generates VHDL output (IIRC), and so can hook into all the back end tools, whilst at the same time, preserve customers code base. In this form, ABEL is a valid choice for new designs ( esp in the CPLD arena ). Altera could do the same, with their AHDL (or may have already). Someone at Altera may clarify this ? -jgArticle: 103678
jjlindula@hotmail.com wrote: > He asked if you > could do IC after the I/O pin symbols have been physically assigned > to pins? I'm not an expert on IC so I hope someone can help. Yes. Look at Design Partitioning... -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 103679
Dale wrote: > Hello, > > I'm trying to get my ILMB and DLMB of my microblaze to be 24kBytes, but > I am only given an option of powers of two. Is there any way around > this? > You can instantiate 16K and 8K BRAM blocks on the LMB, at contiguous addresses. However, I think that the data2mem tool (which stuffs ELFs into BRAM) will not recognise them as a contiguous memory space. This might introduce some complications for you, but shouldn't be a showstopper. Regards, JohnArticle: 103680
Andy wrote: > If you use "falling_edge(awe)" then awe will get tied to the clock > input on one or more registers that will hold the signal values that > you assign within that if-then clause. > > Storing data on falling edges of strobes will work, but think about > what you are going to do with that data in the latches. The timing can > be very difficult to manage if you need to use that data elsewhere in a > synchronous (clocked) system. Handling asynchronous buses in a > synchronous system is beyond the scope of this conversation. Whole > chapters/books have been written on it. Generally speaking, you usually > end up syncrhonizing the control lines, and using those synchronized > versions to control storage into synchronous registers (i.e. they form > clock enables on registers that are clocked by your system clock). If > your clock is not fast enough to handle the timing of the controls, > then you may need to latch the data with the asynchronous strobe, then > use a synchronized version of the strobe to enable transfer from the > latch into a register on the system clock. > Andy., got to know many things from you. I havenot worked too much on handling asynchronous events., i think its probably very challenging and i guess one should be fully equipped with the basics involved. If you could suggest any book/links which might be very helpful to go further in to the above discussed topics, it would be really appreciated. Thanks in advance, SrikanthArticle: 103681
Hi, I have a query regaring RAM usage in FPGA. Please help me in understanding it. Whats the thumb rule for choosing Block ram vs distributed Ram? When, which should be preffered? Why? Thanks AshishArticle: 103682
On Thu, 08 Jun 2006 12:13:28 +1000, John Williams <jwilliams@itee.uq.edu.au> wrote: >Dale wrote: > >> Hello, >> >> I'm trying to get my ILMB and DLMB of my microblaze to be 24kBytes, but >> I am only given an option of powers of two. Is there any way around >> this? >> > >You can instantiate 16K and 8K BRAM blocks on the LMB, at contiguous addresses. > However, I think that the data2mem tool (which stuffs ELFs into BRAM) will not >recognise them as a contiguous memory space. This might introduce some >complications for you, but shouldn't be a showstopper. > I did it on EDK 6.1 and 7.1, without problems. Don't know about EDK 8.1, but I have the feeling that it will work right away Regards, ZaraArticle: 103683
On 7 Jun 2006 21:41:19 -0700, "Ashish" <ashish.shringarpure@gmail.com> wrote: >Hi, > >I have a query regaring RAM usage in FPGA. Please help me in >understanding it. > >Whats the thumb rule for choosing Block ram vs distributed Ram? > >When, which should be preffered? Why? > > - If it should be dual ported with different clocks per port, use block ram - If it is large (more then 1kbit, use block ram) - If you are have unused block ram, use it ... Use distributed ram only when you can't use block ram Zara BTW, these are guidelines. As every guide line, it may be followed. Or not. It is your personal option, and you may behave differently if such things as timing, clock distrbuiton... indicates you should.Article: 103684
With each Virtex FPGA you get a certain number of BlockRAMs. Until you have used all of them, they are incrementally free, so use them, even if it may look wasteful (18 K or 36 K bit capacity). Nice features like progrmmable width/depth ratio, dual-ported, read-befor-write option, etc You can even do one read-modify-write operation per clock cycle (using both ports) One caveat: Reading is a synchronous operation, it only occurs after a clock edge. Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and is faster, but requires more design effort. Peter Alfke, Xilinx ApplicationsArticle: 103685
Peter Alfke wrote: > With each Virtex FPGA you get a certain number of BlockRAMs. Until you > have used all of them, they are incrementally free, so use them, even > if it may look wasteful (18 K or 36 K bit capacity). > > Nice features like progrmmable width/depth ratio, dual-ported, > read-befor-write option, etc > You can even do one read-modify-write operation per clock cycle (using > both ports) > > One caveat: Reading is a synchronous operation, it only occurs after a > clock edge. > > Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and > is faster, but requires more design effort. > This is my main query. How does speed matter here? What is thumb rule from operation speed point of view? I have some logic which uses counters, some configuration registers and FIFO. Fortunately same clock is used for all. What will be best choice for implementing these? BRAM and distributed RAM? Pls. advice. I am using Spartan2 device. > Peter Alfke, Xilinx Applications Thanks AshishArticle: 103686
>I am very suspicious of any claims of self-contained internal precision >ocillators, although such claims have been made. (Precision defined as >1 or 2%) Microchip/PIC says they get 1% at typical conditions and 2% over reasonable VCC and temp. (5% for wider VCC/Temp.) That needs a calibration step specific to each chip. A magic number is stored in flash. You have to copy it over to a speed-tweak register as part of initialization. The factory initializes the flash location and/or you can rederive it with their tools. That's from the data sheet for the PIC-12F675 which is several years old. I haven't checked their more recent chips. (Or newer versions of that data sheet.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 103687
Peter Alfke wrote: > Uwe, wishful thinking. > The frequency must be brought in from the outside. > I am very suspicious of any claims of self-contained internal precision > ocillators, although such claims have been made. (Precision defined as > 1 or 2%) These things do keep getting better and better, but they are not simple, or trivial blocks. Maxim and Linear tech have 'Silicon Oscillators', that claim these precisions, but in these devices all they have to do is oscillate, so they can target a process very specifically. A very recent, and perhaps better example, is the Freescale MC9RS08KA2 tiny microcontroller. That is true mixed signal. That claims 2% MAX, over voltage and temperature,(which I think means -40'C to 85'C and 1.8V-5.5V), and it has a 0.2% trim precision. This costs ~140uA, for 32Khz, but they also have a 300nA/1KHz oscillator, with reduced precision ~30%. They also have a 1% 1.2V bandgap reference in this device - AND it all costs under 50c !!. All of this will be something of a culture shock to FPGA vendors :) [ uA ?! cough, what's a nA ? 50 _cents_ ?! , choke... ] -jgArticle: 103688
>From my experiance there will be large routing delay if you use block RAMs and that will be very difficult to avoid if your block RAM usage is in a scattered manner. I tried to implement a 16 port RAM design suggested early in this group but with lot of effort could get only 10ns delay. Sumesh V SArticle: 103689
www.fpgaarcade.com With a bit of help from Paul Walsh, Invaders now has audio. I have targeted it at the Spartan3E starter board from Xilinx and tarted it up a bit with a colour overlay emulator. Enjoy, Cheers, MikeJArticle: 103690
MikeJ <mikej@fpgaarcade.nospam.com> wrote: >www.fpgaarcade.com >With a bit of help from Paul Walsh, Invaders now has audio. >I have targeted it at the Spartan3E starter board from Xilinx and tarted it >up a bit with a colour overlay emulator. Now we are waiting for the fpga demoscene ;)Article: 103691
On Wed, 07 Jun 2006 22:38:31 -0700, Peter Alfke wrote: > With each Virtex FPGA you get a certain number of BlockRAMs. Until you > have used all of them, they are incrementally free, so use them, even > if it may look wasteful (18 K or 36 K bit capacity). > > Nice features like progrmmable width/depth ratio, dual-ported, > read-befor-write option, etc > You can even do one read-modify-write operation per clock cycle (using > both ports) > > One caveat: Reading is a synchronous operation, it only occurs after a > clock edge. > > Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and > is faster, but requires more design effort. > > Peter Alfke, Xilinx Applications The big advantage of distributed RAM is that it's everywhere on the chip which means that PAR can put it near the logic that it's driving. Routing delays are the dominant factor in determining the overall performance of a design. When I look at the worst case paths in .twr reports I generally see that 75% of the delay is due to interconnect so anything that can be done to simplify PARs placement job is helpful. Sixteen word FIFOs are deep enough for many applications, for example I generally use them to couple different stages of my pipelines together. The other advantage of distributed RAM is lower latency. The read port on distributed RAM is asynchronous which saves a minimum of one clock cycle. In high speed designs it's frequently necessary to double pipeline the output of a Block RAM, i.e use the output register that's included V4 Block RAM plus an additional dflop register to handle the interconnect delay, so the difference between distributed RAM and Block ram can be as much as three cycles (although I would generally pipeline the output of the distributed RAM in those applications also so the difference is two cycles). In my experience it always been pretty obvious which type of memory to use. Either you need a lot, in which case you use Block RAM, or you need a little in which case you use distributed RAM. I've never run into a situation where I needed something intermediate, either 16 or rarely 32 words is enough or I need 1K or more.Article: 103692
Jacek Wawrzaszek =E5=86=99=E9=81=93=EF=BC=9A > <boxi.yang@gmail.com> wrote: > > it would be use on academic research only). Would you please tell me > > where can I get a copy of the API or tell me the email address of > > Delon Levi? Eager for your help, thank you > > > > Heve you tried Delon (dot) Levi (at) xilinx (dot) com ? >=20 > J. Thank you for your reply.Yes I did try but did not get replyArticle: 103693
Hi Joe, You can certainly use Quartus II Incremental Compilation after assigning the pins in your design to physical locations on the device. Incremental compilation should help your co-worker preserve the unchanged parts of his design, including the pin locations, as he adds updated modules. He should also save compilation time during this process as well. For more information on Quartus II Incremental Compilation you can visit the following links: Quartus II Incremental Compilation Website (Provides an overview of the feature and links to more information): http://www.altera.com/products/software/products/quartus2/design/qts-incremental.html Quartus II Handbook Volume 1, Chapter 1 (Provides a thorough description of the feature and how to use it): http://www.altera.com/literature/hb/qts/qts_qii51015.pdf Hopefully this provides all the information your co-worker needs to use incremental compilation for his design, good luck! Regards, Shawn Malhotra Altera Corp. jjlindula@hotmail.com wrote: > Hello, my co-worker has a very large Altera Quartus 5.1 design that > takes about 45 minutes to compile. The project has already had the pins > physically assigned and he is still adding things to the project such > as updated modules. I mentioned to him that trying Incremental > Compilation (IC) might decrease compilation time. He asked if you could > do IC after the I/O pin symbols have been physically assigned to pins? > I'm not an expert on IC so I hope someone can help. > > Thanks, > joeArticle: 103694
I think everybody asking for advice should always mention the intended clock rate. A 5 ns delay is horribly slow in some applications, but blindingly fast in others. Most experienced designers are accustomed to push the envelope, but many novices might operate below 50 MHz. My first question is always: How fast is your design? Peter Alfke, Xilinx ================= Josh Rosen wrote: > On Wed, 07 Jun 2006 22:38:31 -0700, Peter Alfke wrote: > > > With each Virtex FPGA you get a certain number of BlockRAMs. Until you > > have used all of them, they are incrementally free, so use them, even > > if it may look wasteful (18 K or 36 K bit capacity). > > > > Nice features like progrmmable width/depth ratio, dual-ported, > > read-befor-write option, etc > > You can even do one read-modify-write operation per clock cycle (using > > both ports) > > > > One caveat: Reading is a synchronous operation, it only occurs after a > > clock edge. > > > > Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and > > is faster, but requires more design effort. > > > > Peter Alfke, Xilinx Applications > > > The big advantage of distributed RAM is that it's everywhere on the chip > which means that PAR can put it near the logic that it's driving. > Routing delays are the dominant factor in determining the overall > performance of a design. When I look at the worst case paths in .twr > reports I generally see that 75% of the delay is due to interconnect so > anything that can be done to simplify PARs placement job is helpful. > Sixteen word FIFOs are deep enough for many applications, for example I > generally use them to couple different stages of my pipelines together. > The other advantage of distributed RAM is lower latency. The read port on > distributed RAM is asynchronous which saves a minimum of one clock cycle. > In high speed designs it's frequently necessary to double pipeline the > output of a Block RAM, i.e use the output register that's included V4 > Block RAM plus an additional dflop register to handle the interconnect > delay, so the difference between distributed RAM and Block ram can be as > much as three cycles (although I would generally pipeline the output of > the distributed RAM in those applications also so the difference is two > cycles). > > In my experience it always been pretty obvious which type of memory to > use. Either you need a lot, in which case you use Block RAM, or you need a > little in which case you use distributed RAM. I've never run into a > situation where I needed something intermediate, either 16 or rarely 32 > words is enough or I need 1K or more.Article: 103695
I find it interesting that Xilinx webpack has tools to convert AHDL to VHDL, but Altera does not! Of course, the copyright notice included in the generated code restricts its use to Xilinx products. Andy Jim Granville wrote: > jjlindula@hotmail.com wrote: > > > Hello, I posted this question a while back but I'm hearing the rumor > > again from people attending Altera's Quartus workshops. The rumor is > > that Altera may eventually phase out their support of AHDL in their > > Quartus development software. Does anyone know what's in the future for > > AHDL? > > I can see that they would move AHDL to "maintenance mode", but I doubt > they would kill it entirely. > > Altera took some trouble to keep the MAX +II interface option, and > CPLDs must still be a sizeable chunk of their business. > > I liked what Xilinx did with ABEL : that now generates VHDL output > (IIRC), and so can hook into all the back end tools, whilst at the > same time, preserve customers code base. > In this form, ABEL is a valid choice for new designs ( esp in the > CPLD arena ). > > Altera could do the same, with their AHDL (or may have already). > > Someone at Altera may clarify this ? > > -jgArticle: 103696
Andy wrote:
> I find it interesting that Xilinx webpack has tools to convert AHDL to
> VHDL, but Altera does not!
Yes. In fact Quartus synthesis still maps
a few VHDL code templates to
.tdf (AHDL) blocks.
Still some reptile brain inside :)
-- Mike Treseler
Article: 103697I'm looking for a stable, tested 6502 core does one exist? I'm looking for freebies or pay-to-gets RichArticle: 103698
Ryan Laity wrote: > Rickman, > > You don't have to install them using the web installer - that's why I > suggested that you check the "Install Later" box once the installer > downloads and you run it. That makes the Web Installer just act like a > download tool. You get installers that can easily be installed from a > CD at a later time (even by IT). > > I've also forwarded this request on the right person within Xilinx, > perhaps he will comment. I certainly don't think that the web installer > is the most intuitive way to download individual installers so I am > motivated to get this suggestion in the hands of someone who can do > something about it. Nonetheless, I've used this method for my customers > (I'm an FAE) to get a lab-only install of iMPACT standalone, so I've > been through it myself. > > Best regards, > Ryan Laity > > BTW - Rich, I don't like bottom posting, I think that top posting is > much easier for the flow of the thread (just start at the bottom and > work up). Well, I got over my frustration with this effort and gave the download a try with the "install later" option. It would not complete. When I ran the Webinstall software, it started with an error message, "System Administrator priviledges are needed to install this software." It ran anyway, but I kept getting error messages saying "The following error was encountered during installation:2:An error was detecgted in the archive.. Press retry to try again, otherwise press cancel to exit the installation." I tried both the "Connect directly to the Internet" and "Use Internet Explorer Proxy Settings" options and got the same error. Our system is expressly set up to not allow software installation without priviledges. I guess this is still an installation even though nothing is being installed. So this method will not work for everyone.Article: 103699
Andy wrote: > I find it interesting that Xilinx webpack has tools to convert AHDL to > VHDL, but Altera does not! Of course, the copyright notice included in > the generated code restricts its use to Xilinx products. Given Subroto's reply, why would Altera need to do this ? AHDL works fine, and is supported. Xilinx, on the other hand, have to oil the pathways for Altera users, so they have to offer something... -jg
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