Intel Ampcrypt Module Hierarchy

Let me check this with the tool administrator.

Regards,

Richard Tan

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

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

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

Do you have any further inquiries regarding this case?

Regards,

Richard Tan

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

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

case reopening