Low jitter, ultra-low power (<950uW) ring-oscillator-based PLL-2.4GHz
Benefits of Executable Specification
By Devender Pal Khari, Agnisys
What is an executable spec?
In the context of an IP and/or SoC design and development, a specification consists of a complete description of the concerned IP/SoC or any subsystem. It consists of architecture, register map, memory map, functionality, data path, FSMs, timing behavior, sequences, etc. Most of this spec is static and informative, helping design and verification engineers to write RTL, verification testbenches, and firmware. There is a significant part of the specification that can be described in a way that can be directly processed by tools and automatically generate design, verification and validation infrastructure, firmware, and documentation collaterals with minimal human intervention. This form of specification is called an executable specification. It can be described in different user-defined formats such as spreadsheets, documents, CSV, YAML and industry standards like IP-XACT, System RDL, PSS, etc.
Usually, about 30-35% of a design (IP/SoC) consists of addressable registers and memory maps. Once the register specification is captured, designers work on manually creating a custom synthesizable application logic layer for the intended functionality using these addressable hardware registers. Creating this layer often consists of using various design constructs. This manual work done by the designer may be error prone and often requires additional changes. Most of the application logic consists of data paths and FSMs, which is about 25-30% of the whole design. Regarding verification of a design, sequences (test and control) are a significant part. Automation in application logic creation further reduces the IP/SoC development cycle time.
An executable spec can help automatically handle registers, memory maps, data paths, FSMs, sequences, etc and generate required collaterals for design, verification, validation, firmware and documentation. It serves as a Golden Specification, a single source of truth, which is essential to streamline the development process and reduce the likelihood of errors that may arise from manual coding. Agnisys offers different products that can use this spec as input to generate required collaterals as shown in Figure-1 below:
Figure-1: Golden specification generating different collaterals using different tools
Executable specifications can also serve as a platform for collaboration among team members with different roles and expertise. System architects, design engineers, verification engineers, software engineers and validation engineers can work together on a shared model, promoting a more integrated and collaborative design process. Each role requires different collaterals as shown in Figure-2 below:
Figure-2: Agnisys IDesignSpec Suite generating different collaterals for different roles
In the above figure, some commonly used executable spec formats are mentioned. The spec in any of these formats or a mix of some of these formats can be fed into the Agnisys tools, which then generate required collaterals. The formats mentioned in green color are industry standards, that is, System RDL, IP-XACT, and PSS. Users can customize the generated outputs as per their requirements by applying various properties in their design at different levels of hierarchy. Agnisys products support a rich set of properties, in excess of 400. The designs can be organized hierarchically as shown in Figure-3 below:
Figure-3: Hierarchical organization of user design
A single spec can be defined for the whole hierarchy or each block can be defined in a separate spec and then these specs can be combined to introduce hierarchy. In Figure-3, each box can be any of the components like Register, Register Group, Memory, IP Block, Third Party IP, Sub System, and SoC. Circles at some blocks indicate the bus interfaces.
Components of an executable spec
An executable spec format allows users to capture information regarding the following aspects of a design:
- Registers:
Registers are the basic building blocks of the register map. Each bit or set of bits within the register controls some behavior of a design. Every register has at least two accesses: Software Access and Hardware Access. The Software Access is the access from the host register bus, such as AMBA, Tile-link, etc. The Hardware Access is the access to the register from the user defined hardware logic. Based on the Hardware and Software Access types various ports and logic are generated in RTL.
An IP or sub system design can be divided into blocks with each block containing registers. Users can define logical boundaries for these registers using Register Group (Register File). Register groups can further have more logical boundaries around registers which means users can create nested register groups. This is also depicted in Figure-3 above. Agnisys IDesignSpec Suite of tools allows users to add some UDPs on registers to change their behavior. For example, using alias property on a register users can make a single physical location accessible in two ways.
- Memory:
A memory is a storage with contiguous address locations. In IDesignSpec, memories are conceptualized as external register groups. Memory depth is the total number of registers in the external section and width is max width of these registers.
Apart from capturing registers and memory maps, users can capture other aspects of an IP using the following:
- D-Q Table:
Users can capture sequential logic by using D-Q tables. Users can specify the outputs in one column and specify the assignments on the other column. This is a way to make flops. The RTL output for this D-Q Table is a clocked procedural block.
- Datapath (Continuous Assignment):
The flow of data from input to output in a hardware is known as datapath and this style of modeling is called dataflow modeling. The continuous assignment statement is the main construct of dataflow modeling which can be used to drive (assign) values. Assign tables can be used to capture dataflow modeling where assignment can be specified as either of the two cases mentioned below:
- assign to output signals
- assign to registers
- FSM:
A state machine is a construct which makes transitions through a series of states based on external inputs and the current state of the machine. They play an important role as the complexity in hardware increases. The functionality can be broken down into a collection of states and inputs that determine when the system transitions from one state to another. Users can specify next state and outputs based on different external inputs in the form of a table.
- Non Addressable Register (Internal Register):
User application logic may need to store some results. Internal registers or non addressable registers can be used for this purpose. They can also be specified in the form of a table with the register names and the width of the register.
- Sequences (Configuration and Tests)
A sequence isa “set of steps” that involve reading/writing specific bit fields of registers in the IP/SoC. These sequences can be simple, or complex involving conditional expressions, array of registers, loops, etc. Users provide sequence specification in different forms like PSS, Python, and Agnisys proprietary format. Agnisys products then generate the UVM sequences for verification, SystemVerilog sequences for validation, C code for firmware & device driver development, and various output formats for automatic test equipment (ATE).
Benefits to users
- Executable specifications serve as a common ground for communication between different stakeholders in the development process, including architects, designers, verification engineers, firmware developers, and post silicon validation engineers
- Agnisys products analyze the specification to ensure that it meets certain design criteria, helping to identify potential issues early in the development process
- Automation reduces manual intervention, significantly avoiding human errors
- Significant reduction, about 30%, in overall IP/SoC development cycle time
- Ensures traceability: Changes to the specification can be tracked and traced throughout the development lifecycle. This traceability ensures that design decisions are well documented and can be revisited and understood at any point in the future
Conclusion
Overall, the use of executable specifications in front-end electronics architecture contributes to a more rigorous and efficient development process, helping to ensure that the final product meets the specified requirements and performs as intended.
If you wish to download a copy of this white paper, click here
|
Related Articles
- Proven solutions for converting a chip specification into RTL and UVM
- Using PSS and UVM Register Models to Verify SoC Integration
- Unveiling Efficient UVM Register Modeling with IDesignSpec™ GDI by Agnisys®
- M31 on the Specification and Development of MIPI Physical Layer
- Are you optimizing the benefits of cloud computing for faster reliability verification?
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |