We had a discussion of IP-XACT recently and asked ourselves how does this work with protected IP. I think it presents yet another use case for the visibility issue. The general issue is, what needs to be visible within protected ip to support reasonable use and how is that defined/controlled by the IP author. IP-XACT presents a possible way to make information about a protected IP known and maybe, by implication or some specific mechanism not yet defined, prescribe visibility. In my mind, that is a catch-22 and fixing the visibility problem independently will make the IP-XACT information usable with protected IP.

There are other bug bucket use cases for visibility. I'll tag them here without explanation

  • references from UPF files into protected IP
  • SDF files that apply to protected IP
  • user instantiation of design units in protected IP
  • hierarchical references into protected IP
  • use of SV bind statements to reference protected IP ( SV or PSL assertions)
  • error/warning messages from tools related to protected IP

The context we have in P1735 is that the IEEE encryption has done little to address the visibility issue and has sort of defined a baseline requirement that nothing be visible unless it is necessary for proper operation of the tool. The mechanisms for visibility that exist today are simplistic and ill-defined. Take your HDL and protect disjoint but related pieces with the pragmas, use the viewport pragma, or allow some implicit visibility in the spirit of proper tool operation.

The disjoint protection is definitely ill defined. That has to be fixed, but the result is not likely to help with these big visibility use cases. The viewport pragma is similar, in my opinion. Beyond that, the IP authors have stated a flow requirement for protecting IP. They develop and maintain it unprotected in house. When it is validated and golden they do not want to touch the HDL source in order to decorate it with protection pragmas. They prefer to apply protection with the pragmas encapsulating all IP or otherwise just be specified externally. Is that lazy? Amongst other things, that means basic visibility of design units for instantiation by the user has to be considered an implicit visibility or nothing would work. The flow requirement, I might add, could be met by allowing/requiring IP authors to embed the protection and visibility pragmas in their HDL and ignoring them during development. It could still be a lot of touch labor for them to explicitly make design units visible with viewports or disjoint protection pragmas. Where is the value in that as a mechanism?

I believe we need to acknowledge some classes of visibility that can be applied to the protected IP as a whole. They may be implicitly defined defaults or expressly defined in new pragmas. I don't want to overdo the details of how this might be expressed.

One aspect is to allow visibility to make references to protected IP objects from outside the IP whenever you know the name of the object. The names are obsfucated or hidden in the protected IP, but encryption is not a lossy transformation. If the IP author provides the information in their documentation, IP-XACT specifications, supporting UPF files, then just allow it to work for reasonable use cases. I have to say that tool vendors today have decided to do just that in some measure. If that were not true, some of the visibility use cases I mentioned would be show stoppers today. That is also not a violation of the LRM ; it is just a lack of standardization.

Another aspect to consider is restricting some implicit visibility to certain execution phases of a tool. For example, most of issues with user instantiation, hierarchical references, bind statements, etc. could be satisfied by allowing implicit visibility up to the end of elaboration. My point is that narrowing visibility by execution phase has merit.

Finally allowing tools to refer to named objects in error and warning messages is a clear tradeoff on usability and exposure of some of the IP internals. Does it present a compromise that devalues the IP or allows it to be stolen? IMHO, almost certainly not. But other business reasons may require the IP deliverer to hide the fact that some of the IP they provide really comes from further down the IP food chain. That paranoia about pathnames exposing a business relationship may be enough to choose to keep all errors and warnings mostly useless. I expect IP authors to need control here. Today there is none and the tool vendors have to choose, with erring on the side of hiding information being the norm.

This doesn't address everything, but we have to start considering visibility as a key problem and build some consensus on the acceptable mechanisms for dealing with it. I propose that we need classes of visibility and mechanism for IP authors to emply them. Further, we will subsequently need to fix the disjoint protected region semantics and viewport pragma.

The issue of encrypting all the related side files, IP-XACT, SDF, UPF, etc. is interesting but is also a huge flow issue and probably pretty costly. We better be able to articulate what the value proposition is. Even if there is one, I see the visibility problem as needing a fairly independent solution anyway.

- JohnShields - 2010-07-23

Topic revision: r1 - 2010-07-23 - 15:46:12 - JohnShields
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback