Saturday, 2021-11-27

ghostmansd[m]Hi Luke, thank you for the explanation and patience! It's clearer now.05:00
lkclprogrammerjake, no problem. we're out of printer black ink here too :)10:15
lkclghostmansd[m], it's like... 3.5 years of development behind SVP64, but actually only probably about.... maybe... 750 lines of c code needed for this.10:16
lkclit's a weird contrast.10:16
lkclrecommend starting really really small: do the SUBVL field first.  should be no more than about... mmm... 200 lines (most of which will be decoding slashes and identifying and stripping "sv." from the front of the v3.0 instruction10:17
lkclwe set a hard rule:10:17
lkclunder absolutely no circumstances is an SVP64 instruction permitted to exist without a v3.0 scalar instruction also existing10:18
lkclhow can it? if there's no 32-bit "suffix", how can it be "prefixed"??10:22
lkclit is exactly the same situation for Power ISA v3.1 64-bit prefixes.10:23
cesarSome amusing quotes I found, on the importance of testing backups:10:27
cesar"People think they need backups, while in fact they need restores..."10:27
cesar"Backups are a worthless waste of time! Restores, on the other hand..."10:27
lkclhaha yeah10:28
cesarThere is work in progress for adding a OpenLane/SKY130 PDK Platform to nMigen...10:45
cesarhttps://github.com/nmigen/nmigen/pull/64410:45
lkclcesar, very cool.  the next one to include is a coriolis2 ASIC platform10:46
Veera[m]lkcl: query regarding RFP12:42
Veera[m]lkcl: is it possible that payment will be combined for two separate RFP by NLNET in a single bank transfer?12:43
lkclyes12:43
Veera[m]For that do I have to say in each email about the other?12:45
lkclno12:46
Veera[m]How will NLNET know about two RFP's in side by side?12:47
lkclbecause you send them in the same day12:48
lkclbecause they are intelligent people.12:48
lkcli don't know, i am not working for them12:48
Veera[m]ok12:49
lkclChips4Makers[m], yes, i've updated #589's title to indicate it's for the NLnet EUR 50,000 grant for "crypto-primitives"12:54
lkclthis was back... mmm.... 8 months ago? when you first suggested the gigabit router idea, so i put in the tasks under that12:55
lkclthen realised we needed a lot more funding (MPWs), hence the NGI POINTER application.12:56
lkclsome things (memory compiler, sram cells) stay under that original NLnet "crypto-primitives" one12:57
lkclaand of course, NLnet does not mind if the RFPs go to Fibraservi :)12:58
Chips4Makers[m]lkcl, cesar : we are working on Coriolis nmigen for Sky130. The Sky130 port of PDKMaster is funded for the CryptoRouter is input for that. First (hacked together) proof of concept has gone on MPW3: https://efabless.com/projects/48112:58
Chips4Makers[m]s/lkcl, cesar : we are working on Coriolis nmigen for Sky130. The Sky130 port of PDKMaster is funded for the CryptoRouter is input for that. First (hacked together) proof of concept has gone on MPW3: https://efabless.com/projects/481/lkcl, cesar : we are working on Coriolis nmigen for Sky130. The Sky130 port of PDKMaster - NLNet funded for the CryptoRouter - is input for that. First (hacked together) proof of concept has gone on MPW3:12:58
Chips4Makers[m]https://efabless.com/projects/481/12:58
Veera[m]NLNet.2019.10.Wishbone == Memorandum of Understanding 2019-10-04313:24
Veera[m]NLNet.2019.10.Standards == Memorandum of Understanding ?13:25
lkclVeera[m], check email13:40
lkclChips4Makers[m], i saw, looks fantastic13:40
lkcli think what i'll do is make the JTAG Boundary Scan ASICPlatform a "mixin" class13:41
lkclso that it can be mixed in with a coriolis2ASICPlatform13:41
lkclto create a Coriolis2JTAGScanASICPlatform13:41
lkcland mixed in with a N.E.OtherASICPlatform13:42
lkclalso, btw, pinmux (GPIO muxing) is going to be a bit... intrusive into C4M-JTAG13:42
lkclC4M-JTAG Boundary Scan will have to be extended to understand the concept of GPIO pull-up/pull-down, current strength driving13:43
lkcland the GPIO muxing itself (4-to-1 fan-in and 1-to-4 fan-out)13:43
lkclnot the CSR registers *on top* of that, but just the ability to redirect the Muxing, pull-up, pull-down, current-strength-driving through Boundary Scan regs13:44
Veera[m]lkcl:  saw it.13:45
Veera[m]lkcl: sent you email13:45
lkclVeera[m],13:47
lkcl:Phase/milestone(s): 384 65413:47
lkcljust 65413:48
lkcl:Phase/milestone(s): 174 242 73013:48
lkclyou did not work on 174 or 24213:48
lkcland the URL is wrong13:48
lkclyou did not work on https://bugs.libre-soc.org/show_bug.cgi?id=70013:48
Veera[m]Shall I resend you email with corrections13:49
lkclyes please13:49
Veera[m]ok13:50
Veera[m]sent email with corrections13:56
lkclalso put "total NNNNN shared with lkcl, klehman"13:59
lkclso that the Accountant knows to check / expect those14:00
Veera[m]In "URLs and notes"  put EUR 600 Veera (total EUR 750 shared with lkcl) for 654 and EUR 700 Veera (total EUR 1000 shared with lkcl, klehman) for Bug 730 ?14:03
lkclyes14:05
Veera[m]Do I have to do the same in About Us Page in Wiki14:06
lkclhooray! i fixed the WaW checking in in-order core!14:07
lkclVeera[m], that's up to you.  that page is there for your convenience so that you can cut/paste the notes into the RFP later14:07
lkclso in this case, you've just written the RFP, so having it in your home page is kinda a waste of time14:07
lkclbut, budget-sync actually should auto-generate the notes for you which you can cut/paste into the RFP as well14:08
Veera[m]I ran budget sync. It did not showed shared with lkcl, klehman14:11
lkclshould have done, oh well14:11
Veera[m]Sent mail with corrections for shared info14:11
lkcldouble-checking.14:12
lkclamount good.  654.  total 600.  notes good14:12
lkcl730.  total 700.  notes good14:12
lkclok all good, feel free to fill in bank account and address, and send SEPARATE emails to rfp@nlnet.nl14:13
lkclwith subject line:14:13
lkcl[RFP] Veera Kumar - {27nov2021} {Project Number} {Project Name}14:15
lkclha! we have a superscalar in-order core!14:16
Veera[m]What is Project Number and Project Name?14:16
Veera[m]what about 2019-10P@nlnet.nl, I sent to this before for Wishbone Bugs?14:17
lkclah yes14:19
lkclProject Number = the project number NNNN-NN-NNN14:19
lkclProject Name = the NLnet Project name, you have two choices: Wishbone or Standards14:20
Veera[m]Prj Num: 2019-10-04314:21
lkclit's so the Accountant sees the information in the subject line of email inbox14:21
Veera[m]or Prj Num: 2019-10-04614:21
lkclthat's it14:21
Veera[m]What's about cc mail? e.g.  2019-10P@nlnet.nl14:22
lkclyes that'll do, although it's not strictly necessary14:26
Veera[m]is cc same for both Wishbone and OpenPOWER Standard?14:33
lkclthey are both 2019, both 10 (2019-10-NNN) so yes14:35
* lkcl resting. tired. heavy concentration for 2.5 hours.14:36
Chips4Makers[m]lkcl: I will certainly look at your code and base extension to C4M-JTAG and the Platform on it. From the other side I think the muxing itself should still be able to be kept out of the platform. For supporting pull-up/pull-down, different drive strength etc. the current signal set of (i, o, oe) will need to be extended or changed.15:30
Chips4Makers[m]Idea I had to have separate signals for different sink and source transistors (sink=pd, source=pu); e.g. pd0, pd1, pd2, pd3 and pu0, pu1, pu2, pu3. These would then have configurable drive strength; pd0/pu0 could represent classic pull-up/pull-down drive strength. and puN/pdN corresponds with for example N=1 => 5mA, N=2 => 10mA, N=3 => 20mA. This would allow to have any drive strength from 5mA to 35mA in steps of 5mA.15:42
Chips4Makers[m]Open drain would be done by only switch pdN signals.15:42
Chips4Makers[m]Actually IO cell on test vehicle has already such a design.15:42
Chips4Makers[m]s/has/had/15:42
lkclinteresting: different pull-up/pull-down strengths would be useful, i've not seen any ECs with that feature.  low/med/hi speed, yes (STM32Fs)15:57
lkclnot having muxing control in C4M-JTAG Boundary Scan will be a problem.15:57
lkclthe 4-1 and 1-4 Mux has to go directly in front of the IO pad, as close to it as possible15:58
lkclhttps://elinux.org/images/c/cd/Pincontrol-gpio-update.pdf page 416:00
lkclremember that with GPIO Muxing, there are up to 4x as many peripherals as there are pins16:01
lkclhow can you test the peripherals over JTAG Boundary Scan, if JTAG Boundary Scan cannot understand (and set) the Muxes??16:01
lkclit's impossible, isn't it?16:01
lkcland16:01
lkclalternatively16:02
lkclif the Muxes are placed *after* the JTAG Boundary Scan16:02
lkcland are not controlled by JTAG Shift Registers16:02
lkclit is impossible to set the IO pads16:02
lkcl(that might be the other way round)16:03
lkclbasically if JTAG Shift Registers do not understand Muxing, you either cut off IO pads or you cut off peripherals, depending on which side the (uncontrollable, inaccessible) MUXes are placed16:04
Chips4Makers[m]lkcl: Both the muxing and the peripherals will be memory mapped and thus be able to be driven by the Wishbone master on on the JTAG.16:04
lkcland if that fails?16:04
Chips4Makers[m]What fails ?16:05
lkcl(you can tell i thought about that scenario already)16:05
lkclif wishbone bus fails16:05
lkclif memory-mapping fails16:05
Chips4Makers[m]Then you have a faulty chip and throw it away.16:05
lkclindeed... but what happens if *all* chips are found to befaulty?16:06
Chips4Makers[m]Then you need to find the big in your nmigen code...16:06
lkcl"Design For Test" strategy tends to suggest to plan for full isolation of components16:06
Chips4Makers[m]s/big/bug/16:06
lkclmaking a dependency on something as large as a wishbone bus and CSRs is risky and violates DFT principles16:07
Chips4Makers[m]Can you show a MCU/CPU where the JTAG scan chain is put befor the MUX ?16:07
lkclall of them are proprietary so the question is invalid, unfortunately, they are all under NDA16:08
lkcland we're the first Libre ASIC Project to even consider this, because FPGAs, well, why would you waste gates on a pinmux?16:09
Chips4Makers[m]You should be able to find the BDSL for quite some of them.16:09
lkclah interesting16:09
Chips4Makers[m]Your use case is certainly not foreseen in the JTAG boundary scan documentation.16:09
lkcloh good! i mean, it's certainly been industry-standard practice to create pinmuxes esp. in ECs, for decades, so i should not be surprised to learn of that.16:11
Chips4Makers[m]lkcl: I am not saying to not have a pinmux; it's if it needs to be part of the platform.16:12
lkclan idea that occurred to me is that the JTAG BS test mode is a "5th mux option"16:12
lkclthis would allow the existing C4M-JTAG boundary-scan IOpad code to remain unmodified16:13
lkclinstead of having an intrusive rewrite16:13
Chips4Makers[m]Going afk16:14
lkclack. need to rest too.16:16
lkcloctavius, Chips4Makers[m]: i took at look at the new ASICPlatform this evening.  briefly: Simulation() can't cope with a Fragment returned from a platform.19:47
lkclthe clock domains get into a recursive-dependency loop19:47
lkcli'll think about how to solve that one overnight. it won't be pretty.19:48
octaviusOk, thanks lkcl. So the fragment grows exponentially with the number of signals to connect to the boundary scan chain?20:03
lkclno, it's something to do with how clock domains are allocated20:52
lkcla recursive dependency somewhere inside nmigen is created that Simulation() cannot cope with when handed a Fragment created by Platform20:53
lkcltherefore, to "solve" that, the entire JTAG boundary scan io has to be created OUTSIDE of ASICPlatform20:53
lkclwhich is going to be a frickin nuisance20:54
lkclpad_mgr is going to have to move to *inside* class JTAG20:54
lkclBlinker.elaborate can still call ASICPlatform.request() but ASICPlatform.request() has to match *pre-allocated* pad_mgr resources that have been wired up to the JTAG instance already20:57
lkclthis is going to be a bloody nuisance20:57
Veera[m]lkcl: I submitted the both RFP's to NLNET21:09
Veera[m]Update Bug: 654 page Pay TOML to vklr={amount=600, submitted=2021-11-27}21:10
Veera[m]Is it OK21:10
lkclyes fantastic.  do the other one as well, 73021:11
lkclthen check with budget-sync21:11
lkclthe mdwn file should change to reflect the new status21:12
Veera[m]Shal I do the same to Bug page: 73021:12
Veera[m]ok21:12
octaviuslkcl, bloody "ell, that does sound like a nightmare23:11
lkclChips4Makers[m], doh: *not* foreseen.  doh :)23:20

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!