• 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

Paths & Origen.root


As you may know Origen.root can be used to make references to files and paths within Origen application code. In this simple example the variable my_pattern_dir will be assigned to an absolute path to the application’s pattern directory regardless of where the workspace owner has installed the application:

my_pattern_dir = "#{Origen.root}/pattern"

However things get a bit more complicated when writing a plugin, for example if the above code resides in a plugin do you mean the plugin’s pattern directory or the pattern directory of the importing application?

By established conventions Origen.root always means the root of the current application, so in the above example the variable will always be set to the top-level application’s pattern directory even if the code resides in a plugin.

Origen.root!

What if you are writing a plugin and you do mean to reference somewhere within the plugin’s source files?

In that case the method Origen.root! can be used instead. If the plugin is being run in a standalone manner then the path returned will be the same as that from the conventional Origen.root. However if the plugin is invoked through a 3rd party application then it will return the path to the plugin’s source files instead of those of the importing/top-level application.

Here is a simple example to illustrate this:

# Lives in a plugin called 'atd_test'
module ATDTest
  class ATD16
    def root
      Origen.root
    end

    def root!
      Origen.root!
    end
  end
end

# Lives in the top-level application
class SoC
  def atd
    @atd ||= ATDTest::ATD16.new
  end

  def root
    Origen.root
  end

  def root!
    Origen.root!
  end
end
   
# Say the top-level application has been installed to /proj/c28/workspace1
$dut = SoC.new

$dut.root       # => "/prog/c28/workspace1"
$dut.root!      # => "/prog/c28/workspace1"
$dut.atd.root   # => "/prog/c28/workspace1"
$dut.atd.root!  # => "/home/thao/.origen/gems/atd_test"

Origen.root(:plugin_name)

Additionally within an application it is sometimes useful to be able to refer to a 3rd party plugin’s root directory. This can be done by supplying the name of the plugin to Origen.root.

An example use case of where this is useful is if you want to re-open and extend a class that is provided by a plugin:

# Ensure the original is loaded
require "#{Origen.root(:atd_test)}/lib/atd_test/atd16"
module ATDTest
  class ATD16
    def my_additional_method
      puts "hello"
    end
  end
end

Origen.top

Origen.top always returns the absolute path to the Origen core installation regardless of whether it is called by top-level application or plugin code.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license