set_driving_cellin your SDC to give it a better idea of the port input drive. If you really don't want resizer touching the buffers, then you can set the buffer placement status to
FIXEDand I believe that will prevent resizer from touching it.
Error: instAnalysis unsupported pinFig, seems to come from this section of code
@laurentc2 There is a mode of ioPlacer which uses non-random assignment - it uses an algorithm to place I/O pins such that wire length is minimized. We don't have it active right now because there was an issue where it might place pins too close together and cause routing violations. It depends on a placed design, so to run it, one has to run random IO assignment --> global placement --> non-random IO assignment.
It is not quite what you are asking, but it is better than random. There is probably a way to do place pins using OpenDB commands, but yes, we should make the interface easier to use. I will forward this to the team.
I found out that that some pins were defined in a layers not connected, so it solved my last issue.
But now, I face a new problem : TritonRoute is crashing in the middle of its processing with the message :
post process guides ...
GCELLGRID X -1 DO 48 STEP 14400 ;
GCELLGRID Y -1 DO 87 STEP 14400 ;
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 10) >= this->size() (which is 10)
0:03.00elapsed 250%CPU 19148memKB
Hope you can help me, I cannot find in the TritonRoute code the line that is crashing ...
Thank you, BRgds,
Error: no ap for AAA/BBBmeans that TritonRoute was unable to find an access point (ap) for cell instance
BBB. This can mean several things, such as 1) TritonRoute cannot find the pin definition in the LEF, 2) the cell is designed such that TritonRoute is unable to make a clean connection to the pin, 3) The location where the instance was placed makes it inaccessible by TritonRoute.