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

In short John, yes, it is statistically incredibly unlikely that this
would occur. I guess a tool could even check for the case and add
whitespace or something to eliminate it if it did occur but I can't see
expending the effort.

I see 3 alternatives off hand:

1) allow the statistical error (leave it alone)
2) Further standardspecification of the format of the encoded data
(similar to Mac's suggestion)
3) Adoption of a --pragma encoding <format> <data>

The last option was one we had internaly for a while where the only
supported <format> was SIXEL and the <data> was the number of encoded
bytes. This leaves the door open for vendors to support other formats
that might also include data compression. As I said earlier, I think
this would be overkill.

Jay

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

> -----Original Message-----
> From: Michael McNamara [mailto:mac@verisity.com]
> Sent: Wednesday, May 19, 2004 6:42 PM
> To: Ries, John
> Cc: Jay Lawrence; vhdl-200x@eda.org; vhdl-200x-ft@eda.org
> Subject: Re: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and
> Encryption Donation
>
>
>
>
> The encrypted text produced by encryption when translated to sixal is
> usually included text as a set of precisely 60 character "words" each
> on their own line, with no internal spaces, or the use of the
> character "_"; so you are quite safe.
>
> For example, the granddaddy of binary encapsulation is uuencode, which
> turns your email message into:
>
>
Received on Thu May 20 06:39:17 2004