commit | 513e4ab1647ca584aeb802129a45ebb63044db49 | [log] [tgz] |
---|---|---|
author | Dan Rodrigues <danrr.gh.oss@gmail.com> | Thu Dec 17 17:46:49 2020 +1100 |
committer | Dan Rodrigues <danrr.gh.oss@gmail.com> | Thu Dec 17 17:46:49 2020 +1100 |
tree | 8c2eae949cbc81741a4f7a1ce1a734bab9f2046c | |
parent | 59c874e40b9deac288ffdfdbb61d9c538389c38b [diff] |
Add current gl user_project_wrapper.v
This is a basic sprite generator that can be controlled using the PicoRV32 + WB interface of the Caravel SoC. It outputs 640x480@60Hz video with pixels doubled to 320x240. The sides of the screen are clipped by 64 pixels each to reduce the “FF RAM” address width to 8bits. If all goes well, OpenRAM could be used in future runs to relax some of these constraints, restore features etc.
The sprites can have arbitrary screen positions and can select any glyph from the character ROM.
It is a minimized variant of the VDP found in the icestation-32 project. The rest of the system is not included although minimal serial IO for gamepad reading is included. To fit the time / memory constraints, functionality has either been removed or simplified.
The font included in the character ROM is the Good Neighbours pixel font by Clint Bellanger, which is public domain.
cd openlane make vdp_lite_user_proj
The /openlane
directory contains a symlink to a $readmemh
file to be treated as ROM. Attempting to build it a different way or with a different CWD may fail.
The resulting vdp_lite_user_proj.gds
and vdp_lite_user_proj.lef
should be moved to the project /gds
and /lef
directories respectively, to be consistent with how others in caravel are handled.
Then to build the user project wrapper:
cd openlane make user_project_wrapper
The resulting GDS / LEF can then be integrated into Caravel
For the included build artefacts in this repo, these tools and their respective commits were used:
vdp_lite_user_proj
8688323e12530b9ced04b8053a6c4699b28402fc
817314be3c7996f62b6cb499e35e2107d4b822e2
user_project_wrapper
mpw-one-a
tagged openlane and open_pdks were used.
Testbenches that instantiate the caravel
SoC running tests software. They can be found in the verilog/dv/vdp_lite
directory.
video_frame
: Outputs a complete video frame using dumped RGBHV outputs, which is then converted using a Python script to a PNG.gamepad
: Exercises the gamepad serial IO and (tentative) LED outputs.A sample PNG from the video_frame
is shown below. It takes a very long time to complete and can be manually cut short to show a partial frame. The black borders represent the front/backporches.
The original contents of the README file follow:
A template SoC for Google SKY130 free shuttles. It is still WIP. The current SoC architecture is given below.
Start by cloning the repo and uncompressing the files.
git clone https://github.com/efabless/caravel.git cd caravel make uncompress
Then you need to install the open_pdks prerequisite:
* Note: You can avoid the need for the magic prerequisite by using the openlane docker to do the installation step in open_pdks. This could be done by cloning openlane and following the instructions given there to use the Makefile.
Install the required version of the PDK by running the following commands:
export PDK_ROOT=<The place where you want to install the pdk> make pdk
Then, you can learn more about the caravel chip by watching these video:
Your area is the full user_project_wrapper, so feel free to add your project there or create a differnt macro and harden it seperately then insert it into the user_project_wrapper. For example, if your design is analog or you're using a different tool other than OpenLANE.
If you will use OpenLANE to harden your design, go through the instructions in this README.md.
You must copy your synthesized gate-level-netlist for user_project_wrapper
to verilog/gl/
and overwrite user_project_wrapper.v
. Otherwise, you can point to it in info.yaml.
Note: If you're using openlane to harden your design, this should happen automatically.
Then, you will need to put your design aboard the Caravel chip. Make sure you have the following:
./gds/
in the Caravel directory.* Note: You can avoid the need for the magic prerequisite by using the openlane docker to run the make step. This section shows how.
Run the following command:
export PDK_ROOT=<The place where the installed pdk resides. The same PDK_ROOT used in the pdk installation step> make
This should merge the GDSes using magic and you'll end up with your version of ./gds/caravel.gds
. You should expect ~90 magic DRC violations with the current “development” state of caravel.
To use the magic installed inside Openlane to complete the final GDS streaming out step, export the following:
export PDK_ROOT=<The location where the pdk is installed> export OPENLANE_ROOT=<the absolute path to the openlane directory cloned or to be cloned> export IMAGE_NAME=<the openlane image name installed on your machine. Preferably openlane:rc6> export CARAVEL_PATH=$(pwd)
Then, mount the docker:
docker run -it -v $CARAVEL_PATH:$CARAVEL_PATH -v $OPENLANE_ROOT:/openLANE_flow -v $PDK_ROOT:$PDK_ROOT -e CARAVEL_PATH=$CARAVEL_PATH -e PDK_ROOT=$PDK_ROOT -u $(id -u $USER):$(id -g $USER) $IMAGE_NAME
Finally, once inside the docker run the following commands:
cd $CARAVEL_PATH
make
exit
This should merge the GDSes using magic and you'll end up with your version of ./gds/caravel.gds
. You should expect ~90 magic DRC violations with the current “development” state of caravel.
Please make sure to run make compress
before commiting anything to your repository. Avoid having 2 versions of the gds/user_project_wrapper.gds or gds/caravel.gds one compressed and the other not compressed.
<macro>
/ : includes all configuration files used to run openlane on your project.The managment SoC runs firmware that can be used to:
The memory map of the management SoC can be found here
This is the user space. It has limited silicon area (TBD, about 3.1mm x 3.8mm) as well as a fixed number of I/O pads (37) and power pads (10). See the Caravel premliminary datasheet for details. The repository contains a sample user project that contains a binary 32-bit up counter.
The firmware running on the Management Area SoC, configures the I/O pads used by the counter and uses the logic probes to observe/control the counter. Three firmware examples are provided: