• 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

Controllers

Direct Controllers


Direct controllers provide identical functionality to Shadow controllers and you should read that guide first to understand the background here.

Direct controllers are designed to work in the case where the model for a given IP block is managed by a 3rd party and not the test engineer responsible for the given block. Often this may exist as part of a complete device model as shown here:

From the perspective of the ATD test engineer, how the model is constructed is unimportant and the main thing they need to know is what is the path to their sub-model of interest. Let’s say in our example that the model is instantiated as $model and the path to the ATD model is $model.atd.

Controller Implementation

Creation of the controller is almost identical to the example Shadow controller.

The key difference is that instead of linking the controller to a model class who’s instances it should shadow, it is instead linked to a model instance:

# lib/atd_test_block/atd_controller.rb
module ATDTestBlock
  class ATDController
    include Origen::Controller

    model path: "$model.atd"

    # ATD pattern API implementation as before
  end
end

Instantiating the Controller

This is where the main difference between Shadow and Direct controllers exists, the direct controller needs to be instantiated directly:

$model = SoC::Eagle.new    # Instantiates a model of the target device

atd = ATDTestBlock::ATDController.new

atd.convert(10)  # => <BitCollection>

Once instantiated the atd object above will otherwise behave identically to the Shadow controller example.

Typical Integration

Application environments designed in this manner are a fairly recent development, and the best practices for how to build them are probably still to emerge.

However here is one approach that would work; first the top-level controller would be created and managed by the top-level test engineer:

class EagleController
  include Origen::Controller

  model path: "$model"

  # Instantiate a model whenever a new controller is instantiated
  def initialize(options = {})
    $model = Eagle.new(options)
  end

  # Instantiate an ATD controller as required
  def atd
    @atd ||= ATDTestBlock::ATDController.new
  end
end

The target would instantiate the top-level controller, not the model:

$dut = EagleController.new

The ATD API is now available within the ecosystem as per the Shadow controller example:

$dut.atd.convert(10)  # => <BitCollection>

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license