Which HVL do you use for verification? Which methodology do you follow? Which power format does your team use? Do these questions sound familiar?
No, these aren’t interview questions. These are the conversation starters of verification world!
Last few years have witnessed maximum activity in the verification space. Every EDA company was busy gearing up to propose a solution in different areas. Verification being touted as the most resource consuming activity has been a darling of the EDA community. With so much action in this space, the engineers are left in a confused state.
The options available in various verification categories include –
HVL – e (IEEE 1647), System Verilog (IEEE 1800), Vera (Open source).
Methodology [MET] – eRM (e), RVM (Vera), AVM, URM, VMM, OVM, UVM.
Power Format [PF] – CPF, UPF (IEEE 1801).
The alternatives listed above have witnessed a full course of evolution before wide acceptance. The choice still depends on the marketing strategy, sales pitch and the final deal!!! From launch of a solution to becoming an industry standard it’s a long road to survival. During this process the verification teams spoiled for choices experience multiple challenges. A few of them include –
- For SOC development, getting third party IP is inevitable. If the Verification environment accompanying the IP is in a different HVL/ MET/ PF then integration becomes an issue.
- Choice of verification environment for IP vendors becomes critical too. Wrong choice on the above categories can even put them out of the race with some customers.
- ASIC flow involves tools from multiple vendors. A Power Format supported by verification tools might not work with implementation tools thereby adding inefficiencies in flow.
- Integrating tools from multiple vendors for verification (through PLIs etc.) may lead to long iterations (delaying schedule) in tool debug if unusual behavior is encountered.
- Given multiple options (above), hiring engineers with required skill set or training them as desired, further delays the productivity.
If having alternatives is the root cause of these issues why do we have them?
Well, to solve the next level engineering challenges, we need to make sure the solutions to the present ones are mature enough. As designs kept unfolding new problems, answers to them are made available by EDA vendors. To get a stable solution either we brainstorm together (unusual in competitive world) or each one brings up a solution and the better one is chosen when standardizing. Multiple designs, multiple engineers and multiple customers work towards making the solution robust and mature. While the EDA vendors are busy wooing customers they continue untiring efforts in order to get their proposal become an industry standard. When the industry moves to next level of design complexity, the war for defining a standard becomes a need. The ‘war’ that was, feeds to bring up a standard that makes process simpler and sets the stage to solve the next engineering challenge.
No doubt this WAR ends up in a HEALTHY outcome!
No comments:
Post a Comment