why systemc?

Discussion in 'VHDL' started by singh.shailendra@gmail.com, Sep 8, 2004.

  1. Guest

    Hi,
    Can anybody elaborate on the speed of the simulation in systemC in
    comparision with Verilog. In our case we have used the systemC for
    the modeling of RTL design, then verified the systemC RTL models. As
    a final step
    systemC RTL is converted into verilog RTL(line by line translation).
    we are surprised to see the both systemC models and Verilog models are
    running at almost same speed. Can you through some light on it, what
    went wrong in the process?
    is it systemC coding is not proper or may be testbench not written
    properly or
    if we code systemC and Verilog at same level of abstraction we should
    same speed only.
    , Sep 8, 2004
    #1
    1. Advertising

  2. Hello:

    We work in a similar way than you, we first made the RT model in
    SystemC, we verificate it using TLM style with SCV features and then we
    made a automatic translation to Verilog using a tool we will release
    very soon under GPL license at www.opensocdesign.com.
    You are rigth, our measures also indicates that the simulation in
    SystemC and in Verilog run at almost the same speed. SystemC creators
    said that one of the advantages of SystemC is the speed, obviously is
    not true, maybe Cadence NCSystemC is faster, I dont know, but the GPL
    implementation of SystemC not.
    But the main advantage I think is not the simulation speed. I think the
    main advantage of SystemC is the verification environment, the SystemC
    Verification Library and the easy way to integrate C code that allows to
    create a very powerfull verification environment. It is true that you
    can also can made similar things using Verilog and PLI but is not so
    easy and here with simulating Verilog with PLI, the simulation is slower
    than one only with SystemC.

    Regards

    Javier Castillo

    www.opensocdesign.com


    wrote in
    news::

    > Hi,
    > Can anybody elaborate on the speed of the simulation in systemC in
    > comparision with Verilog. In our case we have used the systemC for
    > the modeling of RTL design, then verified the systemC RTL models. As
    > a final step
    > systemC RTL is converted into verilog RTL(line by line translation).
    > we are surprised to see the both systemC models and Verilog models are
    > running at almost same speed. Can you through some light on it, what
    > went wrong in the process?
    > is it systemC coding is not proper or may be testbench not written
    > properly or
    > if we code systemC and Verilog at same level of abstraction we should
    > same speed only.
    >
    Javier Castillo, Sep 8, 2004
    #2
    1. Advertising

  3. A good starting point , in my opinion , to gain some insight in the
    matter is asking :
    why would _you_ think SystemC is faster or slower ?

    Jos

    wrote:
    > Hi,
    > Can anybody elaborate on the speed of the simulation in systemC in
    > comparision with Verilog. In our case we have used the systemC for
    > the modeling of RTL design, then verified the systemC RTL models. As
    > a final step
    > systemC RTL is converted into verilog RTL(line by line translation).
    > we are surprised to see the both systemC models and Verilog models are
    > running at almost same speed. Can you through some light on it, what
    > went wrong in the process?
    > is it systemC coding is not proper or may be testbench not written
    > properly or
    > if we code systemC and Verilog at same level of abstraction we should
    > same speed only.
    Jos De Laender, Sep 8, 2004
    #3
  4. Okay -- I think you (and others who replied) have missed one of the main
    points of SystemC. One of the points of SystemC is to enable you to model
    and simulate things at a HIGHER level of abstraction than RTL. If you write
    code at the RT level -- it will probably always simulate on the same order
    of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
    simulators are more mature -- Verilog may simulate faster than SystemC
    (though I haven't done the exact measurements myself and it is simulator
    dependent). The talk about SystemC being faster is making the assumption
    that you write SystemC at a higher level of abstraction than your RTL.
    Though, as a side note, there are several vendors out there who will
    translate Verilog to optimized C/C++ or SystemC and then get about a 10x or
    more improvement over Verilog (TenisonEDA and Carbon Systems come to mind).

    In my opinion -- writing RTL in SystemC is a waste of time since Verilog (or
    VHDL) is more suitable to that task (and maintaining RTL descriptions in TWO
    languages seems like even more of a waste of time and is asking for
    trouble). In any case you can always have Verilog and SystemC co-exist by
    interfacing SystemC to RTL through a PLI or using one of the unified
    SystemC/Verilog simulators.

    My point -- adopting a new language without also adopting a new methodology
    that makes use of the power of the language will only give you limited
    benefit (if any benefit at all). For example, when going from schematic
    capture to Verilog -- many people at first used Verilog just like a textual
    schematic capture tool. This got them using an HDL (which is a step in the
    write direction), but they really didn't get the full advantage of the HDL
    until they started writing RTL that then could then synthesized into gates
    (basically raising the level of abstraction at which they modeled their
    design).

    So for SystemC some of the power of the language comes in being able to do a
    top-down implementation where you start with a high-level architectural
    model and refine it down to the RTL level (or perhaps use a behavioral
    synthesis tool once you get down to a appropriate level of abstraction).
    Also the SystemC Verification extensions (SCV) is another way SystemC can be
    used to improve your verification effort (here again -- you will probably
    need to use a different verification methodology to make full use of SCVs
    capabilities). I'll stop there -- if you look hard enough you should be
    able to find other references talking about the new methodologies enabled by
    SystemC.

    I hope that helps,
    Russell



    <> wrote in message
    news:...
    > Hi,
    > Can anybody elaborate on the speed of the simulation in systemC in
    > comparision with Verilog. In our case we have used the systemC for
    > the modeling of RTL design, then verified the systemC RTL models. As
    > a final step
    > systemC RTL is converted into verilog RTL(line by line translation).
    > we are surprised to see the both systemC models and Verilog models are
    > running at almost same speed. Can you through some light on it, what
    > went wrong in the process?
    > is it systemC coding is not proper or may be testbench not written
    > properly or
    > if we code systemC and Verilog at same level of abstraction we should
    > same speed only.
    Russell Fredrickson, Sep 8, 2004
    #4
  5. Russell Fredrickson wrote:
    > Okay -- I think you (and others who replied) have missed one of the main
    > points of SystemC. One of the points of SystemC is to enable you to model
    > and simulate things at a HIGHER level of abstraction than RTL. If you write
    > code at the RT level -- it will probably always simulate on the same order
    > of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
    > simulators are more mature -- Verilog may simulate faster than SystemC

    <SNIP>

    I don't count myself in the "and others who replied" ;-)
    You hit the main point : Higher level of abstraction (i.e. omitting
    detailed information) improves performance.
    You even don't need SystemC for that. It's very well possible in VHDL
    and probably Verilog too.

    Jos
    Jos De Laender, Sep 9, 2004
    #5
  6. Hello:

    I dont think the use of SystemC for RT design is a waste of time. I think
    of course ,that it main advantage is the possibility of describe the system
    in a higher abstraction level and to develop the verification environment
    at this level of abstraction, but for the moment there are not tools that
    make a synthesis from this high abstraction level. The results is that you
    have to refine the model and finally write the RT modules of your system.

    If you want to take advantage of the verification environment you have
    developed before, you have to write the RT modules in systemC. You will say
    that you can write them in Verilog and them use a tool that allows
    simulation of mixed languages, of course, but this tools are really
    expensive and the code you write is not compatible with the SystemC GPL
    implementation.

    We use systemC in that way, we first develop a verification environment and
    a high level model of the system. Then we refine the model to a RT
    description in SystemC and we use the same verification environment
    changing the transactors to verificate the RT model. When the RT model is
    correct, we translate the RT model to Verilog with a automatic translation
    tool in ordet to synthetise it. We dont maintain two descriptions since
    the Verilog is an automatic translation from systemC and believe me, that
    is works really well.

    I dont know if you have used SystemC for RT design, we use it extensively
    and I can say it can be used for RT design without any problem.
    I dont understand why to use PLI or mixed language simulators since there
    are a working implementation of syntemC, suitable for RT design, that works
    fine.
    If you dont believe me, go to www.opencores.org and download SystemCAES,
    SystemCDES or SystemCMD5 projects and you will see systemC RT designs with
    a high level model and a verification environment and its automatic
    translation to verilog working.

    Regards

    Javier Castillo

    www.opensocdesign.com


    "Russell Fredrickson" <> wrote in
    news:chnpum$vq2$:

    > Okay -- I think you (and others who replied) have missed one of the
    > main points of SystemC. One of the points of SystemC is to enable you
    > to model and simulate things at a HIGHER level of abstraction than
    > RTL. If you write code at the RT level -- it will probably always
    > simulate on the same order of magnitude whether it's Verilog or
    > SystemC -- in fact since the Verilog simulators are more mature --
    > Verilog may simulate faster than SystemC (though I haven't done the
    > exact measurements myself and it is simulator dependent). The talk
    > about SystemC being faster is making the assumption that you write
    > SystemC at a higher level of abstraction than your RTL. Though, as a
    > side note, there are several vendors out there who will translate
    > Verilog to optimized C/C++ or SystemC and then get about a 10x or more
    > improvement over Verilog (TenisonEDA and Carbon Systems come to mind).
    >
    > In my opinion -- writing RTL in SystemC is a waste of time since
    > Verilog (or VHDL) is more suitable to that task (and maintaining RTL
    > descriptions in TWO languages seems like even more of a waste of time
    > and is asking for trouble). In any case you can always have Verilog
    > and SystemC co-exist by interfacing SystemC to RTL through a PLI or
    > using one of the unified SystemC/Verilog simulators.
    >
    > My point -- adopting a new language without also adopting a new
    > methodology that makes use of the power of the language will only give
    > you limited benefit (if any benefit at all). For example, when going
    > from schematic capture to Verilog -- many people at first used Verilog
    > just like a textual schematic capture tool. This got them using an
    > HDL (which is a step in the write direction), but they really didn't
    > get the full advantage of the HDL until they started writing RTL that
    > then could then synthesized into gates (basically raising the level of
    > abstraction at which they modeled their design).
    >
    > So for SystemC some of the power of the language comes in being able
    > to do a top-down implementation where you start with a high-level
    > architectural model and refine it down to the RTL level (or perhaps
    > use a behavioral synthesis tool once you get down to a appropriate
    > level of abstraction). Also the SystemC Verification extensions (SCV)
    > is another way SystemC can be used to improve your verification effort
    > (here again -- you will probably need to use a different verification
    > methodology to make full use of SCVs capabilities). I'll stop there
    > -- if you look hard enough you should be able to find other references
    > talking about the new methodologies enabled by SystemC.
    >
    > I hope that helps,
    > Russell
    >
    >
    >
    > <> wrote in message
    > news:...
    >> Hi,
    >> Can anybody elaborate on the speed of the simulation in systemC in
    >> comparision with Verilog. In our case we have used the systemC for
    >> the modeling of RTL design, then verified the systemC RTL models. As
    >> a final step
    >> systemC RTL is converted into verilog RTL(line by line translation).
    >> we are surprised to see the both systemC models and Verilog models
    >> are running at almost same speed. Can you through some light on it,
    >> what went wrong in the process?
    >> is it systemC coding is not proper or may be testbench not written
    >> properly or
    >> if we code systemC and Verilog at same level of abstraction we should
    >> same speed only.

    >
    >
    >
    Javier Castillo, Sep 9, 2004
    #6
  7. Varun Jindal Guest

    Hello Russell,

    I have a model in SystemC and to simulate it with Verilog testbench, i
    am using a PLI (for VCS). you have mentioned SystemC/Verilog
    co-simulators, but i have not been able to find any. Does anybody know
    any such simulators available?

    Thanks in Advance.

    regards
    Varun.





    "Russell Fredrickson" <> wrote in message news:<chnpum$vq2$>...
    > Okay -- I think you (and others who replied) have missed one of the main
    > points of SystemC. One of the points of SystemC is to enable you to model
    > and simulate things at a HIGHER level of abstraction than RTL. If you write
    > code at the RT level -- it will probably always simulate on the same order
    > of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
    > simulators are more mature -- Verilog may simulate faster than SystemC
    > (though I haven't done the exact measurements myself and it is simulator
    > dependent). The talk about SystemC being faster is making the assumption
    > that you write SystemC at a higher level of abstraction than your RTL.
    > Though, as a side note, there are several vendors out there who will
    > translate Verilog to optimized C/C++ or SystemC and then get about a 10x or
    > more improvement over Verilog (TenisonEDA and Carbon Systems come to mind).
    >
    > In my opinion -- writing RTL in SystemC is a waste of time since Verilog (or
    > VHDL) is more suitable to that task (and maintaining RTL descriptions in TWO
    > languages seems like even more of a waste of time and is asking for
    > trouble). In any case you can always have Verilog and SystemC co-exist by
    > interfacing SystemC to RTL through a PLI or using one of the unified
    > SystemC/Verilog simulators.
    >
    > My point -- adopting a new language without also adopting a new methodology
    > that makes use of the power of the language will only give you limited
    > benefit (if any benefit at all). For example, when going from schematic
    > capture to Verilog -- many people at first used Verilog just like a textual
    > schematic capture tool. This got them using an HDL (which is a step in the
    > write direction), but they really didn't get the full advantage of the HDL
    > until they started writing RTL that then could then synthesized into gates
    > (basically raising the level of abstraction at which they modeled their
    > design).
    >
    > So for SystemC some of the power of the language comes in being able to do a
    > top-down implementation where you start with a high-level architectural
    > model and refine it down to the RTL level (or perhaps use a behavioral
    > synthesis tool once you get down to a appropriate level of abstraction).
    > Also the SystemC Verification extensions (SCV) is another way SystemC can be
    > used to improve your verification effort (here again -- you will probably
    > need to use a different verification methodology to make full use of SCVs
    > capabilities). I'll stop there -- if you look hard enough you should be
    > able to find other references talking about the new methodologies enabled by
    > SystemC.
    >
    > I hope that helps,
    > Russell
    >
    >
    >
    > <> wrote in message
    > news:...
    > > Hi,
    > > Can anybody elaborate on the speed of the simulation in systemC in
    > > comparision with Verilog. In our case we have used the systemC for
    > > the modeling of RTL design, then verified the systemC RTL models. As
    > > a final step
    > > systemC RTL is converted into verilog RTL(line by line translation).
    > > we are surprised to see the both systemC models and Verilog models are
    > > running at almost same speed. Can you through some light on it, what
    > > went wrong in the process?
    > > is it systemC coding is not proper or may be testbench not written
    > > properly or
    > > if we code systemC and Verilog at same level of abstraction we should
    > > same speed only.
    Varun Jindal, Sep 10, 2004
    #7
  8. jtw Guest

    "Varun Jindal" <> wrote in message
    news:...
    > Hello Russell,
    >
    > I have a model in SystemC and to simulate it with Verilog testbench, i
    > am using a PLI (for VCS). you have mentioned SystemC/Verilog
    > co-simulators, but i have not been able to find any. Does anybody know
    > any such simulators available?

    Modelsim, for one: VHDL, verilog, and SystemC (to a limited extent.)
    Of course, you need the appropriate licen$e$.

    >
    > Thanks in Advance.
    >
    > regards
    > Varun.


    Jason
    jtw, Sep 10, 2004
    #8
  9. The one we are using is the Cadence Insicive Unified Simulator. I know
    Mentor has a version as well (don't know about Synopsys). I don't know
    about the Mentor version -- but The Cadence implementation is very nice in
    that you can do things like call Verilog functions/tasks from SystemC (and
    in the next version -- IUS 5.4 -- you are supposed to be able to call
    SystemC functions from Verilog), instantiate SystemC inside Verilog (and
    vice versa), directly access Verilog memories from SystemC, etc. In
    addition, they do have an integrated environment debug environment and a
    good transaction recording facility (from what I can tell -- I haven't used
    the transaction recording too much yet). Cadence also has it's hands in
    donating major portions of the SystemC add on libraries (SCV, TLM
    methodology) -- so they really good in terms of full support for most
    anything you want to do with SystemC. Again, I really don't have any data
    on Mentor's version, so I can't comment on it.

    Russell


    "Varun Jindal" <> wrote in message
    news:...
    > Hello Russell,
    >
    > I have a model in SystemC and to simulate it with Verilog testbench, i
    > am using a PLI (for VCS). you have mentioned SystemC/Verilog
    > co-simulators, but i have not been able to find any. Does anybody know
    > any such simulators available?
    >
    > Thanks in Advance.
    >
    > regards
    > Varun.
    >
    >
    >
    >
    >
    > "Russell Fredrickson" <> wrote in message

    news:<chnpum$vq2$>...
    > > Okay -- I think you (and others who replied) have missed one of the main
    > > points of SystemC. One of the points of SystemC is to enable you to

    model
    > > and simulate things at a HIGHER level of abstraction than RTL. If you

    write
    > > code at the RT level -- it will probably always simulate on the same

    order
    > > of magnitude whether it's Verilog or SystemC -- in fact since the

    Verilog
    > > simulators are more mature -- Verilog may simulate faster than SystemC
    > > (though I haven't done the exact measurements myself and it is simulator
    > > dependent). The talk about SystemC being faster is making the

    assumption
    > > that you write SystemC at a higher level of abstraction than your RTL.
    > > Though, as a side note, there are several vendors out there who will
    > > translate Verilog to optimized C/C++ or SystemC and then get about a 10x

    or
    > > more improvement over Verilog (TenisonEDA and Carbon Systems come to

    mind).
    > >
    > > In my opinion -- writing RTL in SystemC is a waste of time since Verilog

    (or
    > > VHDL) is more suitable to that task (and maintaining RTL descriptions in

    TWO
    > > languages seems like even more of a waste of time and is asking for
    > > trouble). In any case you can always have Verilog and SystemC co-exist

    by
    > > interfacing SystemC to RTL through a PLI or using one of the unified
    > > SystemC/Verilog simulators.
    > >
    > > My point -- adopting a new language without also adopting a new

    methodology
    > > that makes use of the power of the language will only give you limited
    > > benefit (if any benefit at all). For example, when going from schematic
    > > capture to Verilog -- many people at first used Verilog just like a

    textual
    > > schematic capture tool. This got them using an HDL (which is a step in

    the
    > > write direction), but they really didn't get the full advantage of the

    HDL
    > > until they started writing RTL that then could then synthesized into

    gates
    > > (basically raising the level of abstraction at which they modeled their
    > > design).
    > >
    > > So for SystemC some of the power of the language comes in being able to

    do a
    > > top-down implementation where you start with a high-level architectural
    > > model and refine it down to the RTL level (or perhaps use a behavioral
    > > synthesis tool once you get down to a appropriate level of abstraction).
    > > Also the SystemC Verification extensions (SCV) is another way SystemC

    can be
    > > used to improve your verification effort (here again -- you will

    probably
    > > need to use a different verification methodology to make full use of

    SCVs
    > > capabilities). I'll stop there -- if you look hard enough you should be
    > > able to find other references talking about the new methodologies

    enabled by
    > > SystemC.
    > >
    > > I hope that helps,
    > > Russell
    > >
    > >
    > >
    > > <> wrote in message
    > > news:...
    > > > Hi,
    > > > Can anybody elaborate on the speed of the simulation in systemC in
    > > > comparision with Verilog. In our case we have used the systemC for
    > > > the modeling of RTL design, then verified the systemC RTL models. As
    > > > a final step
    > > > systemC RTL is converted into verilog RTL(line by line translation).
    > > > we are surprised to see the both systemC models and Verilog models are
    > > > running at almost same speed. Can you through some light on it, what
    > > > went wrong in the process?
    > > > is it systemC coding is not proper or may be testbench not written
    > > > properly or
    > > > if we code systemC and Verilog at same level of abstraction we should
    > > > same speed only.
    Russell Fredrickson, Sep 10, 2004
    #9
  10. Javier Castillo <> wrote in message news:<Xns955F6B1A9D131jcastilloopensocdesi@193.147.184.15>...
    > Hello:
    >If you dont believe me ...


    I do believe, that it is possible to write design in SystemC. There
    may be some advantages of this approach for people with strong C
    background. There are obviously drawbacks too, and I would like to
    outline some of them.

    1. Translation problems. I am really suspicious about "complete
    automatization" of language translation process. The problem is to
    make it work in ALL the cases. The easiest way to cleanup translation
    may be to reduce "translatable" subset in SystemC. It may not be a
    problem, but then it reduces "synthesizable" subset of SystemC and
    converts it to even more limited subset of synthesizable Verilog RTL.

    2. Descriptive power.
    Verilog as a language was developed for RTL coding and constantly
    improves during years of practice. For example, Verilog 2001 and then
    SystemVerilog defines new useful constructs such as always_comb,
    always_ff etc allowing designer to specify design intent in a way that
    tools can verify. I doubt that SystemC has similar operator or can
    produce them during code translation.

    3. Need to maintain 2 code versions. Despite of Javier's opinion that
    it is not a problem, I do see the need to maintain separately Verilog
    version of RTL code. First, synthesis, STA and Equivalence checking
    tools require verilog as an input. Then, there is a need to use
    library cells, memories, DFT logic such as MBIST and JTAG, PLLs etc
    etc. Do we have all this design infrastructure developed for SystemC?

    4. Synthesis-STA-driven design modifications. These are very popular,
    their intent is to improve timing performance of design. Translation
    will complicate this process as well.

    5. Maintenance effort. Designers cannot escape working and knowing
    Verilog RTL. So they'll end up working with 2 languages as well as
    constantly maintain functional equivalence between SystemC and Verilog
    design representations.

    In addition to design, I also doubt that SystemC is a good choise for
    the whole verification environment. For the system-level verification,
    it is a good choise since it allows seamless interoperability with the
    software. For the functional verification, verification-specific
    languages (HVL)or SystemVerilog would be much better choise.
    Functional verification requires advanced coverage, random generation,
    assertion support as well as may other items such as random stability
    etc. I doubt that SystemC has similar capabilities comparing to HVLs
    or SV.

    Finally, there are already tools fo more efficient C-to-Verilog
    integration than PLI provides. For example, VCS has DirectC interface.
    Similar interface is also defined in SystemVerilog standard.

    Regards,
    Alexander Gnusin
    Alexander Gnusin, Sep 11, 2004
    #10
  11. On Wed, 08 Sep 2004 19:51:24 GMT, Jos De Laender <> wrote:
    >A good starting point , in my opinion , to gain some insight in the
    >matter is asking :
    >why would _you_ think SystemC is faster or slower ?
    >Jos


    and

    On Wed, 8 Sep 2004 13:26:32 -0700, "Russell Fredrickson" <> wrote:
    > ....
    >One of the points of SystemC is to enable you to model
    >and simulate things at a HIGHER level of abstraction than RTL. If you write
    >code at the RT level -- it will probably always simulate on the same order
    >of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
    >simulators are more mature -- Verilog may simulate faster than SystemC
    >(though I haven't done the exact measurements myself and it is simulator
    >dependent).


    I believe pretty much everything I read. Here is a quote from
    a recent article by Shawn McCloud, High-Level Synthesis Product
    Manager, Mentor Graphics Corporation.

    http://www.xilinx.com/publications/xcellonline/xcell_50/xc_mentor-esl50.htm

    This is about half way through the article, in the print version on page
    49 is the following:

    "One advantage of SystemC is that it simulates as much as 100 times faster
    than an equivalent RTL representation specified at the same level of
    abstraction. However, to make a SystemC representation suitable for RTL
    generation or direct C synthesis, designers would need to write it at
    nearly the same level of abstraction as hand-translated RTL, which largely
    negates the advantages of using it in the first place."



    That doesn't mean that the above is true, but here we see Mentor promoting
    it that way.




    Philip Freidin

    For the US news media, there is nothing so important
    or relevant, that it can't be ignored in favor of
    some new, bright and shiny irrelavancy.
    Philip Freidin, Sep 12, 2004
    #11
  12. Alexander Gnusin wrote:

    > I do believe, that it is possible to write design in SystemC. There
    > may be some advantages of this approach for people with strong C
    > background. There are obviously drawbacks too, and I would like to
    > outline some of them.


    Personally, I am against HDL's that are more C like than verilog.

    To me, they make people believe that one can think serially, as
    when writing in a programming language. In hardware, everything
    at least has the possibility of being active all the time, and the
    language should emphasize that.

    Consider the ability to port a serial algorithm written in C to a
    hardware implementation of that algorithm.

    -- glen
    glen herrmannsfeldt, Sep 13, 2004
    #12
  13. Andy Freeman Guest

    glen herrmannsfeldt <> wrote in message news:<ci52f3$14o$>...
    > In hardware, everything
    > at least has the possibility of being active all the time, and the
    > language should emphasize that.


    Nope. A language should emphasize writing demonstrably correct programs.

    > Consider the ability to port a serial algorithm written in C to a
    > hardware implementation of that algorithm.


    Yes, consider that. Assuming that you're using multiple cycles, you're
    reusing clocked storage, pipelining, or both. Between said storage,
    you've got acyclic or converging logic, and the correctness of the
    latter, not to mention its timing, is very hard to verify.

    Note that expressing clocked storage correctly in Verilog is not
    straightforward. (Disagree? Explain why folks have problems with
    storage they didn't intend or don't get storage they do intend.)
    It's hard to do worse with C, and easy to do better. (No, the
    resulting C doesn't look much like sequential C, but so what?)

    With the exception of don't cares, acyclic logic between storage elements
    is just as easy to express in C as any HDL. The only possible advantage
    for HDLs is converging cyclic logic without control signals.

    I don't think that HDLs are going to make up ground with better ways to
    designate clock signals.

    -andy
    Andy Freeman, Sep 14, 2004
    #13
  14. Hello:

    I dont want to have a discussion about what is better, because is obvious
    that actually Verilog or VHDL are more mature HDLs and SystemC is a newbie.
    The thing I want to transmit is that systemC can be used for RT design with
    its current limitations. I say current because the SystemC Synthesis
    Working Group is working in improve the SystemC capabilities in order to
    make SystemC a RT solution as Verilog is.

    About your comments, I am agree in some of them because is obvious that
    tools have a Verilog input and doesnt support SystemC. This Verilog input
    is the reason to make a translation of the SystemC code, but I expect the
    EDA suppliers will add SystemC support in their products.

    But I am not agree in other things, for example when you said:

    > In addition to design, I also doubt that SystemC is a good choise for
    > the whole verification environment. For the system-level verification,
    > it is a good choise since it allows seamless interoperability with the
    > software. For the functional verification, verification-specific
    > languages (HVL)or SystemVerilog would be much better choise.
    > Functional verification requires advanced coverage, random generation,
    > assertion support as well as may other items such as random stability
    > etc. I doubt that SystemC has similar capabilities comparing to HVLs
    > or SV.


    One of the strongest features of SystemC is the verification capabilities.
    The SystemC Verification Library provides random generation, transaction
    recording and many other features. Assertion or advance coverage is not
    possible, the only thing you can do is a line coverage metric using GNU
    gcov program. But as I said I expect EDA vendors will supply a SystemC
    front end in their products.


    > 1. Translation problems. I am really suspicious about "complete
    > automatization" of language translation process. The problem is to
    > make it work in ALL the cases. The easiest way to cleanup translation
    > may be to reduce "translatable" subset in SystemC. It may not be a
    > problem, but then it reduces "synthesizable" subset of SystemC and
    > converts it to even more limited subset of synthesizable Verilog RTL.
    > 2. Descriptive power.
    > Verilog as a language was developed for RTL coding and constantly
    > improves during years of practice. For example, Verilog 2001 and then
    > SystemVerilog defines new useful constructs such as always_comb,
    > always_ff etc allowing designer to specify design intent in a way that
    > tools can verify. I doubt that SystemC has similar operator or can
    > produce them during code translation.


    We are talking about using SystemC as a RT language, and as a RT language
    you can do the same things you make in Verilog. Verilog and SystemC are
    different, and since they are different some things are described in a
    different way, for example assign statement in Verilog has to be translated
    into a combinational process in SystemC, but it can be translated. I think
    that all the Verilog RT subset has translation into SystemC.


    Regards

    Javier Castillo

    www.opensocdesign.com
    Javier Castillo, Sep 14, 2004
    #14
  15. Javier Castillo <> wrote in message news:<Xns95647797DF637jcastilloopensocdesi@193.147.184.15>...

    Hi Javier,
    please see by comments below.

    > I dont want to have a discussion about what is better, because is obvious
    > that actually Verilog or VHDL are more mature HDLs and SystemC is a newbie.
    > The thing I want to transmit is that systemC can be used for RT design with
    > its current limitations. I say current because the SystemC Synthesis
    > Working Group is working in improve the SystemC capabilities in order to
    > make SystemC a RT solution as Verilog is.


    I am convinced that it is possible to develop RTL using SystemC. More
    than that, I am also convinced that, with some efforts, it will be
    possible to develop RTL using Perl or any other language. The question
    will be: how easy will be to sell it to designers.
    Working Group effors are not sufficient to make SystemC a RTL Solution
    as Verilog is. It is about the whole chip design infrastructure. It
    took decades of common effort to bring Verilog-based design
    infrastructure to the current level. Then, the trend as I see is to
    reduce, but not increase the number of RTL languages. SystemVerilog is
    targeting this goal, inheriting most of useful RTL constructs from
    VHDL. In fact, there is no value to express the same design intent in
    different languages. As long as single language allows designers to
    express all he/she needs, there is no need for another one.

    > About your comments, I am agree in some of them because is obvious that
    > tools have a Verilog input and doesnt support SystemC. This Verilog input
    > is the reason to make a translation of the SystemC code, but I expect the
    > EDA suppliers will add SystemC support in their products.


    EDA suppliers will add SystemC support only if there will be business
    case for it. Business case will be developed if designers will be
    willing to pay money for the ability to develop RTL with SystemC. It
    may not happen in the nearest feature.


    > But I am not agree in other things, for example when you said:
    >
    > > In addition to design, I also doubt that SystemC is a good choise for
    > > the whole verification environment. For the system-level verification,
    > > it is a good choise since it allows seamless interoperability with the
    > > software. For the functional verification, verification-specific
    > > languages (HVL)or SystemVerilog would be much better choise.
    > > Functional verification requires advanced coverage, random generation,
    > > assertion support as well as may other items such as random stability
    > > etc. I doubt that SystemC has similar capabilities comparing to HVLs
    > > or SV.

    >
    > One of the strongest features of SystemC is the verification capabilities.
    > The SystemC Verification Library provides random generation, transaction
    > recording and many other features. Assertion or advance coverage is not
    > possible, the only thing you can do is a line coverage metric using GNU
    > gcov program. But as I said I expect EDA vendors will supply a SystemC
    > front end in their products.


    SystemC has good enough support for transaction-based, system-level
    verification. It does not have almost any support for cycle-precised
    verification, such as sequences, properties, assertions, coverage
    constructs etc. This is natural, since SystemC, according to it's
    name, targets system-level modeling and verification.


    Regards,
    Alexander Gnusin
    Alexander Gnusin, Sep 15, 2004
    #15
  16. Guest

    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. zoro
    Replies:
    2
    Views:
    3,047
    =?ISO-8859-1?Q?Nicolai_J=F8rgensen?=
    Jul 5, 2003
  2. Andrew Paule

    Re: looking for systemC cores

    Andrew Paule, Jul 20, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,064
    Andrew Paule
    Jul 20, 2003
  3. Andreas
    Replies:
    1
    Views:
    886
    Eyck Jentzsch
    Oct 13, 2003
  4. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    881
    Mark Rae
    Dec 21, 2006
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,857
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page