layout to svg

R

Roger Light

Guest
Hi,

I've been experimenting with ways of getting nice pictures of layouts
recently. My first attempt was to create a new display type "solid"
where all of the layers were made of solid colour rather than a pattern.
It worked nicely, but suffered because of the order of the layers - MET2
would obscure VIA1 for example and N/PPLUS would obscure DIFF.

So anyway, I've built up some skill code that runs on a layout cell view
and produces an SVG file of the visible layers which you can then open
in inkscape, the gimp or anything else that supports it. The results
look pretty good in my opinion.

Before you use it you need to create two files which tell the code which
layers to consider and which order they should appear in as well as
how they should appear. So in my case, I use top metal to cover lots of
circuitry, so I can make it slightly transparent so I can see what's
going on underneath (or I could make it non-visible in the LSW and it
wouldn't appear at all).

If you want to give it a try, you'll also have to edit the code slightly
to point it at where you have the files and where to dump the output.

One caveat - it leaves behind a library (by default this is layout2svg)
which it uses as a temporary library. Creating a library and then
deleting it again for each operation means your cds.lib would fill up
with multiple entries about the deletion, which is a bit impolite. It's
safe to delete the temporary library, or search for FIXME in the code
and enable the deletion if you're happy that it will produce excess
lines in your cds.lib.

It turned out quite large in the end and I'm a bit reluctant to post a
19k file here directly (especially after all that waffle), so I've put
it on the web at http://atchoo.org/tools/cadence/svg.il

Hope you find it useful - but don't expect it to work on large designs!

Cheers,

Roger
 
Hello Roger,

That's a nice idea I think. Nice code, too.

I understand now your need for the scratch library. I see you have made this choice of keeping the
hierarchy, but yourself state that it causes problems because instances appear below the layer from
the root cell regardless of their z-order.

So I wonder, have you considered copying the root cell to a scratch cellview, then flattening
*everything* down to level 32, then merging all shapes together. That would fix the z-order problem
as well as the need for a scratch library, tough it would probably result in a larger .svg file and
longer run time !

Also, I believe that the layer order could be read from the technology data, unless you have a
particular reason of wanting it to be overriden by the user.


Anyway, lots of thanks for sharing this code with us. When I have time, I'll give it a try to see
for myself.

Stéphane
 
Hi StĂŠphane,

That's a nice idea I think. Nice code, too.
Thanks.

I understand now your need for the scratch library. I see you have made
this choice of keeping the hierarchy, but yourself state that it causes
problems because instances appear below the layer from the root cell
regardless of their z-order.

So I wonder, have you considered copying the root cell to a scratch
cellview, then flattening *everything* down to level 32, then merging all
shapes together. That would fix the z-order problem as well as the need
for a scratch library, tough it would probably result in a larger .svg
file and longer run time !
You're absolutely right, this would solve the z-order problem and produce a
larger file. It would make the code much simpler as well, not having to
deal with mirrored and rotated instances... I decided to do it this way so
that you have the option of doing it both ways. If a bit of problem with
z-order doesn't matter to you then you get a smaller file, but if it is
important then you can go ahead and flatten a copy of your own layout
anyway.

Also, I believe that the layer order could be read from the technology
data, unless you have a particular reason of wanting it to be overriden by
the user.
I do want it to be overridden by the user. The technology data normally
defines metal like this:

MET2
VIA1
MET1

whereas I want

VIA1
MET2
MET1

so that I can see the vias rather than them being covered with MET2. Having
the layers in the correct order works if your metal layers aren't
completely solid which is why it is ok to do that in virtuoso.

Cheers,

Roger
 
One possible problem with flattening the hierarchy is the text. In the
pcells in our PDK the instance name text is a paramaterized label
[@instanceName] so when it is flattened it changes back from EX: M1
back to [@instanceName].

If you don't care about text it should be fine.

Tim
 
Tim wrote:

One possible problem with flattening the hierarchy is the text. In the
pcells in our PDK the instance name text is a paramaterized label
[@instanceName] so when it is flattened it changes back from EX: M1
back to [@instanceName].
Ah, I've not come across that in a layout before. Unfortunately for you, my
code does flatten all pcells and mosaics by one level until there are none
left (hence the need for the temporary library) as that's a much easier
solution than trying to figure out whether two pcell instances are
identical and then assigning unique names.

Cheers,

Roger
 
On Mar 28, 7:21 pm, Roger Light
<roger.li...@DOESNTLIKESPAMnottingham.ac.uk> wrote:
Hi,

I've been experimenting with ways of getting nice pictures of layouts
recently. My first attempt was to create a new display type "solid"
where all of the layers were made of solid colour rather than a pattern.
It worked nicely, but suffered because of the order of the layers - MET2
would obscure VIA1 for example and N/PPLUS would obscure DIFF.

So anyway, I've built up some skill code that runs on a layout cell view
and produces an SVG file of the visible layers which you can then open
in inkscape, the gimp or anything else that supports it. The results
look pretty good in my opinion.

Before you use it you need to create two files which tell the code which
layers to consider and which order they should appear in as well as
how they should appear. So in my case, I use top metal to cover lots of
circuitry, so I can make it slightly transparent so I can see what's
going on underneath (or I could make it non-visible in the LSW and it
wouldn't appear at all).

If you want to give it a try, you'll also have to edit the code slightly
to point it at where you have the files and where to dump the output.

One caveat - it leaves behind a library (by default this is layout2svg)
which it uses as a temporary library. Creating a library and then
deleting it again for each operation means your cds.lib would fill up
with multiple entries about the deletion, which is a bit impolite. It's
safe to delete the temporary library, or search for FIXME in the code
and enable the deletion if you're happy that it will produce excess
lines in your cds.lib.

It turned out quite large in the end and I'm a bit reluctant to post a
19k file here directly (especially after all that waffle), so I've put
it on the web athttp://atchoo.org/tools/cadence/svg.il

Hope you find it useful - but don't expect it to work on large designs!

Cheers,

Roger

Very excited about this. I'm not sure how you are rendering these
but, I am not getting colour. I've reduce a file to a pretty simple
case.
this renders in black for me. This is more of an SVG issue I guess.


<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="190.5px" height="392px" viewBox="0 0 190.5 392"
xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://
www.w3.org/1999/xlink">
<title>layout2svg - ESD_c - layout</title><desc></desc>
<defs>
<style>
..MET4drawing { fill: #990006; opacity: 0.075; }
</style>
</defs>
<polygon class="MET4drawing" points="0.65,118.9 89.85,118.9
89.85,87.75 0.65,87.75 0.65,118.9"/>
</svg>

Thanks
 
Hi noopster,

Very excited about this. I'm not sure how you are rendering these
but, I am not getting colour. I've reduce a file to a pretty simple
case.
this renders in black for me. This is more of an SVG issue I guess.


?xml version="1.0" standalone="no"?
!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"
svg width="190.5px" height="392px" viewBox="0 0 190.5 392"
xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://
www.w3.org/1999/xlink"
title>layout2svg - ESD_c - layout</title><desc></desc
defs
style
.MET4drawing { fill: #990006; opacity: 0.075; }
/style
/defs
polygon class="MET4drawing" points="0.65,118.9 89.85,118.9
89.85,87.75 0.65,87.75 0.65,118.9"/
/svg
What are you using to display the svg file? I've tried the above and get a
pastel pink in both inkscape and gimp but black if I use convert from
imagemagick.

Thanks,

Roger
 
On Apr 9, 8:56 am, Roger Light
<roger.li...@DOESNTLIKESPAMnottingham.ac.uk> wrote:
Hi noopster,



Very excited about this. I'm not sure how you are rendering these
but, I am not getting colour. I've reduce a file to a pretty simple
case.
this renders in black for me. This is more of an SVG issue I guess.

?xml version="1.0" standalone="no"?
!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/
Graphics/SVG/1.1/DTD/svg11.dtd"
svg width="190.5px" height="392px" viewBox="0 0 190.5 392"
xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://
www.w3.org/1999/xlink"
title>layout2svg - ESD_c - layout</title><desc></desc
defs
style
.MET4drawing { fill: #990006; opacity: 0.075; }
/style
/defs
polygon class="MET4drawing" points="0.65,118.9 89.85,118.9
89.85,87.75 0.65,87.75 0.65,118.9"/
/svg

What are you using to display the svg file? I've tried the above and get a
pastel pink in both inkscape and gimp but black if I use convert from
imagemagick.

Thanks,

Roger
I was loading it up with firefox/mozilla with the built in SVG
capability. I also tries the Adobe
plugin as well. Both rendered black. I'll give GIMP and/or inkscape
a try.
 

Welcome to EDABoard.com

Sponsor

Back
Top