Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1

[Anil Sewani <sewani@qualcorelogic.com>]

>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@informasic.com  Home: www.informasic.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