SystemVerilog for verification

Discussion in 'VHDL' started by Rob Gaddi, Nov 15, 2011.

  1. Rob Gaddi

    Rob Gaddi Guest

    Oh good, a topic to start a flame war with...

    So I consider myself pretty comfortable with VHDL. I use it for my
    synthesizable designs. I use it for my testbenches. Occasionally I'll
    write a VHDL behavioral model and run it through my simulator just to
    generate timing diagram waveforms for people.

    I can, given sufficient time and energy, muddle through reading Verilog.
    Never written a line of it. But I'm getting a vague sense, possibly
    out of frustration, that a whole lot of verification benches, especially
    as you're trying to get up into transaction level bus models, get easier
    in SystemVerilog than they are doing it in VHDL, even with the 2008
    improvements.

    I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    and the idea of calling bus_master.write(address, data); seems like a
    pretty natural way of stringing a bench together. The options for doing
    similar in VHDL (procedures with a billion signal parameters or entities
    with abstract req/ack ports and 'transaction signaling) seem,
    comparatively, pretty crude. I've made them work time and again, but I
    can't say I've ever sat back and read it back over and said "You know,
    that's pretty elegant."

    I have no intention of giving up VHDL for my synthesizables; I cling to
    strong typing like Linus to his blanket. But am I doing myself a
    disservice by not learning SV?

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
    Rob Gaddi, Nov 15, 2011
    #1
    1. Advertising

  2. On Nov 15, 9:28 am, Rob Gaddi <>
    wrote:
    > Oh good, a topic to start a flame war with...
    >
    > So I consider myself pretty comfortable with VHDL.  I use it for my
    > synthesizable designs.  I use it for my testbenches.  Occasionally I'll
    > write a VHDL behavioral model and run it through my simulator just to
    > generate timing diagram waveforms for people.
    >
    > I can, given sufficient time and energy, muddle through reading Verilog.
    >   Never written a line of it.  But I'm getting a vague sense, possibly
    > out of frustration, that a whole lot of verification benches, especially
    > as you're trying to get up into transaction level bus models, get easier
    > in SystemVerilog than they are doing it in VHDL, even with the 2008
    > improvements.
    >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together.  The options for doing
    > similar in VHDL (procedures with a billion signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude.  I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."
    >
    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket.  But am I doing myself a
    > disservice by not learning SV?
    >
    > --
    > Rob Gaddi, Highland Technology --www.highlandtechnology.com
    > Email address domain is currently out of order.  See above to fix.


    I use VHDL and Verilog in equal amounts. When asked which I prefer, I
    always say "the other one" - there's always something the other
    language does better.

    SystemVerilog has a lot of the features of VHDL that I miss when
    coding in Verilog - IMnsHO, enough that I think you should look at it.

    If only I could trust Brand-X to synthesize it properly - right now I
    use it for verification only.

    RK
    NeedCleverHandle, Nov 15, 2011
    #2
    1. Advertising

  3. On 11/15/2011 11:28 AM, Rob Gaddi wrote:
    > Oh good, a topic to start a flame war with...
    >
    > So I consider myself pretty comfortable with VHDL. I use it for my
    > synthesizable designs. I use it for my testbenches. Occasionally I'll
    > write a VHDL behavioral model and run it through my simulator just to
    > generate timing diagram waveforms for people.
    >
    > I can, given sufficient time and energy, muddle through reading Verilog.
    > Never written a line of it. But I'm getting a vague sense, possibly out
    > of frustration, that a whole lot of verification benches, especially as
    > you're trying to get up into transaction level bus models, get easier in
    > SystemVerilog than they are doing it in VHDL, even with the 2008
    > improvements.
    >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together. The options for doing
    > similar in VHDL (procedures with a billion signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude. I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."
    >
    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket. But am I doing myself a
    > disservice by not learning SV?
    >


    I use Python via MyHDL for all my verification unless dictated
    otherwise. As you point out, you can easily build up transaction
    interfaces to the DUT. With MyHDL bridging the HLL to the cycles and
    bits is a breeze. I have used it successfully on our last mixed-sginal
    ASIC design (small'sh design but all verification via Python/MyHDL).

    I do keep up with SystemVerilog but that is mainly out of curiosity and
    for job prospects if I ever need it. Not all places are open to
    alternative solutions. Also, integrating my signal-processing system
    design/simulations and leveraging it for HDL verification is
    straight-forward.

    Regards,
    Chris
    Christopher Felton, Nov 15, 2011
    #3
  4. Rob Gaddi

    HT-Lab Guest

    On 15/11/2011 17:28, Rob Gaddi wrote:
    > Oh good, a topic to start a flame war with...
    >
    > So I consider myself pretty comfortable with VHDL. I use it for my
    > synthesizable designs. I use it for my testbenches. Occasionally I'll
    > write a VHDL behavioral model and run it through my simulator just to
    > generate timing diagram waveforms for people.
    >
    > I can, given sufficient time and energy, muddle through reading Verilog.
    > Never written a line of it. But I'm getting a vague sense, possibly out
    > of frustration, that a whole lot of verification benches, especially as
    > you're trying to get up into transaction level bus models, get easier in
    > SystemVerilog than they are doing it in VHDL, even with the 2008
    > improvements.
    >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together. The options for doing
    > similar in VHDL (procedures with a billion signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude. I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."
    >
    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket. But am I doing myself a
    > disservice by not learning SV?
    >


    It can never hurt to learn a new language and to have something else to
    mention on your CV, but make sure it is actually useful to you. If you
    are planning to use a verification framework like OVM/UVM/VMM etc then I
    would say go for it and learn SV (or SC). Make sure however that your
    employer has the budget to buy a simulator capable of handling SV for
    verification and not just for design (huge price difference).

    If you need more verification power like constraint random, functional
    coverage etc then you can perfectly stay with VHDL. Just check out some
    of the packages available on the web like Jim Lewis' excellent
    Constraint Random and Coverage packages.

    http://www.synthworks.com/downloads/index.htm

    Throw in some PSL goodness and you have a very powerful/capable
    functional verification environment.

    Given you like OOP you might also want to check out SystemC, if you are
    a Modelsim user then it is the cheapest way to get access to an OOP
    language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
    is pretty good. You might even be able to use OVM via the free OVM-ML
    package from Cadence although I haven't played with it myself.

    Good luck,
    Hans
    www.ht-lab.com
    HT-Lab, Nov 16, 2011
    #4

  5. >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together. The options for doing
    > similar in VHDL (procedures with a billion signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude. I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."
    >
    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket. But am I doing myself a
    > disservice by not learning SV?
    >


    If you do decide to use SystemVerilog for verification, get the 3rd
    edition of "SystemVerilog for Verification"
    http://www.buchhandel.de/detailansicht.aspx?isbn=9781461407140

    Very good resource!
    Chris
    Christopher Felton, Nov 16, 2011
    #5

  6. >
    > Given you like OOP you might also want to check out SystemC, if you are
    > a Modelsim user then it is the cheapest way to get access to an OOP
    > language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
    > is pretty good. You might even be able to use OVM via the free OVM-ML
    > package from Cadence although I haven't played with it myself.
    >


    I think SystemC/C++, in this context, is a waste of time and effort.
    Every verification effort that I have been involved with that uses
    SystemC has had to devoted a fair number of resources to C++ development
    and maintenance. In my opinion SystemC/C++ is antiquated and there are
    better options available.

    I believe Hans' main point is, if you want to use the advanced
    verification features of SV you will need to shell out some money for an
    SV simulator. And a cheaper alternative is SystemC. But my take,
    SystemC is anti-productive, you are better off leveraging
    SV/Python/Ruby/Matlab/Java any HLL that empowers the developer. SystemC
    is for the large organizations that can devote the resources. In my
    opinion you will spend more money developing C++ code than you will on
    an SV enabled simulator.

    Regards,
    Chris
    Christopher Felton, Nov 16, 2011
    #6
  7. Rob Gaddi

    Dal Guest

    I have been using SV to implement a test bench for my current project.
    I didn't get into OVM/UML but just used the language to create a
    simple test environment. I find the language features very useful
    (objects, randomization, queues, fork/join etc) and a very 'natural'
    way to develop test code.

    I can't see myself going back. SV seems suitable for simple and
    complex designs and also allows the engineer to start simply which is
    important as I was self taught as training is non-existant in my part
    of the world.

    I would always still use VHDL for synthesizable code.

    My only gripe is there does seem to be a premium on the licence (at
    least with Cadence). I am disappointed vendors didn't treat it as
    Verilog from a licencing point of view.

    Darrin

    On Nov 16, 4:28 am, Rob Gaddi <>
    wrote:
    > Oh good, a topic to start a flame war with...
    >
    > So I consider myself pretty comfortable with VHDL.  I use it for my
    > synthesizable designs.  I use it for my testbenches.  Occasionally I'll
    > write a VHDL behavioral model and run it through my simulator just to
    > generate timing diagram waveforms for people.
    >
    > I can, given sufficient time and energy, muddle through reading Verilog.
    >   Never written a line of it.  But I'm getting a vague sense, possibly
    > out of frustration, that a whole lot of verification benches, especially
    > as you're trying to get up into transaction level bus models, get easier
    > in SystemVerilog than they are doing it in VHDL, even with the 2008
    > improvements.
    >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together.  The options for doing
    > similar in VHDL (procedures with a billion signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude.  I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."
    >
    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket.  But am I doing myself a
    > disservice by not learning SV?
    >
    > --
    > Rob Gaddi, Highland Technology --www.highlandtechnology.com
    > Email address domain is currently out of order.  See above to fix.
    Dal, Nov 16, 2011
    #7
  8. Rob Gaddi

    HT-Lab Guest

    On 16/11/2011 15:02, Christopher Felton wrote:
    >
    >>
    >> Given you like OOP you might also want to check out SystemC, if you are
    >> a Modelsim user then it is the cheapest way to get access to an OOP
    >> language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
    >> is pretty good. You might even be able to use OVM via the free OVM-ML
    >> package from Cadence although I haven't played with it myself.
    >>

    >
    > I think SystemC/C++, in this context, is a waste of time and effort.
    > Every verification effort that I have been involved with that uses
    > SystemC has had to devoted a fair number of resources to C++ development
    > and maintenance. In my opinion SystemC/C++ is antiquated and there are
    > better options available.



    Interesting, my experience is actually the opposite. I have seen a large
    number of companies that are quite successful with SystemC. You are
    right that most of these were large companies, that is those that use
    virtual prototyping but I have also seen single users quite successfully
    use SystemC for their development.

    Regarding better languages, yes, I guess we all know that C++ has many
    pitfalls and allows users to write in-comprehensible, un-portable mind
    boggling complex code.

    However, I still believe that SystemC (and the free reference simulator)
    is one of those hidden gems of the EDA world. If you can discipline your
    development and adhere to some good coding practises you will be amazed
    what you can achieve with SystemC.

    Hans
    www.ht-lab.com


    >
    > I believe Hans' main point is, if you want to use the advanced
    > verification features of SV you will need to shell out some money for an
    > SV simulator. And a cheaper alternative is SystemC. But my take, SystemC
    > is anti-productive, you are better off leveraging
    > SV/Python/Ruby/Matlab/Java any HLL that empowers the developer. SystemC
    > is for the large organizations that can devote the resources. In my
    > opinion you will spend more money developing C++ code than you will on
    > an SV enabled simulator.
    >
    > Regards,
    > Chris
    HT-Lab, Nov 25, 2011
    #8
  9. On 11/25/11 3:02 AM, HT-Lab wrote:
    > On 16/11/2011 15:02, Christopher Felton wrote:
    >>
    >>>
    >>> Given you like OOP you might also want to check out SystemC, if you are
    >>> a Modelsim user then it is the cheapest way to get access to an OOP
    >>> language, TLM2.0, AMS(?) and CR. The interface between VHDL and SystemC
    >>> is pretty good. You might even be able to use OVM via the free OVM-ML
    >>> package from Cadence although I haven't played with it myself.
    >>>

    >>
    >> I think SystemC/C++, in this context, is a waste of time and effort.
    >> Every verification effort that I have been involved with that uses
    >> SystemC has had to devoted a fair number of resources to C++ development
    >> and maintenance. In my opinion SystemC/C++ is antiquated and there are
    >> better options available.

    >
    >
    > Interesting, my experience is actually the opposite. I have seen a large
    > number of companies that are quite successful with SystemC. You are
    > right that most of these were large companies, that is those that use
    > virtual prototyping but I have also seen single users quite successfully
    > use SystemC for their development.


    It depends on how you measure success. I was trying to convey, IMO, the
    *cost* to use SystemC/C++ (cost in time and resources). The projects I
    have experience with that used SystemC, most would consider their
    efforts successful. But the companies could assign half a dozen or more
    programmers to the problem.

    I have not seen efforts were one or two developers were able to leverage
    SystemC. If someone has years of experience pumping out C++ code, they
    might do very well. I do believe it is possible just not plausible for
    a single developer or small team.

    >
    > Regarding better languages, yes, I guess we all know that C++ has many
    > pitfalls and allows users to write in-comprehensible, un-portable mind
    > boggling complex code.
    >
    > However, I still believe that SystemC (and the free reference simulator)
    > is one of those hidden gems of the EDA world. If you can discipline your
    > development and adhere to some good coding practises you will be amazed
    > what you can achieve with SystemC.


    I believe any technology, regardless how old or new, can be successfully
    utilized by someone who completely understands what the technology
    provides and can make up for the short-comings with time and/or
    resources. In this case I believe the OP wants to highly leverage a
    technology for verification, I don't think SystemC is the best choice.

    Chris

    >
    > Hans
    > www.ht-lab.com
    >
    >
    >>
    >> I believe Hans' main point is, if you want to use the advanced
    >> verification features of SV you will need to shell out some money for an
    >> SV simulator. And a cheaper alternative is SystemC. But my take, SystemC
    >> is anti-productive, you are better off leveraging
    >> SV/Python/Ruby/Matlab/Java any HLL that empowers the developer. SystemC
    >> is for the large organizations that can devote the resources. In my
    >> opinion you will spend more money developing C++ code than you will on
    >> an SV enabled simulator.
    >>
    >> Regards,
    >> Chris

    >
    Christopher Felton, Nov 27, 2011
    #9
  10. Rob Gaddi

    JimLewis Guest

    Hi Rob,
    > I can, given sufficient time and energy, muddle through reading Verilog.
    > Never written a line of it. But I'm getting a vague sense, possibly
    > out of frustration, that a whole lot of verification benches, especially
    > as you're trying to get up into transaction level bus models, get easier
    > in SystemVerilog than they are doing it in VHDL, even with the 2008
    > improvements.
    >
    > I'm pretty used to doing OOP in languages like Python, C++, and Perl,
    > and the idea of calling bus_master.write(address, data); seems like a
    > pretty natural way of stringing a bench together.


    For VHDL-2008, we looked at adding an interface construct. I wanted
    an
    upgrade from the record based IO I use. However at the same time,
    I also worked out acceptable resolution functions for integer, time,
    and
    real and found I can get by without an interface construct.
    From a users perspective, I create a package, define a record, and
    define procedures that use the record.
    Then calls to the procedures in the package are of the following
    form (where bus_master is a record object whose elements are a
    resolved type):
    write(bus_master, address, data) ;

    On the other hand with OOP, the complexity of the tasks is
    about the same and the call is (where bus_master is a
    class object):
    bus_master.write(address, data);

    From a VHDL purist perspective, it feels a little kludgey to
    initialize the bus_master signal object to give the drivers
    a default value, however, from a pragmatic perspective, it
    works and it does not require any new language features.

    Also from a pragmatic perspective, the current VHDL solution is
    good enough that I think we (the VHDL language committee) needs
    to focus our attention on other things. However, if someone is
    interested in putting forward a proposal, please step up and
    do it. If you are interested in what is happening with VHDL,
    see http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome
    There is always room for more helpers.

    With popular SV OOP methodologies, creating a transaction based
    testbench requires lots of fork and join to both initialize
    objects and create the concurrency. Sure with OOP, you can
    and are dynamically elaborating the testbench, however, how
    often are you plugging and unplugging components during a
    simulation run - never had much use for guarded blocks, but
    I suspect that they will handle this just fine.

    > The options for doing similar in VHDL (procedures with a billion
    > signal parameters or entities
    > with abstract req/ack ports and 'transaction signaling) seem,
    > comparatively, pretty crude. I've made them work time and again, but I
    > can't say I've ever sat back and read it back over and said "You know,
    > that's pretty elegant."


    When I use a BFM to do the interface waveform generation, I always
    use the req/ack ports. However, for simple interfaces that do not
    warrant a BFM, I just put the interface signals in the record and
    am done with it.

    I generally use the BFM because there is other stuff that is
    convenient to put in there, such as protocol checkers (VHDL or
    PSL) and interface waveform loggers.


    > I have no intention of giving up VHDL for my synthesizables; I cling to
    > strong typing like Linus to his blanket. But am I doing myself a
    > disservice by not learning SV?


    At the end of the day, it may end up like VHS vs Betamax and
    politics and/or marketing BS may determine the winner and
    not actual capability.

    As Hans mentioned, check out our Functional Coverage
    and Randomization packages at:
    http://www.synthworks.com/downloads

    The randomization packages rely on procedural randomization.
    Used by itself, procedural randomization requires a little
    more thought to get a balanced distribution of stimulus
    values, however, when combined with the intelligent
    coverage modeling supported by our functional coverage
    packages, it does better than simple solver based
    randomization. I am guessing that the results are similar
    to the intelligent randomization testbench tools for which
    you will have to purchase an additional license. See the
    documentation for more details.

    To help you go further, our testbench class (shameless
    advertising plug) also comes with packages for creating
    scoreboards, resolving integers, real, and time,
    creating memory models (using a methodology that is
    easier than using an array), and utilities.

    If you are considering switching to SV for testbenches and
    the costs are ok, make sure to take a class first (not a plug
    as our focus is on VHDL) as this will give you a better idea
    of what you are getting into - before you make the investment.
    Also, no reason not to check out the free materials out there -
    Mentor and Aldec both have SV web presentations recorded on
    their websites.

    Best,
    Jim

    P.S.
    If you are a senior member of the VHDL community, you
    should be participating in the VHDL standards. VHDL is
    an individual based standard and while membership in
    IEEE, IEEE-SA, and DASC are always greatly appreciated,
    they are not required for participation. For more details
    see: http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome

    Don't let your good ideas be overlooked. Particularly
    those of you who have OOP experience.
    JimLewis, Dec 13, 2011
    #10
    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. Cliff Cummings

    SystemVerilog: "logic" or "ulogic?"

    Cliff Cummings, Sep 16, 2003, in forum: VHDL
    Replies:
    7
    Views:
    4,116
    cc0139808
    Sep 20, 2003
  2. Swapnajit Mittra
    Replies:
    0
    Views:
    1,023
    Swapnajit Mittra
    Sep 21, 2004
  3. Swapnajit Mittra
    Replies:
    0
    Views:
    446
    Swapnajit Mittra
    Oct 21, 2004
  4. vhdlcohen
    Replies:
    0
    Views:
    1,030
    vhdlcohen
    Dec 1, 2004
  5. imavroid
    Replies:
    0
    Views:
    827
    imavroid
    Mar 12, 2006
Loading...

Share This Page