[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1
- To: cores@opencores.org
- Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1
- From: Tom Hawkins <tom1@launchbird.com>
- Date: Wed, 28 May 2003 08:04:51 -0500
- In-Reply-To: <1054092580.23682.18.camel@linux8k>
- Organization: Launchbird Design Systems, Inc.
- References: <Pine.LNX.4.21.0305201027150.22930-100000@nefertit.intranet> <200305271420.51095.tom1@launchbird.com> <1054092580.23682.18.camel@linux8k>
- Reply-To: cores@opencores.org
- Sender: owner-cores@opencores.org
- User-Agent: KMail/1.4.3
On Tuesday 27 May 2003 10:29 pm, Rudolf Usselmann wrote:
> On Wed, 2003-05-28 at 02:20, Tom Hawkins wrote:
> > On Tuesday 27 May 2003 11:58 am, Shehryar Shaheen wrote:
> > > So what would Sytem Verilog have in the offing that
> > > SystemC doesn't ?
> > >
> > > Would you think that the reason that SystemC is not popular is
> > > cause the learning curve associated with a new language tends
> > > to put off many users who already have a firm grip over
> > > current HDLs ?
> >
> > SystemC is not popular because C, object-orientation, and
> > imperative programming are very poor languages and paradigms for
> > describing hardware systems.
>
> I have to disagree here, Tom. It's not the Object Oriented aspect
> that make a language like SystemC dis-liked by most HW designers.
> Matter of fact, Object Oriented languages are quite popular, look
> at Vera and E.
Rudi, I agree with you here. OO works well in the test bench. But
for synthesizable RTL, how often you you code a StateMachine class
that inherits from BaseStateMachine and extend the Reset and
StateTransistion methods?
> In my opinion the reason SystemC is dead (and I did try it several
> times) is because it is a "Software Development" language. By
> default the flow of the program is sequential. I find it very
> difficult to think and write hardware descriptions (even
> behavioral) that are equivalent to an 'alway' or 'assign'
> statements in verilog. Both of these are constantly executed in
> parallel. Well, virtually in parallel. The time is advanced after
> all of these 'always' and assign' blocks have been executed. I
> don't have to think about time advancing and parallelism when
> writing HDL. It's like drawing gates but on a higher level.
> This in my opinion is why SystemC is dead. I have written quite a
> bit C and C++ code, and feel that I know both of those languages
> fairly well.
Very much agreed. Implicit parallelism is the main reason we all
prefer HDL. It provides a very convenient way to code that block
diagram you drew out on a napkin over lunch. Unfortunately,
SystemVerilog doesn't extend these ideas much -- hence, my motivation
for cf.
> Honestly, i don't know enough about all the feature SystemVerilog
> is adding. BUT, I'm thinking if it does build on Verilog, whats
> there to loose ? Guys who don't like all the new constructs, can
> stay in their comfort box and only use the part of the language
> they feel comfortable with. The rest of us, more adventurous guys,
> will love the additional help we get from the additions ...
SystemVerilog will also support the new tax laws. This will really
help me out with my 1040s and 1099s next April. ;-)
The only thing lost by all this new stuff is implementation. A lot of
tools don't even completely support Verilog-2001 yet. Synopsys will
be the only company with broad SystemVerilog support for the distant
future. Remember, they bought Co-Design, the creators and
implementors of SuperLog. It only makes sense for Synopsys to push
for SystemVerilog; most of the work has already been done for them.
-Tom
--
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
tom1@launchbird.com
http://www.launchbird.com/
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml