Message

Reply | Reply all

Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

From: Joachim Strömbergson<Joachim.Strombergson@I...>
Date: Wed, 28 May 2003 08:40:53 +0200
Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1

Aloha!

Rudolf Usselmann wrote:
> 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 ...

Exactly. I like Superlog and SystemVerilog because they are evolutionary 
developments based on Verilog. This means that there still exists a clear 
path/sub domain of the language that always makes sense as a HW description. 
SystemC takes a SW language and tries to extend it downwards and into the HW 
domain.

Co-Design were always very explicit and clear on how you could go from 
Superlog features down to RTL. The path was always there. When asking other 
tool vendors how I could go from their nice, graphical HW/SW Codesign tool to 
HW I usually got blank stares or mumbling about stuff in the works at their 
R&D lab.

Expressed in another way: Superlog/SystemVerilog builds on something known to 
work and tries to remove/alleviate problems associated with growing design 
complexitieties (SoC, productivity gap etc, verification explosion and all 
that). SystemC takes something that does not work (for HW design) and adds 
stuff so that it (might) be able to do the same thing as the stuff known to work.

Oh, BTW: HW engineers have been building executable specs and behavioural 
models for ages. They use C, Perl, Java, C++ to model blocks, functions 
complete systems. Depending on what abstraction level, analysis to be 
performed are different languages are better suited than others. Doing a 
simple trace analysis to calculate CPI and total cycle count is probably 
better done in Perl (for easy parsing) than C.

What SystemC tries to do is doing it all in one tool. I'm not totally 
convinced that multi-function tools (like the screw-hammer-plier) is better 
than a good toolbox with optimized point tools. HW designers are used to work 
with tons of tools, so creating the do-it-all tool doesn't remove that much 
problems.

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
VP, Research & Development
----------------------------------------------------------------------
InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden
Tel: +46 31 68 54 90  Fax: +46 31 68 54 91  Mobile: +46 733 75 97 02
E-mail: joachim.strombergson@i...  Home: www.informasic.com
----------------------------------------------------------------------

Reference	Author
Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1	Marco Antonio Simon Dal Poz
Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1	Joachim
Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1	Shehryar Shaheen
Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1	Tom Hawkins
Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1	Rudolf Usselmann

Follow up	Author
Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1	Tom Hawkins
Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1	Anil Sewani