QLogic Depends on Verification for First-time Silicon Success Tom Paulson QLogic Tom Paulson, principal engineer for QLogic’s system simulation in the Switch Products Group, talked to cdnusers about verification of complex chips. Tom has 30 years experience in hardware and software development. He has designed and developed hardware and firmware for products including high-speed processors and pacemakers. He holds a Bachelor of Science degree in Electrical Engineering from Marquette University. cdnusers: Please tell us something about QLogic. Tom: We create high-performance storage networking solutions, producing ASIC’s that are then used in our fabric switches. cdnusers: What is your methodology for block-level, chip-level and system-level verification? Tom: We have a very elaborate unit test plan that is written by the chief design engineer, with input from the design engineers. This is all direct testing requiring one or more testbenches for each designer. The design engineers are responsible for completing the unit test plan. Our chip-level and system-level testing methodologies are really the same. We do ASIC verification and feature testing at the system level with the complete chip. In some cases, we remove the serdes since it has a serial path and is tested more completely in the unit testing. Our system-level testing is all “black-box” testing with the results self-checked. We use Palladium for all our system level testing. This gives us the ability to test many features and combinations of features, more then we could do with a software simulator. cdnusers: What are your biggest verification challenges? Tom: Our biggest verification challenge is at the system level. Our designs have become very complex with many required features. These features are most often driven by marketing and become a requirement for the design. Our efforts are largely concentrated on running tests for individual features, and then combining features and running more tests. This type of testing not only finds end case problems in the design, but also problems created by interaction of features. cdnusers: How do you mitigate your risk and cost of failure? Tom: Cost of failure to us translates to the question: Can we achieve first-pass silicon? The failures we have seen in our silicon have been in one of two areas. One, a test case that we just did not think of—that is, why didn’t we think of that? And two, an end case that was very difficult to get to. This second area is where new verification technologies will help to identify this type of end case bug. cdnusers: How do you know when you are done with your verification process? Tom: We don’t know. In my thinking, there is always another test to run. We do have a system-level plan that is completed, but that only sets a time-certain for releasing the chip. It doesn’t really mean the verification process is complete. cdnusers: How successful are you with first-pass silicon? Tom: We have been successful with first-pass silicon for six chips. In a very few cases we have seen features that are not working exactly as we expected. We are trying to address these cases with system-level modeling. cdnusers: What bugs does Palladium help you find? Tom: This is a very good question for me, since I have been doing system-level testing on Palladium for the last five years. We are finding bugs that could not be found in unit testing. These are show-stopping bugs, and the designers are very appreciative that we are able to find them. In some cases, it is signal timing that produces the failure. In other cases, it is the interaction of features—or simply having the full chip in the testbench—that causes the failure. Palladium has provided us with the speed and flexibility to do all this testing. With Palladium, it takes only an hour from the time the engineer provides the design fix, to re-run the failing test case and verify the fix. This results in real time savings in the verification process. cdnusers: Do you have the right tools and horsepower to meet your verification needs? Tom: We do now, but that will change. We are going to require more horsepower in our verification process. This is because designs are getting more and more complex; the 65 nm silicon allows for very large designs on a single chip. One of our biggest challenges is how to characterize our design and then apply the right verification technology to each part of the design. This includes all the current technologies such as assertions, formal, test languages, accelerators and others. The trick will be applying the right technology to the right part of the chip. In the end, we will be asked to do more verification, in the same amount of time, for a more complex chip. cdnusers: How are you going to accomplish verification in the future assuming that your resources are fixed and the complexity is increasing? Tom: Again, we have to work smarter and make sure we have the technologies that will address the end-case bugs that could cause a re-spin. Also, remember, even if we are able to do a work around for a bug in our silicon that allows us to avoid a re-spin, we still have costs in time and money at the end. Summary About the author Tom Paulson has worked in the technology industry for 30 years in hardware and software development. He has designed and developed hardware and firmware for products including high-speed processors and pacemakers. He has also worked as an application engineer for a co-verification product supporting customers and developing Bus Functional Models. Tom currently works for QLogic as the lead engineer for system simulation in the Switch Products Group. He also evaluates and recommends products used in the verification process. Tom continually works to improve the development and verification processes for ASICs developed in the Switch Products Group. Tom holds a Bachelor of Science degree in Electrical Engineering from Marquette University. Ratings   This content has not yet been rated by other users   Comments