Skip to content

Commit

Permalink
Add text on latency and tensions
Browse files Browse the repository at this point in the history
  • Loading branch information
VonTum committed Oct 19, 2023
1 parent 4208d59 commit 19397bc
Show file tree
Hide file tree
Showing 2 changed files with 30 additions and 0 deletions.
11 changes: 11 additions & 0 deletions philosophy/state.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,17 @@ However, state registers should not count towards the latency count. So specifyi

If this rule holds for all possible hardware designs is up for further research.

### Maximum Latency Requirements
It's the intention of the language to hide fixed-size latency as much as possible, making it easy to create pipelined designs.

Often however, there are limits to how long latency is allowed to be. The most common case is a state to itself feedback loop. If a state register must be updated every cycle, and it depends on itself, the loopback computation path may not include any latency.

For example, a FIFO with an almost_full threshold of _N_, may have at most a `ready_out -> valid_in` latency of _N_.

For state to state paths, this could be relaxed in several ways:
- If it is proven the register won't be read for some cycles, then the latency can be hidden in these cycles. (Requires complex validity checking)
- Slow the rate of state updating to the maximum latency, possibly allow automatic C-Slowing

## On State
State goes hand-in-hand with the flow descriptors on the ports of modules. Without state all a module could represent is a simple flow-through pipeline.

Expand Down
19 changes: 19 additions & 0 deletions philosophy/tensions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
# Implementation Tensions

## HW Design wants as much templating as possible --- Turing-Complete code generation can't be generically checked
### Solutions
- Don't analyze Templated Code before instantiation (C++ way)
- Default Args required, do user-facing compile based on these.
- Limit Code Generation to a limited subset that can be analyzed generically. (Lot of work, will eliminate otherwise valid code)

## Compilation Ordering: Code Generation --- Flow Analysis --- Latency Counting
Most of the time, Latency Counting is dependent on Template Instantiation. For example, a larger Memory may incur more latency overhead for reads and writes.

On the other hand, one could want a measured latency count to be usable at compile time, to generate hardware that can specifically deal with this latency. For example, a FIFO's almostFull threshold.

Another important case: Automatic Generation of compact latency using BRAM shift registers. The compiler could instantiate a user-provided module with as template argument the latency between the bridging wires, but the module may then add vary in its latency depending on the memory block size, requiring the compiler to again fiddle with the template argument.

### Solutions
- Always compile in order Template Instantiation -> Flow Analysis & Latency Counting. Explicitly state template args. Add asserts for latencies that are too high and reject designs that violate this.
- For each nested module separately, perform Template Instantiation & Latency Counting first, and allow use of measured latency of higher modules
- Add latency template arguments, allowing higher modules to set the latency of lower modules. Reject lower modules that violate this latency.

0 comments on commit 19397bc

Please sign in to comment.