cell libraries and place and route

[server]

message unavailable

 

[Torgny Johansson]

Hi again!

As I said before we're trying to create a cell library that will work with
place and route tools. We seriously need to minimize the time used so I
wonder which files are absolutely necessary for this?

What we've figured out so far is that we need the layout for the cells, a
lef file describing the technology and the cells and possibly an abstract
view of the cell?

What else is needed? We don't need a TLF unless we wan't time driven
placing right? Is the abstract needed? Do we need any kind of timing files
for basic place and route?

Thanks!

Regards Torgny

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

 

[A. B.]

fogh wrote:

Silvaco announced that they support bsim5.

That very nice and all, but what the heck is bsim5 ? It is not even
mentioned on berkeley EECS.

I saw something by Jin He and al. If you can't find it I can e-mail to

you the pdf. Good luck.

 

[Andrew Beckett]

I believe it is a Surface Potential model which is currently under
beta-test from Berkeley. There doesn't seem to be much information
about it publicly yet.

Andrew.

On Mon, 04 Oct 2004 13:42:22 -0500, "A. B." <b@f.g> wrote:

fogh wrote:
Silvaco announced that they support bsim5.

That very nice and all, but what the heck is bsim5 ? It is not even
mentioned on berkeley EECS.

I saw something by Jin He and al. If you can't find it I can e-mail to
you the pdf. Good luck.

 

[Duncan Barclay]

Barry Bass wrote:

Often when I extract a Spectre netlist in Cadence I get a warning
that indicates I have a mismatch between the terminals in cellview
and the pin order on schematic or termOrder property on the CDF.

While it doesn't seem to cause a problem, what is this, and how do
I correct it or prevent it from happening?

Barry, as others have indicated this is when the symbol, schematic and
CDF get out of sync.

Most of the time, the Spectre default netlist order gets things right (I
cannot remember the details but it does something input/outputs,
outputs, inputs with each in alphabetical order). However, in the past
we've been really burnt by this with circuits that appear to be
connected correctly not simulating correctly for no reason. Until we
look at netlist and realise that the power supply is connected backwards...

The rule that I try and drum into people I work with is that if you see
this, disregard simulation results and regenerate the symbol+CDF. The
manual way is to rename a pin in the schematic, do a create cellview
from cellview, and then name it back again. This gets everything in sync
and has worked without fail since about IC4.4.3.

As I mentioned above, most of the time things are okay and you can
ignore this, but I never let sign off simulations have this error...

Duncan

Regards,

Barry

 

[Richard Griffith]

Szekit wrote:

Thank you very much for your answer.

If upgrade is not an option in the near future, is there a
quick-and-dirty way to get around this problem?

Write an ahdl model to replace the bsource. This is a nonlinear resistor
described by the function as you see it. The model deck would have to be
changed to call the ahdl model.

Szekit

Andrew Beckett <andrewb@DcEaLdEeTnEcTe.HcIoSm> wrote in message news:<12e6l0hndgin3gg7v1oa9lorpdsjge656q@4ax.com>...

You're using too old a version of spectre. bsource was introduced
(officially) in IC5033. If you are using a version before IC50 MSR3
though, you'll get this (bsource was there, but as an engineering
release).

In practice you need to use IC5033 or IC5141 to use bsource. Your
design kit probably says this somewhere in the documentation...

Andrew.


On 22 Sep 2004 11:08:50 -0700, szekit@gmail.com (Szekit) wrote:


Hi,

In my resistor's model deck, I have the following:

r1 ( 1 12 ) bsource r=rsh/mf*1/(w-dw)*(1+pvcl*abs(v(12,2))+pvc2*v(12,2))*tfac/6

When I run with spectre simulator, it says that the v function is not
defined or being called recursively.

What is the problem here? Am I missing some files?

Thanks
szekit

 

[fogh]

John,

Aki Fujimura mentioned during DATE that a foundry database standard not quite unlike OA was on it's way.
Do you have news about that ?
Will that help share process/physical/electrical data among P&R, layout edit, retargetting, verification, tutti quanti ?

