Bug 526 - create dry-run 180nm GDS-II files for IMEC
Summary: create dry-run 180nm GDS-II files for IMEC
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Hardware Layout (show other bugs)
Version: unspecified
Hardware: PC Linux
: High normal
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 199
  Show dependency treegraph
 
Reported: 2020-11-05 12:15 GMT by Luke Kenneth Casson Leighton
Modified: 2020-12-22 12:33 GMT (History)
4 users (show)

See Also:
NLnet milestone: NLNet.2019.Coriolis2
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments
Complete log of `make lvx` output in experiments9 (59.61 KB, text/plain)
2020-11-12 17:28 GMT, Cole Poirier
Details
My log of build.sh, run in experiment9 (55.76 KB, text/x-log)
2020-11-12 23:46 GMT, Jean-Paul.Chaput
Details
output of cougar and lvx when running `./build_full.sh` (6.94 KB, text/plain)
2020-11-13 19:40 GMT, Cole Poirier
Details
Screenshot of `make view` cgt after my incomplete `build_full.sh` (805.54 KB, image/png)
2020-11-13 20:22 GMT, Cole Poirier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-11-05 12:15:04 GMT
jean-paul, reminder, staf would like to go through the submission process to IMEC, before submitting the invoice.

test_issuer *will* work, with the following instructions:

