|
Received 2/9/2006: Dr. Bakos, I came across your link on Abstract Generation. I am currenly working on the same tool. We are using Abstract Generator version IC5141. In this version we don't have "Technology editor" option in file menu. So basically we cannot create .DPUX file. We also never got warning message when we fired up Abstract generator that technology file not found or anything. We have technology file available. We don't know how to set MANUFACTURING GRID. In the verify stage, it does not create NLOCOS layer in the LEF file. Due to that it cannot fire up encounter. If you could give us any advise, that will be really appreciated. Do we need down grade abstract generator as you suggested in your paper? or is there any way we could use the current version we have and get the LEF file for our design? |
|---|
|
Your question is a difficult one to answer because Cadence has royally screwed up the abstract flow and the whole situation is one huge mess. First, some preliminaries. The new Abstract Generator (packaged with IC5141) no longer accepts a tech.dpux file. Instead, it can only import the technology information directly from the Cadence DF-II IC library. However, the real question is: what technology information does Abstract Generator require? Well, aside from the layer definitions, Abstract Generator needs design rules for metal1 and up. This includes width, spacing, and via rules. This is information that used to be contained within a tech.dpux file, and this file is supposed to be shipped as a standard component of your process design kit (PDK). However, aside from the fact that tech.dpux is a binary-encoded proprietary file format, it is not used by ANY CADENCE TOOL EXCEPT the old version of Abstract Generator. And you will probably never find it in any PDK. Unfortunately, the NCSU CDK for the AMI C5N process (which I'm using for my class) DOES NOT include a tech.dpux file, nor does it contain design rule information in the Cadence technology library. The design rules are only provided by the Diva DRC file. This is all incredibly confusing and obfuscated due to the subtle distinctions between the "Cadence technology library" and the "Diva technology file". Both of which are included in a process design kit, but Abstract Generator can only read the design rules from the "Cadence technology library", not the "Diva technology file". This is all STUPID STUPID STUPID, because even if the design rules were included in the Cadence technology library, you would STILL need a Diva technology file in order to run DRC checks, making all of this very redundant. ALSO, of all the commercial PDK's I've ever used for chip design in Cadence (including Peregrine Semiconductor .5um and .25um UTSi, IBM .5um SiGe 5HP, MIT Lincoln Labs .18um FDSOI, TSMC .18um, LSI Logic .18um), NONE of these kits included design rules in the technology library (or a tech.dpux file for that matter). This makes the new Abstract Generator useless. Therefore, the only solution I've found is to use the old Abstract Generator from the DSMSE54 package (only available for Solaris). Also, I recommend installing the latest update for the package. Even if you have this version of Abstract, you still won't have a tech.dpux file. Therefore, you'll need to write your own technology LEF file (by hand) in order to import into Abstract Generator and convert it to to the tech.dpux file. If you'd like, I can send you an example technology LEF file. As far as the MANUFACTURING GRID goes, this also needs to be manually entered into the technology LEF file as it is part of the technology information that Abstract Generator needs. I hope this helps. Please let me know if you have any other questions. -Jason |
|
Dr. Bakos, I don't think my college has older version of Abstract generator that you have mentioned. I talked to Linux guy who sets us everything here regarding to cadence, he told me that they were going to get that version but it turned out to be expensive or somthing so they didn't get it. I would like to ask you a few question about a new version. With the new version, I didn't have to import technology information. I just had to open up the design library I am working on and import the GDS file and LAYERmap file (.map file) . I never imported or there wasn't any option of importing technology LEF file. I would assume that it obtains all technology information from the technology file that is attached to the design library. I also looked at the technology library, but I didn't find any technology LEF file. I just found one file called techfile.cds. So I would assume that it gets all technology information from there. Even though If you could send me a sample Technology LEF file, that will be great. When I used the new version, I could create pin and go though "extract" and "abstract" steps. I was having problem in the "verify step" because the .LEF file Abstract generator creates right before verify step did not have "NLOCOS" layer defined. Can I just ingone "verify" step? Would you say that it will not be possible to use Abstract generator's new version to create LEF file of the design? Would you suggest that I should talk to my advisor to get the older verion? I hope I didn't confuse you. |
|
You're fortunate if your technology library contains the design rules.
You will be able to verify this once you generate the combined
technology/macro LEF file. Assuming this is the case, you will not need
to go back to the earlier version of AbstractGen. Even if you did,
you'd have to write our own technology LEF by hand (and you don't want
to do that!). I don't see a reason why you would need an N diffusion layer defined in the LEF file as it is not a routing layer. Any layer that (1) isn't a routing layer and (2) doesn't present a route obstruct for Encounter should not be included in the LEF file. I would ignore this error, but you should check the output LEF file to make sure there aren't any obvious problems. All you need to do is check the technology information (spacing and via rules), which appears at the beginning of the file before the first "MACRO" line. The LEF file is in an easily-readable text format and isn't complicated. If you did any custom layout in that particular process, you're probably already well familiar with the design rules. Hope this helps! -Jason |
|
Dr. Bakos, Back to the main question. If this is the case, how can I change or add the MANUFACTURING grid? I don't see any option abstract generation. |
|
If you don't have an option in the Abstract Generator to change the
MANUFACTURING GRID, you should just add a line for this to the beginning
of your output LEF file. I'm sending you an example LEF file so you can
see where it fits in. Hope this helps! -Jason |
Dr. Bakos, I looked at the LEF file. That problem has been solved. I was just curious, that if you just change MANUFACTURING GRID in the LEF file doesn't it effect anything else. I thought MANUFACTURING GRID is somthing we have defined when we do layout based on what technology we are working on. Now I am having trouble with verification step. It just gets stuck there after it invokes encounter. I have to kill that to get out of it. Would you have any idea why it would do that? Any suggestion how I can overcome that problem? |
|
The manufacturing grid is related to the fabrication process, although
I'm not entirely sure how. I know that MOSIS forces you to adhere to a
half-lambda manufacturing grid for SCMOS layout files. This may not be
a universal rule, although I'm pretty sure that most processes either
recommend or require a certain manufacturing grid. All of the
commercial PDKs with which I've worked required a certain layout grid.
I've always assumed that this requirement was designed to make mask
generation easier. In Encounter, the routing is drawn on the routing grid, which should be a fairly large multiple of the manufacturing grid (in my tutorial, the routing grid was 4.5u, which is 30 times the half-lambda manufacturing grid). Since the I/O ports of each cell are also on this grid, Encounter should also be placing cells and global I/O pins on this grid as well. If this is the case, then the manufacturing grid wouldn't make much of a difference for Encounter. As for your problem, are you saying that Abstract Generator is invoking Encounter? I wasn't aware that the new version does this. In my experience, I simply had Abstract Generator output a LEF file which is later read into Encounter during design import. Assuming that you're skipping the verification step in Abstract Generator, at what point exactly is Encounter hanging? -Jason |
|
Dr. Bakos, I think now it makes sense to me about manufacturing grid. Basically it is just a value that has to be in LEF file for fabricaton process. Abstract Generator invokes encounter in Verify step. That's where sometimes it cannot verify and sometimes it gets hanged. I suppose to go through verify step, shouldn't I? I know that you have mentioned in your tutorial to skip that. I thought that we might have to go to through that step. |
|
I wonder why Abstract Generator is invoking Encounter. Maybe it's using
Encounter to perform (or aid in) the verification? I'm not sure... I would just generate the LEF file and skip the verify step. Then you can invoke Encounter yourself and have it read in the LEF file. Make sure you look over the LEF file to do a quick sanity-check. -Jason |
|
Dr. Bakos, I will do that, I will just get that LEF file and use it in encounter. If you don't mind I have one more question related to Encounter. Would you by any chance know how to integrate Analog part with digital netlist? I cannot even get analog part into Encounter. I cannot creat cdump file properly that is required to import analog LEF and GDS file into encounter. I created LEF file. I was just making sure that LEF file has all pin information. But apperently it didn't have that. I looked at the abstract log file. It says that "no underlying geometry found for the label, so no pin can be created? I wonder is that how it gets all pin information just from geometry? |
|
The pins are supposed to be compiled during the "pin step" of Abstract
Generator. It does this by finding the pins in the layout. Make sure
you're using pins (not labels) in your layout. Also, make sure the pins
have the correct layer associated with them (must be metal layers).
Finally, make sure the pins are located on the routing grid. As for getting analog cells into Encounter, I have never done this. But I would assume that if you can get Abstract Generator to generate macros for the analog components, and you have these components instantiated and wired up in a the Verilog netlist (which is the hard part, since the synthesizer won't do this), then Encounter shouldn't have a problem with placing and routing them. In other words, Abstract Generator shouldn't have a problem with non-digital cells. You just can't characterize them with SignalStorm, and you can't use them for logic synthesis. Basically, you will have to manually wire up your analog cells in the Verilog netlist in order for this to work (bolt them into the digital portion of your design). However, I don't see any problem with generating abstracts/macros for these layouts, since Abstract Generator doesn't care if the layouts are digital or not. For example, I generated an abstract for a "filler cell" and transmission gate, and neither of which generate a logical (digital) function. -Jason |
|
Dr. Bakos, I will try what you have suggested. I will let you know if it works. Thanks for all your help. I really appreciate that. I will keep in touch. |