Debugging multiprocessor code
Jakob Engblom, Virtutech
EE Times (07/21/2008 12:00 AM EDT)
Debugging code running on multiprocessor computing systems, and, in particular, parallel code on multicore devices, is an old computing problem that has reached a certain prominence and urgency because of the profound transformation of hardware from single-processor to multiprocessor and multicore solutions in the past few years. But beyond software engineers' moaning and groaning that hardware is making life harder, what does this transformation really mean? It's one thing to claim that something is difficult, but it is something else entirely to produce a solution that truly helps.
There are several different schools of thought about multiprocessor software design and debugging, depending on the background of those in the discussion. Sometimes, the issue is optimizing an "embarrassingly parallel" algorithm by writing a small piece of new code to run on a particular parallel machine. Other times, it is taking an existing many millions of lines of code and simply making them work correctly in a parallel world. Although I think that most cases involve a mix of both, the bigger immediate problem is posed by large pieces of existing working code. One obvious example is the battle between SMP (symmetric) and AMP (asymmetric) setups, an argument often more religious than anything else. It is also an argument quite irrelevant to the debugging question.
EE Times (07/21/2008 12:00 AM EDT)
Debugging code running on multiprocessor computing systems, and, in particular, parallel code on multicore devices, is an old computing problem that has reached a certain prominence and urgency because of the profound transformation of hardware from single-processor to multiprocessor and multicore solutions in the past few years. But beyond software engineers' moaning and groaning that hardware is making life harder, what does this transformation really mean? It's one thing to claim that something is difficult, but it is something else entirely to produce a solution that truly helps.
There are several different schools of thought about multiprocessor software design and debugging, depending on the background of those in the discussion. Sometimes, the issue is optimizing an "embarrassingly parallel" algorithm by writing a small piece of new code to run on a particular parallel machine. Other times, it is taking an existing many millions of lines of code and simply making them work correctly in a parallel world. Although I think that most cases involve a mix of both, the bigger immediate problem is posed by large pieces of existing working code. One obvious example is the battle between SMP (symmetric) and AMP (asymmetric) setups, an argument often more religious than anything else. It is also an argument quite irrelevant to the debugging question.
To read the full article, click here
Related Semiconductor IP
- nQrux® Root of Trust IP
- AXI to UCIe Bridge IP
- UCIe 2.x Controller IP
- SWI3S (SoundWire I3S Interface) Peripheral Controller Core IP
- OpenTitan-based RISC-V Secure Element
Related Articles
- Creating, Simulating, and Debugging SVA Code Outside of the Traditional Design/Verification Environment
- Retargeting IP -> Design system compiles silicon straight from C code
- IP vendors making leap from source code to silicon
- Customized DSP -> VLIW calls for special debugging
Latest Articles
- A Secure dToF LiDAR SoC with Dual-Domain Fingerprinting and Event-Driven AFE Circuit Achieving Sensor-Level Attack Resilience
- ZTA-Q: an Open-source RISC-V Platform for Accurate Quantized CNN Inference
- Automated Pre-Silicon Verification of High-Speed DDR5 and LPDDR5/6 Memory Controllers: Closed-Loop Timing, Mode Register, and PHY Synchronization in UVM
- U-Sonic: An Open-Source 8-Channel Ultrasound Transmit IP in a 130 nm RISC-V SoC
- S-ALSA: Co-Design of Adiabatic Logic-based Sensing and Balanced Bit-Cells for Secure and Energy-Efficient MRAM