Unified Debug Environment for Adaptive Computing Systems

1
Unified Debug Environment for Adaptive Computing
Systems

• Brigham Young University
• Provo, UT
• September 13, 1999

2
Introduction and Motivation
3
Basic Premise
FPGAs bring something unique to the party.
4
What is unique?
FPGAs are faster?
5
What is unique?
FPGAs are reprogrammable?
ASIC
6
What is unique?
FPGAs are always available?
FPGAs
7
What is unique?
FPGA Potential Hardware development becomes
software development.
8
Good News
modify design
synthesize
download/verify
FPGA development cycle is similar to software
development cycle.
9
Bad News
placeroute/ download
scratch head
synthesize
modify design
simulate/verify
execute
There are two development cycles!
10
Issues
1000s of times slower...
1000s of times faster...
simulate/verify
execute/scratch head
excellent visibility
poor visibility
Either approach is insufficient.
11
Goal One Efficient Cycle
1000s of times faster...
execute/verify
excellent visibility
12
Main Issue
Need to provide software visibility when
debugging hardware.
13
What is Software Debugging?

• Debug prints.
• Examine/watch variables.
• Modify variables.
• Single-step/multistep.
• Breakpoints.

14
Cant I just use VHDL?

• Simulation Yes (but that was always the case).
• Execution No
• Cannot control HW platform via VHDL.
• Automatic downloading of bitstreams.
• Patching the bitstream for debug prints.
• Controlling the clock.
• Accessing platform memory.

15
Do I have to use JHDL?

• NO!
• EDIF can be translated to JHDL debug format.
• All debugging tools operate using the debug
  format.
• User-defined signal names will be generally
  available via the debugging tools.

16
General Vision

• FPGAs programmed and debugged similar to
  software.
• Use general-purpose languages for programming.
• Use software-like debugging techniques.
• Provide EDIF-interchange for access via other
  tools.

17
Project Overview
18
Goal
Create a productive environment for debug and
development that exploits the unique features of
ACS.
19
Specifics

• Unified access to simulation and execution.
• Multitasking support for hardware execution.
• Control of the platform from remote locations.
• Automatic synthesis of debug circuitry.
• Checkpointing of execution and simulation.
• Support for external high-level tools.

20
General Software Architecture
21
Unified Simulation/Execution
Simulator
Simulate
ATR
X3
X4
ATR Circuit Description
X1
X2
JHDL Library
data
Configure/ Execute
X0
configure
Simulator/Run-time API
HW Manager
ACS Platform
22
Single-User Systems
Whos got the board?
Whos got the ?? board?
Glad nobody needs the board.
23
Hardware Multitasking
Multitasking ACS Server
24
Remote Access
25
Remote Access

• Access ACS Hardware away from Laboratory

ACS Platform
ACS Platform
Home
Across Campus
Across Hall
26
Remote Access

• Centralize Maintenance and Support
• It is expensive to outfit and support ACS
  technology
• ACS technology can be fragile

ACS Platform
ACS Platform
ACS Platform
27
Remote Access

• Extend availability of ACS technology
• Collaborate with large distributed development
  teams
• Provide ACS hardware access to those without ACS
  capability

Universities
Public School
Internet Access
ACS Platform
Industry
28
Remote Access - Issues

• No standardized client architecture
• User interfaces are unique (cannot export host
  display!)
• Only simple protocols available (http, ftp,
  telnet, etc.)

ACS Platform
ACS Platform
Windows NT
Mac
HP Workstation
Sun Workstation
Linux x86 Workstation
29
Remote Access - Issues

• Network Bandwidth Limitations
• Must limit the data needed for remote
  access/debug
• Exporting user interface consumes excessive
  bandwidth

v.34
ACS Platform
ACS Platform
LAN
slip
30
Remote Access - Issues

• Security/Safety
• Must insure access to ACS hardware is restricted
• Prevent inadvertent communication (download email
  to SLAAC board?)

ACS Platform
ACS Platform
hacker
31
Remote Access - Approach

