remove_buffers and repair_timing crash the tool

[Lang-Ian]

Hello,
This is my first post, so hopefully I have chosen a suitable place. Anyway, I am trying to use OpenROAD for a pair of digital blocks that will be instantiated in a mainly analogue chip. I guess quite a good place to start with OpenROAD. What I have found though is that, with the library I am using, the tool inserts quite a lot of hold time buffers, usually having around 5ns delay. Clearly this destroys the timing (I'm aiming for 100MHz). But it seems they can be removed using either the remove_buffers command or the maybe also the repair_timing command. The problem is, more often than not, when I try either of these command, the tool simply crashes. Is this a problem that other people have encountered and is there a fix?

[maliberty]

Is this something where you could provide a test case? It is hard to guess what your issue is.

[Lang-Ian]

Hi Matt,
Thank you for replying. Erm, I don't think I can share a test case because I would to supply information about the library. And we have an NDA covering that.
Ian

[maliberty]

One option is to do an NDA with https://precisioninno.com/ and share a test case that way.

It sounds like you have excessive hold buffers as your root issue. If you look a the clock tree view in the GUI do you see a large skew (you can also report it with report_clock_skew)?

[Lang-Ian]

The clock skew doesn't look good actually, I would say:

Might it be that the tool has not found clock buffers with enough drive?

[maliberty]

That is ugly. Are there any macros in this design? What are the arguments to clock_tree_synthesis? Are you using a current version of OR?

@arthurjolo any suggestions?

[arthurjolo]

Without a test case is hard to say, the arguments to clock_tree_synthesis would help a lot.

The first thing that catches my attention is the large wire delay in this tree. There are a couple of reasons that could cause this:

1. The clock drives a small number of sinks that are very far apart, CTS has a hard time with cases like this.

   • You can use -distance_between_buffers to specify CTS a buffering distance. You could try a couple of values, this would help to decrease the wire delay we see.
   • This is not a definitive fix, it possible that the sinks are way to spread out, and the leaf levels will still show a large wire delay.

2. The user specifies a bad wire unit for CTS. I am not sure if you are using the argument -wire_unit, but if so you can test removing it.

If you think the buffers CTS is using a buffer that is too small you can manually set a list of buffers for CTS to use with -buf_list

• By default CTS tends to use buffers with the highest driving strenghts, if it is indeed using small buffers it may not have found the correct buffers.
• CTS searches the library looking for specific clock buffers, it does that first by looking for a argument that indicates it is a clock buffer, it it doesn't find any it looks by the name if it has the sub-string "CLKBUF". If it still doesn't find any it look for cells if the sub-string "BUF" in the name.

[stefanottili]

In order to rule out that it's your library that's causing this as opposed to the tool, have you tried to map your rtl to one of the OSRF platform technologies ?

[minuaka]

Hi,

I am working with Ian on this topic and can give you some more infos and observations I made.

The arguments to cts are:
-buf_list "CKNID20 CKNID16 CKNID8" -sink_clustering_enable -sink_clustering_size 20 -root_buf CKNID20 -tree_buf CKNID8

After cts I get the following values for the clock-skew:
report_clock_skew -setup = 0.25
report_clock_skew -hold = 0.18

For me this looks ok so far.

After routing and finishing the design, the situation is different.
report_clock_skew -setup = -4.96
report_clock_skew -hold = -5.03

Which is quite bad when I understand this correctly.

Now I would say that this is introduced by parasitics and would require an optimization of the clock tree after the routing. How can this be done? I can't really find some useful information.

[maliberty]

It sounds like some miscorrelation between estimated and final parasitics. Do you see a similar jump after global routing or only after detailed routing and rcx? It is possible the set_layer_rc values are not a good predictor of the final extracted values. This is part PDK setup so perhaps you can describe the process you used to configure these.

[minuaka]

Fair point and excellent input. Let me try to explain.

1. The rcx ruledeck I generated following this guideline: https://github.com/The-OpenROAD-Project/OpenRCX/blob/master/doc/calibration.txt
   Looking at the output it looks generally reasonable to me.
2. The set_layer_rc values I took from the electrical specifications but they only report parasitic R, not C. Therefor I run a parasitic extraction and derived the cap values from there. The R values coming from the extraction match very well those from the spec. So I assume that's ok.
3. What I noted today is that the tool distiguishes between set_layer_rc and set_wire_rc. If I understand it correctly, set_layer_rc is used by global and detailed router while set_wire_rc is used by placement and CTS. Why there are different commands needed I do not understand. But what I did is to replicate more or less the set_layer_rc statements for set_wire_rc.
4. The jump already happens between cts and global routing. It's already accounts for approx. 67%. Rest comes when finishing the design.

It's very well possible that there's still a bug in the setup of the PDK but I can't really see where.

And I have another question:
When I am running the STA, I meet both setup and hold. So why do I have to care about the clock_skew?
At the end it's a 200ns clock with a skew of approx. 5% Why is this an issue?

Thanks and kind regards!

[minuaka]

Oh, I found something really strange. Please check the attached picture. It shows inspection of e.g. M1 in the Openroad GUI.
All values look like taken from the technology LEF but the values for Resistance and Capacitance are weird.

1. There's no definition of those values in the technology LEF.
2. I can not find any place which has values like this which are even close. With 38.69Ohms/sq you would be dead! For the Via it's even worse: 6.4kOhm/sq (although this number at least fits to my setting in the set_layer_rc but a fctor 1000 too high)

Do you have any explanation for this?

[minuaka]

What are the units used for set_layer_rc?

It looks to me that for resistance it is kOhm/um fro the wires and kOhm for the via.
For the capacitance it looks like fF/um.

Can you confirm this?

When I change those numbers accordingly, the rsult looks much better.

What is the correct way to verify those settings?

[arthurjolo]

By the documentation for these commands, the units come from the Liberty files:

| -resistance | Resistance per unit length, units are from the first Liberty file read. |
| -capacitance | Capacitance per unit length, units are from the first Liberty file read. |