Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

protected_lib related #2165

Open
fuyong10 opened this issue Feb 12, 2020 · 10 comments
Open

protected_lib related #2165

fuyong10 opened this issue Feb 12, 2020 · 10 comments
Labels
new

Comments

@fuyong10
Copy link

@fuyong10 fuyong10 commented Feb 12, 2020

Have tried protected_lib, it works!

Two comments:

  1. Any way to turn off protection? To instantiate a verilated IP in SOC does not always mean to stop the visibility inside. To give the VCD file of a full SOC to the IP developer can help the developer debug quickly. Meanwhile, the source code of that IP can still be maintained by the developer.

  2. What if an IP has been instantiated several times with different parameters?

@fuyong10 fuyong10 added the new label Feb 12, 2020
@toddstrader

This comment has been minimized.

Copy link
Member

@toddstrader toddstrader commented Feb 12, 2020

Great, I'm glad to hear that it's working for you.

Currently the protected library does no tracing of its own. My thought for allowing the IP developer to see what's going on is in #1523 (currently being worked on in #2118). Basically, the end user would generate a trace of what they are doing with the IP and ship the trace (or just the part of the trace which interacts with the IP) to the IP developer who would replay the trace data through their unprotected version of the IP.

However, I gather you're suggesting something else with # 1. Are you suggesting a mode where the RTL of the IP core will still be protected, but it will trace all of its internal signals without any kind of protection/encryption? If I'm understanding this correctly, it can't be done today, but this feature could be added in the future.

One significant caveat here is that we protect the signal names in the verilated C++ that will be compiled into the protected library by having --protect-lib imply --protect-ids. You can certainly override that on the command line so that you get unprotected signal names in the protected library, but that opens the door to more reverse engineering on the compiled IP library. I'm curious, do proprietary simulators have an analogous feature where they can trace plain text signal names of encrypted RTL? And is this something IP vendors can opt into when encrypting their RTL? If so, they'd be susceptible to the same reverse engineering.

Regarding # 2, that's certainly the biggest issue with --protect-lib at present. #1522 is tracking this, but I'm afraid that will be a pretty long-term project. If you have a reasonably small set of parameter permutations, my current suggestion would be to ask your IP vendor to provide you with a compiled library for each permutation (i.e. the vendor sets the parameters you supply).

Some additional thoughts on # 2 can be found in the talk I gave at ORConf last year on --protect-lib:
https://www.youtube.com/watch?v=0D2982U84Oo
https://www.veripool.org/papers/protect-lib-orconf-2019.pdf

@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Feb 12, 2020

For 1, note @toddstrader is suggesting to use --protect-lib --no-protect-ids (in that order).

For 2, if you don't mind Verilating multiple times, you could work around this by make a model for each parameterized "flavor"; use the -P argument to Verilator to specify the parameter values, and make sure to use a different model name for each flavor.

@toddstrader

This comment has been minimized.

Copy link
Member

@toddstrader toddstrader commented Feb 12, 2020

For 1, note @toddstrader is suggesting to use --protect-lib --no-protect-ids (in that order).

This would un-protect the symbols in the protected library (i.e. you can see them with the strings command), but it won't add trace data for the protected core in the VCD/FST of the instantiating design. I believe this is the correct default behavior, namely that protected IP shouldn't expose anything (including scrambled signal names) in the trace data other than its I/O.

However, if this is desirable, I can look at adding an option for the IP vendor --yes-trace-signals-in-the-instantiating-design (but with a better name). This does intersect with #1518, so we'd have to figure that out first.

@fuyong10

This comment has been minimized.

Copy link
Author

@fuyong10 fuyong10 commented Feb 13, 2020

thanks Tod and Wilson. Sorry I did not make the suggestion well. My intention is to compile IP(s) without protect, and then integrate the verilated IP(s) in the full SOC.

The usage scenario is not about the IP from 3rd vendor, rather for the internal design group. Ex:
FULL_SOC
IP #(param1, param2..) IP_instance_1 (...)
IP #(param3, param4..) IP_instance_2 (...)

Assume this is a big SOC, from compile time, Verilator's capability of handling large design, to verilate IPs first, and then instantiate into full SOC. SOC compile only take the reset of design, so might be easier than the full thing. But at run time, hopefully the waveform of full design including the IPs can be generated.

