Added more tips.

doc/erko_hdl_design_article.txt

@@ -73,3 +73,80 @@ Ik zie twee niveaus:
    block processing foutloos (dwz what you want is what you get). Dan kunnen we er intern steeds
    van uitgaan dat de blokken data correct zijn en hoeven we dus intern geen checks meer te doen.
 
+
+Design steps:
+Make detailed design document with:
+- requirements and assumptions
+- design decisions
+- context : environment, use cases
+- architecture :
+  . dut block diagram with instances and anticipated processes,
+  . entity with generics, ports, MM interfaces.
+- verification : sim on HW
+  . list of generic ranges to cover
+  . list of input case to cover
+  . tb block diagram with dut instance, other anticipated instances and processes
+
+Implementation steps:
+- prepare empty entity and tb files (dut, mmp_, tb_, tb_tb_)
+- DUT:
+  . instantiate the reused components from the block diagram and wire them
+  .  t_reg : gradually add the functional state signals that are needed
+
+  . -- State registers
+    SIGNAL r             : t_reg;
+    SIGNAL nxt_r         : t_reg;
+
+  . -- Pipeline registers
+    SIGNAL in_data_p     : ...
+
+  . p_reg : PROCESS(dp_clk, dp_rst)
+    BEGIN
+      IF dp_rst='1' THEN
+        r <= c_reg_rst;
+      ELSIF rising_edge(dp_clk) THEN
+        r <= nxt_r;
+      END IF;
+    END PROCESS;
+
+  . p_comb : PROCESS(r, ...)  -- single process for all combinatorial logic
+                              -- complete sensitivity list contains all signals that are read, so that are
+                              -- . at right of assignment statement <= , :=
+                              -- . in the condition of an IF statement
+      -- State variable
+      VARIABLE v : t_reg;
+      -- Auxiliary variables
+      VARIABLE v_*   -- optional, use to improve code readability
+                     -- use v. only on left side? use separate v_* to clearly indicate when we use it also on the right side of assignments ?
+    BEGIN
+      v := r;      -- default keep existing state
+      v.* := ...;  -- default force specific values, e.g. set strobes to '0',
+                   -- typically do not force data, but leave it as it is to avoid
+                   -- unnecessary toggling and to ease viewing data value in Wave window
+
+      -- implement the processes from the block diagram to determine nxt_r
+      -- . this is where creativity is needed, however a good design will
+      --   guide the implementation
+      -- . use of v and r
+
+      -- next state
+      nxt_r <= v;
+    END PROCESS;
+
+  . -- Pipelining
+
+- TB: Test the functionality of the DUT:
+  . start with easiest, default use case,
+  . then verify the additional functions and features,
+  . then verify the corner cases (e.g. 0, 1, some prime value, smallest, largest),
+  . check that the TB did indeed run (i.e. no happened must not be regarded as passed),
+
+- TB_TB_: Multi test bench that runs multiple TB in parallel to achieve coverage
+  . multiple TB instances in parallel, each with other generic settings
+  . typically it is easier to run multiple TB in parallel, then to run the tests
+    that they do sequentially in one TB
+
+- MMP_DUT: DUT with MM interfaces
+
+- TB_MMP_DUT: Testbench with focus on MM interface access only, so typically no
+  need for a TB_TB_MMP.