138 lines
6.9 KiB
ReStructuredText
138 lines
6.9 KiB
ReStructuredText
Running a Design on VCU118
|
|
==========================
|
|
|
|
Basic VCU118 Design
|
|
-------------------
|
|
|
|
The default Xilinx VCU118 harness is setup to have UART, a SPI SDCard, and DDR backing memory.
|
|
This allows it to run RISC-V Linux from an SDCard while piping the terminal over UART to the host machine (the machine connected to the VCU118).
|
|
To extend this design, you can create your own Chipyard configuration and add the ``WithVCU118Tweaks`` located in ``fpga/src/main/scala/vcu118/Configs.scala``.
|
|
Adding this config fragment will enable and connect the UART, SPI SDCard, and DDR backing memory to your Chipyard design/config.
|
|
|
|
.. literalinclude:: ../../fpga/src/main/scala/vcu118/Configs.scala
|
|
:language: scala
|
|
:start-after: DOC include start: AbstractVCU118 and Rocket
|
|
:end-before: DOC include end: AbstractVCU118 and Rocket
|
|
|
|
Brief Implementation Description + More Complicated Designs
|
|
-----------------------------------------------------------
|
|
|
|
The basis for a VCU118 design revolves around creating a special test harness to connect the external IOs to your Chipyard design.
|
|
This is done with the ``VCU118TestHarness`` in the basic default VCU118 FPGA target.
|
|
The ``VCU118TestHarness`` (located in ``fpga/src/main/scala/vcu118/TestHarness.scala``) uses ``Overlays`` that connect to the VCU118 external IOs.
|
|
Generally, the ``Overlays`` take an IO from the ``ChipTop`` (labeled as ``topDesign`` in the file) when "placed" and connect it to the external IO and generate necessary Vivado collateral.
|
|
For example, the following shows a UART ``Overlay`` being "placed" into the design with a IO input called ``io_uart_bb``.
|
|
|
|
.. literalinclude:: ../../fpga/src/main/scala/vcu118/TestHarness.scala
|
|
:language: scala
|
|
:start-after: DOC include start: UartOverlay
|
|
:end-before: DOC include end: UartOverlay
|
|
|
|
Here the ``UARTOverlayKey`` is referenced and used to "place" the necessary connections (and collateral) to connect to the UART.
|
|
The ``UARTDesignInput`` is used to pass in the UART IO from the ``ChipTop``/``topDesign`` to the ``Overlay``.
|
|
Note that the ``BundleBridgeSource`` can be viewed as a glorified wire (that is defined in the ``LazyModule`` scope).
|
|
This pattern is similar for all other ``Overlays`` in the test harness.
|
|
They must be "placed" and given a set of inputs (IOs, parameters).
|
|
The main exception to this pattern is the ``Overlay`` used to generate the clock(s) for the FPGA.
|
|
|
|
.. literalinclude:: ../../fpga/src/main/scala/vcu118/TestHarness.scala
|
|
:language: scala
|
|
:start-after: DOC include start: ClockOverlay
|
|
:end-before: DOC include end: ClockOverlay
|
|
|
|
Without going into too much detail, the clocks overlay is placed in the harness and a PLL node (``harnessSysPLL``) generates the necessary clocks specified by ``ClockSinkNodes``.
|
|
For ease of use, you can change the ``FPGAFrequencyKey`` to change the default clock frequency of the FPGA design.
|
|
|
|
After the harness is created, the ``BundleBridgeSource``'s must be connected to the ``ChipTop`` IOs.
|
|
This is done with harness binders and io binders (see ``fpga/src/main/scala/vcu118/HarnessBinders.scala`` and ``fpga/src/main/scala/vcu118/IOBinders.scala``).
|
|
For more information on harness binders and io binders, refer to :ref:`Customization/IOBinders:IOBinders and HarnessBinders`.
|
|
|
|
Introduction to the Bringup Platform
|
|
------------------------------------
|
|
|
|
An example of a more complicated design used for Chipyard test chips can be viewed in ``fpga/src/main/scala/vcu118/bringup/``.
|
|
This example extends the default test harness and creates new ``Overlays`` to connect to a DUT (connected to the FMC port).
|
|
Extensions include another UART (connected over FMC), I2C (connected over FMC), miscellaneous GPIOS (can be connected to anything), and a TSI Host Widget.
|
|
The TSI Host Widget is used to interact with the DUT from the prototype over a SerDes link (sometimes called the Low BandWidth InterFace - LBWIF) and provide access to a channel of the FPGA's DRAM.
|
|
|
|
.. Note:: Remember that since whenever a new test harness is created (or the config changes, or the config packages changes, or...), you need to modify the make invocation.
|
|
For example, ``make SUB_PROJECT=vcu118 CONFIG=MyNewVCU118Config CONFIG_PACKAGE=this.is.my.scala.package bitstream``.
|
|
See :ref:`Prototyping/General:Generating a Bitstream` for information on the various make variables.
|
|
|
|
Running Linux with SDCard Setup
|
|
-------------------------------
|
|
|
|
Both the bringup and normal VCU118 platforms are setup to boot Linux loaded from the SPI SDCard.
|
|
|
|
Building Linux with FireMarshal
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To build Linux that will run on the VCU118 prototype, we will use the FireMarshal platform.
|
|
To understand FireMarshal in more depth, refer to it's documentation.
|
|
|
|
1. Setup FireMarshal
|
|
2. Switch the FireMarshal "board" to target the prototype platform using ``marshal-config.yaml``
|
|
|
|
```
|
|
echo "board-dir : \'boards/prototype\' > PATH_TO_FIREMARSHAL/marshal-config.yaml
|
|
```
|
|
|
|
This should allow you to use the ``br-base.json`` workload built for the prototype platform (includes GPIO/SPI drivers).
|
|
|
|
3. Run ``./marshal -v -d build br-base.json`` to build the workload with initramfs.
|
|
|
|
4. Install the workload ``./marshal -v -d install -t prototype br-base.json``. This will flatten the binary.
|
|
|
|
.. note:: Feel free to modify and build off the `br-base.json` using normal FireMarshal functionality.
|
|
|
|
Setting up the SDCard
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The following instructions are for Linux but you can follow a similar set of steps on Mac (using `gpt`).
|
|
|
|
Linux Instructions
|
|
==================
|
|
|
|
Use `gdisk` to put the binary on the SDCard.
|
|
The following steps use `/dev/sdc` as the path to the SD card (replace with your own path).
|
|
|
|
1. Wipe the GPT on the card.
|
|
|
|
`sudo gdisk /dev/sdc`
|
|
|
|
2. Use the `z` command to zap everything.
|
|
|
|
`sudo gdisk /dev/sdc`
|
|
|
|
3. Change the default partition alignment to `1` so you can write to sector `34`.
|
|
Do this with the `l` command.
|
|
|
|
4. Then create the new GPT with `o`. Click yes on all the prompts.
|
|
|
|
5. Create a 512MiB partition to store the Linux payload (note this can be smaller but it must be larger than the size of the Linux payload).
|
|
Use `n` and select sector 34, with size `+1048576`.
|
|
For the type search for the `apfs` type and use the hex number given.
|
|
|
|
6. Create a second partition to store any other files with the rest of the SDCard.
|
|
Use `n` and use the defaults for starting sector and overall size.
|
|
For the type search for the `hfs` and use the hex number given.
|
|
|
|
7. Write the changes using `w`.
|
|
|
|
8. Setup the filesystem on the 2nd partition using the following command:
|
|
|
|
`sudo mkfs.hfs -v "Prototype Data" /dev/sdc2`
|
|
|
|
Note that `sdc2` is used since it points to the 2nd partition.
|
|
|
|
Transfer Linux to the SDCard
|
|
============================
|
|
|
|
Finally transfer the `-flat` binary generated by FireMarshal to the sdcard:
|
|
|
|
`sudo dd if=<path-to-firemarshal>/br-base-bin-nodisk-flat of=/dev/sdc1`
|
|
|
|
Note that `sdc1` points to the 1st partition.
|
|
|
|
Additionally at this point you can mount the 2nd partition, add files, and mount that on the Linux on the prototype.
|