Dr. Rolland,
John,That is fine, just answer it privately or in some forum that IBIS supports if you have to mention companies or products.
Thank you for your feedback.
I have to mention that I have answered to a question coming from one IBIS group member.
I do agree with you concerning the advertising issue. The problem is that it is hard to speak about someting new without providing the evidence that it exists. That is the reason why I had to provide this information.Nonsense. You did not have to advertise and you are not allowed to do so here. You can speak about the technical concept and, if debate about the technical merit exists, you can offer the idea that a product exists and offer to discuss it privately with anyone interested. I understand that you would have me believe this case is an exception to the rule, or that you could not see an easy way to say what you wanted to say, and so you took it upon yourself to advertise. Even if I agreed with you, which I do not because yours was a blatant advertisement, or even if the majority of others on this list agreed with you, it does not matter. We are obligated to follow IEEE rules.
You can, by the way, wipe out immediatly all the doubt you mentionned in your post by testing the solution.I don't have an issue with the importance of the problem and that the need exists. It is true that there is no standard that serves today. I agree with all of that. In fact, I am involved with the effort in VHDL to address this. It is fine for you to talk about the problem and say that there is no need, in your opinion, for encryption in VHDL-AMS because you believe a better solution is to handle the problem outside of the language with an obsfuscator. Defend that technical position, as you like. Maybe someone will agree with you and maybe someone else will not and that is all OK. Regardless, you do not get to advertise here. The IEEE forbids it. The reason they do absolutely forbid it, is that, if allowed, there is no way to close the door. All vendors would be able to justify advertising their products in the name of providing useful technical information, answering questions, or related rationalization like yours. That would ruin these reflectors, clutter them with spam. It is not my rule. I am sure one of the officers can provide stronger support for the purpose of the rules that are in place.
Concerning the encryption issue, as I far as I know there is no standard at all for the vhdl-ams nor is there a legal solution concerning information protection and country specific issues (see the today Yahoo issue and China looking outside of the pure VHDL-AMS community). The stuff is serious enough to spent a bit of time and thinking over it.
A standard is only valid if the academic community as well as the _industry_ takes it over for its quality.
There is no doubt over it as a language but, because of its hardware description nature, writing a model might be sensitive concerning its intellectual property content. This is why the question concerning the ip protection will come and come over again as long as there is no answer to it. So it is our duty, in order to promote efficiently the standard, to look at all issues slowing its adoption, to find out solutions and to share it with all members.
I'll ignore your insult as misguided and unintentional.
This has been the reason for my post.
Anyway I do apologize if the information provided has been somehow incomfortable for your eyes and your mind.
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,
First of all, you should be aware of the rules for advertising products here. You participated in the recent discussion with Amr Turk in which this issue was explained. Since it is not new to you, I am concerned that you are not taking it seriously. It would not be hard to talk about the problem without mentioning your product. You made no attempt to do so. You do realize the consequences are being removed from the privilege of posting to this group?
Regarding your opinion about encryption, I think you should look at the solution that is being standardized. Those problems you mention have been considered and well addressed. */Every single one/* you mentioned. I might cast some doubt on your solution as truly having the attributes you claim, but there is no reason to discuss it in the context of this standards group. Please, refrain from this kind of email.
Regards, John Shields
olivier.rolland@systemsvip.com wrote:
Hi everybody,
Thank you for your question, the topic you open is really important for IP protection purpose and an answer is required to guarantee a successfull spread of the VHDL-AMS.
1) It is not , in our view, something which is relevant to the language itself, since the source code protection has nothing to do with the semantic or grammatical rules.
2) Encryption tool which depends to an EDA vendor is useless because of its proprietary nature which is in contradiction to the IEEE open standard natureof the language itself.
3) Using a common encryption scheme to protect the source code presents several issues:
- the first one is related to different national laws dealing with encryption tools and encryption keys management, which might drive to major security holes or impossibility to implement a suitable common set of tools and keys
- the second one is related to the logistic nightmare users might face when dealing with keys management coming for complex design using encrypted models from different providers (see the today Digital Right Management issue we do have with the music industry)
- the third one is related to the limited value of a secret (encryption scheme) shared by an open community to be able to implement it. Knowing the encryption algorithm used is of great help for a hacker to find out the encryption key and implement the appropriate reverse engineering.
- the fourth one is related to the EDA vendors who have a strong interest to limit, for obvious reasons, simulation and development platforms interroperability.
We have developped, for all this reasons an obfuscation tool which is available in form of an ASP through an encrypted internet web site.
What does it mean?
An VHDL-AMS obfuscator convert a source code model into an other formally equivalent source model unreadable by a human beeing but treated like a standard source code model by a vhdl-AMS compilers and simulators.
This shows many advantages:
- No encryption tools and keys (no legal limitation and no encryption key management nightmare)
- No reverse engineering possible since the generated model is a new one formaly equivalent to the original one (only the necessary information for the compiler and related simulator and generated, all other informations like comments ore meaningfull sgnal names are thrown away in to preserve the Intellectual property).
Note that developping such a sophisticated obfuscator is as complex as developping a compiler.
- Watermarking included into the generated code in order to guaranted the traceability of the delivered models and the enforcement of contrated NDA and contracts between companies.
- EDA independant generated scrambled code (as long as the original source works on all target platforms), there is no compilers and simulators platform changes required at all.
- EDA software platform version independant scrambled model since it can be compiled when required.
- Since the scrambler deals with the VHDL-AMS language, the pure digital world (namely VHDL) is covered as well by the solution.
In order to give you a first taste of this software capabilities which is the result of more than two years of intensive research and development work, you can have a look on our web site: www.systemvip.com
and register yourself on following link: http://www.systemsvip.com/request_access.html to get within 48 hours your personal login and password to have access on our limited demo version of the software.
I apologize in advance for this partially advert oriented email, but we think that providing such breakthrough capabilities in term of IP protection to the VHDL-AMS community is crucial for its long term success and therefore all community members should have a chance to get this information. Whith such tools the era of intensive information sharing among companies can start putting the VHDL-AMS as the natural choice for moving from physical prototypes based R&D to a more virtual prototypes de-materialized based R&D.
Your feedback will be appreciated
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
Muranyi, Arpad wrote:
Hello everyone,
Sorry for bringing up such off topic questions all the time,
but I would like to find out whether encryption has been
considered by the workgroup for VHDL-AMS models.
The reason I am asking is because this has been brought up
in the recent IBIS Open Forum discussions in connection
with modeling bleeding edge high speed buffers behaviorally.
Semiconductor vendors feel increasingly uneasy about
releasing even behavioral models for such buffers without
encryption. In addition we do not like the idea of using
the individual and proprietary encryption schemes of EDA
vendors, because that would require the model makers to
encrypt the same model multiple times for each tool. It
seems that there is a strong need for some sort of a tool
independent encryption scheme.
We thought we should look around what has been done, if
anything, before we reinventing the wheel.
Thanks,
Arpad
=============================================================
This archive was generated by hypermail 2.1.8 : Mon Apr 24 2006 - 17:10:26 PDT