Hello all, while wrapping up two macros with user_...
# openlane
g
Hello all, while wrapping up two macros with user_project_wrapper, I am getting the following error in the 37th Step. It says that there are illegal overlaps in the design. I have attached my log file, config file and feedback files. It would of great help if someone could provide a solution for this.
m
@User Don't know if this is related to your problem but is this variable correct?
Copy code
set ::env(EXTRA_GDS_FILES) "\
	$script_dir/../../gds/gps_multichannel.gds \
	$script_dir/../../gds/analog_macro.lef"
I'd think that you'd want to use
analog_macro.gds
not
analog_macro.lef
.
g
Ohh sorry, I'll check once, by changing it.
@User The problem persists even after changing that
@User @User @User
v
can you share flow_summary.log
g
flow_summary.log
v
Copy code
set ::env(DIODE_INSERTION_STRATEGY) 4
can you try with other diode insertion ?
g
I tried with 0 and 4
v
g
But I updated my PDK just a few days ago, in the issue they have told that the bug has been cleared in an older version of open_pdks
@User Can you elaborate how you had solved that issue?
t
@User: Magic doesn't provide a description of the layer types involved in the illegal overlap. So you would need to look at the layout and check against one of the error bounding boxes specified in the
37-magic_ext2pice.feedback.txt
file, whose values are given in, I think, centirmicrons, so
box 149976 90256 150875 90347
indicates an error at (1499.76um, 902.56um) to (1508.75um, 903.47um).
g
@User: This is one of the box in which overlap occurs. I think the overlap is between two met4 layers. But I am not sure of the reason.
t
@User: The box is centered on one of the standard cell rails and I recall errors similar to this one, which were due to a number of reasons, all having to do with the standard cells, and what libraries and cell views were being used. I'd need to see the same layout with the standard cells expanded (i.e., the problem is on metal1, not metal4. The problem has to be exactly coincident with the error box).
g
@User: When I try to expand, I get a message in the console, Cell sky130_fd_sc_hd_diode_2 is unavailable. It could not be expanded.
t
Where is your installation of open_pdks? Are you running magic with the "-rcfile" switch?
g
No, I am not running with -rcfile switch
t
In that case you don't get the paths set for magic to find the standard cell libraries, so it can't expand any of the cells.
g
@User: I expanded with rcfile switch, there were no standard cells in those error boxes, but some rails were passing through those boxes. But those rails had no illegal overlaps. And one more important thing is that many of the overlap error boxes were outside the user_project_area, in the empty area. Attaching one such empty area error box image, and zoomed in version of that.
t
I'm not sure what's going on with the error boxes that are outside of the user project area, but if there are drawn power rails with no standard cells underneath, then your synthesis is wrong, because the layout should be filled completely with standard cells.
g
@User: Actually this was for wrapping two macros and so the synthesis step in this flow was fairly simple. The topmost verilog file just had two instantiations with each of its pins connected to the IO ports.
Is there a way to find out the error in the synthesis as you mention?
Because the flow didn't show any errors
t
I'm not sure that's the problem because I haven't seen the layout with all cells unexpanded.
g
@User: Just to Clarify, For the ChipIgnite Program, we are in need to integrate two analog and One digital macro into the User Project Area. The method we thought was to use the user_project_wrapper to integrate those. The steps are, 1. Create Empty verilog files for the Analog macros. 2. Instantiate those in the user_project_wrapper.v with the digital verilog file. 3. Making the necessary connections of the analog macros to the io pins 4. Adding .lef files and .gds files in the config.tcl of user_project_wrapper 5. Running --> make user_project_wrapper Do you think this is a correct method to integrate all the designs? Or is there any flaw in our method?
t
It sounds right to me, but I'd really have to see the complete layout.
r
Hello @User in the flow that @User has mentioned we need to give analog inputs to the analog macros. How that can be done using the GPIOs? Thank you in advance.
t
@User: Connect to the
analog_io
signals, and write a control program for the management SoC that sets those GPIOs to disable the digital input and output buffers (e.g.,
reg_mprj_io_13 = GPIO_MODE_USER_STD_ANALOG
)
r
Thank you @User.
@User While running the Openlane flow i am getting the Version as N/A, a picture of which is attached here. Is this the cause for the issue pointed by @User? FYI the flow was complete without fatal errors for the counter example.
g
@User: I have shared the Layout file link with you in personal chat yesterday. Kindly take a look into it. Thanks.
r
Hello @User. Can you please let me know how to write a control program for the management SOC? Thank you in advance.
t
@User: Look at any of the example control programs in the verification testbench tests for caravel in the caravel repository under
verilog/dv/caravel/mgmt_soc/
.
r
Ok sure thank you @User.
@User as far as I understand control programs for the management SOC can be written only after we get our chip right? If yes can the digital input and output buffers can be disabled after we get our chips? Please correct me if I am wrong. Thank you in advance.
t
You should definitely write a control program and test it in verilog prior to tapeout, as it is the only good way to ensure that your chip will work when you get it back. Yes, the digital input and output buffers can be disabled on the GPIOs connected to analog signals.
r
Ok @User thank you.