Indian Railways and SoCs

Last week I woke up late as usual and decided to flip through the news paper on Coffee to enjoy the lazy Sunday morning, but I ended up reading a sad news about a train accident. Everyday virtually we hear about minimum one accident. Indian Railways, wow, what a reliable transportation system we have built. It clearly indicates we have to learn how to plan meticulously before jumping into execution.

I was not really surprised when Harry Foster at DVCon mentioned “Average number of Chip respins in India is more than any other countries, though we are the best in adopting latest verification methodologies”. In my imagination, Indian railways which has been built over the legacy British railways system reflects the structure and complexity of an SoC which is built using legacy chips and IPs. Although our SoCs don’t crash like our Indian railways, still we need to improve our project planning and execution to achieve First-Time-Pass.

‘First Time Silicon Pass’ pretty much depends on how you plan the whole project execution, especially the RTL verification. So as a verification consultant I would like to explain the project planning from a verification perspective.

Team – Are they skilled enough to do their job?
Build the team with right resources and train them on the technologies and methodologies which are relevant to the project. Also implement a process to identify their readiness with respect to spec understanding and skills. Everyone doesn’t need to know everything. Experienced engineers will implement TB infrastructure and mid level engineers will write only Testcases and coverage models and junior engineers will monitor and automate the regression. For example mid level and junior engineers must be skilled enough to use EDA tools to debug the simulation failures.

Project manager/TB Architect – Have they understood the methodology properly and perfected their approach?
In my consultancy experience what I have identified is that most of the project managers are traditional verification folks who have limited understanding of latest methodologies like constrained random verification. So they end up mixing traditional approaches with latest methodologies. I have seen them using UVM/OVM with traditional test plans. There is a huge difference between test plan and Vplan. In UVM/OVM, we do not think about test cases while creating the Vplan. Similarly sometimes experienced verification engineers who are new to SystemVerilog end up writing lot of directed test cases by narrowing the constraint range to specific conditions.

TB Architect – Has he considered his customer?
Architect the test bench infrastructure in such a way that it can be reusable with any technology at any level [IP/Chip/SoC verification on Simulation/Formal/Emulation]. Also your VIP should be able to accommodate the spec and design changes at any time in the future. Always try to simplify the user interface, aiming towards making your VIP as a push button type [ON & OFF] verification component. Write necessary scripts to automate the regression and report generation.

Finally I would say, ‘Make it simple’. That’s what your customer wants. He does not want to go through thousand pages of your user manual just to understand how to use your VIP. Most importantly, he doesn’t want to miss the tape out debugging and fixing your VIP functional bugs. So you need to be creative enough to invent a methodology/flow too to verify your VIP, as a competent Project Manager.