https://open-source-silicon.dev logo
Join SlackCommunities
Powered by
Hi everyone, My project requires me to connect a p...
# caravel
j
Hi everyone, My project requires me to connect a premade gds blob to the wishbone bus so it can be accessed as a peripheral from the risc-v core. I am running into some issues placing the blob in the caravel user project. These issues occur during signoff when klayout XOR is run. There are a lot of differences according to the XOR check and I suspect this is because of how I obtain the gds. My employer has provided me with a .mag file of the blob to be added. I export it to gds and lef from magic, place those in the correct folders of my caravel_user_project and I've also added a verilog module with its interface so that the connections are routed properly. The magic file is a hierarchical file so I suspect some issues could arise there. Is there anyone here who has done something similar or knows how to approach this and can help me? I will gladly provide more information if it is needed
I've figured it out, so for future reference I will add my solution here. First you should flatten the magic file and then export the GDS and lef
m
@Jelmer Lap I would not recommend flattening any layouts to perform integration. Check your gds output options and possibly expand to read all the sub cells into memory before gds/lef export. Read the gds and lef into klayout to be sure everything looks ok.
j
@Mitch Bailey Why is this not recommended? I can't get it to work any other way
m
@Jelmer Lap Maybe I should have prefaced that with “my personal recommendation”. One reason is that you have to keep the 2 databases in sync, the original hierarchical and then the flattened one. Are you able to share your logs from the hierarchical version that weren’t passing precheck?
j
@Mitch Bailey I am sadly not really able to share the log as there is some confidential information. What I can say is that magic had some computed cells that it did not expand when writing the gds, which was fixed when flattening the design.
m
Is it possible to expand the cells in magic before gds/lef? Expand in magic loads the subcell data that intersects the select window into memory without flattening the hierarchy. select top cell expand lef write -hide -pinsonly gds write
j
@Mitch Bailey The pins are not accessible if I run it like this see this error: 
[ERROR DRT-0073] No access point for nsa0/syn_addr[0].
So doing it like this I don't get past the routing step
This is fixed if I omit 
-pinonly
And if I run it without pinonly, I get the same XOR issues I had before flattening the layout
m
The 
-pinonly
option requires that the pins go to the border of the cells and the 
-hide
option requires a cell boundary (
FIXED_BBOX
property). Are the XOR issues between klayout gds and magic gds or with the caravel integration?
j
When running 
make user-project-wrapper
it gives XOR issues between the klayout GDS and the magic GDS
The pins do not go to the border of the cells, so that is probably where it goes wrong
However I do not make the custom layout myself, it is done by someone else so I will pass this info along to them
m
When running 
make user-project-wrapper
it gives XOR issues between the klayout GDS and the magic GDS.
This is slightly concerning. Can you share more detail about what mismatches occur so we can figure out why? Is this a fatal error?
j
@Mitch Bailey I assume it comes from the fact that I am using an externally sourced hierarchical magic file which I place as a macro. The wrapper does not know or import any of the cells in the subhierarchy and they are also not accessible to it. Therefore I don't think it is an issue with the user project
m
My understanding is that the macro gds should contain all the subcells.
j
@Mitch Bailey Yeah however when I normally write it it does not, so I flatten the layout first and then write the gds
I do have another question to ask you about the FP_PDN_MACRO_HOOKS if you could help me with that? I currently have this in the json of the wrapper:
Copy code
"FP_PDN_MACRO_HOOKS": [
        "nn0 vccd1 vssd1 vccd1 vssd1",
        "nsa0 vccd1 vssd1 dVDD dGND",
        "nsa0 vdda1 vssa1 aVDD aGND"
    ],
With
Copy code
array nsa0 (
        `ifdef USE_POWER_PINS
            .dGND(vssd1),
            .dVDD(vccd1),
            .aGND(vssa1),
            .aVDD(vdda1),
        `endif
        .CLK(wb_clk_i),
        .syn_addr(nn_ids)
    );
