cell libraries and place and route

On Wed, 11 May 2005 01:51:47 -0700, hsphuah wrote:

I encounter a problem when I import my gdsii stream file which I
generated my own program. The import stream file gives me this error
message:

FATAL (149): Bad Stream record type `112' encountered in the input
Stream file. Valid range is `0-59'.

What is the record type "112"? I cannot find the code in gdsii code on
the Internet.

For your information, the gdsii format is copying the same format as
Cadence export gdsii stream file. The only different is my generated
size is less than 182 bytes but cadence generated gdsii file has 2048
bytes. I had wrote a simple program to dump the binary file, it
contains many zero at the end of 400.

HS Phuah
There is a good GDSII spec online at:
http://www.xs4all.nl/~kholwerd/interface/bnf/gdsformat.html

Note that there is no record type 112, so your file is likely invalid
GDSII. Perhaps you forgot to swap some bytes? GDSII files use a byte
ordering that is the opposite of most systems (including X86 processors).
If you want to send me the file, you can send it to my email address
without the _REMOVE_THIS_ and I can decode the records and tell you what's
wrong.

Frank
 
On Wed, 11 May 2005 10:59:58 +0200, Guenther Sohler wrote:

Hallo

* gds file sizes must always be multiples of 2048 bytes. Always pad with
'0's to make file file size a multible of 2048 bytes.

* maybe you swapped decimal and hex presentation of the code for the
stream record. Which stream record did you want to put to the file ?

The format of a record is
Total byte len of record> as 2 Bigendian Bytes
Record type > as one byte
Data type> as one byte
Total byte len-4 bytes of data

When you send me your gds file, I can probably tell you the error.

I've never heard of a multiple of 2048 restriction on GDSII file sizes,
and I would be surprised if any real software required that. Maybe that
was part of the spec many years ago, but I have plenty of GDSII files that
are not multiples of 2048 in size and work just fine in several CAD tools
that read GDSII. Can you point me to a GDSII spec that mentions the size
restriction? Is this a Cadence restriction?

Some programs do pad the GDSII file with zeros to make it a "nice" size.
It certainly can make reading the file faster if the reader uses an
internal 2048 buffer to read the file by blocks. I think it's valid to
have anything after the ENDLIB record since most programs stop reading
after they encounter the end of the library.

Frank
 
Normally, you will have some kind of isolation of the digital and analog
substrate regions. I have seen this done with a double row of substrate
ties with a very low resistance path to the ground pad. This forms a
noise barrier, of a sort.

Given some barrier, you can geometrically separate the analog substrate
region from the digital substrate region during extraction. This lets
LVS see both gnd! and gnda! as separate nets in the layout and the
schematic. It has the added benefit of letting LVS validate that the
digital and analog devices are not connected to the wrong substrate
regions.

On 11 May 2005 03:31:20 -0700, reubenwilcock@hotmail.com wrote:

Hi all,

I am using a flow which includes Diva LVS, but because my layouts and
schematics use different grounds (gnd! and gnda!) the LVS gets upset
about the substrate being connected to different nets. I have to create
a special LVS version of my schematic and layout and ensure that there
is only one net connected to the substrate (i.e. either gnd! or gnda!).
This is a pain to do and it would be great if I could write a script to
search the extracted view (is it just a netlist?) and replace any
occurrences of gnda! with gnd!. I would also like to be able to do this
with the schematic, but I guess it would have to be easy to change it
back after the LVS...

Any ideas or suggestions welcome.

Also did anyone ever manage to get remote simulation in analog artist
working on a machine which requires a username/password? I need some
way of auto signing into the machine without requiring a password - I
can do this with ssh but I think the remote simulation uses rsh?

Cheers,

Reuben
 
On Wed, 11 May 2005 19:42:56 -0700, hsphuah wrote:

Hi all,

Does CalTech Interchange Format (CIF) has BNF on the Internet? If so,
could someone give me the link, please? Thanks.

HS Phuah

You're working with CIF as well as GDSII? There are many websites with
info on both CIF and GDSII, such as:
http://www.wrcad.com/manual/xicmanual/node476.html
http://www.rulabinsky.com/cavd/text/chapb.html

