missing files for openframe

[marwaneltoukhy]

Missing files for openframe:

1. verilog/gl/caravel_openframe.v
2. gds/openframe_project_wrapper_empty.gds

NOTE: When trying to generate openframe_project_wrapper_empty.gds from openframe_project_wrapper.mag it is not the same as the default def file for openframe_project_wrapper

[RTimothyEdwards]

@marwaneltoukhy : (1) I do not know why we even have versions of caravel.v and caravan.v in verilog/gl/, since the RTL is only structural and the gate level netlist is funtionally and structurally the same. However, if you need a separate gate level netlist for caravel_openframe, then you will need to make one. Yosys was used to create the gate level netlists for caravel.v and caravan.v, and I don't know how that was done. Presumably you know?

(Will answer (2) after I investigate.)

[marwaneltoukhy]

@RTimothyEdwards It is needed for consistency check in precheck. I will work on (1).

[RTimothyEdwards]

@marwaneltoukhy : By "default def file for openframe_project_wrapper", do you mean the one that is in caravel_openframe_project/openlane/openframe_project_wrapper/fixed_dont_change/? It looks like I failed to include blockages when I wrote that file. But the version in the caravel repository has metal layers where there are pins in the caravel_openframe cell that extend into the user project area but are not pins that connect to anything. Whether or not they exist in the user project wrapper GDS is irrelevant as long as they aren't shorted by routing. But the DEF file in the project example definitely should have contained blockages.

[marwaneltoukhy]

This is a sample of the XOR difference between the example we taped out (done by the default def file) and the gds I produced out of caravel/gds/openframe_project_wrapper_empty.gds. These are shapes highlighted are metals that don't have a pin on top.

[RTimothyEdwards]

@marwaneltoukhy : Yes, I'm aware of that. Did you not read my last post? The DEF file needed to include blockages. I will need to update the DEF file. I did do a spot check and the router fortunately went straight in on all the pins and didn't short to any of the metal lines that should have been blockages.

If you want the design to be taped out to pass an XOR check, it would be necessary to start with the original empty wrapper GDS rather than try to re-create the layout from the DEF file. There are several ways to go about it that I can think of, all pretty much equivalent. It's just necessary to keep in mind that the situation is slightly different from the original Caravel and Caravan user wrappers because there are metal shapes that cross the wrapper boundary that are not wrapper pins and therefore must be treated as blockages.

[marwaneltoukhy]

If these aren't pins, and they shouldn't be connected to anything, then why are they in the mag file for the empty wrapper? OpenLane would have issues with that, and therefore the XOR will always fail.

[RTimothyEdwards]

They're in the empty wrapper .mag file because I use that to create the DEF file with the blockages. If you remove those shapes from the empty wrapper, then anybody manually wiring up something inside the wrapper won't know that there are blockages there that they need to avoid.

I think that the problem, though, is that those shapes were previously missing from the DEF file. I updated the DEF file yesterday to include those shapes among the blockages. I don't know how those will translate back to GDS---Maybe they won't. Maybe the solution is to swap out the wrapper cell created by reading the DEF for the original wrapper layout, which is easy enough to do.

[RTimothyEdwards]

@marwaneltoukhy : Also need gl/chip_io_openframe.v. These missing files are rising to the level of urgency. Please create the gate level netlists and commit them ASAP.