Hello, I'm using the analog wrapper. During my precheck, I encountered two errors: OEB and consistency. How can I correct these? I manually routed connections from my design to the wrapper.

Have you used following command to run precheck?

MPW_TAG=mpw-9j make precheck
make run-precheck

it is on the plateforme

user_defines.v

updated right as per GPIO connection?

I can share you my user_defines.v

you've to use valid values from https://github.com/efabless/caravel_user_project_analog/blob/main/verilog/rtl/user_defines.v only.

// Authoritive source of these MODE defs is: caravel/verilog/rtl/user_defines.v
// Useful GPIO mode values.  These match the names used in defs.h.
//
`define GPIO_MODE_MGMT_STD_INPUT_NOPULL    13'h0403
`define GPIO_MODE_MGMT_STD_INPUT_PULLDOWN  13'h0c01
`define GPIO_MODE_MGMT_STD_INPUT_PULLUP    13'h0801
`define GPIO_MODE_MGMT_STD_OUTPUT          13'h1809
`define GPIO_MODE_MGMT_STD_BIDIRECTIONAL   13'h1801
`define GPIO_MODE_MGMT_STD_ANALOG          13'h000b

`define GPIO_MODE_USER_STD_INPUT_NOPULL    13'h0402
`define GPIO_MODE_USER_STD_INPUT_PULLDOWN  13'h0c00
`define GPIO_MODE_USER_STD_INPUT_PULLUP    13'h0800
`define GPIO_MODE_USER_STD_OUTPUT          13'h1808
`define GPIO_MODE_USER_STD_BIDIRECTIONAL   13'h1800
`define GPIO_MODE_USER_STD_OUT_MONITORED   13'h1802
`define GPIO_MODE_USER_STD_ANALOG          13'h000a

Ok and for open pins what do I ?

check this thread: https://open-source-silicon.slack.com/archives/C01E06TUSC9/p1691744880377679

Is there a report?

@Charly Meyer plz share reports directory as well for precheck run

@Charly Meyer Did you connect the OEB (Output Enable Bar) lines for the IOs that you are using?

I don't know what is mean ? I do that, the yellow is VDD and pink the signal, may be I need to reverse it . no ?

I think this is reversed, the

io_in

is the signal IO, and the

OEB

is to enable or disable the output. so if you want to use it as input the

OEB

should be tied to 1

@Charly Meyer If you want the GPIO to be a dedicated chip input connect io_oeb to VDD and the signal io_out to your circuit. If you want the GPIO to be a dedicated chip output connect GND to io_oeb and the signal io_in to your circuit.

I will correct that.

@Charly Meyer The OEB check runs on the extracted layout.

Setting power for mode...
ERROR: could not expand signal vccd* signal vccd* not found
ERROR: Could not find net vccd*
ERROR: could not expand signal vdda* signal vdda* not found
ERROR: Could not find net vdda*
ERROR: could not expand signal vssa* signal vssa* not found
ERROR: Could not find net vssa*
ERROR: could not expand signal vssd* signal vssd* not found
ERROR: Could not find net vssd*
...
ERROR: could not expand signal user_clock2 signal user_clock2 not found
ERROR: Could not find net user_clock2
Power definition error

Can you attach the extracted netlist? It should be in

tmp/ext/user_analog_project_wrapper.gds.spice

I’m thinking that the top level may not have ports.

I don't have it

Do you have a

precheck_results

or

mpw_precheck

directory? Under that directory there should be an

outputs

, and

logs

directory and if there were errors, there should be a

tmp

directory too.

tmp is empty

For the local precheck directory or the platform precheck results?

for the local precheck

Can you join a huddle?

Just an FYI @Charly Meyer here is a simplified block diagram of the GPIO.

Are you running LVS in the local precheck or do you have that disabled?

I disable the LVS

Can you enable the LVS? It should fail and leave the files in the

tmp

directory.

It is not possible to run the LVS, I ran the LVS with Klayout in my side without precheck

OK. It may be a little tricky, but can you grab the

user_*project_wrapper.gds.spice

file from the tmp directory while precheck is running?

You said this in previous thread: https://open-source-silicon.slack.com/archives/C01E06TUSC9/p1699201277189489?thread_ts=1699085363.405979&cid=C01E06TUSC9

Hmmm. If CVC(RV) was running, OEB should run too. However, it does use the extracted netlist, so maybe it fails if that hasn’t been created. I’ll look into it.

I generated the netlist with klayout I have this

@Charly Meyer when I looked at the attached extracted netlist, it appears that the top netlist circuit is

ARX_chip

. In order to integrate in to the caravan framework the top gds cell needs to be

user_analog_project_wrapper

(not just the file name) and all the expected ports (and only these ports) need to be extractable (on the top level) in the layout. Would if be possible to see your final project wrapper gds data? @Anton Maurovic (efabless support) the discussion is continuing here.

Thanks @Mitch Bailey!

ad a call yesterday, and I created the netlist. However, for the case of the io_oeb signal (io_oeb[21] in this case), it is connected to vssd2 to have a signal on the output pin. Do I need to connect Vssd2 and io_oeb[21] (and the others) in the netlist to have a good OEB precheck?

@Mitch Bailey can you help?

For analog designs, the current best practice is to insert a generic metal resistor in both the layout and schematic to virtually separate the pins.

My local precheck has finished, and I finally have no OEB errors, but I still have consistency errors. I don't know how to correct them.

@Charly Meyer flattening the whole circuit does allow it to pass the consistency check, but I think you’re going to have problems with LVS.

I also had something weird happen. When I do the precheck, the DRC_magic shows errors corresponding to nothing in my layout. In the end, when it shows which checks have failed, DRC_magic is not included. What should I think about that?

@Marwan Abbas would probably be better qualified to answer that question. I think magic was running recommended, but not necessary drc checks - but don’t quote me on that.

Yes, klayout is the more important check as it is the MR (Manufacturing Rules) check, which skywater requires for the shuttle.

I'm wondering if consistency is needed. With a flat layout, I can achieve it, but concerning the LVS... The problem is that it shows vias as devices and does not find subcircuits of these vias in my netlist.

Right. Flattening the layout is one way to “skip” the consistency check, but it may make the other checks slower or harder. My personal recommendation is to submit the design and fail with consistency. Then have efabless override the precheck to proceed to tapeout.

ok thanks 😉

@Charly Meyer what assistance do you need to finish your submission? @Anton Maurovic (efabless support)

@Charly Meyer are you ready to follow through with @Mitch Bailey’s advice? This would require that you revert your flattening, prove once again that LVS succeeds on our platform precheck (but Consistency will fail), and then you can ask us to override this and push through the tapeout job to ensure the design is validated for fabrication DRC requirements, making it then possible for us to load onto the shuttle for you.