# Logic Design Principles

1. Constants are your friend. They optimize logic without losing generality in the source.
2. Ready/valid handshakes allow for action every clock cycle if possible and compose well. Pulses necessarily limit your max throughput by half. They are a layer of abstraction.
3. Pulse generators and pulse latches remove many FSMs and can fix race conditions (ABA problems).
4. Separate control and data: it allows you to optimise the datapath sooner and more easily. It also avoids having to explicitly describe the cartesian product of all states and outputs, which makes for tedious code that doesn't describe the design itself, but a behavioural enumeration of it, from which the design must be reverse engineered.
5. Modularity means debugging more of the *design* than its implementation
6. Writing smaller modules means a smaller context, thus more likely to avoid bugs, and easier to write meaningful code/comments. This benefit is preserved through composition.
7. Hierarchy: pulses, ready/valid, 4-phase, 2-phase (TODO: chapter to introduce/explain them, why/where use them, etc...)
8. CDC implies asynchrony, which means no notion of time, only of sequence, hence the 2ph/4ph handshakes must be present inside non-trivial CDC designs.
9. Don't generate/divide clocks: generate enables for the desired rate, synchronous to the main clock.
10. Make the code reflect the design: don't make the reader reverse-engineer the design from the implementation.
11. Non-blocking assignments for testbench logic, blocking assignment for testbench clock. (avoid races)
12. Design with retiming in mind: lets you design without worrying about where to pipeline. Makes for more readable design source. Tailors to devices/widths/etc...
13. Forward retiming works better (re: Vivado phys_opt, and general retiming algorithms)
14. Since the `clear` input, a synchronous reset, is a signal that changes the output, and derived from some control path logic, it must trigger an "output updated" signal in pulse interfaces as any other `load` or `valid` input signal, though only as a single pulse since the output only changes once even with a steady `clear`. This also implies that `clear` must be pipelined, separately and in parallel if necessary, and not broadcast to all units, which means similar latency, and better routing and distribution.
15. Amend that last one: don't signal an "output updated" value, as consecutive calculations can have identical results (so a Word Change Detector is no good here), and multiple commands can update a given output. Instead, signal when a command is done. That "done" signal also denotes when the given output is valid to sample. Internally latch the command so we know which one to report as "done" if multiple commands update one internal object (itself with a "done" signal). This does not allow concurrency or queueing by itself.
16. Following up on last one: using a "done" signal on commands also separates control and data paths.
17. Possible general design principle: connect datapaths with ready/valid handshakes at boundaries, enumerate ready/valid actions as 2-input truth table, result is computed by one of the 16 dyadic Boolean functions.
18. If a module contains latches which will hold state, then it must have a reset/clear. Else a reset of the surrounding logic would result in an inconsistent system (e.g.: a valid line from a latch stayed high after reset).

Hiding a note here:
    Wakerly - Digital Design Princicples and Practice
    Mins, Elliott - FSM-based Digital Design using the Verilog HDL
    Davis, Reese - Finite State Machine Datapath Design, Optimization, and Implementation

And another:
    Dally, Towles, Principles and Practices of Interconnection Networks (Ch.18 Arbitration)
    Dimitrakopoulos, Psarras, Seitanidis, Microarchitecture of Network-on-Chip Routers (Ch.4 Arbitration Logic)
    Dimitrakopoulos, Kachris, Kalligeros, Scalable arbiters and multiplexers for on-FPGA interconnection networks, FPL 2011
    Weber, Arbiters: Design Ideas and Coding Styles, SNUG Boston 2001