start on coriolis2

diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn
index f6d533283f59a5002382372bebb07b8edd982606..502882cb896a2b9e08ee3c24373fa1307139021b 100644 (file)
--- a/updates/023_2020mar26_decoder_emulator_started.mdwn
+++ b/updates/023_2020mar26_decoder_emulator_started.mdwn
@@ -87,7 +87,69 @@ More on that when it happens.
 
 # Coriolis2 experimentation started
 
-TODO by Jock http://bugs.libre-riscv.org/show_bug.cgi?id=217#c44
+Jock, a really enthusiastic and clearly skilled and experienced python
+developer, has this to say about coriolis2:
+
+    As a humble Python developer, I understand the unique status and
+    significance of the Coriolis project, nevertheless I cannot help
+    but notice that it has a huge room for improvement. I genuinely hope
+    that my participation in libre-riscv will also help improve Coriolis.
+
+This was the short version, with a much more
+[detailed insight](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005478.html)
+listed here which would do well as a bugreport.  However the time it would
+take is quite significant.  We do have funding available from NLNet,
+so if there is anyone that would like to take this on, under the supervision
+of Jean-Paul at LIP6.fr, we can look at facilitating that.
+
+One of the key insights that Jock came up with was that the coding style,
+whilst consistent, is something that specifically has to be learned, and,
+as such, being contrary to PEP8 in so many ways, creates an artificially
+high barrier and learning curve.
+
+Even particularly experienced cross-language developers such as
+myself tend to be able to *read* such code, but editing it, when
+commas separating list items are on the beginning of lines, results in
+syntax errors automatically introduced *without thinking* because we
+automatically add them *at the end* because it looks like one is missing.
+
+This is why we insisted on PEP8 in the
+[HDL workflow](http://libre-riscv.org/HDL_workflow) document.
+
+Other than that: coriolis2 is actually extremely exciting to work with.
+Anyone who has done manual PCB layout will know quite how much of a relief
+it is to have auto-routing: this is what coriolis2 has by the bucket-load,
+*as well* as auto-placement.  We are looking at half a *million* objects
+(Cells) to place.  Without an auto-router / auto-placer this is just a
+flat-out impossible task.
+
+The first step was to
+[learn and adapt coriolis2](http://bugs.libre-riscv.org/show_bug.cgi?id=178)
+which was needed to find out how much work would be involved, as much as
+anything else, in order to be able to accurately assign the fixed budgets
+to the NLNet milestones.  Following on from that, when Jock joined,
+we needed to work out a compact way to express the
+[layout of blocks](http://bugs.libre-riscv.org/show_bug.cgi?id=217#c44)
+and he's well on the way to achieving that.
+
+Some of the pictures from coriolis2 are
+[stunning](bugs.libre-riscv.org/attachment.cgi?id=29).  This was an
+experimental routing of the IEEE754 FP 64-bit multiplier.  It took
+5 minutes to run, and is around 50,000 gates: as big as most silicon
+ASICs that have formerly been done with Coriolis2, and 50% of the
+practical size that can be handed in one go to the auto-place/auto-router.
+
+Other designs using coriolis2 have been of the form where the major "blocks"
+(such as FPMUL, or Register File) are laid-out automatically in a single-level
+hierarchy, followed by full and total manual layout from that point onwawrds,
+in what is termed in the industry as a "Floorplan".
+With around 500,000 gates to do and many blocks being repeated, this approach
+is not viable for us.  We therefore need a *two* level or potentially three
+level hierarchy.
+
+[Explaining this](http://bugs.libre-riscv.org/show_bug.cgi?id=178#c146)
+to Jean-Paul was amusing and challenging.  Much bashing of heads against
+walls and keyboards was involved.  
 
 # POWER ISA decoder and Simulator