HWSW Interface Management thru Automated Register Specification

1
HW/SW Interface ManagementthruAutomated
Register Specification

• Anupam Bakshi
• Engineering Director
• Agnisys Technology Pvt. Ltd.
• ab_at_agnisys.us

Embedded Systems Conference Noida, India. 2008
2
Agenda

• Introduction
• HW design process
• The Problem
• Possible Solutions
• QA

3
Introduction
4
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

Source Spirit/NXP Dec 2007
5
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
6
System Design Process
Software Application
Integration
Software Design
Partitioning
Software API
Functional specification
HW/SW Interface
I/F Design
Hardware Protocol
Hardware Design
Configuration Registers Hardware
Correction iteration
7
System Design Process
Hardware Design
Spec
Programming guide or MS excel file
VHDL
Hardware Verification
System Diagnostics/Firmware
C/C Header
Application Software
8
Canonical Hardware System
9
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,

10
The Problem
11
The Domino effect in HW design
12
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

13
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.

14
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

15
Possible Solutions
16
What if we have

• One specification for all registers
• All representations generated from the single
  source

17
Possible solutions

• Single description for all registers
• SPIRIT
• SystemRDL
• Implementation
• GUI based tools
• Eclipse based tools
• Editor based tools

18
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,

19
SPIRIT Register description
ltspiritregistergt ltspiritnamegtstatuslt/spiritna
megt ltspiritdescriptiongtStatus
registerlt/spiritdescriptiongt
ltspiritaddressOffsetgt0x4lt/spiritaddressOffsetgt
ltspiritsizegt32lt/spiritsizegt
ltspiritvolatilegttruelt/spiritvolatilegt
ltspiritaccessgtread-onlylt/spiritaccessgt
ltspiritfieldgt ltspiritnamegtdataReadylt/spirit
namegt ltspiritdescriptiongtIndicates that new
data is available
in the receiver holding register
lt/spiritdescriptiongt ltspiritbitOffsetgt0lt/spi
ritbitOffsetgt ltspiritbitWidthgt1lt/spiritbitW
idthgt ltspiritaccessgtread-onlylt/spiritaccessgt
lt/spiritfieldgt ltspiritfieldgt lt!--
--gt lt/spiritfieldgt lt/spiritregistergt
20
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 f170 8d5
field hw r sw w f2158 8d10
Addresmap blk1_admap name blk1 address
map in chip1 chip1 chip1_reg _at_0x0000
21
Automation in System Design
Register Spec
Hardware Design
Hardware Verification
RTL
Documentation Programmers guide Memory map
Automation
C/C Header
System Diagnostics/Firmware
Application Software
22
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
23
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

24
C/C Header file

• typedef struct
• union
• Newman_ColdfireInterface_s s
• hwi_uint32 filler0x200
• ColdfireInterface
• union
• reusememblock_s s
• hwi_uint32 filler0x200
• reusememblock
• union
• Newman_FrameBuffers_s s
• hwi_uint32 filler0x200
• FrameBuffers
• union
• Newman_genlock_s s
• hwi_uint32 filler0x200
• genlock
• union
• Newman_VideoCapture_s s

25
HTML output
26
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

27
Q/A