[ERROR DRT-0073] No ap for wishbone.bd_ram.spram_32_256/din0[0]

[vijayank88]

Describe the bug During detail routing am facing below issue

[INFO DRT-0165] Start pin access.
[INFO DRT-0076]   Complete 100 pins.
[INFO DRT-0076]   Complete 200 pins.
[INFO DRT-0076]   Complete 300 pins.
[INFO DRT-0076]   Complete 400 pins.
[INFO DRT-0076]   Complete 500 pins.
[INFO DRT-0076]   Complete 600 pins.
[INFO DRT-0076]   Complete 700 pins.
[ERROR DRT-0073] No ap for wishbone.bd_ram.spram_32_256/din0[0].
terminate called after throwing an instance of 'std::runtime_error'
  what():  DRT-0073
Elapsed time: 0:14.68[h:]min:sec. CPU time: user 28.59 sys 1.07 (201%). Peak memory: 1544204KB.
make: *** [results/asap7/ethwish/base/5_route.def] Error 6

I'm trying to use spram_32_256_asap7.lef, spram_32_256_asap7_TT_1p0V_25C.lib files as hard macro for eth_spram_256x32. LEF/LIB files I derived from nangate45 technology, as ASAP7 not yet supported by SRAM generator.

Expected behavior Successfully complete flow.

Environment (please complete the following information): Please only report issues for supported OSs.

• OS: Ubuntu 20.04
• OpenROAD-flow commit : v2.0-1978-gc1af9a878

File Uploads Attached detail_route tar file detail_route_ethwish_asap7_base_2021-12-07_06-38 Size is more then 45MB. So given google drive access path. https://drive.google.com/drive/folders/1S4SNdLPshZroumiTbh-9-3wQuhSvUAkT

[maliberty]

When I run your test case I get: [ERROR ORD-0001] ./designs/asap7/ethwish/spram_32_256_asap7.lef does not exist.

it appears the packaging missed at least one file.

[vijayank88]

When I run your test case I get: [ERROR ORD-0001] ./designs/asap7/ethwish/spram_32_256_asap7.lef does not exist.

it appears the packaging missed at least one file.

@maliberty shared in google drive missing LEF file

[maliberty]

Your ram is in the wrong orientation. M4 pins on the south which is an H layer and M3 pins on the west which is a V layer.

[maliberty]

" I derived from nangate45 technology, as ASAP7 not yet supported by SRAM generator." is your problem as the layer stack doesn't align between these processes.

[vijayank88]

@maliberty is manually derived lib and lef won't be acceptable? We need help from bsg_fakeram or OpenRAM to support ASAP7/ ASAP7-6T

[maliberty]

@vijayank88 It isn't acceptable if it makes no sense. You need the pins on the right layers. The tool doesn't care how it was derived. Since this is fake data you can just swap the pin layers to be correct for asap7.

[QuantamHD]

@maliberty is there something we could do to improve the error message for pin access. Not everyone will be familiar with terms like ap and DRT-0073. Making this more user friendly would help the community solve their issues more quickly.

[maliberty]

@QuantamHD do you have a suggestion as a what we might say?

[QuantamHD]

Instead of

No ap for wishbone.bd_ram.spram_32_256/din0[0].

I would say this might be more clear

The detailed router couldn't find an access point to the pin named wishbone.bd_ram.spram_32_256/din0[0]. 
The router is trying to find a way to connect to this pin, but cannot because it would either cause a short, 
the router configuration prevents it from doing so, or existing blockages defined by the MACRO prevent 
the router from reaching the pin.

This could be caused by a few things:

1. The pin is block from all sides above, and below by other nets or vias.
2. The pin layers may not match the detailed routers pin layer configuration. See {insert_link_here} on how you can resolve this.
3. Other likely causes... 

[maliberty]

I like it. You are in charge of user messages :)

On Wed, Dec 8, 2021 at 3:38 PM Ethan Mahintorabi @.***> wrote:

Instead of

No ap for wishbone.bd_ram.spram_32_256/din0[0].

I would say this might be more clear

The detailed router couldn't find an access point to the pin named wishbone.bd_ram.spram_32_256/din0[0].

This could be caused by a few things:

1. The pin is block from all sides above, and below by other nets or vias.
2. The pin layers may not match the detailed routers pin layer configuration. See {insert_link_here} on how you can resolve this.
3. Other likely causes...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues/248#issuecomment-989315060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZ5KS5ZG225ZTHB6JF4VLUP7UA7ANCNFSM5JQQNBAQ .

[rovinski]

In commercial tools, they often leave a short error message in the log and provide a more detailed message if you use help [error code] or man [error code]. It would be great if we eventually had a similar structure.

So in this example the message could stay as is and then help DRT-0073 could provide a message similar to what @QuantamHD wrote.

[vijayank88]

@rovinski I agree with your suggestion. This is also part of documentation work which already discussed with @dralabeing. This should be collaborative effort from designer message and Developer Error code

[vijayank88]

@vijayank88 It isn't acceptable if it makes no sense. You need the pins on the right layers. The tool doesn't care how it was derived. Since this is fake data you can just swap the pin layers to be correct for asap7.

@maliberty Even numbers are Horizontal layer, Odd number are vertical layers in ASAP7. But in sky130 and nangate45 its inverse. Updated my LEF file, configuration and issue got fixed.

[QuantamHD]

@rovinski

I disagree that it should be a separate tool for a couple of reasons.

1. We don't want to break the flow of our users. Asking them to run a separate command breaks their flow, and may lead to getting distracted, or forgetting what they were trying to do.
2. If messages exist separate from the codebase they're documenting they're likely to go out of date.
3. We need to teach users that these tools exist. Which means there will always be some percentage of users who don't get good error messages.

I do think we should adopt an internationalization library for string messages in the long term so that we can support users in multiple languages. That would mean we have separate files for strings that we could use to generate such man tools, and web pages in addition to printing them in the logs.

[mithro]

clang having developer friendly error messages (for things like C++ template errors) is one of the reasons people started switching away from GCC. I would highly recommend looking into them.

See https://clang.llvm.org/diagnostics.html https://gcc.gnu.org/wiki/ClangDiagnosticsComparison and https://blogs.gnome.org/mortenw/2014/01/27/gcc-vs-clang-for-error-messages/

David Malcolm at RedHat has some great blog posts about the improvements in GCC in the last couple of years in this area;

• https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements
• https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9
• https://hub.packtpub.com/gcc-9-will-come-with-improved-diagnostics-simpler-c-errors-and-much-more/

Error message usability matters.

[mithro]

In commercial tools, they often leave a short error message in the log and provide a more detailed message if you use help [error code] or man [error code]. It would be great if we eventually had a similar structure.

So in this example the message could stay as is and then help DRT-0073 could provide a message similar to what @QuantamHD wrote.

It is good to have short error codes associated with error messages.

It is bad to require a seperate tool to make those error codes useful for all the reasons @QuantamHD points out.

[mithro]

FYI - Short error codes tend to be mostly useful for toolchain developers, not end users.

[mithro]

I recommend also reading the "Not just for humans" section in the https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9 blog post.

[mithro]

FYI - All open source projects should support localization (l10n) and internationalization (i18n). Please just use gettext so you can integrate into various translation tooling and efforts. See;

• https://www.gnu.org/software/gettext/manual/gettext.html
• https://en.wikipedia.org/wiki/Gettext

[rovinski]

One reason I disagree with the disagreement is because putting full messages with tips, etc. can easily clog up the log and make things more difficult to parse. If the same error happens on 2000 items, then all of a sudden the same help message is printed to the log 2000 times and can make it more difficult to parse. Hardware designs are different from software because often problems do not originate from a single source, and so finding problems becomes an issue of reading through all the errors/warnings and determining which one might be the root cause.

Something that should be noted about the error code approach is that every message ends with Use 'help [error code]' for more information so that it is not possible for a user to not be familiar with it.

If no one likes the help [error code] approach that commercial tools use, what alternatives are there? Because I strongly disagree with dumping out a paragraph of text for every error message for the aforementioned reasons. I find it's a major annoyance in compilers, and I believe it would be even worse here.

[maliberty]

@rovinski you should distinguish warnings from errors. Errors stop the flow so you won't get more than one unless you explicitly catch the exception

[rovinski]

Do we enforce that now? I recall several instances where the flow would push through with errors.

[maliberty]

@rovinski when the logger's error() is called it always throws an exception (see https://github.com/The-OpenROAD-Project/OpenROAD/blob/33aaefeb2f9d9a80bfafec464c338040b9b65f17/src/utl/include/utl/Logger.h#L152)

