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 11:04:32 -0500
    Subject: Re: [oc] Verilog coding style for Open Cores-RTL - Case in point SHA1
    Top

    On Wednesday 28 May 2003 08:14 am, Rudolf Usselmann wrote:
    > > Rudi, I agree with you here.  OO works well in the test bench. 
    > > But for synthesizable RTL, how often you you code a StateMachine
    > > class that inherits from BaseStateMachine and extend the Reset
    > > and StateTransistion methods?
    >
    > Actually I think OO could work very well for synthesizable code
    > as well. Interfaces definitions come to mind, that could be
    > extended and overloaded etc. I could also envision writing IP
    > cores that are later extended using OO techniques. I might
    > offer different flavors of an IP core that I sell at different
    > costs/configuration. Vera was not synthesizable, but I really
    > liked some of it's OO constructs and believe they could be made
    > synthesizable.
    
    Good point about extendable interfaces.  SystemVerilog is going in the 
    right direction in this regard.  However, their are other ways to 
    define and extend interfaces other than using OO inheritance.
    
    Confluence handles this using first class components (components that 
    can be passed into, or return from other components through ports).
    
    For example, we can define a generic Wishbone interface that 
    implements the Wishbone Data Flow interconnection:
    
    WbDataFlowInterface <-
      comp +DataOp +BusIn -BusOut
        (* Protocol logic here. *)
      end
    
    'BusIn' and 'BusOut' are clearly the input and output Wishbone buses.  
    'DataOp', on the other hand, is some generic operation (component) 
    that is appiled (instantiated) inside 'WbDataFlowInterface' to 
    implement a specific operation.
    
    Want to create a wishbone component that simply NOTs incoming data?
    
      {WbDataFlowInterface, `not BusIn, BusOut}
    
    How about one that implements a filter?
    
      {WbDataFlowInterface, FirFilter BusIn, BusOut}
    
    Need a wishbone fast fourier transform?  Not a problem:
    
      {WbDataFlowInterface, FFT BusIn, BusOut}
    
    Once used to higher-order data-types, there's all sorts of crazy 
    things one can do.
    
    -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 point SHA1Tom Hawkins
    Re: [oc] Verilog coding style for Open Cores-RTL - Case in pointSHA1Rudolf Usselmann

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