Overview
One of the great benefits of an SoC device is having a Processing System (PS) consisting of application ARM cores integrated together with Programmable Logic (PL) or what we traditionally think of as an FPGA.
The PL basically becomes another addressable peripheral of the software cores, with addition of some control signals like interrupts between the two. This integration opens up what seems like endless possibilities of HW/SW "collaboration", or more commonly referred to as "hardware offloading" and "hardware acceleration".
This project will serve to show the common tradeoffs considered when implementing a design on an SoC and choosing what gets implemented in software versus fabric.
Architecture
One application on two different PS/PL architectures will be explored while the external interface(s), namely a 1Gbps link to a host PC and the DDR controller, are kept the same.
A0
The first architecture is shown below; we'll call this one "A0".
In architecture A0, the Gigabit Ethernet MAC (GEM) is allocated to the A53 core running Linux: packets are received by the GEM and written to DDR. The A53 forwards data packets to the PL through the PS DMA Engine. The same datapath is followed for egress packets: PL -> PS DMA Engine -> DDR -> GEM.
This gives us our first list of tradeoffs:
- [+] Linux driver handles the GEM and external PHY initialization
- [+] Linux includes a full networking (ethernet) stack
- [-] Linux app needs to copy between socket buffers and user buffers
- [-] Linux app is the scheduler of the PS DMA transactions between PL and DDR
This tradeoff sacrifices latency (and possibly throughput performance) for a full networking stack with the added bonus that the stack is "free".
As tradeoffs often involve comparing similar but different devices, it's important to note that with the size of this particular SoC, even if we were okay with significant developing time for implementing a stack in the PL, this SoC would not have enough PL logic resources.
Design
A0
SW app
Packetizer
Verification
Do not skip this one. You come from an environment where verification is the discipline, and most personal projects in this space have none, so the contrast is worth the paragraphs.
Describe the testbench, what you drove, what you checked against, and how you knew it was right. Coverage, assertions, a reference model, hardware-in-the-loop traffic — whatever you actually used. If simulation and hardware disagreed at any point, that story is worth telling in full.
Results
The numbers. Throughput, latency distribution, resource utilisation, timing margin at the achieved clock. A small table is the right format, and one honest number beats three vague adjectives.
If a result fell short of the target, say so and say why. It reads as competence, not weakness.
What I would do differently
Two or three items, specific. This section is disproportionately persuasive to anyone who has shipped hardware, because it shows the design is understood rather than merely finished.
Implementation notes
The deep layer. Anything a reader who has gotten this far would want: bring-up gotchas, constraint files, clock domain crossings, specific errata you hit. Nobody is obliged to read this, which means it can be as detailed as you like — and it is the first section that should become its own page when it gets long.
Software stack
How the Linux side was built and why that route rather than the alternatives. Keep this short unless it was genuinely hard — if it was, say what was hard.