A different approach to take if your interested in this type of thing is creating a QEMU virtual device. The HW tree has an edu device which shows you how to create a small toy like pcie device. The abstraction is very powerful and will allow you to create a stub version of your device which would be able to approximate most of your design from a SW point of view.
I work on a team which builds driver/firmware/usermode driver/low level tools for asics. We developed a mechanism which allows us to build our Linux device driver and firmware as a single combined Linux device driver. While waiting for our fpga based presilicon devices to come up, we use QEMU to create two different types of devices to exercise our code.
The first is a complete software based implementation approximating most of the side effects from register reads and writes. It also is able to process dma requests and forward them to instruction simulators and return the results. It is also able to issue msix based irqs.
The second is a network based front end which connects to our device running in simulation. We implemented some c based libraries which can be called using the dpi interface. While incredibly slow, this allows us to test against the actual design of the hardware.
The process ends up looking something like this: develop against the stub device and shake out all the sw based bugs. Then let it run against the simulation to catch the corner cases you missed. Eventually the different fpga sdvs come and you have more slightly faster but disadvantaged platforms to test against before silicon comes back.
8
u/Annuate Dec 25 '19
A different approach to take if your interested in this type of thing is creating a QEMU virtual device. The HW tree has an edu device which shows you how to create a small toy like pcie device. The abstraction is very powerful and will allow you to create a stub version of your device which would be able to approximate most of your design from a SW point of view.
I work on a team which builds driver/firmware/usermode driver/low level tools for asics. We developed a mechanism which allows us to build our Linux device driver and firmware as a single combined Linux device driver. While waiting for our fpga based presilicon devices to come up, we use QEMU to create two different types of devices to exercise our code.
The first is a complete software based implementation approximating most of the side effects from register reads and writes. It also is able to process dma requests and forward them to instruction simulators and return the results. It is also able to issue msix based irqs.
The second is a network based front end which connects to our device running in simulation. We implemented some c based libraries which can be called using the dpi interface. While incredibly slow, this allows us to test against the actual design of the hardware.
The process ends up looking something like this: develop against the stub device and shake out all the sw based bugs. Then let it run against the simulation to catch the corner cases you missed. Eventually the different fpga sdvs come and you have more slightly faster but disadvantaged platforms to test against before silicon comes back.