| commit | 265c142698f46a031d72163a4d3f245f685ac5ba | [log] [tgz] |
|---|---|---|
| author | Jeff DiCorpo <jeffdi@efabless.com> | Fri Feb 19 01:53:26 2021 -0800 |
| committer | Jeff DiCorpo <jeffdi@efabless.com> | Fri Feb 19 01:53:26 2021 -0800 |
| tree | 3ab27e607b57bf2edc8b63246ee009a5398bcf3c | |
| parent | db4d3bc75e4ae52e3972ac72497d6f6833f34f6e [diff] |
final gds & drc results
A pseudo random number generator oriented towards random cache placement and replacement for critical real-time processors.
The prng_proj module, contained in the prng_proj.v verilog file, offers an implementation of a pseudo random number generator. Such module is based on a parametric hash function used to randomise the cache placement. The following Figure shows our implementation of the parametric placement function:
The hash function rotates the address bits, based on some bits of the random index identifier (RII) as it is shown in the two rightmost rotate blocks of the figure. By doing this, we ensure that when a different RII is used, the mapping of that address changes. Analogously, the address bits are rotated based on some bits of the address itself. This operation, which is performed by the two leftmost rotate blocks, changes the way that the addresses are shifted. Note that addresses are padded with zeros to obtain a power-of-two number of bits, so address bits can be rotated without any constraint.
Finally, all bits of the rotated addresses, the original addressand the RII (187 bits in the example), are XORed successively, until we obtain the desired number of bits for indexing the cachesets
In the verilog implementation we will find the rotating register lfsr that we use to generate random numbers:
always @(posedge clk) begin if (rst == 0) begin lfsr[WIDTH-1:0] <= 0; end else begin lfsr[WIDTH-1:0] <= {lfsr[164:0],xnor_o}; end end
Reference: https://people.ac.upc.edu/fcazorla/articles/lkosmidis_date_2013a.pdf
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: