For LEF based LVS, I strongly suggest making sure that the ports match at each hierarchy. Currently, your log shows:

Subcircuit pins:
Circuit 1: bitfour_EESPFAL                 |Circuit 2: bitfour_EESPFAL                 
-------------------------------------------|-------------------------------------------
GND                                        |GND                                        
k[0]                                       |k[0]                                       
k[1]                                       |k[1]                                       
k[2]                                       |k[2]                                       
k[3]                                       |k[3]                                       
k_bar[0]                                   |k_bar[0]                                   
k_bar[1]                                   |k_bar[1]                                   
k_bar[2]                                   |k_bar[2]                                   
k_bar[3]                                   |k_bar[3]                                   
x[0]                                       |x[0]                                       
x[1]                                       |x[1]                                       
x[2]                                       |x[2]                                       
x[3]                                       |x[3]                                       
x_bar[0]                                   |x_bar[0]                                   
x_bar[1]                                   |x_bar[1]                                   
x_bar[2]                                   |x_bar[2]                                   
x_bar[3]                                   |x_bar[3]                                   
VDD                                        |VDD                                        
Dis0                                       |(no matching pin)                          
CLK0                                       |(no matching pin)                          
CLK1                                       |(no matching pin)                          
Dis1                                       |(no matching pin)                          
CLK3                                       |(no matching pin)                          
Dis2                                       |(no matching pin)                          
CLK2                                       |(no matching pin)                          
Dis3                                       |(no matching pin)

The verilog is probably defined as

input wire [BIT_SIZE-1:0] CLK,
    input wire [BIT_SIZE-1:0] Dis,

which I believe expands to

CLK[3], CLK[2], …, Dis[3], …

etc. How are you creating the LEF file? It seems to have much more information than say this file for a larger macro.

I'm creating the LEF file via magic. Had magic read the GDS file from klayout, perform

lef write bitfour_EEPFAL -tech

. I also had magic write the GDS file, which is used as part of the macro. When you say each hierarchy, do I have to go down to the most basic cell(EESPFAL_NAND_V3, etc.), or just the top cell(bitfour_EESPFAL) pins wrapping them together in the layout?

Just for the cells that show up in the LVS report. In the log file you shared, the only circuit with

no matching pins

error was

bitfour_EESPFAL

. @Tim Edwards is there a way to create a more succinct LEF file with magic? Something like the lef created by open lane for macros?

Gotcha, I updated the CLK pins and removed duplicates. At this point, the lvs mismatch with VDD, does it have to do with the config file?

I don’t think so. I was thinking of suggesting adding power rail ports on metal3 instead of metal1, but it might not make a difference.

@Mitch Bailey: Use `lef -hide`; see the documentation on the

lef

command for additional options. Usually there should be some set of options that gets the result you want for a useful abstract view.

I've moved the port label pins up to M3 and it did not make a difference. @Tim Edwards Hi Tim, what does lef -hide 's distance starting from center to the corners or its something like the following graphic? I've tried 1 lambda and 25um where the former seems to hide everything, the latter doesn't hide anything.

@JC: The best way to ensure that it's easy to automate the process of creating the LEF view and using it in place & route is to make sure that every pin touches the outer boundary of the macro (and that the macro has a place & route boundary defined by the "prBoundary" layer). The rules for "-hide" are (1) block out each pin and provide a space around the pin, then (2) find the minimum bounding box of all geometry of each metal layer not including the pins, and create an obstruction layer of that size, avoiding the pins and the keep-out area around the pins.

Just to check, I've lvs the bitfour_EESPFAL's with the xschem schematic and it shows that its clear... To be clear, is the image below accurately depict what I should be doing?

The pins look reasonable, although be aware that if the pins are spaced closely together and are not aligned with the route pitch that the router is using to make connections to the macro, then it could fail routing because it is not able to reach a pin even though the pin is on (or outside of) the boundary. I don't think that the boundary will cause any problem.

Would the better thing to do is to take the inputs, dis, signal pins and power pins, route all of those to the left, close to each other, and take the output and do the same thing towards the right?

@JC The top LVS result is clean, but intermediate levels show missing pins in the layout.

Subcircuit pins:
Circuit 1: EESPFAL_s3                      |Circuit 2: EESPFAL_s3                      
-------------------------------------------|-------------------------------------------
EESPFAL_3in_NOR_v2_0/OUT                   |s3 **Mismatch**                            
EESPFAL_3in_NOR_v2_0/OUT_bar               |s3_bar **Mismatch**

My personal preference is to make sure LVS is clean (if possible) at every level. Your openroad gui shows what appears to be one red power rail running vertically through the macro. There should be 2, one for VSS and one for (dummy) VDD. If you zoom in, are there actually 2 and do they connect to all your macro m3 power rails? As @Tim Edwards mentioned, routing on boundaries, tends to be in the direction on into the chip. If the macros are placed close together, you may get a congestion error. Either separate you macros by a few tracks, or arrange your LEF so that routing can be done by dropping vias.

