Import stream file error.

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

 

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.

 

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

 

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

 

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...)

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).

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.

 

I could have sworn that the Cadence documentation mentioned something

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

 

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.

 

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.

 

But you would not want to upset the people you "tape-out" to!
( who ships MAG-TAPE now? )
The Fab's can be picky about the data you send.

You also need to be aware of any glitches in sending the data to the mask
inspection people.
(normally not seen by non-fab people)

- Gerry