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

ldo_v2 #5

Closed
Ahmedredamohamed2022 opened this issue Dec 5, 2022 · 9 comments
Closed

ldo_v2 #5

Ahmedredamohamed2022 opened this issue Dec 5, 2022 · 9 comments

Comments

@Ahmedredamohamed2022
Copy link

Hi, I am trying to use your design titled "ldo_v2". I would like to double-check with you the simulation results. As attached are the test bench and simulation results of line regulation @different load currents. I found that
1- The ldo works well as long as IL is less than 200uA@ volt of enable equals 2.3V.
2- When setting the volt of enable at 3 V, the ldo works well as long as IL is less than 100uA. should the volt of the enable be set a certain value?
3-How can I adjust the ldo to regulate the output @ IL more than 1mA to 10 mA? Should I adjust the testbench with a certain condition or I missed something?
Thanks
image
image

@ChrisZonghaoLi
Copy link

It did not surprise me that the simulation results of this design did not match to what it claimed on the README file, as there are so many flaws of this design. For instance, there is no capacitive load at the output, no stability testbench to ensure the loop stability (at both min/max current load condition as well as min/max cap load condition), no .OP analysis to double check the operation region of transistors, bad choice of the resistive feedback network (should be made of the ratio of multiple unit resistor). Anyway, in your case I would probably check first the op-amp open-loop response, and then probably increase the width of the pass transistor (10 is probably too small, try 30/40). I guess when IL is around 300uA, that pass transistor is already in triode region! And then do a loop stability test to see the open-loop gain and phase margin.

@atorkmabrains
Copy link
Contributor

@ChrisZonghaoLi and @Ahmedredamohamed2022 Here are the final script that we have used to generate our results with the associated netlist embedded in code:

https://github.com/mabrains/Analog_blocks/blob/main/scripts/ldo_corners_v4.py.

Also, be aware of 2 things. I don't believe any analog design using Skywaters PDK 130nm that is publically available will ever work. As the models are very heavily binned. Which make them unusable at all:
https://github.com/google/skywater-pdk-libs-sky130_fd_pr/blob/main/cells/nfet_01v8/sky130_fd_pr__nfet_01v8.pm3.spice#L36

This just one bin. There 68 bins that has a lot of gaps in between. I'm planning to redesign this in GF180MCU which might work better.

@ChrisZonghaoLi
Copy link

I am aware of that and yes this is very unfortunate, I guess the reason might be that SKY130 was a digital process back then...

@atorkmabrains
Copy link
Contributor

@ChrisZonghaoLi and @Ahmedredamohamed2022 Please ignore whatever here in that repo from the simulation point of view. GDS is only correct here in that repo.

The correct simulation is here:
https://github.com/mabrains/Analog_blocks/blob/main/scripts/ldo_corners_v4.py#LL112C5-L112C8

We used the high L and high C method for loop simulation. Please check the link above.

We used resistive load to be able to simulate a specific load current. We have simulated at different capacitive loads as well. But not included in the above script.

But again, remember the models for skywaters here are totally unusable.

@Ahmedredamohamed2022
Copy link
Author

@atorkmabrains @ChrisZonghaoLi I would like to thank you for sharing this notice. That means Skywater PDK 130nm is not the best choice for analog circuit design till now! right. You mentioned that the models for skywaters are totally unusable, is it confirmed by silicon validation? Is there a way to fix it or avoid this issue?

@atorkmabrains
Copy link
Contributor

@Ahmedredamohamed2022 The problem is how the bins are defined in Skywaters according to what we have seen. Check the link above.

I believe that Efabless is working on enabling the continuous versions of the model. That might be better to address this issue.

Take a look at this:
google/skywater-pdk-libs-sky130_fd_pr#3

Cc @proppy @RTimothyEdwards @mithro

@RTimothyEdwards
Copy link
Contributor

@atorkmabrains : We have continuous models---they are currently sitting in a branch that Proppy pushed---But there is little evidence that they solve anything; they were made using the same characterization data from the discrete set of devices with supported values of W and L. They continue to show unlikely behavior for some parameters at points between the original device widths and lengths.

The existing models are certainly not "unusable"---They have been used successfully by multiple designers to make robust, working analog designs. But one does need to be a bit careful about how a particular design might be sensitive to certain parameters.

@atorkmabrains
Copy link
Contributor

Thanks @RTimothyEdwards for the feedback.

@atorkmabrains
Copy link
Contributor

@ChrisZonghaoLi and @Ahmedredamohamed2022 we will redesign this on GF180MCU. I'll close the ticket.

@atorkmabrains atorkmabrains closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants