HW SW Interface Management thru Automated Register Specification Anupam

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 www. agnisys. us 1

Agenda n Introduction n HW design process n The Problem n Possible Solutions n Q&A www. agnisys. us 2

Introduction www. agnisys. us 3

So. C/FPGA designs today n Ever increasing design complexity – IP (in-house/3 rd party) § Integration : 30% of total development cycle* – Verification § 60% of total development effort* n Increased Cost – 80% cost is head-count related* n TTM pressures – 89% of designs go over deadline by avg. 44% n Parallel software development *Source: Spirit/NXP Dec 2007 www. agnisys. us 4

FPGA/So. C System overview n Device Driver, OS Kernel n Creates Hardware abstraction n Uses Hardware Protocols – AMBA (AHB, APB) – OCP-IP – Proprietary Software Application Software API HW/SW Interface Hardware Protocol Configuration Registers Hardware www. agnisys. us 5

System Design Process Software Application Integration Software API Partitioning Functional specification HW/SW Interface Hardware Protocol Configuration Registers Hardware Correction iteration www. agnisys. us 6

System Design Process Spec Hardware Design VHDL Programming guide or MS excel file Hardware Verification System Diagnostics/Firmware C/C++ Header Application Software www. agnisys. us 7

Canonical Hardware System www. agnisys. us 8

Hardware Registers n Hardware contains many Registers – 100 s : Control applications – 1000 s : Image Processing applications n Registers Used for – – – n 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 9

The Problem www. agnisys. us 10

The Domino effect in HW design www. agnisys. us 11

The problem n Many representations of the same register information – – – – Functional Specification HW Design HW Programming Guide Verification Environment Firmware Diagnostics Application Software www. agnisys. us MS Word/Frame VHDL/Verilog MS Word/Excel HVL/TCL C/C++ header 12

Problem Description (contd. ) n Problems with Register descriptions in multiple places: – Time consuming to create – Additions/Changes are problematic – Error prone – Monotonous work n Longer debug time n Longer Hardware/Software integration times. www. agnisys. us 13

Problem Description (contd. ) Number of register is large 2. Changes are inevitable during design process 1. – – – Add/remove registers Register definition/bit fields Register location Register type (r, r/w, w 1 c, …) Register implementation www. agnisys. us 14

Possible Solutions www. agnisys. us 15

What if we have … n One specification for all registers n All representations generated from the single source www. agnisys. us 16

Possible solutions n Single description for all registers – SPIRIT – System. RDL n Implementation – GUI based tools – Eclipse based tools – Editor based tools www. agnisys. us 17

SPIRIT n Unified set of specification based on IP meta-data – www. spiritconsortium. org n Called IP-XACT – XML Schema – Language neutral n Comprehensive data – Components, Registers, Address spaces, … – Bus definitions, Ports, … www. agnisys. us 18

SPIRIT Register description status Status register 0 x 4 32 true read-only data. Ready Indicates that new data is available in the receiver holding register 0 1 read-only www. agnisys. us 19

System. RDL n Open specification – www. denali. com n Textual n non-XML based n New language n Donated to Spirit Reg chip 1 { name = “some reg”; desc = “some desc”; field { hw = w; sw = r} f 1[7: 0] = 8’d 5; field { hw = r; sw = w} f 2[15: 8] = 8’d 10; … } Addresmap blk 1_admap { name = “blk 1 address map in chip 1”; chip 1_reg @0 x 0000; } www. agnisys. us 20

Automation in System Design Register Spec Hardware Design Hardware Verification RTL Automation C/C++ Header Documentation Programmer’s guide Memory map System Diagnostics/Firmware Application Software www. agnisys. us 21

Automation in System Design (contd. ) C/C++ Header C++ Classes Register Spec Synthesizable RTL Auto Verification tests Diagnostic tests Documentation (HTML/Word) Mnemonic/hex address mapping Future Generators www. agnisys. us 22

Benefits of Auto Register generation n Fast n Consistent n Correct by construction n Standardized VHDL and C++ code n Complete, in-sync documentation n Automatic register R/W tests n Helps reusability www. agnisys. us 23

C/C++ Header file typedef struct { union { Newman_Coldfire. Interface_s s; hwi_uint 32 filler[0 x 200]; } Coldfire. Interface ; union { reusememblock_s s; hwi_uint 32 filler[0 x 200]; } reusememblock; union { Newman_Frame. Buffers_s s; hwi_uint 32 filler[0 x 200]; } Frame. Buffers; union { Newman_genlock_s s; hwi_uint 32 filler[0 x 200]; } genlock; union { Newman_Video. Capture_s s; hwi_uint 32 filler[0 x 200]; } Video. Capture; : : www. agnisys. us 24

HTML output www. agnisys. us 25

Conclusion n Manually creating multiple views of registers is inefficient. n Automation enables us to maintain a single source of register specification. n Automation streamlines the whole process with better Hardware/Software Integration, Diagnostics and Verification www. agnisys. us 26

Q/A www. agnisys. us 27