Gotcha. I will add all of those tasks into what I need to check and fix.

I’m going to try to recreate the error. The lef file you attached was empty. Could you upload all the files? config.json, verilog rtl, gds, lef, macro_placement.cfg.

Yes! Please kindly find the .zip containing the files. I have included the

./env.py issue -survey

in the readme.txt just in case.

The lef file may be a bit old. It doesn’t look like the pins are in the same position as the gds. For LVS, pins can be any size, but for lef, you probably want your pins to be at least as wide as the underlying metal. The pins for the power rails should be the exactly the same size as the underlying metal. There should be GND text on each GND metal 3. After fixing the pins and using this command to write lef,

lef write -tech -hide 100 -toplayer -pinonly 100

, I got 20 violations and shorts. Looks like there’s not enough room to place met1 contacts to li1 on the left side. See attached diagram. Also attaching the gds file and lef file that I used. I copied the

Makefile

from

caravel_user_project/openlane

to

caravel_user_project_analog/openlane

Moved the files around a bit and ran

make blackbox_test_2

. All the changes should be in the attached tarball. The results are in

openlane/blackbox_test_2/runs/<timestamp>/results/routing/blackbox_test_2.odb

which you can view in openroad.

export UPRJ_ROOT=$PWD
cd $OPENROAD_ROOT
make mount
openroad -gui

The data will be located under

user_project

. You can load the drc database which is located at

user_project/openlane/blackbox_test_2/runs/<timestamp>/reports/routing/drt.rpt

Thank you for looking into the issue. To follow your steps, am I supposed to move the relevant folder/files into the copy of caravel_user_project_analog directory? And does the following image points to the caravel_user_project_analog I have is too old?

Run

make blackbox_test_2

from

caravel_user_project_analog

not

caravel_user_project_analog/openlane

. That should set

PDK_ROOT

,

CARAVEL_ROOT

,

OPENLANE_ROOT

and

PDK

.

i redownloaded

caravel_user_project_analog

but looks like docker is having issues. Should I replace the makefile that's in

~/caravel_user_project_analog

with the make file thats in

~/caravel_user_project_analog/openlane

? The attached makefile belongs to

~/caravel_user_project_analog

edit: I have done similar setup to

~/OpenLane

and

caravel_user_project

. Do I have to repeat the setup for the dependencies (caravel, volare, etc.), for caravel_user_project_analog?

caravel_user_project_analog/Makefile

and

caravel_user_project_analog/openlane/Makefile

are different files. Both are needed. If

caravel_user_project_analog/openlane/Makefile

is missing, copy from

caravel_user_project/openlane/Makefile

. If you have

CARAVEL_ROOT

,

PDK_ROOT

,

PDK

,

OPENLANE_ROOT

and

UPRJ_ROOT

defined, I don’t think you need to run

make setup

again.

I think I get it... i'm running the

make install

on the caravel_user_project_analog but stopped and uninstalled it. I've checked the

caravel_user_project

's caravel folder is not empty but it looks like it's caravel lite that's installed. Is that the where I should point the

CARAVEL_ROOT

to?

Right. That should be ok.

@Mitch Bailey: Is there a package that I can install for other tools? I'm looking at warnings from running

make blackbox_test_2

in the following image. The errors that comes with it I think has to do with the tools not up to date

You can try

make openlane

in the

caravel_user_project_analog

directory. This may delete and reinstall the

OPENLANE_ROOT

directory, so be sure to backup any files that you may have modified there.

I tried

make openlane

in caravel_user_project_analog and it seems to have pulled a pretty old version of it. The tested pdk doesn't look like to be listed on volare

WARNING]: OpenLane may not function properly: The version of open_pdks used in building the PDK does not match the version OpenLane was tested on (installed: 933e5f2b8e42c5ec25b83c6d242455ada6f3e926, tested: a56526bfe45971322526978132b059d43ddd3a02)
This may introduce some issues. You may want to re-install the PDK by invoking `make pdk`.

You can override the settings in the Makefile. Here are the current settings in the digital

caravel_user_project/Makefile

. Just set these before

make openlane

or `make pdk-with-volare`; there’s no need to modify the Makefile.

export OPEN_PDKS_COMMIT=78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc
	export OPENLANE_TAG=2023.07.19

make blackbox_test_2

on caravel_user_project_analog got past the error by having done

export OPENLANE_TAG=2023.07.19

. But the step 40 lvs reports the same issue. Would you mind checking it on your end? I have included the files in the attachment. I have a version that uses vccd1 and vssd1 pin names but that didn't make a difference. edit: Does the width of the VDD and GND rails have to be same as the rails used for the decap6 ~ decap12?

