Add support for Digilent Genesys 2 board

[yqszxx]

Depends on sifive/fpga-shells#159

Related issue: N/A

Type of change: new feature

Impact: new fpga target

Release Notes

Add support for Digilent Genesys 2 board

[abejgonzalez]

This code seems like a copy of the VCU118 code. Maybe we can dedup this by creating a folder like: fpga/src/main/scala/common and putting both sources there (with a new package name chipyard.fpga.common). Then we just reference that.

[yqszxx]

Good idea, I noticed I was just copying and pasting code when porting too 😂. Should I try to do some dedup work now or after this PR get merged?

[abejgonzalez]

I would wait until we get back to you on the testing side and fpga-shells gets merged.

[abejgonzalez]

Awesome, thanks so much for the contribution! I added one comment to maybe reduce the amount of duplication between this and the VCU118 work. I think before we consider merging this into Chipyard, you should try to get your PR merged into fpga-shells.

With that being said, the Chipyard team is discussing how best to deal with a PR like this... mainly because we have no mechanisms for testing that this works on the Genesys2 board without having one ourselves. We will get back to you on that once we have a decision.

[yqszxx]

Awesome, thanks so much for the contribution! I added one comment to maybe reduce the amount of duplication between this and the VCU118 work. I think before we consider merging this into Chipyard, you should try to get your PR merged into fpga-shells.

With that being said, the Chipyard team is discussing how best to deal with a PR like this... mainly because we have no mechanisms for testing that this works on the Genesys2 board without having one ourselves. We will get back to you on that once we have a decision.

Testing is really a problem, looking forward to your discussion results~

[jerryz123]

Do we need the actual boards to do testing? Wouldn't it be sufficient to test that Vivado can elaborate the design?

It may be a unreasonable goal for us to maintain regressions for many FPGA boards anyways. It may be better to have the board support checked in anyways, with the caveat that it might require more tinkering to make work compared to other flows.

[abejgonzalez]

Do we need the actual boards to do testing? Wouldn't it be sufficient to test that Vivado can elaborate the design?

It may be a unreasonable goal for us to maintain regressions for many FPGA boards anyways. It may be better to have the board support checked in anyways, with the caveat that it might require more tinkering to make work compared to other flows.

Correct, we want to avoid the need for having a board. However, we want to have some sort of simulation flow setup that can run the tests with FPGA collateral provided by Xilinx (through Vivado etc). An example of this would be https://github.com/ucb-bar/chipyard/tree/arty-sim/fpga or FPGA-level sim in FireSim