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