Stats

  • Locked Locked
  • Replies 8
  • Subscribers 144
  • Views 15488
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Searching for the best way to rasterize layout data, i.e. generate a bitmap

caver456

We would like to generate a single-bit ('black-and-white') raster / bitmap from a certain cell in Virtuoso Layout for each of a set of layers.

The cell size / grid size / pixel size for us would be 2.625 x 2.625 microns, but that may change.  We would generate the raster over some area of our top level layout, so, we're looking at potentially low thousands of pixels in each dimension.

Criteria would probably be simple; maybe as simple as "if that cell contains any (>0%) of the layer in question, the pixel value will be 1, otherwise it will be 0".

We would like to create a separate raster for metal1, a raster for via1, a raster for metal2, a raster for via2, and a raster for metal3... the point being, we have a small fixed set of layers and we'd like one raster per layer.

SKILL might not be the best fit... maybe Diva or Dracula or Assura or Calibre, or an external program looking directly at the GDS data?  An idea or solution in SKILL or any one of those other tools would be very helpful.  This forum seemed like the best venue for the question

  • to clarify, the starting point is a Virtuoso layout cell; the desired output is a set of raster files (or actually csv files like "1,0,0,0,1,1,0,0,1,.....")

  • I've had success exporting top-level captures of selected layers to .png files using the SKILL function hiExportImage. You are able to specify a specific coordinate region so it should work for what you're trying to accomplish.

  • Thanks, that looks like an excellent lead. Cadence has a very large list of functions and a lot of the time you only hear about the ones you need by word of mouth!

    I tried it out on one layer by setting metal1 to the only visible layer, then doing hiExportImage(?fileName "a.png" ?bBox enterBox() ?scaleFactor 0.380952381 ?colorType 'biColor ?fgColor "white" ?bgColor "black") (note the scalefactor above is 1/2.625 with 2.625u x 2.625u being our desired pixel size; the docs don't exactly spell out what the numerator units and denominator units are for the scalefactor (pixels per micron? pixels per manufacturing grid?) but it will be easy to find out by trial and error. The png looks good (the bmp had some interesting artifacts) but I haven't really checked if for accuracy yet, especially pixel/row/column shifting due to scale rounding issues.

    Writing a bit of skill wrapper code (i.e. set the layers in question to have a solid fill pattern; turning off grids which it looks like you could do from within the hiExportImage function if needed; iteratively setting the layer in question to be the only visible layer then calling this function; setting the display back to normal when done).

    Anyway, thanks for the great lead, I will be trying this out more as time allows and will post back here if/when we get a good solution to actually build the desired csv files. Still - any additional leads, other options, more details would be great.

  • My first question would really be "why?". This seems an odd thing to want to do...

    Anyway, out of interest, I was assuming that you might want to having something potentially more accurate, so was looking at using the "abe" functions (Advanced Boolean Engine) that have been added in IC617 (I'd recommend a recent ISR if  you're going to go down this route). I was experimenting with various tradeoffs, but it seems to get stuck slightly at times - I've not done any real profiling yet as this was an experiment. I suspect it's some kind of garbage-collection issue (when I have a chance, I'll investigate further - but I'd sooner know why you want this!)

    I was going to post the code now, but I've definitely narrowed it down to being a garbage collection problem - I'm not sure what I can do about it currently because even when disabling garbage collection altogether, it runs fairly quickly with 2500 x 1000 pixels - but then a single gc() call at the end takes a very long time (and a huge amount of memory has been allocated). I'll need to work with R&D to understand why this is happening.

    To be fair, it's probably not quite what the boolean engine functions were intended for; I'm essentially doing an AND in each pixel area to see if there are any shapes.

    Regards,

    Andrew.

  • We do use the abe functions for some other tasks not related to this one. They work great on small data; it's interesting to hear of the stumbling points on larger data. The bigger limitation of the abe functions that we've run across is the fact that they operate on fractured tiles, which can lead to unexpected results for certain drawn shapes. The results make sense when you re-read the description of the tiling. Sounds like an AND in each area would likely be immune to unexpected tile-related behavior?
    Anyway, the goal is basically to feed a layout representation into an external spreadsheet program that does a whole truckload of number crunching. Maybe there's a different way to accomplish that entire end goal? Probably writing something in C to chug directly on the gds or oa data would be 'optimal' but for the scope of this question I'm treating the spreadsheet task as a black box that needs its csv 'bitmap' per layer. However if you've got any ideas for how to work the entire task more intelligently that would be great.

  • I don't think the tiles would have any impact here - in fact all I'm doing is seeing if the numTiles>0 for the result of any AND; I try to avoid creating new layers each time, but it's actually generating a lot of list cells - more than I would have expected - plus a lot of abeLayer objects. Anyway, that's something for me to look into when I have a moment (moments are in short supply at the moment, unfortunately!)

    I still don't really see what the use analysing a rasterised representation of a layer would provide - if you were trying to check density, then physical verification tools can do that better. If I had a better idea of the end goal, then perhaps I might be able to suggest alternatives? Put another way, what are you doing with the results (other than "processing in Excel" - why would you do this? What does it tell you?)

    Andrew.

  • The tiles probably aren't an issue here as I just use ->numTiles to determine whether there are any shapes at all in the result of each pixel And.

    I still don't see what this is actually telling  you. Yes, you're doing Excel number crunching, but why? What's the objective of this processing? If it's for density estimation, then physical verification tools would do that better. If for something else, I might be able to suggest a better option.

    Regards,

    Andrew.

  • I can't really provide any more detail, since it's proprietary. I'm not the lead on the scheme, I'm just the guy who happens to know some skill and other languages, tasked with figuring out if we can generate the per-layer csv rasters.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.