Intel Ampcrypt Module Hierarchy

[mdidomenico3]

Hello,

I am using ampcrypt to encrypt a design for a third party user, and have found that while the encrypted file cannot be viewed in Quartus, as plain text, or in the RTL viewer tool, when running analysis and synthesis, Quartus Prime Standard reports a message in the following format:

Info (12128): Elaborating entity "encrypted_entity_name" for hierarchy "full:encrypted|entity:hierarchy|with:all|module:names"

Is there any way to disable these messages, either through the encryption method or the license? To me, it seems like displaying the entire system hierarchy for an encrypted module somewhat defeats the purpose of encrypting (even though the full source is not available).

For completeness, I'd additionally appreciate any information I would need to ensure that any design details other than the top level encrypted module name and port interface is hidden from the user.

Thanks in advance!

[RichardTanSY_Intel]

Let me check this with the tool administrator.

Regards,

Richard Tan

[mdidomenico3]

Great, thanks! Any update on this?

[RichardTanSY_Intel]

Sorry for the wait. The Quartus tool development team is looking into this and plans to implement it in a future Quartus release (may subject to change based on priority/resources).

I am checking with them to see if there is a way to hide the elaboration message in the current Quartus Standard.

If that is not possible with the current quartus, I would suggest have a combination of a license agreement between the IP provider and their customer, and encrypting the IP to prevent IP theft.

Please keep in mind that any work involving our developer team may take some time, ranging from a few days to a few weeks, depending on the complexity of the issue.

Regards,

Richard Tan

[mdidomenico3]

Hi Richard,

Just to clarify, the IP source is already encrypted with ampcrypt, and while the design input text files are not readable, once the design is built, Quartus Standard 17.0 reveals the names of modules, signals, etc., in timing analyzer, signal top node finder, and even in the technology map viewer, which is definitely a concern. An end user being able to see the technology map view of the IP core would be able to get a good understanding of how the encrypted IP works even if they can't see/modify the source code.

Please let me know if there is anything I could be missing to prevent Quartus from revealing information from the encrypted files.

Thanks!

[RichardTanSY_Intel]

Yes, this is expected. For some encrypted IP cores, the ability to tap internal nodes is considered a feature, while for others, it is seen as a security vulnerability.

I believe this was discussed years ago, and a potential solution was considered—allowing IP providers to decide whether their signals could be tapped on a customer’s machine. However, due to the complexity and high development costs, this proposal was ultimately rejected or put on hold.

Unless there is a strong business justification, this is unlikely to change, especially for Quartus Standard, which is currently in maintenance mode.

I'm not sure if obfuscation would provide much protection. While it may add a layer of difficulty for reverse engineering, users would still be able to use SignalTap to extract some level of information.

Regards,

Richard Tan

[RichardTanSY_Intel]

After exploring the possible workarounds, there are currently two ways to suppress the message.

1. Using the QSF Assignments

Add the following assignments in your .qsf file:

set_global_assignment -name MESSAGE_DISABLE <value>

set_global_assignment -name MESSAGE_DISABLE -entity <entity name> <value>

set_instance_assignment -name MESSAGE_DISABLE -to <to> -entity <entity name> 

Note: <value> refers to the Info ID of the message you want to suppress.

2. Using the GUI

Open the GUI and suppress the message as shown in the snapshot. A .srf file will be created in the design folder.

The next time you run the design, the suppressed messages will no longer be displayed.

However, if the customer removes the QSF assignments or the .srf file, the message will reappear.

This method is not a foolproof encryption solution but merely a way to suppress the messages.

Regards,

Richard Tan

[RichardTanSY_Intel]

Do you have any further inquiries regarding this case?

Regards,

Richard Tan

[RichardTanSY_Intel]

I believe your inquiries has been answered.

With that, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. Please login to https://supporttickets.intel.com/s/?language=en_US , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

The community users will be able to help you on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan

[RichardTanSY_Intel]

I found out that to disable a warning message in standard, you can set the following pragma at the beginning of the verilog file:

// message_off <id>

So in this case, you can set 

// message_off 12128

in the beginning of all the verilog files

Reference: https://www.intel.com/content/www/us/en/docs/programmable/683283/18-1/enabling-or-disabling-specific-hdl-messages.html

Regards,

Richard Tan

[mdidomenico3]

Thanks for all the information. Just to summarize, there's no way to prevent a user from seeing entity/node names within the encrypted module in signal tap, technology viewer and timing analyzer?

[RichardTanSY_Intel]

Yes. There is no foolproof way to completely hide entity/node names within an encrypted module from tools like Signal Tap, Technology Viewer, and Timing Analyzer in Quartus. While encryption protects the RTL source code, Quartus must still synthesize the design. 

Regards,
Richard Tan

[Kenny_Tan]

case reopening