• 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

Versioning


Adding a version attribute is strongly encouraged since this will be how bugs and features will be tracked in the future.

Since this is such a common attribute all Origen models already have a version attribute and if this key is passed to a sub_block definition it will automatically be attached to the sub-block, even in the case where a custom class is used.

When instantiating an SoC model we can supply a version and this should then cascade down the hierarchy affecting what versions of the sub-modules get instantiated.

Let’s say that two different versions of our Eagle device exist, and in turn each one instantiated a different version of the NVM IP. We can model that like this:

# lib/soc/eagle_m352.rb
module SOC
  class EAGLE_M352
    include Origen::TopLevel

    def initialize(options={})
      case version
      when 0
        sub_block :nvm, class_name: "NVM_M682", version: 3
      when 1
        sub_block :nvm, class_name: "NVM_M682", version: 5
      else
        fail "The BOM for version #{version} has not been defined!"
      end
    end
  end
end

Note that we define an error condition if our application attempts to instantiate a version that we have not defined.

We then cascade this information down the tree, so our NVM module should also instantiate it’s components based on the required version:

# lib/nvm/nvm_m682.rb
module NVM
  class NVM_M682
    include Origen::Model

    def initialize(options={})
      case version
      when 3
        sub_block  :analog,        class_name: "ANALOG_T921", version: 11
        sub_blocks :memory,        class_name: "MEMORY_128_B954", instances: 4, version: 12
        sub_block  :state_machine, class_name: "CONTROL_D345", version: 20

      when 5
        sub_block  :analog,        class_name: "ANALOG_T921", version: 12
        sub_blocks :memory,        class_name: "MEMORY_128_B954", instances: 4, version: 12
        sub_block  :state_machine, class_name: "CONTROL_D345", version: 24

      else
        fail "The BOM for version #{version} has not been defined!"
      end
    end

  end
end

We can test this out in the console:

$dut = SOC::EAGLE_M352.new(version: 0)
$dut.nvm.state_machine.version   # => 20

$dut = SOC::EAGLE_M352.new(version: 1)
$dut.nvm.state_machine.version   # => 24

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license