Does OpenCPI support checkpoint files for OSP development? For instance, if I have a firmware bitstream which loads when the OS boots and I want my HDL worker to operate within this wrapper.
No, right now OpenCPI doesn’t have this capability.
If I understand your question correctly, your looking for a feature that exports OpenCPI HDL assembly / container into a design check point (.dcp) file that can be imported it into an existing platforms build process.
Currently OpenCPI requires OSP developers to control the entire FPGA fabric. This is where all clocks and interconnect interfaces are defined such that it comes down to building an HDL assembly all the necessary IP is there to support it.
We’ve actually been discussing this internally for sometime. Such a capability would ease platform developers integration into existing platforms and allow users to drop in OpenCPI functionality into existing builds and platforms.
Is that what you were thinking?
Speaking very very roughly here, what is possible in that setup if you have access to the top level (as in, you can change what ports are on the top level of the dcp) is:
- You pipe out one M_AXI_GP
- Various widths are possible, but 32 address 32 data works.
- This needs a specific base address (0xA0000000 off the top of my head) and at least 64MB (off the top of my head) of range
- IIRC, you don’t actually need to set this in Vivado. You can leave the port unmapped.
- You pipe out two S_AXI_HP
- Various widths are possible, but 32 address 64 data works.
- Pipe out a clk and a reset (sync or async).
That is enough to implement an OpenCPI Platform Worker (you might be able to get away with less). Every other dcp pin can be set to a pin in the Platform Worker XML and will passthrough directly to a top level pin.
Your dcp can then be in the sourcefiles of the Platform Worker.
The constraints file can be just a dump of the checkpoints constraints, with the current_instance commands regex changed to move where the dcp is in the hierarchy (your top level is now “deeper” in the design so the constraints will reference the wrong location).
That’s a very rough description, but that’s the simplest existing top level DCP → OSP flow possible changing as little of the dcp as you can.
I can expand on this if helpful.
I agree @waltersdom all the pieces are already there for zynq and zynq_ultra platforms we just need a reproducible process flushed out and document it. If we stick to the same address spaces as you suggested would be easiest but perhaps add configurability to addresses would provide more flexibility.
Hi, thanks for your reply. Yes this is my thinking
Hi, thanks for your reply. This is very helpful. I will give this a try, I’m new to OSP development so I may have some questions.