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.
gimme a moment i need to sort this and replicate it properly.
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.
(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
(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.
(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.
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.
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.
(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).
(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.
(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).
(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.
(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.
(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.
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 ?)
(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" ?
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>) ```
(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.
(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
(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.
JP going back to commit 5bcbe5c040 the error is the same, "unable to find sffx3_x4"
(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.
(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.
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.
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.
Created attachment 116 [details] My log of build.sh, run in experiment9
(In reply to Jean-Paul.Chaput from comment #25) > Created attachment 116 [details] > My log of build.sh, run in experiment9 Dodo. Now!
(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
(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.
(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.
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.
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)
(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.
(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?
(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).
(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.
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...".
(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.
(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.
(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/ ?
(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.
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.
(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.
(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)
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 )
(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.
(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.
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,
(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.
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.
(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.
(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,
(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.
(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.
(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 ?
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.
(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.
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 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.
(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
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]
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".
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.
(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.
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.
(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 :)
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.
(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.
(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.
> > 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.
(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.
(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.
(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.
(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.
(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.
> 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.
> 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.
(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.
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
Hello Luke, I'm ready to perform tests on the full core, could you generate it and commit it? (il/json) Regards,
(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.
(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 :)
(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....
(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.
(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.
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
(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.
(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.
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! :)
(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.
(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).
(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.
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
(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
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.
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
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)
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*
(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;
(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
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,
(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.