A post about GDS file format spec is posted on comp.lsi.cad

A post about GDS file format spec is posted on comp.lsi.cad

Post by Kuhl » Mon, 13 Apr 2009 03:35:58


Hi, all: I have just post a question about GDS format spec on
comp.lsi.cad . But I found that there are very few people on that
group. To promote the possibility of this question getting answered, I
give a message here. Would anyone have a look? Thank you in advance.
 
 
 

A post about GDS file format spec is posted on comp.lsi.cad

Post by Riad KACE » Tue, 14 Apr 2009 22:59:16

Hi Kuhl,

It would have been easier if you'd given the link to your post. This
would have saved me couple of minutes hunting your question :-)
Anyway, here is the link in question:

http://www.yqcomputer.com/ #

I don't really know the answer to your question. I have a www link
that might help you though :
http://www.yqcomputer.com/

The first 2 items in the 'See also' section are dealing with the GDS
format:

* Computer Aids for VLSI Design - Appendix C: GDS II Format by Steven
M. Rubin
* The GDSII Stream Format by Jim Buchanan
* List of various layout editors/viewers

The latter is a useful link to open-source programs related to reading/
viewing GDSII files. You might be interested comparing your script
against those already on the market. I usually go for the re-use
option myself, I don't want to reinvent the wheel :-)

Hope this is helping you,
Regards,
Riad.

 
 
 

A post about GDS file format spec is posted on comp.lsi.cad

Post by Andrew Bec » Thu, 16 Apr 2009 19:39:24

Riad KACED wrote, on 04/13/09 14:59:

There are two optional records, ELFLAGS and PLEX which come between the element
type (e.g. BOUNDARY, PATH, TEXT etc) and LAYER record.

This is covered in <ICinstDir>/doc/transref/transref.pdf (Appendix A).

I'm not aware of any recent tools using these records - they were used by some
rather old Calma tools, if my memory is correct.

In general I've always tended to write programs that read stream file by having
a big case statement for each of the record types I'm interested in, and then
just ignoring the ones that I'm not - and then effectively use a sort of state
machine to keep track of which element type (or other) that you're currently in,
so that when you get to the ENDEL record you have collected all the info you
need. That way you don't need to build anything that assumes that one record
will immediately follow another.

Regards,

Andrew.