Hi, i'm trying to generate gate over-driving voltage level circuit. I'm getting around 8kHz frequency from ring oscillator at 'clk' node. since it looks almost sine shape i'm passing it through Schmitt Trigger from which on same 8kHz frequency around 51% duty cycle is archived at node 'dclk'. then to smooth-out the ringing at the edges an Inverter is placed which gives nice and clean 8kHz at 'indclk' node which is shown in attached image. Now, for prescaler dividing it by factor of 8 so by using standard cell of D FF its made. However, in attached image node 'Va' is not consistent in period, very much glitchy. I have tested each individual as blocks with ideal inputs or so and they works. Can someone help me about it.

Try using a smaller time step. It may be a problem of racing conditions also. I don't have problems with the C2MOS flip flop.

Yes it's only a matter of timestep. I ran your circuit using 5ns (2nd picture) instead of 5us (1st picture) timestep and results are all fine. I still see a problem on Va at ~3.3ms, this is a bit scaring...

Perhaps the problem is at indclk, as it is too fast. This inverter should be changed to standard VT or even to a 5 V device. Or a capacitance could be added there.

@Luis Henrique Rodovalho the indclk period is more than 120us so it is not fast for this technology, even at 1.5V.

The rise and fall edges seem inconsistent. This looks like a result of small time-step. If the inverters were a little more slower, it wouldn't be a problem. I think that if this circuit were fabricated, it wouldn't be a problem. Anyway, simulation will suck. I don't know. Maybe, if the simulation error tolerance were increased, there would be only small time steps at the edges.

@Pritesh Ps @Luis Henrique Rodovalho I tried to use the Xyce simulator on this circuit and there are no problems whatsoever, even using 5us as the timestep. the

tstep

parameter in a

.tran

should always be a 'suggested' timestep, the simulator must choose the actual timestep depending on the speed of the signals. Attached the modified schematic with Xyce commands in addition to ngspice. SO it seems ngspice has some problems simulating a low frequency circuit for a long time, I will try to run the simulation in ngspice with a very low tstep to see if the problem goes away.

Thank you @Stefan Schippers and @Luis Henrique Rodovalho for helping. Yes, that Va Flop is triggered on falling edge sometimes. At first i thought it could be something wrong in circuit and started to test in possible ways. As its foundry provided standard cell so i didn't doubt on it. Lastly, i came across to check proper behavior i had to use lower time steps to look for unwanted response.

@Pritesh Ps As a side effect i have ran a simulation with a 5 million point raw file and it seems in some cases the waveform drawing by xschem generates requests that are too big for the xserver to handle so i will make some fixes to split those big waveform drawing requests into smaller chunks. Testing real word examples always help to improve the tool.

@Stefan Schippers woh! that's huge raw data. I mean, SPICE capabilities. Ok. So, it will be like chunks of smaller request. Thanks again. I took an IEEE paper where such things are fabricated and proven.

Ngspice has some problem simulating logic that reacts in hundreds of picoseconds time with timestep of 1microsecond. You have to use at least 1nanosecond otherwise you get erratic simulation.

And only changed time step to 1u i.e. 'tran 1u 5m uic ' to reduce the simulation time rather than using 1nSec. and I got as following image.
At this point i'm totally not able to understand, what's the issue for not getting proper response

This is your original problem. If you reset the timestep back to 1us you get back the original problem. This is a problem with ngspice and should be filed as a bug. May be i can manage to create a super simple test case (a frequency divider) and submit the problem. For the time being there is no alternative, you have to use 1ns tstep parameter in .tran and wait... ... or use Xyce

Thanks a lot @Stefan Schippers! I understood it now. Yes as suggested, i'll use it. Yeah, i was also thinking for filing it as bug. Since, designs may slow for low power and the responses of standard cells could be very fast and that creates a situation where time step has to be taken very low while final time has to be taken a large, only then the design responses can be checked. Also, adding to it as final time is big and step time is very low it will definitely generate very large data which is also very time consuming depending on resource hardware, as mentioned earlier by Stefan. And, once my whole circuit block design is done. Will look forward to Xyce (new for me).

If you look the last schematic I posted you see the

devices/spice_probe.sym

symbols attached to nets. nets with this symbol attached will be saved in the raw file. Nets without this symbol will not be saved. I used these symbols to save only the nets i am interested in and removing the 'save all' line from the commands. This will reduce the size of the raw file considerably and make the simulation run a bit faster.

Great. this may save simulation time a lot, as i'm interested in only few nets like clk, dclk, indclk and Vc. and can procced further for next block of Non-overlapping clock generation and next to it DC-DC switch capacitor. and done!

Not exactly related to your question maybe, but I remember back then I did have some problems with transient and DC analysis in ngspice. I guess I was applying some settings suggested here to get rid of those issues: https://gist.github.com/turingbirds/c90672c3b126d0d5f37f90494d5057cb

@Stefan Schippers How do you specify which signals and nets get written to the .raw file? My sims are killed because of memory limitations

@Matthew Siyu Chen if you are running ngspice in interactive mode everything is kept in memory. If process gets killed this happens before the ngspice process has a chance to write the results in the raw file. For very large simulations use ngspice in batch mode. In this mode all data is immediately written to raw file, keeping memory usage low. If you need interactive mode you can try to remove the

save all

and

.option savecurrents

(if present) and do a

save

of interesting nodes only.