implement S mode CSRs#878
Conversation
Benchmarks summaryPerformance benchmarks
You can view all the metrics here. Synthesis benchmarks (basic)
Synthesis benchmarks (full)
|
Benchmarks summaryPerformance benchmarks
You can view all the metrics here. Synthesis benchmarks (basic)
Synthesis benchmarks (full)
|
Benchmarks summaryPerformance benchmarks
You can view all the metrics here. Synthesis benchmarks (basic)
Synthesis benchmarks (full)
|
|
Fmax seems worrying, but the critical path seems unrelated. |
Benchmarks summaryPerformance benchmarks
You can view all the metrics here. Synthesis benchmarks (basic)
Synthesis benchmarks (full)
|
|
it can be verified with other toolchains or/and we should add option for yosys to print more top worst paths (it might hide behind the optimization target). |
This seems like the best course of action. Still, I don't want this to be a blocker for further S-mode work, and I'm willing to merge now and worry later. What do you think? |
Benchmarks summaryPerformance benchmarks
You can view all the metrics here. Synthesis benchmarks (basic)
Synthesis benchmarks (full)
|
|
It seems like my comment during the meeting was not correct:
|
|
|
|
I have made a version that would not have the The critical path there also doesn't touch CSRs - it goes around RS and ALU, so I have no idea what caused the loss of FMax. Maybe the resource usage started to impact the FMax due to contention? |
|
mayhaps but the increase is not that large, and in runs on this PR it differs a lot compared to that - ~3k change, but Fmax doesn't seem to correlate with that. Utilzization now: Due to previous comments, I would merge |
|
Merge now and worry later, then. |
|
wait, did it disappear on master? https://kuznia-rdzeni.github.io/coreblocks/dev/benchmark/ maybe we forgot how bad it is on full config and this was not an issue. Device utilization may be the case. |
closes #863