* apply the patch at https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
* git checkout full_core_ls180_prerun (it's a tag)
* cd experiments9
* edit coriolis2/ioring.py enable # core option (big, time-consuming)
       'core.size'       : ( l(28000), l(28000) ),
       'chip.size'       : ( l(30200), l(30200) ),
* run ./build_full_core.sh

i am just verifying that, now.
Comment 1 Luke Kenneth Casson Leighton 2020-11-05 12:39:23 GMT
gimme a moment i need to sort this and replicate it properly.
Comment 2 Luke Kenneth Casson Leighton 2020-11-08 15:26:25 GMT
jean-paul i can't get the old ioring operational, i started on converting
ls180 (experiment10) and am running into difficulties, can you take a look?
run "./build.sh" to get it to do the required tasks for a build.
Comment 3 Jean-Paul.Chaput 2020-11-08 16:19:27 GMT
(In reply to Luke Kenneth Casson Leighton from comment #2)
> jean-paul i can't get the old ioring operational, i started on converting
> ls180 (experiment10) and am running into difficulties, can you take a look?
> run "./build.sh" to get it to do the required tasks for a build.

  Don't invest time on the old ioring. We must use the new alpha "block"
  approach for now on. I will take a look this evening. I will also
  slightly change the interface so you no longer need to give the
  "direction" signal. The direction will be guessed from the signal
  direction, then an approriate 0/1 signal will be generated "on the fly"
  and inserted in the core top-level netlist. To place the zero/one
Comment 4 Jean-Paul.Chaput 2020-11-08 16:20:53 GMT
(In reply to Luke Kenneth Casson Leighton from comment #2)
> jean-paul i can't get the old ioring operational, i started on converting
> ls180 (experiment10) and am running into difficulties, can you take a look?
> run "./build.sh" to get it to do the required tasks for a build.

  Don't invest time on the old ioring. We must use the new alpha "block"
  approach for now on. I will take a look this evening. I will also
  slightly change the interface so you no longer need to give the
  "direction" signal. The direction will be guessed from the signal
  direction, then an approriate 0/1 signal will be generated "on the fly"
  and inserted in the core top-level netlist. To place the zero/one
  cells instances as close as possible to the I/O pad they are controlling,
  one signal will be generated per I/O pad.
Comment 5 Luke Kenneth Casson Leighton 2020-11-08 19:58:06 GMT
(In reply to Jean-Paul.Chaput from comment #4)

>   Don't invest time on the old ioring.

yep stopped 2 days ago.

> We must use the new alpha "block"
>   approach for now on. I will take a look this evening. I will also
>   slightly change the interface so you no longer need to give the
>   "direction" signal. The direction will be guessed from the signal
>   direction,

just like in ioring.

> then an approriate 0/1 signal will be generated "on the fly"
>   and inserted in the core top-level netlist. 

nuts that was the last 2 days ah well :)

at least i have the code in experiments10/doDesign.py read the ls180 pinouts JSON file and create the pinspec.


> To place the zero/one
>   cells instances as close as possible to the I/O pad they are controlling,
>   one signal will be generated per I/O pad.

ah goood, whew.

you will see i edited Makefile to stop it generating ls180.vst from ls180.il

and i added by hand an io_in and io_out to non_generated/ls180.vst which can be removed.
Comment 6 Luke Kenneth Casson Leighton 2020-11-09 15:54:37 GMT
jean-paul i added some comments to experiments10/doLayout.py which allow to understand how the static ioSpecPads has been replaced by reading from a JSON file.
Comment 7 Luke Kenneth Casson Leighton 2020-11-11 14:53:49 GMT
i have "./build.sh" operational except with "Error : connectors vss and vdd
are on the same equi" from /usr/bin/cougar

the reason for this is most probably because i commented out the ErrorMessage
warning that the pad positions were not matching up.

i fixed that in the old ioring.py with this:
https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29

by adding a new parameter "pads.useChipSize".

of course, the new code does not do that, it was copied from the old code.

now i cannot find the matching core and chip size.  either the core is too
small or the core is too large.
Comment 8 Jean-Paul.Chaput 2020-11-11 15:00:01 GMT
(In reply to Luke Kenneth Casson Leighton from comment #7)
> i have "./build.sh" operational except with "Error : connectors vss and vdd
> are on the same equi" from /usr/bin/cougar
> 
> the reason for this is most probably because i commented out the ErrorMessage
> warning that the pad positions were not matching up.
> 
> i fixed that in the old ioring.py with this:
> https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
> 
> by adding a new parameter "pads.useChipSize".
> 
> of course, the new code does not do that, it was copied from the old code.
> 
> now i cannot find the matching core and chip size.  either the core is too
> small or the core is too large.

  I hope to catch up on full test_issuer tomorrow. So have it work by
  the evening (assuming no untoward bugs pops up in the meantime).
  Today, I make work a (much) smaller test case (the Arlet6502).
Comment 9 Luke Kenneth Casson Leighton 2020-11-11 15:19:14 GMT
(In reply to Jean-Paul.Chaput from comment #8)

>   I hope to catch up on full test_issuer tomorrow. So have it work by
>   the evening (assuming no untoward bugs pops up in the meantime).
>   Today, I make work a (much) smaller test case (the Arlet6502).

good idea.

i have cut everything out of ls180.vst except io_in, io_out and one (fake) connection to a single pin (i2c_scl).

this makes ls180 "make lvx" complete in around 3-4 minutes instead of 90

even though the core size is 16000 x 16000

putting the core back (test_issuer) and the litex peripherals into ls180 will be the last task.
Comment 10 Jean-Paul.Chaput 2020-11-11 16:28:05 GMT
(In reply to Luke Kenneth Casson Leighton from comment #7)
> i have "./build.sh" operational except with "Error : connectors vss and vdd
> are on the same equi" from /usr/bin/cougar
> 
> the reason for this is most probably because i commented out the ErrorMessage
> warning that the pad positions were not matching up.
> 
> i fixed that in the old ioring.py with this:
> https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
> 
> by adding a new parameter "pads.useChipSize".
> 
> of course, the new code does not do that, it was copied from the old code.
> 
> now i cannot find the matching core and chip size.  either the core is too
> small or the core is too large.

I'm taking a first look. Did a git pull, run experiment0/build.sh,
and... No json file gets generated (but I see that pinmux is being
successfully called). Note that it's symbolic link in coriolis2/
is wrong (there is one "../" missing).
Comment 11 Luke Kenneth Casson Leighton 2020-11-11 18:16:00 GMT
(In reply to Jean-Paul.Chaput from comment #10)

> I'm taking a first look. Did a git pull, run experiment0/build.sh,
> and... No json file gets generated (but I see that pinmux is being
> successfully called). Note that it's symbolic link in coriolis2/
> is wrong (there is one "../" missing).

sorry, forgot to say.  from this (and also from comment 0)

      i have "./build.sh" operational 

i assumed it would be understood to run the ./build.sh script, and to
run it only from inside the directory (experiments9).

it's not set up to be run outside.
Comment 12 Jean-Paul.Chaput 2020-11-11 22:45:40 GMT
(In reply to Luke Kenneth Casson Leighton from comment #11)
> (In reply to Jean-Paul.Chaput from comment #10)
> 
> > I'm taking a first look. Did a git pull, run experiment0/build.sh,
> > and... No json file gets generated (but I see that pinmux is being
> > successfully called). Note that it's symbolic link in coriolis2/
> > is wrong (there is one "../" missing).
> 
> sorry, forgot to say.  from this (and also from comment 0)
> 
>       i have "./build.sh" operational 
> 
> i assumed it would be understood to run the ./build.sh script, and to
> run it only from inside the directory (experiments9).
> 
> it's not set up to be run outside.

  Mmmmhhh. That is what I did, run in the experiment9 directory.
  *But* I didn't use the "full_core_ls180_prerun" (used the latest
  master HEAD), should I do it ? I plan to integrate your json
  parser directly into the Chip class.
Comment 13 Luke Kenneth Casson Leighton 2020-11-11 23:43:42 GMT
(In reply to Jean-Paul.Chaput from comment #12)
> (In reply to Luke Kenneth Casson Leighton from comment #11)
> > (In reply to Jean-Paul.Chaput from comment #10)
> > 
> > > I'm taking a first look. Did a git pull, run experiment0/build.sh,
> > > and... No json file gets generated (but I see that pinmux is being
> > > successfully called). Note that it's symbolic link in coriolis2/
> > > is wrong (there is one "../" missing).
> > 
> > sorry, forgot to say.  from this (and also from comment 0)
> > 
> >       i have "./build.sh" operational 
> > 
> > i assumed it would be understood to run the ./build.sh script, and to
> > run it only from inside the directory (experiments9).
> > 
> > it's not set up to be run outside.
> 
>   Mmmmhhh. That is what I did, run in the experiment9 directory.

ok good, that should have worked.

pinmux was set up to run from the coriolis2 directory (relative import by ioring.py)

so as not to have 2 copies of pinmux i created a symlink.

really it should be done as a python package (with a setup.py) i haven't got round to it yet.

>   *But* I didn't use the "full_core_ls180_prerun"

no i haven't got to that, it is for later when adding the full core (ls180.il)

we are still at the drastically-cut-down handcrafted ls180.vst stage.

once that works then adding the full core and trying that is the next stage.  once that works i will tag it so that it can be snapshotted and repro'd any time.

> (used the latest
>   master HEAD),

good.

> I plan to integrate your json
>   parser directly into the Chip class.

the unicode-to-str converter? it isnot mine, it is code i found on stackexchange. it will need attribution, i will try to find the link again.
Comment 14 Luke Kenneth Casson Leighton 2020-11-12 17:11:03 GMT
JP i saw the commits this morning to the toolkit cmos45 directory, but "make lvx" fails, are there files missing, by chance? (can i copy them from ../cmos ?)
Comment 15 Jean-Paul.Chaput 2020-11-12 17:20:42 GMT
(In reply to Luke Kenneth Casson Leighton from comment #14)
> JP i saw the commits this morning to the toolkit cmos45 directory, but "make
> lvx" fails, are there files missing, by chance? (can i copy them from
> ../cmos ?)

  You mean benchs/adder/cmos45 ? As far as I can tell everything was
  committed this early morning. And the nightly self check did pass...
  Could you show me the complete log of "make lvx" ?
Comment 16 Cole Poirier 2020-11-12 17:28:30 GMT
Created attachment 115 [details]
Complete log of `make lvx` output in experiments9

Hi JP, I'm not sure if my output will be the same as Luke's, but in my case it fails because a pad is out of range of the "vdd" horizontal rail.

```
 Connect pad contact <id:8084 Pin vss METAL3 [210.L 0.L] 403.L x 4.L vss.2 SOUTH>
    HORIZONTAL rail.
    railRange:[2, 3, 4, 5, 6, 7]
    Connect to [-2] @598.L
    Try to connect to: <HorizontalRail "vdd" (2) @598.L>

 [ERROR] <id:8084 Pin vss METAL3 [210.L 0.L] 403.L x 4.L vss.2 SOUTH> is outside rail/corona X range,
         power pad is likely to be to far off west or east.
         (core:<Box 714.L 694.L 15726.L 15706.L>)
```
Comment 17 Luke Kenneth Casson Leighton 2020-11-12 19:24:54 GMT
(coriolis2)lkcl@fizzy:~/alliance-check-toolkit/benchs/adder/cmos45$ make lvx
User configuration file: ./mk/users.d/user-lkcl.mk
AVERTEC_TOP is not defined, HiTas/Yagle are not availables
Using ALLIANCE_TOP = "/home/lkcl/alliance/install".
Using PATTERNS = "patterns".
Logical synthesis is using Alliance.
Physical synthesis is using Coriolis.
| Netlist for Place & Route (PNR):
|  - "adder.vst"
Using core netlist:   "adder"
Using corona netlist: "corona.vst"
Coriolis is working in symbolic mode (vst & ap)
Using RDS_TECHNO_NAME = "/home/lkcl/alliance-check-toolkit/etc/FreePDK45.rds"
make: *** No rule to make target 'adder.vst', needed by 'chip_r.vst'.  Stop.
Comment 18 Luke Kenneth Casson Leighton 2020-11-12 19:29:40 GMT
(In reply to Cole Poirier from comment #16)
> Created attachment 115 [details]
> Complete log of `make lvx` output in experiments9

Cole we are not discussing experiments9 at the moment, this is
alliance-check-toolkit/benchs/adder/cmos45

JP if i manually do "cp ../cmos/non_generated/adder.vst ." the results are:

[ERROR] CParsVst() VHDL Parser:
        Unable to find cell "sff3_x4", please check your <./coriolis2/settings.py>.
        
        Python stack trace:
        #0 in                scriptMain() at doDesign.py:29
Comment 19 Cole Poirier 2020-11-12 19:55:03 GMT
(In reply to Luke Kenneth Casson Leighton from comment #18)
> (In reply to Cole Poirier from comment #16)
> > Created attachment 115 [details]
> > Complete log of `make lvx` output in experiments9
> 
> Cole we are not discussing experiments9 at the moment, this is
> alliance-check-toolkit/benchs/adder/cmos45
> 
> JP if i manually do "cp ../cmos/non_generated/adder.vst ." the results are:
> 
> [ERROR] CParsVst() VHDL Parser:
>         Unable to find cell "sff3_x4", please check your
> <./coriolis2/settings.py>.
>         
>         Python stack trace:
>         #0 in                scriptMain() at doDesign.py:29

Ah yes sorry, figured that out after posting the wrong log. I get the same error as you when running benchs/adder/cmos45 after manually copying adder.vst from the adder/cmos directory.
Comment 20 Luke Kenneth Casson Leighton 2020-11-12 20:01:44 GMT
JP going back to commit 5bcbe5c040 the error is the same,
"unable to find sffx3_x4"
Comment 21 Jean-Paul.Chaput 2020-11-12 21:02:38 GMT
(In reply to Luke Kenneth Casson Leighton from comment #20)
> JP going back to commit 5bcbe5c040 the error is the same,
> "unable to find sffx3_x4"

Found the problem: there was a .gitignore I was not aware of
which was preventing the commit of versions of adder.vst...
I did correct it and commited the right version of adder.vst.
Comment 22 Luke Kenneth Casson Leighton 2020-11-12 21:50:57 GMT
(In reply to Jean-Paul.Chaput from comment #21)

> Found the problem: there was a .gitignore I was not aware of
> which was preventing the commit of versions of adder.vst...
> I did correct it and commited the right version of adder.vst.

excellent that worked, ok so next step is experiments10... which...
ha!  it worked!


commit 3664562c9cbac2062229a0e879928c761ca79827
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Thu Nov 12 21:50:31 2020 +0000

    remove io_in/io_out from niolib experiments10

ls180 test is next.
Comment 23 Luke Kenneth Casson Leighton 2020-11-12 22:01:46 GMT
excellent, that worked too... but only because of this:

diff --git a/cumulus/src/plugins/alpha/chip/corona.py b/cumulus/src/plugins/alpha/chip/corona.py
index a632e09b..f929f152 100644
--- a/cumulus/src/plugins/alpha/chip/corona.py
+++ b/cumulus/src/plugins/alpha/chip/corona.py
@@ -115,9 +115,9 @@ class HorizontalRail ( Rail ):
         if    contactBb.getXMin() < self.side.innerBb.getXMin() \
            or contactBb.getXMax() > self.side.innerBb.getXMax():
             trace( 550, '-' )
-            raise ErrorMessage( 1, [ '{} is outside rail/corona X range,'.format(contact)
+            print ( WarningMessage( [ '{} is outside rail/corona X range,'.format(contact)
                                   , 'power pad is likely to be to far off west or east.'
-                                  , '(core:{})'.format(self.side.innerBb) ] ) 
+                                  , '(core:{})'.format(self.side.innerBb) ] ) )
         if self.vias.has_key(contact.getX()): return False
         trace( 550, '\tvias:{}\n'.format(self.vias) )
         keys = self.vias.keys()
@@ -222,9 +222,9 @@ class VerticalRail ( Rail ):
         contactBb = contact.getBoundingBox()
         if    contactBb.getYMin() < self.side.innerBb.getYMin() \
            or contactBb.getYMax() > self.side.innerBb.getYMax():
-            raise ErrorMessage( 1, [ '{} is outside rail/corona Y range'.format(contact)
+            print ( WarningMessage( [ '{} is outside rail/corona Y range'.format(contact)
                                    , 'power pad is likely to be to far off north or south.'
-                                   , '(core:{})'.format(self.side.innerBb) ] ) 
+                                   , '(core:{})'.format(self.side.innerBb) ] ) )
         if self.vias.has_key(contact.getY()): return False
         trace( 550, ',+', '\tVerticalRail.connect() [{}] @{}\n'.format(self.order,DbU.getValueString(self.axis)) )
         trace( 550, '\t{}\n'.format(contact) )

that option, pads/useChipSize, from https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
is needed.

moving to the gitlab coriolis2 bugreport.
Comment 24 Luke Kenneth Casson Leighton 2020-11-12 23:39:21 GMT
with commit db5f3c203190f110be02cb12ff107f206528ac9b i finally have the
(dummy, hand-edited) ls180.vst compiling, currently running cougar on
a 25,000 sized layout is taking a loooong time.

however there were no prior errors (including the ones i turned from errors
to warnings) so i expect this run to succeed.

i will know tomorrow and will try with the litex peripherals and the core.
Comment 25 Jean-Paul.Chaput 2020-11-12 23:46:09 GMT
Created attachment 116 [details]
My log of build.sh, run in experiment9
Comment 26 Jean-Paul.Chaput 2020-11-12 23:47:07 GMT
(In reply to Jean-Paul.Chaput from comment #25)
> Created attachment 116 [details]
> My log of build.sh, run in experiment9

  Dodo. Now!
Comment 27 Cole Poirier 2020-11-13 00:21:56 GMT
(In reply to Luke Kenneth Casson Leighton from comment #24)
> with commit db5f3c203190f110be02cb12ff107f206528ac9b i finally have the
> (dummy, hand-edited) ls180.vst compiling, currently running cougar on
> a 25,000 sized layout is taking a loooong time.
> 
> however there were no prior errors (including the ones i turned from errors
> to warnings) so i expect this run to succeed.
> 
> i will know tomorrow and will try with the litex peripherals and the core.

Can you commit the new hand-edited ls180.vst, currently when running build.sh in experiments9 I get the same error as earlier. Once that's fixed, mine will hopefully compile much faster than yours since I'm not limiting my cpu clock to 1 GHz.

```
Connect pad contact <id:8732 Pin vss METAL3 [460.L 0.L] 403.L x 4.L vss.3 SOUTH>
    HORIZONTAL rail.
    railRange:[2, 3, 4, 5, 6, 7]
    Connect to [-2] @298.L
    Try to connect to: <HorizontalRail "vdd" (2) @298.L>

[ERROR] <id:8732 Pin vss METAL3 [460.L 0.L] 403.L x 4.L vss.3 SOUTH> is outside rail/corona X range,
        power pad is likely to be to far off west or east.
        (core:<Box 464.L 394.L 25476.L 25406.L>)
        Python stack trace:
        #0 in                  __init__() at .../lib64/python2.7/dist-packages/crlcore/helpers/io.py:167
        #1 in                   connect() at .../dist-packages/cumulus/plugins/alpha/chip/corona.py:120
[snip]
        #9 in                  <module>() at .../coriolis-2.x/Linux.x86_64/Release.Shared/install/bin/cgt:204
Comment 28 Luke Kenneth Casson Leighton 2020-11-13 01:07:28 GMT
(In reply to Cole Poirier from comment #27)

> Can you commit the new hand-edited ls180.vst, 

it already is.  if you checked the diff from the commits which is the normal practice you would see that.

https://git.libre-soc.org/?p=soclayout.git;a=summary

> currently when running
> build.sh in experiments9 I get the same error as earlier.

you can get rid of them by applying the patch from comment 23.

however if the error is occurring it is likely because you have not updated to the commit listed in comment 24.

please make absolutely certain to read ALL comments CAREFULLY and THOROUGHLY before writing anything on this bugreport so as not to cause a distraction to Jean-Paul.
Comment 29 Cole Poirier 2020-11-13 01:43:37 GMT
(In reply to Luke Kenneth Casson Leighton from comment #28)
> (In reply to Cole Poirier from comment #27)
> 
> it already is.  if you checked the diff from the commits which is the normal
> practice you would see that.
> 
> https://git.libre-soc.org/?p=soclayout.git;a=summary

I did. I just thought I was missing it because I kept getting an error (see below).

> you can get rid of them by applying the patch from comment 23.

This was the key (although with some trickiness, see below).

> however if the error is occurring it is likely because you have not updated
> to the commit listed in comment 24.

No, I was fully up to date. Would not post here without first pulling the latest commits and reviewing the change log.

> please make absolutely certain to read ALL comments CAREFULLY and THOROUGHLY
> before writing anything on this bugreport so as not to cause a distraction
> to Jean-Paul.

I do.

I did all of that actually. I just went and read through the file you showed the patch for in comment #23, and with manual review I saw that patching the source and reinstalling hadn't installed the patched version but the old one. Actually even patching the files in the coriolis install dir did nothing. Finally, manually changing the two 'raise ErrorMessage' to 'print ( WarningMessage...' worked, running cougar now.
Comment 30 Cole Poirier 2020-11-13 02:16:24 GMT
Cougar finished running. This is all that it printed out:

```
---> Extract symbolic figure chip_r

	netlist.536 Warning : Generates core_equi file !

	netlist.543 Error : connectors "vss" and "vdd" are on the same equi !

make: *** [mk/alliance.mk:50: chip_r_ext.al] Error 1
```

`make view` looks nice, and very complex.
Comment 31 Luke Kenneth Casson Leighton 2020-11-13 18:03:17 GMT
jean-paul i've got the (partial) core P&R underway, all corona pins match
the litex peripherals, the actual PowerISA core is excluded, we have one
Horizontal route "uncompleted".  time taken to route is of the order of
5-8 mins which is semi-reasonable for iteration (cougar still takes forever)
Comment 32 Jean-Paul.Chaput 2020-11-13 18:27:58 GMT
(In reply to Luke Kenneth Casson Leighton from comment #31)
> jean-paul i've got the (partial) core P&R underway, all corona pins match
> the litex peripherals, the actual PowerISA core is excluded, we have one
> Horizontal route "uncompleted".  time taken to route is of the order of
> 5-8 mins which is semi-reasonable for iteration (cougar still takes forever)

  Yes, very good. But I still cannot do it on my end... Could you take
  a look to the log of build.sh (attachment 115 [details]) to hint me at what's
  wrong (still do not get the JSON file generated).

  Note that I fully redo the procedure with the libraries supplied by
  Staf which are under NDA so I cannot show them to you. The routing
  will differs du to cell layout differences.
Comment 33 Luke Kenneth Casson Leighton 2020-11-13 18:35:35 GMT
(In reply to Jean-Paul.Chaput from comment #32)
> (In reply to Luke Kenneth Casson Leighton from comment #31)

>   Yes, very good. But I still cannot do it on my end... Could you take
>   a look to the log of build.sh (attachment 115 [details]) to hint me at
> what's
>   wrong (still do not get the JSON file generated).

sorry, not build.sh this time: ./build_full.sh (copies over a different
file, this time it is non_generated/full_core_ls180.il rather than
non_generated/ls180.vst)

build.sh will not work now (does @ a few commits ago) because the
hand-coded ls180.vst needs to be updated to match exactly the
ILANG file.

>   Note that I fully redo the procedure with the libraries supplied by
>   Staf which are under NDA so I cannot show them to you.

not a problem

> The routing will differs du to cell layout differences.

interesting.  not an important question, just curious: why are the ghost
cells different from the real ones? different placement of internal parts?
Comment 34 Cole Poirier 2020-11-13 19:08:48 GMT
(In reply to Jean-Paul.Chaput from comment #32)
>
>   Yes, very good. But I still cannot do it on my end... Could you take
>   a look to the log of build.sh (attachment 115 [details]) to hint me at
> what's
>   wrong (still do not get the JSON file generated).

I had this problem yesterday JP. Try manually running `git submodule update --init --recursive`, I think that's what fixed it for me. Then you should *hopefully* be able to simply run `./build_full.sh` and have it run at least into the cougar part of the process (cougar started running about 5 min ago, so I should have some results to report in the next 15 minutes to 1 hour).
Comment 35 Luke Kenneth Casson Leighton 2020-11-13 19:39:52 GMT
(In reply to Cole Poirier from comment #34)

> I had this problem yesterday JP. Try manually running `git submodule update
> --init --recursive`,

hm git submodule --init --remote is supposed to be enough, and is in build_full.sh

i will try it and add it if necessary.
Comment 36 Cole Poirier 2020-11-13 19:40:26 GMT
Created attachment 117 [details]
output of cougar and lvx when running `./build_full.sh`

(In reply to Cole Poirier from comment #34)

> cougar started running about 5 min ago,
> so I should have some results to report in the next 15 minutes to 1 hour).

Hi JP and Luke, see this attachment for the output of cougar and lvx when running `./build_full.sh`, it ran for about 30 min before stopping due to "Too many errors. Cannot continue further more" then "Have a nice day...".
Comment 37 Luke Kenneth Casson Leighton 2020-11-13 19:45:45 GMT
(In reply to Cole Poirier from comment #36)

`ls180_cts` Error 38 line 917914 :width or/and type mismatch
`ls180_cts` Error 38 line 917915 :width or/and type mismatch

that means you haven't updated alliance and coriolis2.
Comment 38 Cole Poirier 2020-11-13 19:51:10 GMT
(In reply to Luke Kenneth Casson Leighton from comment #37)
> (In reply to Cole Poirier from comment #36)
> 
> `ls180_cts` Error 38 line 917914 :width or/and type mismatch
> `ls180_cts` Error 38 line 917915 :width or/and type mismatch
> 
> that means you haven't updated alliance and coriolis2.

I just went and did `git pull` in each of the three directories alliance, alliance-check-toolkit, and coriolis2 and they all gave me "Already up to date."

Should I revert your patch? That's the only thing I can think of that would be different between my local source and the one on gitlab.
Comment 39 Luke Kenneth Casson Leighton 2020-11-13 20:05:37 GMT
(In reply to Cole Poirier from comment #38)

> I just went and did `git pull` in each of the three directories alliance,
> alliance-check-toolkit, and coriolis2 and they all gave me "Already up to
> date."

did you also run the build instructions shown in https://libre-soc.org/HDL_workflow/coriolis2/ ?
Comment 40 Cole Poirier 2020-11-13 20:15:30 GMT
(In reply to Luke Kenneth Casson Leighton from comment #39)
> (In reply to Cole Poirier from comment #38)
> 
> > I just went and did `git pull` in each of the three directories alliance,
> > alliance-check-toolkit, and coriolis2 and they all gave me "Already up to
> > date."
> 
> did you also run the build instructions shown in
> https://libre-soc.org/HDL_workflow/coriolis2/ ?

Yes. I wrote and scripted those instructions.
Comment 41 Cole Poirier 2020-11-13 20:22:15 GMT
Created attachment 118 [details]
Screenshot of `make view` cgt after my incomplete `build_full.sh`

Here's a quick look at the results produced by my last running. Reinstalling all of the tools now, and will try a fresh build.
Comment 42 Jean-Paul.Chaput 2020-11-13 22:36:54 GMT
(In reply to Luke Kenneth Casson Leighton from comment #35)
> (In reply to Cole Poirier from comment #34)
> 
> > I had this problem yesterday JP. Try manually running `git submodule update
> > --init --recursive`,
> 
> hm git submodule --init --remote is supposed to be enough, and is in
> build_full.sh
> 
> i will try it and add it if necessary.

  OK. Did that plus a git pull and ran build_full.sh, and it worked.
  I have the json file. My question now is, could you elaborate on
  it's structure (give a small example perhaps) about it's semantic?
  So I can adapt it to the new style chip making.
Comment 43 Luke Kenneth Casson Leighton 2020-11-13 23:38:40 GMT
(In reply to Jean-Paul.Chaput from comment #42)
> (In reply to Luke Kenneth Casson Leighton from comment #35)
> > (In reply to Cole Poirier from comment #34)
> > 
> > > I had this problem yesterday JP. Try manually running `git submodule update
> > > --init --recursive`,
> > 
> > hm git submodule --init --remote is supposed to be enough, and is in
> > build_full.sh
> > 
> > i will try it and add it if necessary.
> 
>   OK. Did that plus a git pull and ran build_full.sh, and it worked.

excellent.  there are some errors but rhey do not stop the build (still a corona error on vss and vdd for example)

>   I have the json file. My question now is, could you elaborate on
>   it's structure (give a small example perhaps) about it's semantic?

well, it was originally just pads.instances (the list of lists)

however the change to niolib i had to "construct" the new format including the IoPad.SOUTH by parsing additional information from the pinmux json file that, really, should be done *by* rhe pinmux program.

if given a choice i would simply use that exact format (the niolib list of lists IOPadsSpec), and get the pinmux program to generate that.

now, one other useful idea: have the entire chipconf constructed by json.

stored as a dict, every key of the toplevel dict is a name of a property in the chipconf class.

this is easy to do with setattr:

jd = json.load()
cconf = ChipConf()
for k, v in jd.items():
   setattr(cconf, k, v)

although that is messy, it can be hidden behind cconf.update(jd)
Comment 44 Luke Kenneth Casson Leighton 2020-11-14 16:34:35 GMT
jean-paul i have some pad-directions which i am sorting out (litex errors)
and you can keep grabbing the latest soclayout whilst i sort that.

however the key question is: do you want a bigger ASIC to send as the
dry-run GDS-II test?  currently (commit cb8d46535056) the actual PowerISA
core is cut out, leaving only litex peripherals.  this means one 4k SRAM
@ 64bit wide which is what Staf agreed to design.

(edit: related - https://bugs.libre-soc.org/show_bug.cgi?id=502#c5 )
Comment 45 Staf Verhaegen 2020-11-16 13:36:58 GMT
(In reply to Luke Kenneth Casson Leighton from comment #44)
 
> however the key question is: do you want a bigger ASIC to send as the
> dry-run GDS-II test?  currently (commit cb8d46535056) the actual PowerISA
> core is cut out, leaving only litex peripherals.  this means one 4k SRAM
> @ 64bit wide which is what Staf agreed to design.

The SRAM design is not in a state to be able to be part of the dry-run; I did not plan it to be part of the dry-run.
Comment 46 Luke Kenneth Casson Leighton 2020-11-16 14:39:58 GMT
(In reply to Staf Verhaegen from comment #45)

> The SRAM design is not in a state to be able to be part of the dry-run; I
> did not plan it to be part of the dry-run.

ok no problem here.
Comment 47 Jean-Paul.Chaput 2020-11-24 10:44:21 GMT
Hello Luke & Al,

Not a daily kan-ban, more like a bi-monthly...

* Coriolis is now able to generate DRC correct GDSII for TMSC C180 technology,
  Tested on the Arlet 6502 from alliance-check-toolkit.
    Used this example, because sometimes I need to run with debug support
  enabled which is 4 times slower than normal (more than 10 times if you
  stack valgrind on top...).

My next steps are:

* Try to optimize the METAL2 routing pitch which is very bad (almost 100% loss),
  I have a simple modification in mind and will strictly limit this work to
  one day.
* Integrate the JSON reader (output of pinmux) in Coriolis to get the I/O pad
  positions.
* Proceed with experiment9 (hollow, then full design).

No timetable though, be only assured that I work as fast as I can to catch up.


Can't find where the question was originally posted, but with nsxlib, you will
get completly diffirent results to what I got with TSMC/FlexLib. If we want to
have the same without infringing the NDA, we would need to create a "degenerate"
version of FlexLib. With very strict requirements. To preserve Coriolis determinism,
you would have to:

* Have the exact same number of shapes (to keep id order).
* The exact same geometric relationship between shapes (to keep sorting order).

Then we should have "same results".

Best regards,
Comment 48 Luke Kenneth Casson Leighton 2020-11-24 12:08:26 GMT
(In reply to Jean-Paul.Chaput from comment #47)

> * Integrate the JSON reader (output of pinmux) in Coriolis to get the I/O pad
>   positions.

remember, it currently outputs something more like ioring.py not niolib.

> * Proceed with experiment9 (hollow, then full design).
> 
> No timetable though, be only assured that I work as fast as I can to catch
> up.

star, no problem.
Comment 49 Luke Kenneth Casson Leighton 2020-11-25 01:46:36 GMT
JP just re-ran that ./build_full.sh (bear in mind the POWERISA core is still
not included in that, it is just litex peripherals) and it is still successful.
one route is not successful however i just noticed that this exact same
unsuccessful unrouted track is one that had 2 "repair events" on it.
Comment 50 Cole Poirier 2020-11-25 02:14:35 GMT
(In reply to Luke Kenneth Casson Leighton from comment #49)
> JP just re-ran that ./build_full.sh (bear in mind the POWERISA core is still
> not included in that, it is just litex peripherals) and it is still
> successful.
> one route is not successful however i just noticed that this exact same
> unsuccessful unrouted track is one that had 2 "repair events" on it.

I was able to reproduce this successfully.
Comment 51 Jean-Paul.Chaput 2020-11-25 21:25:03 GMT
(In reply to Luke Kenneth Casson Leighton from comment #49)
> JP just re-ran that ./build_full.sh (bear in mind the POWERISA core is still
> not included in that, it is just litex peripherals) and it is still
> successful.
> one route is not successful however i just noticed that this exact same
> unsuccessful unrouted track is one that had 2 "repair events" on it.

  I'm now ready to attack that part. DRC is OK, I am looking into JSON.

  Don't give too much importance to the final results, I am using Staf
  FlexLib which has 17 METAL2 tracks instead of 10 for the nsxlib
  version. So I expect to route with much less problems...
    What matters here is that the flow by itself works (reading the
  netlist and the positions of the I/O pads).

  Best regards,
Comment 52 Luke Kenneth Casson Leighton 2020-11-26 00:18:01 GMT
(In reply to Jean-Paul.Chaput from comment #51)

>   I'm now ready to attack that part. DRC is OK, I am looking into JSON.


>   Don't give too much importance to the final results, I am using Staf
>   FlexLib which has 17 METAL2 tracks instead of 10 for the nsxlib
>   version. So I expect to route with much less problems...

ok - can you add that to alliance-check-toolkit, and set up an example?
(is there a Phantom version of FlexLib that's publicly available? i was
under the impression that there would be!)

i'd very much prefer that we're "tracking" what you're doing (right up
to the point where the "real" (NDA'd) version of FlexLib is used) and
have full public replicability.

>     What matters here is that the flow by itself works (reading the
>   netlist and the positions of the I/O pads).

at this stage, i take it.  ok.
Comment 53 Staf Verhaegen 2020-11-26 08:53:28 GMT
(In reply to Luke Kenneth Casson Leighton from comment #52)
> (In reply to Jean-Paul.Chaput from comment #51)
> 
> ok - can you add that to alliance-check-toolkit, and set up an example?
> (is there a Phantom version of FlexLib that's publicly available? i was
> under the impression that there would be!)
> 
> i'd very much prefer that we're "tracking" what you're doing (right up
> to the point where the "real" (NDA'd) version of FlexLib is used) and
> have full public replicability.

The FlexLib is designed to make use of possibilities of each technology as much as possible. Result is that the P&R results will differ for each technology. In that respect I think it is very difficult to make a replica technology that does not violate the NDA. Therefor I targeted FlexLib P&R results to be only reproducible by people who are under NDA.

What is planned is to provide the netlist + placement of the cells of what is taped. This information together with an implementation of the cells in an open technology like freepdk45 or Sky130 should allow full verification of the design:

* first given the netlist one should be able to verify that the logic is fully equivalent with the RTL design.
* second given the placement + layout of the cells in open PDK should allow to verify that actual produced chip is the one that is taped by delidding an decapsulating the chip.
Comment 54 Jean-Paul.Chaput 2020-11-26 11:58:07 GMT
(In reply to Staf Verhaegen from comment #53)
> (In reply to Luke Kenneth Casson Leighton from comment #52)
> > (In reply to Jean-Paul.Chaput from comment #51)
> > 
> > ok - can you add that to alliance-check-toolkit, and set up an example?
> > (is there a Phantom version of FlexLib that's publicly available? i was
> > under the impression that there would be!)
> > 
> > i'd very much prefer that we're "tracking" what you're doing (right up
> > to the point where the "real" (NDA'd) version of FlexLib is used) and
> > have full public replicability.

  I completely understand that. I *may* be able to provide an obfuscated
  version of FlexLib which should not infringe the NDA. But, two problems:

  1. It would take a little time (to be 100% sure that nothing under NDA
     is still present). And I am critically low on that.

  2. Even if [1] is fullfilled, Staf is against it at the moment, because
     of potential FUD from the foundry. And he do not want to take any
     action that could jeopardize his relationship with IMEC/Foundry.


> The FlexLib is designed to make use of possibilities of each technology as
> much as possible. Result is that the P&R results will differ for each
> technology. In that respect I think it is very difficult to make a replica
> technology that does not violate the NDA. Therefor I targeted FlexLib P&R
> results to be only reproducible by people who are under NDA.

  I beg to differ, I am confident I could make it, but time is short
  right now.


> What is planned is to provide the netlist + placement of the cells of what
> is taped. This information together with an implementation of the cells in
> an open technology like freepdk45 or Sky130 should allow full verification
> of the design:
> 
> * first given the netlist one should be able to verify that the logic is
> fully equivalent with the RTL design.
> * second given the placement + layout of the cells in open PDK should allow
> to verify that actual produced chip is the one that is taped by delidding an
> decapsulating the chip.

  You mean to provide the placement done with *FlexLib+real foundry* ?
  Because otherwise, the placements are likely to differ. And without the
  wiring, how do you intend to check the layout correctness ?
Comment 55 Luke Kenneth Casson Leighton 2020-11-26 12:14:06 GMT
first priority: get chip done.

second priority: interns perhaps next year do phantom library. as 2nd priority.

third priority: skylake PDK has no problem. can look at targetting that. as 3rd priority.
Comment 56 Staf Verhaegen 2020-11-26 12:24:54 GMT
(In reply to Jean-Paul.Chaput from comment #54)
> (In reply to Staf Verhaegen from comment #53)
> > (In reply to Luke Kenneth Casson Leighton from comment #52)
> > > (In reply to Jean-Paul.Chaput from comment #51)
> > > 
> > > ok - can you add that to alliance-check-toolkit, and set up an example?
> > > (is there a Phantom version of FlexLib that's publicly available? i was
> > > under the impression that there would be!)
> > > 
> > > i'd very much prefer that we're "tracking" what you're doing (right up
> > > to the point where the "real" (NDA'd) version of FlexLib is used) and
> > > have full public replicability.
> 
>   I completely understand that. I *may* be able to provide an obfuscated
>   version of FlexLib which should not infringe the NDA. But, two problems:
> 
>   1. It would take a little time (to be 100% sure that nothing under NDA
>      is still present). And I am critically low on that.
> 
>   2. Even if [1] is fullfilled, Staf is against it at the moment, because
>      of potential FUD from the foundry. And he do not want to take any
>      action that could jeopardize his relationship with IMEC/Foundry.

I will indeed not provide the needed information from my upstream version of FlexLib nor will I take reproducibility for non-NDA people into account during further development of FlexLib.

I don't forbid users of FlexLib to distribute information for reproducibility if they think they can do it without violating the NDA.

> > * second given the placement + layout of the cells in open PDK should allow
> > to verify that actual produced chip is the one that is taped by delidding an
> > decapsulating the chip.
> 
>   You mean to provide the placement done with *FlexLib+real foundry* ?

Yes, with coordinates in integer grid points not real dimension.

>   Because otherwise, the placements are likely to differ. And without the
>   wiring, how do you intend to check the layout correctness ?

You have the nets in the netlist and can trace back the connections on the decapsulated chip. So you can verify the interconnect on the real chip with the one in the netlist.
If the problem is that you don't trust the guy doing the P&R himself and want to check him, you need to get NDA yourself.
Comment 57 Jean-Paul.Chaput 2020-11-27 13:46:22 GMT
I'm finally reaching the point where I P&R the ls180, but I get an error.
It seems that there are pad definition for the PLL, but the PLL is not
present in the core, so the core2chip choke on that (tries to guess the
kind of pad from the core signal). Faulty signal is "sys_pll_48_o", but
all the PLL related ones should be in the same case.

I did try to get back to the master spec that is feeded to pinmux that
generate the JSON file. But I was not able to get it.
Comment 58 Cole Poirier 2020-11-27 16:09:40 GMT
(In reply to Jean-Paul.Chaput from comment #57)
> I'm finally reaching the point where I P&R the ls180, but I get an error.
> It seems that there are pad definition for the PLL, but the PLL is not
> present in the core, so the core2chip choke on that (tries to guess the
> kind of pad from the core signal). Faulty signal is "sys_pll_48_o", but
> all the PLL related ones should be in the same case.
> 
> I did try to get back to the master spec that is feeded to pinmux that
> generate the JSON file. But I was not able to get it.

Hi JP, if Luke doesn’t get to this before me, I’ll take a look and see if I can fix this. I have an idea of what may be going wrong, it’s related to configuration parameters passed to the configuration stage of the litex compilation That generates ls180.il.
Comment 59 Luke Kenneth Casson Leighton 2020-11-27 17:54:03 GMT
(In reply to Jean-Paul.Chaput from comment #57)

> I'm finally reaching the point where I P&R the ls180, but I get an error.
> It seems that there are pad definition for the PLL, but the PLL is not
> present in the core, so the core2chip choke on that (tries to guess the
> kind of pad from the core signal). Faulty signal is "sys_pll_48_o", but
> all the PLL related ones should be in the same case.

here's where the signal sys_pll_48 shows up in files:

(coriolis2)lkcl@fizzy:~/soclayout/experiments9$ grep -r sys_pll_48
non_generated/partial_core_ls180.il:  wire output 4 \sys_pll_48_o
non_generated/partial_core_ls180.il:  connect \sys_pll_48_o \main_libresocsim_libresoc_pll_48_o
non_generated/ls180.vst:       ; sys_pll_48_o    : out bit

there is *no presence* of sys_pll_48_o associated with the command 
./build_full.sh

   $ cat ./build_full.sh
   ...
   ...
   cp non_generated/full_core_ls180.il ls180.il
   ...
   ...

partial_core_ls180.il is not copied over by build_full.sh.
ls180.vst is not copied over either.

if however you are (by mistake) running ./build.sh:

   $ cat ./build.sh
   ...
   ...
   cp non_generated/ls180.vst .
   ...

then we would expect the error that you're seeing to occur (because it's
an out-of-date command).  i've updated it as of this commit to comment that
it should not be used:

    commit 3a7825e6c2a4070ef997a68490822c6c4661dc96


however, if you *are* using ./build_full.sh then we have some further
investigation to do.

git submodule should be at this:

(coriolis2)lkcl@fizzy:~/soclayout/experiments9$ git submodule
 f5495dcca0e6c7ce85743df7f93206ac77b8cd64 ../pinmux (remotes/origin/HEAD)

and git log in soclayout should be at this:

commit 3a7825e6c2a4070ef997a68490822c6c4661dc96
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Fri Nov 27 17:50:53 2020 +0000

    add comment do not use build.sh
Comment 60 Luke Kenneth Casson Leighton 2020-11-27 18:04:26 GMT
just saw this, Jean-Paul:
https://gitlab.lip6.fr/vlsi-eda/coriolis/-/commit/85d943a3e48515a5d95ebcef8f895f86e76906c7

looks good!  a little different from what i have in experiments9/doDesign.py

i've not made any changes to soclayout (other than to put a warning/exit
into build.sh), am re-running ./build_full.sh to check that it completes
[up to cougar/lvx]

[edit: completes - with same lvx width and/or type mismatch errors caused
 by deliberately removed core which, if we added, would increase P&R to
 45+ minutes, up from around 5-10 right now]
Comment 61 Jean-Paul.Chaput 2020-11-28 17:29:00 GMT
I'm finally reaching the point where I P&R the ls180, but I get an error.
It seems that there are pad definition for the PLL, but the PLL is not
present in the core, so the core2chip choke on that (tries to guess the
kind of pad from the core signal). Faulty signal is "sys_pll_48_o", but
all the PLL related ones should be in the same case.

I did try to get back to the master spec that is feeded to pinmux that
generate the JSON file. But I was not able to get it.(In reply to Luke Kenneth Casson Leighton from comment #59)
> (In reply to Jean-Paul.Chaput from comment #57)
> 
> > I'm finally reaching the point where I P&R the ls180, but I get an error.
> > It seems that there are pad definition for the PLL, but the PLL is not
> > present in the core, so the core2chip choke on that (tries to guess the
> > kind of pad from the core signal). Faulty signal is "sys_pll_48_o", but
> > all the PLL related ones should be in the same case.
> 
> here's where the signal sys_pll_48 shows up in files:
> 
> (coriolis2)lkcl@fizzy:~/soclayout/experiments9$ grep -r sys_pll_48
> non_generated/partial_core_ls180.il:  wire output 4 \sys_pll_48_o
> non_generated/partial_core_ls180.il:  connect \sys_pll_48_o
> \main_libresocsim_libresoc_pll_48_o
> non_generated/ls180.vst:       ; sys_pll_48_o    : out bit


  My previous message was ambiguous, the problem is that "sys_pll_48_o"
  do *not* appear in the core, *but* appear in the JSON file describing
  the I/O pads. If I grep, I get:

  jpc@lepka:experiments9$ grep -Rl sys_pll_48 *
  coriolis2/ls180/ls180_pins.py
  coriolis2/ls180/litex_pinpads.json
  ls180/ls180_pins.py
  ls180/litex_pinpads.json
  non_generated/partial_core_ls180.il
  non_generated/ls180.vst

  The problem being with this one:
  coriolis2/ls180/litex_pinpads.json

  It refers "sys_pll_48_o", which is not in the core, so core2chip fails.

  Maybe this isn't the right file?

  I should be up to date and I always used "build_full.sh".
Comment 62 Luke Kenneth Casson Leighton 2020-11-28 18:46:56 GMT
ok that says, for some reason, that you have an outdated submodule and, possibly, a 2nd copy of the pinmux in a location that is being imported from python path where it should not be (i moved the ls180 symlink some weeks ago)

is it the case that coriolis2 is appended to PYTHONPATH or sys.path?

can you please blow away any symlinks to ls180 (in coriolis2) 

absolute last resort re-clone soclayout.
Comment 63 Luke Kenneth Casson Leighton 2020-11-29 15:02:16 GMT
(In reply to Jean-Paul.Chaput from comment #61)

>   jpc@lepka:experiments9$ grep -Rl sys_pll_48 *
>   coriolis2/ls180/ls180_pins.py
>   coriolis2/ls180/litex_pinpads.json
>   ls180/ls180_pins.py
>   ls180/litex_pinpads.json

what's happening is: i *used* to have the auto-generated ls180_pins.py
in the coriolis2 directory, however because doDesign.py needs it, i
had to move the symlink to the directory below.

and because i believe (suspect) coriolis2 modifies sys.path (or PYTYHONPATH)
to make coriolis2 a module-search directory:

     export PYTHONPATH="./coriolis2" or
     sys.path.append("./coriolis2")

something like that, yes?

if that's the case then "from ls180.ls180_pins import X" will have the
*DUPLICATE* (wrong, old, redundant) version of ls180_pins.py, which you
will find is completely out-of-date and was generated well over a month
ago...

... as the *higher* priority import in sys.path than the cwd.

if however it *is* up-to-date (the symlinks) then you need to check the
submodule.  use the following commands:


   $ git diff

this should produce NOTHING.  it should **NOT** say, for example:

    - submodule pinmux {xxxxxx}
    + submodule pinmux {xxxxxxxx}

if it does, you have submodules out-of-date (usually due to editing and
commits that have not yet been pushed) and should do:

    git reset --hard
    git submodule update --init --remote

basically you are highly likely to have an out-of-date pinmux submodule.
you need to be up-to-date with this submodule commit:

   (coriolis2)lkcl@fizzy:~/soclayout/experiments9$ git submodule
   f5495dcca0e6c7ce85743df7f93206ac77b8cd64 ../pinmux (remotes/origin/HEAD)

until that is the case, it is absolutely guaranteed that you will systematically fail to be able to compile this code.
Comment 64 Jean-Paul.Chaput 2020-11-29 22:17:37 GMT
Hello Luke,

I will investigate tomorrow your explanation. I've succeeded in getting
it to work by re-cloning the repository.

So I've successfully done the P&R with Staf FlexLib & I/O pads. I will
commit that work under experiments11. Only I or Staf will be able to
run it because it needs the NDA (this directory, however, will not
contains any classified information).

The P&R works ok and it is DRC clean (with the golden tool Mentor/Calibre).

Some points:

* Could it be possible for the JSON file to be human-readable formatted?
  It will not induce significant slowdown and I will be able to perform
  manual tweaks more easily.

* In your json file, you seems to have inverted vdd/vss on the I/O pads.
  "vdd" should be connecteds to "power" and "vss" to "ground".

* The power pads are too far off the side, at least put one ordinary pad
  at the very begin/end of each side.

* Display is still abnormally slow. Another thing to look at after tapeout.

I will try to take a picture and post it.
Comment 65 Cole Poirier 2020-11-29 22:29:27 GMT
(In reply to Jean-Paul.Chaput from comment #64)
> [snip]
> * In your json file, you seems to have inverted vdd/vss on the I/O pads.
>   "vdd" should be connecteds to "power" and "vss" to "ground".
> 
> * The power pads are too far off the side, at least put one ordinary pad
>   at the very begin/end of each side.

This should hopefully resolve the error we were running into. Luke created the hack/patch of changing the behavior of alpha/chip/corona.py from erroring when a contact is outside rail corona X/Y range to just raising a warning, such that the compilation would run to completion, but with errors in the P&R layout. See diff below:

```
diff --git a/cumulus/src/plugins/alpha/chip/corona.py b/cumulus/src/plugins/alpha/chip/corona.py
index c86fc70a..a19425aa 100644
--- a/cumulus/src/plugins/alpha/chip/corona.py
+++ b/cumulus/src/plugins/alpha/chip/corona.py
@@ -120,9 +120,9 @@ class HorizontalRail ( Rail ):
         if    contactBb.getXMin() < self.side.innerBb.getXMin() \
            or contactBb.getXMax() > self.side.innerBb.getXMax():
             trace( 550, '-' )
-            raise ErrorMessage( 1, [ '{} is outside rail/corona X range,'.format(contact)
+            print ( WarningMessage( [ '{} is outside rail/corona X range,'.format(contact)
                                   , 'power pad is likely to be to far off west or east.'
-                                  , '(core:{})'.format(self.side.innerBb) ] ) 
+                                  , '(core:{})'.format(self.side.innerBb) ] ) )
         if self.vias.has_key(contact.getX()): return False
         trace( 550, '\tvias:{}\n'.format(self.vias) )
         keys = self.vias.keys()
@@ -232,9 +232,9 @@ class VerticalRail ( Rail ):
         contactBb = contact.getBoundingBox()
         if    contactBb.getYMin() < self.side.innerBb.getYMin() \
            or contactBb.getYMax() > self.side.innerBb.getYMax():
-            raise ErrorMessage( 1, [ '{} is outside rail/corona Y range'.format(contact)
+            print ( WarningMessage( [ '{} is outside rail/corona Y range'.format(contact)
                                    , 'power pad is likely to be to far off north or south.'
-                                   , '(core:{})'.format(self.side.innerBb) ] ) 
+                                   , '(core:{})'.format(self.side.innerBb) ] ) )
```

> * Display is still abnormally slow. Another thing to look at after tapeout.

I have already investigated this because I was curious. I found the problem and solution. Let's talk after the tapeout :)
Comment 66 Jean-Paul.Chaput 2020-11-30 11:19:50 GMT
Just pushed experiments11 in soclayout git repository.

Note that it cannot be run without the NDA part of Coriolis2.
You may place under non_generated the full chip .il and the associated .json for the I/O pad placement so I can pull them and P&R them. Maybe with different names.
I am usually against copying/duplicating file, but in this instance it
will allow us to work in parallel and choosing when we want to synch.
Comment 67 Luke Kenneth Casson Leighton 2020-11-30 13:05:04 GMT
(In reply to Jean-Paul.Chaput from comment #64)
> Hello Luke,
> 
> I will investigate tomorrow your explanation. I've succeeded in getting
> it to work by re-cloning the repository.

honestly don't bother!  re-cloning is Bad(tm) but if it works, it works.


> So I've successfully done the P&R with Staf FlexLib & I/O pads. I will
> commit that work under experiments11. Only I or Staf will be able to
> run it because it needs the NDA (this directory, however, will not
> contains any classified information).

sigh.  now we have two sets of identical work to maintain.  so, when i add the core back in, you have to duplicate that.


> The P&R works ok and it is DRC clean (with the golden tool Mentor/Calibre).

excellent.

> Some points:
> 
> * Could it be possible for the JSON file to be human-readable formatted?

with some independent parser tool, probably yes.  unix philosophy applies.

>   It will not induce significant slowdown and I will be able to perform
>   manual tweaks more easily.

mmm... if you're doing manual tweaks to an auto-generated (machine-generated) file this raises alarm bells in my mind.


> * In your json file, you seems to have inverted vdd/vss on the I/O pads.
>   "vdd" should be connecteds to "power" and "vss" to "ground".

ah ok good catch.

> * The power pads are too far off the side, at least put one ordinary pad
>   at the very begin/end of each side.

again, to remind you: https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29

this is exactly what i fixed and dealt with as part of the "pads.useChipSize" parameter.

by using the core size not the chip size then regardless of the chip size
the positions of the IOpads align up perfectly with the core.
Comment 68 Luke Kenneth Casson Leighton 2020-11-30 13:07:49 GMT
(In reply to Jean-Paul.Chaput from comment #66)
> Just pushed experiments11 in soclayout git repository.
> 
> Note that it cannot be run without the NDA part of Coriolis2.
> You may place under non_generated the full chip .il and the associated .json
> for the I/O pad placement so I can pull them and P&R them. Maybe with
> different names.
> I am usually against copying/duplicating file, but in this instance it
> will allow us to work in parallel and choosing when we want to synch.

yeah honestly i am not happy about that.  i was under the distinct impression (right up until last week) that an NDA-free Phantom Library would be available, so that exactly this situation would never occur.

however... we work with things as they are.
Comment 69 Jean-Paul.Chaput 2020-11-30 14:21:28 GMT
> > So I've successfully done the P&R with Staf FlexLib & I/O pads. I will
> > commit that work under experiments11. Only I or Staf will be able to
> > run it because it needs the NDA (this directory, however, will not
> > contains any classified information).
> 
> sigh.  now we have two sets of identical work to maintain.  so, when i add
> the core back in, you have to duplicate that.

  Yes that's far from ideal. However, just copying the ".il" generated by
  nMignen should suffice. And afterward we run the automated P&R.


> > * Could it be possible for the JSON file to be human-readable formatted?
> 
> with some independent parser tool, probably yes.  unix philosophy applies.

  With Python/JSON this is very easy... Already did.

 
> >   It will not induce significant slowdown and I will be able to perform
> >   manual tweaks more easily.
> 
> mmm... if you're doing manual tweaks to an auto-generated
> (machine-generated) file this raises alarm bells in my mind.

   And I totally agree. I mean, it is useful for debugging purpose.
   If I can read the JSON I can quickly pinpoint the problem, make
   a manual correction to see if it works, then suggest/request an
   appropriate fix (fast debug loop).


> > * In your json file, you seems to have inverted vdd/vss on the I/O pads.
> >   "vdd" should be connecteds to "power" and "vss" to "ground".
> 
> ah ok good catch.

  Benefit of human readable file...


> > * The power pads are too far off the side, at least put one ordinary pad
> >   at the very begin/end of each side.
> 
> again, to remind you: https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
> 
> this is exactly what i fixed and dealt with as part of the
> "pads.useChipSize" parameter.
> 
> by using the core size not the chip size then regardless of the chip size
> the positions of the IOpads align up perfectly with the core.

  Yes, I didn't forgot. But it means that we loose some space at the end of
  each side. If we are core limited, no problem. If we are pad limited, this
  may be bad (especially if the core is *much* smaller than the corona).
  Anyway, for a better power distribution it is likely that I will change
  the whole approach.
Comment 70 Jean-Paul.Chaput 2020-11-30 14:38:13 GMT
(In reply to Luke Kenneth Casson Leighton from comment #68)
> (In reply to Jean-Paul.Chaput from comment #66)
> > Just pushed experiments11 in soclayout git repository.
> > 
> > Note that it cannot be run without the NDA part of Coriolis2.
> > You may place under non_generated the full chip .il and the associated .json
> > for the I/O pad placement so I can pull them and P&R them. Maybe with
> > different names.
> > I am usually against copying/duplicating file, but in this instance it
> > will allow us to work in parallel and choosing when we want to synch.
> 
> yeah honestly i am not happy about that.  i was under the distinct
> impression (right up until last week) that an NDA-free Phantom Library would
> be available, so that exactly this situation would never occur.
> 
> however... we work with things as they are.

  Yes I perfectly understand. I am not completly happy either.

  I think I should write a more complete explanation so that everyone can
  understand the pros and cons of each approach. I only (very) recently
  fully understand the whole implications of Staf ways, leading to a
  intermediate one. So here is the situation, with three possible paths:

  Plan A : FlexLib with maximum density routing gauge (routing tracks as
           close as allowed by the technology).
           * Pros: Gives close to maximum density for the design.
                   Easier for the P&R to complete, minimum area (i.e. cost).
           * Cons: Impossible to publish the layout. Only netlist, and
                   maybe placement (but no routing).

  Plan B : (Intermediate, *new*) FlexLib, but with a routing gauge with
           track pitches on a fractional of the cell height/cell width.
           * Pros: Allow publication of a "symbolicized" layout of both
                   cells (phantom/abstracts or full).
                   Not portable across technological nodes.
           * Cons: Increased area. More difficult for the router.

  Plan C : Use the original NSXLIB/Alliance symbolic layout.
           * Pros: Same as plan B, plus possibility of cross porting
                   between technological nodes.
           * Cons: Even more increase of area. Marie-Minerve is working
                   on that as part backup plan, but she's still facing
                   some scaling problems.

  For the future, people should be able to choose between, at least A and B,
  given the tradeoff they want.
Comment 71 Luke Kenneth Casson Leighton 2020-11-30 14:46:03 GMT
(In reply to Jean-Paul.Chaput from comment #69)
> > > So I've successfully done the P&R with Staf FlexLib & I/O pads. I will
> > > commit that work under experiments11. Only I or Staf will be able to
> > > run it because it needs the NDA (this directory, however, will not
> > > contains any classified information).
> > 
> > sigh.  now we have two sets of identical work to maintain.  so, when i add
> > the core back in, you have to duplicate that.
> 
>   Yes that's far from ideal. However, just copying the ".il" generated by
>   nMignen should suffice. 

and ls180 pinmux changes should be picked up cleanly, too.


> 
> > > * Could it be possible for the JSON file to be human-readable formatted?
> > 
> > with some independent parser tool, probably yes.  unix philosophy applies.
> 
>   With Python/JSON this is very easy... Already did.

if you are using that command regularly please do feel free to add it as a helper script to soclayout (experiments9 and 11) so that you don't have to repeat it / forget it


>  
> > >   It will not induce significant slowdown and I will be able to perform
> > >   manual tweaks more easily.
> > 
> > mmm... if you're doing manual tweaks to an auto-generated
> > (machine-generated) file this raises alarm bells in my mind.
> 
>    And I totally agree. I mean, it is useful for debugging purpose.
>    If I can read the JSON I can quickly pinpoint the problem, make
>    a manual correction to see if it works, then suggest/request an
>    appropriate fix (fast debug loop).

i get it.  the ls180 pinmux program is... slightly obtuse.


> 
> > > * In your json file, you seems to have inverted vdd/vss on the I/O pads.
> > >   "vdd" should be connecteds to "power" and "vss" to "ground".
> > 
> > ah ok good catch.
> 
>   Benefit of human readable file...

:)

> > by using the core size not the chip size then regardless of the chip size
> > the positions of the IOpads align up perfectly with the core.
> 
>   Yes, I didn't forgot. But it means that we loose some space at the end of
>   each side. If we are core limited, no problem. 

there are three possibilities:

* IO bound (IO defines size of chip)
* core bound (core defines size of chip)
* grey area right in the middle where either one could end up defining the size

there are bugs/quirks in the current algorithm (without the pads.useChipSize patch) that mean that things will neverrrr work (unless forcing to move the VSS/VDD inwards which i do not want to do).

the current size of the chip is, by a coincidence, in the "upper" part of that "grey area", just transitioning to core-bound.

this upper limit of the grey area is what pads.useChipSize is designed to fix.

once the OpenPOWER core is added back in, this will *not* be the case, because the chip will definitely be core-bound, and the bugs/quirks will not be encountered.


> If we are pad limited, this
>   may be bad (especially if the core is *much* smaller than the corona).

then such designers would not use the pads.useChipSize option.

>   Anyway, for a better power distribution it is likely that I will change
>   the whole approach.

ah ok.
Comment 72 Luke Kenneth Casson Leighton 2020-11-30 14:52:30 GMT
(In reply to Jean-Paul.Chaput from comment #70)

>   For the future, people should be able to choose between, at least A and B,
>   given the tradeoff they want.

Plan D: adapt Staf's FlexLib to use the Skywater 130nm PDK, then make some (reasonable) assumptions similar to Plans A or B based on (reasonable but to-be-verified) assumptions that things will scale

of course if the target *is* Skywater 130nm then no A/B compromises need to be made.

going to a larger geometry (180nm) my intuition expects that scaling up the Skywater 130nm PDK would be fine, however to a smaller one (110nm or below) would be a different story.
Comment 73 Jean-Paul.Chaput 2020-11-30 15:41:31 GMT
(In reply to Luke Kenneth Casson Leighton from comment #72)
> (In reply to Jean-Paul.Chaput from comment #70)
> 
> >   For the future, people should be able to choose between, at least A and B,
> >   given the tradeoff they want.
> 
> Plan D: adapt Staf's FlexLib to use the Skywater 130nm PDK, then make some
> (reasonable) assumptions similar to Plans A or B based on (reasonable but
> to-be-verified) assumptions that things will scale

  Constantly forgot about this one. Yes, if NDA goes away, then most
  of our problems also does. And A & B fuse.

  And yes, we should definitely provides support for Skywater,
  but we must focus on our immediate target.

> of course if the target *is* Skywater 130nm then no A/B compromises need to
> be made.
> 
> going to a larger geometry (180nm) my intuition expects that scaling up the
> Skywater 130nm PDK would be fine, however to a smaller one (110nm or below)
> would be a different story.

  Yes, but devil is in the details... So it may be not as straightforward.
  At least, it is our experience that every port has to be carefully
  crafted whatever the apparent symplicity.
Comment 74 Luke Kenneth Casson Leighton 2020-11-30 17:30:24 GMT
(In reply to Jean-Paul.Chaput from comment #73)
> (In reply to Luke Kenneth Casson Leighton from comment #72)

> > Plan D: adapt Staf's FlexLib to use the Skywater 130nm PDK, then make some

>   Constantly forgot about this one. Yes, if NDA goes away, then most
>   of our problems also does. And A & B fuse.

i would recommend an intern handle this (next year) with as little interaction with Staf as humanly possible.


also, Staf, i recommend that before that happens that you have a conversation with IMEC, to make it ABSOLUTELY and abundantly clear that FlexLib is flexible and scaleable, and that you have IN NO WAY violated the *TSMC* 180nm NDA simply by a THIRD PARTY (that has absolutely no association with you whatsoever) looking at the *SKYWATER* 130nm Libre/Open PDK.

this is new territory: they are going to be extremely uncomfortable with their monopoly power position being disrupted, and you do not want to be caught in the shitstorm that might result if they decide to fly off the handle.

giving IMEC a chance to go through that in advance so that they do not try to accuse you of anything might be a good idea?


>   And yes, we should definitely provides support for Skywater,
>   but we must focus on our immediate target.

yes absolutely 100% agreed.
Comment 75 Staf Verhaegen 2020-11-30 19:00:03 GMT
> this is new territory: they are going to be extremely uncomfortable with
> their monopoly power position being disrupted, and you do not want to be
> caught in the shitstorm that might result if they decide to fly off the
> handle.
> 
> giving IMEC a chance to go through that in advance so that they do not try
> to accuse you of anything might be a good idea?

It's not imec that has to be convinced but TSMC and they can only be convinced by showing the money.
Comment 76 Staf Verhaegen 2020-11-30 19:02:25 GMT
> i would recommend an intern handle this (next year) with as little
> interaction with Staf as humanly possible.
> 
> 
> also, Staf, i recommend that before that happens that you have a
> conversation with IMEC, to make it ABSOLUTELY and abundantly clear that
> FlexLib is flexible and scaleable, and that you have IN NO WAY violated the
> *TSMC* 180nm NDA simply by a THIRD PARTY (that has absolutely no association
> with you whatsoever) looking at the *SKYWATER* 130nm Libre/Open PDK.

LIP6 also has signed the TSMC NDA so they will be bound by same restrictions as I am and TSMC will consider any intern @ LIP6 bound by that NDA also.
Comment 77 Luke Kenneth Casson Leighton 2020-11-30 19:20:08 GMT
(In reply to Staf Verhaegen from comment #76)

> LIP6 also has signed the TSMC NDA so they will be bound by same restrictions
> as I am and TSMC will consider any intern @ LIP6 bound by that NDA also.

drat, good point.  have to find another way, then.  Hagen Sankowski might be a good candidate.
Comment 78 Luke Kenneth Casson Leighton 2020-11-30 21:12:46 GMT
JP, fyi:

i have not overwritten the non_generated json file in experiments11

commit f5d1ef0196785d5cf62ecb63afae18e4730d1627
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Mon Nov 30 15:04:46 2020 +0000

    update submodule for ls180 pinmux, iopad vss/vdd inversion corrected
Comment 79 Jean-Paul.Chaput 2020-12-02 22:48:28 GMT
Hello Luke,

I'm ready to perform tests on the full core, could you generate it and
commit it? (il/json)

Regards,
Comment 80 Cole Poirier 2020-12-02 22:57:03 GMT
(In reply to Jean-Paul.Chaput from comment #79)
> Hello Luke,
> 
> I'm ready to perform tests on the full core, could you generate it and
> commit it? (il/json)
> 
> Regards,

Hi Luke,

If all this requires is using the command line switch when running issuer.py then I can do this, so you can get to bed. If it requires more careful  modification of pins and other files then I likely cannot. Let me know.
Comment 81 Luke Kenneth Casson Leighton 2020-12-02 22:57:49 GMT
(In reply to Jean-Paul.Chaput from comment #79)
> Hello Luke,
> 
> I'm ready to perform tests on the full core, could you generate it and
> commit it? (il/json)

json should not change at all, that is pinouts, will do core tomorrow.

if you know a way to get quick core size estimate rather than taking 20-30 minutes to place *then* fail, then i increment chip size and do it all over again, that would be handy :)
Comment 82 Luke Kenneth Casson Leighton 2020-12-02 22:59:36 GMT
(In reply to Cole Poirier from comment #80)
> (In reply to Jean-Paul.Chaput from comment #79)
> > Hello Luke,
> > 
> > I'm ready to perform tests on the full core, could you generate it and
> > commit it? (il/json)
> > 
> > Regards,
> 
> Hi Luke,
> 
> If all this requires is using the command line switch when running issuer.py

issuer_verilog.py followed by copying to litex then make in the ls180 litex directory to merge the peripherals verilog and convert to ilang....
Comment 83 Cole Poirier 2020-12-02 23:03:09 GMT
(In reply to Luke Kenneth Casson Leighton from comment #82)
> (In reply to Cole Poirier from comment #80)
> > (In reply to Jean-Paul.Chaput from comment #79)
> > > Hello Luke,
> > > 
> > > I'm ready to perform tests on the full core, could you generate it and
> > > commit it? (il/json)
> > > 
> > > Regards,
> > 
> > Hi Luke,
> > 
> > If all this requires is using the command line switch when running issuer.py
> 
> issuer_verilog.py followed by copying to litex then make in the ls180 litex
> directory to merge the peripherals verilog and convert to ilang....

Will do. JP, I should have the ilang file for you in the next 15 minutes or so.
Comment 84 Cole Poirier 2020-12-02 23:18:30 GMT
(In reply to Cole Poirier from comment #83)
>
> Will do. JP, I should have the ilang file for you in the next 15 minutes or
> so.

I forgot it was end of day for you JP. I'm going to refrain from doing this as luke will have to review the generated file anyway, so I might as well let him do it right the first time.
Comment 85 Luke Kenneth Casson Leighton 2020-12-02 23:45:38 GMT
what's this one about, JP?

[ERROR] The density required by the obstacles is above 1
        Python stack trace:
        #0 in                     place() at .../dist-packages/cumulus/plugins/alpha/block/block.py:494
        #1 in                     doPnR() at .../dist-packages/cumulus/plugins/alpha/block/block.py:573
        #2 in                     doPnR() at .../dist-packages/cumulus/plugins/alpha/chip/chip.py:144
        #3 in                scriptMain() at doDesign.py:168


commit 7802ade1ecb4ffcb41fd41c581f71fc7e23aff0a
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Wed Dec 2 23:36:41 2020 +0000

    begin random search for appropriate core size.  start at 36000


... never mind: increasing to 40,000 seems to have made the error "go away"

commit 3c534a425d5902f4b3d91697b17dc5191c19629a
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Wed Dec 2 23:44:51 2020 +0000

    increase size to 40,000
Comment 86 Jean-Paul.Chaput 2020-12-02 23:48:51 GMT
(In reply to Cole Poirier from comment #84)
> (In reply to Cole Poirier from comment #83)
> >
> > Will do. JP, I should have the ilang file for you in the next 15 minutes or
> > so.
> 
> I forgot it was end of day for you JP. I'm going to refrain from doing this
> as luke will have to review the generated file anyway, so I might as well
> let him do it right the first time.

Thank you. One before last reply before I go to sleep...
I did not mind having the design late. This way I lanch the
run during the night. ASICs way.
Comment 87 Jean-Paul.Chaput 2020-12-02 23:54:11 GMT
(In reply to Luke Kenneth Casson Leighton from comment #85)
> what's this one about, JP?
> 
> [ERROR] The density required by the obstacles is above 1
>         Python stack trace:

  At face value, it's real meaning is "there is not enough area in
  the core to place all the cells" (it's contrived). So increasing
  the size value is the right move.

  Or, more viciously, there is a previous placement that is lurking
  and has been wrongly taken into account and cause the density
  calculations to fail.
    To avoid that, systematically remove any "ap" file before
  (re)P&R a design.

  Boarding my Bed now! Finishing my Ted Chiang novel.
Comment 88 Luke Kenneth Casson Leighton 2020-12-03 00:37:22 GMT
  Renaming cloned cell: "<id:926510 Cell fsm>"
  Renaming cloned cell: "<id:927937 Cell irblock>"
MBK_OUT_LO=al; export MBK_OUT_LO; MBK_SEPAR='_'; export MBK_SEPAR; /home/lkcl/alliance/install/bin/cougar       -c -f chip_r chip_r_ext

*** mbk error *** alcloadphfig : missing or non-numeric field
( line 319054 parsing corona_cts_r.ap )


  Renaming cloned cell: "<id:926510 Cell fsm>"
  Renaming cloned cell: "<id:927937 Cell irblock>"
MBK_OUT_LO=al; export MBK_OUT_LO; MBK_SEPAR='_'; export MBK_SEPAR; /home/lkcl/alliance/install/bin/cougar       -c -f chip_r chip_r_ext

*** mbk error *** alcloadphfig : missing or non-numeric field
( line 319054 parsing corona_cts_r.ap )

S 1775000,593000,1779000,593000,300,core.subckt_29416_test_issuer.subckt_1_ti.subckt_2768_core.subckt_4053_fus.subckt_7_shiftrot0.subckt_1078_alu_shift_rot0.subckt_0_pipe1_110.subckt_472_main_114.subckt_12_rotator.subckt_592_right_mask.abc_641657_new_n108,RIGHT,ALU2

that's a new one.

it looks like there's an assumption in alliance that names will be under...

lkcl@fizzy:~/src/libresoc/yosys$ wc /tmp/y
  1   2 267 /tmp/y

... under 256 characters in length.  clearly this is not the case! :)
Comment 89 Luke Kenneth Casson Leighton 2020-12-03 00:39:42 GMT
(In reply to Jean-Paul.Chaput from comment #87)
> (In reply to Luke Kenneth Casson Leighton from comment #85)
> > what's this one about, JP?
> > 
> > [ERROR] The density required by the obstacles is above 1
> >         Python stack trace:
> 
>   At face value, it's real meaning is "there is not enough area in
>   the core to place all the cells" (it's contrived). So increasing
>   the size value is the right move.

loovely
 
>   Or, more viciously, there is a previous placement that is lurking
>   and has been wrongly taken into account and cause the density
>   calculations to fail.
>     To avoid that, systematically remove any "ap" file before
>   (re)P&R a design.

i usually do an rm *.ap *.vst gratuitously before "make clean"
 
>   Boarding my Bed now! Finishing my Ted Chiang novel.

:)  reading "Blonde Bombshell" by Tom Holt to my daughter whilst waiting for a P&R to finish.  hilarious that the names, due to hierarchical OO HDL design, are exceeding 256 characters in length.
Comment 90 Staf Verhaegen 2020-12-03 08:36:15 GMT
(In reply to Luke Kenneth Casson Leighton from comment #81)
> (In reply to Jean-Paul.Chaput from comment #79)
> > Hello Luke,
> > 
> > I'm ready to perform tests on the full core, could you generate it and
> > commit it? (il/json)
> 
> json should not change at all, that is pinouts, will do core tomorrow.
> 
> if you know a way to get quick core size estimate rather than taking 20-30
> minutes to place *then* fail, then i increment chip size and do it all over
> again, that would be handy :)

The chips will target 3.5mm x 3.5mm including IO ring. So I propose to make the core such that the just fits in the IO ring is 3.5mm x 3.5mm. No need to find minimal core size for placer.

I also propose to allow JP to play with the core size later without needing to iterate with you guys when also PLL and SRAM is included in the design (not this one).
Comment 91 Luke Kenneth Casson Leighton 2020-12-03 11:40:16 GMT
(In reply to Staf Verhaegen from comment #90)

> The chips will target 3.5mm x 3.5mm including IO ring. So I propose to make
> the core such that the just fits in the IO ring is 3.5mm x 3.5mm. No need to
> find minimal core size for placer.

it is time.  the full completion is O(N^2) or O(N^3) and so iterating to find bugs would have to move to an entire day cycle if hard-fixed at the maximum size whereas at a smaller size it is tolerable (just) to perform 4-6 bugfixing iterations per day.
 
> I also propose to allow JP to play with the core size later without needing
> to iterate with you guys when also PLL and SRAM is included in the design
> (not this one).

yes, it is just one parameter.
Comment 92 Luke Kenneth Casson Leighton 2020-12-03 11:52:01 GMT
trying this although because the file was written by another tool and this tool (mbk) is *reading* it may just create a silent fail.


(In reply to Luke Kenneth Casson Leighton from comment #88)
>   Renaming cloned cell: "<id:926510 Cell fsm>"
>   Renaming cloned cell: "<id:927937 Cell irblock>"
> MBK_OUT_LO=al; export MBK_OUT_LO; MBK_SEPAR='_'; export MBK_SEPAR;
> /home/lkcl/alliance/install/bin/cougar       -c -f chip_r chip_r_ext
> 
> *** mbk error *** alcloadphfig : missing or non-numeric field
> ( line 319054 parsing corona_cts_r.ap )

diff --git a/alliance/src/mbk/src/alc_pars_p.c b/alliance/src/mbk/src/alc_pars_p.c
index 742108c3..f82627f7 100644
--- a/alliance/src/mbk/src/alc_pars_p.c
+++ b/alliance/src/mbk/src/alc_pars_p.c
@@ -60,8 +60,8 @@
 
 
 #define        MBKSZNAME       1024
-#define        MAXLBUFFER       256
-#define        MAXLBUFF         256
+#define        MAXLBUFFER       512
+#define        MAXLBUFF         512
 
 #define        EVAL               2
 #define        EVER               3
Comment 93 Luke Kenneth Casson Leighton 2020-12-03 13:47:20 GMT
(In reply to Luke Kenneth Casson Leighton from comment #92)
> trying this although because the file was written by another tool and this
> tool (mbk) is *reading* it may just create a silent fail.

didn't work

https://gitlab.lip6.fr/vlsi-eda/alliance/-/issues/3
Comment 94 Luke Kenneth Casson Leighton 2020-12-03 15:38:16 GMT
JP note, in passing:

commit df409461a7320964e5459bf9ea130ee10d338887
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Thu Dec 3 15:36:00 2020 +0000

    added 3 more 4k SRAMs

these are now 64-bit 4k, i corrected an error where the wishbone bus had
been 32-bit, making the SRAM also 32-bit 4k.  this is now sorted, all 4
SRAMs are 64-bit 4kbytes.
Comment 95 Luke Kenneth Casson Leighton 2020-12-03 16:18:29 GMT
ARGH.

i know why i cut down the size of the SRAM to only 512 bytes for test purposes: yosys ABC tries to go completely mental and map anything over 256 bytes to... yeah, that bug.

i will cut it back down from 4k to 0x200 for now
Comment 96 Luke Kenneth Casson Leighton 2020-12-03 18:33:34 GMT
JP: clearly this, below, is not true!  ls180.vst clearly has gpio_o of length
0..15


_connect <id:1224733 Net "vss" e-- GROUND ---- (UNDEFINED)>
_connect <id:1224782 Net "vdd" e-- POWER ---- (UNDEFINED)>
[ERROR] CoreToChip.buildChip(): Pad "p_gpio_8" refer net "gpio_o(8)" which do not exist in core "ls180".
        Python stack trace:
        #0 in                  __init__() at .../install/lib/python2.7/dist-packages/crlcore/helpers/io.py:167
        #1 in                 buildChip() at .../cumulus/plugins/alpha/core2chip/core2chip.py:639
        #2 in                scriptMain() at doDesign.py:166
        #3 in                 runScript() at .../coriolis-2.x/Linux.x86_64/Release.Shared/install/bin/cgt:73
        #4 in                  <module>() at .../coriolis-2.x/Linux.x86_64/Release.Shared/install/bin/cgt:204


commit a4ac6b9543939ffea583be44cfba1141bdaeb7e6
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Thu Dec 3 18:30:12 2020 +0000

    very weird bug where CoreToChip.buildChip cannot find gpio_o(8)
Comment 97 Luke Kenneth Casson Leighton 2020-12-03 21:53:23 GMT
in alpha core2chip.py i added this:

@@ -629,8 +635,9 @@ class CoreToChip ( object ):
                     if netName is None: continue
                     coreNet = self.core.getNet( netName )
                     if not coreNet:
-                        raise ErrorMessage( 1, 'CoreToChip.buildChip(): Pad "{}" refer net "{}" which do not exist in core "{}".' \
-                                               .format(ioPadConf.instanceName,netName,self.core.getName()) )
+                        print (ErrorMessage( 1, 'CoreToChip.buildChip(): Pad "{}" refer net "{}" which do not exist in core "{}".' \
+                                               .format(ioPadConf.instanceName,netName,self.core.getName()) ))
+                        continue

which allowed reporting of all errors rather than bombing out and preventing detection of all others.

a completely arbitrary set of GPIO "do not exist" when, looking at ls180.vst, it is blindingly obvious that yes, in fact, they do exist.  additionally:

i2c_sda_i exists but... err... wait... how the hell has it been turned from
an input into an output?

there is something extremely strange going on, not helped by the fact that when the wishbone bus size is set to 32 bit *these errors do not occur*
Comment 98 Cole Poirier 2020-12-03 22:46:28 GMT
(In reply to Luke Kenneth Casson Leighton from comment #92)
>
> diff --git a/alliance/src/mbk/src/alc_pars_p.c
> b/alliance/src/mbk/src/alc_pars_p.c
> index 742108c3..f82627f7 100644
> --- a/alliance/src/mbk/src/alc_pars_p.c
> +++ b/alliance/src/mbk/src/alc_pars_p.c
> @@ -60,8 +60,8 @@
>  
>  
>  #define        MBKSZNAME       1024
> -#define        MAXLBUFFER       256
> -#define        MAXLBUFF         256
> +#define        MAXLBUFFER       512
> +#define        MAXLBUFF         512
>  
>  #define        EVAL               2
>  #define        EVER               3

Maybe this will work Luke?

diff --git a/alliance/src/mbk/src/alc_pars_l6.c b/alliance/src/mbk/src/alc_pars_l6.c
index 77a69244..f6f20922 100644
--- a/alliance/src/mbk/src/alc_pars_l6.c
+++ b/alliance/src/mbk/src/alc_pars_l6.c

@@ -925,7 +925,7 @@ int          version;
   losig_list	*ptsig;
   char           type;
   float          capa;
-  char           signame[256];
+  char           signame[512];
   ht            *htsigname;
   long           index;
   char          *ptallocsigname;
Comment 99 Jean-Paul.Chaput 2020-12-04 17:50:20 GMT
(In reply to Luke Kenneth Casson Leighton from comment #92)
> trying this although because the file was written by another tool and this
> tool (mbk) is *reading* it may just create a silent fail.
> 
> 
> (In reply to Luke Kenneth Casson Leighton from comment #88)
> >   Renaming cloned cell: "<id:926510 Cell fsm>"
> >   Renaming cloned cell: "<id:927937 Cell irblock>"
> > MBK_OUT_LO=al; export MBK_OUT_LO; MBK_SEPAR='_'; export MBK_SEPAR;
> > /home/lkcl/alliance/install/bin/cougar       -c -f chip_r chip_r_ext
> > 
> > *** mbk error *** alcloadphfig : missing or non-numeric field
> > ( line 319054 parsing corona_cts_r.ap )
> 
> diff --git a/alliance/src/mbk/src/alc_pars_p.c
> b/alliance/src/mbk/src/alc_pars_p.c
> index 742108c3..f82627f7 100644
> --- a/alliance/src/mbk/src/alc_pars_p.c
> +++ b/alliance/src/mbk/src/alc_pars_p.c
> @@ -60,8 +60,8 @@
>  
>  
>  #define        MBKSZNAME       1024
> -#define        MAXLBUFFER       256
> -#define        MAXLBUFF         256
> +#define        MAXLBUFFER       512
> +#define        MAXLBUFF         512
>  
>  #define        EVAL               2
>  #define        EVER               3

   This is the right correction. Commited in Alliance
   #c12f377989571c1d868bebebdfb1574572e2ccf9
Comment 100 Jean-Paul.Chaput 2020-12-22 11:16:10 GMT
Hello Luke,

Staf is now in a state where he can provides me with a first
version of the SRAM block. So would it be possible to include
instances of thoses block inside the ls180 dry run ?

Best regards,
Comment 101 Luke Kenneth Casson Leighton 2020-12-22 12:33:31 GMT
(In reply to Jean-Paul.Chaput from comment #100)
> Hello Luke,
> 
> Staf is now in a state where he can provides me with a first
> version of the SRAM block. So would it be possible to include
> instances of thoses block inside the ls180 dry run ?
> 
> Best regards,

i have replied in bug #502 which deals with the SRAM.