VHDL language of choice?

Discussion in 'VHDL' started by Herb T, Apr 4, 2005.

  1. Herb T

    Herb T Guest

    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
    Herb T, Apr 4, 2005
    #1
    1. Advertising

  2. Herb T

    Neo Guest

    verilog is widely prevalent in asic design world and is the language of
    choice. But in FPGA design community both are widely used.
    Neo, Apr 4, 2005
    #2
    1. Advertising

  3. On 4 Apr 2005 00:14:45 -0700, "Neo" <> 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:
    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.
    Jonathan Bromley, Apr 4, 2005
    #3
  4. Herb T

    Duane Clark Guest

    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)!
    Duane Clark, Apr 4, 2005
    #4
  5. 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/papers/CummingsSNUG2000SJ_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
    Ralf Hildebrandt, Apr 4, 2005
    #5
  6. Herb T

    Jim Lewis Guest

    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:
    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
    >
    Jim Lewis, Apr 5, 2005
    #6
  7. Herb T

    Phil Tomson Guest

    In article <>,
    Jim Lewis <> 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
    Phil Tomson, Apr 7, 2005
    #7
  8. Herb T

    Jim Lewis Guest

    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 <>,
    > Jim Lewis <> 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:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis, Apr 8, 2005
    #8
  9. Herb T

    David Bishop Guest

    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.
    David Bishop, Apr 9, 2005
    #9
  10. Herb T

    mk Guest

    On Sat, 09 Apr 2005 15:33:53 GMT, David Bishop <>
    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.
    mk, Apr 9, 2005
    #10
  11. 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
    Tim Hubberstey, Apr 11, 2005
    #11
  12. 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
    Mike Treseler, Apr 12, 2005
    #12
  13. On Mon, 11 Apr 2005 16:50:17 -0700, 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.


    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
    Brian Drummond, Apr 12, 2005
    #13
  14. 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
    Ralf Hildebrandt, Apr 12, 2005
    #14
  15. Herb T

    Paul Guest

    > * 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
    Paul, Apr 12, 2005
    #15
  16. 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
    Ralf Hildebrandt, Apr 12, 2005
    #16
  17. Ralf Hildebrandt <> 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>
    Kai Harrekilde-Petersen, Apr 12, 2005
    #17
  18. "Paul" <> 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


    --

    TRW Conekt, Solihull, UK
    http://www.trw.com/conekt
    Martin Thompson, Apr 13, 2005
    #18
  19. On 12 Apr 2005 10:47:26 -0700, "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));
    >
    >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
    Brian Drummond, Apr 13, 2005
    #19
  20. 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
    Mike Treseler, Apr 13, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green
    Replies:
    1
    Views:
    326
    Tommy McDaniel
    Jul 24, 2003
  2. Mickey Segal
    Replies:
    0
    Views:
    874
    Mickey Segal
    Feb 2, 2004
  3. Roedy Green
    Replies:
    1
    Views:
    306
    Tommy McDaniel
    Jul 24, 2003
  4. afd
    Replies:
    1
    Views:
    8,329
    Colin Paul Gloster
    Mar 23, 2007
  5. miles.jg
    Replies:
    16
    Views:
    871
    Alf P. Steinbach
    Nov 14, 2007
Loading...

Share This Page