The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design Languages >> Verilog-AMS >> Hierarchical VerilogA for Cadence Spectre/AMS
https://designers-guide.org/forum/YaBB.pl?num=1210250205

Message started by designerjoe on May 8^th, 2008, 5:36am

Title: Hierarchical VerilogA for Cadence Spectre/AMS
Post by designerjoe on May 8^th, 2008, 5:36am

Does anyone know a way to implement Hierarchical models for use in Cadence with the Spectre and AMS simulators?

I would like to create modules in separate files as well as in the same files as the "parent module" to ease/improve multiple instantiations of various structures.

The only way I can get away with putting "child modules" in the same file as the parent module without incurring a syntax error is by putting these after the "parent module" code. This is however no good as it is impossible to instantiate the "child module" which needs to be declared before its instantiation.

If I put frequently used modules in their own cells (files) there seems to be no way of making Cadence realise that they exist at all when compiling a module in which they are instantiated.

Does anyone know how to get any or both of these types of instantiations to work?

Title: Re: Hierarchical VerilogA for Cadence Spectre/AMS
Post by jbdavid on May 15^th, 2008, 3:54am

Sure. put each module in its own cell, make sure it has a symbol and that the symbol exists before you compile/syntax check the parent that contains that child.

2 put all the sub modules in a single .v file and ahdl include it in the modelfiles

3. do it all at the command line.. What you do need Symbols and Views for?
kind of useless until you are ready to build the implematic (a "Scheme"atic shows the scheme.. if you have transistors will all parameters and substrate connections you are really showing the implementation so you should call it an "implematic"

Title: Re: Hierarchical VerilogA for Cadence Spectre/AMS
Post by designerjoe on May 29^th, 2008, 3:19am

Thanks jbdavid!

I was just logging in to reply to my own posting with my findings as I worked it out a couple of weeks ago.

I would say that in cases where Verilog-A is used to speed up top level verification rather than proof of concept it is beneficial to be able to use the same simulation test benches and schematics.
The level at which the parts of the design hierarchy is replaced by Verilog-A depends of course on the importance of speed vs.accuracy of the block in question. Generally, you loose accuracy but gain speed the higher up in the hierarchy you model in an HDL.

For the reson of following the schematic implementation flow I would recommend anyone to as you said generate child models WITH symbols before compiling the higher level parent model as this looks for binding information generated only if a symbol for the child model is in place.

It is also possible, though it is said not to be supported by in Cadence because it probably breaks some other Cadence tool flow, to write child modules into the same file as the parent. They must be written below the end of the parent module for this to work.

It is therefore also possible to instantiate "external" modules without symbols by using the `include compiler directive to insert child modules into the same file. Just remember the `include compile directive inserts the contents of the "include file" at the place it is used, so put the `includes below the parent module.

The reason why this unsupported method seems to work and why having child modules listed ahead of its parent doesn not is that the netlisting and binding tools seem to look at only the first module interface of the file, ignoring the name of the module. However, you need to give full or relaitive path names for this to work.

If you are trying to keep the schematic hierarchy and the Verilog-A hierarchy in line with each other (with breaks in implementation structure wher it makes sense for the HDL implementation) I would recommend using the supported symbol/and/verilog-A approach for an easy life unless you have compelling reasons not to.

Hope this and jbdavid's entries are of use to anyone else.

Best regards
designerjoe