IEEE P1735 Draft Development Committee Meeting of June 17, 2013

Meeting Info

Conference Bridge and Live-Meeting

Participants

• Attending
  • Steven Dovich, (chair) Cadence DR
  • Jeff Fox, Altera DR
  • Dave Graubart, Synopsys DR
  • Dave Clemans, Synopsys DRA
  • Michael Smith, Synopsys DRA
  • Ray Martin, Xilinx DR
  • John Shields, Mentor DR

• Not Attending
  • Jarek Kaczynski, Aldec DR
  • Devin Sundaram, Altera DRA
  • Joe Daniels, P1735 Technical Editor
  • Krista Gluchoski, IEEE Professional Services
  • Parminder Gill, Synopsys DRA
  • Premduth Vidyanandan, Xilinx
  • Nick Sgoupis, CAST
  • Albert Chiang, Synopsys
  • Nitin Khurana, Cadence DRA
  • David Pena, Cadence
  • Bin Dai, Xilinx
  • Ruchi Tyagi, Cadence DRA
  • Syed Huq, Cisco
  • Meera Srinivasan, Synopsys
  • David Tran, Synopsys

Agenda

1. Patent slides
2. Comment and Open Issue review
3. Adjourn

Minutes

Patent Policy

The Patent slides were offered for review.

No new claims were disclosed at the call for essential patent claims.

Comment and Open Issue review

Dave has closed on consensus for the condition expressions, following the proposed syntax from John. The syntax description will appear in a fresh draft of that clause. John will retain the definition of the activity and toolphase conditions. The License Management clause will define the license condition.

John identified the boolean vs string return from the License API as still pending.

Our current draft on visibility proposes to improve the viewport pragma. This was an existing pragma, not well defined or supported, and not part of version 1 interoperability. A bit of a mess. The revised pragma will be a required part of version 2. The improvements in the draft make it interoperable and define P1735 expectations for what that means. One semantic issue it addressed, for example, is that viewport is strictly concerned with whether a named object in a protected region is visible or not. (It removes the idea of what kind of access is allowed.) The draft was conservative and kept the notion that viewport can only refer to objects by name in the protected source code. The next draft revision would clarify what objects could be named and discuss name syntax. It would state some things that are tacitly understood, such as the fact that the pragma must appear in the same decryption envelope as the declaration of the object it makes visible. All well and good.

The recent discussion on visibility use cases for common rights asks for better mechanisms to address interface visibility. That is a great suggestion and the willingness to improve the functionality is welcome. I'd like to see if it's real. There is also a good case to be made for a very simple form of the pragma that applies positionally to protected source. Let me outline all this and solicit feedback.

`protect viewport - this is the expected form, where a single object is referenced. The name could refer to a net, signal, variable, etc. The reasonable extension is to allow it to refer to a larger set of declarations. It could refer to a module or design unit and mean that the entire declaration should be visible.

`protect interface_viewport - is a new pragma that makes only the interface of a named object visible. This would allow only a module interface to be made visible, which addresses the use case that was raised. It is not the only way to accomplish this kind of visibility (as was noted in the common rights draft 3), but it does allow it without being dependent on source code organization. We cannot force anyone to organize their source code a particular way, but we can recommend good practice. This closes the gap on controlling what interfaces are visible. More detail needed, but the idea is clear.

`protect_viewport and `protect interface_viewport - This is a form of the 2 pragmas above, where the argument is optional. It makes the declaration that follows visible, simple as that. This positional association is common with pragmas and makes it possible for the designer to simply express this intention without name lookup. Fast to process, nice maintainability properties.

There is a still a lot of work to properly specify all the above. One has to avoid dictating what can and cannot be made visible. We don't want to create a form of the problem we currently have with encryption envelope granularity. Given that we intend viewport to work for objects and have design unit granularity well supported, I do not think this is an onerous issue. I would suggest that it remain confined to complete declaration of objects, some of which have well defined interface and implementation. It could not refer to types or other non-object declarations and we would have an error or warning expected. I am inclined to say no subset (slice, bit, or fields) of a composite object either (please weigh in on that). It would allow and expect 1076, 1800, (and any other IP representation) to suitably restrict or clarify what declarations it may be applied to, which is otherwise beyond our scope. I should say the groups have still asked us to make the recommendations to them.