I can't find a site with BNF for CIF at the moment. I
think CIF actually stands for "CalTech Intermediate Format", so you
might have an easier time Google searching with that term. CIF is a little
tricky since there are many optional parameters, custom languange
extensions, etc. For example, you can have an entire layout in a CIf
text file with no newlines or whitespace and only refer to the commands
by their first letters (if unique). It's less well-defined than GDSII,
though easier to work with since it's text.

Frank
 
Frank E. Gennari wrote:
I've never heard of a multiple of 2048 restriction on GDSII file sizes,
and I would be surprised if any real software required that.
GDSII, at least once upon a time, required files to be multiples of some
pad (2048 seems a bit large, but not implausible) for the simple reason
that tape files had to be multiples of a blocksize. Heck, GDSII still
has record types 50 and 51, TAPENUM and TAPECODE, so you can be sure
that you've loaded the correct tape onto the photoplotter driver.

The reason 2048 isn't sounding right to me is because dd defaults to 512
byte blocks, the most common block size for tapes and disks. (At
Seagate, the channels people were trying to get this increased to 4k or
8k to take advantage of better coding schemes... I'm not sure if they
ever succeeded or put some kind of emulation in there or what...)

Maybe that
was part of the spec many years ago, but I have plenty of GDSII files that
are not multiples of 2048 in size and work just fine in several CAD tools
that read GDSII. Can you point me to a GDSII spec that mentions the size
restriction? Is this a Cadence restriction?
I could have sworn that the Cadence documentation mentioned something
about this (Design Data Translator's Reference, appendix A), but I don't
see anything in the IC 5.1.41 version of the manual. I'll see if I
can't dig out an earlier version (I first started messing with GDSII
around 4.4, IIRC).

I think it's valid to
have anything after the ENDLIB record since most programs stop reading
after they encounter the end of the library.
Well, just to be nice, I'd recommend stopping at the ENDLIB or adding
zero pads when writing GDSII, and ignoring anything beyond the ENDLIB
when reading it.

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
G Vandevalk wrote:
My personal solution is to model connections to the substrate ( i.e. P+
diffusion in the P-Sub ) as a small (>1ohm) resistor. This device is
something I require in the schematic when a cct has a substrate
contact.
Out of curiosity, how well does this hold up for silicon-on-insulator
processes? I've never done anything with an SoI process, but the whole
"little islands of floating bulks" issue has perplexed me as to how
anyone is able to make reasonable designs with it...

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
hsphuah@usa.com wrote:
Does CalTech Interchange Format (CIF) has BNF on the Internet? If so,
could someone give me the link, please? Thanks.
I was able to find the following:
http://www.ee.vt.edu/~ee5545jg/ee5545e/sld004.htm

Otherwise, I'd imagine it's documented in Mead & Conway; see if a
coworker/professor who has been around awhile has a copy.

If I may ask, what's the interest in CIF? I haven't played with it
since I used the Chipmunk tools and LEdit back at Caltech. (Though, by
the time I got there, the actual Chipmunk cluster was long gone, and we
were running on 300s or 400s...)

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
I could have sworn that the Cadence documentation mentioned something
about this (Design Data Translator's Reference, appendix A), but I don't
see anything in the IC 5.1.41 version of the manual. I'll see if I
can't dig out an earlier version (I first started messing with GDSII
around 4.4, IIRC).
the 5.0.33 version states :

If the Stream file is on a magnetic tape, the records of the library are
usually divided in 2048-byte physical blocks

stéphane
 
Wow, gee !
What a lucky chap you are !
I am happy for you.
How on earth didthis coincidence happen that you found this tool ?

Heidi wrote:
Hey guys, I just found a netlist trace and ECO tool, which looks
perfect for me. It allows users draw and isolate gates in schematics by
just clicking on gate pins. Starting from one cell user has interest
in, after several mouse clicking and moving, one circuit appears. Users
can move, replace, delete or add gates in the schematics, and can also
drag and drop gates from codeview window. By using this tool, debugging
is not a problem anymore. And the best thing is, you can try it for
free!! Go and take a look

http://www.necosys.com/
 
The SOI technologies are, of course, required to have ties to each local
sub-well.



