• 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

Miscellaneous

Logger


Origen provides an API for applications and plugins to log output data to the console and to files within the application’s log directory.

All log output is always written to the log files, whereas the console can be configured to increase or decrease the amount of log output that is displayed.

Log output is created by calling the following methods…

Information messages will always appear in the console unless it is set to silent:

Origen.log.info "This is an INFO message." 

Success, warning, and error messages are like information messages, except that they will be colored green, amber and red in the console respectively:

Origen.log.success "This is a SUCCESS message." 

Origen.log.warn "This is a WARNING message."  

Origen.log.error "This is an ERROR message."  

Finally, debug messages are like information messages, however they will only appear in the console when it is set to verbose mode:

Origen.log.debug "This is a DEBUG message."    

Deprecation Warnings

It is sometimes helpful to warn your users in advance if a feature they may be using is going to be removed in the future. Marking a feature for removal like this is called deprecating it, and a deprecation warning can be generated by using the following API:

Origen.deprecate "Feature X will be removed in the next release, please use Y instead"  

Note that the API is Origen.deprecate and not Origen.log.deprecate. While the latter may look like it works, the former is the correct way to call it and this will allow Origen to enhance your message by informing the user about where in their code they have invoked the deprecated API.

Changing the Console’s Verbosity Level

The console can be run with one of three verbosity levels: verbose, normal and silent. These levels only affect the output which appears in the console window, the log file will always capture everything regardless of the verbosity level.

You can enable verbose logging by adding the -verbose switch to your Origen command line:

origen compile templates/web/index.html.erb -verbose

To set the verbosity level to normal, you just run Origen commands without the -verbose option:

origen compile templates/web/index.html.erb 

To set the verbosity level to silent, run Origen commands with the -silent switch:

origen compile templates/web/index.html.erb -silent

When in silent mode, Origen will NOT output anything to the console window and will save everything to the log file only. This is intended to be used when other tools are invoking Origen rather than the user directly.

Time Tracking

Each log entry will look something like this:

[INFO]       0.506[0.474]    || Your helpful log message here

The type of the log message is obviously shown first, and this is then followed by a timestamp.

The first number shows the time in seconds since Origen was started, while the number in square brackets is the time since the last message was logged.

Log Files

All log output generated by an Origen invocation is saved to the file log/last.txt.

Every time Origen is invoked this file is saved to log/last.txt.old and then a fresh log is started, so you always have the output from the last two invocations of Origen available.

Additionally, the output that applies to a specific job is saved to job specific log files. Each test pattern, or program flow which is generated (or simulated) is an example of a job, as is each file that is compiled by Origen.

The console output will inform you of the location of the job specific files that are generated, as shown in this example:

[INFO]       0.005[0.005]    || **********************************************************************
[INFO]       0.031[0.026]    || Generating...  /home/stephen/Code/github/origen/spec/patterns/atp/nvm_j750_workout.atp
[INFO]       0.506[0.474]    ||
[INFO]       0.509[0.003]    || Pattern vectors: 146
[INFO]       0.511[0.003]    || Execution time : 0.019288
[INFO]       0.512[0.001]    || ----------------------------------------------------------------------
[INFO]       0.576[0.064]    || Log file written to: /home/stephen/Code/github/origen/log/pattern_generator/debug/j750_workout.txt
[INFO]       0.584[0.008]    || **********************************************************************
[SUCCESS]    0.584[0.001]    || Total patterns:   1
[SUCCESS]    0.585[0.001]    || Total vectors:    146
[SUCCESS]    0.586[0.001]    || Total duration:   0.019288
[SUCCESS]    0.587[0.001]    || New patterns:     0
[SUCCESS]    0.588[0.001]    || Changed patterns: 0
[INFO]       0.589[0.001]    ||
[INFO]       0.589[0.001]    || **********************************************************************

The location of the job-specific log files is: log/<job type>/<target>/<filename>.txt.

No old copy of job-specific log files is automatically maintained and these will be overwritten the next time Origen is asked to perform the same job.

Custom Log Files

Custom log files can be used to collect a specific type of data in one place.

Calling Origen.log.<my_log_name> in place of one of the standard message types will cause the given message to be logged to a custom file instead.

For example, these messages would be written to log/accesses.txt:

Origen.log.accesses "An access was made with this value: #{my_val}"

By default, such messages will be formatted as per standard Origen log messages, with the message type and timestamp appended to the front.

To output the message without this additional formatting being applied, add the format: false option:

Origen.log.accesses "An access was made with this value: #{my_val}", format: false

Custom log messages are never output to the console and will be captured in the applicable log file only.

One old copy of the file will be maintained in the same way as it is done for log/last.txt.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license