Guaranteeing the reliability and efficiency of complicated digital programs has two elementary points: useful verification and digital design. Digital Design predominantly focuses on the structure of the system that entails logic blocks, management circulate items, and information circulate items. Nevertheless, design alone shouldn’t be sufficient.
Useful verification performs a important function in confirming if the design (digital system) behaves as supposed in all anticipated circumstances. It entails writing testbenches and operating simulations that take a look at the performance of the design and catch bugs as early as doable. With out correct verification, even probably the most well-designed system can fail in actual world use.
Protection is a set of metrics/standards that determines how completely a design has been exercised throughout a simulation. It identifies and checks if all required enter mixtures have been exercised within the design.
There are a number of kinds of protection utilized in trendy verification flows, the primary one being code protection, which analyzes the precise executed code and its branches within the design. Useful protection, alternatively, is user-defined and assessments the performance of the design primarily based on the specification and the take a look at plan.
Protection closure is an important step within the verification cycle. This step ensures that the design is powerful and has been examined completely. With a rise in scale and complexity of recent SoC/IP architectures, the processes required to realize protection closure change into considerably tough, time-consuming, and useful resource intensive.
Conventional verification entails a excessive diploma of handbook intervention, particularly if the design is continually evolving. This makes the verification cycle recursive, inefficient, and susceptible to human errors. Guide intervention in protection closure stays a persistent problem when coping with complicated subsystems and enormous SoCs.
Automation isn’t just a solution to pace up the verification cycle; it provides us the bandwidth to give attention to fixing strategic design issues reasonably than repeating the identical duties again and again. This analysis relies on the identical thought; it turns protection closure from a tedious process to a targeted, strategic a part of the verification cycle.
This paper focuses on leveraging automation supplied by the Cadence Incisive Metric Middle (IMC) software to reduce the necessity for handbook effort within the protection closure course of. With the assistance of configurable instructions within the Protection Configuration File (CCF), we are able to train high-quality management in protection evaluation, decreasing the probabilities of handbook changes and making the circulate dynamic.
Overview of Cadence IMC software
IMC stands for Incisive Metrics Middle, which is a protection evaluation software designed by Cadence to assist design and verification engineers consider the completeness of verification efforts. It really works throughout the design and testbench throughout simulation to gather protection information saved in a database. This database is later analyzed to determine the areas of design which have been examined and people which haven’t met the specified protection objectives.
IMC makes use of effectively outlined metrics or instructions for each code and useful protection, which offer an in depth view of protection outcomes and determine any gaps to enhance testing. The applying contains the creation of a user-defined file referred to as CCF, which incorporates these instructions to regulate the kind of protection information that needs to be collected, excluded, or refined.
This paper affords a number of instructions—comparable to “select_coverage”, “deselect_coverage”, “set_com”,”set_fsm_arc_scoring” and “set_fsm_reset_scoring”—which deal with totally different genres of protection points. The “select_coverage” and “deselect_coverage” instructions automate the inclusion and exclusion exercise by deciding on particular sections of code as per the requirement, thus eliminating the handbook exclusion course of.
The “set_com” command gives a easy strategy to keep away from the handbook efforts by mechanically excluding protection for fixed variables. In the meantime, the “set_fsm_arc_scoring” and “set_fsm_reset_scoring” instructions focus extra on enhancement of finite state machine (FSM) protection by figuring out state and reset transitions for the FSMs current within the design.
By utilizing this exact and command-driven strategy, the methods mentioned on this paper enhance productiveness and protection accuracy. That performs an important function in right this moment’s fast-paced complicated chip growth cycles.
Choosing/deselecting modules and covergroups for protection evaluation
The RTL design is a hierarchical construction which consists of varied design items like modules, packages, situations, interfaces, and program blocks. It may be a mystifying train to exclude a selected code protection part (block, expr, toggle, fsm) for the assorted design items in IMC software.
The train to pick/deselect any design items for code protection will be carried out in a clear method by utilizing the instructions talked about under. These instructions additionally present help to pick/deselect any particular covergroups (inside lessons).
- deselect_coverage
The command can allow the code protection sort (block, expr, toggle, fsm) for the given design unit and may also allow covergroups that are current within the given class.
Syntax:
select_coverage <-metrics> [-module | -instance | -class] <list_of_module/occasion/class>
Determine 1 The above snapshot exhibits an instance of select_coverage command. Supply: eInfochips
This command is to be handed in CCF with the suitable set of switches; <-metrics> defines the kind of protection metric like block, expr, toggle, fsm, and covergroup. In line with the protection metric, -module or -instance or -class is handed after which the listing of module/occasion/class is to be talked about.
- deselect_coverage
The command can disable the code protection sort (block, expr, toggle, fsm) for the given design unit or can disable covergroups that are current within the given class.
Syntax:
deselect_coverage <-metrics> [-module | -instance | -class] <list_of_module/occasion/class>
Determine 2 This snapshot highlights how deselect_coverage command works. Supply: eInfochips
The mix of those two instructions can be utilized to regulate/handle a number of kinds of code protection metrics scoring all through the design hierarchy, as proven in Determine 4, and useful protection (covergroup) scoring all through the testbench setting, as proven in Determine 7.
The design has hierarchical construction of modules, sub-modules, and situations (Determine 3). Right here, no instructions in CCF are supplied and the code protection scoring for all of the design items is enabled, as proven within the determine under.
Determine 3 Code protection scoring is proven with out CCF Instructions. Supply: eInfochips
For instance, allow us to assume code protection (block, expr, toggle) scoring in ‘ctrl_handler’ module shouldn’t be required and block protection scoring in ‘memory_2’ occasion can also be not required; then in CCF, the deselect_coverage instructions talked about in Determine 4 might be used. To deselect all of the code protection metrics (block, expr, fsm, toggle), ‘-all’ choice is used. Determine 4 additionally depicts the end result of the instructions used for disabling the assumed protection.
Determine 4 Code protection scoring is proven with deselect_coverage CCF instructions. Supply: eInfochips
In one other state of affairs, the code protection scoring is required for the ‘design_top’ module, and the toggle protection scoring is required for the ‘memory_3’ occasion. Code protection for the remainder of the design items shouldn’t be required. So, the entire design hierarchy might be de-selected and solely the 2 design items by which the code protection scoring is required are chosen, as proven in Determine 5. The code protection scoring generated as per the CCF instructions can also be proven in Determine 5.
Determine 5 Code protection scoring is proven with deselect_coverage/select_coverage CCF instructions. Supply: eInfochips
The 2 covergroups (cg1, cg2) in school ‘tb_func_class ’ are scored when no instructions in CCF are talked about, as proven in Determine 6. In case useful protection scoring of ‘cg2’ covergroup shouldn’t be required, the CCF command talked about in Determine 7 is used. For de-selecting any particular covergroup in a category, the ‘-cg_name’ <covergroup identify> choice is used
Determine 6 Useful verification is carried out with out CCF command. Supply: eInfochips
Determine 7 Useful verification is carried out with CCF command. Supply: eInfochips
It’s essential to notice that each instructions ‘select_coverage/deselect_coverage’ can have a cumulative impact on the protection evaluation. In <metrics> sub-option, ‘-all’ will embrace all of the code protection metrics (block, expr, toggle, fsm) however is not going to embrace -covergroup metric.
Within the closing evaluation, by utilizing the ‘select_coverage/deselect_coverage’ instructions, code/useful protection within the design hierarchy and from the testbench setting will be enabled and disabled from the CCF immediately, which makes the protection circulate neat. If these instructions will not be used, to acquire the same impact, handbook exclusions from design hierarchy and testbench setting should be carried out within the IMC software.
Sensible exclusions of constants in a design
In lots of initiatives, there are some alerts or codes of a design that aren’t exercised all through the simulation. Such alerts or codes of design create pointless gaps within the protection database. To manually add the exclusion of such fixed objects in all of the modules/situations of design is an exhausting job.
Cadence IMC gives a command which neatly identifies the fixed objects within the design and ignores them from the protection database. It’s described under.
set_com
When the set_com command is enabled within the CCF, it identifies the protection gadgets comparable to an inactive block, the fixed alerts, and fixed expressions, which stay unexercised all through the simulation; it omits them from protection evaluation and marks them IGN within the output generated file.
Syntax:
set_com [-on|-off] [<coverages>] [-log | -logreuse] [-nounconnect] [-module | -instance]
To allow the Fixed Object Marking (COM) evaluation, present the [- on] choice with the set_com command. When the COM evaluation is completed, the IMC generates an output file named “icc.com” which captures all of the objects which can be marked as fixed.
By offering the [-log] choice, it creates the icc.com file and ensures that the icc.com is up to date every time for all of the simulations. This icc.com file is created within the path “cov_work/scope/take a look at/icc.com.” The COM evaluation for particular module/occasion is enabled by offering the [-module | -instance] choice with the set_com command.
Determine 8 The above picture depicts the design hierarchy. Supply: eInfochips
Determine 9 The COM evaluation command is proven as talked about in CCF. Supply: eInfochips
Contemplate that the “chip_da” variable of the design stays fixed all through the simulation. By enabling the set_com command as proven in Determine 9, the variable chip_da might be ignored from the protection database, which is proven in Determine 10 and Determine 11.
Determine 10 The icc.com output file is proven within the protection database. Supply: eInfochips
Determine 11 Fixed variable chip_da is ignored with set_com command enabled. Supply: eInfochips
COM evaluation
Within the CCF, the set_com command is enabled for the addr_handler_instance1 occasion.
- Right here, because the set_com command is enabled, the “chip_da” sign, which stays fixed all through the simulation, might be ignored from protection evaluation for the outlined situations. As proven in Determine 10, in each submodule the place the chip_da sign is handed, it will get ignored because the chip_da sign is the port sign, and the COM evaluation is completed primarily based on the connectivity (top-down/bottom-up).
- Together with the port alerts, the interior alerts which stay fixed, are additionally ignored from the protection database. In Determine 10, the “wr” sign is an inner sign and it’s ignored from the protection database (additionally mirrored in Determine 11).
- The sign chip_da is fixed for this simulation (which is IGN) whereas if chip_da is variable for another simulation (which is roofed/uncovered) and these two simulations are merged. Then the sign chip_da might be thought of as a variable (lined/uncovered) and never an ignored fixed.
It’s price noting that when the set_com command is enabled for a module/occasion, and if the sign is port sign and is marked as IGN, then the port alerts of different sub-modules, that are immediately related to this sign, are additionally IGN regardless of the command enabled for that module/occasion.
Lastly, to keep away from the pointless protection that’s captured for fixed objects and to avoid wasting time in including exclusion for such fixed objects, the set_com command is extraordinarily helpful.
Detailed evaluation of FSM protection
A coverage-driven verification strategy provides assurance that the design is exercised completely. For the FSM-based design, there are a number of kinds of protection evaluation out there. FSM state and transition protection evaluation are the 2 ways in which assist to carry out the coverage-driven verification of FSM designs, nevertheless it’s not a whole verification of FSM designs.
FSM arc protection gives a complete evaluation to make sure that the design is exercised completely. To try this, Cadence IMC gives some CCF instructions, that are described under.
set_fsm_arc_scoring
The FSM arc protection is disabled by default in ICC. It may be enabled by utilizing the set_fsm_arc_scoring command within the CCF. The set_fsm_arc_scoring allows the FSM arcs, that are nothing however all of the doable enter circumstances for which transitions happen between the 2 FSM states.
Syntax:
set_fsm_arc_scoring [-on|-off] [ -module <modules> | -tag <tags>] [-no_delay_check]
To allow the FSM arc protection, present the [-on] choice within the set_fsm_arc_scoring. The FSM arc protection will be encompassed for all of the FSMs outlined in a module by offering the [-module <module_name>] choice.
If the FSM arc protection must be captured for particular FSM within the module, it may be achieved by offering the tag identify to FSM utilizing the set_fsm_attribute command within the CCF. By offering tag identify choice with set_fsm_arc_scoring, FSM arc protection will be captured for the FSM in design.
set_fsm_reset_scoring
A state is taken into account a reset state if the transition to that state shouldn’t be depending on the present state of the FSM; for instance, within the code proven under.
Determine 12 Right here is an instance of a reset state. Supply: eInfochips
State “Zero” is a reset state as a result of the transition to this state is impartial of the present state (ongoing_state). By default, the FSM reset state and transition protection are disabled in ICC, as proven in Determine 13. They are often enabled utilizing the set_fsm_reset_scoring command within the CCF. This command allows scoring for all of the FSM reset states and transitions resulting in reset states which can be outlined throughout the design module.
Determine 13 FSM protection is proven with out set_fsm_arc_scoring command. Supply: eInfochips
Syntax:
set_fsm_reset_scoring
Within the design, there are two FSMs outlined—fsm_design_one and fsm_design_two—and we’re enabling the FSM arc and reset state and transition protection for fsm_design_two solely. If the set_fsm_arc_scoring and set_fsm_reset_scoring instructions will not be supplied within the CCF, the FSM arc, FSM reset state and transition protection will not be enabled, as proven in Determine 13.
If the set_fsm_arc_scoring and set_fsm_reset_scoring instructions are supplied within the CCF, as proven in Determine 14, then the FSM arc, the FSM reset state, and the transition protection are enabled as proven in Determine 15.
Determine 14 The set_fsm_arc_scoring and set_fsm_reset_scoring instructions are supplied in CCF. Supply: eInfochips
Determine 15 FSM protection is proven with set_fsm_arc_scoring and set_fsm_reset_scoring instructions. Supply: eInfochips
In case the design consists of FSM(s), and to make sure that the FSM design is exercised completely, and it’s verified primarily based on a coverage-driven strategy, one ought to allow the set_fsm_arc_scoring and set_fsm_reset_scoring instructions within the CCF information.
Environment friendly protection closure
Environment friendly protection closure is important for guaranteeing thorough verification of complicated SoC/IP designs. This paper builds on prior work by introducing Cadence IMC instructions that automate key points of protection administration, considerably decreasing handbook effort.
The usage of select_coverage and deselect_coverage allows exact management over module and covergroup protection, whereas set_com intelligently excludes fixed objects, enhancing the protection accuracy. Moreover, set_fsm_arc_scoring and set_fsm_reset_scoring improve the FSM verification, guaranteeing that each one state transitions and reset circumstances are completely exercised.
By adopting these automation-driven methods, verification groups can streamline the protection closure course of, improve effectivity, and keep excessive verification high quality, enhancing productiveness in trendy SoC/IP growth.
Rohan Zala, a senior verification engineer at eInfochips, has experience in in IP/SoC verification for sensor-based chips, sub-system verification for fabric-based design, and NoC programs.
Khushbu Nakum, a senior verification engineer at eInfochips, has experience in IP/SoC verification for sensor-based chips and sub-system verification for NoC design.
Jaini Patel, a senior verification engineer at eInfochips, has experience in IP/SoC verification for sensor-based chips and SoC verification for sign processing design.
Dhruvesh Bhingradia, a senior verification engineer at eInfochips, has experience in IP/SoC verification for sensor-based chips, sub-system verification for fabric-based design, and NoC programs.
Associated Content material
- The Ever-Elusive Design Closure
- A revolution in useful verification
- Utilizing SystemVerilog for useful verification
- Timing Closure Utilizing Structure Primarily based Design Course of
- How formal verification saves time in digital IP design
The submit Lowering handbook effort in protection closure utilizing CCF instructions appeared first on EDN.