"David Cuthbert" <dacut@kanga.erasethis.org> wrote in message
news:Uq2dnQG-b63oTh_fRVn-pw@comcast.com...
G Vandevalk wrote:
My personal solution is to model connections to the substrate ( i.e. P+
diffusion in the P-Sub ) as a small (>1ohm) resistor. This device is
something I require in the schematic when a cct has a substrate
contact.

Out of curiosity, how well does this hold up for silicon-on-insulator
processes? I've never done anything with an SoI process, but the whole
"little islands of floating bulks" issue has perplexed me as to how
anyone is able to make reasonable designs with it...

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
G Vandevalk wrote:
The SOI technologies are, of course, required to have ties to each local
sub-well.
Right. My question was more along the lines of simulation modeling.
Saying that each analog well is tied to a nice, common gnda! is, and
always has been, a lie (and why we have tools like Substrate Storm to
guess just bad the lie is). Is it one that we can still get away with
in SoI?

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
hsphuah@usa.com wrote:
I am requested to write a program to convert GDSII to CIF and vice
versa for layout automation software. That's why I am looking for CIF
BNF.
This is a solved problem. Is there a reason why pipo doesn't work for
you? Pull up the .../tools/doc/transref/transref.pdf documentation in
Acrobat for information on this.

If you're doing this as a learning exercise, that's great. But if it's
to write a competing tool, we can't exactly help you in this regard. :)

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
"David" == David Cuthbert <"dacut at cadence dot com"> writes:
David> Date: Thu, 12 May 2005 09:43:06 -0400

David> G Vandevalk wrote:
The SOI technologies are, of course, required to have ties to
each local sub-well.
David> Right. My question was more along the lines of simulation
David> modeling. Saying that each analog well is tied to a nice,
David> common gnda! is, and always has been, a lie (and why we
David> have tools like Substrate Storm to guess just bad the lie
David> is). Is it one that we can still get away with in SoI?

Good question. I think most people are saying, well the common
substrate was a myth anyway. Now we error is a little bigger, big deal!
BSIM3SOI is supposed to be more accurate for SOI processes.

I have worked only on mostly bipolar SOI process. The 3 terminal GP
model suddenly is more accurate in SOI process. The 4 terminal
VBIC model (which was originally invented for better modeling of
BJTs) tries to figure out the collector-substrate diode. To make
matters worse, some of the libraries have a common substrate node for
VBIC on SOI. Go figure!

Satya

--
Remove XXX and YYY to get my address
 
hsphuah@usa.com wrote:
Does CalTech Interchange Format (CIF) has BNF on the Internet? If so,
could someone give me the link, please? Thanks.
Ok, I managed to track down a copy of Mead & Conway (which is out of
print). I'm reproducing the CIF 2.0 grammar found on pages 116-117 here
(and translating it to BNF on the fly) in the hopes that it becomes part
of Google's collective memory.

cifFile ::= (blank* command? semi)* endCommand blank*
command ::= primCommand | defDeleteCommand |
defStartCommand semi (blank* primCommand? semi)* defFinishCommand
primCommand ::= polygonCommand | boxCommand | roundFlashCommand |
wireCommand | layerCommand | callCommand | userExtensionCommand |
commentCommand
polygonCommand ::= "P" path
boxCommand ::= "B" integer sep integer sep point (sep point)?
roundFlashCommand ::= "R" integer sep point
wireCommand ::= "W" integer sep path
layerCommand ::= "L" blank* shortname
defStartCommand ::= "D" blank* "S" integer (sep integer sep integer)?
defFinishCommand ::= "D" blank* "F"
defDeleteCommand ::= "D" blank* "D" integer
callCommand ::= "C" integer transformation
userExtensionCommand ::= digit userText
commentCommand ::= "(" commentText ")"
endCommand ::= "E"
transformation ::= (blank* ("T" point |
"M" blank* "X" |
"M" blank* "Y" |
"R" point)*)*
path ::= point (sep point)*
point ::= sInteger sep sInteger
sInteger ::= sep* "-"? integerD
integer ::= sep* integerD
integerD ::= digit+
shortname ::= c c? c? c?
c ::= digit | upperChar
userText ::= userChar*
commentText ::= commentChar* |
commentText "(" commentText ")" commentText
semi ::= blank* ";" blank*
sep ::= upperChar | blank
digit ::= "0" | "1" | ... | "9"
upperChar ::= "A" | "B" | ... | "Z"
blank ::= any ASCII character except digit, upperChar, "-", "(", ")",
or ";"
userChar ::= any ASCII character except ";"
commentChar ::= any ASCII character except "(" or ")"

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
On Thu, 12 May 2005 09:55:03 +0200, S. Badel wrote:

