• Previous message: R. Timothy Edwards: "process scaling"
• In reply to: R. Timothy Edwards: "process scaling"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

R. Timothy Edwards writes:
 > Dear Jeff,
 > 
 > >> any scaling.  I know that MOSIS rounds off, such as the TSMC 0.25 um
 > >> process becomes a 0.24 um process in the CIF output sent to MOSIS, and
 > >> I presume that MOSIS scales it by a factor of 25/24 before passing it
 > 
 > > nope. i don't know where you're getting these .25/.24 numbers.  i
 > > think mosis does nothing special with layout given in vendor rules.
 > 
 > Sorry, that's my mistake.  Looking closer at the actual TSMC design rules,
 > I see that their so-called ".25 micron process" is actually a 0.24 micron
 > process, according to their polysilicon minimum width rule, so the CIF
 > output from magic (with cifoutput scale = 024) is correct according to
 > vendor specs.  So why doesn't TSMC call it a 0.24 micron process?  In
 > this case, does the vendor actually read rules drawn to 0.24 and scale
 > them to 0.25 themselves?  If so, does that indicate some concern over

most vendors refer to their process by the "effective" gate length
(after mask bloats and/or processing "bias") while the drawn gate
length is often larger and more conveniently "whole".  their spice
model should include an "XL" (or similar) model parameter to convert
from drawn to effective size for simulation. but what a vendor calls a
process can also be a "marketing term".

 > specifying design rules at sub-centimicron measurements?
 > 
 > While my comment doesn't apply to the TSMC process, it does apply to the
 > foundry process I'm currently looking at, the Chartered (Singapore) 0.13
 > micron process, which does in fact call for design rules on 0.005 micron
 > boundaries.
 > 
 > After cogitating about it for a while, I decided that it is not necessary
 > to extend the syntax of the magic tech file, only to relax the conditions
 > that the cif scale must be integer (GDS) or an even integer (CIF).  Magic
 > can figure out itself what expander (and reducer, for that matter) values
 > are needed.  So  "scalefactor 6.5" should suffice for a 0.13 micron
 > process.

do they really expect a drawn size of .13 um ?  anyway, sounds like
you're making a techfile where the gate length is 2 lambda, but that
(gate length = 2 lambda) is only necessary for mosis scalable rules. i
found using iota = .06 and gate length = 3 iota (refering to the units
as 'iota' rather than lambda to reduce confusion) so the drawn gate
length is .18 um (which is the vendor rule specified drawn gate length
size) more convenient for other design rules, like metal1 (width/space
= .24/.24 um), going to a tsmc .18 um process.  using iota = .09 um
would really hurt the metal1 width/space.

/jeff

 > 
 > Thanks for your helpful comments.
 > 						Regards,
 > 						Tim

• Next message: R. Timothy Edwards: "Code changes in progress"
• Previous message: R. Timothy Edwards: "process scaling"
• In reply to: R. Timothy Edwards: "process scaling"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]