testcase framework

doc/logbooks/000-Main-Logbook

@@ -76,6 +76,60 @@ Write about this in the SystemRDL errata?
     Maybe add some words to the "clarifications" section
 
 
+================================================================================
+Unit Testing
+================================================================================
+I NEED to start building a suite of unit-tests!
+Goal:
+- Small easy-to-understand testcases
+- Parameterized testcases to rerun testcases with different cpuifs, etc.
+- coverage
+
+Split it into the following components:
+    Common testbench SV infrastructure
+        Make a generic SV framework that can be re-used everywhere
+        Use SV interfaces/classes and even `include preprocessor tricks to make it possible
+        to swap out for specific testcases:
+        - cpuif abstraction layer
+            Need to be able to swap out to different CPU interfaces easily
+        - Clocks/resets
+        - DUT instantiation
+            Will need to account for minor variations in port list somehow
+            Maybe a good time to use the .* method?
+        - Helper functions, assertion library, etc.
+
+    Testcase-specific
+        SV sequence file that issues transactions and asserts things
+
+Dispatch tests completely through pytest
+    - Each testcase has its own folder with:
+        testcase-specific SV file(s)
+        RDL file
+        pytest entry point .py file
+    - build up py utility functions that will:
+        Export the testcase-specific RDL --> SV
+        Compile and run the simulation
+            need to deal with timeouts if the RTL deadlocks somehow. Limit of how many uS to run?
+        Query sim result for pass/fail
+    - Each testcase folder will likely have multiple subtests
+        - Variations to RDL export:
+            - different cpuif
+            - pipe stages
+            - etc.
+        - Different test sequences
+            may be necessary to test the same compilation in different ways
+            I can imagine it may not be possible to do everything from a single test sequence.
+            May require the sim to reset to T-0 for fresh-slate.
+        - Handle these variations using pytest testcases & parameterizations as appropriate.
+            Possibly something like:
+                - Each pytest class --> unique compilation/elaboration
+                    pytest parameters to expand this for export variations
+                - Each pytest class method --> simulation sequence
+    - Collect coverage!
+        install the tool in a venv, collect exporter coverage, etc.
+        TBD if i want to deal with SV coverage (is that even allowed in modelsim free?)
+
+
 ================================================================================
 Dev Todo list
 ================================================================================

doc/logbooks/Signal Dereferencer

@@ -4,7 +4,7 @@ to stuff via a normalized interface.
 For example, if RDL defines:
     my_field->next = my_other_field
 Then in Python (or a template) I could do:
-    x = my_field.get_property("next")
+    x = my_field.get_property('next')
     y = dereferencer.get(x)
 and trust that I'll get a value/identifier/whatever that accurately represents
 the value being referenced

doc/logbooks/Validation Needed

@@ -82,7 +82,7 @@ X If a node ispresent=true, and any of it's properties are a reference,
     then those references' ispresent shall also be true
     This is an explicit clause in the spec: 5.3.1-i
 
-! Flag illegal sw actions if not readable/writable
+X Flag illegal sw actions if not readable/writable
     The following combinations dont get flagged currently:
         sw=w; rclr;
         sw=w; rset;
@@ -91,15 +91,15 @@ X If a node ispresent=true, and any of it's properties are a reference,
     their counterparts do get flagged. such as:
         sw=w; onread=rclr;
 
+X Signals marked as field_reset or cpuif_reset need to have activehigh/activelow
+  specified. (8.2.1-d states that activehigh/low does not have an implied default state if unset!)
+  Also aplies to signals referenced by resetsignal
+
 ! hwclr/hwset/we/wel probably shouldn't be able to reference itself
     y->hwclr = y;
     y->we = y;
     ... it works, but should it be allowed? Seems like user-error
 
-! Signals marked as field_reset or cpuif_reset need to have activehigh/activelow
-  specified. (8.2.1-d states that activehigh/low does not have an implied default state if unset!)
-  Also aplies to signals referenced by fieldreset
-
 
 
 
@@ -126,7 +126,7 @@ X Warn/error on any signal with cpuif_reset set, that is not in the top-level
 
 ! async data signals
     Only supporting async signals if they are exclusively used in resets.
-    Anyhting else declared as "async" shall be an error
+    Anyhting else declared as "async" shall emit a warning that it is ignored
     I have zero interest in implementing resynchronizers
 
 ! Error if a property references a non-signal component, or property reference from