[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: encrytped models on gnucap or ngspice



On Friday 25 April 2008, Dan McMahill wrote:
> carzrgr8@xxxxxxxxxxxxx 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user