[SI-LIST] Re: Error in HSPICE

I have run into this many times. The reason is that your receiver and your 
driver both contain the NCH transistor .model information. As Andy said, 
encapsulating the process/transistor models within each subcircuit will solve 
this problem. 

Other ideas:

If you have access to the process models you can create a .lib file.  

If the model is completely encrypted (except for the .subckt statement) you can 
encapsulate the entire model by creating a new subcircuit around it. Thus:

********************************************************************
.Subckt new node1 node2 node3 ....

x1 node1 node2 node3 ... encryptedsub

.subckt encryptedsub node1 node2 node3 ...
** the full encrypted file that you have should be here***

.ends new

*******************************************************************

I hope this helps...

Peter


"Ingraham, Andrew" wrote:
> 
> > Hi! In my spice deck I had calls for two encrypted
> > driver & receiver. When I run the sim, it gives me
> > error: 'above line attempts to redefine nch' and
> > similar error for pch. I know this could be due to the
> > same nodes being called in the encrypted models.
> 
> It is probably not the same nodes.  SPICE wouldn't have a problem with
> that.  It is probably duplicate transistor model definitions:
> 
> .MODEL NCH NMOS ...
> 
> ... and later, another one:
> 
> .MODEL NCH NMOS ...
> 
> > What is the workaround for this?
> 
> Unless one of the .model definitions is your own (outside the encrypted
> portions), contact whoever is responsible for the encrypted models and
> ask them to change one or both model names to something less generic.
> Or be more blunt and remind them they made a big mistake by creating two
> encrypted models that both define the same transistor models (rather
> than putting the .MODEL definitions into a third encrypted file that
> gets loaded as needed by the driver and receiver models).
> 
> Or do what Craig Clewell suggested and see if you can split your
> simulation into two parts that run separately.  Since many simulations
> depend on the nonlinear interaction between driver and receiver, this
> might be less than satisfactory.
> 
> (I forget whether encapsulating the encrypted models into subcircuits is
> another way to avoid this problem, by limiting the "scope" of each model
> definition.  I think it doesn't, in the case of .MODEL statements.)
> 
> Regards,
> Andy
> 
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> 
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
> 
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> 
> List archives are viewable at:
>                 http://www.freelists.org/archives/si-list
> or at our remote archives:
>                 http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
>                 http://www.qsl.net/wb6tpu
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages 
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: