Matching needs to take W/L ratios at least into account.

To be undertaken once we have enough PDKs from #203

Original comment from Steve below:

Let me know how you want to do the M3 porting. I currently get opens when I port both M2 and M3 lines (because I can't port the V2 without the global router crashing.)

We should do what makes sense and fix the issues that it causes.
Options seem to be:

• Port metal2 only --- router doesn't know that it is connected internally
• Port metal3 only --- router can't use existing metal2 for routes (metal2 in LEF as an obstruction)
• Port metal2 and metal3 --- router thinks there is an open when only looking at the LEF view (can be solved by looking at all the layout
• Port metal2, metal3 and via2 --- router crashes but could be fixed

@kkunal1408 The make flow is not working currently. Can you fix it?
Pull request #88 has the circleci config necessary to include make runs in the CI.

Having MockPDK canvas rely on # fins, polys & dummies discourages canvas reuse & forces us to pass these parameters around to downstream processes.

For example, PnRPython has these values hardcoded right now. The whole flow will fail dramatically the minute someone tries a different combination of fins, polys & dummies.

This fix is needed before #203 can be committed to master.

Does it makes sense to always export M2 pins even when we are going through multiple via layers to do so? I feel like it would make more sense to simply extend existing M2s... Or export a higher metal layer to begin with.

@stevenmburns @desmonddak @Lastdayends

While I briefly alluded to this issue in #165, it should be considered an independent enhancement and not a bugfix for the MinL issue.

python3 & pip3 are currently hard-coded in Makefile.

May be better to create a virtual environment in a separate step.

Test benches should come with whatever simulation collateral is needed to successfully simulate the schematic view in Xyce. This includes spice models, test circuits and the tolerances associated with each circuit property. It is entirely possible we may need to do some Python based post-processing to actually extract the properties of interest from the Xyce waveforms. I suggest starting with the simplest properties that can be directly measured.

Please let me know if you need any help @meghna09 @tonmoydhar @arvuce22.

Running into DRC MinLength issues when x_cells = 1 & y_cells = 1

Potential solutions include:

• Port M1 instead of M2 when M2 is not needed for routing
• Always port M2 or above and extend M2 rectangles where needed.

Potentially related to #167 if we decide to go with option 1.

Any feedback @stevenmburns, @arvuce22 ?

There are a few separate but related issues here:

1. There is no mapping from the Transistor (M*) device types represented in basic_element.sp to default devices in SPICE. We should either refactor basic_elements.sp to refer exclusively to NMOS & PMOS for M* devices... Or we should add appropriate .model statements so that the mapping is clear. I elected to take the second route in Circuit/tests/basic_template.sp as shown below.

.model NMOS_VTL NMOS
.model PMOS_VTL PMOS
.model nmos_rvt NMOS
.model pmos_rvt PMOS
.model nch NMOS l=60N m=1 w=1u
.model pch NMOS l=60N m=1 w=1u

2. We should not be overriding default SPICE types as it results in significant confusion. For example, we are overriding Res & Cap with subcircuit definitions in basic_element.sp. This makes it very confusing as to whether future Res / Cap instantiations should start with X* or R* / C*. For the new Spice Parser in Circuit, I am simply throwing an assertion if the user attempts to redefine something that's already in the library. I have commented out the lines of concern in Circuit/tests/basic_template.sp.

** You may not redeclare an existing library element
; .subckt Cap PLUS MINUS
; CC1 PLUS MINUS 60f
; .ends Cap

** You may not redeclare an existing library element
; .subckt Res PLUS MINUS
; RR1 PLUS MINUS 10k
; .ends Res

3. Number of terminals is often ambiguous. We cannot be using 2 terminal devices to be creating 3 terminal ones. I have circumvented the issue by creating empty subcircuit definitions in Circuit/tests/basic_template.sp as shown below.

** CANNOT USE 2 TERMINAL CAP TO CREATE 3 TERMINAL CAP
; .subckt Cap_b PLUS MINUS BULK
; CC1 PLUS MINUS BULK cap cap=60f
; .ends Cap_b
.subckt Cap_b PLUS MINUS BULK
.param cap=60f
.ends Cap_b

.subckt spiral_ind PLUS MINUS BULK CTAP
.param w=9u
** DEFAULT INDUCTOR IS 2 TERMINAL NOT 4.
** SUBCKT SHOULD STAND ON ITS OWN
; L0 PLUS MINUS BULK CTAP spiral_sym_ct_mu_z w=9u
.ends spiral_ind

Summary:
I have made proposed fixes in basic_template.sp in Circuit/tests/basic_template.sp but this is not yet being used by sub_circuit_identification. Please let me know if there is a good reason for the redefinitions / lack of .model mapping from a system-level perspective. I believe it was mainly to construct a list of supported primitives but we should be able to create default spice devices anyway as I highlighted in #221.

Also need to think of leaving enough tracks for digital Vdd & Gnd

@desmonddak

This could be a documentation issue.
The first suggested flow fails because there is no virtual environment in "/general" to source. (It is installed elsewhere and probably should be assumed to be activated.)

The second suggested flow fails because the last line is incorrect:

docker-compose exec make-docker-service make -f $ALIGN_HOME/DESIGN=<design>

Tried a bunch of other things but couldn't figure it out.

@arvuce22 @kkunal1408
Currently we using python to write out a bash script, that when run calls multiple python scripts.
There are multiple problems with this but the main one is that we aren't catching errors (if one of the primitive fails to generate we don't know.)

There are several ways to fix this. One idea is to just import all the python primitive generation code into the python script that current writes out the bash script and generate the primitives from there.
If we want more decoupling, we can write out a json file with the kinds for primitives we want to generate and use that as input to the primitive generation script.

Can you please take a look at this @Lastdayends ?

@Lastdayends

Has the new Gcell based global router been modified so it can generate layer-specific global route information?

If not, what do you need from me to get started? Or alternatively, what do I need to know to do it myself?

@soneryaldiz @Lastdayends @meghna09 @desmonddak @parijatm @arvuce22 @kkunal1408

Here is the case I was discussing yesterday in the team meeting. We are routing signals in metal5 over the top of the unit capacitors. Is this okay, or should we block off unit caps to force routing in the channels between the unit capacitors.

Let's discuss this using this GItHub issue. (If you can't see the picture below, view this issue using the GitHub web interface.)

