• 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

Config & Origen.app


Every Origen application and plugin has an object that represents it, this is returned by Origen.app and is essentially an instance of the class defined in config/application.rb.

When calling Origen.app within plugin code some thought has to be given to which application you mean, do you mean the plugin itself or the top-level application that it is plugged into?

To deal with this ambiguity the following API exists which works the same as Origen.root:

Origen.app                # Returns the current top-level app instance
Origen.app!               # Returns the app instance associated with the code making the
                          # call, typically use this to get a plugin's app instance
Origen.app(:doc_helpers)  # Returns the app instance for the given plugin name

Am I the Current Application or Plugin?

A common use case for examining the application instance is to see if a plugin is running standalone (in its own development workspace) or if it is running fully deployed as a plugin to a wider application.

The following code can be used in this case:

if Origen.app!.current?
  # The plugin is running standalone in its own workspace (I am the current application)
else
  # The plugin is running as a component in a parent application
end

A further question can arise if the plugin is found to be running as a component in a parent application: ‘am I the current plugin?’

To test for this:

if Origen.app!.current_plugin?
  # Do something special when I am the current plugin
else
  # Sigh, just another run-of-the-mill plugin
end

Overriding the Application Config

Some config options have the ability to be overridden by the current plugin, e.g. config.pattern_prefix will be set by the plugin that owns the pattern and not the top-level application.

See ATTRS_THAT_CURRENT_PLUGIN_CAN_OVERRIDE in the Configuration API for a complete list of the config options that fall into this category.

If the current plugin does not provide a value for a given config option then the value defined by the top-level application will be used instead.

Typically a rich plugin which provides patterns and similar IP to an application will contain logic like this in its config/application.rb:

# If this app is running standalone then it supports multiple devices and so in that
# case namespace the output by device type. However if running as a plugin then it
# will be in a single device app, in that case put everything in the 'atd' directory 
config.output_directory do
  if current? # If app is running standalone (i.e. not as a plugin)
    "#{Origen.root}/output/#{dut.class}"
  else
    "#{Origen.root}/output/atd"
  end
end

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license