On Friday 25 April 2008, Dan McMahill wrote: > [EMAIL PROTECTED] wrote: > > Can either of these simulators handle an encrytped model? > > I have some from fairchild that are hspice format, using > > ".prot FREELIB" , which is encrypted. > > I'd be surprised. It seems to me that if you knew how to use > the encrypted models then you'd also know how to decrypt the > model. Even if there were no other reason, I'll bet this one > alone would prevent the details of the encryption from being > publicly known.
For now, the answer is no. It will probably remain no for a long time, unless you can get some of the vendors to talk to each other. Actually, some of the big vendors would rather share with each other than with open-source. The whole idea of the Berkeley license, used by Spice, is to make a one-way pipe from the free to the proprietary. A few years back, this issue came up in an IBIS futures committee. I don't think most people there understood it, but I did have strong support from several well known large corporations. I made a presentation, showing the issues and options, and a conclusion that there is one way to do it that would be secure and portable. Part of what I showed is that simple encryption would not meet the goals, because of what Dan said. The one way that would work is to provide models in some kind of object code, for some kind of machine, real or virtual, and have a documented interface. It would need to be treated as a separate executable, with message passing. Since we don't know what the future will bring, the only way of interfacing that is portable enough is stdin/stdout. For true portability, the executable really needs something like a virtual machine .. perhaps java byte code. Now define an interface .. setting parameters, evaluation, etc. Then any simulator supporting it would need to make the appropriate wrapper. Back then, I also brought it up with the NGspice people, who thought the idea was great at first, but didn't show any interest in follow-up. I don't think anyone there understood what it was all about. My reason for proposing it there was that if we can make it work with both gnucap (then "ACS") and NGspice, with their very different architectures, that goes a long way to demonstrate that the method is truly portable, at least with the same CPU. My proposal at the time would let you write the model in any language that supported stdin/stdout, so how portable it really was depended the language and tools you used. At that time, I had the outline for how the future gnucap plugins would work, but because of some political issues, I was not able to really get to work on plugins until many years later. If there is interest (hopefully with some funding) I could re-open it. This is an area where we can do something the big guys can't. If someone wants to help, I will give direction. It would be a good project for someone who might have considered a summer-of-code project, but wants something smaller. I see it as a much smaller project than any of the SoC projects we are doing this year, but will anyone use it? _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
