Date: Thu Feb 22 2007 - 01:01:05 PST
There is a paper at DVCON called, "Challenges and Practical Lessons Learned in the Verification of an Ultra-High Performance Game-Physics Processing ASIC" by Badri Gopalan et al, from Ageia Technologies and Wipro Technologies. Some might remember Badri from Synopsys. With his agreement and encouragement, I'm presenting his wish-list. This is from a draft of the paper, so the final paper might be a little different. Some of these are explained more fully in the paper, some require more clarification. IV. SUGGESTED ENHANCEMENTS TO SYSTEMVERILOG SystemVerilog [6] is a natural migration path for Verilog users for their verification needs. Based on our experiences in verifying the current ASIC, we have a list of features we think will make the language even more useful for practical verification: * More power to the preprocessor: Management of multiple configurations is typically implemented using conditional compilation / generates etc., which are very limiting. Enhancements to be able to read configurations from files, templates, and syntax to specify auto-wiring of module ports are desirable. The number of possible configurations in an SOC can be large, and managing these using the preprocessing features of Verilog is tedious. The language could borrow features from other approaches [9][10]. * RTL structural aspect orientation support: Structural and procedural modifications of the RTL from an external input, including removal of instances, change of values, constants etc., is used in several situations. Examples include reduction of counter values to shorten reset sequences, changing the default algorithm in a BIST simulation to run the shortest algorithm for a quick sanity check, removal of instances where they are not required in order to reduce the memory consumption (typically on chips with multiple cores), change of design parameters to aid quicker verification etc., Today, any change in the design for verification purposes requires a hack of the design. One way to enable this would be to use Aspect orientation-based approaches for RTL modifications from a source external to the module. * Embedding synthesizable RTL logic in the interface for abstraction of the interface specification from the implementation is not well addressed in either methodology or language support. The traditional methodology examples usually show verification constructs, or bundling of wires in an interface, but not RTL logic. The interface methodology in SystemVerilog and does not seem to support the idea of abstraction of communication, in a manner similar to SystemC. For SystemVerilog to evolve into a productive system design language, some language enhancements in this area are crucial. * The interface cannot instantiate a module: it is impossible to have existing modules in the interface without replicating their functionality. For example, if we consider an interface which represents a clockdomain synchronizer, one would ideally instantiate a existing synchronizer module written in Verilog inside the interface. * Synthesis would likely result in flattening of the interface. There are several methodology issues to be addressed regarding this, such as the state of the top level interface ports after flattening, how RTL logic in the interface is synthesized etc., * Standard / customizable logging infrastructure and classes: SystemVerilog needs a standardized and powerful logging mechanism to avoid vendor-specific or user-written logging capabilities. * Ability to save and restore an instance of any module using built in system calls: The existing $save / $restore needs to be augmented to be instance specific. * Object interface with C++ / SystemC: The Direct Programming Interface (DPI) of SystemVerilog currently seems to only provide a procedural interface to foreign languages. The ability to pass test-bench objects to the C++ code is useful. * Syntax to capture of applicable physical design aspects: Language syntax should be introduced to capture the power-related design requirements such as dynamic power (activity factors for nodes in RTL and cells in libraries), static power (consumption and leakage in library cells), attributes for voltage (high-Vt, low Vt etc.,) and voltage island information (inherited by the cells from design blocks in which they reside, and used to check for isolation related checks). These attributes can enable the verification of the power structure. For example, to verify if the clock slows down in a low-power mode of operation, it would be helpful to be able to query power attributes of a set of specific nodes or a moduleinstance to verify the lowering of activity. * SystemVerilog for system specification and verification: Providing a means of specification and verification of elements at a higher level of abstraction including register and memory map, state machines, busses and processing elements. Shalom Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
