Stats

  • Locked Locked
  • Replies 1
  • Subscribers 125
  • Views 16672
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Stop view

samer1

Hello,

I am confused about the concept of the stop view. Let's say I have a a two terminal device "X" that I implemented in verilogA and have some parameter in it. Once I save it as a symbol, those parameters are automatically added to the CDF list. Now let us say that I added a spectre view of the device, and added those parameters to the CDF list in the by simulation tab, how would that affect the simulation of that device?

Can someone give me an example that illustrates that concept?

Thanks

Parents
  • Andrew Beckett

    Probably a bit of a late reply, but the principles of switch view lists and stop lists are quite simple. The idea is that when the hierarchy is being traversed by the netlister, when it comes to an instance it will look along the view list in order and see if one of those views exists. Once a view is found it switches into that view. If the view that is switched into is in the stop list, no further hierarchical expansion is performed and netlisting is done using the simulation information in the CDF for that component (with a slight complication I'll mention in a moment). If it's not a stopping view, that view is then traversed and netlisted as a subckt (or similar depending on the netlister).

    The complication is that there's something called view-specific CDF which is where things like the veriloga analyser add some additional information in the CDF about a specific view. This is to allow (for example) multiple veriloga views with different terminal orders or different parameters.

    Anyway, if you add a spectre view then usually that is before veriloga in the switch view list, and hence it will stop expanding the hierarchy and netlist the component using the simulation information in the CDF. It will however not add the ahdl_include in the netlist because it is unaware of the veriloga view being used.

    Hopefully that helps!

    Andrew.

Reply
  • Andrew Beckett

    Probably a bit of a late reply, but the principles of switch view lists and stop lists are quite simple. The idea is that when the hierarchy is being traversed by the netlister, when it comes to an instance it will look along the view list in order and see if one of those views exists. Once a view is found it switches into that view. If the view that is switched into is in the stop list, no further hierarchical expansion is performed and netlisting is done using the simulation information in the CDF for that component (with a slight complication I'll mention in a moment). If it's not a stopping view, that view is then traversed and netlisted as a subckt (or similar depending on the netlister).

    The complication is that there's something called view-specific CDF which is where things like the veriloga analyser add some additional information in the CDF about a specific view. This is to allow (for example) multiple veriloga views with different terminal orders or different parameters.

    Anyway, if you add a spectre view then usually that is before veriloga in the switch view list, and hence it will stop expanding the hierarchy and netlist the component using the simulation information in the CDF. It will however not add the ahdl_include in the netlist because it is unaware of the veriloga view being used.

    Hopefully that helps!

    Andrew.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.