I could have sworn that the Cadence documentation mentioned something
about this (Design Data Translator's Reference, appendix A), but I don't
see anything in the IC 5.1.41 version of the manual. I'll see if I
can't dig out an earlier version (I first started messing with GDSII
around 4.4, IIRC).

the 5.0.33 version states :

If the Stream file is on a magnetic tape, the records of the library are
usually divided in 2048-byte physical blocks

stéphane
Yes, GDSII on tape used to require 2048-byte blocks, but does anyone still
use tapes? Can Cadence read GDSII files that are not multiples of 2048? I
don't see why not.

Frank
 
S. Badel wrote:
the 5.0.33 version states :

If the Stream file is on a magnetic tape, the records of the library are
usually divided in 2048-byte physical blocks
Ah, ok. Yes, this is the relevant bit I was thinking of (and is still
present in 5.1.41). The text states:

-----
If the Stream file is on a magnetic tape, the records of the library are
usually divided in 2048- byte physical blocks. Records can overlap
physical block boundaries; a record is not required to be wholly
contained in a single physical block.

Two consecutive zero bytes are a null word. You can use null words to
fill the space between the last record of a library and the end of its
physical block.

Stream records are always an even number of bytes. If a record contains
ASCII string data and the ASCII string is an odd number of bytes, the
last character is a null character.
-----

The way I read this is: be prepared to encounter NULL records after the
ENDLIB when reading a stream file; they are not required when writing.

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
On Wed, 11 May 2005 23:43:55 -0700, hsphuah wrote:

I am requested to write a program to convert GDSII to CIF and vice
versa for layout automation software. That's why I am looking for CIF
BNF.

HS Phuah

That's quite a project if you plan to support the complete CIF/GDSII
formats. Some of the shapes in one format can't easily be represented in
the other (round flashes in GDSII?). If you want a reliable converter that
others will be using then you probably want to look for a cheap/free
conversion tool, or use Cadence. What is the intended use of your tool?
What sort of design flow involves both CIF and GDSII?

Frank
 
Frank E. Gennari wrote:
Yes, GDSII on tape used to require 2048-byte blocks, but does anyone still
use tapes? Can Cadence read GDSII files that are not multiples of 2048? I
don't see why not.
Cadence certainly can handle non-blocked GDSII files. pipo might write
out blocked files just to be nice to legacy tools (not sure about this
-- I'm at home without VPN access at the moment). NeoCell's GDSII
writer (which is what I'm familiar with) does this.

As for tapes... well, there are still a few movies I have on VHS that
haven't gone over to DVD yet. :) But otherwise, nope.

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
Hi,

f_grid = techGetMfgGridResolution( techGetTechFile( ddGetObj( t_libName ) ) )

where 't_libName' is your technology library name;

returns the mfgGridResolution value form your tech library technology file
which should probably be the right manufacturing gird.

Use the value to calculate your power grid.

Bernd

wrote:
Hi everyone,
I wrote some skill code to generate a custom power-grid. The grid
appears fine but when I run DRC on it, it gives me errors stating "Edge
not on grid". I think that it may be because the dimensions I compute
in the skill code are not multiples of the manufactuing grid
resoultion. Is there any simple way to fix these errors?

Any comments would be appreciated.

Saby.
 
David Cuthbert wrote:

hsphuah@usa.com wrote:

I am requested to write a program to convert GDSII to CIF and vice
versa for layout automation software. That's why I am looking for CIF
BNF.


This is a solved problem. Is there a reason why pipo doesn't work for
you? Pull up the .../tools/doc/transref/transref.pdf documentation in
Acrobat for information on this.

If you're doing this as a learning exercise, that's great. But if it's
to write a competing tool, we can't exactly help you in this regard. :)

No,
He can better try to team up with Sagantec instead. They make intensive use of
CIF.
 

Welcome to EDABoard.com

Sponsor

Back
Top