From c67217f6af1e0852d77c21055dce5e2bdc42a0bd Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 23 Jan 2020 11:24:13 +0000 Subject: [PATCH] --- HDL_workflow.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn index 62860004f..6246a0763 100644 --- a/HDL_workflow.mdwn +++ b/HDL_workflow.mdwn @@ -102,9 +102,9 @@ regarding code structure: we decided to go with small modules that are both easy you can now fullsize the graphviz window and scroll around. if it looks reasonably obvious, i.e the connections can be clearly related in your mind back to the actual code (by matching the graph names against signals and modules in the original nmigen code) and the words are not tiny when zoomed out, and connections are not total incomprehensible spaghetti, then congratulations, you have well-designed code. If not, then this indicates a need to split the code further into submodules. -The reasons for doing a proper modulatisatoion job as several-fold. +The reasons for doing a proper modularisatoion job are several-fold: -* firstly, we will not be doing a full automated layout-and-hope using alliance/ciriolis2, we will be doing leaf-node thru tree node half-automated half-manual layout. +* firstly, we will not be doing a full automated layout-and-hope using alliance/ciriolis2, we will be doing leaf-node thru tree node half-automated half-manual layout, finally getting to the floorplan, then revising and iteratively adjusting. * secondly, examining modules at the gate level (or close to it) is just good practice. poor design creeps in by *not* knowing what the tools are actually doing. * thirdly, unit testing, particularly formal proofs, is far easier on small sections of code. -- 2.30.2