Minor router1 debug log improvements

Signed-off-by: Clifford Wolf <[email protected]>

common/router1.cc

@@ -666,12 +666,18 @@ struct Router1
 
         WireId cursor = dst_wire;
         delay_t accumulated_path_delay = 0;
+        delay_t last_path_delay_delta = 0;
         while (1) {
             auto pip = visited[cursor].pip;
 
             if (ctx->debug) {
-                log("  node %s (%+.1f)\n", ctx->nameOfWire(cursor),
-                    ctx->getDelayNS(ctx->estimateDelay(cursor, dst_wire)) - ctx->getDelayNS(accumulated_path_delay));
+                delay_t path_delay_delta = ctx->estimateDelay(cursor, dst_wire) - accumulated_path_delay;
+
+                log("  node %s (%+.2f %+.2f)\n", ctx->nameOfWire(cursor), ctx->getDelayNS(path_delay_delta),
+                    ctx->getDelayNS(path_delay_delta - last_path_delay_delta));
+
+                last_path_delay_delta = path_delay_delta;
+
                 if (pip != PipId())
                     accumulated_path_delay += ctx->getPipDelay(pip).maxDelay();
                 accumulated_path_delay += ctx->getWireDelay(cursor).maxDelay();

docs/faq.md

@@ -46,7 +46,8 @@ See [archapi.md](archapi.md) for a complete reference of the architecture API.
 ### Delay Estimates
 
 Each architecture must implement a `estimateDelay()` method that estimates the expected delay for a path from given `src` to `dst` wires.
-*It is very important that this method slightly overestimates the expected delay.* Otherwise there will be performance issues with the router.
+*It is very important that this method slightly overestimates the expected delay.* Furthermore, it should overestimate the expected delay
+by a slightly larger margin for longer paths than for shorter paths. Otherwise there will be performance issues with the router.
 
 The delays estimates returned by that method should also be as fine-grain as possible. It definitely pays off to spend some time improving the `estimateDelay()`
 for your architecture once implementing small designs work.