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 all, I am a newbie in the FPGA stuff!.. I wanted to know some FPGA resource consumption by the microblaze but could not find some specific details such as how much BRAMS does it take (with minimal configuration) ?...I checked other documents but they had its architecture but not these resource consumption details!... Also, I installed ISE Design suite 13.2 Embedded Kit ( License type: Evaluation). And followed base system builder guidelines for spartan 6 board with microblaze (My OS is Win 7). But I could not create netlist and design summary.. Is this because of the evaluation license issue ? Also could anyone suggest a weblink or source where I can start learning from basics about the FPGA development toolkit ?... Thanks you, Hrishi --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152726
hrishi24h wrote: > Hello all, > > I am a newbie in the FPGA stuff!.. > > I wanted to know some FPGA resource consumption by the microblaze but could > not find some specific details such as how much BRAMS does it take (with > minimal configuration) ?...I checked other documents but they had its > architecture but not these resource consumption details!... BRAM for MicroBlaze depends to a large extent on how much instruction memory you assign during the BSB process. > > Also, I installed ISE Design suite 13.2 Embedded Kit ( License type: > Evaluation). And followed base system builder guidelines for spartan 6 > board with microblaze (My OS is Win 7). But I could not create netlist and > design summary.. Is this because of the evaluation license issue ? > In my experience evaluation licenses have done everything you can do with a full license, with the possible exception of creating a bitstream. So I don't think the netlist generation problem is from the license. On the other hand Windows 7 Professional is the only W7 officially supported for ISE. There may be some issues using WIndows 7 Home... > Also could anyone suggest a weblink or source where I can start learning > from basics about the FPGA development toolkit ?... > > > Thanks you, > Hrishi > > > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 152727
"hrishi24h" <hrishi24h@n_o_s_p_a_m.gmail.com> writes: > Hello all, > > I am a newbie in the FPGA stuff!.. > > I wanted to know some FPGA resource consumption by the microblaze but could > not find some specific details such as how much BRAMS does it take (with > minimal configuration) ?...I checked other documents but they had its > architecture but not these resource consumption details!... It depends on the cache size you choose. AFAIK the core CPU doesn't need any BRAMs at all. There's also the instruction/data memory that you may hang off the LMB, which also takes up BRAMs, but isn't technically part of microblaze. > > Also, I installed ISE Design suite 13.2 Embedded Kit ( License type: > Evaluation). And followed base system builder guidelines for spartan 6 > board with microblaze (My OS is Win 7). But I could not create netlist and > design summary.. Is this because of the evaluation license issue ? > I doubt it - evaluation license may stop you at the bsitstream phase, but not the netlisting. Post the error messages... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152728
Hello, all, I know this refers to graveyard parts, but we have reason to keep using them. Anyway, I made a new batch of motherboards that use a 5 V Spartan as the slot select control logic. I have made over 20 of these before. i did a revision of the design, but this particular area had no schematic change, and I really didn't move any traces, either. I do have a case for bus reflections, as the bus is 16 inches long. The FPGA detects unoccupied card slots and jumps serial config strings across the empty positions, and also has some serial config registers on the FPGA. Well, this newest version worked erratically, and after a couple days working with it, I figured out reflections on the serial clock that goes to all board slots plus the FPGA were double-clocking the FPGA. I patched a series termination resistor on the output of the driver, and the board now works perfectly. So, what caused this change? I'm fairly sure the board layout is not to blame. The older boards were made with 2003 Spartan XCS20-3PQ208C chips, the newer ones were made with 2009 vintage chips, otherwise the same designation, and just purchased a few weeks ago from Avnet. Could a more recent fab run at Xilinx have been made with significantly different speeds in the I/O? Of course, this COULD just be a circuit that was so close to the edge that I've just been really lucky, but I did make 20+ of these with no sign of this problem before. (This is a 6-layer board, always made at the same board house.) JonArticle: 152729
Jon Elson <elson@pico-systems.com> wrote: > Anyway, I made a new batch of motherboards that use a 5 V Spartan > as the slot select control logic. I have made over 20 of these > before. i did a revision of the design, but this particular area > had no schematic change, and I really didn't move any traces, > either. I do have a case for bus reflections, as the bus is > 16 inches long. (snip) > version worked erratically, and after a couple days working with > it, I figured out reflections on the serial clock that goes to all > board slots plus the FPGA were double-clocking the FPGA. I patched > a series termination resistor on the output of the driver, and > the board now works perfectly. I don't know any specifics about the chips, but certainly faster switching outputs could cause reflection problems. Series termination is often needed on lines much shorter than 16in. With a dielectric constant of about 2.5, that is in the 4ns to 5ns range, which is easily slow enough to double clock those. > So, what caused this change? I'm fairly sure the board layout is > not to blame. The older boards were made with 2003 Spartan > XCS20-3PQ208C chips, the newer ones were made with 2009 vintage > chips, otherwise the same designation, and just purchased a few > weeks ago from Avnet. -- glenArticle: 152730
On Oct 13, 5:26=A0pm, Jon Elson <el...@pico-systems.com> wrote: >=A0Could a more recent fab run at Xilinx > have been made with significantly different speeds in the I/O? It does not need to be 'significantly' in absolute terms, just enough to trigger the problem :) You can build a ring oscillator test cell, to check the raw MHz of the silicon, and see if that differs by much. I think Xilinx parts had a small hystereis, so maybe that varied ? 6 years is a reasonable time too, so the exact same fab line is unlikely to have been used. -jgArticle: 152731
>Hello, all, I know this refers to graveyard parts, but >we have reason to keep using them. > >Anyway, I made a new batch of motherboards that use a 5 V Spartan >as the slot select control logic. I have made over 20 of these >before. i did a revision of the design, but this particular area >had no schematic change, and I really didn't move any traces, >either. I do have a case for bus reflections, as the bus is >16 inches long. The FPGA detects unoccupied card slots and jumps >serial config strings across the empty positions, and also has >some serial config registers on the FPGA. Well, this newest >version worked erratically, and after a couple days working with >it, I figured out reflections on the serial clock that goes to all >board slots plus the FPGA were double-clocking the FPGA. I patched >a series termination resistor on the output of the driver, and >the board now works perfectly. > >So, what caused this change? I'm fairly sure the board layout is >not to blame. The older boards were made with 2003 Spartan >XCS20-3PQ208C chips, the newer ones were made with 2009 vintage >chips, otherwise the same designation, and just purchased a few >weeks ago from Avnet. Could a more recent fab run at Xilinx >have been made with significantly different speeds in the I/O? >Of course, this COULD just be a circuit that was so close to the >edge that I've just been really lucky, but I did make 20+ of these >with no sign of this problem before. > >(This is a 6-layer board, always made at the same board house.) > >Jon > Does the 'old' design with the 'new' chips fail? Does the 'new' design with the 'old' chips fail? Does the 'new' design use a newer version of ISE than before? Slight changes in logic can cause surprisingly large changes in placement and routing. Changes in ISE version can cause large changes in placement and routing. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152732
Jon Elson wrote: > Hello, all, I know this refers to graveyard parts, but > we have reason to keep using them. > > Anyway, I made a new batch of motherboards that use a 5 V Spartan > as the slot select control logic. I have made over 20 of these > before. i did a revision of the design, but this particular area > had no schematic change, and I really didn't move any traces, > either. I do have a case for bus reflections, as the bus is > 16 inches long. The FPGA detects unoccupied card slots and jumps > serial config strings across the empty positions, and also has > some serial config registers on the FPGA. Well, this newest > version worked erratically, and after a couple days working with > it, I figured out reflections on the serial clock that goes to all > board slots plus the FPGA were double-clocking the FPGA. I patched > a series termination resistor on the output of the driver, and > the board now works perfectly. > > So, what caused this change? I'm fairly sure the board layout is > not to blame. The older boards were made with 2003 Spartan > XCS20-3PQ208C chips, the newer ones were made with 2009 vintage > chips, otherwise the same designation, and just purchased a few > weeks ago from Avnet. Could a more recent fab run at Xilinx > have been made with significantly different speeds in the I/O? > Of course, this COULD just be a circuit that was so close to the > edge that I've just been really lucky, but I did make 20+ of these > with no sign of this problem before. > > (This is a 6-layer board, always made at the same board house.) > > Jon Over the years, without "changing" the process, the fab houses do a better job of producing parts that fall into the highest speed grade bin. In 2003 when you ordered a -3 part, it was therefore more probable that this part did not meet the -4 speedgrade than it is now with the 2009 parts. In other words, your 2009 "-3" chips were *tested* to the -3 speed grade requirements, but most probably *meet* the -4 speedgrade. Xilinx has commented on increased yields over the life of newer products, and I don't see why Spartan parts would be any different. -- GaborArticle: 152733
On 10/13/2011 07:11 AM, RCIngham wrote: > > Does the 'old' design with the 'new' chips fail? > Does the 'new' design with the 'old' chips fail? > Does the 'new' design use a newer version of ISE than before? > > Slight changes in logic can cause surprisingly large changes in placement > and routing. Changes in ISE version can cause large changes in placement > and routing. No, this is running the exact same EPROM image as all older revs. The only change is the mfg date of the FPGA and other chips on the board, and whatever changes might have occurred on the PCB layout and fabrication details of the PCB itself. The serial clock is generated by a 74HC14, and it is also possible that the output driver of this commodity part might be different than the ones used before. Thanks for all the interesting comments! This is now mostly an academic curiosity, as the board runs with this additional resistor. Almost certainly I SHOULD have been using such a scheme from the beginning on the several clock lines on the board. But, it worked without them....... JonArticle: 152734
Hi, The article describing my "Synthesizable heap-sorter for FPGA" (available at http://www.ise.pw.edu.pl/~wzab/fpga_heapsort) is just published and available at http://dx.doi.org/10.1117/12.905281 -- Regards, WojtekArticle: 152735
Could you describe this serial clock that goes to all boards in a bit more detail? Is it a single clock that is daisy-chained to all card slots? If so, you may still have a problem. The driver on a series- terminated net will send a half-height wave down the trace when it transitions, followed by a half-height reflection in the reverse direction. The upshot is that the signal at the very last load will look fine, because the return wave launches at the same time the incident wave arrives, producing a clean rising or falling edge. But all other loads along the line will see a half-height pedestal in the edge, with the pedestal becoming more pronounced as you get closer to the driver. If that pedestal happens to be in the transition region, the receiver could see a double (or triple, or whatever) clock. On the other hand, if you send a separate, series-terminated clock to each load, each clock should look fine at its destination (well, there are other considerations, but I'm going to conveniently ignore them for the moment). If this is a series-terminated, daisy-chained clock, take a look at the clock going into the FPGA with a high-bandwidth scope and probe, and see if there's a pedestal. If there is, there's more work to be done. Bob Perlman Cambrian Design Works On Oct 13, 3:48=A0pm, Jon Elson <jmel...@wustl.edu> wrote: > On 10/13/2011 07:11 AM, RCIngham wrote: > > > > > Does the 'old' design with the 'new' chips fail? > > Does the 'new' design with the 'old' chips fail? > > Does the 'new' design use a newer version of ISE than before? > > > Slight changes in logic can cause surprisingly large changes in placeme= nt > > and routing. Changes in ISE version can cause large changes in placemen= t > > and routing. > > No, this is running the exact same EPROM image as all older revs. =A0The > only change is the mfg date of the FPGA and other chips on the board, > and whatever changes might have occurred on the PCB layout and > fabrication details of the PCB itself. =A0The serial clock is generated b= y > a 74HC14, and it is also possible that the output driver of this > commodity part might be different than the ones used before. > > Thanks for all the interesting comments! =A0This is now mostly an academi= c > curiosity, as the board runs with this additional resistor. =A0Almost > certainly I SHOULD have been using such a scheme from the beginning on > the several clock lines on the board. =A0But, it worked without them.....= .. > > JonArticle: 152736
Bob Perlman <cambriandesign@gmail.com> wrote: (snip) > The driver on a series- > terminated net will send a half-height wave down the trace when it > transitions, followed by a half-height reflection in the reverse > direction. The upshot is that the signal at the very last load will > look fine, because the return wave launches at the same time the > incident wave arrives, producing a clean rising or falling edge. But > all other loads along the line will see a half-height pedestal in the > edge, with the pedestal becoming more pronounced as you get closer to > the driver. If that pedestal happens to be in the transition region, > the receiver could see a double (or triple, or whatever) clock. That is what is supposed to happen, but there are other possibilities. First, consider no termination. The reflection comes back at double height, hits the protection diode, and pulls Vcc up. That can't be good. That might be enough to mess up IOB flip-flops. Next, try a smaller than optimal impedance match resistor. The signal going out might be at 3/4 height, instead of 1/2, the reflection will then come back at 3/2, but goes through the resistor before hitting the protection diode. There will also be a negative reflaction back again, which should be about half the reflection coming in, which shouldn't bother things too much. Also, the resistor, into the transmission line load impedance, should round off the sharp edge a little bit, but not too much, reducing the effects of a too-fast transition. If the bus is TTL levels, then half of 5V, or even half of 4V will meet the Vhigh level. A small series termination resisitor is a lot better than none at all. -- glenArticle: 152737
Hi: While I'm very able to learn on my own, I feel that at my age and with so many people pulling at me every minute, that to assemble the hours of focussed attention to actually work through a significant amount of study material, these sorts of immersion courses are beneficial. Of course, that also assumes that my employer is willing to pay for it, which they are. If I had to pay, then the economics would be in favor of cracking a book and taking the fully DIY approach--which is basically how I've learned nearly everything I know about electronics to date. Of course, these sorts of courses require a lot of DIY follow-through to drive things home. In this case, since I have quite a bit of increasingly complicated (though still fairly simple by the standards of most experts) FPGA development to do over the next few years, there will be ample opportunity to exercise what I have learned. I think the point is, that there are a lot of practices that aren't obviated by simply reading a Verilog textbook. Even some of the "learn by example" books have some shoddy practices. Also, I suffer from "tool overwhelmitis" syndrome, where there are so many sub-tools in the vendor's development environment that I don't know what they are all for. Anyway, I am considering to take the "Comprehensive Verilog" and "Essentials and Design for Performance" classes by Doulos at Xilinx in Dec. Just wondering if people think these are worthwhile? Thanks for input. And output too. Just no high-z's! Good day! -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 152738
Greetings: They gave me a 6-mo eval license for those, which I will begin tinkering with in upcoming weeks. I have so far used only Icarus Verilog for sims, ever since Modelsim stopped being included with Xilinx tools. I know they have Isim now, or whatever the flavor of the month is, but I have yet to check it out or even determine if it's free in some capacity or not. But what attracted me to Synapticad's product was the prospect for much easier "graphical" waveform editing to compose test benches, which I suppose is among all of our least favorite things to do. Any thoughts on Synapticad for Verilog sim and testbench generation? Thanks for comments. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 152739
On Oct 15, 2:03=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > A small series termination resisitor is a lot better than > none at all. > > -- glen Sometimes. And clearly in this case it *is*better, because the new motherboards seem to work. But the question before us is whether this is a legitimate fix, i.e., one that will work for the next batch of boards, and the batches after that. Without probing at the signals to see what they look like, and perhaps simulating over the range of likely driver output impedances and risetimes, you can't say. But in general, using a series-terminated, daisy-chained net to drive multiple clock inputs is a bad idea, and is to be avoided. For those who want to learn more about this, here's a paper I wrote a while back: http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_p= aper.pdf Bob Perlman Cambrian Design WorksArticle: 152740
Bob Perlman wrote: > Could you describe this serial clock that goes to all boards in a bit > more detail? Is it a single clock that is daisy-chained to all card > slots? Yes, a horrible situation, a 16" long trace that is fed roughly from the middle, to all 16 board slots, with the FPGA in the middle. > If so, you may still have a problem. The driver on a series- > terminated net will send a half-height wave down the trace when it > transitions, followed by a half-height reflection in the reverse > direction. The upshot is that the signal at the very last load will > look fine, because the return wave launches at the same time the > incident wave arrives, producing a clean rising or falling edge. But > all other loads along the line will see a half-height pedestal in the > edge, with the pedestal becoming more pronounced as you get closer to > the driver. If that pedestal happens to be in the transition region, > the receiver could see a double (or triple, or whatever) clock. > Yup, I am not inexperienced in transmission line design. I tried a number of combinations of daughter boards, but obviously not a full combinatorial test. There was no sign of trouble in those test cases. Our control system runs test patterns on the serial config. register, and found no trouble. > On the other hand, if you send a separate, series-terminated clock to > each load, each clock should look fine at its destination (well, there > are other considerations, but I'm going to conveniently ignore them > for the moment). > This is already a 6-layer board filled with traces, so I don't think that is practical. > If this is a series-terminated, daisy-chained clock, take a look at > the clock going into the FPGA with a high-bandwidth scope and probe, > and see if there's a pedestal. If there is, there's more work to be > done. Yes, I ought to do some more testing to make sure this HACK is as robust as I hope it is. JonArticle: 152741
glen herrmannsfeldt wrote: > Also, the resistor, into the transmission line load impedance, > should round off the sharp edge a little bit, but not too much, > reducing the effects of a too-fast transition. > That is what I was hoping to do, round off the edge so that loads, and the board itself pretty much absorbs the reflection. > If the bus is TTL levels, then half of 5V, or even half of 4V > will meet the Vhigh level. Everything is CMOS, but may have "TTL" input thresholds. > A small series termination resisitor is a lot better than > none at all. Well, it SEEMS to have solved the problem. I will probably do some more testing to be sure it is solid. JonArticle: 152742
Bob Perlman wrote: > On Oct 15, 2:03 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> A small series termination resisitor is a lot better than >> none at all. >> >> -- glen > > Sometimes. And clearly in this case it *is*better, because the new > motherboards seem to work. But the question before us is whether this > is a legitimate fix, i.e., one that will work for the next batch of > boards, and the batches after that. Without probing at the signals to > see what they look like, and perhaps simulating over the range of > likely driver output impedances and risetimes, you can't say. But in > general, using a series-terminated, daisy-chained net to drive > multiple clock inputs is a bad idea, and is to be avoided. > > For those who want to learn more about this, here's a paper I wrote a > while back: > > http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_paper.pdf Thanks for the link. Well, in this system, the daughter boards have two chips made by MOSIS for us on the half um AMI process, now ON Semi. Not a really fast process, but the important stuff there is all analog, and the slower digital is fine. There are some Maxim serial-controlled MOS switches on the motherboard that have the slowest digital logic I've ever seen, dating back to the discrete transistor computer days. I had to slow the serial clock down to 1.2 us to get valid data to clock through these chips, almost twice as slow as their datasheet! So, the ONLY thing fast on this board seems to be the FPGA! That's why I got away with this design before. Having the FPGA in the center of the board may be the worst spot for reflections. JonArticle: 152743
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote: >Hi: > >While I'm very able to learn on my own, I feel that at my age and with >so many people pulling at me every minute, that to assemble the hours of > focussed attention to actually work through a significant amount of >study material, these sorts of immersion courses are beneficial. > >Of course, that also assumes that my employer is willing to pay for it, >which they are. If I had to pay, then the economics would be in favor >of cracking a book and taking the fully DIY approach--which is basically >how I've learned nearly everything I know about electronics to date. > >Of course, these sorts of courses require a lot of DIY follow-through to >drive things home. > >In this case, since I have quite a bit of increasingly complicated >(though still fairly simple by the standards of most experts) FPGA >development to do over the next few years, there will be ample >opportunity to exercise what I have learned. > >I think the point is, that there are a lot of practices that aren't >obviated by simply reading a Verilog textbook. Even some of the "learn >by example" books have some shoddy practices. Why Verilog? If you have a background in programming you might find VHDL easier to work with. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152744
>glen herrmannsfeldt wrote: >> Also, the resistor, into the transmission line load impedance, >> should round off the sharp edge a little bit, but not too much, >> reducing the effects of a too-fast transition. >> >That is what I was hoping to do, round off the edge so that loads, >and the board itself pretty much absorbs the reflection. > >> If the bus is TTL levels, then half of 5V, or even half of 4V >> will meet the Vhigh level. > >Everything is CMOS, but may have "TTL" input thresholds. >> A small series termination resisitor is a lot better than >> none at all. >Well, it SEEMS to have solved the problem. I will probably >do some more testing to be sure it is solid. > >Jon If available, I advise doing tests in a cold chamber, which should increase edge rates (reduce rise/fall time). It wasn't until we got to low temperature qualification tests that I discovered signal integrity issues relating to series termination on one of my designs... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152745
Nico Coesel wrote: > "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote: > >> Hi: >> >> While I'm very able to learn on my own, I feel that at my age and with >> so many people pulling at me every minute, that to assemble the hours of >> focussed attention to actually work through a significant amount of >> study material, these sorts of immersion courses are beneficial. >> >> Of course, that also assumes that my employer is willing to pay for it, >> which they are. If I had to pay, then the economics would be in favor >> of cracking a book and taking the fully DIY approach--which is basically >> how I've learned nearly everything I know about electronics to date. >> >> Of course, these sorts of courses require a lot of DIY follow-through to >> drive things home. >> >> In this case, since I have quite a bit of increasingly complicated >> (though still fairly simple by the standards of most experts) FPGA >> development to do over the next few years, there will be ample >> opportunity to exercise what I have learned. >> >> I think the point is, that there are a lot of practices that aren't >> obviated by simply reading a Verilog textbook. Even some of the "learn >> by example" books have some shoddy practices. > > Why Verilog? If you have a background in programming you might find > VHDL easier to work with. I thought very carefully about the decision to use Verilog years ago. My background is electronics, with a bunch of programming, mostly low-level to go along with it. But I have to do many things, and sometimes I will do a burst of logic/embedded work, then go align lasers for 6 months. What I come back to needs to be as simple as possible. Verilog is less verbose than VHDL. I consider VHDL to be the Java of HDLs. I don't need that. So far I have been happy with working with Verilog. It's fairly easy to understand. I'd just like an immersion type of experience right now to cover in a few short days all the details that I need to learn about, even if I don't necessarily commit them to memory in that short time, or fully get all their implications. Likewise with the toolset. Thanks for the comment. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 152746
Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote: (snip) > I thought very carefully about the decision to use Verilog years ago. > My background is electronics, with a bunch of programming, mostly > low-level to go along with it. > But I have to do many things, and sometimes I will do a burst of > logic/embedded work, then go align lasers for 6 months. What I come > back to needs to be as simple as possible. > Verilog is less verbose than VHDL. I consider VHDL to be the Java of > HDLs. I don't need that. I have worked with Java, and it isn't that wordy. Some have compared VHDL to ADA, though I haven't worked with ADA enough to know. I can usually read VHDL enough to figure out what it does, but won't claim to be able to write it. Some years ago, I was told that VHDL was more common for FPGA designs, and verilog for ASIC designs, but I believe even that isn't true by now. > So far I have been happy with working with Verilog. It's fairly > easy to understand. I'd just like an immersion type of experience > right now to cover in a few short days all the details that I need > to learn about, even if I don't necessarily commit them to memory > in that short time, or fully get all their implications. -- glenArticle: 152747
"Some have compared VHDL to ADA, though I haven't worked with ADA enough to know." Both were developed at the behest of the USA DoD, and a cursory examination of example code from each will draw you to the inevitable conclusion that VHDL's syntax was derived from that of Ada's. Which should not be a surprise... Note: 'Ada' is not an acronym, but 'VHDL' is. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152748
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote: > >(snip) > >> I thought very carefully about the decision to use Verilog years ago. >> My background is electronics, with a bunch of programming, mostly >> low-level to go along with it. > >> But I have to do many things, and sometimes I will do a burst of >> logic/embedded work, then go align lasers for 6 months. What I come >> back to needs to be as simple as possible. > >> Verilog is less verbose than VHDL. I consider VHDL to be the Java of >> HDLs. I don't need that. > >I have worked with Java, and it isn't that wordy. Some have >compared VHDL to ADA, though I haven't worked with ADA enough >to know. I can usually read VHDL enough to figure out what it >does, but won't claim to be able to write it. > >Some years ago, I was told that VHDL was more common for FPGA >designs, and verilog for ASIC designs, but I believe even that >isn't true by now. It depends on personal preference I guess. To me Verilog looks like a lot of gibberish so I use VHDL. What I also like about VHDL is its power. VHDL may be more verbose but once you treat it as a programming language a simple function can reduce the number of typing required considerably. A nice example is a priority encoder. If you search with Google for an example you'll see 9 out of 10 people write an equation for each output. Only one writes a function consisting of 3 lines which has the additional advantage of being generic. And don't get me started on designs which can be adjusted by means of few simple parameters... -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152749
Nico Coesel <nico@puntnl.niks> wrote: (snip, someone wrote) >>> Verilog is less verbose than VHDL. I consider VHDL to be >>> the Java of HDLs. I don't need that. >>I have worked with Java, and it isn't that wordy. Some have >>compared VHDL to ADA, though I haven't worked with ADA enough >>to know. I can usually read VHDL enough to figure out what it >>does, but won't claim to be able to write it. (snip) > It depends on personal preference I guess. To me Verilog looks like a > lot of gibberish so I use VHDL. What I also like about VHDL is its > power. VHDL may be more verbose but once you treat it as a programming > language a simple function can reduce the number of typing required > considerably. I mostly write structural verilog, with continuous assignment and module references. Behavioral (always blocks) mostly for registers and state machines. > A nice example is a priority encoder. If you search with Google for an > example you'll see 9 out of 10 people write an equation for each > output. Only one writes a function consisting of 3 lines which has the > additional advantage of being generic. You mean for each input? It seems, good or bad, that most synthesis tools do pretty well with the verbose form, though. Last time I wrote one, for 40 inputs, I did it nested, first writing the eight input encoder, then five of those, and the logic to put the result together. I believe it was pipelined, with a register between the two. > And don't get me started on designs which can be adjusted by means of > few simple parameters... -- glen
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