https://open-source-silicon.dev logo
Join Slack
Powered by
embedding analog design to caravan for the first t...
# analog-design
a
embedding analog design to caravan for the first time
👍 2
hi everyone, I've am working with a group of students within the UNIC-CASS program (a tape-out in collaboration with IEEE Circuits and Systems Society and efabless), and I it seems I am failing to wrap my head around getting our design into the caravan. The design is a simple DAC, and I wanted first to make sure I understand the process before I try including the whole DAC. Hence I tried wth the simplest of subcircuits, 
dac_cell1
- just four transistors and one resistor. This cell is DRC and LVS clean (checked in local computer) and I gave my best shot in getting it into the caravan by: 1. instantiated symbol of our cell into 
xschem/user_analog_project_wrapper.sch
using Xschem 2. connected it to pins like 
vdda1
, 
vssa1
(hoping that's the GND), and then 
io_analog[0]
etc. 3. instantiated layout (
.mag
) of our cell into 
mag/user_analog_project_wrapper.mag
using Magic 4. connected ports of our cell to various pins in layout, just the same like in schematic, see image attached
However, when I try to do LVS check in local, this is what I get:
Copy code
Contents of circuit 1:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 8 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   4
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 16 nets, and 9 disconnected pins.
Contents of circuit 2:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 8 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   4
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 10 nets.

Circuit was modified by parallel/series device merging.
New circuit summary:

Contents of circuit 1:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 2 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   1
Circuit contains 15 nets, and 6 disconnected pins.
Contents of circuit 2:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 5 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 9 nets.

Circuit 1 contains 2 devices, Circuit 2 contains 5 devices. *** MISMATCH ***
Circuit 1 contains 6 nets,    Circuit 2 contains 9 nets. *** MISMATCH ***

  Flattening non-matched subcircuits dac_cell1 dac_cell1

Flattening instances of dac_cell1 in file ../mag/user_analog_project_wrapper.spice
Flattening instances of dac_cell1 in file ../xschem/user_analog_project_wrapper.spice

Contents of circuit 1:  Circuit: 'user_analog_project_wrapper'
Circuit user_analog_project_wrapper contains 12 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   1
  Class: sky130_fd_pr__res_generic_m3 instances:  10
Circuit contains 35 nets, and 652 disconnected pins.
Contents of circuit 2:  Circuit: 'user_analog_project_wrapper'
Circuit user_analog_project_wrapper contains 5 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 9 nets, and 656 disconnected pins.

Circuit 1 contains 12 devices, Circuit 2 contains 5 devices. *** MISMATCH ***
Circuit 1 contains 26 nets,    Circuit 2 contains 9 nets. *** MISMATCH ***


Final result: 
Netlists do not match.
Logging to file "comp.out" disabled
LVS Done.
Please note this is only one of the subcells of our, much larger design - I wanted to start with the simplest piece, so that's why there are only 4 transistors. Note, further, how netgen detects some resistors in the layout somewhere... I did not make them, nor they exist in our cell... Could it be that they remain somehow from that power-on example? Also, note how in the beginning netgen successfully recognizes 4 transistors in both the schematic and layout, but then, for some reason, merges transistors in the layout extracted netlist, although they are obviously not paralel nor series, rather independent devices... Why does this happen? For completeness, here is the command I used for netgen:
Copy code
netgen -batch lvs "../mag/user_analog_project_wrapper.spice user_analog_project_wrapper" "../xschem/user_analog_project_wrapper.spice user_analog_project_wrapper" /opt/open_pdks/sky130/sky130A/libs.tech/netgen/setup.tcl
Finally, since I wasn't able to push to efabless repo today (couldn't pass the login screen all day long), I pushed now to the github repo - please check files there: https://github.com/apaj/UNIC-CASS_precheck_dac
@Tim Edwards and @Mitch Bailey do you think you could spare some time to take a look and let me know what am I doing wrong here?
For completeness, I just did another push to the github repo with lvs check of 
dac_cell1
alone, i.e. 
dac_cell1.sch
vs 
dac_cell.mag
only to point out that netgen works fine and our design is DRC and LVS clean. If anyone clones the repo, here's how to repeat that result (from the 
netgen
directory):
Copy code
netgen -batch lvs "../mag/layout_cell1/dac_cell1.spice dac_cell1" "../xschem/dac_cell1.spice dac_cell1" /opt/open_pdks/sky130/sky130A/libs.tech/netgen/setup.tcl
and the output:
Copy code
Contents of circuit 1:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 8 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   4
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 10 nets.
Contents of circuit 2:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 8 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   4
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 10 nets.

