FPGA Debug –
How hard can it be?
Didier Martiny, CIO
IT IS
REALLY
HARD
About Byt
Byte
e Paradigm & Yugo Systems
• Founded in 2005 by 3 ASIC-SoC-FPGA engineers as a
Design Center for high-end FPGA and board design
• 2007
2007: GP-22050 is launched (www.byteparadigm.com)
– GP-22050 was a USB digital pattern generator & logic analyzer
– Now diversified - with notably SPI Storm,
Storm the market technology leader for SPI &
serial protocol host adapter in USB form factor
• 2011
2011: decision to capitalise on FPGA + T&M experience
– Market research and R&D. Multiple potential markets explored.
• Dec. 2014:
2014 Creation of ‘Yugo Systems’
Systems’, a separate trade name &
brand of Byte Paradigm.
• Yugo Systems focuses exclusively on FPGA debug & verification.
EXOSTIV is our first product under the Yugo Systems name.
About Byt
Byte
e Paradigm & Yugo Systems
GP-22050 USB Digital Pattern Generator & Logic Analyzer
A simple case: a video processing platform
Headers & controls per frame : 1.024 bits
2.048 pixels
1.024
lines
Pixels per frame:
Pixel encoding :
Frame rate:
221
36 bit
24 fps
‘Something’ goes wrong…
• Randomly
• Unknown time from cause to effect
• Occurs when system is put together
• Not everything was designed in-house
Debug case
• ‘Emergent system’ type: function of not just
the individual little pieces, but the way they
collectively interact as a whole.
• ‘Some’ history’ must be captured.
We don’t know how much of that history is necessary
• Simulation
Simulation--only cannot be used:
used
– too long to be practical
– there is probably a problem of modelling since the
bug was not detected during RTL verification.
– we need to ‘narrow in’ on the bug first
Debugging with an Embedded LA
Debugging with an Embedded LA
1) Limit capture to header and controls : 1.024 bit per frame
2) Worst case : full 2 hours movie at 24 fps:
1.024 b x 2 h x 3.600 s x 24 fps = 176.947.200 b ~ 22
3) Reality: 32 kbit RAM is available for debug in the FPGA.
= Debug information for 32 frames
Equivalent to 1,33 s of a 2 hours movie.
‘Shooting in the dark’?
4) Solution: we need a more clever triggering approach…
approach
Question: how do you trigger
on something you do not know?
know?
MB
You may prevail… but how fast?
Debugging with a ‘traditional’ LA
Debugging with a ‘traditional’ LA
1) Is there any usable connector on the FPGA I/Os?
In our case : no connector  we cannot use a LA.
Supposing there is a connector…
2) Can the interesting signals be routed ‘as is’?
- Sampling speed: 200 MHz to 400 MHz. Can the I/O do it?
- Can the PCB support that speed?
- There aren’t probably enough pins
3) Does the design need to be adapted?
- Data buffering + clock speed adaptation
- Time-multiplexing on the available debug I/Os
Question: How can you foresee the required ‘real estate’ when
you don’t know what you’ll have to debug?
Is FPGA different?
Source: Xilinx web site
Can’t we simply adopt
ASIC & SoC tools & methodology?
The ASIC / SoC design community about FPGA…
‘Another example of the FPGA design
community shooting themselves in the foot.’
Gary Smith in 2011, about the lack of adoption of emulation in the FPGA design
flow, after the demise of GateRocket (Emulation for FPGA)
‘Apparently it still doesn't pay to make killer EDA tools
for FPGA designers. They're too used to getting free
EDA tools directly from the FPGA vendors.’
John Cooley’s comment (DeepChip.com)
Source: http://www.deepchip.com/wiretap/110818.html
What’s different with FPGA?
• Economics
• Engineers
• Technical constraints
- or - Perception?
Perception (1)?
• 10x to 20x lower (upfront?) design cost =
Lower incentive to spend for advanced tools.
• Engineers’ education & experience
• The ‘cliff’ of advanced verification techniques
learning (such as UVM)
• ‘Gut feeling’ that no technique is the ‘panacea’
• In-lab is there because, YES, WE CAN.
ASIC / SoC cost – ‘Big numbers’ (* Beware *) – Source: IBS
Perception (2)?
• Debugging happens because engineers are
incompetent…
• It is hard to ask the Boss to spend more
money so you can correct your mistakes…
• ASIC / SoC ‘cost mountain’ is not in sight.
• Cheap & early access to real hardware
About InIn-lab Debug
‘The electronic engineer is like a
doctor without XX-Ray’
• The ability to test & debug in the lab is…
– An Opportunity
• Modeling
• Time of execution
– A Challenge
• Temptation to do everything in the lab
• Observability / Visibility
EXOSTIV
TM
Thank you Any questions?
FPGA Debug Reloaded
www.yugosystems.com