I re-visited the forum and see quite several threads related to:

  1. To use VCS/IUS together with Verilator. I assume DUT is varilated, and testbench with DPI calls are made so connect with VCS/IUS. However, the protect-lib wins since:
    a. protect_lib take care of the DPI and wrapper automatically
    b. the clock analysis etc are done by tools, so does the evaluation way.
    c. Also a nice thing is protect-lib can support multiple clocks! (correct if I am wrong. I played with tracing_c example by turning sub.v into protect_lib. Module sub has clk and faskclk)
    Seems like there are people use VCS+Verilator successfully.
  2. Embedded IP. This is very close to what I think. I noticed there is a test case, test_regress/t/emdeded* and will play with it.
  3. Somehow remember there is a limitation says, one Verialted IP can be be instanciated by another verilated IP? For example, verilate "IP" mentione above, and then want to verilate "FULL_SOC" with "IP" inside.
  4. Also recalled the challenge of handling the comb logic output if the comb logic input is the primary input of the IP. Or needs several eval() here can solve this issue but with the performance downgrade.

Seems like to verilate a FULL SOC with some of its IPs being verilated first is a challenge.

@fuyong10

This comment has been minimized.

Copy link
Author

@fuyong10 fuyong10 commented Feb 13, 2020

example modifed with tracing_c:

verilator -cc -02 --protect-lib verilated_ip -Mdir obj_dir_ip sub.v
This command works, intention is to verilate module "sub" and put into a lib "verilated_ip"

Add --no-protected-ids:
verilator -cc -02 --protect-lib --no-protected-ids verilated_ip -Mdir obj_dir_ip sub.v
%Error: Cannot find file containing module: verilated_ip

could not find doc for --no-protected-ids, surely my command is incorrect. Any hints here. Thanks,

@toddstrader

This comment has been minimized.

Copy link
Member

@toddstrader toddstrader commented Feb 13, 2020

Changing your command to:
verilator -cc -02 --protect-lib verilated_ip --no-protect-ids -Mdir obj_dir_ip sub.v
will at least get you past your current error. --protect-lib takes an argument (verilated_ip) in this case so you need --no-protect-ids to come after that argument. Also, you can find --protect-ids in the manual and --no- before a boolean switch just negates the switch.

But yes, if your intention is to use --protect-lib to reduce compile time on a large design you are correct that there are some challenges. I think your list summarizes things well, but I'm not sure I know what # 3 is referring to. Perhaps a link to the thread would help here.

Also, even with the above command you won't get signals from the protected library in your top-level trace file. I modified test_regress/t/t_prot_lib.pl similarly and confirmed this. The reason is the generated C++ does nothing with respect to tracing. This might be the simplest change to make in the direction I believe you are trying to go. If you're interesting in submitting a PR for this or anything else --protect-lib related please let me know and I can try to supply some pointers.

@fuyong10

This comment has been minimized.

Copy link
Author

@fuyong10 fuyong10 commented Feb 14, 2020

verilator -cc -02 --protect-lib verilated_ip --no-protect-ids -Mdir obj_dir_ip sub.v
=> This command works!
You are right, I did not get the signals.

OK, my original intention :

tesbench   <= some complex SV here, so would like to run in VCS or IUS 
     dut       <= verilate dut , and hopefully can have SV/DPI so can be compiled together with testbench in VCS/IUS
          IP1   <= want to verilate as an IP
          IP2    <= want to verilate as an IP

I also learning the dpi_compile_master example. Let me re-think the initial idea and maybe manually make an example and share. Any example that might help are welcomed.

@toddstrader

This comment has been minimized.

Copy link
Member

@toddstrader toddstrader commented Feb 14, 2020

Agreed that an example would be beneficial here. Also, for additional reference beyond the examples directory you may want to look at test_regress/t/t_prot_lib* if you haven't done so already.

@fuyong10

This comment has been minimized.

Copy link
Author

@fuyong10 fuyong10 commented Feb 14, 2020

Thanks tod, will look at the example.

By the way, have saw several examples. Many if not all are using two phases eval(). In your example, verilated_secret.sv, you have calls of *_combo_update() and *_seq_update(). Well, more eval() in one simulation time can always yield "stable" and more predictable result. But just curious, if Verilator has been schedule the data path statically, will one eval() after clock tick (in *_seq_update) be good enough? Since verilator is called cycle based, so can I assume that each eval(), regardless of how many input has changes, will always run through all the evaluations, so consume same CPU time?

@toddstrader

This comment has been minimized.

Copy link
Member

@toddstrader toddstrader commented Feb 18, 2020

The reason eval() may be called more than once a cycle is that the testbench (e.g. C++ code) can respond combinatorially. In other words, you may change your stimulus to the DUT based on something the DUT is doing within the same clock cycle. This would require you to call eval() again because the DUT hasn't seen the new stimulus.

--protect-lib calls eval() multiple times per cycle for related reasons. I.e. if there were a combinatorial path through a protected library, we can't wait for a clock edge to evaluate it because that would be too late.

Reducing the number of times eval() is called is on the list of things to do for --protect-lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.