System-level design
Making Power Intent Specification Easy
Fortsetzung des Artikels von Teil 2
Interactive Development
The IDE is more than just a visualization platform; it is a development environment that proactively assists engineers with code entry. Because the IDE supports both UPF (IEEE Std. 1801-2015) and CPF (version 2.0), it has a complete definition of allowed syntax. If an engineer makes a mistake in a specification, for example typing “create_power_domains” into the UPF editor, the IDE will immediately report this as an error and will recommend a correction to the proper “create_power_domain” command.
The IDE also makes suggestions; typing in only “create_” will pop up a menu showing the possible auto-completions and allowing the user to choose one. As mentioned earlier, one of the complaints against UPF is that it is a new format to learn. By leveraging its built-in knowledge of language and specification standards, the IDE can greatly reduce the burden of up-front format memorization and thereby accelerate the learning process.
The IDE can also generate a template for the new command, showing which fields the user must fill in. For each field, as the user types a module or signal name from the design, both auto-completion options and error reporting are available. This greatly reduces the time it takes to create a power-intent specification, even for expert users who know the format well.
Consistency Checking
The difficulty in keeping multiple design and verification files in synchronization is a major challenge on SoC projects. Stand-alone specification files only exacerbate the problem. It is interesting to note that one of the reasons that SystemVerilog Assertions (SVA) is widely preferred over the Property Specification Language (PSL) standard is that assertions are included directly within the design and verification code. Using search-and-replace to change a variable name is likely to result in updates to assertions as well as to other references.
Although power intent specification is in a separate file, the IDE can bridge the gap between this file and others than might reference the same design names. Because it compiles on the fly whenever changes are made, it immediately cross-checks any edits to UPF/CPF or RTL files. Figure 2 shows an example of such a check. The RTL has been updated to change instance "i_smc_lite_old" to "i_smc_lite" but the UPF file still has the old name. The IDE instantly detects and reports this inconsistency.
Conclusion
Several factors are driving low-power design considerations for contemporary SoCs. Multiple techniques are available to reduce and manage power consumption, but the ability to control individual power domains offers a great deal of flexibility for hardware and software management. A clear, unambiguous definition of these domains and other aspects of power intent is required, using one of the specification standards available. By expanding to include support for power intent formats, the same IDE used to develop the design and verification code can ensure consistency across all files. The result is faster adoption, easier specification, and a more robust approach to low-power design.
- Making Power Intent Specification Easy
- Power Intent Specification
- Interactive Development
