https://open-source-silicon.dev logo
Join Slack
Powered by
Is this a valid placement from tool? I am seeing s...
# openlane
h
Is this a valid placement from tool? I am seeing some buffer cells and mux cells placed on top of a pre-hardened macro
v
Just check the OBS for macros and check HALO spacing.
h
The macros do have OBS over them
Where do I check HALO spacing? I am not setting one in config
v
Check inside run directory with all variables in 
config.tcl
h
Copy code
set ::env(FP_PDN_HORIZONTAL_HALO) "10"
set ::env(FP_PDN_VERTICAL_HALO) "10"
set ::env(FP_TAP_HORIZONTAL_HALO) "10"
set ::env(FP_TAP_VERTICAL_HALO) "10"
set ::env(PL_MACRO_HALO) "0 0"
v
Copy code
set ::env(PL_MACRO_HALO) "0 0"
update above value to 20 20 and try again
m
In previous openlane versions, we had to update a legalization distance so that it could move cells far enough to get them outside the macros. This parameter has changed frequently though.
It was this: set ::env(PL_DIAMOND_SEARCH_HEIGHT) 500
v
I think it is deprecated
m
What is it set to? I think I had an issue when it was deprecated because it is still needed.
It should be set to at least half the size of the largest macro.
@Hadir Khan this is likely the source of the problem with the routing issue as well
h
@Matthew Guthaus this variable is not available anymore, so it has been removed. I think it wasn't there for mpw8 as well.
m
I know the variable isn't there, but there is still a setting in the placer with a default value. If it is set too small, the legalizer won't work. In one of the tape outs, I had to set it by modifying the script.
If there are cells overlapping like that, the router will fail.
h
do you remember the flag? I see these on the documentation:
Copy code
global_placement
    [-timing_driven]
    [-routability_driven]
    [-skip_initial_place]
    [-incremental]
    [-bin_grid_count grid_count]
    [-density target_density]
    [-init_density_penalty init_density_penalty]
    [-init_wirelength_coef init_wirelength_coef]
    [-min_phi_coef min_phi_conef]
    [-max_phi_coef max_phi_coef]
    [-overflow overflow]
    [-initial_place_max_iter initial_place_max_iter]
    [-initial_place_max_fanout initial_place_max_fanout]
    [-routability_check_overflow routability_check_overflow]
    [-routability_max_density routability_max_density]
    [-routability_max_bloat_iter routability_max_bloat_iter]
    [-routability_max_inflation_iter routability_max_inflation_iter]
    [-routability_target_rc_metric routability_target_rc_metric]
    [-routability_inflation_ratio_coef routability_inflation_ratio_coef]
    [-routability_pitch_scale routability_pitch_scale]
    [-routability_max_inflation_ratio routability_max_inflation_ratio]
    [-routability_rc_coefficients routability_rc_coefficients]
    [-timing_driven_net_reweight_overflow]
    [-timing_driven_net_weight_max]
    [-timing_driven_nets_percentage]
    [-pad_left pad_left]
    [-pad_right pad_right]
    [-verbose_level level]
    [-force_cpu]
m
I don't remember. You could search the repo for that parameter to see what it was.
Though, if mpw8 worked without it...
h
My guess of why there are problems with PnR is that until mpw8 our macros were blackboxed (i.e there were no lib files). I think these tools read the lib file constraints to figure out what the placement should be and try the optimizations?
m
The lib file should have nothing to do with the placement. The LEF file has the placement info and it is still black boxed.
There might be timing driven placement but that would just change the weights on which wires to make shorter.
Also, the option would be in detailed placement not global placement.
🌍 1
h
The log files after fp, pl and grt had read liberty commands so I thought they might be influencing
13 Views
Open in Slack
PreviousNext
Powered by