Feature: Embedded design
exploration of the entire software stack. Watching the whole system executing full-sized tasks will still have to wait for working silicon, even though it worked on the server. Seeking the root cause of problems will require trying to reproduce the error in the emulation or simulation environment and sorting out the behaviours of the hardware and software.
Testing the full stack Ideally, the full software stack and the complete RTL design should be tested together as soon as both are sufficiently complete and stable to allow meaningful execution runs. This gives the development team the opportunity to identify bugs and hardware/software interactions early, while they are more easily isolated. And good version control ensures that the software team is working with the current RTL model and that the hardware team knows at once if they have just broken the software. The problem is speed. To test the
full software stack on the SoC model realistically requires an FPGA- based prototype and its development environment. Accordingly, FPGA prototypes have become increasingly common in SoC development.
Experience has shown that this is not
enough. An FPGA prototyping system will be able to run the full software stack on a realistic model of the SoC logic and memory, fast enough for intensive system verification. What about the model’s interaction with the outside world? Verification requires seeing how the design behaves in continuous operation with real-world data. In the past, many designers have
attempted to circumvent this challenge by trying to identify patterns of input data that will be most challenging to the system. Then those patterns can be synthesized as scripts and fed into the prototype to observe its response. This is ultimately a low probability
approach. As years of development have shown, it is not possible to anticipate what streams of video from HD cameras are going to cause an AI system to mis- categorise a traffic situation. As any communications engineer can attest, it is equally impossible to predict the patterns of data that will appear on a real-world Gigabit Ethernet link or PCIe bus. As both ADAS and networking engineers have learned, a priori analysis is no substitute for massive amounts of real-world data.
Ideally, verification engineers could
connect the high-speed FPGA prototype directly to cameras, sensors, actuators and displays of the real system, and subject the system design to real-world data, in its unpredictable variety and natural speed. That could mean running the FPGA prototype system in a moving car, a live network switch, or a storage controller in a data centre.
A question of interfaces This raises another question: how to get at-speed or near-speed signals from the real world into the FPGA prototype. Design teams have tried several approaches. Once again, one solution is emerging. It might seem reasonable to implement
the critical interfaces in the FPGA prototype. After all, the finished SoC will include those interfaces, so they are a real part of the design. And external networks, buses and control signals could be connected directly into the prototyping system. But there are serious issues with this
approach. The first is that it will divert important design and verification resources away from the main design project. These interfaces will be present
Figure 1: A desktop system delivers FPGA-based prototyping powered by AMD’s VP1902 FPGA in a compact, portable form factor
www.electronicsworld.co.uk December 2025/January 2026 35
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
