• 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

Target


All targets are defined by files that reside in the target directory. Targets are regular Ruby files and they should be simply named:

<identifier>.rb

Normally the target is used to select the target device and they are simply named after the device that they instantiate, e.g.

target
|-- eagle.rb
|-- falcon.rb
|-- vulture.rb
`-- osprey.rb

Creating a Target

To create a new target, simply create the file containing whatever Ruby code you need. They are usually very concise and normally only instantiate the target device model, here are some examples:

# target/eagle.rb
MyApp::Eagle.new

# target/falcon.rb
MyApp::Falcon.new

A common variation on this theme is to have different targets for different versions of the device that are available, or perhaps to configure the model differently for different types of test:

# target/eagle_1.rb
MyApp::Eagle.new(version: 1)

# target/eagle_2.rb
MyApp::Eagle.new(version: 2)

# target/falcon_func.rb
MyApp::Falcon.new(configuration: :func)

# target/falcon_bist.rb
MyApp::Falcon.new(configuration: :bist)

Setting a Default Target

A default target can be defined that will be used withing a new workspace unless the user specifies otherwise. This is not required and should only be added if it makes sense within the context of the application - i.e. you may choose not to have a default to avoid the situation where the user builds something without really understanding what configuration they are targeting.

A default is specified by creating a target file called target/default.rb, typically this is a symbolic link to another target file:

ln -s target/falcon_bist.rb target/default.rb

Getting and Setting the Target

The current target for a given application workspace can be queried by running the origen target command, or origen t for short, this will show you the content of the current target file:

> origen t

Current target: falcon_bist.rb
**********************************************************************
  MyApp::Falcon.new(configuration: :bist)
**********************************************************************

The target can be changed by running the same command and supplying the desired target:

> origen t target/falcon_func.rb

> origen t falcon_bist

As shown above, a full path or any snippet which is enough to uniquely identify one of the available target files is sufficient.

Additionally all Origen commands allow an override to be supplied at runtime:

> origen g my_pattern -t eagle_2

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license