It is finding .sp files and mapping them to source pawn.

Hi Desmond/Steve,
Thanks for setting up the compose flow. In this flow I found that for PnR compiler installation I need to do have googletest which is an extra task while installing the flow on a standalone server. Can we keep the test flow separate than running flow?
Kunal

@arvuce22 @kkunal1408 @Lastdayends
One bottleneck in runtime for this example is that PnR takes a long time to read in the LEF file. It seems to be very large and from what I can tell some of the component descriptions are repeated 10000 times in the file. I think we need only one copy of each template.

(general) smburns@smburns-XPS-13-9370:~/DARPA/ALIGN-public/PlaceRouteHierFlow$ egrep MACRO ../testcase_latest/sc_dc_dc_converter.lef | sort | uniq -c
    749 MACRO cap_10f
     72 MACRO cap_12f
   9924 MACRO CMC_NMOS_n10_X2_Y2
   4998 MACRO CMC_NMOS_n10_X3_Y1
    749 MACRO CMC_NMOS_n10_X40_Y25
      7 MACRO CMC_NMOS_n12_X139_Y6
    378 MACRO CMC_NMOS_n12_X2_Y1
   9924 MACRO CMC_NMOS_n12_X3_Y1
   9924 MACRO CMC_PMOS_n10_X3_Y1
   4998 MACRO CMC_PMOS_n10_X4_Y3
   9924 MACRO CMC_PMOS_n12_X2_Y1
    378 MACRO CMC_PMOS_n12_X5_Y2
   4998 MACRO CMC_PMOS_S_n10_X1_Y1
   9924 MACRO CMC_PMOS_S_n10_X2_Y1
   9924 MACRO CMC_PMOS_S_n12_X1_Y1
   9924 MACRO DCL_NMOS_n10_X3_Y1
    378 MACRO DCL_NMOS_n12_X1_Y1
   9924 MACRO DCL_NMOS_n12_X2_Y1
    378 MACRO DCL_PMOS_n12_X1_Y1
    288 MACRO DCL_PMOS_n12_X5_Y1
   9924 MACRO DP_NMOS_n10_X11_Y1
   1488 MACRO DP_NMOS_n10_X1_Y1
   4998 MACRO DP_NMOS_n10_X3_Y1
    749 MACRO DP_NMOS_n10_X40_Y25
      7 MACRO DP_NMOS_n12_X139_Y6
     72 MACRO DP_NMOS_n12_X1_Y1
    378 MACRO DP_NMOS_n12_X3_Y1
     72 MACRO DP_NMOS_n12_X3_Y2
   9924 MACRO DP_NMOS_n12_X3_Y3
   2688 MACRO SCM_NMOS_n10_X1_Y1
   4998 MACRO SCM_NMOS_n10_X2_Y1
   2688 MACRO SCM_NMOS_n10_X3_Y1
    288 MACRO SCM_NMOS_n12_X1_Y1
    378 MACRO SCM_NMOS_n12_X2_Y1
   9924 MACRO Switch_NMOS_n10_X11_Y1
   9924 MACRO Switch_NMOS_n10_X2_Y2
      7 MACRO Switch_NMOS_n12_X139_Y6
    288 MACRO Switch_NMOS_n12_X1_Y1
    378 MACRO Switch_NMOS_n12_X2_Y1
   9924 MACRO Switch_NMOS_n12_X3_Y1
     72 MACRO Switch_NMOS_n12_X3_Y2
   9924 MACRO Switch_NMOS_n12_X3_Y3
   9924 MACRO Switch_PMOS_n10_X2_Y1
   9924 MACRO Switch_PMOS_n10_X3_Y1
   9924 MACRO Switch_PMOS_n12_X1_Y1
   9924 MACRO Switch_PMOS_n12_X2_Y1
    378 MACRO Switch_PMOS_n12_X5_Y1
    378 MACRO Switch_PMOS_n12_X5_Y2
    288 MACRO Switch_PMOS_n12_X5_Y4
   9924 MACRO test

