HW/SW Interface Management thru Automated Register Specification Anupam Bakshi Engineering Director Agnisys Technology Pvt. Ltd. Embedded Systems Conference Noida, India. 2008
Agenda Introduction Introduction HW design process HW design process The Problem The Problem Possible Solutions Possible Solutions Q&A Q&A
Introduction
4 SoC/FPGA designs today Ever increasing design complexity Ever increasing design complexity –IP (in-house/3 rd party) Integration : 30% of total development cycle* –Verification 60% of total development effort* Increased Cost Increased Cost –80% cost is head-count related* TTM pressures TTM pressures –89% of designs go over deadline by avg. 44% Parallel software development Parallel software development *Source: Spirit/NXP Dec 2007
FPGA/SoC System overview Device Driver, OS Kernel Device Driver, OS Kernel Creates Hardware abstraction Creates Hardware abstraction Uses Hardware Protocols Uses Hardware Protocols –AMBA (AHB, APB) –OCP-IP –Proprietary HW/SW Interface Hardware Protocol Software API Software Application Configuration Registers Hardware
System Design Process HW/SW Interface Hardware Protocol Software API Software Application Configuration Registers Hardware Functional specification Partitioning Integration Correction iteration
System Design Process Hardware Design Hardware Verification System Diagnostics/Firmware Application Software Spec VHDL Programming guide or MS excel file C/C++ Header
Canonical Hardware System
Hardware Registers Hardware contains many Registers Hardware contains many Registers –100s : Control applications –1000s : Image Processing applications Registers Used for Registers Used for –Configurations –Control –Status Why focus on Registers? Why focus on Registers? –Ubiquitous and essential –Wide spread impact/ Quick ROI –Low hanging fruit! –Effects not just the hardware but software, firmware, …
The Problem
The Domino effect in HW design
The problem Many representations of the same register information Many representations of the same register information –Functional SpecificationMS Word/Frame –HW Design VHDL/Verilog –HW Programming GuideMS Word/Excel –Verification Environment HVL/TCL –FirmwareC/C++ header –DiagnosticsC/C++ header –Application SoftwareC/C++ header
Problem Description (contd.) Problems with Register descriptions in multiple places: Problems with Register descriptions in multiple places: –Time consuming to create –Additions/Changes are problematic –Error prone –Monotonous work Longer debug time Longer debug time Longer Hardware/Software integration times. Longer Hardware/Software integration times.
Problem Description (contd.) 1. Number of register is large 2. Changes are inevitable during design process –Add/remove registers –Register definition/bit fields –Register location –Register type (r, r/w, w1c, …) –Register implementation
Possible Solutions
What if we have … One specification for all registers One specification for all registers All representations generated from the single source All representations generated from the single source
Possible solutions Single description for all registers Single description for all registers –SPIRIT –SystemRDL Implementation Implementation –GUI based tools –Eclipse based tools –Editor based tools
SPIRIT Unified set of specification based on IP meta-data Unified set of specification based on IP meta-data – Called IP-XACT Called IP-XACT –XML Schema –Language neutral Comprehensive data Comprehensive data –Components, Registers, Address spaces, … –Bus definitions, Ports, …
SPIRIT Register description status Status register 0x4 32 true read-only dataReady Indicates that new data is available in the receiver holding register 0 1 read-only
SystemRDL Open specification Open specification – Textual Textual non-XML based non-XML based New language New language Donated to Spirit Donated to Spirit Reg chip1 { name = “some reg”; desc = “some desc”; field { hw = w; sw = r} f1[7:0] = 8’d5; field { hw = r; sw = w} f2[15:8] = 8’d10; … } Addresmap blk1_admap { name = “blk1 address map in chip1”; chip1 }
Automation Automation in System Design Hardware Design Hardware Verification System Diagnostics/Firmware Application Software Register Spec RTL C/C++ Header Documentation Programmer’s guide Memory map
Automation in System Design (contd.) Register Spec Synthesizable RTL Documentation (HTML/Word) C/C++ Header Verification tests C++ Classes Diagnostic tests Mnemonic/hex address mapping Auto Future Generators
Benefits of Auto Register generation Fast Fast Consistent Consistent Correct by construction Correct by construction Standardized VHDL and C++ code Standardized VHDL and C++ code Complete, in-sync documentation Complete, in-sync documentation Automatic register R/W tests Automatic register R/W tests Helps reusability Helps reusability
C/C++ Header file typedef struct { union { union { Newman_ColdfireInterface_s s; Newman_ColdfireInterface_s s; hwi_uint32 filler[0x200]; hwi_uint32 filler[0x200]; } ColdfireInterface; } ColdfireInterface; union { union { reusememblock_s s; reusememblock_s s; hwi_uint32 filler[0x200]; hwi_uint32 filler[0x200]; } reusememblock; } reusememblock; union { union { Newman_FrameBuffers_s s; Newman_FrameBuffers_s s; hwi_uint32 filler[0x200]; hwi_uint32 filler[0x200]; } FrameBuffers; } FrameBuffers; union { union { Newman_genlock_s s; Newman_genlock_s s; hwi_uint32 filler[0x200]; hwi_uint32 filler[0x200]; } genlock; } genlock; union { union { Newman_VideoCapture_s s; Newman_VideoCapture_s s; hwi_uint32 filler[0x200]; hwi_uint32 filler[0x200]; } VideoCapture; } VideoCapture; : :
HTML output
Conclusion Manually creating multiple views of registers is inefficient. Manually creating multiple views of registers is inefficient. Automation enables us to maintain a single source of register specification. Automation enables us to maintain a single source of register specification. Automation streamlines the whole process with better Hardware/Software Integration, Diagnostics and Verification Automation streamlines the whole process with better Hardware/Software Integration, Diagnostics and Verification
Q/A