[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
On Wednesday 28 May 2003 01:40 am, 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.
>
>
> 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.
I agree a multi-function tool is not as useful as a good as a well
stocked toolbox. This same argument applies to SystemVerilog too --
they are trying to add verification constructs by borrowing features
from other languages. A better approach would be to translate
Verilog into whatever language is convenient for verification: C,
Java, Perl, Python, etc. Verilator and VTOC already do this for C.
(Writing this paragraph just convinced me to build a Python generator
for Confluence. Thanks!)
-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