RE: [1076.1] Information on proposed IP support in VHDL-200X

Folks,

Just a bit of clarification about a point Olivier raised, regarding
"encryption keys broken by chinese mathematicien a few month ago." So far as
I could find, it was not encryption keys that were broken. Rather, the group
attacked the SHA-1 hash function used, inter alia, for generating digests of
messages for digital signatures. They found a way of finding messages that
have the same hash value some 2000 times faster than the brute-force
approach. This is not the same as breaking encryption. For more info, see

  http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

Of course, if that was not what Olivier referred to, I'd be interested to
hear and follow it up. Thanks.

Cheers,

PA
--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone (mobile):  +61 414 70 9106
Australia


> -----Original Message-----
> From: owner-vhdl-ams@server.eda-stds.org 
> [mailto:owner-vhdl-ams@server.eda-stds.org] On Behalf Of 
> olivier.rolland@systemsvip.com
> Sent: Friday, 23 June 2006 17:05
> To: John Shields
> Cc: Alain Vachoux; 1076.1 mailing list; Lance Thomson
> Subject: Re: [1076.1] Information on proposed IP support in VHDL-200X
> 
> 
> Thanks John for your quick answer. It seems that you have 
> only scratch 
> the surface with your thought. Let me give some additional 
> comments (see 
> below in the core text).
> 
> Dr. Olivier Rolland
> Systems'ViP
> c/o SEMIA
> 4, rue Boussingault
> F-67000 Strasbourg
> 
> Tel:   +33 671 128 130
> Email: olivier.rolland@systemsvip.com
> Web:   http://www.systemsvip.com
> 
> Systems'ViP: Your innovation capitalization partner
> 
> This e-mail, including attachments, is intended for the 
> person(s) or company named and may contain confidential 
> and/or legally privileged information. Unauthorized 
> disclosure, copying or use of this information may be 
> unlawful and is prohibited. If you are not the intended 
> recipient,please delete this message and notify the sender
> 
> 
> 
> John Shields wrote:
> > /Dr. Rolland,
> >
> > Thanks for the feedback and the thought exercise here.  I made some
> > comments below and I apologize for repeating myself in 
> places. I can't 
> > spend much more time on this in the immediate future, but 
> the thought 
> > experiment has been interesting.  I am clearer on the strengths and 
> > weakness of the obsfucation approach. I wish you the best 
> of luck with 
> > this going forward.
> > /
> > /
> > Regards, John/
> Answer: Thank you john for your good luck wishes. I notice 
> that you have 
> decided to give up on this intellectual fight, because of 
> timing issue, 
> where on the other hand you give so much time on conferences 
> to promote 
> an encryption based solution for the vhdl-ams community. Is that not 
> strange?
> >
> > olivier.rolland@systemsvip.com wrote:
> >> John,
> >>
> >> Thank you for your answer. Let me provide some comments.
> >>
> >> 1) The foundation for the standard is open and published
> >> cryptographic algorithms and the flexibility of the pragmas should 
> >> make it possible to build tools that afford legal 
> compliance across 
> >> countries.  As always, the quality of tool implementations matters 
> >> even when standards apply.  You make some good points and 
> the legal 
> >> context is certainly one of them.  As best I understand it, it was 
> >> well considered when crafting the standard and it remains 
> the domain 
> >> of the tool developers and IP providers to assure they are 
> compliant 
> >> with any rules.
> >>
> >> Answer:
> >> In order to be compliant between all providers tools, you 
> need first
> >> to share some keys between simulators softwares providers and 
> >> guarantee that everybody uses exactly the same 
> encryption/decryption 
> >> algorithms with all variants implemented for different key 
> lenght. In 
> >> addition you have to guarante that users will stick to the 
> US legal 
> >> constraints (NSA or other agency key code registration) + 
> Key lenght 
> >> limitations depending on location where the software and encrypted 
> >> VHDL, VHDL-AMS model is used. What is your proposal to help the 
> >> end-user to cope with this complexity. On top of it, the encrypted 
> >> source code is decrypted by the simulator before the code analysis 
> >> and compilation because of the parser, compilers requirements. It 
> >> means that a malicious organisation might be able to try 
> to read the 
> >> computer memory and get theVHDL, VHDL-AMS source code without 
> >> tremendous efforts. Is there an answer in the standard proposal to 
> >> prevent this type of issue?
> > /The algorithms are not an issue. They are themselves 
> standard.  It is
> > tool developer's job to build a correct implementation.  A 
> tool that 
> > is not correct produces encrypted results that no one can 
> read or is 
> > incapable of decrypting anything legitimate.  Such tools are easily 
> > weeded out.  Having to qualify new tool releases before committing 
> > them to your production tool flow is nothing new for users, be they 
> > providers or consumers of IP.
> > The key mgmt problem is not a short discussion, but it will 
> not be the 
> > burden you think.  The key exchange is between the tool 
> provider and 
> > the IP owner, not between tool providers.  No one has to guarantee 
> > that users do the right thing, but the IP providers and 
> tool providers 
> > have to do the right thing.  If a tool provider delivers a 
> tool that 
> > is capable of doing something that violates export laws, that is a 
> > problem for them. If an IP provider delivers IP protected 
> in a manner 
> > such that no legal tool can decrypt it, that might be bad for 
> > business.   Of course I  can't say what every tool might 
> do, but your 
> > concept of how a compiler or load-n-go simulator would handle the 
> > decryption task is not what any tools that I know of would 
> do.  I do 
> > not believe the malicious scenario you describe is realistic.  
> > However, the IP provider has to trust the tools that you 
> authorize to 
> > handle your IP by providing them keys have a reasonable approach./
> ANSWER: Algorithm is definitly an issue:
> First crypto guys will tell that they never trust an algoritm not 
> implemented at home and second look at the reaction in this area with 
> the encryption keys broken by chinese mathematicien a few 
> month ago. The 
> telecommunication industry has to rethink its cryptography 
> implementation to prevent individual or government based 
> hacking. Third, 
> if you want to make your solution avalaible on a worldwide basis, you 
> will end up with a really low crypto security level because of key 
> deposit you have to make at each security government agency, 
> because of  
> local key lenght limitations and because of algorithm export 
> limitation 
> which prevent you from using really rugged crypto algorithm. 
> All of that 
> is basic stuff in the crypto world. The today proposed cryptographic 
> implementation is a joke for a government agency and will protect the 
> customers IP only in apparence.
> The malicious way I've described comes from existing implementations 
> used in the past in other area.
> Concerning the key management, this might be a nightmare for the end 
> user. Think about a company dealing with ten different Soft 
> IP providers 
> for a complex design. This company will have to manage all this keys 
> (Think about  the potential complexity of  serious PKI (public Key 
> Infrastructure)worldwide based) in a really clean manner, 
> assuming that 
> his underlying software will be able to cope with it. You 
> just need to 
> have a look on the music or video industry and the Digital Right 
> Management issue ending up into several standards and end 
> user community 
> splitted by type of music players (ipod vs. Sony vs......). 
> This is not  
> a viable way for the VHD and VHDL-AMS industry and I hope 
> that this is 
> the goal of simlators providers. Do not forget that we deal with IEEE 
> standards where, per definition, we want a really open world with low 
> cost in term of data exchange.
> By the way, IF you want all simulators  vendors to implement 
> a complex 
> key management system and the related encryption algoritms, 
> there will 
> be a lot of good job opportunities for crypto guys in the future. It 
> will as well significantly  increase the development cost of the 
> software. The end-users will show their licence fees jumping 
> up and that 
> is absolutly not good news for the community.
> >>
> >> 2) If I may, you have made a case for  source code 
> obfuscation and it
> >> may prove to be effective protection for many 
> applications.  I do not 
> >> understand enough of the approach you have advocated. Without the 
> >> details and looking at a high level, I have some concerns. 
>  Perhaps 
> >> you can shed some light?
> >>
> >> Answer: The difference between encryption and obfuscation 
> lies in the
> >> fact that with the encryption, you make your source code 
> unreadable 
> >> by applying an encryption algorithm othe it. As long as 
> you have the 
> >> encryption key(s) and you know the algorithm used, you can reverse 
> >> the process and you get the original code back.
> >> Using the obfuscation mechanism, you rewritte your source 
> code in a 
> >> new human unreadable source code while keeping it strictly 
> identical 
> >> at a simulator level after compilation.The consequence is 
> that there 
> >> is no need for key sharing and the process can't be applied 
> >> backwards. It is stricly impossible to make a reverse 
> engineering and 
> >> therefore you get through this obfuscation mechanism a rugged, 
> >> legally independant IP protection mechanism. The issue with it, is 
> >> that developing such an obfuscator is a non trivial task. 
> This is why 
> >> encryption is usually the poor man implementation for IP 
> protection.
> >>
> > /Of course a key is the secret.  Without it, the encryption 
> cannot be
> > broken.  The algorithm is sufficiently strong that is not a problem 
> > for it to be known.  That is the nature of encryption and 
> its inherent 
> > strength.
> > So you are saying the algorithm for the obsfucator is the 
> key to doing 
> > this right. It itself is the secret. A poor algorithm would be 
> > possibly be reversible, yes?  Why would I want to trust a single 
> > vendor?  I think reverse engr does not need to come up with 
> the same 
> > names for objects, etc. to understand the original implementation.  
> > The HDL has a set of keywords that must be preserved which itself 
> > offers a lot of insight. 
> > /
> Answer: Concerning the key and the secrecy have a look at my answer 
> before. Concerning the obfuscation there is, per definition, 
> no way to 
> go backwards. For you there is no need to trust a single vendor since 
> all of us can develop our own obfuscators. The issue, please 
> remember, 
> is that the task to develop such a tool is absolutely not 
> trivial. The obfuscated code is treated like the source code 
> by the simulator, so 
> you don't have to bother with compatibility issue, there is 
> no issue in 
> this case.
> Yes, you can partially reverse engineer the obfuscated code 
> with pretty 
> printers tools (good point) and because you keep the HDL 
> keywords. The 
> problem is that it works quite well for a resistor 
> definition, even if 
> you never get the original comments and original signal 
> names....But if 
> you have to deal with industrial gradedesign with thousands of line 
> codes, seeing the HDL keywords doesn't help you at all and that makes 
> the difference.
> > //
> >> 3) First is that tools will not understand the intent to protect
> >> information because it is not conveyed with source code 
> obfuscation.  
> >> If there is information to be mined from obfuscated 
> source, the tools 
> >> will allow it in an oblivious manner, correct?  Looking at the 
> >> opposite problem, if there is information that the tool 
> should convey 
> >> because the intent of the IP provider is to open aspects (what is 
> >> addressed by the viewport pragma in the VHDL IP protection 
> spec) to 
> >> the user, would the obfuscated source get in the way?  Finally, I 
> >> have no knowledge of your specific algorithms for obsfucation and 
> >> what a determined hacker with a sufficient spec for what the IP is 
> >> (in order to use it) might be able to do to reverse 
> engineer it.  I 
> >> presume you would assert that it is next to impossible.  I wonder 
> >> whether that depends on the algorithms you use remaining trade 
> >> secret.  If you had the algorithm would it help unobsfucate the 
> >> source?  If not, would the availability of one proprietrary tool 
> >> using these algorithms be of concern?  Would other tools attempt 
> >> obsfucation and inferior implementations lead to compromise?
> >>
> >> Answer: There is no need to convey  obfuscation  intent 
> information,
> >> since  original source code or obfuscated code is 
> transparent on the 
> >> compiler simulator level.E.g. If a variable is called 
> >> "temperature_input" or "10001111001100100101" it has a lot 
> of meaning 
> >> for a human being but make no difference for a simulator. This 
> >> approach is valid as well constant values, code suite, not 
> speaking 
> >> about comments which are useless for a simulator.
> >> Concerning the obfuscation algorithm, this algorithm is useless to 
> >> un-obfuscate the source, this is why I told you that this solution 
> >> really rugged (no need to mention the application potential).
> >> Bottom line, an obfuscated code is treated the same a a 
> source by a 
> >> compiler. This then no tool dependency as long as the 
> source has been 
> >> written in a way where the original code is understood by 
> all simlators.
> >>
> > /I disagree with the first part of your answer.  If tool must report
> > information which is meaningful only if the original 
> declarations are 
> > used, there is a problem.  The interface declaration has to be 
> > readable enough to use, so if you can't change it, you can 
> see how it 
> > is referenced in the obsfucated source.  If a tool can support code 
> > understanding and causality tracing, it will show hierarchical 
> > structure and loads and drivers.  You can write an obsfuscator that 
> > uses long, unintelligable names and hides meaningful white 
> space.  I 
> > can write a tool that collects and substitutes better, 
> cleaner names 
> > and pretty prints the source, correct?  I might even have an 
> > interactive tool in which I review and cleanup names on the 
> fly as my 
> > understanding grows./
> Answer: You can design an obfuscator where the top level interface is 
> readable. As said befor a pretty printer will help you to see the 
> structure but you have no chance concerning the meaning of it. It is 
> like having a pretty printer to decipher the structure of a 
> chinese book 
> (for the one not understanding the mandarin language) and a grammatic 
> analysis tool. As long as you do not understand the meaning 
> of the words 
> all this tools are meaningless. This is the key lesson concerning the 
> obfuscators and this one of the reason why it is so succesfull in the 
> java community where I wissh that one day the VHDL VHDL-AMS community 
> will see its language be spread as far as it is the case for the java 
> language.
> >> My point is really to say that I do not understand enough of the
> >> technical approach you have advocated and I am, of course, an 
> >> advocate for the current standard approach.  Of course, it 
> will have 
> >> to prove itself in the marketplace like anything else.
> >>
> >> In order to make the point clear to everybody, my proposal is to
> >> provide, to all of you ,an obfuscated VHDL-AMS model (with 
> its spec 
> >> documents and testbench and simulation results) running on 
> the three 
> >> VHDL-AMS platforms avalaible (Ansoft, Mentor Graphic and Dolphin), 
> >> and to give you 15 days to re-engineer this model back (having all 
> >> initial value, variables names and comments provided back).
> > /I grant you your point.  I don't want to invest energy trying to
> > "crack" any approach to convince myself of its strength.  
> It would be 
> > horrible if the EDA community had to analyze the 
> theoretical strength 
> > of various encryption algorithms.  There is an accepted 
> body of such 
> > expertise in cryptography that has done that and we trust this is 
> > effective.  How would I reach such trust with your idea?
> > /
> Answer: It wouldn't be horrible at all if the EDA community had to 
> analyze the strebngh or weakness of various  IP protection  
> scheme.  The 
> community should have enough smart guys which are ble to deal 
> with such 
> topics (I hope so). Else there is no reason to deal with that and use 
> better a PGP (Pretty Good Privacy based tools) implementation 
> to protect 
> your Intellectual Property.
> Could you give me more information about an accepted body concerning 
> cryptography on a worldwide basis. On top of it, having a good 
> encryption algorithm doesn't prevent you from having backdoors in its 
> implemntation. I think about a well known groupware software having 
> encryption capabilities but we all know that the key root has 
> been (for 
> legal compliance issues) deposit to the relevant federal agency. It 
> means that such encrypted databases can be decrypted by the 
> appropriate 
> body within minutes.There is no trust in this case. Looking on a 
> worldwide basis this is just not acceptable, because a growing market 
> like China or India will never agree. So we have to find a 
> way which is 
> acceptable by all countries.
> This is why an obfuscator is so powerfull, there is no way 
> back, even if 
> you have the obfuscation algorithm in you hand and it force 
> everybody to 
> treat the IP on the same level and to respect its 
> counterpart. This is 
> why I think that the community will show a strong interrest 
> in such a way.
> 
> 
> > /
> > A few thoughts on that. First no one can get back 
> information that is
> > truly missing, such as elided comments.  It is trivial to strip 
> > comments before encryption too (but arguably unnecessary). 
> Regarding 
> > names, it would not matter that I have the names correct, only 
> > meaningful. I would not waste my time doing this task 
> manually, but if 
> > I was determined, I would build a tool to support me.  You 
> cannot hide 
> > keywords, so alot of integrity of the HDL decl and 
> statement structure 
> > must remain, only obscured. I think the important 
> theoretical point is 
> > supported by examing what the obsfucating mechanism does 
> and whether a 
> > determined effort can mitigate what information was merely hidden.  
> > But if the obsfucation algorithm is itself the only secret 
> and since 
> > only you know it, it seems pretty unverifiable whether it is strong 
> > enough to resist code understanding tools.  It therefore remains a 
> > worthy task for you to obtain such trust from your potential 
> > customers.  There is nothing other vendors can do to build 
> tools that 
> > do the same thing without also being a proprietary and unique 
> > solution  and  also facing the same task as you have with 
> your tool. I 
> > don't see something to standardize for all tool vendors to 
> use here./
> >> I do not want to go against the mailing list policy, this is why I
> >> aske here the moderator authorization to share an obfuscated model 
> >> with everybody.
> >>
> >> Regards.
> >>
> >> Olivier Rolland
> >>
> >> Dr. Olivier Rolland
> >> Systems'ViP
> >> c/o SEMIA
> >> 4, rue Boussingault
> >> F-67000 Strasbourg
> >>
> >> Tel:   +33 671 128 130
> >> Email: olivier.rolland@systemsvip.com
> >> Web:   http://www.systemsvip.com
> >>
> >> Systems'ViP: Your innovation capitalization partner
> >>
> >> This e-mail, including attachments, is intended for the 
> person(s) or
> >> company named and may contain confidential and/or legally 
> privileged 
> >> information. Unauthorized disclosure, copying or use of this 
> >> information may be unlawful and is prohibited. If you are not the 
> >> intended recipient,please delete this message and notify the sender
> >>
> >>
> >>
> >> John Shields wrote:
> >>> Dr. Rolland,
> >>>
> >>> Thanks for your comments.  The foundation for the standard is open
> >>> and published cryptographic algorithms and the flexibility of the 
> >>> pragmas should make it possible to build tools that afford legal 
> >>> compliance across countries.  As always, the quality of tool 
> >>> implementations matters even when standards apply.  You make some 
> >>> good points and the legal context is certainly one of 
> them.  As best 
> >>> I understand it, it was well considered when crafting the 
> standard 
> >>> and it remains the domain of the tool developers and IP 
> providers to 
> >>> assure they are compliant with any rules.
> >>>
> >>> If I may, you have made a case for  source code obfuscation and it
> >>> may prove to be effective protection for many applications.  I do 
> >>> not understand enough of the approach you have advocated. Without 
> >>> the details and looking at a high level, I have some concerns.  
> >>> Perhaps you can shed some light?
> >>>
> >>> First is that tools will not understand the intent to protect
> >>> information because it is not conveyed with source code 
> >>> obfuscation.  If there is information to be mined from obfuscated 
> >>> source, the tools will allow it in an oblivious manner, correct?  
> >>> Looking at the opposite problem, if there is information that the 
> >>> tool should convey because the intent of the IP provider 
> is to open 
> >>> aspects (what is addressed by the viewport pragma in the VHDL IP 
> >>> protection spec) to the user, would the obfuscated source 
> get in the 
> >>> way?  Finally, I have no knowledge of your specific 
> algorithms for 
> >>> obsfucation and what a determined hacker with a 
> sufficient spec for 
> >>> what the IP is (in order to use it) might be able to do 
> to reverse 
> >>> engineer it.  I presume you would assert that it is next to 
> >>> impossible.  I wonder whether that depends on the 
> algorithms you use 
> >>> remaining trade secret.  If you had the algorithm would it help 
> >>> unobsfucate the source?  If not, would the availability of one 
> >>> proprietrary tool using these algorithms be of concern?  
> Would other 
> >>> tools attempt obsfucation and inferior implementations lead to 
> >>> compromise?
> >>>
> >>> My point is really to say that I do not understand enough of the
> >>> technical approach you have advocated and I am, of course, an 
> >>> advocate for the current standard approach.  Of course, 
> it will have 
> >>> to prove itself in the marketplace like anything else.
> >>>
> >>> Regards, John
> >>>
> >>> olivier.rolland@systemsvip.com wrote:
> >>>> John,
> >>>>
> >>>> I do now understand  your somehow aggressive reaction, in march
> >>>> 2006, when I do have send some information to the working group 
> >>>> over the fact that an obfuscation based solution exists vor the 
> >>>> VHDL and VHDL-AMS languages and that it might be better than all 
> >>>> other solutions.
> >>>> After reading the accelera information, it turns out, asd Arpad 
> >>>> said, that we will have maybe a common mechanism for IP 
> protection 
> >>>> but based over propietary keys and proprietary implementation of 
> >>>> the general mechanism. I hope that the community members 
> will pay 
> >>>> attention to the theoretical and practical consequences of going 
> >>>> into potentially vendor dependant implementation of an IP 
> >>>> protection mechanism and its inherent, country dependant, legal 
> >>>> limitation related to the use of an encryption key based 
> mechanism.
> >>>> Remember that the java language is so successfull because of its 
> >>>> portability over many platforms and the IP protection 
> solution used 
> >>>> in this case is based over source code obfuscation 
> tools. I do hope 
> >>>> that theVHDL and VHDL-AMS community has got enough smart 
> guys to be 
> >>>> able to understand and treat the IP protection issue in a truly 
> >>>> open, vendor independant and legally smart way.
> >>>>
> >>>> Regards.
> >>>>
> >>>> Olivier Rolland
> >>>>
> >>>>
> >>>>
> >>>> Dr. Olivier Rolland
> >>>> Systems'ViP
> >>>> c/o SEMIA
> >>>> 4, rue Boussingault
> >>>> F-67000 Strasbourg
> >>>>
> >>>> Tel:   +33 671 128 130
> >>>> Email: olivier.rolland@systemsvip.com
> >>>> Web:   http://www.systemsvip.com
> >>>>
> >>>> Systems'ViP: Your innovation capitalization partner
> >>>>
> >>>> This e-mail, including attachments, is intended for the person(s)
> >>>> or company named and may contain confidential and/or legally 
> >>>> privileged information. Unauthorized disclosure, copying 
> or use of 
> >>>> this information may be unlawful and is prohibited. If 
> you are not 
> >>>> the intended recipient,please delete this message and notify the 
> >>>> sender
> >>>>
> >>>>
> >>>>
> >>>> John Shields wrote:
> >>>>> Alain,
> >>>>>
> >>>>> A bit of a clarification.  IMHO, the more appropriate group to
> >>>>> engage in discussion is the Accellera VHDL TC. Visit 
> >>>>> www.accellera.org to add yourself if  your company is a 
> member.  
> >>>>> Lance Thompson, the chair, may know to what extent you might 
> >>>>> participate even if you are not a member.  The 
> vhdl-200x group is 
> >>>>> not active as their work has transitioned and broadened at the 
> >>>>> Accellera VHDL TC.  He is cc'ed on this email. It is true that 
> >>>>> many of the same people are on both email reflectors and within 
> >>>>> the boundaries of the IEEE, it is easy to 
> subscribe/engage working 
> >>>>> groups.  Nevertheless, the work is taking place in Accellera. 
> >>>>> Their results will move back systematically to the IEEE 
> for review 
> >>>>> and ballot preparation.
> >>>>>
> >>>>> A second item that may be of interest if you are 
> attending DAC is
> >>>>> that I will be making a presentation on IP encryption 
> at the IBIS 
> >>>>> Summit meeting sometime on Tuesday morning.  They are 
> interested 
> >>>>> specifically in VHDL-AMS IP, though the focus of the 
> talk will be 
> >>>>> to provide a general understanding of the mechanism and how it 
> >>>>> works for any Verilog or VHDL-based HDL.  I will at 
> least motivate 
> >>>>> where issues specific to a particular HDL would lie.
> >>>>>
> >>>>> Regards,
> >>>>> John Shields
> >>>>>
> >>>>> Alain Vachoux wrote:
> >>>>>> Dear 1076.1 Working Group member,
> >>>>>>
> >>>>>> A couple of months ago, there was some discussion about the
> >>>>>> support of encryption/decryption for VHDL-AMS models. Ernst 
> >>>>>> Christen mentioned the ongoing effort in the VHDL-200X working 
> >>>>>> group (http://www.eda-stds.org/vhdl-200x/). Since then, I 
> >>>>>> discussed with Lance Thomson, Chair of the Accellera Technical 
> >>>>>> Committee in charge of developing the new VHDL LRM to be 
> >>>>>> submitted to IEEE for revision. We agreed to provide 
> the 1076.1 
> >>>>>> WG members with documents for information and review. Three 
> >>>>>> documents on IP protection may be then downloaded at the 
> >>>>>> following URLs:
> >>>>>>
> >>>>>> 
> http://www.accellera.org/apps/group_public/download.php/532/VHDL_
> >>>>>> IP_Proposal_V9.doc
> >>>>>>
> >>>>>> The original proposal put forward by the VHDL TC extensions
> >>>>>> committee. It is derived from a donation from Cadence 
> which was 
> >>>>>> derived from their donation to Verilog.
> >>>>>>
> >>>>>> 
> http://www.accellera.org/apps/group_public/download.php/634/IP-re
> >>>>>> quirements.pdf
> >>>>>>
> >>>>>> A reworked document fixing the low security level provided by
> >>>>>> some of the use models. This is the base for the new 
> 1076-2006 LRM.
> >>>>>>
> >>>>>> 
> http://www.accellera.org/apps/group_public/download.php/682/LCS-2
> >>>>>> 006-140.pdf
> >>>>>>
> >>>>>> Actual LRM text that has been added to VHDL (P1076-2006-D2.11)
> >>>>>> which is currently under review.
> >>>>>>
> >>>>>> If you have questions or comments about the proposed 
> IP support,
> >>>>>> I would suggest to carry the discussion to *both* the 
> 1076.1 and 
> >>>>>> the VHDL-200X mailing list (go to the VHDL-200X web site to 
> >>>>>> subscribe).
> >>>>>> The IP protection proposal that is being developed is pretty 
> >>>>>> general and should be applicable to 1076.1 models as 
> well. A more 
> >>>>>> detailed review might however reveal some issues specifically 
> >>>>>> related to AMS models. But so far the ownership of the 
> proposal 
> >>>>>> belongs to the VHDL-200X Working Group.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Alain Vachoux
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >
>