Closed oharboe closed 1 week ago
Do you not want this merged? If so what is your goal?
Do you not want this merged? If so what is your goal?
I need to see CI results and fix some things. I removed you as reviewer and marked clearly as draft for now.
With a few tweaks, I would like to see it merged. Possibly rename "make memory" to "make synth-check/info" or something...
@maliberty unrelated SEGFAULT, I think...
[INFO GRT-0101] Running extra iterations to remove overflow.
Signal 11 received
Stack trace:
0# 0x0000000000DFC367 in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
1# 0x00007FEF66316400 in /lib64/libc.so.6
2# sta::TagGroup::arrivalIndex(sta::Tag*, int&, bool&) const in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
3# sta::PathVertex::PathVertex(sta::PathVertexRep const&, sta::StaState const*) in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
4# sta::CheckCrpr::maxCrpr(sta::ClkInfo*) in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
5# sta::ArrivalVisitor::pruneCrprArrivals() in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
6# sta::ArrivalVisitor::visit(sta::Vertex*) in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
7# 0x0000000001078A99 in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
8# sta::DispatchQueue::dispatch_thread_handler(unsigned long) in /tmp/workspace/ublic_tests_all-pr_PR-2075-merge/tools/install/OpenROAD/bin/openroad
9# 0x00007FEF6A252EB4 in /home/jenkins/.local/lib64/libortools.so.9
10# 0x00007FEF6AD9BEA5 in /lib64/libpthread.so.0
11# clone in /lib64/libc.so.6
Elapsed time: 0:02.52[h:]min:sec. CPU time: user 4.81 sys 3.07 (312%). Peak memory: 206076KB.
make[1]: *** [Makefile:790: do-5_1_grt] Error 11
@maliberty I can't reproduce that crash.
Upon thinking about it: perhaps you want to see the artifacts for this (possibly) intermittent failure?
The PR is good to go for my part...
restarted
@maliberty Crash is intermittent...
@maliberty This is part documentation that this is possible, part CI regression testing that build times are not affected, part a useful report.
I can immediately use this report to trim down dependencies in bazel-orfs scripts today for manually maintined dependencies. Also, this approach demonstrates some shortcomings compared to cmake's ability to automatically determine dependencies from .cpp and .h files, which is useful to know.
Knowing this information is especially useful when using e.g. Chisel/Amaranth or other RTL metaprogramming where Verilog files are generated.
Example of use. We can see that there are more .v files in dependencies for synthesis for aes, so if I change some .v file that is only used in synthesis, I still have to re-run synthesis.
Carefully maintaining dependencies can save many, many hours of build times for large projects... This is especially useful when iterating on RTL for backend modifications w.r.t. fMax where small changes to RTL that do not change dependencies can lead to large fMax effects and where only parts of the design(not all macros) need to be rebuilt. Think megaboom... 24 hour build times...
These are all the .v files that designs/asap7/aes/config.mk depends on for synthesis today:
Whereas it could be shortend to: