Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very slow Cace simulation on ulpcomp2 input offset example #74

Open
azwefabless opened this issue Jun 3, 2024 · 5 comments
Open

Very slow Cace simulation on ulpcomp2 input offset example #74

azwefabless opened this issue Jun 3, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@azwefabless
Copy link

cell is ~/cheetah_v3_analog/dependencies/sky130_icrg_ip__ulpcomp/
Run time is exceptionally long for me but about 100x faster for Tim. Suspect an IO setting difference that Tim has set but I have not.
The simulation with the speed problem is input offset voltage

@mole99
Copy link
Member

mole99 commented Jun 4, 2024

Hi, thanks for the bug report!

The repository for sky130_icrg_ip__ulpcomp is here: https://github.com/efabless/sky130_icrg_ip__ulpcomp/

And the problematic parameter is that one here, right? https://github.com/efabless/sky130_icrg_ip__ulpcomp/blob/e0244073f7b21e02c1f6d787516cf0ae9cfe5436/cace/sky130_icrg_ip__ulpcomp2.txt#L425

I've seen something similar with a transient simulation as well. Are you getting a lot of "Reference value" output?

Are you running CACE via GUI or CLI? If you are working via cli, could you try passing --sequential? Please make sure cace is up to date as --sequential was broken previously.
If you are working via gui, you can enable sequential mode in the settings.

@mole99 mole99 added the bug Something isn't working label Jun 4, 2024
@azwefabless
Copy link
Author

Yes, Correct repo and correct file. There are 2 sims that are dying in what appears to be similar manner. Both output enormous amounts of Reference value data to the GUI. Tim runs the same config file and it finishes in minutes for him. Mine is still going after 20 minutes with 8 railed CPU cores. Sequential might be a good workaround but is not a fix. I will try it today.

@mole99
Copy link
Member

mole99 commented Jun 4, 2024

Thanks! I just ran it on my side (fresh pull) and here it seems to work well:

cace --source schematic cace/sky130_icrg_ip__ulpcomp2.txt -p offset_error

grafik

I believe it could be a tooling issue. I am using Nix to set up my tools, it uses the stable version of ngspice.
There's no installation documentation on that yet, but it's basically the same as in OL2: https://openlane2.readthedocs.io/en/latest/getting_started/common/nix_installation/index.html

My PDK is bdc9412b3e468c102d01b7cf6337be06ec6e9c9a (2024.01.10) (enabled).

Which tool and PDK versions do you use?

@mole99
Copy link
Member

mole99 commented Jun 4, 2024

Taking a second look at it, it doesn't seem to work well ^^
The results are nonsense, also I get measurement errors from ngspice:

Error: measure  vhigh  find(AT) : out of interval
 meas tran vhigh find v(inp) when v(vout)=1.65 cross=1 failed!

Is the repository in a working state? I am asking because I had to replace some /home/ttuser/... paths with {PDK_ROOT}.

@azwefabless
Copy link
Author

I'm having the issue after swithing to a prereease version of the PDK that Tim requested. Also note that there are a lot of convergence related comments in the terminal. I suspect either a models issue or an environment setting variable around convergence or ngspice setup that is missing from the default config information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants