Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

why systemc?

 
 
Philip Freidin
Guest
Posts: n/a
 
      09-12-2004
On Wed, 08 Sep 2004 19:51:24 GMT, Jos De Laender <(E-Mail Removed)> 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" <(E-Mail Removed)> 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/x...ntor-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.
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      09-13-2004


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

 
Reply With Quote
 
 
 
 
Andy Freeman
Guest
Posts: n/a
 
      09-14-2004
glen herrmannsfeldt <(E-Mail Removed)> wrote in message news:<ci52f3$14o$(E-Mail Removed)>...
> 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
 
Reply With Quote
 
Javier Castillo
Guest
Posts: n/a
 
      09-14-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
www.opensocdesign.com

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