LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Sponsors
  • Mirrors
  • Logos
  • Contact us
  •  
    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: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?=<Joachim.Strombergson@I...>
    Date: Tue, 21 Jan 2003 17:00:39 +0100
    Subject: Re: [oc] Real newbie questions
    Top

    Aloha!
    
    John Sheahan wrote:
    > minor nit - 'fancy language constructs' can often have a place in 
    > test benches / models of the things your code is talking to.
    
    Yes, sorry. I was only talking about the design description, not the whole 
    enchilada with testbenches and other constructs used during development.
    
    I'm not allergic to advanced language constructs per se, I have only found it 
    to be a symptom of a problematic design. I know several experienced designers 
    that produce great HW that uses properly selected advanced constructs from the 
    language to create good, tight code.
    
    One have to be very careul though and verify that the subset of the HDL 
    language to be used in a given project will be accepted by all tools in the 
    flow to be used.
    
    I know at least one instance were the introduction of a tool into the flow 
    (for STA, formal verification etc) ended up causing all kinds of pain simply 
    because the tool deemed neccesary didn't handle a language feature used.
    
    If you have a small FPGA design with a few source files that might be ok. With 
    1000+ source files in the database, then someone will have a bad day (week or 
    month).
    
    > but definitely not in the code you want to synthesize.
    > I agree - if you cannot visualize the hardware your rtl is describing 
    > there is (will be) a problem.
    
    Exactly. Seriously, what do we have to play with - really? Primitive gates 
    (combinational clouds), registers and latches. Then possibly MUXes, FIFOs, and 
    specific memories. That's it (basically ,-)
    
    The HDL needed to describe these things are very simple and well understood.
    
     From these primitives we create higher level RTL thingys such as ALUs, 
    register files, FIR filters, etc. We end up with RTL based IP-cores. But it's 
    all (again basically) hierarchies of very simple functions. The HDL 
    description should reflect that.
    
    The way you do your system modelling, system design, design entry, simulation, 
    feedback, incremental functional development, synthesis, backend, timing 
    convergence runs or whatever is up to you and your methodology. There are good 
    and bad ones and different designs requires different tool flows and 
    adaptation of the methodology. But no matter what your methodology looks like, 
    my deepest recommendation is that you never, never forget that it's a HW 
    design you are developing and implementing. Not HDL programs.
    
    -- 
    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
    
    
    
    
    

    ReferenceAuthor
    [oc] Real newbie questionsNiclas Hedhman
    Re: [oc] Real newbie questionsJohn Sheahan
    Re: [oc] Real newbie questionsJoachim
    Re: [oc] Real newbie questionsNiclas Hedhman
    Re: [oc] Real newbie questionsRudolf Usselmann
    Re: [oc] Real newbie questionsJoachim
    Re: [oc] Real newbie questionsJohn Sheahan

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