Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > why systemc?

Reply
Thread Tools

why systemc?

 
 
singh.shailendra@gmail.com
Guest
Posts: n/a
 
      09-08-2004
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.
 
Reply With Quote
 
 
 
 
Javier Castillo
Guest
Posts: n/a
 
      09-08-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
www.opensocdesign.com


(E-Mail Removed) wrote in
news:(E-Mail Removed) m:

> 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.
>


 
Reply With Quote
 
 
 
 
Jos De Laender
Guest
Posts: n/a
 
      09-08-2004
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

(E-Mail Removed) 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.

 
Reply With Quote
 
Russell Fredrickson
Guest
Posts: n/a
 
      09-08-2004
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



<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) m...
> 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.



 
Reply With Quote
 
Jos De Laender
Guest
Posts: n/a
 
      09-09-2004
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
 
Reply With Quote
 
Javier Castillo
Guest
Posts: n/a
 
      09-09-2004
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
(E-Mail Removed)
www.opensocdesign.com


"Russell Fredrickson" <(E-Mail Removed)> wrote in
news:chnpum$vq2$(E-Mail Removed):

> 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
>
>
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) m...
>> 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.

>
>
>


 
Reply With Quote
 
Varun Jindal
Guest
Posts: n/a
 
      09-10-2004
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" <(E-Mail Removed)> wrote in message news:<chnpum$vq2$(E-Mail Removed)>...
> 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
>
>
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) m...
> > 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.

 
Reply With Quote
 
jtw
Guest
Posts: n/a
 
      09-10-2004

"Varun Jindal" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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


 
Reply With Quote
 
Russell Fredrickson
Guest
Posts: n/a
 
      09-10-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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" <(E-Mail Removed)> wrote in message

news:<chnpum$vq2$(E-Mail Removed)>...
> > 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
> >
> >
> >
> > <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed) m...
> > > 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.



 
Reply With Quote
 
Alexander Gnusin
Guest
Posts: n/a
 
      09-11-2004
Javier Castillo <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments