Over the lifetime of this blog, we’ve covered a lot of diverse topics regarding Breker’s products and technology, trends in SoC verification, and the EDA industry in general. For the last month, we’ve offered our longest series of posts ever on a single topic: portable stimulus. There’s a very good reason for this: Accellera’s Portable Stimulus Working Group (PSWG) is making good progress on defining a standard in this area. As one of the group’s leaders, Breker has been leveraging our many years of experience in SoC verification to develop the best possible industry solution. We’ve been using The Breker Trekker blog to share our thoughts and to encourage your feedback.
We begin the fifth, and perhaps most important, post in our series by reminding you that we split portable stimulus into three layers: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios. We have shown over the last two posts that both the first and second layers can be defined easily by a simple application programming interface (API) providing access to a base-class library. This library includes the basic building blocks needed for a directed or automated test as well as scheduling control for processors, threads, and resources. It is natural to wonder whether the randomization layer can be handled in a similar way.