What command did you use to create the lef file? It looks like metal3 pins are overlapping metal3 obstruction. Looking at the final gds, you can see that neither GND nor VDD is connected to your macro. The current power rail spacing (about 150um) is too far apart for your macro. You’ll need to have a narrower pitch and be careful of where you place your macros. I don’t know why the met4 VDD power rail is not connecting and also why the pdn report does not show a missed connection. Wondering if it might have something to do with grid placement.

@Mitch Bailey: Sorry for the confusion. The lef file is generated with

lef write -tech -hide 100 -toplayer -pinonly 100

. As for the M3 pins, I drew the pins exactly the same size, length and place it on top of the M3 line. My question for grid placement is, this is 1/16 of the sbox and the goal of doing

blackbox_test

was to get familiarize with openlane's handling of macros. Would introducing 1 or 3 more, placing it in a 1x4 pattern or 2x2 pattern, be wise to try changing up the grid placement? Another thing I'm curious is, would the VDD line be better placed away from the circuit such as below the last row of GND?

@Mitch Bailey: I am sure I have not tried all the

-hide <distance> -pinonly <distance>

options in all possible combinations. Generally, the

lef write

options were created to solve specific problems and different options might interact in unexpected ways if nobody has tried that combination before. I'll take a look at it later today.

@Mitch Bailey what would be the recommended M3 boundary to have between the M3 rails?

The expected metal3 obstructions in my diagram were the bounding boxes of the underlying metal3 minus the metal3 pins. I thought I had a version where magic calculated it automatically.

I will try to include the M3 boundary box within the layout and see what happens.

Probably not the bounding box purpose, but an blockage purpose is needed. for met3

70/10

.

Gotcha. By the way I found this issue: https://github.com/The-OpenROAD-Project/OpenLane/issues/1768 The solutions looks like its for gf180. Is there a version and method for sky130A to do what @Kareem Farid suggested in

caravel_user_project_analog

?

add_pdn_connect \
    -grid macro \
    -layers "Metal3 Metal4"

Rereading the discussion, I think what @Kareem Farid was saying is that openroad assumes that macro have a power grid up to one metal layer lower than the top metal layer specified in the config file. Since the macro in question did not have met3 or met4, the configuration was modified to add those. This may be related to the problem you’re seeing if your max routing layer is met5. Can you try setting the max routing layer to met4?

Yes. It is OpenLane pdn script that makes that assumption though.

I've tried

"RT_MAX_LAYER":4

but I don't think that's the command. I got the following error

[ERROR GRT-0056] In argument -clock_layers, min routing layer is greater than max routing layer.

as shown in the image. Under

pdn_cfg.tcl thats

located in

~/OpenLane/scripts/openroad/common

is it possible to change the

FP_PDN_VERTICAL_LAYER

and `FP_PDN_HORIZONTAL_LAYER`in line 128 using the config file? I don't see these 2 variables listed in the Flow Configuration Variables and PDK Configuration Variables of openlane documentation.

RT_MAX_LAYER is not the way to do it. I suggest you copy

pdn_cfg.tcl

and provide your own config file using

FP_PDN_CFG

and add the necessary changes to it

I've made changes to line 128 with

-layers "Metal3 Metal4"

and also renamed a copy of pdn_cfg.tcl. The flow is complaining it can't find Metal3. The

FP_PDN_CFG

seems to be successful in telling openlane where to go?

@JC metal layers in sky130 are called met1, met2, met3, met4 and met5

@Kareem Farid: Met3 and Met4 clears step 7 but the rails are still not connected to the macro. Would you mind checking it? I have included the gds and lef in the attached folder.

@JC can you attach all the design files? Also can you do that on github? It will be easier to follow the issue there.

@Kareem Farid I understand and I have open the issue on github. I'm leaving this link here for reference purposes: https://github.com/The-OpenROAD-Project/OpenLane/issues/1947

Great to see the progress! With openlane, circuit 1 is the extracted layout. So what you’re saying is that you do not need to actually connect the macro to normal VDD or GND? The macro ground is going to be physically connected connected to the top level GND through the psubstrate unless you use separate deep nwells. However, you can trick LVS into ignoring this high resistance connection by surrounding your macro with

subcut

(81/53 in klayout,

isosubstrate

in magic [2nd row, 1st column]). The whole point of the dummy VDD pin was to allow the power grid router to connect to GND. If you don’t need to connect to VDD or GND, you may be able to skip

FP_PDN_MACRO_HOOKS

. You’d need to define you’re rtl so that the macros do not connect to normal GND/VSS and probably need to modify (widen) the layout connections manually after post-processing.

I will try the trick shortly. My current concern is how serious of an undertaking it is to make the layout to have deep nwell? Would the circuit still work if we went on with the current layout because we want to take power measurements of this macro and its digital counterpart. This is the first time I need to use deep nwell. If this means securing the circuit's robustness or functionality, I will do it. I assume it is not be as simple as just laying a blanket deep nwell layer over the whole layout and call it good? Edit: Apologies for not addressing the question. We do not need to connect the macro to normal VDD or GND. We wanted to have some way to take power measurements of the macros and went with the plan of using gpio pins as the adiabatic and its digital counterparts' ground.