• Exploit platform independence of Java/JHDL
• Create unique communication protocol
• Limit ACS to client communication to essential
  control and data information
• Add security layer to remote communication
  protocol
• Provide same interface to ACS hardware without
  requiring login access to host machine

32
Remote Access - Approach
jhdl/browser
ACS protocol
security
jvm (x86)
ACS protocol
jhdl/browser
security
ACS protocol
ACS server
security
Hardware API
jvm (mac)
Hardware
33
Debug Circuitry
34
Debug Circuitry Synthesis
?

• Simulation routinely used for debugging circuits
• Greater visibility
• More control over execution
• Easy to use interfaces
• Facilitate the use of hardware debugging by
  synthesizing custom circuits

35
Debug Circuitry Synthesis
?
36
Debug Circuitry Synthesis
Additional Wires and I/O for Visibility
0
1
0
37
Debug Circuitry Synthesis
Memory Buffers for Real-Time Data Capture
Signal Buffer
38
Debug Circuitry Synthesis
Logic Circuits for Hardware Breakpoints
0
Disable Clock
39
Debug Circuitry Synthesis
Counters and Logic for System Profiling and
Analysis
0
40
Debug Circuitry Synthesis - Issues

• Preserve speed/function of circuit
• Debug circuitry may add delays
• Circuitry may introduce logic errors
• Remove debug circuits gracefully
• Avoid place and route step
• Limit turn around time for debug cycle
• May not be possible with some technologies
• Xilinx-Jbits (Guccione)

41
Debug Circuitry Synthesis -Approach

• Define API for specifying debugging needs
• Develop platform independent synthesis tools
• Create platform specific debugging libraries
• Optimized state machines
• Clock controllers
• Memory buffers and counters

42
Checkpointing

• Complete capture restoration of
  simulation/execution state

43
Checkpointing
Simulate/execute from any saved point - repeat
problem sections - continue tomorrow
44
Checkpointing
Mix simulation execution
ACS Platform
Simulation
ACS Execution
or
45
Checkpointing
Support for multitasking
46
Checkpointing Issues

• State capture

• Device issues
• flip flops
• LUT contents
• on-chip RAMs
• Platform issues
• memories
• fifos
• control registers
• Hardware support for?

47
Checkpointing Issues

• State capture
• State representation

• Custom format?
• Common format?
• Communication with other tools?

48
Checkpointing Issues

• State capture
• State representation
• State storage

• Local vs. remote
• speed of access
• Hardware support for?

49
Checkpointing Issues

• State capture
• State representation
• State storage
• State restoration

• Similar to capture
• device issues
• platform issues
• Hardware support for?

50
Checkpointing Concerns

• Device support for
• Xilinx, Altera, CSRC
• Platform support for
• Wild, SLAAC1, CSRC, Altera platforms
• Proprietary issues
• need for open systems

51
Checkpointing Concerns (2)

• Scope of applicability
• Multiple-clock systems
• Host-bus based systems
• Other
• what if no single-step capability?
• what if no host bus?

52
External Tool Support

• Leverage this environment for any design...

53
External Tools -Scenario 1

• Platform control
• configuration
• clock/IO control
• memory peek/poke
• bitstream management

Similar to most environments in existence
54
External Tools -Scenario 2

• Platform control
• Waveform display of execution results
• flat signal name space

Similar to Splash-2s t2 tool.
55
External Tools -Scenario 3

• Platform control
• Hierarchy navigation
• Schematic viewing
• Waveform display of execution results
• hierarchical name space
• Mixed simulation/hardware execution

No known equivalent...
56
External Tools -Scenario 4

• Platform control
• Hierarchy navigation
• Schematic viewing
• Waveform display
• Mixed execution
• Programmatic control of debug process

No known equivalent...
57
General Software Architecture
58
Collaborative Involvement

• Virginia Tech (P. Athanas)
• Synopsys (NIMBLE, R. Harr)
• Sanders (CSRC, C. Myers)
• Xilinx (Jbits, S. Guccione)
• Sarnoff (C-Streams, M. Gokhale, J. Arnold)
• Lockheed Martin (ECMA, R. Pancoast)
• LANL (DAPS, K. McCabe)

