Stats

  • Locked Locked
  • Replies 1
  • Subscribers 125
  • Views 3157
  • 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

Spectre VS Hspice in simulation speed- questions and concerns.

Alex Liao

Hello,

In my simulation by using Cadence Spectre running in the command line mode (e.g., call runSimulation with input.scs and extract performance using ocean script), the time analysis is as follows.

For example, one simulation time by using the Spectre simulator is TSim = 4.45s and the time spent in licensing is 3.66s which is 82.3% of TSim. The time for running the SKILL-language-based Ocean script for extracting performance is TOcnExt = 5.5s, and I am not sure if the licensing check is involved in the ocean script execution or not. So, for simulating one netlist and extracting the performance will take TSim + TOcnExt= 9.95s. While in the work:

  R. Castro-Lopez, O. Guerra, E. Roca, F. Fernandez, An integrated layout-synthesis approach for analog ICs, IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 27 (7) (2008), 1179 - 1189.

the simulation was run by Hspice (say HspiceD) and was performed on a PentiumIV at 1.3-Hz PC in 2008. Their reported CPU times was 612.31 seconds for 2437 iterations.

So in average, 0.25s/iteration. Such a huge difference. I assume the data from an IEEE transaction level paper is trustable.

If the accuracy of simulation results only rely on the device model included, no simulator is more superior than another. (Maybe Spectre has a more fancy and powerful IDE.) Then why not always using Hspice due to its dominant position in run speed.

Anybody has a knowledge on this? 

Kind regards,

Alex

Parents

  • Alex,

    I only skimmed the paper, but the issue here is almost certainly that you're trying to run in a way that is all overhead and little simulation. A few observations:

    1. Your licensing overhead seems excessive - that suggests something is wrong with the licensing setup if it takes that long
    2. Most likely, the HSPICE runs were done with the measurements being done within the simulator (e.g. .MEASURE statements) and maybe even the simulator control (optimisation loops) too. That could be done in spectre too (e.g. with Spectre MDL or .MEASURE). You also have multi-variable search in Spectre MDL.
    3. If you controlled the simulator with OCEAN, and were running in the default interactive mode (envSetVal("spectre.envOpts" "controlMode" 'string "interactive") ) then spectre would start once (check out the licenses once) and each desVar() change and run() would not cause the simulator to re-start. Similarly you'd not have the overhead of starting spectre either. In recent(ish - since IC616 ISR6) versions you can also speed things up by suppressing the simulator output in OCEAN via envSetVal( "asimenv.misc" "includeSimLogInOCEAN" 'boolean nil) . So provided that your measurement functions were not excessively slow (and I see no reason why they would be for an opamp) this would also be quick.
    4. In general simulation via OCEAN is not quite as optimal as controlling it directly within the simulator, but the convenience is higher and in most cases it doesn't matter because the actual simulation time dominates. In this case it appears that the simulation time of an individual run is tiny. However, if you do need to do large numbers of simulations, you can always use the MDL approach.
    5. Optimisers that we have in ADE GXL (or ADE Assembler) can also run many points in parallel - and are geared up for large numbers of runs with many variables and many metrics to measure - again, may be some overhead for these tiny jobs, but still overall can reach good levels of efficiency.

    So I don't think this is anything to do with simulator performance - spectre and APS have excellent simulation performance - it's about optimising the flow for optimisation (sorry about that!). We do similar things for our characterisation tools - having greater control over the simulator via a plugin interface to the simulator helps to eliminate these startup overheads (which  you'd also have in HSPICE too depending on how you run the simulations).

    Regards,

    Andrew.

Reply

  • Alex,

    I only skimmed the paper, but the issue here is almost certainly that you're trying to run in a way that is all overhead and little simulation. A few observations:

    1. Your licensing overhead seems excessive - that suggests something is wrong with the licensing setup if it takes that long
    2. Most likely, the HSPICE runs were done with the measurements being done within the simulator (e.g. .MEASURE statements) and maybe even the simulator control (optimisation loops) too. That could be done in spectre too (e.g. with Spectre MDL or .MEASURE). You also have multi-variable search in Spectre MDL.
    3. If you controlled the simulator with OCEAN, and were running in the default interactive mode (envSetVal("spectre.envOpts" "controlMode" 'string "interactive") ) then spectre would start once (check out the licenses once) and each desVar() change and run() would not cause the simulator to re-start. Similarly you'd not have the overhead of starting spectre either. In recent(ish - since IC616 ISR6) versions you can also speed things up by suppressing the simulator output in OCEAN via envSetVal( "asimenv.misc" "includeSimLogInOCEAN" 'boolean nil) . So provided that your measurement functions were not excessively slow (and I see no reason why they would be for an opamp) this would also be quick.
    4. In general simulation via OCEAN is not quite as optimal as controlling it directly within the simulator, but the convenience is higher and in most cases it doesn't matter because the actual simulation time dominates. In this case it appears that the simulation time of an individual run is tiny. However, if you do need to do large numbers of simulations, you can always use the MDL approach.
    5. Optimisers that we have in ADE GXL (or ADE Assembler) can also run many points in parallel - and are geared up for large numbers of runs with many variables and many metrics to measure - again, may be some overhead for these tiny jobs, but still overall can reach good levels of efficiency.

    So I don't think this is anything to do with simulator performance - spectre and APS have excellent simulation performance - it's about optimising the flow for optimisation (sorry about that!). We do similar things for our characterisation tools - having greater control over the simulator via a plugin interface to the simulator helps to eliminate these startup overheads (which  you'd also have in HSPICE too depending on how you run the simulations).

    Regards,

    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.