Each deep nwell needs to be surrounded by an nwell/ntap guard ring. All nwells within each deep nwell will be connected. Since the adiabatic circuit uses 4 separate nwells (right?), you’d need separate deep nwells. Or you might consider putting just the nmos in deep nwells and having all the pmos nwells separate, but either way looks like a lot of work with the current layout. If you can physically separate your macro from the other psub taps, and you expect you macro GND to be nominally 0V, using the

subcut

layer may be sufficient.

Inspecting the adiabatic circuit, if I group nwell into columns, each CLK powers that column. Please correct me if my understanding is wrong. The deep nwell plus its guard rings will be grouped by its columns and then separated, because for example CLK0 and CLK2 nwell cannot share the same nwell and that rules applies for deep nwells. The adiabatic's macro ground gpio pin will be connected to the external signal generator's ground and that should be nominally 0V. What does it mean by physically separate the macro from other psub taps?

Dividing by columns should work, but from the layout I have, it’s currently not a clean division. See attached. Space between dnwell is 6.3um and the deep nwell has to be enclosed by nwell which has a width/spacing rule of 0.84um/1.27um. See here. So that’s probably about another 26um in width.

I think for spacing, we should have enough space. If I decide to not go down the dnwell route, would having the taps (guard rings, right?) surrounding the columns work after making them more symmetrical? Or the better strategy be creating guard rings in a grid pattern like the following image

What does it mean by physically separate the macro from other psub taps?

The standard cell rows outside your macro have GND psub taps. If these are too close to your macro, they might affect your measurements. I don’t know what good having a grid of guard rings inside your macro will do.

Gotcha. For the guard ring, do I make surround the whole macro instead if I opted for no dnwell? Also what governs the distance between the standard cells' GND psub taps and the macros?

For the whole macro guard ring, a thin nwell with ntap connected to VDD might work. Using a ptap guard ring with GND just puts the leak source closer to your macro. I think there’s a HALO option that controls the spacing between the standard cells and the macro. Also, if you place the macro at the edge of your design, be aware of the spacing to the io cells.

when you say VDD, are you referring to the floating VDD that's in the macro or its the standard cells? And what is the layer name for tap in klayout?

VDD of the standard cells. Should be able to remove the floating VDD if you’re not doing power routing to your macro. For your macro guard ring, you probably need nwell

42/20

tap

65/44

nsdm

93/44

just like your current nwells.

@Mitch Bailey, @Tim Edwards: may I ask for a cross section for a deep n well process? I've spoken with my advisor and we will be needing the deep n well process to properly give the macro its own ground domain.

@JC Figure 2 triple well here is pretty good. Depending on your expected voltage levels, you might want to surround each nwell and pwell with it’s own guard ring to prevent latch up. With digital designs, it’s not that critical, but with the adiabatic circuit, the nwell voltage will fluctuate quite a bit, correct?

Yes the nwell voltage will change based on the clock. I will go ahead and add the guard rings for the pmos and nmos devices. I'm thinking the overall layout for one of them would look like the following illustration. The Deep Nwell will be separated by columns and further separated by its CLK number. We were also thinking that since the power fluctuates, we can make the body of pmos be tied to analog VDD for body voltage consistency... but will have to simulate it to see what will happen.

@JC: The PDF that Mitch cited looks like it has a deep n-well structure that is the same as used by Sky130, with the nwell forming a continuous ring around the deep n-well, and overlapping the edge of the deep n-well.

Ah I see. I did not draw in the nwell that will be overlapping the edge of the deep n-well and surrounding the pwell. I will make sure to lay that out.

If you are going to tie all your pmos body connections (that’s the nwell taps) to VDD, you’ll only need one deep nwell region. I assumed the nwell body would be where you were storing the energy, but my understanding of the adiabatic process is probably incomplete.

I think so? If the pmos body is tied to VDD, all the deep nwell can be treated as its own entity... I'll make the layout for the basic building block happen first then I'll move on checking lvs on xschem. Are there any pitfalls I should be aware of when making the schematic in xschem?

If you’re pmos body will always be VDD (and the pmos source is never greater than VDD), you should be able to just cover the current layout in deep nwell and add a nwell/ntap guard ring around the entire macro. When using xschem with multiple power nets, I copy the gnd and vdd symbols to local versions and remove the global property. You’ll need to add power i/o pins too though.

Does pwell share the same drc rule as nwell?

I believe the pwell layer is ignored in drc and mask creation. Anything not nwell is going to be pwell. If you’re planning on covering the entire macro with dnwell, then connecting the pmos body to clock will short all your clocks which is probably not what you want. What happened to connecting pmos body to VDD?

