Hi, can somebody explain the output format of the ...
# openroad
k
Hi, can somebody explain the output format of the
diff_spef
command, when calibrating the RCX rules generation.
89.7      7.0717 D LO -47.9 ref     3.7280 R LO -72.6 bounds:    13.5863    41.2144  L   162360  WC   1  V   0 netGndCap corner 0 ,M6:162360  20412 O8_M6oM3_W1640W1640_S04100S04100_2
I am using Cadence QRX as a reference extractor and sometimes I get enormous percentage differences, assuming that the first column stands for the difference. The flow I use is the following
m
the message is
Copy code
fprintf(_diffOutFP,
              "%4.1f  %10.4f D %s %4.1f ref %10.4f R %s %4.1f bounds: %10.4f "
              "%10.4f  L %8d  WC %3d  V %3d %s corner %d %s ",
              diffCap,
              dbCap,
              comp_db,
              boundsPercent,
              refCap,
              comp_ref,
              boundsPercentRef,
              min_cap,
              max_cap,
              wlen,
              wireCnt,
              via_cnt,
              ctype,
              ii,
              _ext->_tmpLenStats.c_str());
👍 1
k
@Matt Liberty thank you for indicating the exact information. I was experimenting with the PEX extraction using booth QRC and OpenRCX and the strange thing is that modifying extaraction parameters like
-coupling_threshold
does not reflect in the actual difference between the extracted values. Is it possible that there exists kind of systematic difference, which does not depend on how we actually perform extraction, and it dominates the difference I attach a histogram
@Tim Edwards have you had similar issues calibrating RC rules for openlane in the case of SKY130 and GF180 ?
t
@Krzysztof Herman: Openlane uses the Calibre-generated OpenRCX rule deck that was provided to us by SkyWater (running Calibre per our instructions for generating the OpenRCX rule deck). So any differences are likely to come from OpenRCX itself. Interesting graph, though, especially as it is clearly bimodal. I'm assuming that since the graph doesn't go negative that it is measuring the absolute value of the differences? The vast majority of the values are centered around 2%, which seems pretty good to me. The second smaller and wider bump centered around 10% difference. . . it would be valuable to know how all those values differ from the values in the other distribution, as in whether they come from some specific geometry or one of the metal layers.
k
@Tim Edwards thanks for answer. Indeed in OpenRCX they do some processing of the relative difference and it never gets negative. https://github.com/The-OpenROAD-Project/OpenRCX/blob/master/src/extSpefIn.cpp I was wondering if a good benchmark would be a comparison between net delays reported during post layout STA
m
-coupling_threshold would only shift between coupled and grounded cap and wouldn't change total cap.
I would pick your high outliers and investigate if there is any commonality (eg layer usage).
a
It's good to look at both the absolute difference as well as the relative. There may be some segments which are off by high percentages but that could be because the cap is small so the absolute difference is also very small and therefore isn't that important for timing.
k
@Austin Rovinski Hi, here goes some graphics related to what you are talking about. Please remember that on the histogram I have manually limited the x axis, but the occurrences of the values |x | > 1 are very seldom.
a
I'm not sure what the units are in the first one, but the outliers are actually the most important ones worth investigating. One thing I've done in the past is to look at the relative difference, but filter all points below a certain absolute threshold. For example, I wouldn't care that a wire which is 100nm long and 0.1 pF cap is off by 0.03 pF (30% difference). But I would care that a 100um wire with 100pF cap is off by 30 pF
👍 2