The Verification Challenge
Our SoC incorporated an SPI EEPROM device that had already been thoroughly verified by an offsite team. We had a golden RTL model of this EEPROM, but for SoC-level verification efficiency, we needed a UVM-based model (UVC) that could be more easily controlled and integrated into our verification environment.
The project had a unique advantage: since we had a pre-verified RTL model, I could validate my UVM implementation against it, providing high confidence in the UVC’s correctness before deploying it in the larger SoC verification environment.
The Three-Phase Approach
I structured the project in three phases to ensure a smooth transition from RTL to UVM modeling:
Phase 1: Testbench for RTL Model
First, I developed a UVM testbench targeting the existing RTL EEPROM model. This allowed me to:
- Verify my understanding of the EEPROM protocol
- Develop sequences that exercised all device functionality
- Create a scoreboard that validated expected device behavior
- Establish a reference point for the UVM model development
Since the RTL model was already verified, any issues discovered during this phase would likely be in my testbench , helping to debug my verification approach before moving to UVM modeling.
Phase 2: Reactive Slave UVC Development
With a working testbench in place, I developed a UVM-based EEPROM model that replicated the behavior of the RTL. Following the architecture outlined in “Mastering Reactive Slaves in UVM,” I implemented a reactive component that could respond correctly to SPI commands at unpredictable times.
The paper’s recommendations for TLM communication between monitor and sequencer, forever sequences, and memory modeling proved invaluable in creating a robust implementation that behaved identically to the RTL device.
Phase 3: SoC Integration
The final phase involved replacing the RTL EEPROM model with my UVC in the SoC verification environment. This required coordination with team mates to establish proper connections and ensure the UVC could be configured to meet various test requirements and device flavours at the system level.
Reactive Slave Architecture
The reactive slave architecture, based on the recommended patterns from “Mastering Reactive Slaves in UVM,” had several key components:
Protocol-Accurate Monitor
The monitor watched the SPI interface and decoded commands exactly as the real device would, publishing request information to other components through TLM connections as suggested in the paper.
Request-Response Mechanism
Following the paper’s guidance, I implemented a specialized communication path connecting the monitor to a sequencer running a “forever sequence.” This architecture allowed the sequence to wait for requests and generate appropriate responses based on internal state.
Memory Model
The paper’s recommendations for integrating storage into reactive slaves guided my implementation of an internal model that maintained the EEPROM’s memory contents and status register, enforcing all the rules implemented in the RTL.
Error Injection Capabilities
Using the error injection mechanisms described in the paper, I added capabilities to simulate various error conditions, enhancing the testability of our SPI controller.
Results and Impact
The project delivered significant value to our verification efforts:
Enhanced Controllability
The UVC provided much greater control over the EEPROM behavior in system-level tests, allowing error injection and corner case testing that was difficult with the RTL model.
Reusable Component
The EEPROM UVC became a reusable verification component across multiple projects, providing consistent behavior without the overhead of an RTL model.
Lessons Learned
Several valuable lessons emerged from this project:
Reference Model Value
Having a pre-verified reference model dramatically improved confidence in the UVC implementation and shortened the development cycle.
Value of Industry Best Practices
Following the architectural patterns described in “Mastering Reactive Slaves in UVM” saved considerable development time and helped avoid common pitfalls in reactive slave implementation.
Communication Architecture
The paper’s emphasis on clean separation between monitoring, sequence generation, and driving proved essential for creating a maintainable and flexible component.
Conclusion
Developing a UVM model to replace a pre-verified RTL EEPROM device presented an interesting verification challenge. By combining the guidance from “Mastering Reactive Slaves in UVM” with validation against the existing RTL, I created a high-quality UVC that seamlessly integrated into our SoC verification environment.
This project demonstrated both the value of industry best practices for verification architecture and the importance of a phased approach when transitioning from RTL to UVM-based modeling. The resulting UVC improved our verification efficiency while maintaining the behavioral fidelity of the original device model.