Circuit was modified by parallel/series device merging.
New circuit summary:

Contents of circuit 1:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 5 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 9 nets.
Contents of circuit 2:  Circuit: 'dac_cell1'
Circuit dac_cell1 contains 5 device instances.
  Class: sky130_fd_pr__res_xhigh_po_0p69 instances:   1
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   4
Circuit contains 9 nets.

Circuit 1 contains 5 devices, Circuit 2 contains 5 devices.
Circuit 1 contains 9 nets,    Circuit 2 contains 9 nets.

No more changes can be made to series/parallel networks.

Final result: 
Circuits match uniquely.
.
Logging to file "comp.out" disabled
LVS Done.
t
@Aleksandar Pajkanovic: So I understand that you can run LVS on 
dac_cell1
alone but not 
user_analog_project_wrapper
? I can take a look at it.
a
Yes, that's exactly the point: I prove the circuit (
dac_cell1
) itself is DRC and LVS clean and I am pretty sure I connected it (not very pretty but) electrically correct within the 
user_analog_project_wrapper
However, I am getting some strange extra resistors after layout extraction... By the way, extraction I do with:
Copy code
extract all
ext2spice lvs
ext2spice
t
I can see the problem in the 
user_analog_project_wrapper.spice
file, because the subcircuit definition of 
sky130_fd_pr__pfet_g5v0d10v5_FGUWVM
has no pins. I am unable to repeat the problem on my end. I think it probably has something to do with your version of magic, which appears to be a bit out of date, as it is generating output like 
w=1e+06u
(which has more recently been improved to read 
w=1.0
now). By doing an extraction with my own version of magic, the 
dac_cell1
matches at the top level, and the only issue with the top level is that the metal3 resistors that separate the nets in the layout are missing from the schematic and need to be added.
(FYI, just for the record: This won't make much difference for a small design like this one, but I recommend doing 
extract no all
before 
extract all
when extracting for LVS, since it skips all the parasitic capacitance calculations. For large layouts that can get very compute-intensive.)
👍 1
a
(always enjoying the logic behind magic commands 🙂 ) Regarding those resistors... I remember there were some in the 
por_example
schematic - but I deleted them, I thought they were part of the example... Am I understanding you correctly, @Tim Edwards, should I have kept them in the schematic?
(goes and updates magic silently)
t
Probably the metal3 resistors just need to be deleted from the layout, as they are still sitting on the 
clamp_io_low
and 
clamp_io_high
pins.
Also small ones on 
io_oeb[16]
io_oeb[15]
, 
io_oeb[12]
, and 
io_oeb[11]
.
a
Ok, so these are not some sort of requirement for the 
caravan
as a project, great. Actually, I wasn't able to locate them - I didn't realize where they were... never occurred to me to look for an analog of 
findlabel
, something like 
finddevice
or similar... I'll take a look. Anyway, thanks, I'll do that and will be back soon. Thanks!
t
try `snap int; select area rm3; box values {*}[select bbox]`; the 
rm3
layers will now be at the box corners.
They are a requirement if you short two or more pins together, to keep the pins on separate nets. The example tied the GPIO 
oeb
pins to ground or 1.8V power to turn them permanently on or off, not bothering to use logic gates; so then a metal resistor has to be placed or else the 
oeb
pin gets absorbed into the power or ground net, disappears, and shows up as a port error in LVS.
a
Right, ok, thanks, that makes sense. However - where are they:
I don't see anything in this image at 
io_clamp_low[0]
to delete - there's just a piece of metal3 that leads to nowhere...
I take that back. Found them
Sorry, I was impatient. Getting late around here 🙂
t
Yes, they're a little hard to see. Sorry about the choice of colors/patterns.
a
Yes, but there is almighty 
see no *
<== yet another example of great syntax 🙂
t
If you want to speed it up, then: Your schematic has 
vsw
on 
io_analog[7]
and 
iref
on 
io_analog[4]
but your layout has 
vsw
on 
io_analog[3]
and 
iref
on 
io_analog[7]
. Once you remove the m3 resistors, that's the only error in the layout (or schematic, since modifying the schematic to match is probably easier).
(I didn't make up that syntax. Blame John Ousterhout, maybe?)
a
Dear Tim, the only thing you can be blamed for is enabling the next stage of human society where the most sophisticated technology commercially available on this planet is brought at the doorstep of every school, every university, even every home. These are just small jokes, I hope you don't mind, but to you nothing but eternal gratitude in the name of every electronic student/engineer/enthusiast/entrepreneur. Thank you.
t
I'll take that comment with a good dose of grace. You're very welcome!
🙌 2
a
To conclude, let me just point out I got the clean LVS. Thanks, again, @Tim Edwards. p.s. If you get around at some point, could you explain this piece: 
box values {*}[select bbox]
?
t
Well, your solution of 
see no *; see rm3
is a lot better. But for the obscure command above: 
select bbox
returns the coordinates of the bounding box of the selection. The value is a Tcl list, but 
box values
takes four individual values, not a list, so the 
{*}
expression expands the list (a quirky shorthand introduced in a fairly recent Tcl version).
👍 1
a
image.png
👍 1
Thanks!
t
@Aleksandar Pajkanovic: By the way, after looking at your layout, I would like to point out that the analog pads on Caravan have no ESD protection. So where you have wires running from an unprotected pad to only a FET gate, that gate will be very sensitive to being destroyed by static electricity. Without a path to ground or power, the pad can easily build up several thousand volts. I would recommend adding diodes internally to protect those gates.l
👍 1
This kind of structure:
👍 1
Could be done like this:
👍 1
Please be aware that I took all of 10 minutes to create the layout above, and it's unverified, but here are the files:
esd_structure.tgz
👍 1
a
hi @Tim Edwards, thanks. We'll look into this, but let me use this opportunity for a quick question - I am on something right now and we couldn't get this figured out, although sounds terribly trivial... How the hell do I get the other contact of mimcap3?
image.png
t
Which contact do you have?
a
Lefthand side comes out nicely in LVS, I just approached with metal3
Looking at the layer stack, I was expecting that I can connect to mimcap from M4 by placing a via3, but Magic tells me I am not allowed to overlap via3 with mimcap...
so I tried with M4 coming from the right hand side, but the label doesn't show up in netlist extracted from layout
t
I see. So in the above picture, you have two connections to the bottom plate. The problem with MiM caps is that they act like antenna diodes, so it's usually not a good idea to connect downward from the bottom plate (although there is no specific rule about that in the sky130 PDK). The contact on the right side connects the bottom plate up to metal4 so that you can connect the bottom plate out on metal4 (your connection to the right). To connect to the top plate, just draw a wire on metal4 from the center of the cap out to the left.
(sorry, confused m4 and m5. . . let me correct the statement above) (fixed)
mimcap_connects.png
👍 1
a
Yes, got it, thanks!
hi @Tim Edwards, hopefully this is the last question... I am failing to make sense of netgen output... We definitely have something wrong as I see that 
sss
selects both 
gnd
and two more nodes in layout... but watching this output... I don't see anything that could help me conclude where in layout, which box, to look for the unwanted cross. Is it even supposed to produce something like that?
comp.out
comp.out
t
The issue appears to start here:
Copy code
sky130_fd_pr__pfet_g5v0d10v5 (3)           |sky130_fd_pr__pfet_g5v0d10v5 (26->1) **Mismatch**
sky130_fd_pr__nfet_g5v0d10v5 (5)           |sky130_fd_pr__nfet_g5v0d10v5 (14->3) **Mismatch**
In the layout (right-hand side), the pFETs have all been combined in parallel; after parallel combining, there is only one pFET and three nFETs, compared to three pFETs and five nFETs in the schematic. I can't tell more without looking at the layout or netlist.
a
This 
.spice
is a netlist from xschem
But wait, you need all the friends of the layout... just a second
miel21_opamp.tar.gz
miel21_opamp.tar.gz
We've created fingered transistors, imported into Magic, and then manually changed property of every one of them so that their diffusions don't overlap
I insisted that the students do LVS as they go, and everything was going pretty well, but at the latest iteration, the design went bananas - somehow everything is connected to ground and, hence, they all get merged...
t
Here's a hint: On the layout, if you do 
sss
on the power net, you'll see that you have a power/ground short. With that selected, do: 
select short power ground
. That reduces the selection to a single path (not necessarily the shortest) between power and ground. From that, you can see that the short is across device instance XM5.
a
Strangely enough...
t
Because you have stripes of both metal1 and metal2 horizontally across XM5, and the metal1 is shorting all the sources and drains together. This is true of a number of FETs, and is because the FET is drawn by default options with an 
mcon
contact covering both source and drain from top to bottom.
I should have clarified that all device instances need to be expanded for the "select short" command to work properly.
a
Ahh, you mean metal 1, not metal 3
I see it now...
t
(Yes, sorry, I have some context-switching problems going constantly between gf180mcu and sky130!) (fixed)
a
Ok, but, in general - was my assumption correct - after reading around on how to understand output LVS - I did not find any way it points to a location in layout where a short might be happening?
t
Often what I do is to adjust the way the mcon contacts are drawn in the device so that the contacts on the sources only cover half of the transistor width, and the contacts on the drains cover the other half, so that I can put a metal1 stripe across the top and bottom like you did. The trick is that in the dialog for the FET device generator, set "Source via coverage" to "+50" and set "Drain via coverage" to "-50" (the "+" and "-" characters are significant, as they cause the resulting via to be aligned to the top and bottom of the transistor, respectively). Of course, since you already have metal2 across these devices, you can just remove the metal1 between the device fingers.
🙌 1
a
Thanks so much, again 🙂
t
The LVS algorithm does not have any understanding of the physical layout; it only looks at the netlist, and the netlist does not specify the position of anything in the layout. It's necessary to see from the LVS report that there is a power/ground short, and then (manually) go back to the layout to trace the short. In principle, both netgen and magic can operate under the same Tcl interpreter and I could add scripts that would allow you to do all that automatically from an LVS GUI. One day I might get around to writing that. . .
a
hi @Tim Edwards, we have successfully completed 
user_analog_project_wrapper
layout and 
drc check
with style 
drc(full)
passes successfully in our local server. After that, I've created gds by simply doing 
gds write user_analog_project_wrapper
. However, the 
precheck
job returns DRC violations... It seems that something is off-grid... but how if 
drc check
in magic showed it's a clean design?
Please find attached output from precheck and the whole project is available in github, here.
logs.zipoutputs.zip
While my wish is not to cross-post, in an attempt to come to the answer sooner, I've asked the same question in the 
UNIC-CASS
slack workspace, here. Sorry, this is our first time submitting for analog caravel tape-out and I am having trouble understanding all the processes happening around the submission. Wherever we understand the issue sooner, I'll also forward the solution to the other thread. Thanks for understanding.
t
This is probably a good issue to post in multiple places. For magic, the answer is that it is really difficult to place something off-grid, because magic has a database format that is itself aligned to the grid and is unable to represent off-grid elements by definition (it can be done only with non-Manhattan shapes in overlapping subcells). I will take a look at the logs and see if I can figure out what's going on.
The reports show an issue with the via.1a rule which I will look at. The other issue is XOR, which problem could exist on either end. I don't know exactly what's being done for the XOR check in the precheck. It is supposed to make sure that nothing in the user design will conflict with the openframe padframe. The check has to be done just right.
a
Hmmm... I just remembered something...
Could be due to missing a piece of metal 3 in the padframe?
I just remembered that two of the analog ios, were shortcircuited to the clamps, and then a very rudimentary separation was done
image.png
I didn't like how that was done, but 
drc check
didn't complain so I let it be
t
@Aleksandar Pajkanovic: That's not the issue. The bounding box of the error is (587.7, 3520) to (2326.97, 3520.53). Nothing in the user design should be above the line at Y=3520um except for the pins (which match the underlying caravan layout). There are a few places (three, I think?) where the metal3 extends above this line.
(587.7, 3520) to (635.14, 3520.54) (1645.97, 3520) to (1646.47, 3520.24) (2234.53, 3520) to (2326.97, 3520.53)
a
Hm... That would make sense actually, because what I did was select the 
user_analog_project_wrapper
and ask it to do 
drc check
Obviously, if there's an issue out of the box, then, it wouldn't have caught it
Crap, I seriously did not expect things out of the design boundaries
t
This is the error with via1. There is a subcell in the dac_cell1 that duplicates the via1 cuts at an offset. I need to figure out why magic didn't report that as an error.
In the middle of the via1 array underneath the label "iref" there are four additional contact cuts at an offset. (This is the view using the 
sky130A-GDS.tech
technology file; it gives a view of the actual GDS layers.)
a
Ah, ok, so the error is actually in the dac_cell1, and then it propagates since we instantiated the thing
t
It occurs to to me that the via1 error is not something that magic can catch by DRC; this type of error would be caught when generating GDS and you should have gotten a "parent and child disagree on CIF" error.
a
No, nothing like that - it just said that there were a number of warnings... That might have been it, then
Ok, found those places and removed metal 3, kept the line though
Could you please screenshot the part of the log/output that led you to conclude this? Trying to learn how to fish :)
Also, I tried things like 
select metal3 at 1645.97 3520
but it didn't work... Is there a way to tell in the magic console where I want the selection, irrelevant of the material?
And yet another question - why don't we see the small cuts in the 
m2c
layer? Is there a way to turn that on?
t
(Sorry, I was on a call and couldn't answer the questions as they were arriving.)
a
(Please do not apologize, you are making me even more uncomfortable for troubling you with so many questions, I am the one to apologize - the deadline is approaching fast and I am getting nervous 🙂 )
Regarding the 
iref
I see now there is an extra 
viali
in the same location, as well... It probably has nothing to do with any of the errors, but still, kicking it out
t
(1) For the metal selection: You're close; the commands would be 
box position 1645.97um 3520um ; select
(2) The cuts can be seen either by reading the GDS with 
magic -T $PDK_ROOT/sky130A/libs.tech/magic/sky130A-GDS.tech
. In the layout with the usual tech file, you can do `cif see VIA1`; however, that does not show the error because it flattens the area first so the problem with the subcell disappears (hmmm, there should be a way to do that properly, but that's software development work).
👍 1
As far as finding the errors: Ideally, I would run klayout and load the XML files. Instead, I just looked into the XML files, discovered that there are entries with the text "polygon" only where errors are being reported, and looked through the sections with the text "polygon" to figure out what rule was being flagged. So I was doing it the hard way.
a
Right... klayout. I was kind of hoping that the precheck process will take its place - i.e. that I won't have to install it 🙂 I was wrong, let's say. I'll just go ahead and get it running, after all
Strangely enough, when I've opened 
dac_top_cell.mag
now it is showing up!
I swear it wasn't there last night! We checked twice at least...
Ok, I think I got them all for now, so re running the precheck...
Ok, seems improved, but still some more. I'll try to track these related to pins, but what is the XOR thing?
logs.zip,outputs.zip
outputs.ziplogs.zip
m
@Aleksandar Pajkanovic Looks like there are 3 fatal errors.
Copy code
2023-10-23 07:28:07 - [CRITICAL] - {{FAILURE}} 3 Check(s) Failed: ['XOR', 'Klayout BEOL', 'Klayout Pin Label Purposes Overlapping Drawing'] !!!
XOR
is a check to verify that nothing relevant has changed in the 
caravel_core
- 
user_analog_project_wrapper
interface. The 
xor_check.log
show that there are 4 differences on the 
70/20
(
metal3/drawing
) layer.
Copy code
--- Running XOR for 70/20 ---
"input" in: xor.rb.drc:39
    Polygons (raw): 188 (flat)  188 (hierarchical)
    Elapsed: 0.000s  Memory: 548.00M
"input" in: xor.rb.drc:39
    Polygons (raw): 184 (flat)  184 (hierarchical)
    Elapsed: 0.000s  Memory: 548.00M
"^" in: xor.rb.drc:39 
    Polygons (raw): 4 (flat)  4 (hierarchical)
    Elapsed: 0.000s  Memory: 548.00M
XOR differences: 4
"output" in: xor.rb.drc:43
    Polygons (raw): 4 (flat)  4 (hierarchical)
    Elapsed: 0.000s  Memory: 548.00M
You can check these by reading 
user_analog_project_wrapper.xor.gds
The second error 
Klayout BEOL
is a drc error from the back end rule deck. Looks like there are some 
via
rules violated. This is the marker file you can load in klayout.
Copy code
outputs/reports/klayout_beol_check.xml
The third error 
Klayout Pin Label Purposes Overlapping Drawing
is actually a check for pin/label shapes that are NOT inside drawing layers. These are not mask layers but are extracted as if were. If you have pins outside of drawing layers, they can cause nodes to be connected when extracting but will not be when the device is actually made. See 
klayout_pin_label_purposes_overlapping_drawing_check.log
Copy code
13 70/16: met3, pin/label not-over drawing:70/20
         ----         met3:70/20/dat    70/16/dat     70/5/EMP
         ----         via3:70/44/dat    70/48/EMP
       4 71/16: met4, pin/label not-over drawing:71/20
         ----         met4:71/20/dat    71/16/dat     71/5/EMP
         ----         via4:71/44/EMP    71/48/EMP
       4 72/16: met5, pin/label not-over drawing:72/20
         ----         met5:72/20/dat    72/16/dat     72/5/EMP
         ----          pad:76/20/EMP     76/5/EMP    76/16/EMP
         ----          pnp:82/44/EMP    82/59/EMP
         ----          npn:82/20/EMP     82/5/EMP
         ----          rdl:74/20/EMP    74/16/EMP     74/5/EMP
         ----     inductor:82/24/EMP    82/25/EMP
      21 total error(s) among 3 error type(s), 33 checks, cell: user_analog_project_wrapper
The marker database is at 
outputs/reports/klayout_pin_label_purposes_overlapping_drawing_check.xml
a
hi @Mitch Bailey , thanks. I am trying to set up KLayout so I can fight these directly, so could you just please take a look at this setup:
Is there anything else I need to install/run/set in KLayout to get it going?
I mean, to be sure it's checking everything it needs to check...?
m
The actual checks are done in docker. You’ll just be using klayout to view the results. It helps if you have access to the pdk files, though.
a
ah... ok... so... wait... Is it the openlane container?
m
The checks are done in an openlane or precheck container. You view the results in your local klayout.
a
my idea was to use KLayout and open the 
logs
and 
output
I got from efabless precheck - does that require the container or it can be done via KLAyout directly?
right, ok, then, thanks
so I am good to go to take a look at 
logs
and 
output
from efabless platform precheck
👍 1
hi @Mitch Bailey and @Tim Edwards, thanks for the comments. I managed to track down all the issues - KLayout was quite intuitive here and precheck is passing now.
👍 1
t
Good to know! I need to learn how to use klayout better myself. I was stymied for a while by being unable to get it to compile in my environment, and then by figuring out how to enable a specific technology. After getting over those two hurdles, it's quite a nice tool, and probably feels way more intuitive than magic to people who have used any commercial layout tool before.
a
To be honest, it's been so long since I started Virtuoso, that am not even sure I remember all the stuff anymore... I remember that the version 5 of cadence tools had the ugliest interface I ever saw, and then 6 was a terrible attempt to correct that, trying so hard to make it pretty... Anyway, I used KLayout just once prior to this (back in 2020 tape-out with XFAB, thanks to Niels Mosly and @Edmund Humenberger) and this was a nice refreshment. Once I learned how to open up the XMLs, it was a breeze to find the errors. Next thing for us to learn is how to get the precheck and tape-out jobs done in local machine - like @Mitch Bailey explained, in the container. Anyway, we are working now on the ESD protection, like you advised, hopefully we'll finish everything in the next day or two. Thanks guys!
42 Views
Open in Slack
PreviousNext
Powered by