It is true that those tools don t necessarily need the same values, so there must be a mechanism to let the PDK maker declare tool-specific values. But it is not AFAICS contradictory with those tools using tech data from the same source by default.
Tech data is needed by icc, fastcap/RCX, VXL, cell3, Qtrek, .... and too little integration to my taste. Wouldn t you see a unified database that contains enough info LPE, EM solvers, and can be extended for complete TCAD, as a step in the right direction ?

John Gianni wrote:

Rajeswaran M <m_rajeswaran@yahoo.com> wrote in message news:<cjcfvs$3up$1@home.itg.ti.com>...

Is there any simple way to get QTrek techfile??


The information in the DFII techfile is not necessarily the same
information that is in the Virtuoso Layout Migrate technology file. In
fact, most of the information in the qtt file isn't even in the DFII
techfile (yet).

Just like you wouldn't necessarily derive an Assura or Calibre rule
deck from the DFII technology file, you don't necessarily have all the
data points you need for a layout migration or optimization or eco in
the DFII technology file.

However, there is a simple AE ware (undocumented unsupported) 300-line
PERL script, tf2qtt, that creates a boilerplate qtt file from an ASCII
dump of the DFII techfile.

In addition, Customers should press their CDK vendor to supply the qtt
file (for now) in the CDK pdk vlm directory. For example, I just
looked in the latest Cadence generic 90nm CDK (CDK090_v1p0p7) which
contains the following directory tree:
CDK090 / pdk090 / vlm090 / gpdk090.qtt & gpdk090_migratemap.il

John Gianni
---
Nothing I say on the USENET is sanctioned by my employer.

CDK === Complete Design Kit (everything to run all desired tools)
pdk === process design kit (enough to run all desired custom
tools)
vlm === Virtuoso Layout Migrate (the desired tool in question on this
thread)

 

[@xignal-A%&HY%$v#&G=.de]

LInd_1 net7 net4 $[Ind]
That's exactly the documented definition of an
inductor for CDL.
In my opinion you can not output any additional
parameters.
The only thing you can have is a third terminal to
substrate, but this is optional, I guess.

Maybe I'm wrong here, if I ,let me know
how you have managed it to output additional parameters,
I'm very interested in.
Benrd

Nikolaos Kasparidis wrote:

Hello,
I have a problem when attempting to extract a valid schematic using
File->Export->Cdl in CIW. The schematic contains a custom 2-port
device(inductor like, made by me) and two pins. The device contains an
auCdl view (copied symbol). The schematic returns no errors or
warnings in Check&Save. The device contains some CDF properties which
I need extracted in the netlist, for example length, number of turns
(CDF names Length and Turns)

In the CDF properties of the device under auCdl I give the following
properties
netlistProcedure: ansCdlCompPrim
instParameters: Len T
termOrder: P1 P2
propMapping: nil Len Length T Turns
namePrefix: L
modelName: [Ind]

the rest are empty. The results of the netlist for the device look
like this
LInd_1 net7 net4 $[Ind]
net7 and net4 are the pin nets and also the modelName but nothing of
the other parameters. I believe I have to use the dollarParameters
somehow, but my attempts were fruitless (the documentation was not
very detailed on this part). I need somehow the other parameters. I
have valid extraction setup for spectre and auLvs but need auCdl too.

Thank you

 

[Terry Lalonde]

I think that you are doing things correctly:

check the type of two properties:

instParameters should be a list
propMapping should be a list

===========================
You can use the procedure cdfDumpAll
to dump the cdf for a library.

cdfDumpAll("LibraryName" "fileName")
the the file: fileName find the section for the
device of interest and look for the auCdl section:
should be something like:

cdfId->simInfo->auCdl = '( nil
netlistProcedure ansCdlCompPrim
instParameters (Len T)
componentName ind
termOrder (P1 P2)
propMapping (nil Len Length T Turns)
namePrefix "L"
modelName "[Ind]"
)


Terry