Thanks for looking at it. For dnwell, I was thinking to not have a full blanket covering the macro, but based on CLK number. If I connect the CLK0 layers to its own dnwell, CLK1s to their own dnwell, that would avoid shorting them together, right? For VDD to pmos body we still have to find out what will happen to the circuit... I'm not hundred percent certain about where it holds the energy during the hold phase, I'll have to check.

If I connect the CLK0 layers to its own dnwell, CLK1s to their own dnwell, that would avoid shorting them together, right?

That is correct.

Hi @Mitch Bailey, by using the dnwell under the pwell, I'm supposed to draw a nwell ring around the dnwell? DRC on klayout did not complain but Magic did. Should I be drawing a deepnwell ring around the pwell? I tried referring the drc rule page but it doesn't look extremely clear.

I do not see deep nwell in the gds you posted. In the image, it appears that you’re trying to add deep nwell at the block level. This is not necessary if you intend to tie the deep nwell to VDD. Just add deep nwell over(under?) the whole macro and create a nwell guard ring with nwell tap connected to VDD around the outside. Your deep nwell should not have any holes. The layout uses the pwell layer, but this layer is ignored in drc, lvs and tapeout. I suggest not using the pwell drawing layer. Anything not nwell is physically pwell.

The current motivation is to make sure I understand the make up and DRC rules for deep nwell. I was thinking of using a block level to test things out. When you say no holes for deep nwell, this means the dnwell go under the pmos, then make a ring of nwell + (nsdm + tap + li). Deep nwell is the bottom of a bucket, Nwell guard ring is the wall where 0.4um from inner dnwell, extend 1.03um from exterior dnwell. Using the single block level as a model, I can connect the first pmos guard ring to VDD, and then also the outer ntap + nwell guard ring to VDD. So the strategy is: The pwell layer from klayout is redundant, so I can treat the layout process for the block levels as if it is a dual well process. On the macro level, I can put down deep nwell blanket across the whole macro, surround macro with ntap+nwell guard ring. VDD is dropped down to the pmos's guard ring and also the nwell guard ring. edit: The image and gds file doesn't have licons, please treat it as if its there for now.

@JC

When you say no holes for deep nwell, this means the dnwell go under the pmos, then make a ring of nwell + (nsdm + tap + li). Deep nwell is the bottom of a bucket, Nwell guard ring is the wall where 0.4um from inner dnwell, extend 1.03um from exterior dnwell. Using the single block level as a model, I can connect the first pmos guard ring to VDD, and then also the outer ntap + nwell guard ring to VDD.

So the strategy is: The pwell layer from klayout is redundant, so I can treat the layout process for the block levels as if it is a dual well process. On the macro level, I can put down deep nwell blanket across the whole macro, surround macro with ntap+nwell guard ring. VDD is dropped down to the pmos’s guard ring and also the nwell guard ring.

That is correct.

Looking with magic, the nwell guard ring should be spaced out properly avoiding the psdm, correct? For the N-well overlap of Dnwell error, nwell should be 1.03 into dnwell, and 0.4um out of dnwell?

Right, in the current layout, it looks like ptap overlaps the nwell guard ring surrounding the deep nwell. Also, your pmos gates might have better performance if you connected them at the bottom close to the contact instead on on the top so it looks like a

u

instead of an

n

.

@Mitch Bailey: Hi, I have made remade the layout to incorporate the guard rings and the nwell guard rings plus deep nwell. Would you mind checking if the nwell guard ring makes sense? Klayout drc did not produce an error. I will try magic drc. Edit: Magic caught one M3 vdda1 power rail line that is at an angle. Fixed that. Next step is perform lvs and then attempt to incorporate into OpenLane flow. Will report back in a few hours.

@JC Looks pretty good! Couple places where met2 could be used instead of li1, but probably won’t be a big deal. I noticed that at the top level, you’re connection vdd to vdda1. vdda1 is sometimes 3.3V. What is your vdda1 level? What are your maximum CLK* signal voltages?

Max CLK voltages are 1.8V. I thought vdda1 or one of the analog pairs connects to 1.8V?

I usually run ERC with vdda1/2=3.3V, but I believe it is externally configurable. See https://open-source-silicon.slack.com/archives/C01E06TUSC9/p1693404959275169?thread_ts=1693399602.360369&cid=C01E06TUSC9

Gotcha. The current plan is to have the power clock voltages peaks and holds at 1.8V and PMOS body be tied at 1.8V. So is it safe to assume vssa1/2 is also existing as a header pin that I can externally jumper wire to? With the current pin names in the layout, I'm thinking vdda1 to keep at 1.8V while having vssa1 as a floating pin to satisfy the vdd and gnd net of`PDN_MACROHOOK` in openlane. For the

prboundary

layer, should I bring the other pins to the edge of that layer for OpenLane to discover the pins and route to it?

