Steps to complete a successful test run of OpenROAD

[RTimothyEdwards]

Yay, I have success!

I managed to create a GDS file with the test AES module using FreePDK45 with the Nangate standard cell library.

It wasn't easy, so for reference for anyone else having difficulty to get the OpenROAD tools up and running, here are the steps I took. Please note the various workarounds for issues:

(1) Did git clone https://github.com/The-OpenROAD-Project/alpha-release Put this into ~/src/OpenROAD_alpha

(2) Did wget https://github.com/The-OpenROAD-Project/alpha-release/releases/download/v2019-07-16_13-32/OpenROAD-2019-07-16_13-32.tar.gz Put this into ~/src/OpenROAD_release

(3) Did cd ~/src/OpenROAD_release/openroad bash (I run tcsh for my environment, which doesn't work with the setup script) source setup.sh

(4) There were issues with some of the tools; I took the easy way out and swapped the search order in PATH so that /usr/local/bin gets executed first, which finds yosys and magic in my system installation, which solves a few of the library dependency problems (old libraries used in OpenROAD, like libffi 5 instead of libffi 6).

(5) I didn't have a local copy of verilog2def, which wanted libtcl8.5 and libtk8.5 (also out of date), so I did: cd /usr/lib/x86_64-linux-gnu ln -s libtcl8.6.so libtcl8.5.so ln -s libtk8.6.so libtk8.5.so".

(6) The runTritonCTS.tcl script execs python scripts with missing dependencies, so I did: sudo pip3 install queuelib sudo pip3 install matplotlib

(7) The runTritonCTS.tcl script calls "exec python" which runs python2, not python3, so I edited the script and changed all occurrences of "python" to "python3".

(8) With the changes made above, the entire test procedure goes like this:

    cd ~/src/OpenROAD_release/openroad
    bash
    source setup.sh
    export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/home/tim/src/OpenROAD_release/openroad/OpenROAD-2019-07-16_13-32/bin:/home/tim/src/OpenROAD_release/openroad/OpenROAD-2019-07-16_13-32/bin/Linux-x86_64:/home/tim/src/OpenROAD_release/openroad/OpenROAD-2019-07-16_13-32/pdn/scripts:.
    cd ~/src/OpenROAD_alpha/flow/
    vi Makefile
    (uncomment "DESIGN_CONFIG = ./designs/aes_nangate45.mk")
    source designs/aes_nangate45.mk
    make

(9) I viewed the result using magic:

    magic -d XR -T platforms/nangate45/magic.tech
    (at the magic prompt:)
    gds read results/aes_cipher_top/finish.gds

[tajayi]

Hi Tim, The builds are not currently in the best shape. We have identified it as an issue an are working on some short term and much needed long term strategies.

To address some points specifically: (1)-(2): User choice

(3): I can add a tcsh script

(4): We use a mofified version of Yosys+Abc which includes support for upsizing/downsizing as well as physical synthesis support (still in dev). Our goal is to hopefully be able to upstream some of these changes

(5) We currently have a dependency on tcl8.5 (as well as including tcl8-6 in our package) but further improvements we plan to make should make this more consistent

(6) I updated the readme

(7) Filed an issue against tritonCTS: https://github.com/The-OpenROAD-Project/TritonCTS/issues/15

Thanks for trying out our flow and pushing through it

[tajayi]

We have added "runtime" docker images with the tools pre-installed. We will try to update this alongside the tool exports. in the long term, we are still looking to make improve the build.

See instructions at https://github.com/The-OpenROAD-Project/alpha-release/tree/master/build#docker-install

On Sat, Jul 27, 2019 at 3:43 PM Øyvind Harboe notifications@github.com wrote:

@tajayi https://github.com/tajayi I'm sure you have thought of this, but have you given any consideration to writing and providing a Dockerfile so it is easier to test the OpenROAD project?

It should be much easier to write and test a Dockerfile than it is to write a readme with precise instructions on how to set up something like the OpenROAD project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/alpha-release/issues/5?email_source=notifications&email_token=AALD5AMAOBRKBFPJ3MAFX6DQBSQM3A5CNFSM4IERHTIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26ROGY#issuecomment-515708699, or mute the thread https://github.com/notifications/unsubscribe-auth/AALD5ALMC4DB7E5KMJGRCADQBSQM3ANCNFSM4IERHTIA .

[oharboe]

I think it would be great if these instructions had a bit more context so that they work "out of the box".

When I try to run the instructions to get the docker image, I get the error message below.

I believe there's a trivial step missing:

oyvind@davos:~$ docker pull openroad/alpha-release Using default tag: latest Error response from daemon: manifest for openroad/alpha-release:latest not found oyvind@davos:~$

On Wed, Jul 31, 2019 at 8:35 PM Tutu Ajayi notifications@github.com wrote:

We have added "runtime" docker images with the tools pre-installed. We will try to update this alongside the tool exports. in the long term, we are still looking to make improve the build.

See instructions at

https://github.com/The-OpenROAD-Project/alpha-release/tree/master/build#docker-install

On Sat, Jul 27, 2019 at 3:43 PM Øyvind Harboe notifications@github.com wrote:

@tajayi https://github.com/tajayi I'm sure you have thought of this, but have you given any consideration to writing and providing a Dockerfile so it is easier to test the OpenROAD project?

It should be much easier to write and test a Dockerfile than it is to write a readme with precise instructions on how to set up something like the OpenROAD project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/The-OpenROAD-Project/alpha-release/issues/5?email_source=notifications&email_token=AALD5AMAOBRKBFPJ3MAFX6DQBSQM3A5CNFSM4IERHTIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26ROGY#issuecomment-515708699 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AALD5ALMC4DB7E5KMJGRCADQBSQM3ANCNFSM4IERHTIA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/alpha-release/issues/5?email_source=notifications&email_token=AAVLJZT2Q6KWFRLJ4CQNSHDQCHLOLA5CNFSM4IERHTIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3IFD7A#issuecomment-516968956, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVLJZRGGFHVFZKU6PJUSLLQCHLOLANCNFSM4IERHTIA .

-- Øyvind Harboe, General Manager, Zylin AS, +47 917 86 146

[tajayi]

Instructions updated and also pushed the "latest" tag to dockerhub

[oharboe]

That worked.

Thanks!

The next thing I'd like to try is to see if FastRoute (FRlefdef) would be able to route something that qrouter can't.

It is my impression from reading the docs that qrouter and FastRoute operate on the same file formats.

On Wed, Jul 31, 2019 at 9:48 PM Tutu Ajayi notifications@github.com wrote:

Instructions updated and also pushed the "latest" tag to dockerhub

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/alpha-release/issues/5?email_source=notifications&email_token=AAVLJZV4IWD4I4WJXNSF453QCHUAPA5CNFSM4IERHTIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3ILLFQ#issuecomment-516994454, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVLJZV7O4KCUBIYKXLAWW3QCHUAPANCNFSM4IERHTIA .

-- Øyvind Harboe, General Manager, Zylin AS, +47 917 86 146

[RTimothyEdwards]

Note that FastRoute is a global router. qrouter is a detail router which makes it equivalent to TritonRoute, not FastRoute. qrouter has the capacity to take a global route solution as input, but since I was never aware of a standard file format, I never implemented it. So qrouter attempts to do a detail route on an entire design without a global route as input. That is part of what makes qrouter painfully slow.

I think the more interesting question is, since FastRoute + TritonRoute has the same file formats as qrouter, can a script be written that incorporates them directly into qflow, replacing qrouter?

It's not exactly a question of whether one tool can do something that another tool can't. It's more a question of how fast it will run, and how good a solution it will produce. Although there are certainly specific features to check if they are implemented or not, such as handling minimum metal area rule (done by qrouter, not very well), handling antenna rule violations (again done by qrouter, not very well), and run-length spacing rules (not done by qrouter at all).

[oharboe]

Ah. I see. Thanks!

I'm just testing these things out and I'm really more of a software engineer who's dabbling in FPGA and when it comes to custom silicon tools, I'm way out of my depth.

I'm able to run the FRlefdef command from within the Docker image now, so no need to build anything to do smoke-tests.

On Wed, Jul 31, 2019 at 11:26 PM R. Timothy Edwards < notifications@github.com> wrote:

Note that FastRoute is a global router. qrouter is a detail router which makes it equivalent to TritonRoute, not FastRoute. qrouter has the capacity to take a global route solution as input, but since I was never aware of a standard file format, I never implemented it. So qrouter attempts to do a detail route on an entire design without a global route as input. That is part of what makes qrouter painfully slow.

I think the more interesting question is, since FastRoute + TritonRoute has the same file formats as qrouter, can a script be written that incorporates them directly into qflow, replacing qrouter?

Ah. Right. My plan was to plonk the lef and def files from qflow into FRlefdef to see what would happen.

This is what happened:

[root@f52f6c101a97 /]# FRlefdef --no-gui --script blah.rsyn [deleted] Running generic reader... Parsing LEF files... WARNING: Unsupported INOUT direction in data pin. gnd. Pin direction is replaced to OUTPUT [LEF CONTROL PARSER] [deleted] Parsing LEF files... Done (runtime: 0.01051 seconds memory: +3 MB) Parsing DEF files... Segmentation fault (core dumped)

It's not exactly a question of whether one tool can do something that

another tool can't. It's more a question of how fast it will run, and how good a solution it will produce. Although there are certainly specific features to check if they are implemented or not, such as handling minimum metal area rule (done by qrouter, not very well), handling antenna rule violations (again done by qrouter, not very well), and run-length spacing rules (not done by qrouter at all)

Certainly if that could be done, it would bring it to a level of userfriendliness that's more in line with something that I could realistically hope to succeed with given my knowledge of this domain. I'm looking to get a realistic fMax for 40nm or lower(i.e. something that's somewhat like a modern DSM node) for my design as a metric to drive the direction of my design.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/alpha-release/issues/5?email_source=notifications&email_token=AAVLJZWVWTDEYVAZXONHW7DQCH7OVA5CNFSM4IERHTIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3ITNEA#issuecomment-517027472, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVLJZQ4SA2FUCXUJQIC4QDQCH7OVANCNFSM4IERHTIA .

-- Øyvind Harboe, General Manager, Zylin AS, +47 917 86 146