• 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

Runtime Environment

Programming


This guide discusses how to programmatically change the target, note that this will also reload the environment as discussed here: How the Runtime Environment is Applied

If you start writing your own commands you may want to programmatically define or manipulate the target.

A single target should always be loaded by using the following method, it can be called again to later switch to a different target:

Origen.load_target("falcon_1")

To load the default target, or to reload the current target, call the same method with no argument:

Origen.load_target
Warning - If you browse the API you may see some similar methods described for loading the target, however these should be avoided. The above method is the intended public API and will ensure that all dependencies are setup correctly.

With the above warning in mind the Origen::Application::Target API can be consulted to see what additional methods are available to work with the target, an instance of that class is available via Origen.target.

For example to get the name of the current target:

Origen.target.name   # => "falcon_1"

Configurable Targets

Any options passed into the Origen.load_target method can be accessed from within the target and used to customize it by the caller.

For example here is a target where the device version is left for the caller to specify:

# target/falcon.rb
MyApp::Falcon.new(version: options[:version])

This would be used like this:

Origen.load_target("falcon", version: 1)
$dut.version   # => 1
Origen.load_target("falcon", version: 2)
$dut.version   # => 2

Target Loops

Target loops (where some code is repeated for a collection of targets) are very common and Origen provides some dedicated helpers for this.

The Origen.target.loop method is the most useful in a command situation and is designed to generate a loop based on the value of a :target key in an options hash. This option can contain the name of a target or an array containing multiple names, and if none are present it will fall back to the default target following the normal conventions.

It is therefore ideally suited to creating a command where the user can supply one or more targets and could be used like this:

opt_parser = OptionParser.new do |opts|
  opts.on("-t", "--target NAME1,NAME2,NAME3", Array,
    "Override the default target, NAME can be a full path or a fragment of a target name") { |t| options[:target] = t }
end
opt_parser.parse! ARGV

Origen.target.loop(options) do |options|
  # The current target is already loaded, the name of the current target has been substituted into options[:target]
  puts "The name of the current target is: #{options[:target]}"
  # Implement your command logic here...
end

The above would work with any of the following inputs:

# Execute for the current default target
origen my_command      

# Execute for a single specific target
origen my_command -t falcon    

# Execute for multiple specific targets
origen my_command -t falcon,eagle    

Production Target Loops

If your application has defined a production target map then some additional methods are available to loop on that:

Origen.target.each_production do |maskset|
  # Do something for each maskset line defined in the map
end

Origen.target.each_unique_production do |masksets|
  # Do something for each unique target defined in the map
end

The latter will only execute for unique target files, so if the same file is used by multiple maskset numbers it will only be looped once and the masksets argument will be an array containing all maskset numbers that use that target.

Forcing Debug Mode

All of the above looping methods accept an option to force all targets to debug mode, this can be useful depending on the purpose of your command, but should obviously be avoided in cases where the command is concerned with generating production IP.

Origen.target.each_production force_debug: true do |maskset|
  # As above except Origen is running in debug mode regardless of the mode defined by the environment
end

Anonymous Targets

Mostly intended for use in test cases, a temporary target can be declared on the fly with a block of code like this:

Origen.target.temporary = -> do
  MyDUT.new
  OrigenTesters::V93K.new
end

Any calls to load or reload the target will now execute the above function.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license