See example in https://github.com/stevenmburns/XyceBuild/tree/master/five

@Lastdayends PnR seg. faults if you don't have a CC constraint corresponding to the capacitors in the design (I guess the CC constraint causes the capacitor array to be generated---otherwise there are pins with missing components in the placer.)

We should probably explicitly check for this and assert with a decent error message. It took a while for me to figure out what was going one.

Expressions are being passed as a string directly to Circuit where it gets evaluated in a lazy fashion if user elects to call Circuit.flatten(). Use of eval is dangerous and may not work in case user tries to do something of the sort {no_of_fins*10n} as SPICE scale factors are not recognized by Python.

A better way to implement this would be to use lambda functions (or plain old functions) wherever expressions are needed. The parser would then need to construct these lambda functions.

Deferring this item until we have a better test-case.

@Lastdayends @arvuce22 @kkunal1408
I was looking through the result of the full flow on the telescopic_ota and I see a few things that we need to fix:

• When we make a connection from new metal3 down to our metal2 pins we seem to be adding off-grid metal2 (not quite creating a short but definitely a design rule violation) A good example is the left side metal3 in the picture below.
• We seem to be doing the same thing when we add metal2 pins. They don't seem to be on-grid. See (vinn, voutp,vbiasn) in the picture below.
  

Support is needed both within primitive generation & sub_circuit_identification

Schematic information is currently specified using spice, translated to verilog, map files etc and passed to the placement / routing engine. A lot of critical information such as number of polys, fins etc, gets lost in the process which is critical for successful LVS & parasitic extraction.

Instead of passing all this information back and forth over files, it would make more sense to create a centralized schematic representation that we transform in sub_circuit_identification, has hooks to the CellFabric primitive generators and (eventually) calls the placement / routing engine for whatever extra connections are needed. The same schematic representation can be used to represent the extracted netlist & generate the SPICE subcircuit representation.

The basic steps of read_netlist, match_graph, and write_verilog FAIL on variable_gain_amplifier:
It does not matter whether flat is set to 0 or 1.

