VHDL language of choice?
Folks,
I was talking to some electronics buffs on a chat channel, and they were telling me that only Universities and DOD uses VHDL. I thought it was hogwash, but wanted to find out if many commercial companies are using the language earnestly. The resident HDL expert was saying verilog is the language of choice these days. Is that true? I personally prefer VHDL because the I already have too many reference materials on how to use it. Thanks, -HT |
Re: VHDL language of choice?
verilog is widely prevalent in asic design world and is the language of
choice. But in FPGA design community both are widely used. |
Re: VHDL language of choice?
On 4 Apr 2005 00:14:45 -0700, "Neo" <[email protected]> wrote:
>verilog is widely prevalent in asic design world and is the language of >choice. But in FPGA design community both are widely used. It isn't that simple; there are many serious commercial ASIC/custom outfits that use VHDL. Sadly, though, it is true that VHDL simply doesn't seem to have the momentum that Verilog has. I know that Jim Lewis and all the great people involved in VHDL-200x are working hard to rectify that, but in the last analysis the only sensible approach for an individual engineer is: become bilingual in VHDL and Verilog. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:[email protected] Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. |
Re: VHDL language of choice?
Herb T wrote:
> Folks, > I was talking to some electronics buffs on a chat channel, and they > were telling me that only Universities and DOD uses VHDL. I thought it > was hogwash, but wanted to find out if many commercial companies are > using the language earnestly. The resident HDL expert was saying > verilog is the language of choice these days. Is that true? I > personally prefer VHDL because the I already have too many reference > materials on how to use it. I was somewhat surprised when I received Xilinx EDK, and all the cores included with it (numbering 50-75 I would say) were written in VHDL. I was even more surprised when I discovered that all the bit vectors were written as std_logic_vector(0 to n) (instead of downto)! |
Re: VHDL language of choice?
Herb T wrote:
> I was talking to some electronics buffs on a chat channel, and they > were telling me that only Universities and DOD uses VHDL. I thought it > was hogwash, but wanted to find out if many commercial companies are > using the language earnestly. The resident HDL expert was saying > verilog is the language of choice these days. Is that true? I > personally prefer VHDL because the I already have too many reference > materials on how to use it. Most of the american companies use Verilog while in Europe VHDL is common. I prefer VHDL, too, because * it is strongly typed and typing errors, that did not lead to syntax errors are detected more often * it avoids all these ugly cases mentioned in "verilog coding styles, that kill" (Clifford Cummings http://www.sunburst-design.com/paper...2000SJ_NBA.pdf ) * it protects better from writing to one signal from different processes * signed / unsigned arithmetics are defined more preceisely (with the disadvantage of having all these type conversions) * handling of multi-dimensional vectors is possible and handling of two-dimensional vectors is much easier * generic parameters and generate statements are easier to use than Verilog parameters and defines * finally: VHDL code it better human-readable - IMHO ;-) Ralf |
Re: VHDL language of choice?
Herb,
The statistics I heard was that in 2001 VHDL had 60% of the FPGA market. Verilog had 15% of the FPGA market and the remaining 25% went to other entry methods. Hence the early FPGA tool development and FPGA model development favored VHDL. With the a large portion of the market shifting from ASIC to FPGA I am sure the market share has changed, but that does not change the pre-existing intellectual property for FPGAs being developed in VHDL. The historic opposite happened with Verilog in the ASIC market. Verilog was first to have a gate level netlist, and hence, became a significant solution for the ASIC market. All marketing statistics I have seen where the Verilog crowd claims to have market share are based on EDA tool sales, where the ASIC tools cost >>> the FPGA tools, and hence, showed that more $$$ were spent on Verilog tools. This is a significant measure for EDA tool vendors as it indicates where there is money to be made. It was never a measure of users, although some would like to convince you it is. Because of this, many emphatically believe that Verilog has a significant lead in user adoption. It is the difference of looking at numbers rather than looking at data. There is an on-going revision of VHDL in progress. It is adding a number of significant features (such as uncostrained arrays of arrays - very useful in parameterized models), generics on packages, packages for fixed and floating point, integration of PSL, and language simplification (case and if statements). In the area of math, VHDL will have an advantage over Verilog/System Verilog as they don't have their own solution for these fixed and floating point. For more details see the papers page at: http://www.synthworks.com/papers In the next revision (immediately following this one) we will be adding enhanced verification features, similar to what System Verilog has done (such as constrained random). We will also be using the new features of the language (specifically generics on packages) to write packages that implement advanced verification data structures (such as queues, FIFOS, and memories). Best Regards, Jim Lewis -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ Jim Lewis Director of Training mailto:[email protected] SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ > Folks, > I was talking to some electronics buffs on a chat channel, and they > were telling me that only Universities and DOD uses VHDL. I thought it > was hogwash, but wanted to find out if many commercial companies are > using the language earnestly. The resident HDL expert was saying > verilog is the language of choice these days. Is that true? I > personally prefer VHDL because the I already have too many reference > materials on how to use it. > Thanks, > -HT > |
Re: VHDL language of choice?
In article <[email protected]>,
Jim Lewis <[email protected]> wrote: > >There is an on-going revision of VHDL in progress. It is >adding a number of significant features (such as uncostrained >arrays of arrays - very useful in parameterized models), >generics on packages, packages for fixed and floating >point, integration of PSL, and language simplification >(case and if statements). In the area of math, VHDL will >have an advantage over Verilog/System Verilog as they don't >have their own solution for these fixed and floating point. >For more details see the papers page at: >http://www.synthworks.com/papers > >In the next revision (immediately following this one) we will >be adding enhanced verification features, similar to what >System Verilog has done (such as constrained random). We will >also be using the new features of the language (specifically >generics on packages) to write packages that implement advanced >verification data structures (such as queues, FIFOS, and >memories). > Any changes planned for the scope of user defined attributes? As in will they be accessable outside of the package they're defined in? (not being able to do this now tends to make them not very useful). Allowing user defined attributes on types to be accessable outside of the package they're defined in, for example, would seem to move VHDL in a more OO direction (which should be a good thing :) As far as VHDL vs. Verilog popularity goes: comp.lang.vhdl seems to get consistently more traffic then comp.lang.verilog. Phil |
Re: VHDL language of choice?
Phil,
If you have a language issue that you think needs to be addressed, you can submit an enhancement request against it at: http://www.eda.org/vasg/bugrep.htm If you have trouble remembering this, there is a link to it at: http://www.eda.org/vhdl-200x/ Best Regards, Jim > In article <[email protected]>, > Jim Lewis <[email protected]> wrote: > >>There is an on-going revision of VHDL in progress. It is >>adding a number of significant features (such as uncostrained >>arrays of arrays - very useful in parameterized models), >>generics on packages, packages for fixed and floating >>point, integration of PSL, and language simplification >>(case and if statements). In the area of math, VHDL will >>have an advantage over Verilog/System Verilog as they don't >>have their own solution for these fixed and floating point. >>For more details see the papers page at: >>http://www.synthworks.com/papers >> >>In the next revision (immediately following this one) we will >>be adding enhanced verification features, similar to what >>System Verilog has done (such as constrained random). We will >>also be using the new features of the language (specifically >>generics on packages) to write packages that implement advanced >>verification data structures (such as queues, FIFOS, and >>memories). >> > > > Any changes planned for the scope of user defined attributes? As in will > they be accessable outside of the package they're defined in? (not being > able to do this now tends to make them not very useful). Allowing user > defined attributes on types to be accessable outside of the package > they're defined in, for example, would seem to move VHDL in a more OO > direction (which should be a good thing :) > > As far as VHDL vs. Verilog popularity goes: comp.lang.vhdl seems to get > consistently more traffic then comp.lang.verilog. > > Phil -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ Jim Lewis Director of Training mailto:[email protected] SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ |
Re: VHDL language of choice?
Herb T wrote:
> Folks, > I was talking to some electronics buffs on a chat channel, and they > were telling me that only Universities and DOD uses VHDL. I thought it > was hogwash, but wanted to find out if many commercial companies are > using the language earnestly. The resident HDL expert was saying > verilog is the language of choice these days. Is that true? I > personally prefer VHDL because the I already have too many reference > materials on how to use it. This is a myth prepuated by some people and companies that typically have a vested interest in Verilog or system Verilog. I have real data from Dataquest that says VHDL is about 50/50 with Verilog. Verilog has the advantage in ASIC space, and VHDL in FPGA space. Note that there are MANY more FPGAs being designed than ASICs, however ASICs are worth much more to the EDA companies than FPGAs are. |
Re: VHDL language of choice?
On Sat, 09 Apr 2005 15:33:53 GMT, David Bishop <[email protected]>
wrote: >Herb T wrote: > >> Folks, >> I was talking to some electronics buffs on a chat channel, and they >> were telling me that only Universities and DOD uses VHDL. I thought it >> was hogwash, but wanted to find out if many commercial companies are >> using the language earnestly. The resident HDL expert was saying >> verilog is the language of choice these days. Is that true? I >> personally prefer VHDL because the I already have too many reference >> materials on how to use it. > >This is a myth prepuated by some people and companies that typically >have a vested interest in Verilog or system Verilog. > >I have real data from Dataquest that says VHDL is about 50/50 with >Verilog. Verilog has the advantage in ASIC space, and VHDL in FPGA >space. Note that there are MANY more FPGAs being designed than ASICs, >however ASICs are worth much more to the EDA companies than FPGAs are. I have another piece of real data. If you go to dice and search for VHDL and Verilog keywords across US and In Bay Area/Silicon Valley Metro areas, you get almost even numbers in whole US and twice as many Verilog related jobs in the Bay Area.Monster gives similar results (320/304 for Verilog/VHDL) if you do a generic search and (140/80 in Northern California). This seems to correlate with your Dataquest data as Bay Area is heavily into ASICs and the distribution of FPGAs would be more even across US. |
Re: VHDL language of choice?
Jim Lewis wrote:
> If you have a language issue that you think needs to be > addressed, you can submit an enhancement request against > it at: > http://www.eda.org/vasg/bugrep.htm > > If you have trouble remembering this, there is a link to > it at: > http://www.eda.org/vhdl-200x/ -- Warning! Rant_Mode <= true The problem with this method is that there are some issues that the language controllers are simply not willing to address. Foremost among these, IMO, is the issue of a built-in pre-processor. Nearly every person I have encountered who is just learning VHDL, but has experience with another language, asks: Why is there no pre-processor/macro capability? From the very beginning (VHDL'87), it has been stated that the designers don't want a pre-processor but that if you really feel the need for one, there are many options available as stand-alone tools. While this is indeed true, use of a 3rd party pre-processor results in *non-standard* and *non-portable* code. There are also those who say that you don't need a pre-processor because there are other methods built into the language that do the same thing. This is true in many cases but use of these methods almost always results in far more complex (hard to maintain) code and/or an explosion in the number of lines of total code. Then there are the issues that, I believe (perhaps incorrectly), can't (or shouldn't) be addressed by any solution other than a pre-processor. One of the most common issues is having optional ports in an entity declaration. Finally, there is the whole issue of compiler directives. This has been "solved" by defining special "comments" that operate as directives. The logical place for these directives, IMO, is as pre-processor directives. Instead, we have what can only be described as a "hack"; these special comments. I wonder how many other people have had problems with inadvertent invocation of a directive because of an unfortunately-worded comment? The existence of a number of custom-designed pre-processors for VHDL is, to me, a clear indication that this is a feature that is really a language requirement. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com |
Re: VHDL language of choice?
Tim Hubberstey wrote:
> Foremost among these, IMO, is the issue of a built-in pre-processor. > Nearly every person I have encountered who is just learning VHDL, but > has experience with another language, asks: Why is there no > pre-processor/macro capability? Hi Tim, I came from a hardware background and found it odd when first maintaining a C program that I had to wade through a nest of #ifndefs and hack some #defines to get the options right. Maintaining the *almost* C-like macros can also be challenging for a bit bouncer. > Then there are the issues that, I believe (perhaps incorrectly), can't > (or shouldn't) be addressed by any solution other than a pre-processor. > One of the most common issues is having optional ports in an entity > declaration. If it's my code, I am inclined to just edit in the change and use version control to dig it up if I ever have to. If it's an untouchable entity, I can make a wrapper in about a minute. > Finally, there is the whole issue of compiler directives. I prefer to keep my code free of directives and make those settings in the back-end files. -- Mike Treseler |
Re: VHDL language of choice?
On Mon, 11 Apr 2005 16:50:17 -0700, Mike Treseler
<[email protected]> wrote: >Tim Hubberstey wrote: > >> Foremost among these, IMO, is the issue of a built-in pre-processor. >> Nearly every person I have encountered who is just learning VHDL, but >> has experience with another language, asks: Why is there no >> pre-processor/macro capability? > >Hi Tim, > >I came from a hardware background and found >it odd when first maintaining a C program that I had to >wade through a nest of #ifndefs and hack >some #defines to get the options right. >Maintaining the *almost* C-like macros >can also be challenging for a bit bouncer. I came to C from a more formal software background (ALGOL-W, then Modula-2 and a very clean OO language), and found much the same thing, plus the non-referentially-transparent nature of C style pre-processing makes it virtually unusable except for trivial hacks. Even then it leads to pretty unstable systems. Part of the problem is that it's untestable, or at least untested by any compiler system I know; only the processed code undergoes syntax checking (does anyone know of a pre-compiler that traverses every branch and reports on errors in the currently unreachable ones?), and that has several interesting ways of generating (or at the very least) obscuring errors. Some of its common uses are to overcome problems in C that shouldn't be there in the first place, and VHDL doesn't have anyway. Such as the lack of a proper import mechanism (package/library/use in VHDL; FROM ... IMPORT in Modula-2). I for one would be very unhappy about adding ways of introducing so many bugs into VHDL, and the only way to avoid it would be a much more rigorous and heavyweight approach than the C pre-processor. - Brian |
Re: VHDL language of choice?
Tim Hubberstey wrote:
> Foremost among these, IMO, is the issue of a built-in pre-processor. > Nearly every person I have encountered who is just learning VHDL, but > has experience with another language, asks: Why is there no > pre-processor/macro capability? > > From the very beginning (VHDL'87), it has been stated that the > designers don't want a pre-processor ... Do we need a preprocessor, if something like the generate statements would be extended to the signal declaration and to the entity? Such a solution would offer configuration using one idea - not two like the parameter and defines in Verilog. Ralf |
Re: VHDL language of choice?
> * finally: VHDL code it better human-readable - IMHO ;-)
I used to think that vhdl would be more readable than verilog, but I've seen too much vhdl code that looks like this: x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + to_integer(unsigned(z2))), 9)); y := std_logic_vector(to_unsigned((to_integer(unsigned( x(7 DOWNTO 0))) + to_integer(unsigned(x(8 DOWNTO 8)))), 8)); which I *think* is meant to do the same thing as this nice verilog code: x = z1 + z2; y = x[7:0] + x[8]; (Now try to imagine the above vhdl code with really long identifiers instead of the short identifiers that I used.) Some vhdl proponents believe that readability is synonymous with verbosity. Paul |
Re: VHDL language of choice?
Paul wrote:
>> * finally: VHDL code it better human-readable - IMHO ;-) > I used to think that vhdl would be more readable than verilog, but I've > seen too much vhdl code that looks like this: > > x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + > to_integer(unsigned(z2))), 9)); .... > which I *think* is meant to do the same thing as this nice verilog > code: > > x = z1 + z2; Yes - I agree, this is the point, where VHDL is not well readable, but remember two things: * It is well-defined if signed or unsigned arithmetics are used (as long as you use IEEE.Numeric_std.ALL). For addition you don't care about this, but for a comparison it is important. * How many of these constructs do you have in a typical design? O.k. - quite a lot if you do DSP arithmetics, but normally these things are rare. (I often try to re-use adders as they have a speed impact and are area-expensive. Therefore 5 such things in the whole design is a big number.) And finally: It is my personal opinion, that it is better readable. ;-) It started learing VHDL with only little knowledge about the C syntax. Now, as I have learned C, Verilog is much more readable, but still my opinion is the same. When I do Verilog I code it like VHDL and it looks much better than in examples. But again: IMHO! Ralf |
Re: VHDL language of choice?
Ralf Hildebrandt <[email protected]> writes:
> Paul wrote: > > >>> * finally: VHDL code it better human-readable - IMHO ;-) > >> I used to think that vhdl would be more readable than verilog, but I've >> seen too much vhdl code that looks like this: >> x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + >> to_integer(unsigned(z2))), 9)); > ... >> which I *think* is meant to do the same thing as this nice verilog >> code: >> x = z1 + z2; I guess we (at work) are not the only ones that have made a package with a bunch of typecasting functions to reduce this problem as much as possible. With our 'type_conv' package the above would look like: x := to_slv(to_uns(z1) + to_uns(z2), 9); Which is a reasonable compromise. But I concur with the general comment about VHDL's verbosity > And finally: It is my personal opinion, that it is better > readable. ;-) IMHO, it ain't. > It started learing VHDL with only little knowledge about the C > syntax. Now, as I have learned C, Verilog is much more readable, but > still my opinion is the same. When I do Verilog I code it like VHDL > and it looks much better than in examples. But again: IMHO! I learned C first, then Verilog, and then VHDL. I've learned to loathe all of them for their individual shortcomings. I think it was Dave Bishop who said, when asked about the difference between Verilog and VHDL: Verilog was designed by a bunch of hardware guys who didn't know a thing about designing software. We had to beat on it to make it work. VHDL was designed by a bunch of software guys who didn't know a thing about designing hardware. We had to beat on it to make it work. Kai -- Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk> |
Re: VHDL language of choice?
"Paul" <[email protected]> writes:
> > * finally: VHDL code it better human-readable - IMHO ;-) > > I used to think that vhdl would be more readable than verilog, but I've > seen too much vhdl code that looks like this: > > x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + > to_integer(unsigned(z2))), 9)); > y := std_logic_vector(to_unsigned((to_integer(unsigned( x(7 > DOWNTO 0))) + to_integer(unsigned(x(8 > DOWNTO 8)))), 8)); > I would argue that's just bad code - x and y should be unsigned in this case. It's not very often that you actually want to assign the result of an arithmetic operation to a boggo vector. One can write unreadble code in any language - and as someone else has pointed out, at least the operations in numeric_std are well-defined. Cheers, Martin -- [email protected] TRW Conekt, Solihull, UK http://www.trw.com/conekt |
Re: VHDL language of choice?
On 12 Apr 2005 10:47:26 -0700, "Paul" <[email protected]> wrote:
>> * finally: VHDL code it better human-readable - IMHO ;-) > >I used to think that vhdl would be more readable than verilog, but I've >seen too much vhdl code that looks like this: > > x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + >to_integer(unsigned(z2))), 9)); > y := std_logic_vector(to_unsigned((to_integer(unsigned( x(7 >DOWNTO 0))) + to_integer(unsigned(x(8 >DOWNTO 8)))), 8)); > >which I *think* is meant to do the same thing as this nice verilog >code: USUALLY that's a warning that you (or the code's writer) hasn't thought through the design properly. If he had defined x and y as type unsigned, he could have written something like > x = z1 + z2; x := z1 + z2; -- clear enough? > y = x[7:0] + x[8]; // Was the length mismatch deliberate or is it cover for an obscure bug? // How do unequal-length operands get handled? // Did it sign extend or zero fill the shorter one? // If it extends the shorter operand, can I trust it to flag length // mismatches between the expression and the assignment variable? y := x(7 downto 0) + "0000000"&x(8); -- Clear and precise. -- Yes there are better ways to extend the shorter operand. -- Doesn't necessarily do the same as the Verilog code because -- there are a lot of assumptions in the translation... The VHDL version has the advantage over the Verilog code that the operand length mismatch was obviously deliberate and handled in a defined manner, and not an obscure bug waiting to happen. Now there are reasons for reverting to std_logic_vector at the physical ports of a chip, but the ":=" form of assignment tells me x and y are variables inside a process, so that can't matter here! Of course the above assumes he is using "numeric_std" and not the non-standard "std_logic_arith" library, whouch would IMO be another warning of a poorly thought out design. >Some vhdl proponents believe that readability is synonymous with >verbosity. And some don't. But this VHDL proponent believes that the precision is worth _some_ excessive verbosity, to ensure that the code actually does what it says it does. - Brian |
Re: VHDL language of choice?
Brian Drummond wrote:
> If he had defined x and y as type unsigned, he could have written > something like > x := z1 + z2; > y := x(7 downto 0) + "0000000"&x(8); > Now there are reasons for reverting to std_logic_vector at the physical > ports of a chip, but the ":=" form of assignment tells me x and y are > variables inside a process, so that can't matter here! Well said. Thanks for the posting. Conversion between std_logic_vector and unsigned is a simple cast on the edge assignments. Most designs have 10 times more process register bits than pins on the device. -- Mike Treseler |
Re: VHDL language of choice?
Mike Treseler wrote:
> Tim Hubberstey wrote: > >> Foremost among these, IMO, is the issue of a built-in pre-processor. >> Nearly every person I have encountered who is just learning VHDL, but >> has experience with another language, asks: Why is there no >> pre-processor/macro capability? > > Hi Tim, > > I came from a hardware background and found > it odd when first maintaining a C program that I had to > wade through a nest of #ifndefs and hack > some #defines to get the options right. > Maintaining the *almost* C-like macros > can also be challenging for a bit bouncer. Unfortunately, any language feature can be abused. I also come from a hardware background so I understand what you mean. However, a lot of the pre-processor complexity you see in C code often comes from people writing code that will work on many different platforms and operating systems. >> Then there are the issues that, I believe (perhaps incorrectly), can't >> (or shouldn't) be addressed by any solution other than a >> pre-processor. One of the most common issues is having optional ports >> in an entity declaration. > > If it's my code, I am inclined to just edit in the change > and use version control to dig it up if I ever have to. > If it's an untouchable entity, I can make a wrapper > in about a minute. That's fine, as long as you're the only person dealing with the code. I try to write code that is, as much as possible, reusable and parameterizable. This often results in situations where you want to vary the port list to include/exclude control signals. There are ways you can do this that stay within the existing VHDL definition, but these methods often result in compiler and/or synthesis warnings that add confusion to the log files. Using a pre-processor, IMO, produces much cleaner results for the *user* of an IP block even though the code inside the block may be a little harder to understand. >> Finally, there is the whole issue of compiler directives. > > I prefer to keep my code free of directives and > make those settings in the back-end files. This is, mostly, a style issue so I won't disagree with your choice. However, there are some pragmas that *must* be inside the code because the tool the pragma is for doesn't have any back-end files. Some code coverage and formal verification tools come to mind here. Even if you don't choose to intentionally use pragmas in your code, it can still happen by accident. For instance, I once wasted an entire day's synthesis run because I reformatted a comment block and inadvertently ended up with a comment line that started out: -- Synopsys ... This caused the synthesis of the block to fail which, since it was a block instantiated by many other blocks, caused the entire 18-hour synthesis run to fail. Even worse is the case where you accidentally generate a valid pragma that causes some subtle error in your result. My point is that, whether you choose to use them or not, pragmas have no business looking like comments. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com |
Re: VHDL language of choice?
Ralf Hildebrandt wrote:
> Tim Hubberstey wrote: > >> Foremost among these, IMO, is the issue of a built-in pre-processor. >> Nearly every person I have encountered who is just learning VHDL, but >> has experience with another language, asks: Why is there no >> pre-processor/macro capability? >> >> From the very beginning (VHDL'87), it has been stated that the >> designers don't want a pre-processor ... > > Do we need a preprocessor, if something like the generate statements > would be extended to the signal declaration and to the entity? Such a > solution would offer configuration using one idea - not two like the > parameter and defines in Verilog. Possibly not for pre-processing, as long as the pragma issue is addressed somehow. However, I would still like to see a macro capability. Generates are powerful and can do many things, but sometimes they either just aren't enough (lack of an "else" clause is a big failing), or are way too complex. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com |
Re: VHDL language of choice?
Tim Hubberstey wrote:
> However, there are some pragmas that *must* be inside the code because > the tool the pragma is for doesn't have any back-end files. Some code > coverage and formal verification tools come to mind here. Thanks for the tip. I will remind myself not to bother evaluating such tools. Modelsim seems to do ok on code coverage without resorting to such hacks. > -- Synopsys ... > This caused the synthesis of the block to fail which, since it was a > block instantiated by many other blocks, caused the entire 18-hour > synthesis run to fail. Serious bummer. I'll resolve to keep vendor names and keywords like "translate" out of my comments. > My point is that, whether > you choose to use them or not, pragmas have no business looking like > comments. I agree that comments ought to be ignored by all tools. Some of the vendors use vhdl attributes to do this sort of thing. At least that eliminates the possible side effects of putting vendor settings in source code. -- Mike Treseler |
Re: VHDL language of choice?
Paul wrote:
>> * finally: VHDL code it better human-readable - IMHO ;-) > > > I used to think that vhdl would be more readable than verilog, but I've > seen too much vhdl code that looks like this: > > x := std_logic_vector(to_unsigned((to_integer(unsigned( z1)) + > to_integer(unsigned(z2))), 9)); > y := std_logic_vector(to_unsigned((to_integer(unsigned( x(7 > DOWNTO 0))) + to_integer(unsigned(x(8 > DOWNTO 8)))), 8)); This really an issue with the standard packages and not the language itself (a hairline distinction). Many people create their own packages that crunch this kind of thing down to something reasonable. For instance, I use a function, AddSLV(vec_1, vec_2, mode), that takes 2 standard_logic_vectors and "adds" them. The "add" function can be signed or unsigned 2's complement, Gray, etc. as defined by the mode value. > which I *think* is meant to do the same thing as this nice verilog > code: > > x = z1 + z2; > y = x[7:0] + x[8]; You could write the exact equivalent in VHDL by using the unsigned package instead of the numeric_bit package: x <= z1 + z2; y <= x(7 downto 0) + x(8); ^-- not sure about this since I don't use the unsigned package. Might need to re-size it. > (Now try to imagine the above vhdl code with really long identifiers > instead of the short identifiers that I used.) > > Some vhdl proponents believe that readability is synonymous with > verbosity. No argument there. I much prefer the [x:y] notation to (x downto y). It's also a safe bet that something that basic is never going to change. However, your example isn't really about readability -- it's about strong (VHDL) vs weak (Verilog) typing. Some people like a strongly-typed language because of the implicit error checking, others hate it because the typing "keeps me from doing what I want". It's a philosophical difference that goes much deeper than just syntax and is probably just as religious as Mac vs PC or Linux vs Windows. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com |
Re: VHDL language of choice?
Tim Hubberstey wrote:
> Jim Lewis wrote: > >> If you have a language issue that you think needs to be >> addressed, you can submit an enhancement request against >> it at: >> http://www.eda.org/vasg/bugrep.htm >> >> If you have trouble remembering this, there is a link to >> it at: >> http://www.eda.org/vhdl-200x/ > > > -- Warning! Rant_Mode <= true > > The problem with this method is that there are some issues that the > language controllers are simply not willing to address. I think for future revisions of VHDL all user requests need to be on the table. To get a good solution, we need to get many perspectives. One of the challenges is to translate from a request that suggests an implementation to the underlying requirement - because there may be a better way of addressing the requirement that is already being proposed. The original language designers have blessed us with a clean, consistent language. As we move forward, those of us who decide to answer the call and step into this role, need to work hard to keep the language clean and consistent. Don't get discouraged because something was rejected in the past, however, do keep in mind the rule about standards: With standards you don't necessarily get what you want, but you usually will get something you can live with. Just so you understand the process we are currently are using (and may become the model for future revisions): things that are high value and someone is interested in working on will get worked on. Keep in mind that they will have to be traded off between other potential candidate solutions. So far this seems to have been working well. If you don't have alot of time, working on just one proposal that has high value to you is great. If you don't feel up to working on language proposals, even being aware of what we are doing and telling your vendors which proposals are of high value to you will ensure that your vendors take note and start consider how they are going to implement the features. Beyond language proposals, if you look at the big differences between the capability of "C" and VHDL, you will note that it is not in the langauge capability, but the fact that C has an extensive number of libraries. VHDL has some ground to cover with respect to implementing packages. Again, if you don't feel up to writing these sort of things, we will need people who try them out. Make sure the use model is ok. Test them and find bugs. There is plenty to do. As we finish the fast track phase and move to the next phase, we are going to need to do more planning. Once that planning is complete, we will be able to be more specific about what needs to be done. Beyond this, while most WG activities are done on a voluntary basis, LRM editing is a paid position and we need between $100K and $150K to finish fast track edits. If you know of an organization who is willing to help us reach our goal, please let myself or Steve Bailey (VASG Chair) know. Please note that neither IEEE dues nor IEEE-SA dues nor donations to IEEE-SA go to fund IEEE standards working groups. Only donated directly to the working group funding organization goes to the working group. Best Regards, Jim Lewis VASG Vice Chair VHDL-200X Fast Track Co-Team lead -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ Jim Lewis Director of Training mailto:[email protected] SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~ |
All times are GMT +1. The time now is 12:11 PM. |
Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved