By Jose Villalobos
As System-on-Chip (SoC) architectures migrate toward more complex designs, like the Network-on-Chip (NoC) fabrics and multi-path access hierarchies, traditional UVM verification often becomes “path-locked”. This occurs when sequences are hardcoded to specific physical interfaces, creating brittle testbenches that are expensive to maintain and difficult to scale. On this article, we explore the usage of a “Global Routing Sequencer” architecture by decoupling logical transaction intent (the “what?”) from physical access paths (the “how?”).
This approach has helped Rydev significantly increase the verification ROI among our projects using enhanced sequence reusability and automated coverage of complex routing scenarios in the designs we’ve worked on and currently in production.
The bottleneck: The “path-coupling” problem:
In standard UVM environment, a sequence targeting a configuration register (CSR) usually must specify a uvm_reg_map. If such register is accessible via (let’s say) APB, AXI and a debug-port, then, the test writing engineer must cover all 3 (or more) versions of the sequence or include a complex branching logic, which comes at a business and engineering impact on:
- Maintenance debt: Changes to the SoC interconnect will require a corresponding update across the entire sequence library
- Verification gaps: Testing often tends to stick to the “primary” path, leaving secondary access paths unverified.
- Limited scalability: Testing replicated targets (i.e. multiple identical UART modules embedded on the same design) requires manual instance management rather than randomized distribution.
How we address it?
In our efforts to review, reinvent and test changes to our methodology aiming to increase speed of verification while keeping quality to its maximum level, we have been working with this concept of a Global Routing Architecture as a solution to this problem. The idea is to build an architecture that introduces a top-level “Global Sequencer” that sits above any protocol-specific agents (AXI, APB, etc.). This Global Sequencer behaves as a traffic controller for the entire UVM environment.
For this concept to work, we need to look at the Global Sequencer from 3 different angles:
- Abstract transaction layer: Instead of generating an “AXI Write” sequence, we produce an “abstract_transaction” object which contains only logical data: address, operation and data payload, along with optional configurable flags (or “hints” if you will) for the router.
- Routing engine: The heart of our system is a centralized logic block that decides the best path for a transaction based on given test constraints on every test to run.
- Supporting components: The other key components to this system are responsible to sustain the operation. Such blocks include:
- A global sequencer simplifies the top-level test writing and provides a central location for all abstract stimulus to be generated.
- A routing decision mechanism, so that the routing engine is directed to the physical path to test: random, round-robin or address-based, ensuring a 100% path coverage through randomization and critical paths to be tested according to plan.
- Results collector and correlator: A mechanism to match incoming hardware responses back to the original abstract sequence, ensuring data integrity across the different paths.
The value behind it:
We have observed efficiencies to our UVM process by using centralized sequences. This operates as an easy to port block, integrated into system-level environment with minimal modifications. As the sequence is now created agnostic to the physical path, it remains valid, whether the target is connected via a simple bus or a complex NoC.
Also, the centralization of the routing logic allows injection to system-wide scenarios (something really complex to achieve by manual coordination), and enabling special stress conditions such as:
- Congestion: Force multiple masters to use the same path in a simultaneous way.
- Diversification: Automatically toggle between primary and debug interfaces to ensure register coherency.
The idea also provides simplified multi-agent coordination, which comes handy in modern transaction systems where “sideband” signaling is required. So, instead of a sequence developed manually to manage multiple different agent handles, a global sequencer orchestrates all the sideband signals behind the scenes and reduces the lines of code required per test case by about 40%.
Use cases:
Thanks to this model, we have been able to test in full production in some interesting use cases such as a replicated target management in a symmetric multi-processing (SMP) cluster: In this case, the Global Sequencer performs the load-balance transactions across controllers, same as it could just specifically target “least recently used” instances to ensure verification is directed at desired goal (i.e. achieve certain coverage metric).
Other use case is the verification of a Crossbar: Here the engine can maintain a topology map and when a sequence requests to write to a given memory address, the engine randomizes the route through the Crossbar, exercising different switches and arbiters every time the test runs, increasing the efficiency and coverage through randomization at the higher level.
Conclusion: The use of centralized transaction routing is no longer an advanced luxury; it is a necessity for modern SoC verification. The creation of a Global Sequencer architecture in our team has shifted the burden of test coordination from manual complex work carefully crafted to meet the specifics of one UVM infrastructure into a more robust, dynamic and reusable verification component, which accelerates Time-To-Market not only on current, but on future projects as well.
About the author: Jose Villalobos is a verification engineer at Rydev. He holds an Electronics Engineering degree from TEC (Tecnológico de Costa Rica) with deep expertise in UVM environments.