• 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

Installing Origen

Invoking Considerations


As you may have noticed, running origen or origen -h gives you a different set of commands depending on where you run. When you invoke Origen, one of the first things it will do is figure out what type of invocation you’ve issued. The type of invocation isn’t something you need to control neccessarily, but its important to understand why Origen’s behavior seems to arbitrarily change.

Application Invocations

When you invoke Origen from within an application (or a plugin), you’re using Origen’s application invocation. This will most likely be the invocation used for any test or product engineer that is not creating a new application. You’ll notice that when you first run Origen from an application, you’ll see Bundler start to do some stuff… but what’s it doing? Bundler is building up a custom bin folder (lbin, to be exact) which it will channel future invocation within the application through. This ties this particular application to the gems specified in the Gemfile and gives you the application invocation.

So, what does that mean? Application invocations begin by booting up the application and all needed plugins. The best way to see that will be to just run origen -h from inside and outside an appication. When running from within an application, you’ll get the core application commands, any Shared Commands from plugins, and any Global Commands from plugins.

Global Invocations

Global Invocations are the opposite of the aforermentioned Application Invocations. These invocations are obviously for when origen is run without any application.

The default core global commands are just new and interactive. This makes sense, since its not appropriate to create a new application if you’re already running from one, and when there is no application you’ll most likely want to create a new one. You can see here for creating a new application.

However, global invocations can also run other global commands. This allows Origen to become a platform for tool distribution, allowing for developers who use Origen to use all that Origen offers to build and distribute other tools or scripts.

Using global commands may require a bit of additional setup. The commands that are available depend on how exactly the global invocation was induced. There are multiple ways to do this, as described in the next section.

Note that this section only covers invocations. For a guide on how to actually create global commands, please see the section on global commands.

System Invocations

For new Origen users, this will be the most likely way of globally invoking Origen. This runs Origen straight from the system installed gem (i.e., what was installed when you ran gem install origen). Origen invocations stemming from the this are known as system invocations.

When these occur, Origen will search through all of the dependencies of each gem that is currently installed on the system. If any of these gems have origen as a dependency, then Origen will assume that it is a plugin and boot that gem during Origen’s own booting process. Thus, it is possible to install plugins that have global commands and also have them active by just running gem install.

Since these are available at the system level, if this is done on a shared system or on a server, all users will see those commands become available.

User Invocations

System invocations have the potential problem of requiring administrative access rights. When running on your own system, this is not an issue, but when run on corporate accounts, most users won’t have these permissions.

User installations are more involved. These require using the site config to indicate to Origen that you have a global Gemfile setup somewhere. The full details are beyond a startup guide, so this is marked as an advanced topic and can be found here

Please don’t let that scare you away. However, a tool distribution platform is not Origen’s primary purpose, so unless you know you’ll need it, you can skip the advanced topic until you have more familiarity with Origen.

The basic procedure is:

  1. Create a custom site config in your Origen home directory.
  2. Enable users installs.
  3. Add dependencies to your user Gemfile.

Not that bad, right? If this seems like something you’d like to tackle now, go ahead and check out the topic here.

Once this is setup, invoking Origen through this Gemfile is known as User Invocation.

Tool-Repo Invocations

Tool Repo invocations look very similar to user invocations. However, the usage for these is different. These installations are built and maintained by an experience user and has the purpose of giving a set of users, or users running from a particular directory, access to a pre-built dependency set.

At this point, you will most likely be a user of such an invocation. If so, you would have received some instructions from the installation manager on how to use it.

Setting these up is an involved process. An advanced topic on this is also available in the advanced topics. For now, that is all that will be said on Tool Repo invocations.

Info! Each one of these cases above, and the application invocations, are handled independently. That is, installing a gem in the system ruby, or installing it in your user install will NOT enable that gem to be used in all your applications. Likewise, installing a gem in the system ruby will not make it attainable automatically in all tool repo installs or in your user install. This is so the Gemfile remains the master dependency list, with the only exception being the system install which has no Gemfile. So, if you want to use a specific gem for all your applications, tool repo installs, and your own user install, you will have to add it to the Gemfile of each.

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license