HV transmission gate obstacles

[davestew]

Hello all,

I am curious on what is the typical method of using a transmission gate when dealing with high voltages in processes where the Vgs_max/Vgb_max is far lower than the input/output voltage of the TG. The difficulty is in not exceeding the max Vgs/Vgb/Vgd limits. For example, an analog sinusoidal signal ranging from 0 to 30V is fed to the input of a TG, however the maximum Vgs/Vgb/Vgd is 5V (due to the oxide thickness). The n/pmos used are the HV symetrical ones that the process offers. The maximum Vds,Vdb and Vsb is 32V of the said devices thus the drain and source voltage are ok if we do no take in consideration the -5V/+5V voltage limits on the Vgd/Vgs. I am assuming that the gate voltages will be tied to VDD/VSS to turn it on and off and the the TG is the regular textbook type (1 nmos in parrallel with 1 pmos). Changing for a cmos process where the maximum Vgs/Vds/Vgd >=30V is not an option since the design is development for some time now.
From what I can see is that the gate voltage needs to be follow min(Vd,Vs)+maxVgs_allowed in order to turn it on (for the nmos), and similarly follow min(Vd,Vs)(or lower) to turn it off. The bulk of the nmos is in a triple-well structure, so the bulk needs also to follow min(Vd,Vs). BTw, the TG can be driven by both the drain and source side so there is no easy way to tell with of the 2 d/s terminals has the lowest voltage. Is there an elegant circuit that allows to do this? well-know to all but me

Regards,
Dave

 

[rangermad]

Do you have any HV devices you can use? A thick ox device or dmos?

 

[davestew]

No thick oxide devices available. No symmetric dmos devices either - there are asymmetric ones but that only solves the Vgd problem.

 

[dick_freebird]

In SOI, device stacking (with a gate network tailored
to suit, different depending whether you're DC or RF
oriented) is the done thing. In JI you are pinned by the
gate-body voltage in cheapo standard CMOS, maybe
free your hand some with a twin- or triple-well process.
I've seen HV DC switches done this way with an op
amp driving the bias network to appropriate "on" (all
the same, as voltage across switch collapses) and
"off" (a divider ladder spaces Vgg properly for both
off isolation, and reliability).

 

[davestew]

I was hoping to avoid the whole [op-amp(s) driving the gate and the bulk as to respect low voltage limits]. What worries me with this approach is that capactive couplling and voltage spikes during on/off transitions will violate the low voltage limits. On top of that, it creates the need for a "not-so-obvious" follower feedback circuit for what was originally expected to be a simple TG.
Ans yes, we are using the el-cheapo standard CMOS (vanilla) with no thick oxide option.

 

[erikl]

Would your vanilla process/foundry allow for including to use for the TG? Of course this also would need the higher VDD voltage for the inverter and the gate controls including the level shifting. Plus additional silicon area consumption, isolation of the HV circuitry and very careful signal routing - especially for the HV input- and output-signals (anyway, BTW).

 

[davestew]

Thanks erikl.
Unfortunately NOT (i think). One of the process flavors would be thick-gate oxide xtors (as opposed to mid or thin oxide), however the foundry does not offer a FOXFET variant. Actually, I have never seen a process where the available transistors were of FOXFET type. What process node were you think of?
Scratch that question, now that I delved into my memory a little deeper, yes I have seen FOXFET devices which where labeled as "native" transistors. We just never used them.

 

[erikl]

... Actually, I have never seen a process where the available transistors were of FOXFET type. What process node were you think of?

Actually, I think you could do this in any CMOS (vanilla, too, of course) technology, but normally foundries won't allow it (apart from their own ESD protection circuits in the pad structures, which often use FOXFETs). It doesn't need any additional steps, not to mention masks, but it always needs careful protection of the HV signals, because at the lowest routing level (poly or metal1) they always jeopardize to invert the underlying substrate, which might result in unexpected behavior. So foundries usually don't allow for it.

What process node we tried this? Our own, still in the last millenium, probably our first submicron process: 0.8µm ;-) And yes: it worked!

But aren't your thick-gate oxide xtors enough for your voltages?

Native FETs have nothing in common with FOXFETs: native MOSFETs are just normal ones, but their channels doped so as to have a very low Vth. Needs one or two more implant masks (for NFETs and PFETs, if the latter is available as native, too).

 

[davestew]

Yes the thick gate oxide would have been sufficient provided the client would be willing to accept the process flavor which would allow it. Our vanilla CMOS only allows for mid-oxides so we our stuck with Vgs limits of ~5V. Too many modules have been designed+tested+approved as the design has been in development for some time, hence the client is worried does not to take the chance that something would go wrong.

 

[erikl]

Can't you step down the input voltage (the sinusoidal signal) via a built-in resistive divider to a manageable voltage, and continue processing it?

 

[davestew]

That was our initial thinking too.
Unfortunately client does not want to compromise signal due to reasons X,Y and Z. The design is unfortunately a joint effort between us and our client. Those kind of joint efforts are always difficult to manage since client side designers and contracted design house designers (us) do not stand on equal footing (client holds the money). Very difficult to persuade them to make changes on elements they have already approved given the fact that they have their own agenda and their clients too. They would prefer no changes at all and "possibly" revisit the proposed changes in a next rev.

- - - Updated - - -

(edit to previous post)
They would prefer no changes at all if it the proposed changes are deemed as too problematic/dangerous to the end-product, and "possibly" revisit the changes in a next rev. Proposed changes will be added on wish list as they are not a must-to-have.

 

[erikl]

Understand. So I'd propose the step-down version - or no 32V input at all. If it's at least a nice-to-have feature for your client, he'd possibly approve of the step-down solution - nothing can really go wrong, at least it would be a free trial on his X,Y,Z reasons, wouldn't it? Good luck!

 

[davestew]

Thanks.
Much appreciated all the received input.