FP_PDN_MACRO_HOOK

does not require the power/ground voltages to be paired (ie, vdda1 with vssa1). Your macro needs

GND_GPIO

, right? I don’t see the need for a dummy vssa1 in you macro. I’m not sure about how independent vssa1 and vssa2 are. I think the

prboundary

is necessary for automatically creating lef and maybe placement. moving the pins to the boundary is one way to simplify, but it may not be necessary. standard cells route over and connect internally.

@Mitch Bailey Hi Mitch, I'm running into an error with yosys in step 1 (image 1). This happened after I made a linux clone of my previous system. I think there is something missing in the setup. I have set the

export OPENLANE_TAG=2023.07.19

to the version you suggested. While running

make pdk-with-volare

i'm getting permission error (image 2) but when I sudo it (image3), it fails as well. Would it be recommended to uninstall caravel or even reinstall caravel_user_project_analog?

I would not run anything with sudo during normal openlane installation - it sometimes causes problems later. Before running

make pdk-with-volare

be sure to set

PDK_ROOT

and

PDK

. My suggestion is to install everything with

caravel_user_project

using

make setup

(set

OPENLANE_ROOT

and

PDK_ROOT

to a directory outside the project). Then you can clone

caravel_user_project_analog

and work from there without rerunning

make setup

. You may want to set some of the environment variables from the

caravel_user_project/Makefile

instead of the current defaults of

caravel_user_project_analog/Makefile

.

Running make setup from

caravel_user_project

deletes

~/OpenLane

... That's normal, correct? Also for the environment variables in

caravel_user_project_analog/Makefile

, what am I supposed to target for change? For PDK_ROOT am I supposed to point it to

~/.volare

or the

/usr/locals/share/pdk

?

Right, running

make setup

deletes

$OPENLANE_ROOT

and

$PDK_ROOT

. You probably don’t have write permission to

/usr/locals/share

so I wouldn’t use that. If you have a ~/sky130 directory, maybe

export OPENLANE_ROOT=$HOME/sky130/Openlane
export PDK_ROOT=$HOME/sky130/pdks
export SKYWATER_COMMIT=f70d8ca46961ff92719d8870a18a076370b85f6c
export OPEN_PDKS_COMMIT=78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc
export OPENLANE_TAG=2023.07.19

would work well.

Currently I have ran

make install

in

caravel_user_project_analog

with

caravel_lite=0

. The

PDK_ROOT

and

OPENLANE_ROOT

is pointed towards

~/.volare

and

~/Openlane

respectively. I have root access to

/usr/

since this is my personal machine. For ~sky130 directory I don't have it made. I have obtained and installed the pdk via Open_PDK steps from opencircuitsdesign.com. Should I make a copy of

/usr/locals/share/pdks/sky130A

into the home directory and set the

OPENLANE_ROOT

and

PDK_ROOT

to that copy? Or just make a folder named sky130 and have

OPENLANE_ROOT

and

PDK_ROOT

be linked there? Edit: After

make install

in

caravel_user_project_analog

, and also replacing the makefile in

~/caravel_user_project_analog/openlane/

with makefile in

/caravel_user_project/openlane/

, it got past step 1 yosys error. Edit2: Currently stuck on step 24 where openlane can't find GND_gpio. Probably due to lef generation -hide covered too much. Will attempt a bigger -hide.

@JC I would not recommend building the pdk manually at

~/.volare

.

volare

is a system to download prebuilt versions of the pdk and may not be compatible with manual installation. I suggest

mv ~/.volare ~/pdks.bak
mkdir $HOME/pdks
export PDK_ROOT=$HOME/pdks
export PDK=sky130A
make pdk-with-volare

Should only take a few minutes. If everything works, you can delete

~/pdks.bak

. You’re

OPENLANE_ROOT

is probably fine. What commands are you using to create the lef from the gds? I see a

GND_GPIO

pin on a pwel layer, which is not necessary.

for the lef command I'm using

lef write -tech -hide 400 -toplayer -pinonly 400

I will go ahead and try the pdk building... I do not have a

$HOME/pdks

directory, but i have

~/open_pdks

downloaded. Do I point

PDK_ROOT

to the sky130 folder that's in

~/open_pdks

? Edit: Oh... I'm not reading the instructions correctly. I will go ahead and try the exports.

@JC Looks like it might be a problem with the PDK.

MAX_FANOUT_CONSTRAINT

is present in my gf180mcu pdks but not the skywater ones (which may be old). Just to be sure, what version of the pdk are you using?

echo $PDK_ROOT/$PDK
cat $PDK_ROOT/$PDK/SOURCES

(base) jchin2@short-simple:~/caravel_user_project_analog$ echo $PDK_ROOT/$PDK
/home/jchin2/pdks/sky130A
(base) jchin2@short-simple:~/caravel_user_project_analog$ cat $PDK_ROOT/$PDK/SOURCES
open_pdks e6f9c8876da77220403014b116761b0b2d79aab4
(base) jchin2@short-simple:~/caravel_user_project_analog$