"Nikolaos Kasparidis" <redhavoc@yahoo.co.uk> wrote in message
news:4e44ab2a.0410070121.63cf430e@posting.google.com...

Hello,
I have a problem when attempting to extract a valid schematic using
File->Export->Cdl in CIW. The schematic contains a custom 2-port
device(inductor like, made by me) and two pins. The device contains an
auCdl view (copied symbol). The schematic returns no errors or
warnings in Check&Save. The device contains some CDF properties which
I need extracted in the netlist, for example length, number of turns
(CDF names Length and Turns)

In the CDF properties of the device under auCdl I give the following
properties
netlistProcedure: ansCdlCompPrim
instParameters: Len T
termOrder: P1 P2
propMapping: nil Len Length T Turns
namePrefix: L
modelName: [Ind]

the rest are empty. The results of the netlist for the device look
like this
LInd_1 net7 net4 $[Ind]
net7 and net4 are the pin nets and also the modelName but nothing of
the other parameters. I believe I have to use the dollarParameters
somehow, but my attempts were fruitless (the documentation was not
very detailed on this part). I need somehow the other parameters. I
have valid extraction setup for spectre and auLvs but need auCdl too.

Thank you

 

[Andrew Beckett]

On Wed, 06 Oct 2004 22:00:32 -0400, Richard Griffith
<rgriffith@istop.com> wrote:

Write an ahdl model to replace the bsource. This is a nonlinear resistor
described by the function as you see it. The model deck would have to be
changed to call the ahdl model.

Just to make sure we're clear here - I would recommend writing a
Verilog-A model rather than a SpectreHDL model. Often "ahdl" views
in DFII refer to SpectreHDL (although the term itself applies to any
analog hardware description language). SpectreHDL is an older,
proprietary language, with limited support going forward.

Regards,

Andrew.

 

[CuteGirl]

I HATE lugging the printed one with me on airplanes......

*cheers*!!


<cg>
Anna

 

[Diva Physical Verificatio]

Unless the child cells are stand-alone blocks that do not interact with
any other cells, they have to be able to be connected together. If you
cannot connect them in the layout, they will not be connected on the
die.

On 7 Oct 2004 23:16:20 -0700, makoc@gmx.de (Manuel Koch) wrote:

Diva Physical Verification <diva@cadence.com> wrote in message news:<0pcbm01pe1i3c997rt3kj6fqoid1mkil76@4ax.com>...

This is the normal way hierarchical design with bottom up LVS is done.
...
The child cell pins should be connected together ...

OK, how exactly do I do that? Do you mean by physical (e.g. metal)
connection? In our designs this is often not possible.

 

[Diva Physical Verificatio]

Yes. The hierarchy should be defined to facilitate that, grouping blocks
that form a higher level block. If you match your schematic hierarchy
and layout hierarchy, you can get creative and use macrocell extraction
to feed LVS functional netlists instead of transistor netlists and
verify your entire design, from the bottom up, as you go. Without having
to switch to another tool when the design becomes large. I have heard of
a customer doing a 50 million transistor design, using only Diva DRC and
LVS, that way. It takes discipline, though.

On 9 Oct 2004 03:15:34 -0700, makoc@gmx.de (Manuel Koch) wrote:

Unless the child cells are stand-alone blocks that do not interact with
any other cells, they have to be able to be connected together.

And they will connect together but not already in the second level of
hierarchy.
Are you suggesting that in every new (higher) level of hierarchy all
connections should be made so that only one pin of every signal is
necessary?

 

[S. Badel]

1. What if you do it in the libInit.il of the tech. library ?
If you don't mind adding or modifying a PDK file...
It would be loaded only once, of course, not sure this matches your needs.

I saw also there is tcRegPreLoadTrigger() which allows a trigger to
be called each time a technology file is loaded.