In the verilog file of the wrapper. But when I run the wrapper it stops on LVS because it says it can't match some pins
I've had this issue before because this value wasn't set correctly
And the pins which are not matched are the power pins
m
This problem has to do with json lists. the list is converted to a string where the 5 tuplets need to be separated by commas. What you have becomes
Copy code
nn0 vccd1 vssd1 vccd1 vssd1 nsa0 vccd1 vssd1 dVDD dGND nsa0 vdda1 vssa1 aVDD aGND
but what you need is
Copy code
nn0 vccd1 vssd1 vccd1 vssd1, nsa0 vccd1 vssd1 dVDD dGND, nsa0 vdda1 vssa1 aVDD aGND
The rather unintuitive solution is to include a 
,
before the 
"
like this
Copy code
"FP_PDN_MACRO_HOOKS": [
        "nn0 vccd1 vssd1 vccd1 vssd1,",
        "nsa0 vccd1 vssd1 dVDD dGND,",
        "nsa0 vdda1 vssa1 aVDD aGND"
    ],
j
@Mitch Bailey Thanks for the help, I've done this but still get the following in the LVS log:
Copy code
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper            
-------------------------------------------|-------------------------------------------
wishbone_nn (1)                            |wishbone_nn (1)                            
neuron_synapse_array_with_input_output_log |neuron_synapse_array_with_input_output_log 
Number of devices: 2                       |Number of devices: 2                       
Number of nets: 155 **Mismatch**           |Number of nets: 153 **Mismatch**           
---------------------------------------------------------------------------------------
NET mismatches: Class fragments follow (with fanout counts):
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper            

---------------------------------------------------------------------------------------
Net: vccd1                                 |Net: vccd1                                 
  wishbone_nn/vccd1 = 1                    |  wishbone_nn/vccd1 = 1                    
                                           |  array/dVDD = 1
                                           |                                           
Net: vssd1                                 |Net: vssd1                                 
  wishbone_nn/vssd1 = 1                    |  wishbone_nn/vssd1 = 1                    
                                           |  array/dGND = 1
                                           |                                           
Net: nsa0/dVDD                             |(no matching net)                          
  array/dVDD = 1                           |                                            
                                           |                                           
Net: nsa0/dGND                             |(no matching net)                          
  array/dGND = 1                           |                                           
