• 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

Mode


Origen supports the following operating modes:

  • Production - To be used whenever generating output destined for production use.
  • Debug - To be used whenever developing an application.
  • Simulation - To be used whenever generating output destined for a simulation.

The default operation mode is production, and in this mode Origen will enforce the following restrictions:

  • Origen will not run if there are modified files within the environment workspace (i.e. edits that are not checked in)
  • Origen will not run if plugins are imported from a local path reference

Both debug and simulation modes remove these restrictions and are essentially the same as far as Origen is concerned. However plugin and application developers may implement different behavior if the output is targeting simulation rather than real silicon.

Note that the origen new command for creating a new application will make it look as though debug is the default mode, but this is just to make life convenient for the new application developer who is obviously about to go on and develop the new app. If the new app was cloned to a new workspace by another user, then it would come up in production mode.

Getting and Setting the Mode

The current default mode for a given application workspace can be queried by running the origen mode command, or origen m for short:

> origen m

debug

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

> origen m production

> origen m debug

> origen m simulation

Any shortcut which provides enough detail to uniquely identify one of the available modes can be used:

> origen m sim

Additionally all Origen commands allow an override to be supplied at runtime. Aside from overriding the current default mode, this will also override any mode setting applied by the current environment or target:

> origen g my_pattern -m simulation

Programmatically Getting and Setting the Mode

Origen.mode returns an object representing the current mode, this provides the following API for sniffing the mode at runtime:

Origen.mode.production?   # => false
Origen.mode.debug?        # => true
Origen.mode.simulation?   # => false

Note that simulation is also considered a debug mode, the API will respond as follows if simulation mode is set:

Origen.mode.production?   # => false
Origen.mode.debug?        # => true
Origen.mode.simulation?   # => true

For example this API can be used to create simulation workarounds if required:

if Origen.mode.simulation?
  # Generate something that is more simulation-friendly
else
  # Generate a pattern construct which works on the tester, but doesn't simulate well
end

The mode can be set like this:

Origen.mode = :production
Origen.mode = :debug
Origen.mode = :simulation
Note that the mode can be frozen in which case the above will have no effect. If the mode is supplied via a --mode option to the current command, then it will be automatically frozen to allow it to override any mode assignment made by the target or environment files via the above API.

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license