Skip to content
DPI protected Verilog proof of concept
SystemVerilog Makefile C++ Tcl
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.gitignore Add XSim Tcl test Aug 12, 2019
LICENSE Initial commit Aug 7, 2019
Makefile XSim works now Aug 14, 2019
README.md Add TODO list Aug 19, 2019
foo.cpp Actually copy all the data Aug 20, 2019
foo.sv Actually copy all the data Aug 20, 2019
foo_impl.sv Actually copy all the data Aug 20, 2019
foo_tb.sv Actually copy all the data Aug 20, 2019
tb.cpp Initial commit Aug 7, 2019
xsim.tcl Add XSim Tcl test Aug 12, 2019

README.md

DPI protected Verilog proof of concept

A non-broken and open source friendly way to distribute protected Verilog simulation models.

The basic idea

Encrypted Verilog is unusable to open source tools like Verilator. Beyond that, the Verilog encryption scheme is basically worthless. See https://acmccs.github.io/papers/p1533-chhotarayA.pdf for futher details. Or if you prefer more practical evidence, spend a little while researching actual attacks on encrypted RTL.

This is a proof of concept for a utility which would use Verilator to compile a protected Verilog module into a DPI-accessible shared object. While the compiled object could be analyzed, this approach provides little to no opportunity for the plaintext Verilog to be exposed.

Beyond compiling the protected module, the tool would do the following:

  • Create a black-box Verilog wrapper to be instantiated by the end user
  • Create a C++ wrapper for the library

The black-box module will call imported DPI functions which the shared object will implement. Given this, the IP provider would deliver the black-box Verilog module and the compiled shared object to the end user. The end user would then instantiate the black-box module and pass the shared object to the DPI-capable simulator of their choice. The protected Verilog will not be visible to the end user, but they will be able to simulate it and observe the I/O.

Things this doesn't attempt to solve

  • Protected VHDL simulation models (though something similar is probably possible via the FLI)
  • Protected RTL for synthesis, etc.

Issues/Things to do

  • Continue researching to verify this doesn't already exist
  • Determine if there are any fundamental flaws in the idea
  • Figure out if this would be part of Verilator or a separate tool
  • Research obfuscation techniques on compiled C++
  • Analyze clocks, etc. to minize unnecessary DPI calls in the wrapper module
  • Advertise these details (e.g. clocks) for Verilator and other simulators to improve scheduling
  • Handle parametric modules by enabling Verilator to create classes with constructor-time parameters

The last one is a doozy. However, it could have potentially useful knock-on effects. Mainly, it would allow Verilator users to avoid separately compiling large designs with different parameters. Of course, it would be quite complicted to implement and would probably have run-time implications.

Example

A simple example is provided to demonstrate how this would work. foo_impl.sv is the module the IP provider whishes to protect. foo.sv and foo.cpp have been constructed by hand, but the proposal is that a tool would generate them. foo_tb.sv and tb.cpp comprise an example testbench which demonstrates the functionality of this proposal, but would be outside the scope of the tool.

Trying it out

Simply run the following:

make
make run

You may need to set VERILATOR_ROOT depending on your Verilator installation method.

See also

There's been some discussion of this project here: https://www.veripool.org/boards/3/topics/3037?r=3042#message-3042

TODO

  • Handle C++ ABI differences (maybe build multiple libraries?)
You can’t perform that action at this time.