• Guides
  • Videos
  • Publications
  • API
  • Github
  • Community
  • Release Notes
  • Plugins
Installing Origen
  • Introduction
  • How to Install
  • How to Install (Windows)
  • Company Customization
  • Understanding Gems
  • Invoking Considerations
  • Workspace Management
Getting Started with Origen
  • Core concepts
  • Creating a New App
  • Directory Structure
  • The Initial Commit
  • Creating New Files
  • Understanding Blocks
  • Application Architecture
Runtime Environment
  • Introduction
  • Mode
  • Environment
  • Target
  • Production Targets
  • Global Setup
  • Load Order
  • Programming
Models
  • Introduction
  • Naming
  • Definition & Hierarchy
  • Adding Attributes
  • Versioning
  • Bugs & Features
  • Package, Mode & Configuration
  • Registers
  • Pins
  • Power Domains
  • Hardware Attributes
  • Parameters
  • Specifications
  • Fuses
  • Generic Components
  • Creating Your Own Components
Compiler (Views)
  • Introduction
  • Creating Templates
  • Using Sub-Templates
  • Helpers
  • Running The Compiler
  • Inline Compiler
Controllers
  • Introduction
  • Shadow Controllers
  • Direct Controllers
Pattern Generator
  • Introduction
  • Creating Patterns
  • Pins
  • Timing and Waiting
  • Registers
  • Documenting Patterns
  • Generating by Name
  • Common API
  • J750 API
  • V93K API
  • UltraFlex API
  • STIL & Other Formats
  • Custom Testers
  • Running The PatGen
  • Concurrent Patterns
Test Program Generator
  • Introduction
  • Philosophy
  • Creating Flows
  • Managing Flow Control
  • Creating an Interface
  • Additional Resources
  • Dynamic Custom Code
  • Characterization API
  • J750 API
  • V93K Common API
  • V93K SMT7 API
  • V93K SMT8 API
  • UltraFLEX API
  • Documenting the Program
  • Creating Custom Testers
  • Running the ProgGen
Decompilation
  • Overview & Example
  • Decompiling, Adding Pins, & Executing
  • Working with Decompiled Patterns
  • Platform Specifics
Simulation
  • Introduction
  • How It Works
  • Compiling the DUT
  • AMS Support
  • Environment Setup
  • Application Setup
  • Simulating Patterns
  • Simulating Flows
  • Direct DUT Manipulation
  • Simulator Log Output
  • Artifacts
  • Debugging
Documentation Generator
  • Introduction
  • Markdown
  • Linking
  • Styling
  • Testing
  • API Generation
  • Deploying
Plugins
  • Introduction
  • Using a Plugin
  • Creating a Plugin
  • Current & Default Plugins
  • Dev Environment
  • Dev Considerations
  • Paths & Origen.root
  • Config & Origen.app
Miscellaneous
  • Revision Control
  • Origen Remotes
  • Lint Testing
  • Session Store
  • LSF API
  • Users, Emails & Maillists
  • Utilities & Helpers
  • Ruby Extensions
  • Logger
  • Adding Commands
  • Overriding Commands
  • Callbacks
  • Application Callbacks
  • Miscellaneous Topics
Advanced Topics
  • Introduction
  • Invocation Customization
  • Custom App Generators

Models

Naming


One of the hardest things in computer science is said to be naming things.

Model naming convention may vary from company to company, but we recommend aligning to whatever system is used by the hardware design teams. In other words the Origen model name for a given IP should be the same as whatever the RTL or macro is called for the corresponding object in the design world.

The overall goal is to eliminate ambiguity and end up with a system where it straightforward to identify what silicon IP is represented by a given Origen model.

Class Naming

Each of your model definitions will be a Ruby class and it is required by Ruby that the class name starts with a capital letter. It is also Ruby convention to use CamelCase for class names, however in our experience this is not necessarily easy to stick to if you are also trying to keep your class names in sync with a 3rd party naming system as recommended above.

If not following CamelCasedNaming, then we recommend that you uppercase and underscore THE_CLASS_NAME for consistency.

It is Ruby (and Origen) conventions that each class is contained within it’s own file that has been assigned the lower_cased_and_underscored version of the class name.

So for example the model for EAGLE_M352 would look like this:

# lib/eagle_m352.rb
class EAGLE_M352

  # Model definition and logic goes here
  
end

Namespacing

Namespacing your code is good practice and is also recommended, in Ruby a namespace involves wrapping all of your code in a uniquely named module.

For example all of the Origen code is contained within the Origen namespace and this (as we will see shortly) is why the Origen register API is accessible via Origen::Registers instead of just Registers.

The name used for the namespace should uniquely identify your application within your ecosystem, if you were writing an application to test a RAM module at a 28nm node for example, then you might go with simply C28RAM.

The namespacing is also mirrored in the file system hierarchy, so all of the files for C28RAM should live in lib/c28ram.

Wrapping the above example in the namespace would change it to:

# lib/c28ram/eagle_m352.rb
module C28RAM
  class EAGLE_M352

    # Model definition and logic goes here
    
  end
end

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license