| ghostmansd[m] | Hi Luke, thank you for the explanation and patience! It's clearer now. | 05:00 |
|---|---|---|
| lkcl | programmerjake, no problem. we're out of printer black ink here too :) | 10:15 |
| lkcl | ghostmansd[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 |
| lkcl | it's a weird contrast. | 10:16 |
| lkcl | recommend 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 instruction | 10:17 |
| lkcl | we set a hard rule: | 10:17 |
| lkcl | under absolutely no circumstances is an SVP64 instruction permitted to exist without a v3.0 scalar instruction also existing | 10:18 |
| lkcl | how can it? if there's no 32-bit "suffix", how can it be "prefixed"?? | 10:22 |
| lkcl | it is exactly the same situation for Power ISA v3.1 64-bit prefixes. | 10:23 |
| cesar | Some 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 |
| lkcl | haha yeah | 10:28 |
| cesar | There is work in progress for adding a OpenLane/SKY130 PDK Platform to nMigen... | 10:45 |
| cesar | https://github.com/nmigen/nmigen/pull/644 | 10:45 |
| lkcl | cesar, very cool. the next one to include is a coriolis2 ASIC platform | 10:46 |
| Veera[m] | lkcl: query regarding RFP | 12: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 |
| lkcl | yes | 12:43 |
| Veera[m] | For that do I have to say in each email about the other? | 12:45 |
| lkcl | no | 12:46 |
| Veera[m] | How will NLNET know about two RFP's in side by side? | 12:47 |
| lkcl | because you send them in the same day | 12:48 |
| lkcl | because they are intelligent people. | 12:48 |
| lkcl | i don't know, i am not working for them | 12:48 |
| Veera[m] | ok | 12:49 |
| lkcl | Chips4Makers[m], yes, i've updated #589's title to indicate it's for the NLnet EUR 50,000 grant for "crypto-primitives" | 12:54 |
| lkcl | this was back... mmm.... 8 months ago? when you first suggested the gigabit router idea, so i put in the tasks under that | 12:55 |
| lkcl | then realised we needed a lot more funding (MPWs), hence the NGI POINTER application. | 12:56 |
| lkcl | some things (memory compiler, sram cells) stay under that original NLnet "crypto-primitives" one | 12:57 |
| lkcl | aand 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/481 | 12: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-043 | 13:24 |
| Veera[m] | NLNet.2019.10.Standards == Memorandum of Understanding ? | 13:25 |
| lkcl | Veera[m], check email | 13:40 |
| lkcl | Chips4Makers[m], i saw, looks fantastic | 13:40 |
| lkcl | i think what i'll do is make the JTAG Boundary Scan ASICPlatform a "mixin" class | 13:41 |
| lkcl | so that it can be mixed in with a coriolis2ASICPlatform | 13:41 |
| lkcl | to create a Coriolis2JTAGScanASICPlatform | 13:41 |
| lkcl | and mixed in with a N.E.OtherASICPlatform | 13:42 |
| lkcl | also, btw, pinmux (GPIO muxing) is going to be a bit... intrusive into C4M-JTAG | 13:42 |
| lkcl | C4M-JTAG Boundary Scan will have to be extended to understand the concept of GPIO pull-up/pull-down, current strength driving | 13:43 |
| lkcl | and the GPIO muxing itself (4-to-1 fan-in and 1-to-4 fan-out) | 13:43 |
| lkcl | not 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 regs | 13:44 |
| Veera[m] | lkcl: saw it. | 13:45 |
| Veera[m] | lkcl: sent you email | 13:45 |
| lkcl | Veera[m], | 13:47 |
| lkcl | :Phase/milestone(s): 384 654 | 13:47 |
| lkcl | just 654 | 13:48 |
| lkcl | :Phase/milestone(s): 174 242 730 | 13:48 |
| lkcl | you did not work on 174 or 242 | 13:48 |
| lkcl | and the URL is wrong | 13:48 |
| lkcl | you did not work on https://bugs.libre-soc.org/show_bug.cgi?id=700 | 13:48 |
| Veera[m] | Shall I resend you email with corrections | 13:49 |
| lkcl | yes please | 13:49 |
| Veera[m] | ok | 13:50 |
| Veera[m] | sent email with corrections | 13:56 |
| lkcl | also put "total NNNNN shared with lkcl, klehman" | 13:59 |
| lkcl | so that the Accountant knows to check / expect those | 14: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 |
| lkcl | yes | 14:05 |
| Veera[m] | Do I have to do the same in About Us Page in Wiki | 14:06 |
| lkcl | hooray! i fixed the WaW checking in in-order core! | 14:07 |
| lkcl | Veera[m], that's up to you. that page is there for your convenience so that you can cut/paste the notes into the RFP later | 14:07 |
| lkcl | so in this case, you've just written the RFP, so having it in your home page is kinda a waste of time | 14:07 |
| lkcl | but, budget-sync actually should auto-generate the notes for you which you can cut/paste into the RFP as well | 14:08 |
| Veera[m] | I ran budget sync. It did not showed shared with lkcl, klehman | 14:11 |
| lkcl | should have done, oh well | 14:11 |
| Veera[m] | Sent mail with corrections for shared info | 14:11 |
| lkcl | double-checking. | 14:12 |
| lkcl | amount good. 654. total 600. notes good | 14:12 |
| lkcl | 730. total 700. notes good | 14:12 |
| lkcl | ok all good, feel free to fill in bank account and address, and send SEPARATE emails to rfp@nlnet.nl | 14:13 |
| lkcl | with subject line: | 14:13 |
| lkcl | [RFP] Veera Kumar - {27nov2021} {Project Number} {Project Name} | 14:15 |
| lkcl | ha! 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 |
| lkcl | ah yes | 14:19 |
| lkcl | Project Number = the project number NNNN-NN-NNN | 14:19 |
| lkcl | Project Name = the NLnet Project name, you have two choices: Wishbone or Standards | 14:20 |
| Veera[m] | Prj Num: 2019-10-043 | 14:21 |
| lkcl | it's so the Accountant sees the information in the subject line of email inbox | 14:21 |
| Veera[m] | or Prj Num: 2019-10-046 | 14:21 |
| lkcl | that's it | 14:21 |
| Veera[m] | What's about cc mail? e.g. 2019-10P@nlnet.nl | 14:22 |
| lkcl | yes that'll do, although it's not strictly necessary | 14:26 |
| Veera[m] | is cc same for both Wishbone and OpenPOWER Standard? | 14:33 |
| lkcl | they are both 2019, both 10 (2019-10-NNN) so yes | 14: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 |
| lkcl | interesting: 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 |
| lkcl | not having muxing control in C4M-JTAG Boundary Scan will be a problem. | 15:57 |
| lkcl | the 4-1 and 1-4 Mux has to go directly in front of the IO pad, as close to it as possible | 15:58 |
| lkcl | https://elinux.org/images/c/cd/Pincontrol-gpio-update.pdf page 4 | 16:00 |
| lkcl | remember that with GPIO Muxing, there are up to 4x as many peripherals as there are pins | 16:01 |
| lkcl | how can you test the peripherals over JTAG Boundary Scan, if JTAG Boundary Scan cannot understand (and set) the Muxes?? | 16:01 |
| lkcl | it's impossible, isn't it? | 16:01 |
| lkcl | and | 16:01 |
| lkcl | alternatively | 16:02 |
| lkcl | if the Muxes are placed *after* the JTAG Boundary Scan | 16:02 |
| lkcl | and are not controlled by JTAG Shift Registers | 16:02 |
| lkcl | it is impossible to set the IO pads | 16:02 |
| lkcl | (that might be the other way round) | 16:03 |
| lkcl | basically 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 placed | 16: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 |
| lkcl | and if that fails? | 16:04 |
| Chips4Makers[m] | What fails ? | 16:05 |
| lkcl | (you can tell i thought about that scenario already) | 16:05 |
| lkcl | if wishbone bus fails | 16:05 |
| lkcl | if memory-mapping fails | 16:05 |
| Chips4Makers[m] | Then you have a faulty chip and throw it away. | 16:05 |
| lkcl | indeed... 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 components | 16:06 |
| Chips4Makers[m] | s/big/bug/ | 16:06 |
| lkcl | making a dependency on something as large as a wishbone bus and CSRs is risky and violates DFT principles | 16:07 |
| Chips4Makers[m] | Can you show a MCU/CPU where the JTAG scan chain is put befor the MUX ? | 16:07 |
| lkcl | all of them are proprietary so the question is invalid, unfortunately, they are all under NDA | 16:08 |
| lkcl | and 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 |
| lkcl | ah interesting | 16:09 |
| Chips4Makers[m] | Your use case is certainly not foreseen in the JTAG boundary scan documentation. | 16:09 |
| lkcl | oh 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 |
| lkcl | an idea that occurred to me is that the JTAG BS test mode is a "5th mux option" | 16:12 |
| lkcl | this would allow the existing C4M-JTAG boundary-scan IOpad code to remain unmodified | 16:13 |
| lkcl | instead of having an intrusive rewrite | 16:13 |
| Chips4Makers[m] | Going afk | 16:14 |
| lkcl | ack. need to rest too. | 16:16 |
| lkcl | octavius, 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 |
| lkcl | the clock domains get into a recursive-dependency loop | 19:47 |
| lkcl | i'll think about how to solve that one overnight. it won't be pretty. | 19:48 |
| octavius | Ok, thanks lkcl. So the fragment grows exponentially with the number of signals to connect to the boundary scan chain? | 20:03 |
| lkcl | no, it's something to do with how clock domains are allocated | 20:52 |
| lkcl | a recursive dependency somewhere inside nmigen is created that Simulation() cannot cope with when handed a Fragment created by Platform | 20:53 |
| lkcl | therefore, to "solve" that, the entire JTAG boundary scan io has to be created OUTSIDE of ASICPlatform | 20:53 |
| lkcl | which is going to be a frickin nuisance | 20:54 |
| lkcl | pad_mgr is going to have to move to *inside* class JTAG | 20:54 |
| lkcl | Blinker.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 already | 20:57 |
| lkcl | this is going to be a bloody nuisance | 20:57 |
| Veera[m] | lkcl: I submitted the both RFP's to NLNET | 21:09 |
| Veera[m] | Update Bug: 654 page Pay TOML to vklr={amount=600, submitted=2021-11-27} | 21:10 |
| Veera[m] | Is it OK | 21:10 |
| lkcl | yes fantastic. do the other one as well, 730 | 21:11 |
| lkcl | then check with budget-sync | 21:11 |
| lkcl | the mdwn file should change to reflect the new status | 21:12 |
| Veera[m] | Shal I do the same to Bug page: 730 | 21:12 |
| Veera[m] | ok | 21:12 |
| octavius | lkcl, bloody "ell, that does sound like a nightmare | 23:11 |
| lkcl | Chips4Makers[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/!