---------------------------------------------------------------------------------------
Netlists do not match.
And:
Copy code
(no matching pin)                          |vdda1                                      
(no matching pin)                          |vssa1                                      
vdda1                                      |(no matching pin)                          
vssa1                                      |(no matching pin)
Do you have any idea what could cause this?
Is it still a wrong configuration or something else going wrong
m
Do you have this?
Copy code
"SYNTH_USE_PG_PINS_DEFINES": "USE_POWER_PINS",
Otherwise, check your pdn log for messages. Look at the lef for 
nsa0
and check that the power rails are accessible for the power grid you are using. If this is the top level and you’re not using power rings, then the macro lef’s should not have met5 obstruction and should have vertical met4 power pins that go from the top of the macro to the bottom.
j
I do have the USE_POWER_PINS. This specific macro has power rings on metal 2 and metal 3. Which are unobstructed in the lef. However in the PDN log is the following warnings:
Copy code
[WARNING PDN-0110] No via inserted between met4 and met5 at (387.5700, 574.8950) - (390.6700, 576.0300) on vssd1
[WARNING PDN-0110] No via inserted between met4 and met5 at (424.7700, 250.1300) - (427.8700, 250.8950) on vssd2
These are from the generated PDN not connecting as the macro has no met5 obstruction but it does have met4 obstruction as can be seen in the following image:
Does the user project by chance only connect power and ground to met4 or met5 pins? Because in that case a power ring of met2 and met3 would not work
@Mitch Bailey I see you responded to someone on october 26th, this is a similar project. It is a mixed signal tapeout and we are loading the analog macro in the caravel harness. I see you said in your response to that question that you might need a custom 
lvs_config
. Could that be the case here as well?
m
@Jelmer Lap you may need to modify the 
pdn.tcl
to connect met5 to met2 (or met4 to met3). To connect met5 to met2 the intermediary met3 and met4 also need to be unobstructed. The 
lvs_config.json
file is used for precheck’s LVS and not for openlane’s abstract LVS.
j
The person who makes the glob made another layout with the ring on met4, it still gives me the same LVS error so sadly that doesn't work
m
Can you look at the layout and see why the power rails aren’t connecting? For example, id there’s no overlap, then the macro might need to be repositioned higher or lower so there is an overlap with the correct power.
j
We just discovered that the pins in the lef are not on met4, so I will retry when we I get that blob back
👍 1
Not quite there yet, but there is progress
[WARNING PDN-0110] No via inserted between met4 and met5 at (250.0150, 374.3300) - (251.0450, 377.4300) on vccd1 [WARNING PDN-0110] No via inserted between met4 and met5 at (250.0150, 554.3300) - (251.0450, 557.4300) on vccd1 [WARNING PDN-0110] No via inserted between met4 and met5 at (252.0200, 572.9300) - (253.0200, 576.0300) on vssd1 [WARNING PDN-0110] No via inserted between met4 and met5 at (252.0350, 392.9300) - (253.0200, 396.0300) on vssd1 [WARNING PDN-0110] No via inserted between met4 and met5 at (254.0050, 268.7300) - (255.0000, 271.8300) on vdda1 [WARNING PDN-0110] No via inserted between met4 and met5 at (254.0050, 448.7300) - (255.0000, 451.8300) on vdda1 [WARNING PDN-0110] No via inserted between met4 and met5 at (256.0050, 287.3300) - (257.0450, 290.4300) on vssa1 [WARNING PDN-0110] No via inserted between met4 and met5 at (256.0050, 467.3300) - (257.0450, 470.4300) on vssa1 with the pins on met4 we now see additional vias missing which are on the specified nets
m
Congratulations on the progress. My only advice is to check the lef and final gds (if you have it) to be sure that the pins are exposed (not covered by met5 obstruction. met4 obstruction over met4 pins is ok - the pins take priority). Make sure all the top level horizontal power rails are overlapping a corresponding met4 vertical power pin in the macro.
r
Looks like our problem is that our m4 strip is too narrow to fit vias to m5, we have a 1um wide strip now but it needs 0.8 um for a via and 2x 0.19um for m4 to wrap properly around the via...
That did get us a step further, LVS passes and the power network is properly connected now!
👍 1
Next up, step 30: DRC. Running into a problem where the standard cell blocks in our layout are no longer recognized since we flattened the core to pass the XOR check. Looks similar to this one: https://github.com/The-OpenROAD-Project/OpenLane/issues/1470
but I don't see a clear solution to that yet
j
@Mitch Bailey I went back to the beginning of this thread and tried to use expand again which fixed the issues. I want to thank you for the time you put into helping us go to fully inserting this gds blob into the project. It is very much appreciated
✅ 1
👍 1
m
Congratulations!
j
@Mitch Bailey Where can I find information on how to configure the harnass' gpio pins? The macro placed has some analog GPIO that is routed to the pins already. But what do I need to set in the defines? And should I set io_oeb to a specific value? Also should I not route to pins analog_io[6:0] or is that already taken care of by the -10 in the definition: 
inout [MPRJ_IO_PADS-10:0] analog_io
m
Where can I find information on how to configure the harnass’ gpio pins?
verilog/rtl/user_defines.v
The macro placed has some analog GPIO that is routed to the pins already. But what do I need to set in the defines?
Not sure what you’re asking. The gpio defaults for analog are 
GPIO_MODE_MGMT_STD_ANALOG
or 
GPIO_MODE_USER_STD_ANALOG
they are functionally equivalent.
And should I set io_oeb to a specific value?
For gpio configured to used for analog signals, the logic level of 
io_oeb
is irrelevant. I recommend tying it either high or low to avoid possible leak current due to Hi--Z inputs.
Also should I not route to pins analog_io[6:0] or is that already taken care of by the -10 in the definition: 
inout [MPRJ_IO_PADS-10:0] analog_io
This might be a little tricky. There are 38 gpio pads in the caravel chip framework. The first 7 and the last 2 are too far away from the user area to be useful as analog connections. So gpio 0~6 and gpio36-37 do not have an analog connection to the user area. 
analog_io[0]
is connected to gpio 7 (along with 
io_in[7]
, 
io_out[7]
and 
io_oeb[7]
. Similarly, 
analog_io[28]
is connected to gpio 35 (along with 
io_in[35]
, 
io_out[35]
and 
io_oeb[35]
). It is probably best to avoid using the same gpio for both digital and analog signal I/O.
6 Views
Open in Slack
PreviousNext
Powered by