RE: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and Encryption Donation

The fundamental principle at issue here is "lexical" vs "syntactic"
placement of the protected region.

In "lexical" placement you allow the beginning of protected region at
any location a new lexical element is allowed. This provides maximum
flexibility in what is protected or not. For instance you may have the
ports of an entity and a few internal registers that you want to be
visible to a user and can leave just those elements in clear text.

The current specification overloads the use of the "comment" lexical
element to allow the pragmas as we have chosen lexical placement. If we
don't want to overload comments in this way (and I agree that it is
dangerous), then it may be more appropriate to bring a new lexical
element into existance.

In "syntactic" placement you would actually change the BNF of VHDL to
specify exactly where in the syntax the encrypted regions may fall. This
is a really hairy proposition. You have to walk through the entire
grammar and make judgements about what specific constructs a user may
want to encrypt and then wrap them syntactically. If you do this
exercise (and I have) you end up with a new syntax that looks something
like a block statement scattered all over the BNF. Some of the sick
cases are things like allowing a subprogram declaration in a package
body to be visible, but protecting the declarations and sequential
statements inside of it or allowing visibilitiy over a generate index
but not the contents of the generate.

The situation that most people are familiar with where this exact same
issue prevails is the -- synopsys translate_on/translate_off macros.
These are treated by most tools as "lexical" elements, they essentially
create an "ifdef" around the region as if the text inside it never
existed. We see users all the time who surround strange parts of a
design with these. For instance, the initial value of an object,
configuration specifications, or individual statements.

As for VHDL attributes, they would imply a "syntactic" placement.
Attributes are always associated with a particular object. So if we
invented a bunch of encryption attributes you could say something like

        B : Block
                variable CONDITION_CODE : std_ulogic(3 downto 0);
        begin
                ....
        end block;

You could then declare some attribute (pardon the syntax):

        B'protected(xxxx);

And it would specify that B was protected, but what if you wanted
register CONDITION_CODE inside of B to be visible, but everything else
protected? It becomes very confusing.

I believe that we can not possible predict all the places that users
will want to intermix cleartext and encrypted text and therefore
"lexical" placement is the best choice.

If there is consensus that a new lexical element need be defined for
introducing the pragmas then I believe that this should be a general
addition to VHDL (BTW, Verilog needs it too). For instance a new
compound delimiter such as -| could be used it would define the
beginning of a pragma. This could be used to standardize pragma usage
within the language.

        entity Foo -| protect begin
                -| translate_off
                -| translate_on
        end Foo; -| protect end

Note that the word "pragma" or "synopsys" is no longer necessary because
the tool knows that what follows is a pragma.
        
This also has the benefit that if a given tool doesn't understand a
pragma it could issue a warning and ignore it gracefully.

The next logical conclusion is that pragmas would be declared:

        package Encryption
                pragma protect;
        end package;

Now the set of pragmas in the language can be defined in the language
standard itself, and even leaves room for user-defined pragmas. The only
minor complication of this approach is that the use of such a pragma
would be lexical and the definition syntactic.

Sorry for the long winded comments ...

Jay

===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================

> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Marcus Harnisch
> Sent: Wednesday, May 19, 2004 11:43 AM
> To: Ajayharsh Varikat
> Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
> Subject: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and
> Encryption Donation
>
>
> Hi Ajayharsh,
>
> Ajayharsh Varikat writes:
> > There is another issue we have in specifying exactly what may be
> > revealed and what must not. There is no way of restricting where
> > begin and end pragmas can be placed in the code, and this could
> > lead to some confusion about what exactly gets protected. One way
> > out is to change the pragmas to language keywords and
> specify exactly
> > where they can occur.
>
> Especially when it comes to adding something to a language standard, I
> have strong objections against "special comments". IMHO, a comment
> should not affect the way program code is interpreted by a tool. I've
> been bitten before by putting the word "synopsys" into a comment. An
> automatic line break put it a the the beginning of a subsequent
> comment line...
>
> Do you see any way to use VHDL attributes for that purpose? This would
> also answer the question which parts of code can be encrypted or not.
>
> As far as visibility is concerned, I could imagine that only the
> external interface of the respective part of the code will be
> visible. For concurrent statements that would be all incoming and
> outgoing signals.
>
> > The down side is that encrypting tools will have to be able to
> > parse the language correctly.
>
> I don't see that as a major showstopper. Tool vendors would integrate
> the encryption into their compilers (isn't that already the case for
> Verilog encryption?). If I intend to ship code encrypted with a
> certain vendor's key, chances are that I have the according toolset
> anyway.
>
> Best regards,
> Marcus
>
> --
> Marcus Harnisch | Mint Technology, a division
> of LSI Logic
> marcus_harnisch@mint-tech.com | 200 West Street, Waltham, MA 02431
> Tel: +1-781-768-0772 | http://www.lsilogic.com
>
>
Received on Wed May 19 14:55:27 2004