Add hard processor support for Cyclone V

[ilesser]

Started a discussion in the litex-boards reporsitory about providing support for HPS in Cyclone V SoCs.

Ultimately the best way to do it is to create something similar to SoCZynq. I was thinking of SoCCV.

[enjoy-digital]

Maybe you could use a more generic name (SoCHPS?) since the same HPS is probably also used on CycloneV and ArriaV, but we could still figure out the best name once things are implemented and working.

[ilesser]

Maybe you could use a more generic name (SoCHPS?) since the same HPS is probably also used on CycloneV and ArriaV, but we could still figure out the best name once things are implemented and working.

Good idea. I've read a lot of doc about cyclone v and I think I can handle it. Do you know if arria v is so much different?

[ilesser]

What's the best approach, add the hps as an instance (as it is handled in the SoCZynq) or create an actual subclass of the CPU class?

[ilesser]

I was also thinking of compiling the HPS with all the possible options using Qsys and then uploading the generated verilog to the repo (similar to the rest of the CPU classes).

Legally speaking, is this ok? should I take any particular measures to upload Qsys generated verilog?

[ilesser]

The advantages of subclassing the CPU class is that you don't have to modify the argument parsers to let the user select if it wants a hps or a sps (soft processor system implemented in the fpga). But the CPU subclass that implements the hps should only accept certain platforms (in this case only altera platforms with cyclone v or arria v chips).

[ilesser]

Qsys can be run using the Quartus Prime Lite Edition which has access to Cyclone V device support.

In the Intel FPGA Software License Agreements I don't see any license for Lite edition so I assume it is ok to upload the code to the repository.

Plus on the main download page it says it is free and no license is required.

[enjoy-digital]

We could probably use the Qsys project file for the HPS and let Quartus regenerate the verilog during the build. This avoid having generated verilog files in the repositories (that's what we are doing on LitePCIe for example). But in a first time, i think you should try to create a LiteX SoC without CPU (based on SoCMini for example) and add the HPS as a Wishbone Master (through a AXI2Wishbone bridge) and get this working. Once you have something working, we could figure out the best way to integrate everything with a better view of things.

[ilesser]

I am half way trough that.

Using a precompiled hps would reduce synthesis time by a lot. We can get back at it once the SoC is working

[ilesser]

I am making progress but there are a few design choices I would like to discuss so my decisions match the project intentions. If possible I would like some feedback on them (silence would mean aproval?)

1. For now we need an ip .qsys file with the description of the hps for quartus to compile. I have moved the addition of this file to the platform into the board platform specification mainly because the qsys file is highly dependant on the board pinout and connections
2. The HPS has two axi3 slave interfaces (f2h and f2h_sdram) which require a wishbone to axi adaptor. I used the modules from ZipCPU formally verified WB2AXIP but I am not entirely sure of how to handle. We have two options: a. Translate the ip to migen and integrate into axi.py. Disadvantages we loose track of the changes in the ZipCPU repo. b. Create a git submodule pointing to the repo and create a wrapper instantiating the blocks. But this is entirely different of what was done for the cpu cores.
3. We need to create a CPU module to reuse all the code from SoCCore and not repeat it here. Is it ok to add the HPS as a new cpu under the cpu module like all the other soft CPUs? My proposal was to add cpu_type="hps" but I don't know what to do with cpu_variant.

[enjoy-digital]

Thanks for the update.

For 1) you can use the platform.add_source to add the qsys file and we could figure out later where is the best location for this file.

For 2) from what i understand you are already using AXI2Wishbone (https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/axi.py#L405) but you need a Wishbone2AXI? If so, you should be able to just use Wishbone2AXILite (https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/axi.py#L414).

For 3) yes, you could create a cpu_type = "hps", the cpu_variant is optional so you could keep it to "standard" or None. That's probably also what we should do for the Zynq instead of a specific SoCZynq class.

[ilesser]

1) Thanks!

2) I need a wishbone to axi3 (full) interconnection. AXI Lite won't be enough.

3) Great!

[enjoy-digital]

LiteX is not supporting bursts on the wishbone bus, so when used in LiteX, AXI Lite should be enough. I could create a Wishbone2AXI class if you want (that just translate AXI Lite to AXI by setting the specific AXI signals not present on AXILite to 0).

[ilesser]

I didn't know that wishbon bus is not supporting burst, AXI lite will be then.

If you could create the Wishbone2AXI class that would be great!

[enjoy-digital]

Yes sure, i'll add a Wishbone2AXI class.

[ilesser]

Is it ok if I create some AXI4 to AXI3 adaptors?

[enjoy-digital]

@ilesser: yes sure.

[enjoy-digital]

Closing since no update. This would however be a nice contribution and this issue could be re-opened if someone wants to work on it.