LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Cores > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: Tom Hawkins <tom1@l...>
    Date: Wed, 28 May 2003 08:25:10 -0500
    Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1
    Top

    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@l...
    http://www.launchbird.com/
    
    
    
    
    

    ReferenceAuthor
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Marco Antonio Simon Dal Poz
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Rudolf Usselmann
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Joachim

    Follow upAuthor
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Joachim

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.