Accessing DRAM on Arty and prototyping flow for Arty100T

[denishoornaert]

Hi all,

I am interested in implementing the rocket core(s) on either the Arty35T or the Arty100T. However, I would like the core(s) to have access to the 256MB of off-chip memory available on these boards. As far as I understand, the provided configuration and prototyping flow for the Arty35T does not provide any access. On the other hand, the fpga-shell of the Arty100T maps the DDR controller (https://github.com/sifive/fpga-shells/blob/f9fb9fd338e5fca2ff5116b1d01506c424280d70/src/main/scala/shell/xilinx/Arty100TShell.scala#L228). Unfortunately, the prototyping flow does not currently support the Arty100T.

Following the documentation (https://chipyard.readthedocs.io/en/latest/Prototyping/Arty.html), I checked that the RocketChipConfig builds successfully for Arty35T. Thereafter, I decided to try the same command with the BOARD variable set to arty_a7_100. Doing so gives the following error:

...
[info] running chipyard.Generator --target-dir ~/chipyard/fpga/generated-src/chipyard.fpga.arty.ArtyFPGATestHarness.TinyRocketArtyConfig --name chipyard.fpga.arty.ArtyFPGATestHarness.TinyRocketArtyConfig --top-module chipyard.fpga.arty.ArtyFPGATestHarness --legacy-configs chipyard.fpga.arty:TinyRocketArtyConfig
[error] (run-main-0) java.lang.ClassNotFoundException: chipyard.Generator
[error] java.lang.ClassNotFoundException: chipyard.Generator
[error]     at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
[error] stack trace is suppressed; run last Compile / bgRunMain for the full output
[error] Nonzero exit code: 1
[error] (Compile / runMain) Nonzero exit code: 1
[error] Total time: 0 s, completed Mar 16, 2021, 9:32:31 PM
~/chipyard/common.mk:97: recipe for target 'generator_temp' failed
make: *** [generator_temp] Error 1

Do you know what is the origin of this error and how I could fix this?

More generally: assuming that I managed to build the TinyRocketConfig for the Arty100T, do you if I will be able to access the off-chip memory and how hard it would be to achieve this?

[LIUQyou]

Hi, I set the Board to arty_a7_100, then it works

  ifeq ($(SUB_PROJECT),arty_100T)
    # TODO: Fix with Arty
    SBT_PROJECT     ?= fpga_platforms
    MODEL           ?= ArtyFPGATestHarness
    VLOG_MODEL      ?= ArtyFPGATestHarness
    MODEL_PACKAGE   ?= chipyard.fpga.arty
    CONFIG          ?= TinyRocketArtyConfig
    CONFIG_PACKAGE  ?= chipyard.fpga.arty
    GENERATOR_PACKAGE ?= chipyard
    TB              ?= none # unused
    TOP             ?= ChipTop
    BOARD           ?= arty_a7_100
    FPGA_BRAND      ?= xilinx
endif

Then I used make SUB_PROJECT=arty_100T CONFIG=XXXX. It can port desired project on arty 7 100T. But I did not add DDR interface yet.

[LIUQyou]

it seems like that we are doing a similar project, I am trying to add a DDR interface to the port as well. Could you tell me how do you add the DDR interface to the project? Thanks

[jamesdunn]

Hello @denishoornaert and @LIUQyou,

Bringing new FPGA harnesses like the Arty 100T into Chipyard requires some plumbing work that has not yet been implemented. Particularly, a new TestHarness that extends the Arty100TShell needs to be implemented, as well as Harness/IOBinders that create and wire system-level (ChipTop) IOs to harness-level IOs (like those for the DDR) for the Arty100TShell harness. Then, this new TestHarness would replace the MODEL and VLOG_MODEL variables in the Makefile.

We initially included the Arty35T in Chipyard since it is the simplest, and we have one of these dev boards on-hand. It currently only implements a subset of the features that Freedom implemented, namely UART, SPI Flash, and JTAG.

I agree that DDR is a very nice peripheral to have access to, so bringing support for it to the Arty35T is high on the priorities and something I will probably be working on soon. For now, the SiFive Freedom repo should allow you to generate Rocket cores for the Arty 100T that can access the on-board DDR. If you're interested in learning how FPGAs map from Freedom into Chipyard, you can check out how the files in this Freedom directory compare to this chipyard directory—it was largely the template we used.

I believe that your error is unrelated, though: changing only the BOARD variable should not affect the Verilog elaboration, since it is only used in the bitfile generation part of the flow. Your error is likely caused by another environment issue.

I would expect LIUQyou's build to succeed, but only because the MODEL variable tells Chipyard to actually build for the Arty35T.

Best, James

[jdeters]

The Freedom repo has been deprecated and points to a pretty old version of Rocket Chip (circa 2018). I have an Arty 100T on hand and am very interested in having Chipyard support the 100T in addition to the 35T. I'd be willing to assist with development and/or testing. FWIW, the original Freedom repo did support the Arty 100T, so it's not outside the realm of possibility to support it within Chipyard.

[AlexanderPuckhaber]

Just to chime in, this project https://github.com/eugene-tarassov/vivado-risc-v implements the latest Rocket Chip on a few different FPGAs (including the nexys-a7-100t, which sounds like it would be pretty similar to the Arty100T).

The repo uses the Vivado Block Diagram / IP Integrator for things like AXI interconnects and also implements DDR-over-AXI using the MIG generator. If the pin mappings for DDR are different, you can just find an example project for the Arty100T and import those into the MIG wizard, which then saves the settings to an xml file.

After editing the Block Diagram and updating the IP blocks to the Arty100T and running the MIG wizard, you can then save the .tcl script for version control (which includes the MIG xml file). It appears to me that the fpga-shells repo also used the MIG wizard

By comparison, the VCU118 Bringup configuration in current Chipyard defines the DDR configuration a bit differently

Then you would need to verify that the .xdc constraints are correct for that board by referencing the manual. Make sure to check the reset (high vs low) and system clock. I ran into issues with those when I adapted the nexys-a7-100t configuration for the AC701

Side note: here are some breadcrumbs I made when trying to figure out the chipyard FPGA configuration files. It's really good to see that people are working on generalizing some of the VCU118 configuration code to make it easier to add support for new FPGAs.

I'm mainly mentioning the vivado-risc-v repo because I have found the prototyping flow to be relatively straightforward, as it uses a lot of Vivado tools like the interactive block diagram. And it supports multiple different FPGAs families booting Linux on rocket chip. Maybe we can use it as an alternate FPGA toolchain - would need to make it point to the Chipyard generator instead of just Rocket Chip. And I suppose when users modify ChipTop, they would have to use the block diagram editor to manually connect the wires to outputs (haven't tried that yet though). Still, it might be faster to prototype that way. Once that works, then I think Chipyard's approach of modular Chisel peripherals has the potential for less code duplication.

[jerryz123]

Resolving this (finally) in #1345