-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparing with OpenROAD-flow-scripts #239
Comments
Hi @mtdudek, I have been looking at this recently too - I started mainly looking at the simple examples under https://github.com/hdl/bazel_rules_hdl/blob/main/synthesis/tests/BUILD#L94-L117 Can you share the Sounds like you have found the issue to be something to do with the floorplan? Tim '@mithro' Ansell |
Hi @mithro, Here is the link to the I found that adding ORFS still reports better timing values. Edit: |
With all the changes in the #243 PR I still had some timing differences when compared to ORFS. |
The OpenROAD team has been working on updating their Yosys version used in OpenROAD-flow-scripts. Hopefully if we can get on identical Yosys versions between |
FYI as of today;
The "delta" in Yosys between I think we are all going to try and get onto Yosys 0.36 (which is commit
|
Just FYI - @vvbandeira and @maliberty |
|
|
FYI - It seems that internal Google3 is on Yosys commit |
@mtdudek You may find this interesting, it is a wafer think Bazel layer on top of ORFS that we are using when studying ORFS on designs as large as MegaBoom: https://github.com/The-OpenROAD-Project/megaboom |
On a related note;
This leaves |
@mtdudek - It would be good to see how the numbers compare now that your changes have landed. The first point of comparison would be the number and type of standard cells Yosys is producing out of synthesis. |
I've compared synthesis results from the newest main and ORFS@82b4fce7fc8ddedb6ea689894db44822e31ae575 ORFS yosys report
Bazel_rules_hdl yosys report
|
This is likely caused by the different Yosys versions? I sorted and split out the cells list and got the following; - Number of cells: 7122
+ Number of cells: 6883
- AND2x2_ASAP7_75t_R 107
+ AND2x2_ASAP7_75t_R 179
- AND3x1_ASAP7_75t_R 79
+ AND3x2_ASAP7_75t_R 86
- AND4x1_ASAP7_75t_R 18
+ AND4x2_ASAP7_75t_R 12
- AND5x1_ASAP7_75t_R 3
- AO211x2_ASAP7_75t_R 4
+ AO211x2_ASAP7_75t_R 5
- AO21x1_ASAP7_75t_R 45
- AO21x2_ASAP7_75t_R 1
+ AO21x2_ASAP7_75t_R 83
- AO221x1_ASAP7_75t_R 7
+ AO221x2_ASAP7_75t_R 18
- AO222x2_ASAP7_75t_R 13
+ AO222x2_ASAP7_75t_R 3
- AO22x1_ASAP7_75t_R 22
+ AO22x2_ASAP7_75t_R 49
- AO31x2_ASAP7_75t_R 3
- AO32x1_ASAP7_75t_R 134
+ AO32x2_ASAP7_75t_R 66
+ AO33x2_ASAP7_75t_R 2
- AOI211x1_ASAP7_75t_R 12
- AOI21x1_ASAP7_75t_R 34
- AOI22x1_ASAP7_75t_R 8
- BUFx2_ASAP7_75t_R 1621
+ BUFx2_ASAP7_75t_R 461
- BUFx3_ASAP7_75t_R 18
- BUFx4f_ASAP7_75t_R 3
- BUFx6f_ASAP7_75t_R 4
DFFHQNx1_ASAP7_75t_R 1148
FAx1_ASAP7_75t_R 20
- HAxp5_ASAP7_75t_R 68
+ HAxp5_ASAP7_75t_R 95
- INVx1_ASAP7_75t_R 686
- INVx2_ASAP7_75t_R 1
+ INVx2_ASAP7_75t_R 1290
- NAND2x1_ASAP7_75t_R 1385
- NAND2x2_ASAP7_75t_R 2
+ NAND2x2_ASAP7_75t_R 27
- NAND3x1_ASAP7_75t_R 4
+ NAND3x2_ASAP7_75t_R 1
- NOR2x1_ASAP7_75t_R 30
+ NOR2x2_ASAP7_75t_R 15
- NOR3x1_ASAP7_75t_R 7
- OA211x2_ASAP7_75t_R 1036
+ OA211x2_ASAP7_75t_R 1105
- OA21x2_ASAP7_75t_R 417
+ OA21x2_ASAP7_75t_R 502
+ OA22x2_ASAP7_75t_R 13
- OA222x2_ASAP7_75t_R 4
+ OA222x2_ASAP7_75t_R 3
- OA31x2_ASAP7_75t_R 2
+ OA31x2_ASAP7_75t_R 1
+ OA33x2_ASAP7_75t_R 2
- OAI21x1_ASAP7_75t_R 29
- OAI22x1_ASAP7_75t_R 17
- OR2x2_ASAP7_75t_R 13
+ OR2x2_ASAP7_75t_R 1525
- OR3x1_ASAP7_75t_R 51
+ OR3x2_ASAP7_75t_R 44
+ OR3x4_ASAP7_75t_R 4
- OR4x1_ASAP7_75t_R 11
+ OR4x2_ASAP7_75t_R 7
- OR5x1_ASAP7_75t_R 6
+ OR5x2_ASAP7_75t_R 8
- TIELOx1_ASAP7_75t_R 1
+ TIELOx1_ASAP7_75t_R 67
- XNOR2x1_ASAP7_75t_R 1
- XNOR2x2_ASAP7_75t_R 38
+ XNOR2x2_ASAP7_75t_R 29
- XOR2x2_ASAP7_75t_R 9
+ XOR2x2_ASAP7_75t_R 13 |
I pull the data into a spreadsheet at https://docs.google.com/spreadsheets/d/1SdI8NbOnJRO_rwhzCbMOW5EQ0-Rh-aIzkAYsk30GOD8/edit#gid=0 - preview image shown below; |
One thing that is clear, |
BTW What did you run to get this data? Is it something that I could run as well? |
Sometime odd about:
Is this apples to apples? |
I'm guessing there is a |
I see what the difference is, in the |
In ORFS we do repair_tie_fanout later which has a -separation flag. |
Recently I've been comparing Verilog to GDS flow between bazel_rules_hdl and OpenROAD-flow-scripts.
I've been testing this flows using common verilog design and
ASAP7 7.5T rev 28 RVT cells library.
The tested design is generated from DSLX language using XLS.
I've tried using bazel_rules_hdl to get GDS for that design, with clock period of 2.5ns.
Design is failing on the global routing stage with error message
[ERROR GRT-0118] Routing congestion too high. Check the congestion heatmap in the GUI.
P&R parameters:
Then I tried running the same source verilog using ORFS.
With the same clock constraints ORFS easily achieved 2.5 ns,
it was able to reach timings < 1ns using RVT cells.
ORFS parameters:
I later tried running bazel_rules_hdl synthesized Verilog through
ORFS P&R stages. It failed, as ORFS expects tie cells to be
already placed in the synthesized Verilog.
I've modified synthesis script, to use tie cells from openroad_pdk provider
and that was enough to get synthesized Verilog through ORFS,
it also achieved clock period < 1ns using RVT cells.
I've also tested starting ORFS from floorplan stage using flororplan generated
by bazel_rules_hdl. This run gave following error message:
[ERROR GRT-0119] Routing congestion too high. Check the congestion heatmap in the GUI
It is exactly the same error message. 119 means that extra information was being logged to
a file, while 118 means that there is no extra file.
I checked which version of ASAP7 ORFS use. It's 7.5t rev 28 with some extra cells defined.
Extra cells can be removed from the picture. Bazel_rules_hdl synthesized Verilog
only uses standard ASAP7 RVT cells and running ORFS P&R on it gave good timing results.
The text was updated successfully, but these errors were encountered: