• 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

Plugins

Current & Default Plugins


The current plugin is a concept that comes into play whenever a plugin provides pattern and test program sources to a parent application.

The current plugin is selected in a similar way to the current target, either at runtime to set the current plugin for a given job only:

origen g atd_ramp --plugin atd_test

or the workspace default can be set via the origen pl command:

origen pl atd_test

Identifying a current plugin performs two main functions:

  • Limits the search scope when dynamically searching for pattern sources and avoids ambiguity over which pattern is being requested
  • Selects which application callbacks and configuration context should be enabled

The first function is fairly self explanatory and means that Origen will search for the requested pattern only within the subset of all available patterns that are owned by the current plugin. The second function warrants some more discussion…

Application instances (as defined in config/application.rb) are automatically registered as listeners into Origen’s callback system and this is often used to implement pattern generation features like sourceless pattern generation.

That works fine when an application is running standalone, but once it starts to incorporate many plugin instances who can all synthesize pattern sources then we have a problem over which one to choose to fulfill a given request. Similarly there could be issues when a 3rd party callback listener kicks in when generating a completely unrelated pattern.

The selection of the current plugin therefore gives Origen some help by specifying what area of the wider application should be enabled when generating a particular pattern. Ideally a more automated system would be developed for this, and it may be in future, but for now the current plugin concept solves the problem and doesn’t seem to be much of an hindrance to use in practice.

Aside from callbacks, the current plugin selection also selects which plugin’s configuration overrides should be applied to a given generation job, see the plugin configuration guide for some more discussion on this.

Programmatically Setting the Current Plugin

The current plugin can be set in Ruby code using the below API.

Origen.app.plugins.current   = :atd_test    # Sets the default plugin
Origen.app.plugins.temporary = :atd_test    # Temporarily sets the current plugin (for this thread only)
Origen.app.plugins.temporary = nil          # Discard the temp plugin and set it back to the default
Origen.app.plugins.current.name             # Returns current plugin name

A common usage pattern for modern ‘BOM’ style applications is to have a target corresponding to each main pattern type, which typically will correspond to the main plugins that are providing pattern sources to the application.

The current plugin can therefore be set in the target and then forgotten about, such that it will automatically be set to the correct thing based on the current target:

# target/atd.rb
load "#{Origen.root}/target/dut.rb"  # Load and instantiate the DUT
Origen.app.plugins.temporary = :atd_test

# target/nvm.rb
load "#{Origen.root}/target/dut.rb"  # Load and instantiate the DUT
Origen.app.plugins.temporary = :nvm_test

Providing A Default Plugin

Applications can denote a default plugin, to be used when populated in a new workspace, by setting the configuration attribute default_plugin. This points to the name of the plugin which should be loaded in the absence of any user intervention:

# Set the default plugin to OrigenTesters
config.default_plugin = :origen_testers

Plugins can be set and reset as normal. Once the current plugin is reset, the default plugin will not be assessed again.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license