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
  • Find Resources
  • 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: Rudolf Usselmann <rudi@a...>
    Date: 20 May 2003 00:35:26 +0700
    Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1
    Top

    On Mon, 2003-05-19 at 14:05, Joachim Strömbergson wrote:
    > Aloha!
    > 
    > Rudolf Usselmann wrote:
    > > First of I want to re-state that I am totally against
    > > Coding/Design Guidelines, as every decent engineer will
    > > have his/her own style and will know what he is doing.
    > 
    > Totally against? So you think that these two documents available today on the 
    > OC site should be hosed?
    > 
    > http://www.opencores.org/OIPC/projects/coding.shtml
    > http://www.opencores.org/cgi-bin/cvsget.cgi/common/opencores_coding_guidelines.pdf
    > 
    > Most commercial cores (that are available as readable RTL) follow some sort of 
    >   vendor guidelines. Additionally, soft, firm and hard cores usuall comply to 
    > documented rules and guidelines, particularly on the interface (where it's 
    > really needed). Clocking, reset and naming conventions for the interface is 
    > there to make the integration process easier, and thereby the cost of 
    > integrting a core lower.
    
    I believe such "guide lines" give a false sense of security that
    an IP core is written in a sane way and will work. Design guide
    lines will only be as good as the users that are using them.
    
    Just because OC has had a design guideline posted for some time,
    it doesn't mean that even one person has followed it. There is no
    QA, or even such basic things as verification at OC. Designers
    verify their own cores ! This is horrible in my opinion. You know
    the chances that you will duplicate a bug in the test bench that
    you did in your RTL are very great. So why even bother ?!
    
    > Since we've been talking about getting acceptance for OC-cores in the 
    > industry, lowering the barrier/cost of integration is one thing I belive is 
    > important. No?
    
    Yes, we do want to lower the cost of integration. It is important.
    However, a design guide line will not help here. It's only a guide
    line that designers might or might not follow, and users might or
    might not agree with. Fact is, ALL IP Cores (including commercial
    IPs) use different styles/design guide lines. Each [commercial] IP
    vendor has his own style/design guide line. There is no industry
    standard. So no point here.
    
    A few weeks ago we had a small argument about synchronous/asynchronous
    reset. I always thought we would never have such a discussion as
    *for me* the choice seemed so clear. But as we have found out,
    different users have different preferences. Are they wrong ? Are
    your customers wrong ? No, probably not. The truth is as engineers,
    we can make the most bizarre design work and perform miraculous
    tasks (look at Microsoft Operating Systems :-).
    
    Quite honestly I do not understand what kind of expectations people
    have from design guidelines. It's not a magic recipe that will make
    all problems go away and allow us to throw IP cores together like a
    bunch of Lego Bricks.
    
    ...
    > Oh, and Altera Quartus-II did choke on the port value redefinition. 
    > "Unsupported Verilog HDL Feature Error".
    
    I'll add this to mi list of "Why do I not use Alteras Quartus
    Software. The first item is it filled up a 10GB hard disk trying
    to "compile" a 100K gate design ! While my full custom ASIC tools
    have a hard time filling up a 4GB partition for a 2.5M gate ASIC.
    Hmm, makes you sometimes wonder wat's in their "Design Guideline" !
    
    Cheers,
    rudi               
    -------------------------------------------------------
    www.asics.ws  -- Solutions for your ASIC/FPGA needs ---
    ---------------- FPGAs * Full Custom ICs * IP Cores ---
    * * * FREE IP Cores  --> http://www.asics.ws/ <-- * * *
    
    
    
    

    ReferenceAuthor
    [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1Joachim
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Rudolf Usselmann
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?=

    Follow upAuthor
    Quartus-II (Was: Re: [oc] Verilog coding style...)=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?=
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1John Dalton
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1John Sheahan
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Paul

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