No, the title is not a comparison of captions but a gist of
the discussions at UVM 1.2 day – a conference hosted by CVC Bangalore celebrating
their decade long journey. The day started with keynote from Vinay Shenoy, MD
Infineon Technologies India where he discussed the evolution of Indian industry
in the last 30+ years and why India is a role model for services but lags in manufacturing.
He also shared some rich insights into the Indian govt initiatives to bridge
this gap. Vikas Gautam, Senior Director, Verification Group, Synopsys delivered
the next keynote raising a question on the current state of verification and
what next after UVM? Later in the day, Anil Gupta, MD Applied Micro India in
his keynote discussed the growth of semiconductor industry emphasizing the need
for value creation and expectations from the verification team adopting UVM.
Pradeep captured the summary of these keynotes here – Vinay, Vikas and Anil. Further
to this, Dennis Brophy, Director of strategic business development, Mentor &
Vice Chairman, Accellera unleashed UVM1.2 inviting engineers to participate in
the open review before final release.
Begin with an end in mind
While the phenomenal adoption rate of UVM has alleviated
obvious worries, applying it effectively to address verification at various
levels is still challenging. Deploying UVM in absence of proper planning and a systematic
approach is a perfect recipe towards schedule abuse. This point was beautifully
comprehended by Anil Gupta referring to carpentry as a profession. UVM is a
toolset similar to hammer, chisel, lathe etc. found with every carpenter. Successful accomplishment
of the work depends upon a focussed effort towards the end goal. If a carpenter
is building a leg of a chair, he needs to concentrate on the leg in the context
of that specific chair. This ensures that when the chair is finally assembled it
comes into shape instantly. Ignoring this would otherwise lead to rework i.e.
delay in schedule while affecting the stability and longevity of the chair. Similarly,
while developing a UVM based environment, it is critical for the verification
engineer to define and build it at block level such that it integrates at the
sub system or SoC level seamlessly.
My 2 cents
Verification today demands a disciplined approach for marching
towards the end goal. To start with, the verification architecture document at
block level needs to address the reuse aspect of UVM components. Next is definition
of sequence item and config DBs, avoiding glue logic while knitting components at
block level and extending clear APIs to enable effective reuse. Performance of
the SoC test bench depends on the slowest component integrated. Memory and CPU
cycles consumed by entities need to be profiled, analyzed and corrected at block
level to weed out such bottlenecks. It is crucial to involve block level owners
to understand, discuss and debate the potential pitfalls when aiming to verify
a SoC that is nothing less than a beast. Breaking the end goal into milestones
that can be addressed at block level would ensure verification cycles at SoC
level are utilized efficiently. Early start on test bench integration for
subsystem/SoC level to enable flushing the flow and providing feedback to block
owners would be an added advantage.
Following is a 5 point rating scale for measuring overall
verification approach effectiveness particularly at IP level –
Remember to revisit this scale frequently while developing
the leg of the chair.... I mean any UVM based entity that is scheduled for
reuse further.... :)
Related articles –
From - Jonathan Zingman
ReplyDeleteSource - System Verilog user group - Linkedin
This is a good point, especially the table at the end. I see a lot of UVM-ish code - lines have "uvm" in them, but modularity and reusability are not emphasized. Effective hierarchies are not developed, leading to spaghetti UVM (the worst of both worlds!)
Better training and more experience in object-oriented development would help a lot. Making sure that everyone understands that there is no such thing as one-off code (always write for reuse) also is useful.
Unfortunately, most folks who bother to read this probably understand the issue already.
Jonathan,
ReplyDeleteThanks for sharing your thoughts.
Yes, today while we have a fantastic platform in form of UVM with a high adoption rate, the mode of adoption is not the best one leading to long time spent in integrating, debugging & worse simulating the code itself.
I do see some young readers raising their doubts on a direct mailer in regards to this post. That definitely is encouraging for all of us.