Breker Graphic

TrekSoC Services

TrekSoC provides a framework of scenario models that are used to generate C test cases. Each test case takes the form of a randomized micro-kernel running applications that drive individual hardware devices to verify possible system interactions.

TrekSoC Services

Scenario models may request system services that are provided by TrekSoC. The key services available to scenario models include:

TrekSoC Services Features
Memory Management

Allocates/frees memory buffers on demand

  • Allocated addresses are randomized
  • Address randomization biased towards creating cache line collisions to test cache coherency
  • Allocation biased towards partial reuse of recently freed buffers to test data ordering
  • Virtual page tables are handled
Register Access

Allows scenario models to request randomization, writing and checking of register value

  • Support register connectivity testing
Scheduler

Enables tasks to be flexibly scheduled sequentially

  • Within a thread (threads may be on the same processor or distributed across multiple processors)
  • Across multiple threads to create producer/consumer scenarios
Interrupts and Polls

Automatically generates interrupt handlers and non-blocking poll loops

System Management

Randomly switches clocking and power modes (scenario models may ask for a specific device to be powered up for the duration of an operation, possibly allowing for intermittent power downs during the operation to test state retention)

Testbench Actions

Allows scenario models to request arbitrary testbench activity to drive and check I/O interfaces or other testbench events

GPIO

Allows scenario models to request specific system GPIO routings

Debug Facilities

Allows scenario models to log various levels of diagnostic messages through automatic generation of diagnostics on thread progress and memory state

Data Checking

Allows scenario models to request checking of memory data buffers against an array of expected data

Timing Checks

Allows scenario models to request checking that the elapsed time between two events falls within a specified range; timing checks may be implemented using either elapsed simulation time or, if available, an onboard timer