(general) root@desmond-v01:/dataVolume/variable_gain_amplifier/topology_output#
(general) root@desmond-v01:/dataVolume/variable_gain_amplifier/topology_output# !211
python3 /ALIGN-public/sub_circuit_identification/src/read_netlist.py --dir ./input_circuit/ -f variable_gain_amplifier.sp --subckt variable_gain_amplifier --flat 1
Reading netlist file: variable_gain_amplifier.sp
INFO: PARSING INPUT NETLIST FILE DONE
circuit graph written in dir: circuit_graphs
(general) root@desmond-v01:/dataVolume/variable_gain_amplifier/topology_output# !212
python3 /ALIGN-public/sub_circuit_identification/src/match_graph.py
Start matching graphs
(general) root@desmond-v01:/dataVolume/variable_gain_amplifier/topology_output# !214
python3 /ALIGN-public/sub_circuit_identification/src/write_verilog_lef.py -U_cap 12 -U_mos 12
Traceback (most recent call last):
File "/ALIGN-public/sub_circuit_identification/src/write_verilog_lef.py", line 422, in
ALL_LEF, UNIT_SIZE_MOS, UNIT_SIZE_CAP)
File "/ALIGN-public/sub_circuit_identification/src/write_verilog_lef.py", line 328, in generate_lef
" --length " + str(values['l']))
KeyError: 'w'

May need your help @arvuce22 to figure out MockPDK values. Will probably work on this once #209 is completed.

@Lastdayend

It seems that metal1 pins generated in the cap array are not on grid, so the top-level router does not properly connect to them (vias are missing). You can see this in the switch_capacitor_filter and especially in the subblock switch_capacitor_combination.

This is more our CI designs in examples/ using the Mock PDK.

@meghna09 @kkunal1408 @tonmoydhar @sapatnekar

The following designs in $ALIGN_HOME/examples fail to run through the flow.

• sc_dc_dc_converter
• adder
• linear_equalizer
• single_to_differential_converter
• variable_gain_amplifier

The last four fail due to missing parameters.
The first fails with a core dump in the router.

We should fix these or move them somewhere else. We shouldn't be advertising test cases that fail.

Discussion from #64 Summarized Below

@parijatm @arvuce22 I think having the unit cell height (and for that matter, the unit cell width) is a nice thing to be encoded in the grid. I think at least the m2 centerline grid should have a repeat of the number of m2 lines per unit cell. Arvind and I discussed this a while back. Unfortuanately, this doesn't help with the stop point grid. Maybe we need to support triples as well so we can get the (row, grid line in the row, minor grid line of the stop point grid). This should be straightforward to do but might be confusing to use. Maybe we can skip it for now (add an issue so we can remember to look at it later) since we shouldn't need to manipulate stop point grids very often (for example if we use ASCII diagrams.)

The triplet does sound easy to implement. And I think usage should be pretty straightforward as well in case the cell height is an integral multiple of relevant metal pitches. My main concern is what happens in case of a non-integral repeat. We can error out of course and force the user to specify a valid cell height. But this might be hard to do for all layers without making the UnitCell too big.

Alternatively, we could just pick one layer (such as M2) like we had done in our previously. If its just one layer though, we could think of some mechanism to override the default repeats as well... As in construct the DefaultCanvas with repeat = 1 & provide some mechanism to override the repeat.

ReadLEF.cpp: ReadLEF
interMetals.resize(interMetals.size()+1);
interMetals.back().metal=temp[1];

This is dangerous programming style. It requires that you resize correctly. In one later case, parsing 'LAYER', the resize was entirely forgotten. back() referred to a bad memory location. This resulted in a seg-fault but only when not running gdb, so very difficult to find. We should not see memory errors when using C++ properly.

The right way to code this is to create a temporary structure and then append it, which eliminates any chance of an allocation error.
PnRDB::contact tmpCon;
tmpCon.metal = temp[1];
interMetals.push_back(tmpCon);

This bug was found using valgrind which showed a bad write at line 91 where a back() call was made. A seg-fault happened only because the back() call happened on a zero length -- otherwise only bad behavior would be observed and valgrind would not have detected (we would have overwritten another contact).

