|
Message
From: Anil Sewani <sewani@q...>
Date: Wed, 28 May 2003 14:40:00 -0500
Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1
>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.
that is true. my experience with SystemC reminds me
that it is a weighty language with complex data types,
some of which i never used.
>The rest of us, more adventurous guys, will love the
>additional help we get from the additions ...
agree with rudi.
Joachim Strömbergson wrote:
>
> 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
> ----------------------------------------------------------------------
>
>
|
 |
Browse