59
Device and Platform Targets

• Devices
• Xilinx (XC 4K and Virtex)
• Sanders CSRC
• Altera
• Platforms
• SLAAC
• AMS WildStar/WildFire

60
Debug and CSRC

• Problem
• CSRC does not support readback.
• Solution
• Dedicate one context as a debug context during
  development.

61
JHDL and Altera
62
Why Target Altera?

• Double check that JHDL is not Xilinx dependent
• The Altera model is much different than the
  Xilinx model
• Show versatility of JHDL for multiple targets

Xilinx XC4000/Virtex
JHDL
Sanders CSRC
Altera 10K
63
How JHDL is translated
JHDLhardware description
Simulator
JHDL-XC4000Technology Mapper
JHDL-Altera 10KTechnology Mapper
JHDL-AlteraNetlister
EDIF
Hardware
Altera ToolMaxPlus II
64
Challenges of interfacing with Altera

• Different architecture
• Hierarchical logic structure
• Logic elements (similar to 0.5 CLBs)
• Logic array blocks ( 8 LEs)
• Embedded Array Blocks (2k RAM)
• Different placement primitives
• no relative placement
• no direct mapping
• Altera placement specifies hierarchy, not
  physical location

65
Challenges of interfacing with Altera

• Difficult to debug
• No readback
• No partial reconfiguration
• JTAG boundary scan
• Can it be used for debug?

66
Debugging strategy

• Instrument design with multiplexors to bring
  signals of interest to pins for debug tracing

Traced Signals
FPGA pins
67
Debugging Strategy Instrumentation
JHDLhardware description
It could be done here by the designerBut it is
bad to alter a design in order to debug it.
Its better to do it here, transparently
Its better yet to do it here.
JHDL-Altera 10KTechnology Mapper
JHDL-AlteraNetlister
EDIF
Hardware
Altera ToolMaxPlus II
Its best to do it dynamically,but this is not
possible with an Altera FPGA
68
Schedule and Milestones
69
Task 1

• Design the DSM.

2000
2001
1999
2002
70
Task 2

• Write the Debug API Spec

2000
2001
1999
2002
71
Task 3

• Develop Platform Control Interface

2000
2001
1999
2002
72
Task 4

• Develop Device Libraries
• Implement Xilinx-Virtex libraries (DEMO)
• Implement Altera libraries (DEMO)
• Implement CSRC libraries (DEMO)

2000
2001
1999
2002
73
Task 5

• Develop Device-Specific Debug Strategies
• Xilinx-Virtex (DEMO)
• Altera (DEMO)
• Sanders CSRC (DEMO)

2000
2001
1999
2002
74
Task 6

• Implement the DSM
• Implement basic DSM capabilities. (DEMO)
• Implement multitasking and remote debugging.
  (DEMO)
• Implement checkpointing. (DEMO)
• Implement automated probe and monitoring. (DEMO)

2000
2001
1999
2002
75
Task 7

• Internal data structures, algorithms,
  command-line interface
• Browser GUI

2000
2001
1999
2002
76
Task 8

• Debugging Circuitry Synthesis Tool
• Specify API
• Develop platform independent software for debug
  circuitry
• Develop platform specific synthesis backend for 2
  platforms. (DEMO)

2000
2001
1999
2002
77
Task 9

• Create API specification for high-level tool
  support.
• Select data interchange mechanism and data
  format(s)
• Create software modules for design data
  interchange
• Demonstrate use of high-level tool with DSM.
  (DEMO)

2000
2001
1999
2002
78
Task 10

• Evaluate effectiveness on DARPA applications.
• FOA, Superquant, CDI, Beamforming, etc.
• Ongoing demonstrations as always...

2000
2001
1999
2002
79
Staffing

• 4 Faculty
• Brad Hutchings
• Brent Nelson
• Mike Wirthlin
• Doran Wilde
• 4 Full-time staff (PhD)
• Scott Hemmert
• Justin Tripp
• 21-25 Students (grad and undergrad).