So unless someone catches it, the execution will stop. We do have code to propagate the exception from c++ to tcl in the swig wrappers.

[maliberty]

In all the clang/gcc examples the error message itself is one line long and the remaining lines are annotated source code. None are as verbose as what @QuantamHD proposes.

[rovinski]

If true, then there could be detailed messages (such as https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues/248#issuecomment-989315060) for errors and short messages with "Use help [warn code]" for warnings? I'd be okay with that.

The other issue that brings up is where to put the long messages. Putting it right in the code like we do now seems like a hassle and breaks code flow.

[maliberty]

@mithro @QuantamHD Internationalization is a huge project that I don't see the resources for. We haven't even fully completed the logger conversion after more than six months.

[rovinski]

One other thing to consider is how to bring warnings and errors together to give the developer a better picture. If the flow errors out with over 100% utilization, there could be a million reasons for it and previous context is necessary. I think it would be borderline impossible to cover all or even most of the bases in one error message. But if there were previous warnings about bad constraints, then it could be much quicker to nail down. Seems like a hard problem; food for thought.

[maliberty]

@vijayank88 is there anything further to do here on your original issue?

[mithro]

gcc / llvm error messages have gotten a lot better but they are far from perfect.

Error messages (+ logging) are like documentation and testing in that there is always more work to do and they can always be improved. Like documentation and testing they are also frequently neglected and not enough effort is put into them.

If you want we can put together a set of principles and style guide with examples of how OpenROAD (and related tools) should aspire to achieve. (This would probably be done by steal liberally from big projects with established best practices.) These can start with a set of base principles like "a user should always have an actionable next step", should include guidance on when to use the various levels and then include more specifics about how they should be formatted.

[mithro]

BTW EDA tools are famously bad at logging, warnings and error best practices. It is not uncommon for things that have no effect ending up as "critical warnings" and messages about critical design failures being "info messages". To make things worse they also have huge issues with excessive logging to the point that the log files associated with a design run start to compare to the output GDS files!

[maliberty]

@mithro that's quite true but it is also true that users have vastly different expectations. Some want to check every little detail and others don't care if the tool catches fire so long as they get a result.

[QuantamHD]

Our goal isn't only "a result" though, it's a brand new way to build things for an audience that's much larger than the existing market. We want people to be proud of the tools they use, and to be excited by what comes next rather than discouraged by cruft

@maliberty I think that's the difference between this project, and a commercial vendors.

[maliberty]

@QuantamHD nobody is arguing for bad error messages. I am just pointing out that among just the few people on this list we don't even have agreement as to what a good message is. We currently have >3k messages and curating them all is a big job (in fact we just did a pass to fix grammar and especially bad ones).

In the spirit of open source I encourage people to jump in and make things better rather than waiting for the small core team to prioritize message clarity over the numerous other competing interests.

[QuantamHD]

Totally understood Matt. I don't expect you, or anyone on the core team to do this work, nor was I implying anyone wants bad error message. I'd be happy to help contribute these small changes myself. I think what this discussion has turned into though probably deserves a different title, and is really trying to get to the heart of what the best user experience is. I definitely get your and @rovinski's point about not inundating the logs with verbose logs.

To that end I think the discussion is useful to feel out the right mindset rather than embarking on a massive project.

[vijayank88]

@vijayank88 is there anything further to do here on your original issue?

@maliberty end up with below error

[INFO] Merging GDS/OAS files...
    ./platforms/asap7/gds/asap7sc7p5t_27_R_1x_201211.gds
    ./designs/asap7/ethwish/spram_32_256_asap7.gds
ERROR: ./util/def2stream.py:130: Invalid record or data type (position=128, record number=6, cell=spram_32_256_asap7) in Layout.read
  ./util/def2stream.py:130 (class exceptions.RuntimeError)
Elapsed time: 0:13.45[h:]min:sec. CPU time: user 12.84 sys 0.60 (99%). Peak memory: 1047624KB.
cp results/asap7/ethwish/base/6_1_merged.gds results/asap7/ethwish/base/6_final.gds
cp: cannot stat 'results/asap7/ethwish/base/6_1_merged.gds': No such file or directory
make: *** [results/asap7/ethwish/base/6_final.gds] Error 1

[rovinski]

@vijayank88 where did you get the spram GDS from?

[vijayank88]

@rovinski I've used wrong GDS file for spram. Updated makefile and able to complete the flow successfully.