My research is focused on solving problems related to visualizing large VLSI datasets. I say large datasets because I think people have done a good job of creating tools to visualize small datasets. For example, a layout editor does a very nice job of displaying information on the screen at high (close in) zoom.
Large datasets are numerous and unvoidable in EDA. Even the canonical form of a design, the HDL description, is large. And it only gets bigger from there. Along each step of the way, the databases get bigger. The structural netlist is bigger than the HDL. The place & route info is larger than that, and the final artwork is the largest of all. This doesn't even begin to consider all the other large datasets that are generated during the design cycle (timing, power, lvs, drc, etc.).
The result of having all these large datasets and no good way to visualize them is that the information goes uninterpreted. Oh sure, people will write perl scripts to get some nuggets of information, but ways of interpreting the entire dataset at once are ad-hoc at best and non-existent at worst. I don't think things need to be this way. I think humans are very good at spacially interpreting patterns of large amounts of information if it's presented in the right way.
The first step I've taken along this road is tackling the always-annoying Layout Redraw Problem. You know, the one where if you hit the wrong button, or you accidently occlude the wrong window, you might as well take a coffee break because the screen isn't going to be refreshed for minutes. EDA companies around the globe have paid homage to this problem by including sure-fire methods of circumventing it: 1) don't draw anything and 2) the graphics interrupt button. Solution 1 involves hiding all detail until explicitly uncovered by the designer and solution 2 gives the designer a button or keystroke that means STOP DRAWING RIGHT NOW!
Let me relabel the above problem as the Layout Redraw and Aliasing Problem. The part that I've added refers the humongous and meaningless glob of stuff that you get after the painful redraw process has completed. It bears little resemblance to anything, and isn't very useful. So I think a useful solution would solve both parts of this problem: fast and accurate drawing. Both are required because solving the first part without the second is easy (see solution 1 above). To summarize, I want a layout viewer that has the following properties:
I started this project in the Fall of 1999 after the millions I was expecting in
funding for sellicethroughthemail.com melted. I just has gotten a
new Ultra60 with Creator3D
graphics and I started playing around with it. I had played (too) many computer
games and simultaneously had had many late nights doing the physical design
backend of the FLASH node
controller. I thought it would be cool to try to use stuff from the former to
make the latter easier.
I currently have a working demo. I modified the Magic Layout Editor and added an OpenGL interface using GLUT.
Besides all the work in computer graphics that has gone into developing texture mapping and mipmapping, the best and most obvious piece of previous work is something called a clipmap. There are two important differences between a clipmap and a ChipMap. The first is that a clipmap requires that the image have been computed everywhere. The second is that a clipmap does not specify exactly how the image is created, which is a fundamental aspect to chipmapping. Clearly, though, the clipmap presents lots of good ideas, some of which I have used.
The ChipMap: Visualizing Large VLSI Physical Design Datasets
Using Texture Mapping with Mipmapping to Render a VLSI Layout
|
|
|
|
|
|
|
| 803×849 | 3,225×3,235 | 12,712×12,712 | 15,575×17,524 | 31,570×27,520 | 100,007×108,571 | 313,216×313,216 |
| (169 KB) | (1.4 MB) | (322 KB) | (683 KB) | (407 KB) | (1.2 MB) | (1.2 MB) |
I wouldn't be where I am today without the incredibly helpful people at Sun. I'd
specifically like to thank John McGuigan for loaning me some very
nice Sun hardware, Levon Mitchell and Peter Denyer for allowing me to demo
my tool in the Sun booth at DAC in 2000 and 2001, and also Ron Bielaski for
entertaining my technical questions regarding all types of Sun hardware and
software issues.
I'd like to thank Stas Polonsky and Michael Rosenfield at IBM Watson for the generous grant to my
advisor which he is using to pay my salary. Also, thanks to Chandu Visweswariah
for arranging the session at DAC that I participated.
Finally, I'd like to thank fellow student Matthew Eldridge for his always helpful suggestions.
For more information, please contact me:
