Hello Ference and Philipp, Hello List!
Today in our Mumble Session we also talked about the effort for Pad Cells.
Well, there are cells we can look at under http://research.kek.jp/people/ikeda/openIP/openIP_2.pdf
This paper is in Japanese, the schematics are understandable. I am not sure, why this guy uses two grounds, but this cells are a good starting point.
As I know from Philipp, he already tried to get the schematics (and the Spice Model at the end of the paper) into the Standard Cell Generator.
Please, Ference and Philipp, talked with each other and kept me/us on topic. It would be nice, to handle the Pad Cells quite flexible and generated.
Regards Hagen Sankowski
Hi,
I just came back from my vacation.
I took a deeper look at the pad cell topic, and currently have the idea that we generate Pad cells the following way by seperating it into several pieces: The pad itself is generated with a generator where we just specify the size, and it takes the existing design rules for vias to stitch vias at the border. I developed that already. Then there is the logic area, there I am currently trying to write the specification for the logic area in our .cell format and using librecell lclayout to generate a layout for it, like the standard logic cells. Then we will need the frame power lanes, which will also be rather easy to generate. Then we need the big nmos and pmos transistors, I am not sure yet, whether we will enhance lclayout to be able to build them directly from spice netlist or whether we will use a special generator for them. In the end we have to connect and route all those components together. I am not sure yet how we will do that. Perhaps we can pre-specify the locations for lclayout then we could use a rather fixed routing, or we perhaps we need a router to do the job. Theoretically the pad cells should be done then, but perhaps some more stuff will need to be added.
Can anyone of you prepare ngspice spice tests for the pad cells that tests functionality and ESD resistance?
Best regards, Philipp
Philipp Gühring schreef op di 10-09-2019 om 08:01 [+0200]:
Can anyone of you prepare ngspice spice tests for the pad cells that tests functionality and ESD resistance?
ESD performance can't be simulated with spice simulators and is typically measured by special equipment; for example for the human-body model one need to have a high voltage capacitor and a resistor. Spice simulators are not able to handle the snapback curve of an ESD event. For ESD structures the layout is very important; they are high current events and one has to make sure that the current is spread equally over the whole structure. This means that the resistance to each point in the ESD structure should not vary much.
greets, Staf.
Hello Unfortunately we're not there yet because no one of those people who claim they're experienced in process design on this list bothered to mention, that I had forgotten the nitride CMP stop in our process for the STI.
So what ever. It's the best we can do.
-lev
On Tuesday, 10 September 2019 5:21:14 PM HKT Staf Verhaegen wrote:
ESD performance can't be simulated with spice simulators and is typically measured by special equipment; for example for the human-body model one need to have a high voltage capacitor and a resistor. Spice simulators are not able to handle the snapback curve of an ESD event. For ESD structures the layout is very important; they are high current events and one has to make sure that the current is spread equally over the whole structure. This means that the resistance to each point in the ESD structure should not vary much.
Staf Verhaegen schreef op di 10-09-2019 om 11:21 [+0200]:
Spice simulators are not able to handle the snapback curve of an ESD event.
And talking about the snapback, likely the process implant steps may need to be tuned to get a proper snapback voltage. Unfortunately that is where my knowledge stops. ESD development was done in imec in a totally separate group and I was never involved with them. Test chips typically did not include ESD protection and measurements were done by properly grounded wafer probing stations. Best to include in a next test chip an input with only the ESD clamp on it. The input should not be connected to a transistor gate as then the gate oxide may break down before you can measure the snapback voltage of the clamp.
greets, Staf.
Hi Yes. ESD test structures are already planned for the next PearlRiver release.
-lev
On Tuesday, 10 September 2019 7:43:13 PM HKT Staf Verhaegen wrote:
And talking about the snapback, likely the process implant steps may need to be tuned to get a proper snapback voltage. Unfortunately that is where my knowledge stops. ESD development was done in imec in a totally separate group and I was never involved with them. Test chips typically did not include ESD protection and measurements were done by properly grounded wafer probing stations. Best to include in a next test chip an input with only the ESD clamp on it. The input should not be connected to a transistor gate as then the gate oxide may break down before you can measure the snapback voltage of the clamp.
Hi Philipp,
The logic area can be auto-generated (but questionable if it worths, as this needs to be done only once :) ). For the pad generation, vias need to be spread all over the surface of the pad, and vias on successive layers shall be offset from each other (like a chessboard). Otherwise, the topmost metal layer may delaminate during encapsulation (due to the mechanical shear stress caused by the thermosetting process). For the output stage transistors: librarian is already capable of generating them (including ESD-tailored features, like increased resistance in drain for current equalization).
Unfortunately, as Staf wrote, ESD performance cannot be estimated using simulation. We will have to design a test chip with several candidates, test it for HBM exposure, then do the failure analysis and decide how it failed and how to improve. I already have a proposal for the test chip for pad cell validation, I just have to properly document it.
Regards, Ferenc
On Tue, Sep 10, 2019 at 8:01 AM Philipp Gühring pg@futureware.at wrote:
Hi,
I just came back from my vacation.
I took a deeper look at the pad cell topic, and currently have the idea that we generate Pad cells the following way by seperating it into several pieces: The pad itself is generated with a generator where we just specify the size, and it takes the existing design rules for vias to stitch vias at the border. I developed that already. Then there is the logic area, there I am currently trying to write the specification for the logic area in our .cell format and using librecell lclayout to generate a layout for it, like the standard logic cells. Then we will need the frame power lanes, which will also be rather easy to generate. Then we need the big nmos and pmos transistors, I am not sure yet, whether we will enhance lclayout to be able to build them directly from spice netlist or whether we will use a special generator for them. In the end we have to connect and route all those components together. I am not sure yet how we will do that. Perhaps we can pre-specify the locations for lclayout then we could use a rather fixed routing, or we perhaps we need a router to do the job. Theoretically the pad cells should be done then, but perhaps some more stuff will need to be added.
Can anyone of you prepare ngspice spice tests for the pad cells that tests functionality and ESD resistance?
Best regards, Philipp
libresilicon-developers@list.libresilicon.com