We should probably eliminate any use of back() used on the LHS.
``

Needs #208 to be resolved first

Cell_Fabric_FinFET__Mock still contains too many files with a lot of duplication (see https://app.codacy.com/app/ALIGN-analoglayout/ALIGN-public/pullRequest?prid=3783741).

Areas for improvement include:

1. Currently, gen_gds_json and gen_lef have technology dependent parameters
   (e.g. list of layer number and via sizes) and are therefore duplicated in the MockPDK directory. Need to figure out how to reuse the base classes in Canvas.
2. There is still a lot of duplication among the fabric_* files based off of CanvasNMOS. It should be possible to merge all the command line tooling into a single file with an additional parameter (Primitive Name).
3. Module imports need to be relative or based off of the CellFabric package itself. Where to store the MockPDK may also warrant additional discussion.
4. The generator classes are all called "UnitCell". Might be better to rename them based on purpose.

This is mainly refactoring work. Not very high priority at the moment so creating a new issue to resolve later.

@Lastdayends

This issue still exists.
I think the Mock PDK JSON is correct.

This shows up in the PnRDB for all m3 wires with v2 connections.

The telescopic_ota examples/ shows this.

Here is the list that UMN thinks are needed to run the make flow locally (from Trello).

Let's start a conversation about whether this is enough or why the current documentation is inadequate.

@desmonddak @meghna09 @kkunal1408 @arvuce22

They are both technology specific right now (gen_gds_json partially reuses JSON layer info). Moving all the data to the JSON & making these technology agnostic would be preferable.

The scaling factor (4) is dependent on process and should be included in the PDK json.
Probably need to do something similar for LEF.

I am not quite sure where the following primitive generators are being used:

1. fabric_CMB3_NMOS.py
2. fabric_CMB5_NMOS.py
3. fabric_Res.py

We should either be testing these modules or removing them from the codebase.

Feels like fabric_CMB* needs to be collapsed into a more generic primitive generator & fabric_Res needs to be tested.

@arvuce22 Can you please look into this? At the very least, every MockPDK primitive generator should have simple tests that perform LVS & DRC (See FinFET14nm_Mock_PDK/test_all.py::test_ALL)

The cell generation and PnR has features to do multiple connections we need them to be integrated in the full flow. The multiple parts within this issue are:

1. Definition be designer
2. Passing it through subcircuit identification
3. How to pass parameters to cell generation.
4. AT PnR stage what happens if the width required by no of routes required is more than given width of the cell pin.

Venc enclosures have definitely evolved.

There may be other parameters that need documenting as well (for example UnitR & UnitC)

Required for parasitic extraction

[ ] Need to specify rules (min space and min length)
[ ] Engine to check rules (simpe)

There are two parameters for height in ALIGN_primitives.py right now: nfin & height. height currently defines the unit cell height & nfin is supposed to define the variable cell height within the unit cell (unused right now). Needs to be fixed at some point.

Parijat has created some new leaf cells with M3 terminals and the global router seg-faults.

The bug is in Bugs/telescopic_ota with a RUNME. The router should not fault but should report an error (in this case, I think it is a net that has no source)?

I supplied the inputs/ directory so you should be able to run pnr_compiler on these inputs and reproduce the bug.

We should try & get as many dissimilar PDKs as we can. For example, an older bulk technology node and a dissimilar FinFET node. Intentionally creating PDKs to excite corner cases such as misaligned M1 / M3 layers is also an option.

@Lastdayends It seems that this testcase takes a long time to run. A lot of time is spent in the detailed router in what I think is the dijkstra routine.

We should implement Built-in spice types like NMOS, PMOS in primitive generation code to ensure we catch escapes from sub_circuit_identification.

@arvuce22 @kkunal1408 @meghna09 can you come up with a simple example circuit that sub_circuit_identification will not have primitives for so that this path can be exercised & tested?

It would be nice if the container supported Xyce and gnuplot as well since we will eventually need it for post layout simulation (See Dockerfiles in https://github.com/stevenmburns/XyceBuild)