Feature Request: Immediate Interrupt Processing for CoSimulation (Bypass limitBuffer)

[eveneihans]

Feature Request: Immediate Interrupt Processing for CoSimulation (Bypass limitBuffer)

Problem Statement

When using Renode's CoSimulation with HDL simulators (Questa/ModelSim), interrupts sent via the async socket are delayed by the limitBuffer time synchronization parameter. This creates significant latency for interrupt-driven applications.

Current Behavior

• Interrupts are sent from HDL via renode_inputs.sv using send_to_async_receiver()
• Messages arrive at Renode's async socket immediately
• However, Renode only reads/processes the async socket when the LimitTimer fires (every limitBuffer nanoseconds)
• Result: Interrupt latency = limitBuffer value (typically 1,000,000 ns = 1 ms)

Use Case

We have a multi-CPU system where:

• UART/bus transactions need large limitBuffer (e.g., 1,000,000 ns) for stable logging
• Interrupts need immediate processing (<50 ns) for real-time responsiveness

Currently, we must choose between:

1. Large limitBuffer → stable UART, but 1ms interrupt latency ❌
2. Small limitBuffer (e.g., 100 ns) → fast interrupts, but requires careful tuning ⚠️

Desired Behavior

Add support for immediate interrupt processing that bypasses limitBuffer synchronization, while keeping bus transactions synchronized normally.

Ideally via a configuration option like:

emulation ConnectToCoSimulation "miv" "my_connection" \
    address="127.0.0.1" \
    limitBuffer=1000000 \
    immediateInterrupts=true  # New parameter

Or per-peripheral:

cosimAXI : CoSimulated.CoSimulatedPeripheral @ sysbus <0x70000000, +0x0fffffff>
    immediateInterrupts: true  # New property
    cosimToRenodeSignalRange: <0,+3>
    [0,1,2] -> cpu@[24,27,28]

Technical Details

Why Current Architecture Delays Interrupts

1. Async socket exists and is used correctly:

   • HDL sends interrupts via sendSender() to async socket
   • Interrupts use ActionType.interrupt
   • cosimToRenodeSignalRange properly maps signals

2. But processing is gated by LimitTimer:

   timer.LimitReached += () =>
   {
       // THIS is when async messages are processed
       // Happens every limitBuffer nanoseconds
   };

3. Documentation states: "asynchronous events are delivered in the synchronization phase automatically"

   • This is correct, but "synchronization phase" = limitBuffer interval
   • Not truly "asynchronous" from user perspective

Proposed Implementation Approach

A safe implementation would need to:

1. Single consumer pattern: Modify existing SocketConnection.ReceiveLoop() to classify messages
2. Event queue: Don't process GPIO directly; queue interrupt events
3. Safe delivery: Let Renode's main emulation thread apply GPIO changes (thread-safe)
4. Always ACK: Send acknowledgments immediately to avoid protocol deadlock
5. Optional feature: Only enable when immediateInterrupts=true to maintain backward compatibility

Critical requirements:

• Single thread reading async socket (avoid race conditions)
• Queue-based approach (avoid thread safety violations)
• Proper ACK handling (avoid protocol deadlock)

Workaround

Current working solution:

limitBuffer=100  # 100ns interrupt latency - acceptable for most cases

This works but:

• Requires tuning per system
• May need adjustment when adding more peripherals
• Not ideal for systems requiring both stable UART and <1µs interrupt latency
• Often introduces freezing of the HDL simulator

Environment

• Renode version: 1.16
• HDL Simulator: Questa/ModelSim
• Connection type: Socket-based CoSimulation
• Use case: Multi-CPU embedded system with interrupt-driven peripherals

Related Documentation

• [Time Framework](https://renode.readthedocs.io/en/latest/advanced/time_framework.html) - "time synchronization only applies to bus transactions"
• [CoSimulation Tutorial](https://renode.readthedocs.io/en/latest/tutorials/co-simulating-custom-hdl.html)
• Integration Library: renode_inputs.sv uses async socket correctly

Questions

1. Is this a known limitation?
2. Are there plans to support immediate interrupts in a future release?
3. Would you accept a pull request implementing this feature?
4. Are there alternative approaches we should consider?

Impact

This feature would enable:

• ✅ Real-time interrupt response in co-simulated systems
• ✅ Better match between HDL simulation and real hardware behavior
• ✅ Use of Renode for interrupt-critical applications
• ✅ Maintain stable bus/UART with large limitBuffer while having fast interrupts

Thank you for considering this feature request! Renode is an excellent tool and this enhancement would significantly expand its applicability for real-time embedded systems.