• 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

Simulation

Simulator Log Output


Log output from simulations is often very verbose, which can make it hard to distinguish between messages that are important and those that can be safely ignored.

By default, OrigenSim will automatically suppress all simulator log output except for any lines that contain the text WARNING or ERROR (case insensitive); both of these will be logged to the console and any occurrences of the latter will also make the result of the simulation be classed as a FAIL.

All log output can be shown in the console by running with the -verbose switch, and the log files will always contain everything that was output by the simulator.

OrigenSim will also consider any output from the simulator to STDERR as a sign that something has gone wrong and this will also cause the simulation result to be classed as a FAIL.

If your simulation produces STDERR output which you don’t care about (and which you don’t want to make your simulation FAIL), then you can configure OrigenSim to ignore all STDERR messages via:

OrigenSim.fail_on_stderr = false

Alternatively, a safer solution is to declare which specific messages on STDERR should be ignored. For example, say that in an early design build the ADC is not configured correctly and this results in a message about this being output to STDERR. However, since this problem does not affect the particular IP that we are testing we do not want our simulations to FAIL because of it.

In such a case you can add strings to the stderr_string_exceptions array and any STDERR lines which contain the given text will be ignored:

OrigenSim.stderr_string_exceptions << 'invalid adc config'    # Case in-sensitive match

Note that in all of these cases the given text is considered to be case-insensitive when considering if it matches a log line.

If you need case-sensitivity (or more generally need more control of exactly what is considered to be a match), you can supply a regular expression instead of a string for all of the cases discussed here:

OrigenSim.stderr_string_exceptions << /invalid adc config/    # Case sensitive match

Similarly, if you find that the default of matching for ERROR in STDOUT messages is being overly aggressive, exceptions can be added in a similar way:

OrigenSim.error_string_exceptions << 'uninitialized value in ROM at'

This means that a log line resembling ERROR uninitialized value in ROM at 0x1000 will not fail the simulation, but the line ERROR uninitialized value in RAM at 0x2000 will fail.

On the other hand, if you find that simply matching for ERROR is not catching some cases which you would like to cause a FAIL, you can add additional strings to watch out for like this:

OrigenSim.error_strings << 'FAILED'

If you want to remove ‘ERROR’ from the list of error strings (in there by default), you can assign a new array instance:

OrigenSim.error_strings << 'FAILED'

OrigenSim.error_strings  # => ['ERROR', 'FAILED']

OrigenSim.error_strings = ['FAILED']

OrigenSim.error_strings  # => ['FAILED']

Similar variables exist to configure what you want to catch as a warning:

OrigenSim.warning_strings            # => ['WARNING']

OrigenSim.warning_string_exceptions  # => []

and also to match any output lines that you simply want to be shown in the console by default:

OrigenSim.log_string  # => []

It is conventional to do all such configuration like this with environment/sim.rb, where you can decide to make it global (applies to all targets), target-specific, or a combination of both:

# environment/sim.rb

# Will apply to all targets
OrigenSim.error_strings << 'FAILED'

case Origen.target.name

when "my_dut1"
  OrigenSim.cadence do |sim|
    # Configuration of Cadence simulator to be used for DUT1 here
  end

  # Known problem with this specific DUT only
  OrigenSim.error_string_exceptions << 'uninitialized value in ROM at'

when "my_dut2"
  OrigenSim.synopsys do |sim|
    # Configuration of Synopsys simulator to be used for DUT2 here
  end

# ...

Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license