What you get, big picture, is a flexible viewport protection mechanism with the ability to open any reasonable viewports into protected IP . It is cohesive to that IP and properly maintained with the maintenance of the IP source code by the IP author. It has the correct separation from rights, which itself is policy for what can be done with the IP using a particular set of tools. That policy should have cohesion with the tool capabilities and business model the IP authors want to support, but not the kind of cohesion that involves references into the IP by name that must be maintained in lockstep with the IP.

Before I invest the time this will take, I would like feedback from the WG that this is what they want. I am not stuck on these pragma names or arguments for additional flexibility. I would like to know ASAP if someone has a serious objection.

The group discussed interaction between preservation controls (for transformative tools) and visibility controls. Steven suggested that these should be orthogonal and that visibility controls should apply if the referenced objects existed in the protected IP. IP authors ought to be responsible for composing those controls to deliver their desired behavior. John suggested that an alternate would be to make the preservation control an IP user responsibility, since the viewport made the object visible to the IP user.

John noted that transparency could be addressed with the technique from the SV standard, where the viewport could be replicated outside the data_block for documentation, but the viewport inside the data_block controlled the visibility.

As you know, visibility from protected regions is not well defined in the LRMs. We have 2 mechanisms. We can use disjoint protected envelopes or the viewport pragma to open up an aspect in an otherwise protected envelope. Let's assume the simple use case of an internal object, a wire or signal in the implementation of the IP. Either of these mechanisms can work, even though we have recommended not to use disjoint envelopes. My first point is they should have consistent behavior. Wherever a viewport pragma has an effect, it could also have been expressed equivalently with disjoint protected envelopes. I will state that in the visibility clause.

If I make an object visible, the IP user can access it freely. It has a name, a location in the design hierarchy, a value, and a type. All of this needs to be understood for tools to provide access for logging, debug, and general tool outputs. It is necessary to define this carefully. Consider the pathname of the object and in general the path to the object. It should be visible to the user in tool outputs and user queries. It is not an issue in common cases where the object in question is declared in a design unit that is directly instantiated by the IP user. The instance path to the object is entirely in the user's code.

Is it really an issue when the object is buried deeper in the design hierarchy of the IP? The use case is a decision on the IP author's part to explicitly make this object visible. It is necessary that the user be able to reference it, so the pathname to the object matters and must be disclosed, right? I believe the correct visibility semantics are that the instance path to the object is made visible by making an internal object visible. This is my second point. It is easy to propose an alternate requirement that a tool must track and subdivide paths to visible objects such that they never display protected portions of a path, but is that is really valid? Moreover, can tools really afford to build it?

My third and last point is that we need to propose what "access it freely" means and recommend what kind of objects can be made visible in HDLs. It is a subset of the declarations in the languages and likely restricted to a subset of the possible declarative regions. I do not think this is hard to do and it will be expressed as recommendations to HDL WGs. They will likely incorporate it by reference but will be free to extend or restrict it.

I need feedback on these 3 points please.

The group discussed Dave's feedback, and the possible impact of the PLI protection model from P1800. Steven agreed to upload the PLI model text to the Wiki as a shortcut for those wanting to understand it.

Work Plan

Date	Clause	Title	Champion	Status
7/15	1	Intro	Steven
7/8	2	Normative Ref	?
7/12	3	Definitions	?
7/16	4	Trust	Steven
7/19	5	Interop	Ray
7/17	6	Key Mgmt	Steven
6/21	7	Rights Mgmt	Dave G	done
7/8	8	License Mgmt	Dave G
6/28	9	Common Rights	John	done
7/10	10	Visibility	John
7/8	A	Bibliography	?
6/28	B	Required Algorithms	?
4/25	X	Visbility Annex	John	done

Next Meeting

The next Draft Development Committee meeting is scheduled for July 29, 2013 at 16:00UTC.

Tentative Agenda

1. Patent slides
2. Comment and Open Issue review
3. Adjourn

Adjournment

Meeting adjourned at 16:35UTC

Approval

These minutes are unapproved.

-- StevenDovich - 2013-07-15