Eder Monteiro

> @eder-matheus what's the status of this PR? I have congestion failures in a few public designs that I need to investigate. I didn't prioritized it yet because I was...

@maliberty Thanks for approving it. Before the merge, I have to update some metrics in ORFS, so it will take a bit of time.

@maliberty My first thought was that jenkins might be killing the process and it shows this stack trace. I will try some runs locally.

I believe this issue is related to the multithreading in STA. Should this be closed, since we're tracking the STA problem in another issue?

@oharboe A quick comment on the RUDY error: it only works when you have at least the pin placement, that's why you got the error. Also, since we don't have...

You are right. Even if we allow Metal1 routing (as in this design), all tracks are completely obstructed by the instance pins and obstructions. I will see what's wrong in...

> My guess is that since the AP is on the border that confuses grt as well about which gcell the ap is in. I think the problem is simpler...

> @eder-matheus Any update on this? I'm trying to solve congestion issues in 3 designs of the public CI. I believe we are having problem with pin access in GRT...

> [risc2.noram.def.gz](https://github.com/user-attachments/files/16042411/risc2.noram.def.gz) > > The RUDY map has a gap of 2 "blocks" on the right/top, whereas on left/bottom it goes right up to the die area. > > The...

> Hmm, something doesn't quite look right to me. > > Next to the pins on the top there is a pretty uniform stdcell density and you have the additional...