One of my favorite toys is my Zynq-7000 PS/PL TUL-2 . This board’s main component combines an ARM processor with an FPGA fabric so that one can make Verilog-based designs and then synthesize and test them.
One of the frustrations of learning the Linux kernel is you often want a device to work on but all the hardware in your system already has device drivers written, so you would need to compile them out. And finding the specs for the guts of your hardware can be rather difficult. So I decided to build my own peripheral to show how it’s done.
In college I used an RPN calculator… hard to learn but once you learned it the calculations were much easier. I won’t rehash RPN here but the quick jist of it is you need a stack and some operations.
So (74+21)*(3+7) is, in RPN:
| Operation | Stack State | Comment |
| reset | [] | |
| Push 74 | [74] | |
| Push 21 | [21,74] | |
| Add | [95] | Add the two elements and put in bottom element, shifting down 1. |
| Push 3 | [3,95] | |
| Push 7 | [7,3,95] | |
| Add | [10,95] | |
| Mul | [950] | Final Value |
| Pop | [] |
Assuming you don’t need complete stack visibility, our peripheral will need 3 registers.
The basic RTL was pretty easy. There are always going to be syntactical nitpicks between what Verilator, Vivado sim and what the synthesis engine will accept.
Now that I have my base IP, I need a ‘register’ file which I can write commands. to.
| Register 0x0 | Value to pop on stack. |
| Register 0x4 | Command (one-hot, so 0=nop,1=reset,2=push, 4=pop,8=add,16=sub,32=mul) |
| Register 0x8 | Value of stack element 0. |
In a “real” system I would of course allow for things like expansion, context switches and add a self-identification register to make sure the IP version matched the kernel module.
The way you get the peripheral onto the FPGA fabric is to create a new IP and indicate you are doing a AXI Peripheral. Instance the ZynqRPNCalculator IP in an AXI Slave Interface. You can see my tutorial from a few years ago on this. This will provide a register file and wrapper for interconnect. Then you package that IP so it looks like another offering in your IP package library.
I also hacked the register file (see “RDP” notes) so that it would not save the one-hot states (I only want the command issued for one clock cycle) and would route the stack-zero value to register 2 for reading. Then I packaged the IP in a local repository. If you want to automate this process, BTW, there is a vivado.jou file that is created which is a transcript of your session. Just remove the start_gui from it and you have a script you can run from the commandline!
Now I instance the ZynqRPNCalculator IP in a board design. You should be able to generate a bitstream pretty easily (I have bitstream if you need it for my TUL Pynq-Z2 board).
Now I copy my bitstreams to the Zynq along with a simple sanity-check program.
Now for the kernel. A simple character device should suffice here for us. Either I’m entering a number or I’m doing an operation. So:
“r123u456ua” would be reset, push 123, push 456, and add.
The Zynq Processing system memory-maps the peripherals you create to a specific address space (you can have multiple peripherals). You can get that address with a python call (it’s in the sanity check script).
print("Base Address 0x%x" % overlay.ZynqRPNCalculator_v1_0.mmio.base_addr)
In this case, 0x4000000. The kernel has access to the registers but you need to go through a similar process to accessing memory pages. This reads our stack0 register:
And this writes our control registers:
Here is the complete Kernel module. The hard part was finding a compile platform. The build environment on-board gave me an error. I did some detective work and figured out how to build the kernel from the published distributions. At least that worked for modules… I would go the petalinux route if I needed to recompile the whole kernel.
And Boom! We have our own peripheral and kernel module!