You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 1, 2022. It is now read-only.
The Common Evaluation Platform (CEP) is intended as a surrogate System on a Chip (SoC) that provides users an open-source evaluation platform for the evaluation of custom tools and techniques. An extensive verification environment is provided to ensure the underlying functionality is maintained even after modification.
20
+
The Common Evaluation Platform (CEP) is an Open Source Hardware (OSH) System on a Chip (SoC). It has been developed to support the test and evluation of custom tools and techniques. An extensive verification environment is provided to ensure the underlying functionality is maintained even after modification.
21
21
22
-
The Logic Locking Key Interface (LLKI) has been provided as a representative means of distributing key / configuration material to LLKI-enabled cores.
23
-
24
-
For CEP v3.1+, the full LLKI has been added. This includes the Surrogate Root of Trust (SRoT) and mock Technique Specific Shims (TSS) for all accelerator cores.
22
+
The Lincoln Laboratory Key Interface (LLKI) has been provided as a representative means of distributing key / configuration material to LLKI-enabled cores.
25
23
26
24
### Please check the [Release Notes](./RELEASE_NOTES.md) to understand what has changed and a list of known issues.
27
25
@@ -206,7 +204,7 @@ See ./cosim/drivers/diag/cepMacroMix.cc for example code.
206
204
207
205
As one might be aware: the endianess usage is not consistent thru out the design, expesially where Chisel wrappers are used to connect to various HW cores. For some cores, little endian is used for loading keys/plain text but big-endian is used to produce cipher text as output. This creates confusion and inconsistent as one might try to understand/follow SW driver for these cores. Also, please note, RISCV is little endian.
208
206
209
-
As of release CEP v2.4 and later, unless otherwise specify, big endian is used thru out the design to match key/plain/ciphertext network order.
207
+
Unless otherwise specified, big endian is used thru out the design to match key/plain/ciphertext network order.
210
208
211
209
This makes it consistent and easier to debug when key/plain text are printed to match against registers.
212
210
@@ -311,11 +309,15 @@ make install append
311
309
312
310
If subsequent changes are made to the source code in <CEP_ROOT>/cosim/drivers/linux, simply copy the changes over to the Linux build by running `make install`.
313
311
314
-
Next, one needs to build linux. First, change to the `<CEP ROOT>/software/freedom-u-sdk` directory. Ensure that the linux variant of the RISC-V toolset is used by executing `unset RISCV`
315
312
316
-
For Ubuntu 18.04 LTS, the default PERL installation may cause a conflict with the build process. You may need to execute `unset PERL_MM_OPT` if set.
313
+
Next, one needs to build linux. First, change to the `<CEP ROOT>/software/freedom-u-sdk` directory.
314
+
315
+
A few cautionary notes:
316
+
- Ensure that the linux variant of the RISC-V toolset is used by executing `unset RISCV`
317
+
- For Ubuntu 18.04 LTS, the default PERL installation may cause a conflict with the build process. You may need to execute `unset PERL_MM_OPT` if set.
318
+
- If you patched the LIBRARY_PATH environment variable to allow for compilation of the Xilinx simulation libraries, this may cause the linux build to fail
317
319
318
-
Begin the build by running `make -jN BOARD=vc707devkit_nopci all` where N is the numbers of cores you can dedicate to the build. Ensure that you have NOT sourced the Xilinx Vivado environment setup script before running this step.
320
+
Begin the build by running `make -jN BOARD=vc707devkit_nopci all` where N is the numbers of cores you can dedicate to the build.
319
321
320
322
Following the linux build, which can take 30 - 60 minutes, you will have a binary which you can load onto an SD card.
321
323
@@ -342,7 +344,7 @@ You should see the following logo/text appear:
@@ -428,7 +430,7 @@ The following cores have been integrated into the "standard" CEP build:
428
430
- Infinite Impulse Response
429
431
- GPS code generator
430
432
431
-
Beginning with the v2.4 release, the following "generated" cores have been added to the repository, but are currently not integrated into the CEP build.
433
+
The following "generated" cores have been added to the repository, but are currently not integrated into the CEP build.
Copy file name to clipboardexpand all lines: cosim/README.md
+18-6
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
7
7
# README for CEP co-simulation environment
8
8
9
-
This SW/HW co-simulation evironment has been developed to support "chip-level" simulation of the CEP.
9
+
This SW/HW co-simulation evironment has been developed to support "chip-level" simulation of the CEP.
10
10
11
11
Several environments are supported:
12
12
@@ -25,19 +25,19 @@ Several environments are supported:
25
25
26
26
* SW and HW are de-coupled such that mistakes that are found in the test/driver (SW side) during development process can be quickly corrected and rerun without having to rebuild the HW. Sometimes, it might takes minutes (or even hours for big ASIC) just to rebuild the HW if test and DUT (Device Under Test) are tightly coupled
27
27
28
-
* Makefile is setup to support vendor independent designs such that same design can be used to target FPGA vendor as Xilinx or TSMC for ASIC, for example.
28
+
* Makefile is setup to support vendor independent designs such that the same design can be used to target an FPGA vendor such as Xilinx or TSMC for ASIC.
29
29
30
30
* To take advantage of multi-core machines, support up to 4K+ threads where all threads can run in parallel and target different HW sections. For example: one core can target the AES block while another core targets the FIR block, etc...
31
31
32
32
* Mailboxes are setup to support in between thread communication for synchronization, handshaking, etc...
33
33
34
-
* All are *makefile* driven with scripts to support auto-dependencies generation. Which means anything changes in either HW files or SW files: incremental builds will be called to save time. This is a must in order to support parallel batching.
34
+
* All are *makefile* driven with scripts to support auto-dependencies generation. Which means when anything changes in either HW files or SW files, incremental builds will be called to save time. This is a must in order to support parallel batching.
35
35
36
36
* Provide 100% visibility to everything in the test bench via wave capturing. From the SW (test) side, any signal in HW can be observed and forced (for negative testing) or to be used to synchronize events (wait for something before sending packet, etc...)
37
37
38
38
* Same setup can be used for any design. Therefore, it takes only hour to set up new test bench for new design and let designer/verification engineers start writing tests right away.
39
39
40
-
* Most of the tests can even be re-used across multiple projects such as memory test, register tests, packet generator and checker. They are written as template where only simple read/write methods need to be overload.
40
+
* Most of the tests can even be re-used across multiple projects such as memory test, register tests, packet generator and checker. They are written as templates where only simple read/write methods need to be overload.
41
41
42
42
* Open source codebase
43
43
@@ -66,7 +66,19 @@ For CEP, the path to tools required are as listed below (see **common.make**)
**NOTE**: If they are not matched your setup, dont need to edit the common.make file, use enviroment variables to override as such (assuming bash shell is used).
69
+
As of release 3.2 or later, Cadence tool set is also supported, all setup related to Cadence tool set can be found in `cadence.make`
70
+
71
+
If you decide to use Cadence's xcelium for simulation, modify cadence.make or override with environment variables to match the below variables:
**NOTE**: If they are not matched to your setup, you dont need to edit the common.make file. Instead, use enviroment variables to override as such (assuming bash shell is used).
70
82
```
71
83
export VIVADO_PATH=<Your_path_to_Vivado_tool>
72
84
export SIMULATOR_PATH=<Your_path_to_questa_tool>
@@ -116,7 +128,7 @@ You should see something like this under *cosim* directory:
116
128
117
129
## Compiling the Xilinx Simulation Libraries ##
118
130
119
-
**NOTE**: xil_lib is the generated library packages created via vivado's compile_simlib command. Not all Vivado / Modelsim version combinations yield the desired result. See the following notes:
131
+
**NOTE**: xil_lib is the generated library packages created via vivado's compile_simlib command. Not all Vivado / Modelsim version combinations yield the desired result. See the following notes:
120
132
- When Vivado 2019.1 and Questa 2019.1 is selected ,the compilation will stop and not generate the appropriate modelsim.ini file, which is required by the co-simulation environemt.
121
133
- When Vivado 2018.3 and Questa 2019.1 (or Quest 10.7c) is selected, the compilation will return with an error in the qdma_v3_0_0 library. This library is not required for CEP simulation and thus the error can be safely ignored.
122
134
- When Vivado 2018.3 and Question 10.6c is selected, the compilation will complete without error. However, it is recommended that Questa 2019.1 be used in order to take advantage of optimizations and bug fixes.
0 commit comments