I think that's the default pdk version that's in the makefile

~/caravel_user_project_analog/Makefile

Ok. I think I can see a problem in my instructions. Thanks for your patience. First,

caravel_user_project_analog/Makefile

is out of date, but we can work around that. We’ll use

caravel_user_project/Makefile

to build the environment and then switch to

caravel_user_project_analog

. In a directory where you want to install everything (eg.

$HOME/sky130

)

export OPENLANE_ROOT=$PWD/openlane_src
export PDK_ROOT=$PWD/pdks
export CARAVEL_ROOT=$PWD/caravel
git clone -b mpw-9d <https://github.com/efabless/caravel_user_project>
cd caravel_user_project
make setup

I forgot to mention the tag in the past. This should create everything in the

OPENLANE_ROOT

,

PDK_ROOT

, and

CARAVEL_ROOT

directories.

cd ..
git clone -b mpw-9d <https://github.com/efabless/caravel_user_project_analog>
cd caravel_user_project_analog
rm openlane/Makefile
cp ../caravel_user_project/openlane/Makefile openlane/Makefile

You can either add these lines to your

caravel_user_project_analog/Makefile

SKYWATER_COMMIT=f70d8ca46961ff92719d8870a18a076370b85f6c
export OPEN_PDKS_COMMIT?=78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc
export OPENLANE_TAG?=2023.07.19

or set these in any shell you use.

export SKYWATER_COMMIT=f70d8ca46961ff92719d8870a18a076370b85f6c
export OPEN_PDKS_COMMIT=78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc
export OPENLANE_TAG=2023.07.19

No, thank you for being patient with me! I will try this when I have access to WiFi

If you have already run

make setup

in the

caravel_user_project

directory, there should be no need to run

make openlane

or

make pdk-with-volare

. You can try

ls $OPENLANE_ROOT
ls $PDK_ROOT/$PDK
ls $CARAVEL_ROOT

to make sure everything is installed.

Earlier, I ran make openlane during the wait... I redid the instructions above and also made sure to replace the

caravel_user_project_analog/openlane/Makefile

.

Make blackbox_test_3

doesn't run.

ls openlane/blackblox_test_3

maybe you meant

blackbox_test_3

? 😉

ah... that was a dumb typo, thank you for catching that. This is my lef command

lef write bitfour_EESPFAL_switch -tech -hide 400 -pinonly 400

and the error persists. I tried moving GND_GPIO in and out of prboundary but still have the same error.

Maybe it’s easier to not use

FP_PDN_MACRO_HOOKS

at all and connect everything manually. You might need to set

QUIT_ON_LVS_ERROR

to

0

. I was assuming you’d use

"FP_PDN_MACRO_HOOKS": "lane0 vdda1 vssa1 vdda1 GND_GPIO",

Going afk for awhile.

I changed the name GND_GPIO to some_GND just to see if the name would be doing anything to it. When I forgot to update the verilog files, the same error shows up but it moved to CLK[1], CLK[2] not in guide . I know its the same error as the following https://github.com/The-OpenROAD-Project/OpenLane/issues/1958. but when they say use a certain version, I'm not sure which one. I have included a .zip file of the current iteration.

I’m not sure. However, with your current design, I don’t think you need a core power ring. This creates and metal power ring around your macro. If you set

FP_PDN_CORE_RING

to

0

, do you complete without errors?

The error is still there. Should I be removing vssa1 and all relevant vssa1 related mentions in the top verilog and blackbox?

You can probably remove vssa1 from the verilog and blackbox. Don’t know what it means by “guide”. Here are the magic and netgen repos. I have not installed ngspice. To install locally on Linux systems (netgen

example

)

git clone <https://github.com/RTimothyEdwards/netgen>
cd netgen
./configure --prefix=$HOME/local
make
make install

This will install in

$HOME/local/bin

so you may need to modify your path. To change the version within docker, if

OPENLANE_ROOT

is set

cd $OPENLANE_ROOT
export OPENLANE_IMAGE_NAME=efabless/current-local
vi dependencies/tool_metadata.yml
(change the commits of the programs you want to update)
cd docker
make openlane

You’ll need to set

OPENLANE_IMAGE_NAME

in every new shell window.

@Mitch Bailey: Hi Mitch, I have tried changing the version within docker and it is getting blocked by docker...? I have also made a ppt log to show what else was attempted before reaching the state shown in the image.

What does

docker images | grep local

return? Looks like the image name is slightly different than what is expected. It’s been a while since I had to update the docker, so something may have changed.

(base) jchin2@short-simple:~/sky130/openlane_src/docker$ docker images | grep local efabless/current-local-amd64 latest 6e1cd0844c15 3 hours ago 1.11GB

