characterizing Clock Gating cells

chandara313

Newbie
Joined
Feb 5, 2024
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
49
Trying to characterize a clock gating AND gate. Facing issue to get induce the arcs automatically to get the setup/hold time for the ULVT version of the cell. Other VT's does not encounter the issue. I know that lower VT means less delay the constraint margins will tighter. But how can I verify this?

Thanks in advance.
 

what tool are you using? what errors are you seeing?
I'm using siliconsmart/primelib. Not facing error per say, but I'm unable to induce the same arcs for a similar clock gating cell with different VT's. LVT version was able to recognize the no_change arc which enables the measurement for setup/hold time. However, the same command fails to create the arc for the ULVT version of the cell.

So, my initial thinking was the ULVT cell has smaller transition time which makes generation of the clock gating arcs was not recognizable by the char engine. I have tried using the pre-characterization flow provided by the tool. It does functional recognition by feeding stimulus to spice netlist. But no results.
 

I believe it is possible to force siliconsmart to work on the arc of your liking if you provide them by hand. I have not touched silicon smart in many years so I am not entirely sure

in any case, the issue might be that the ULVT version glitches and that throws the auto recognition engine off. setting the arc by hand might still give the same result
 

Thanks for the inside. I have tried manually inducing using AUS function, which creates signal per say. I managed to get some numbers but the measurement was off by a lot. So, I need to get the stimulus correct first. By the way, if I set a separate glitch threshold, higher than the logics, do you think, the LUT will be accurate? By default glitch threshold follows logics and set to 70-30 in my case. Which is pretty low already.
 

not sure. glitches are tricky and if you get it wrong your cell library is not reliable...

you can try to capture the spice file generated by silicon smart and run a simulation by yourself to investigate what is happening. I remember doing this for debugging purposes and it was a pain. but it was the only way to decipher what was getting siliconsmart confused
 

Good news. I managed to create the no change arcs. I did manual comparison of the fsdb's. ULVT has glitch at the output. Needed some additional commands to check for glitch threshold. Usually If not explicitly defined it will follow the logic threshold. For some reason, it did not work in this case. But still need verify the quality of the lib.
Thanks for the help. Appreciate it.
 

Cookies are required to use this site. You must accept them to continue using the site. Learn more…