2. you can do (didn't try it)
foreach( packet drGetPacketList("display")
drDeletePacket("display" packet)
) ; foreach
or even enclose it in foreach( display drGetDisplayNameList() ... )
to process all displays.

I think however that all PDKs should use different packet names in order
to be able to load several at the same time without conflicts.

3. try drLoadDrf( file nil )

stéphane

Erik Wanta wrote:

We want to be able to support the use of multiple PDKs at one time. I
want to be able to load the appropriate display.drf for the layout
that I am currently opening up. I created a user trigger to do a
drLoadDrf() on the display.drf for the technology that the library is
attached to.

Problems:
1. I get a pop up message when I open that layout asking if I want to
see a list of all the undefined layers. So, it seems that drLoadDrf
is taking place after it checks to see if packets are defined for all
the layers. Any ideas how I can disable this warning or load the
display.drf sooner?

2. How do I clear all the packets ... from virtual memory? I want to
start from a clean slate before loading the display.drf from a
different technology.

3. If I use drLoadDrf it asks If I want to save the display.drf when
I exit icfb. Maybe if I find a way to purge packets in step 2 it
won't ask.

4. Can't have 2 layouts for 2 different technologies open in the same
session.

procedure(dt(argList)
prog((techName libPath)

when(techName=techGetTechLibName(argList->libId)

/*
foreach(packet drGetPacketList(drGetDisplay("display"))
drDeletePacket(drGetDisplay("display") packet)

) ; foreach
*/


libPath=ddGetObjWritePath(ddGetObj(techName))

when((isFile(strcat(libPath "/display.drf")) &&
!isFile("display.drf"))

drLoadDrf(strcat(libPath "/display.drf"))

) ; when

) ; when

return(t)

) ; prog
) ; procedure

when(member('dt deGetAppInfo("maskLayout")->userAppTrigList)
;if registered, unregister
_deUnRegUserTrigger("maskLayout" 'dt nil nil)
) ; when

;register the display.drf load user trigger
deRegUserTriggers("maskLayout" 'dt nil nil)

---
Erik

 

[Terry Lalonde]

Ok, further up in that same section of the CDF dump for the cell do you see
definitions of: Length and Turns ??
i.e.

cdfCreateParam( cdfId
?name "Length"
?prompt "Length"
?units "lengthMetric"
?defValue ""
?type "string"
?display "artParameterInToolDisplay('Length)"
?parseAsNumber "yes"
?parseAsCEL "yes"
)

Terry

"Nikolaos Kasparidis" <redhavoc@yahoo.co.uk> wrote in message
news:4e44ab2a.0410080008.3eeda35e@posting.google.com...

Yes I have checked through the cdfDumpAll and they are lists. I assume
that CIW makes them a list anyway (I put the values through
Tools->CDF->Edit). I hope I'll figure something out, because there has
to be a way to extract the properties to the netlist. If I find
something, I'll let you know

Thanks for your time
Nick


"Terry Lalonde" <tlalonde.Hold.the.spam@potentiasemi.com> wrote in message
news:<2NWdnc-gK8ed2_jcRVn-qg@rogers.com>...
I think that you are doing things correctly:

check the type of two properties:

instParameters should be a list
propMapping should be a list

===========================
You can use the procedure cdfDumpAll
to dump the cdf for a library.

cdfDumpAll("LibraryName" "fileName")
the the file: fileName find the section for the
device of interest and look for the auCdl section:
should be something like:

cdfId->simInfo->auCdl = '( nil
netlistProcedure ansCdlCompPrim
instParameters (Len T)
componentName ind
termOrder (P1 P2)
propMapping (nil Len Length T Turns)
namePrefix "L"
modelName "[Ind]"
)


Terry

 

[David Cuthbert]

Tom_Ding@hotmail.com wrote:

I am a jackeroo on creating programs by using SKILL language.
When I try to run a SKILL example called "axlform.il" which is in the
Allegro 14.2 installation path, Allegro lists an error by using a
string like the following:
"E-*Error* axlFormDisplay: argument #1 should be an "other" atom (type
template = "o")-nil".
I can not understand what this error message means. Please experts help
me. Thanks a lot!

Hi Tom,

This message means that axlFormDisplay is expecting something other than
a standard SKILL type -- these types are listed on page 20 of the
(PDFized) SKILL language reference. (Unfortunately, SKILL itself
doesn't know about most GUI elements, so you get this rather ambiguous
message.)

I'm not familiar with Allegro (I'm over in CIC), but if you search on
SourceLink for axlFormDisplay, it will direct you to the Allegro/APD
Design Guide: SKILL Reference Manual, in the Form Interface Functions
chapter (11). It gives the following example on how to use these functions:

-----
; User-callable function to set up and
; display the Extract Selector form
(defun myExtract ()
fileList = (cdr (cdr (getDirFiles
cadr( parseString( axlGetVariable("TEXTPATH"))))))
form = axlFormCreate( (gensym)
"extract_selector.form" `("E" "OUTER")
`_formAction t)
axlFormTitle( form "Extract Selector")
axlFormSetField( form "view_file" (car fileList))
selectedFile = (car fileList)
foreach( fileName fileList
axlFormSetField( form "file_list" fileName))
axlFormDisplay( form)
); defun myExtract
-----

So axlFormDisplay() is expecting a form created by axlFormCreate().

Hope this helps.

--
David Cuthbert (dacut@cadence.com) Tel: (412) 599-1820
Cadence Design Systems R&D

 

[Roger Light]

Manuel Koch wrote:

I have a problem creating good printouts from Virtuso's layouts for
documentation porposes.

I want vector graphics output OR high resolution bitmap. The problem
with Cadence is that their printing service produces a horrible
mixture of both.
If you have one of the following outputs set up:

Do you have any suggestions what else I can try?

There have been a few threads on this in the past. Try searching for
"raptor" in this group.

My solution, which I'll freely admit isn't the best is to use a
combination of raptor and the convert program from ImageMagick.

..cdsplotinit entry is:

PNG Out|Generic 600 dpi Adobe PostScript Level 1 Plotter: \
:manufacturer=Hewlett Packard PCL: \
:type=intCLR: \
:spool=/eee/vlsi/Cadence/cdsPNG.sh: \
:sf:sh: \
:maximumPages#1: \
:resolution#600: \
aperSize="5cm sqr" 1182 1182 0 0: \
aperSize="10cm sqr" 2364 2364 0 0: \
aperSize="20cm sqr" 4728 4728 0 0: \
aperSize="40cm sqr" 9456 9456 0 0: \
aperSize="A4" 4758 6846 0 0:


cdsPNG.sh is:

#!/usr/bin/tcsh

setenv PATH /opt/csw/bin:$CDSDIR/tools/plot/bin:$PATH
setenv file /var/tmp/cadPlot$$

cat - > $file

raptor -a -m color -q 100 $file | XWDout > ${file}.xwd
convert -trim ${file}.xwd ~/plot.png
rm -f $file
rm -f ${file}.xwd

#end

Like I say, I'm sure there is a better way of doing this.

You can get encapsulated postscript with a B&W preview for Word with
this .cdsplotinit entry:

EPS Out (With B&W preview for Word)|Encapsulated Postscript: \
:manufacturer=Adobe: \
:type=epsfiC: \
:EPSPreviewType=TIFF: \
:EPSPreviewTIFFCprt="": \
:EPSPreviewByteOrder=LittleEndian: \
:EPSPreviewCompAlg=none: \
:EPSPreviewTIFFStripCnt#1: \
:EPSPreviewTIFFTS: \
:EPSPreviewTIFFHost: \
:resolution#300: \
:maximumPages#1: \
aperSize="A4" 4758 6846 90 90: \
aperSize="A3" 6846 9702 90 90: \
aperSize="Unlimited" 72000 72000:

Hope this helps,

Roger

 

[Pete nospam Zakel]

In article <df2qm05vlte1mph7tmh4rf0r9mndl2b8ve@4ax.com> Andrew Beckett <andrewb@DcEaLdEeTnEcTe.HcIoSm> writes:

On Wed, 6 Oct 2004 19:16:07 +0000 (UTC), "Dmitriy Shurin"
shurin@bgumail.bgu.ac.il> wrote:

I have a button field which has to update a string field in a form. The
string field updates, but the value can be seen only after i reenter the
form. it is very inconvenient, because i can't see the result
immediately. this is the code i have so far

;;;Creation of "Select" button for Vin(+)
VinPosBut=hiCreateButton(
?name 'VinPosBut
?buttonText "Select"
?callback "VinPosStr->value=objSelect()"
)
snipped
is there anything i do wrong?

Yes, you should make your callback for the button start from the
formId, rather then just the field. I'm not 100% sure as to why this
has to be, but it certainly doesn't work properly otherwise.

Andrew is correct, and the reason is because the initial field is a defstruct.
When it is instantiated into a form, a user type is created from the
defstruct. That user type does not replace the defstruct, which is still
the value of the field symbol, but becomes a property of the form where the
field symbol is the property name.

So field->value will refer to the value of the defstruct (which will work for
uninstantiated fields) and form->field->value will refer to the value of the
user type (which is the only way to reference instantiated fields).

-Pete Zakel
(phz@seeheader.nospam)

"What makes the universe so hard to comprehend is that there's nothing
to compare it with."

 

[David Cuthbert]

Manuel Koch wrote:

I want vector graphics output OR high resolution bitmap. The problem
with Cadence is that their printing service produces a horrible
mixture of both.

This is an unfortunate aspect of how display stipples are defined. I,
too, have been less than pleased with the resulting output.

I can think of a number of fixes, but none are that simple:

1. Allow the display data to define both a bitmap and a
Postscript-defined pattern. Then your fill patterns are defined in the
ideal formats for both screen and paper. Downside: requires more work
for the user.

2. Allow the user to specify how much the bitmap is bloated. Downside:
very hard to make this look right.

If you have one of the following outputs set up:

- postscript (1,2): you get the outlines of polygons as a vector
graphic and the fill patterns as low-res bitmaps; unfortunately the
fill patterns are not clipped to their corresponding polygons but
merged with all layers and cut in ‘larger squares' afterwards.

I am seeing some oddities with the way we draw polygons and conics, but
the resulting output looks correct. Are you seeing the same?

At any rate, we probably should be clipping the polygons. I'll see if I
can find out why we're not.

With
the :residentfonts: option text is preserved as text, but each letter
as a separate object, so you cannot change the size or shape of text
afterwards.

Hm... this I'm not seeing. I put a label, "This is a label", on my
layout; I see the following Postscript:

1 rfta save 0 /Courier findfont
140 90 0 rfsc
(This is a label) rft

(Just to make sure... you've spelled the option as :residentFonts: ?)

Can you describe how to make a small testcase which exercises this?

- hpgl: you get only the polygon outlines, no fill patterns;
unfortunately shapes are merged, clipped and stacking orders do no
longer correspond to the drawing layers.

Unfortunately, I have no way of testing HPGL output here in Pittsburgh,
so I can't comment on this.

The best way seems to be to export a GDSII stream and use a third
party utility.

Another route (which I might try out this afternoon) is to write a SKILL
script which generates Postscript directly from the objects on the
layout. It's about a week's worth of effort if you're a SKILL and
Postscript expert, much longer otherwise.

Anyway, I will ping the CAT folks (who are in charge of plotting
services) on these issues.

Thanks,
Dave

--
David Cuthbert (dacut@cadence.com) Tel: (412) 599-1820
Cadence Design Systems R&D

 

[David Cuthbert]

fogh wrote:

I would like to generate EMF files from (simple) schematics or
waveforms. How could I do this in skill ? (I hope it would be cleaner
than from eps to emf).

Hm. Not easily. The problem is that EMF (Windows Enhanced Metafiles)
is a binary format, and SKILL generally does not handle binary strings
well (specifically, it won't pass NUL characters through).

What platform are you running on? Let me see if I can't get something
written this weekend. There have been more than a few times when I've
needed to get a picture of a schematic into a paper, and it's always
been a bit hairy.
--
David Cuthbert (dacut@cadence.com) Tel: (412) 599-1820
Cadence Design Systems R&D