Ok. It’s changed to add the architecture to the image name. Maybe

export OPENLANE_IMAGE_NAME=efabless/current-local-amd64

would work now. (Don’t rebuild the docker image. Just try to run openlane. Sorry, I’m not more help.)

make blackbox_test_3

is running again! But the

error DRT-0218:  Guide not connected to design

still continues... Would you know of who I can bounce this issue off to?

Let’s make sure the verilog is consistent. In the document you sent yesterday,

bitfour_EESPFAL_switch lane0 (
`ifdef USE_POWER_PINS	
	.vdda1(vdda1),
	.vssa1(GND_GPIO_top), //Floating GND pin to trick OpenLane
`endif

but module

bitfour_EESPFAL_switch

has no

vssa1

port.

module bitfour_EESPFAL_switch (
`ifdef USE_POWER_PINS
	inout wire vdda1,
	inout wire GND_GPIO,
`endif

I have fixed the inconsistencies. Shouldn't linter catch them?

Sorry, I’m not familiar with the verilog linter checks. Do your changes fix the problem?

No, it doesn't. I will try again with the correct nwell guard ring and dnwell overlap. Does the error show up on your end?

I think it’s a problem with the lef file. The CLK[0] pin is very small. x[0] is also in a different location than other signals on the same bus. Maybe moving the pins outside the prboundary and using -hide 0 would give a cleaner lef. Might be able to manually modify the lef file afterwards to have several long metal3 pins for vdda1 and GND_GPIO running horizontally across the macro. These would connect with vertical metal4 rails in the upper hierarchy.

I will try moving all the pins outside of the prboundary. Next thing I will try is make the pins big... How big of a pin should I go up to?

The lef looks a lot cleaner, especially the met3 power rails. Are you still getting the error on

CLK[0]

or is it some other pin? The metal2

Dis_Phase

looks really small and may miss the guide.

It's still CLK[0]. I also noticed since we are not using pdn_macro_hook, the rails have reverted to vpwr and vgnd.

I think it may have to do with pin placement. The

clk_top[0]

pin is clear on the top right with a lot of other pins between it and the

CLK[0]

macro port. I think if we lower the macro to allow more routing on the top, we might get better results. (Moving the macro changed nothing.) You might also consider using a pin_placement file to arrange the pins close to where you want the outputs to be. Do you know how to view the openroad database? From your user project directory

export UPRJ_ROOT=$PWD
cd $OPENLANE_ROOT
make mount
openroad -gui

and then choose

File

->

Open DB

and choose

user_project/openlane/blackbox_test_3/runs/<time_stamp>/tmp/routing/17-fill.odb

(edit) The above requires a patch to

$OPENLANE_ROOT/Makefile

ENV_START = docker run --rm\
        -v $(OPENLANE_DIR):/openlane\
        -v $(OPENLANE_DIR)/designs:/openlane/install\
+       -v $(UPRJ_ROOT):/openlane/user_project\
        $(PDK_OPTS)\
        $(STD_CELL_OPTS)\
        $(DOCKER_OPTIONS)

I tried doing

make mount

from openlane_src, and docker is not happy. I accessed openroad -gui from the original OpenLane directory and the image is as shown.

I think you can skip the

FP_PFN_MACRO_HOOKS

and connect the power rails later manually. I don’t know if it will complain about unconnected signals or not.

Gotcha, I will try it out. In layout, i will leave them alone as for its verilog counterpart, I will remove the definition of

ifdef USE_POWER_PINS

from the top verilog and blackboxed verilog and omit

FP_PDN_MACRO_HOOKS

. edit: Ah, nevermind. I don't have to remove the

ifdef endif

block nor the

VDD_NETS and GND_NETS

. Just the

FP_PDN_MACRO_HOOKS

.

How about

results/routing/blackbox_test_4.odb

?

This is what was generated... From what it looks, all the power rails are drawn over the macro.

Can you try

Windows

->

DRC viewer

in the gui? The right hand pane should have a new

DRC Viewer

tab. Open that tab to see where the violations are.

Is there something that needs to be loaded into it for the DRC to work? My understanding is

RUN_TAP_DECAP_INSERTION

and

RUN_FILL_INSERTION

doesn't need to be there and its using up space.

I was hoping they’d show up automatically. There is a load button. Try loading

reports/routing/drt.drc

i have tried a much tighter die size but it failed at step 7.

Looks like there may not be enough routing space at the top. Once you have a clean run on a large inefficient layout, you can gradually reduce the size.

Gotcha, so I should keep the

RUN_TAP_DECAP_INSERTION

and

RUN_FILL_INSERTION

enabled and then reduce the size accordingly

If your signals are being buffered (and you want buffering) between the pins and the macro, then you need to keep decap/tap and fill.

Gotcha. After speaking with my team mate, we are certain we don't need signal buffering between the pins. I will try to make it smaller.