Lets face it, timelines are shrinking with every successive project. What took 18 months earlier is expected in 12 months now. Derivative projects that took 6-9 months are expected to finish in 3-4 months! This is the demand of the market.
To execute projects in such drastically shrunk schedules, activities that were traditionally done serially are now being done in parallel. For example, software development and testing typically started once the hardware prototypes were ready. Consequently, software engineers did not have to debug hardware issues, as the hardware platform was typically quite stable.
In today’s world, software development and testing starts very early on and is being tested on hardware platforms and models that are not stable and are being developed in parallel with the software. Because of this, software engineers are exposed to hardware bugs and need to participate in the hardware debug process. Software and hardware teams cannot work in isolation anymore!
This brings us to the practical difficulties faced by software engineers when they need to participate in debugging hardware. A major component of debug is tractability. Engineers should be able to trace events and actions across software and hardware. A software function call might result in a transaction on the AXI bus that might further result in a control transfer on the USB interface. How do we establish the linkage between these events?
Traceability across the hardware-software boundary is broken as the software engineers and hardware engineers do not speak the same language! For example, a major problem faced during Hardware-Software debug is that software engineers do not understand signal waveforms. It takes a lot of effort for software engineers to make sense of signal wiggles. We need to make life easier for the software engineer. A simple action like checking whether a software function call translated into a transaction on the AXI bus can become a nightmare for him. He needs to pull in a hardware engineer for even a basic task like this.
To enable the software engineer to proceed without pulling in the hardware team, we need to provide him with a higher abstraction view of the hardware. Instead of looking at interface wires and signal toggles, he needs to be able to see the transactions and packets being transferred on these interfaces.
Imagine how simple life would have been if, instead of AXI signals, the software engineer could see AXI read/write transactions! He can proceed without help from a hardware engineer, at least for now. When he hands over the issue to the hardware team, he can tell exactly till where he has been able to trace the issue. Maybe he saw the expected AXI transaction for the correct USB target and then did not see a USB control transfer that he was expecting. He can do this if has a higher abstraction view of hardware. He cannot do this if he has to look at signal waveforms.
This is the kind of problem that we at Arrow Devices are solving with our PDA debug tool. This took can process signal toggles and present the same data in terms of protocol packets and transactions, providing the higher level abstraction view that software engineers can use to shorten the debug cycle.
Take a look at the video here: Extract protocol information from signal dumps
'