In this lab, we demonstrate how to automate simulations in Sci‐Compiler using register scripting . We focus on a Trigger LE Hyst block whose threshold is driven by a programmable register. A Counter increments only when the input signal exceeds the threshold. By dynamically changing the threshold (via a simple VB‐style script), we can perform a threshold scan to observe how the counter behaves at different threshold levels.


1. Block Diagram

Below is the block diagram showing the main components:

Block Diagram
Block Diagram

[Figure: A0 is the analog input. A register (REG) feeds the THRESHOLD pin of the Trigger LE Hyst block. The trigger output goes to a Counter Rising block, which increments only when the input surpasses the threshold.]

  1. Analog In Pin (A0): Receives the simulated pulse train from the Detector Emulator.
  2. REG (named “THRESHOLD”): A 16‐bit register whose value we’ll update via a script.
  3. Trigger LE Hyst: Triggers when A0 exceeds the threshold. It also has a small DELTA for hysteresis.
  4. Counter Rising: Increments on each rising edge of the trigger output. The final count is shown via a simulation probe (P_CNT).

2. Configuring the Detector Emulator

We replace the analog input A0 with a Detector Emulator stimulus. Below is a zoom of the long signal generated by the emulator:

Zoom of Detector Emulator Signal
Zoom of Detector Emulator Signal

[Figure: A snippet of the time‐varying amplitude from the Detector Emulator. It generates random pulses with a chosen distribution, rate, amplitude, and noise.]

From the emulator settings (visible in the screenshot), we see parameters such as:

  • Mode: Detector Emulator
  • Event Distribution: Poisson or Fixed Rate (depending on the test)
  • Event Rate: For instance, 200 kHz or 500 kHz (as set in the screenshot)
  • Amplitude (ADC): e.g., 700–800 range
  • Noise: can be added or set to zero for a cleaner test. We set 15
  • Rise Time / Tau: controls how fast the pulse rises and decays

This configuration provides a continuous stream of pulses of varying amplitude, so that changing the threshold will affect whether the trigger fires and increments the counter.


3. Scripting with Registers

We now define a register named “THRESHOLD” and attach it to the THRESHOLD pin of the Trigger LE Hyst block. Next, we create a VB‐style script to sweep that threshold from 400 to 800 in steps of 10, pausing 20 µs between each change.

Opening the “Registers” Tab

  1. In the Simulation Input dialog, click on the Registers tab.
  2. Enter the script in the text editor:
InitRegister("THRESHOLD",400)
for i = 400 to 800 step 10
    SetRegister("THRESHOLD", i)
    wait_us(20, true)
next

We forget to declare dim i, you’ll see a compile error:

Script Window & Error
Script Window & Error

[Figure: The script with a missing dim i declaration. Compilation fails with an error message. Once fixed, the script compiles successfully.]

Script Window & Error
Script Window & Error

Look at main window, Compiler output to see the error

Script Window & Error
Script Window & Error

Fix the code by adding dim i:

InitRegister("THRESHOLD",400)
dim i
for i = 400 to 800 step 10
    SetRegister("THRESHOLD", i)
    wait_us(20, true)
next

Script Window & Error
Script Window & Error

[Figure: The corrected script with dim i. Without this declaration, compilation fails. Once fixed, the script compiles successfully.]

  • InitRegister(“THRESHOLD”, 400): Initializes the register to 400.
  • for i = 400 to 800 step 10: Steps i in increments of 10.
  • SetRegister(“THRESHOLD”, i): Updates the threshold.
  • wait_us(20, true): Wait 20 µs of simulation time before the next step.

Compiling the Script

  • Click Compile Script.
  • On success, you’ll see “Successfully compilation!” in the log.
  • Any syntax errors appear in the console output.

4. Running the Simulation

  1. Set Simulation Length: For example, 5000 µs.

Start simulation
Start simulation

  1. Menu → Simulation → Run Simulation.
  2. Sci‐Compiler launches the underlying simulator (Vivado).
  3. After completion, you get “Successfully compilation!” or similar.

During the run, the threshold register will automatically update from 400 → 800 in steps of 10, each step lasting 20 µs, so the entire script covers about ((800 - 400) / 10 \times 20,\mu\text{s} = 800,\mu\text{s}) plus overhead.


5. Observing the Results in GTKWave

When the simulation finishes, open GTKWave to see the signals:

GTKWave Result
GTKWave Result

[Figure: The green trace is the input signal on A0. The threshold register s_REG_THRESHOLD_TR changes in steps over time, and the counter P_CNT increments only when A0 surpasses the current threshold.]

Key Observations

  • Below Baseline (400–550): The signal amplitude is always above 460, so the trigger never fires.

  • Low Threshold (460–510): The signal amplitude is often above 460, so the trigger fires frequently, and the counter increments rapidly. Even due to the noise

  • Intermediate Threshold: The counter increments at a nominal signal rate.

    GTKWave Result
    GTKWave Result

  • High Threshold (near 800): The input rarely exceeds 800, so the counter remains constant or increments very slowly. If you zoom in on the waveforms, you’ll see:

    GTKWave Result
    GTKWave Result

  • s_REG_THRESHOLD_TR[31:0] stepping up in discrete intervals.

  • A0[15:0] with random pulses.

  • P_CNT[31:0] increasing only when A0 > threshold.


Conclusion

In Lab 2, we combined:

  1. A Detector Emulator generating random pulses.
  2. A Trigger LE Hyst block with a threshold input from a user‐defined register.
  3. A Visual Basic–style script to sweep the threshold across a range in small steps.
  4. A Counter that increments when the signal surpasses the threshold.

This approach demonstrates how to automate simulations in Sci‐Compiler:

  • By writing scripts to manipulate registers, we can explore a wide range of operating points (e.g., threshold scans).
  • We can confirm correct operation of triggers, counters, and the effect of different threshold settings in a single run.

Thus, scripting in the Registers tab is a powerful way to run parametric tests or advanced verification tasks before implementing the design in hardware.