In mpw-4/slot-001, the layout has 35

EP_gpio_defaults_block_0403

and 1

EP_gpio_defaults_block

while the verilog netlist has 3

gpio_defaults_block_0403

and 33

gpio_defaults_block

Are these blocks electrically equivalent or is this a non-issue for some other reason?

@Mitch Bailey (@Matt Venn): The block is parameterized in RTL verilog, but any parameterization applied in verilog doesn't translate to the gate level (unless that verilog is subsumed into a larger block through synthesis). So to get the user-definable defaults, every different set of parameters passed to the block in RTL verilog has to translate to a new gate-level block in verilog, and a new layout cell, each with a unique name. There is a script in caravel called

scripts/gen_gpio_defaults.py

which needs to be run when the chip top level is assembled, which reads the file

user_defines.v

(there is a default one in

caravel/verilog/rtl

, but if there is one in the user project it is preferred, which is how the user can override the power-on defaults of the GPIO blocks). The script should modify both the gate-level verilog and the layout to create multiple unique versions of the

gpio_defaults_block

for each unique configuration found in

user_defines.v

. If the script has been run correctly and has done its job correctly, then the layout and the gate level verilog should match. So from the above, it looks like the layout was converted with the script, but the gate level verilog wasn't.

But this only should affect defaults? So it's not a big issue. Worth opening an issue anyway?

Thanks for the response, Tim.

@Matt Venn: Yes, it would only affect defaults. But yes, it's worth opening an issue, just to figure out why the GL verilog appears to have reverted back to the original while the layout appears to be correct with respect to applying the script.

@Mitch Bailey would you mind? I don't really understand it

Ok. I'm looking at mpw-4, slot-002 now. I'll compare the results. Should the issue be on efabless/caravel repo?

I think so.

So I was using the default

caravel.v

from the caravel repo because I couldn't find that file or the other caravel verilog files in https://foss-eda-tools.googlesource.com/third_party/shuttle/mpw-four/slot-001. @jeffdi Tim says the

caravel.v

file should be automatically modified with

user_project_wrapper

integration based on the values of

USER_CONFIG_GPIO_*_INIT

. Specifically, the instances of

gpio_defaults_block

should be changed to reflect the values of

USER_CONFIG_GPIO_*_INIT

. Also won't

user_id_programming.v

be different for each design too? Are these modified versions of

caravel.v

and

user_id_programming.v

available for designs that have taped out?

@Mitch Bailey: Yes, the

caravel.v

and

user_id_programming.v

are modified by the script. Note that the magic view of

user_id_programming

has a GDS_FILE property in it, so there is no specific need to touch the layout except for LVS if you don't black-box it. When you say "the only difference is gpio 34", are you referring only to

slot-001

?

@Tim Edwards So far I've checked mpw4

slot-001

and

slot-002

. They both appear to use

gpio_defaults_block

(

0402

) for gpio 34 for some reason.