You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • A Brief History of PSS at Breker

    Verification engineers are hearing a lot about the Portable Stimulus Standard (PSS), and for good reason because it could potentially save them time and effort in doing their jobs much better. In order to get the big picture on what PSS is all about I contacted Adnan Hamid, founder and CEO of Breker Verification Systems, because he's been involved with the formation of PSS since its inception.
    Article: A Comparison of SemiWiki and DeepChip-breker-min.jpg

    Q&A

    Q: How did you get started in high tech?

    In my college days I did AI programs and machine reasoning, joined AMD and started writing some tests. We used machine reasoning to create tests and it was wildly successful. Graph-based problem solving was a key.

    Q: How did Breker System get started?

    We started in 2003, using graph-based problem solving for creating test cases. It's been 5 years of self-funding primarily providing consulting services. Software sales started in 2007.

    Q: Who was one of your first customers?

    ST was an early customer, and we used a graph-based solution on top of the Specman tool which allowed us to verify complex IP quite well. They wanted to know if we could generate SW for tests on this IP.

    Q: When did the concept of PSS start to form?

    Microprocessor designs showed that using PSS was important, and we wrote portable stimulus since 2008 with ST and other customers.

    UVM was a good start, but we need more on top of this.


    Q: What makes PSS such a powerful verification approach?

    I think that there are three reasons:

    1) Abstraction - think about tests in a higher level as data and control flows.

    2) Portability/Reuse - same verification model for UVM level, full-chip, emulation, post-silicon. There's a reuse model across generations of products.

    3) Sharebility - encode UML activity diagrams and activities. Pictures explain the scenrarios. Architect, IP , integration, SW guys all communicate with the same pictures.


    Q: What type of engineer uses PSS the most on an SoC project?

    Mostly the verification engineers are attracted to PSS. The design guys write RTL first, then verification engineers sees if the spec is actually being met, and ask questions like, "Are all use cases met?"

    Q: What is your goal for PSS?

    That ultimately the PSS model becomes an executable specification.

    Q: How difficult is the learning curve for PSS?

    When learning PSS you get to choose either the C++ implementation or the new syntax DSL. At Breker we support both approaches. Some users say that DSL looks more like SystemVerilog and so that would be an easier transition for them.

    DSL is a fully declarative language and it's a new language, being more compact than C++, requiring fewer lines of typing.

    C++ is a fully scalable language that is well understood for many years now.

    An engineer at Intel said that 4 of 5 PSS stake holders use C++:

    1) UVM verification guy use DSL
    2) SOC integration, C++
    3) Emulation, C++
    4) Silicon bring up, C++
    5) Drivers, C++


    UVM tutorials have a few classes and constraints, but in real life there are classes with hundreds of lines of code.


    Q: What are the big challenge with SoC verification today?

    Verification challenges can be a big data problem with a huge search space, so we can have many use cases with too many sets. What are the most important tests to run and verify?

    The semiconductor industry has matured, efficiency is the focus now, so we need to turn verification into a process, PSS lets semi companies think about the process of verification. What is my device supposed to do, and have we tested for all of those things?

    Verification engineers write intent in PSS to the standard (front office), in the back office they use UVM, full chip simulation, emulation, silicon bring up (all tests run everywhere).

    We are capturing knowledge about IP that gets re-used with the PSS approach. There's no need to re-write tests throughout the process.

    The communication between two or more people on the same team, and how they work together is a big challenge. By using UML and data-flow diagrams we can make this communication easier.


    Q: What size is your company, Breker?

    At Breker we have 20 people in CA, East Coast, Bangalore and China.

    Q: Can you talk much about your customers?

    Sure, our public customers include: Broadcom, IBM, ST (past user), Cavium, NVIDIA, Altera (SNUG paper).

    Q: What can you tell me about the time savings when using a PSS approach for verification?

    I've heard one engineering group say that what used to take 10 people 9 months, now only requires 2 people in 6 months. Verification engineers used to spend 20% thinking about what to test and then 80% of the time on how to write the test. With PSS we can now spend 80% of the time on what to test, and then just 20% on how to test.

    PSS is certainly disruptive, because of this good time savings.

    Article: A Comparison of SemiWiki and DeepChip-breker-tool-flow-min.jpg

    Q: Why should IC engineering teams consider Breker for verification?

    At Breker we've been using graph-based verification since 2007, so that's 10 years of experience in this area.

    The learning curve with PSS is so fast that within a few days of being trained the verification engineers can start sharing graph snippets with peers to communicate their design intent.


    Q: What are your plans to grow the business at Breker?

    Our business plans at Breker are to continue growing the company organically.

    Positioning versus the competitors we see ourselves in the lead on PSS.


    Q: Where did your company name come from?

    In my MBA class during the self introductions I said that I brake things for a living, which then became my nickname of breaker, which became our company name - Breker.