--- Log opened Tue May 24 00:00:32 2022
00:18 -!- juri_ [~juri@178.63.35.222] has quit [Ping timeout: 246 seconds]
00:25 -!- juri_ [~juri@178.63.35.222] has joined #hplusroadmap
00:30 -!- juri_ [~juri@178.63.35.222] has quit [Remote host closed the connection]
00:49 -!- juri_ [~juri@178.63.35.222] has joined #hplusroadmap
01:01 -!- darsie [~darsie@84-113-55-200.cable.dynamic.surfer.at] has joined #hplusroadmap
01:12 -!- spaceangel [~spaceange@ip-78-102-216-202.net.upcbroadband.cz] has joined #hplusroadmap
01:34 -!- SDr [~SDr@li1189-192.members.linode.com] has quit [Changing host]
01:34 -!- SDr [~SDr@user/sdr] has joined #hplusroadmap
04:48 -!- Molly_Lucy [~Molly_Luc@user/Molly-Lucy/x-8688804] has joined #hplusroadmap
04:55 -!- srk- [~sorki@user/srk] has joined #hplusroadmap
04:56 -!- srk| [~sorki@user/srk] has joined #hplusroadmap
04:57 -!- srk [~sorki@user/srk] has quit [Ping timeout: 255 seconds]
04:59 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::93] has joined #hplusroadmap
04:59 -!- srk| is now known as srk
04:59 -!- srk- [~sorki@user/srk] has quit [Ping timeout: 246 seconds]
06:31 -!- Moon [~Moon@167.102.183.144] has joined #hplusroadmap
06:32 -!- Moon [~Moon@167.102.183.144] has quit [Client Quit]
06:53 -!- mirage335 [~mirage335@64.79.52.86] has quit [Quit: Client closed]
06:53 -!- mirage335 [~mirage335@64.79.52.86] has joined #hplusroadmap
09:20 -!- mirage335 [~mirage335@64.79.52.86] has quit [Quit: Client closed]
09:21 -!- mirage335 [~mirage335@64.79.52.86] has joined #hplusroadmap
09:23 < kanzure> asic shuttle program https://platform.efabless.com/chipignite/2204C
09:23 < muurkha> a new one?
09:23 < muurkha> what's their pricing like?
09:24 < kanzure> 1000 parts for $20/ea
09:24 < muurkha> according to the splash screen (US?)$9750 per project, 10 mm² user design area, W(L?)CSP package
09:25 < muurkha> for 100 QFN or 300 WCSP parts
09:25 < muurkha> (or alternatively US$20k for 1000 parts)
09:25 < muurkha> "Private shuttle -- no open-source requirement.  Guaranteed reservation with $200 deposit."
09:26 < kanzure> muurkha: context, https://libre-soc.org/conferences/siliconsalon2022/
09:26 < muurkha> I guess the 1000 is W(L?)CSP
09:26 < muurkha> what node?
09:30 < kanzure> well libre-soc is targeting 180nm right now
09:30 < muurkha> the transcript you linked said "Skywater PDK 130nm is now publicly available which is a start" linking to https://skywater-pdk.readthedocs.io/en/main/
09:31 < muurkha> and the efabless page says "Prototype and early volume fabrication for the SKY130 open PDK"
09:31 < kanzure> i might be wrong.
09:31 < muurkha> maybe "SKY130 open PDK" means "Skywater PDK 130nm"?
09:32 < muurkha> 130nm seems like it would be great for analog chips or cheap microcontrollers that don't need to be low-power
09:32 < muurkha> but about 2.6 orders of magnitude lower transistor count than state-of-the-art?
09:33 -!- lkcl [lkcl@we.will.rock.you.bnc4you.xyz] has joined #hplusroadmap
09:33 < kanzure> muurkha: ask lkcl
09:33 < muurkha> hi lkcl!  130nm seems like it would be great for analog chips or cheap microcontrollers that don't need to be low-power, but about 2.6 orders of magnitude lower transistor count than state-of-the-art?
09:34 < muurkha> (or 2.6 orders of magnitude higher leakage current at the same transistor count)
09:34 < lkcl> muurkha, hi
09:34 < lkcl> something like that, yes. 1.2 to 1.8v
09:35 < muurkha> I don't actually know anything about this stuff, I'm just a muurkha, so I could be completely wrong about this
09:35 < lkcl> 180 nm is, if i recall correctly, around 12-15,000 gates per mm^2
09:35 < muurkha> is libre-soc targeting 180nm or 130nm right now?
09:35 < lkcl> and it scales on a square law from there
09:35 < lkcl> the HDL is Foundry / Geometry agnostic
09:36 < muurkha> well sure
09:36 < muurkha> the efabless shuttle program seems pretty appealing
09:36 < lkcl> we just happen to have had the opportunity from NLnet and NGI POINTER sponsorship to make use of 180 nm MPWs
09:36 < muurkha> aha, cool
09:36 < lkcl> yes except it's restricted to 10 mm^2
09:36 < muurkha> via CMP?
09:36 < lkcl> IMEC
09:36 < muurkha> oh, I don't know about IMEC
09:37 < muurkha> that's great!
09:37 < lkcl> established originally at Ghent University, it was a way for Universities to get access to MPWs
09:37 < lkcl> but then corporate companies said, "you have great MPW shuttle services with access to all these foundries, please take our money"
09:37 < muurkha> 10 mm² at 12000 gates per mm² is 120k gates, which seems generous compared to the requirements of something like SeRV
09:37 < lkcl> :)
09:38 < lkcl> 12,000 times the amount needed to scale from 180 to 130 nm
09:38 < muurkha> though I don't know if maybe SeRV would be impractical to harden against power side channel attacks
09:38 < lkcl> which is errr... 30%?
09:38 < muurkha> SeRV is 200 4-LUTs on ICE40 IIRC
09:38 < lkcl> so in the 130 nm of sky130 it would be... errr... 20,000 times 10
09:38 < muurkha> not sure what that works out to in NANDs, NORs, and NOTs
09:39 < lkcl> multiply by about another factor of 5-10
09:39 < lkcl> so you end up with about 2 million transistors
09:39 < nmz787> do they have the PDK available for download, or do you need to sign up for an account first?
09:40 < muurkha> what's that, 11000 MuP21s?
09:40 < nmz787> or do they only accept HDL ?
09:40 < lkcl> which sounds like a lot until you try to implement a 64-bit Power ISA Core with L1/L2 Cache and it starts to look veeeery small
09:40 < muurkha> nmz787: apparently the PDK is https://skywater-pdk.readthedocs.io/en/main/
09:40 < kanzure> skywater PDK was presumably open-sourced
09:40 < lkcl> kanzure: yes. most of the skywater 130nm cell libraries as well
09:40 < muurkha> which links to https://cs.opensource.google/skywater-pdk https://foss-eda-tools.googlesource.com/skywater-pdk/ https://github.com/google/skywater-pdk as download links
09:41 < nmz787> I guess they don't include anything about the seal/guard ring in their PDK? or other frame-abutting cells?
09:41 < lkcl> nmz787, the ... sigh.  ok, the google-sponsored shuttles have a "Management Core"
09:41 < kanzure> they what
09:41 < lkcl> you can't get direct access to the IO pads
09:41 < muurkha> they WHAT
09:41 < lkcl> you are forced to have some stupid RISC-V core on-board, all the time
09:42 < muurkha> can you control it?
09:42 < muurkha> or is it some google backdoor?
09:42 < lkcl> yes but you can't replace it
09:42 < muurkha> that sounds like it would make the google shuttle program totally useless for analog chips
09:42 < lkcl> it's there because it's considered to be "too hard" for n00b engineers to create their own complete ASIC
09:42 < lkcl> they have a *separate* analog Shuttle for that
09:43 < lkcl> but there is an advantage to that Management Core: it includes a PLL
09:43 < nmz787> is that core just for e-test and HVM testing?
09:43 < lkcl> which *is* damn hard to get right
09:43 < muurkha> and 130nm is a a lot less unappealing for analog chips than for digital chips
09:43 < lkcl> well i mean it wasn't so long ago that 800 mhz DDR3 ICs were done in 130 nm
09:43 < muurkha> because you can't really do analog at 10nm, the noise gets too high (I'm just repeating what people who actually know this stuff have said so I might be misinterpreting)
09:44 < lkcl> (800 mhz DDR == an actual clock rate of 400 mhz)
09:44 -!- mirage335 [~mirage335@64.79.52.86] has quit [Quit: Client closed]
09:44 < lkcl> muurkha, *all* ASIC design is analog :)
09:44 -!- mirage335 [~mirage335@64.79.52.86] has joined #hplusroadmap
09:44 < lkcl> even Digital VLSI Engineers sometimes forget that :)
09:44 < muurkha> sure, in the same sense that everything is analog
09:44 < muurkha> and, sure, 130 nm is already close to the end of frequency scaling
09:45 < nmz787> muurkha: yeah that's not quite right (analog at 10nm)
09:45 < lkcl> 180nm is pretty bullet-proof
09:45 < nmz787> analog - "everything between 1 and 0" 
09:45 < lkcl> which is one reason we're using it with Sorbonne University's coriolis2
09:45 < muurkha> I'm saying "analog" because I don't like to say "linear"
09:46 < lkcl> 130 nm is the point where you start to have to take into account parasitic losses, impedance of tracks, etc. etc. etc
09:46 < muurkha> but I'm talking about circuits where the metric of quality is SNR rather than BER
09:46 < muurkha> wrt 130nm or 180nm, there's a big difference between 120k transistors or 2M transistors and 48 million or 400 million transistors
09:47 < muurkha> even if they're at the same clock speed
09:47 < muurkha> which is the 2.6 orders of magnitude I was talking about
09:47 < lkcl> yehyeh absolutely
09:47 < kanzure> https://libre-soc.org/HDL_workflow/coriolis2/ http://coriolis.lip6.fr/ https://gitlab.lip6.fr/vlsi-eda
09:48 < muurkha> I also feel like even if you just want to shovel data to the I/O pins as fast as possible it would be ridiculously counterproductive to have a damn CPU plodding along one fucking instruction at a time between you and the I/O pad
09:48 < muurkha> like, what even is the point then?  3-D accelerators?
09:49 < kanzure> does their analog shuttle include the management core too?
09:49 < lkcl> ah right, ok, so this "Management" Core is controlling a GPIO Mux
09:49 < muurkha> oh, that's fine then
09:49 < lkcl> which is combinatorial
09:49 < lkcl> but
09:49 < lkcl> sigh
09:49 < muurkha> and analog probably
09:49 < muurkha> because pass transistors?
09:50 < lkcl> that combinatorial path, for whatever reason, has a hard limit of about 60 mhz on each IO pad.
09:50 < muurkha> any thoughts on powerlibre-soc power usage?  are we talking about 10000 pJ per instruction, or 1000, or 100, or 10?
09:50 < lkcl> don't ask me the details, i don't know all of them
09:50 < lkcl> muurkha, way too early to tell
09:50 < muurkha> that seems like one of the most important unknowns?
09:51 < muurkha> I mean for externally powered smart cards or server root of trust applications it probably doesn't matter
09:51 < lkcl> like, i'm not even going to start on that level of analysis because it's dwarfed by the nearly-an-order-of-magnitude saving you get from SVP64 Vectorisation
09:51 < muurkha> †where applicable, void where prohibited by law
09:51 < lkcl> after which it becomes pretty much a "standard computing architecture" problem
09:51 < lkcl> :)
09:52 < lkcl> to give an example: we implemented one of ffmpeg's MP3 CODEC functions in SVP64 assembler
09:52 < lkcl> it came out to an astounding 4.5x reduction in code size
09:53 < muurkha> that's pretty astounding yeah
09:53 < lkcl> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD
09:53 < muurkha> sounds like your non-vectorizing compiler had a code quality problem
09:53 < lkcl> so how the heck do you assess the power-efficiency of that? :)
09:53 < lkcl> the entire industry has a waaay worse problem than that, 1 sec...
09:54 < muurkha> well, a lot of the cases where you care most about power efficiency aren't vectorizable
09:54 < lkcl> this article scratches the surface: https://www.sigarch.org/simd-instructions-considered-harmful/
09:54 < lkcl> but drastically, for kindness/political/diplomatic reasons, underestimates its own significance
09:54 < lkcl> the key there:
09:54 < muurkha> yeah yeah, we know Patterson and Waterman are Cray lovers
09:54 < lkcl> * MIPS SIMD does 2 instructions per clock
09:55 < lkcl> * RVV can easily do 32 or 64 instructions per clock
09:55 < lkcl> i took that concept waaay further down the rabbithole
09:55 < muurkha> † 32 or 64 instructions per clock in simulation
09:56 < lkcl> yes, you of course have to have an actual back-end SIMD ALU that does the work
09:56 < muurkha> no actual shipping RISC-V silicon is delivering that kind of performance
09:56 < muurkha> but of course Cray did
09:56 < lkcl> but the point is that the front-end decode and issue sits there idle, twiddling its thumbs, doing bugger-all
09:56 < lkcl> and that means, inherently, less poewr
09:56 < muurkha> right, you're using the CPU instruction set as a scripting language for the vector unit
09:57 < lkcl> calculating *exactly* how much? this is something i don't want to get... "distracted" by, at this early stage
09:57 < lkcl> exactly.
09:57 < lkcl> or, more like, the ISA becomes more of a Software API
09:57 < muurkha> right
09:57 < muurkha> pretty similar to how an S1 MP3 uses a Z80 as a "scripting host" for its MP3 hardware
09:57 < lkcl> SIMD basically smashes the problem of what to allocate right into the programmer's face
09:57 < muurkha> but in a lot of cases where you care about power usage youcan't really vectorize
09:58 < muurkha> because you're doing scripting things, not DSP things
09:58 < muurkha> or even crypto things
09:58 < lkcl> Cray-style Vectors need a much more intelligent intermediary
09:58 < lkcl> yes... and... well... *traditional* Cray-style Vectors, yes.
09:58 < lkcl> but it turns out that there's something called Vertical-First Vectorisation
09:59 < lkcl> which took me about 2 years to get my head aroun
09:59 < muurkha> well, that' whta Patterson and Waterman are advocating in taht article, isn't it?  And in the V extension
09:59 < lkcl> i encountered it on comp.arch from someone named Mitch Alsup, but i just couldn't work it out
09:59 < lkcl> eventually, i realised it's this (dead simple)
09:59 < muurkha> so I'm not saying you should calculate exactly how much power, just saying that there are application areas that are open to Libre-SOC at 100 pJ/insn that are out of the question at 10000 pJ/insn, so it'd be nice to have some sort of order of magnitude
10:00 < lkcl> * Cray-style Vectors go horizontally through elements then move (vertically) onto the next instruction
10:00 < muurkha> well, that's the programmer model yeah
10:00 < muurkha> in reality they're pipelined through a much smaller number of ALUs
10:00 < lkcl> * Vertical-First you go onto the next instruction (just like in Scalar execution) then you call a "STEP" instruction, loop back, and do the EXACT same instructions with the NEXT element
10:01 < lkcl> well, we can do some estimates based on, for example, the SVP64 implementation of strncpy is only like... i think... 19 instructions
10:01 < lkcl> (in RVV it's about 13)
10:01 < lkcl> whereas for IBM POWER9 VSX it's a jaw-dropping 240
10:02 < muurkha> haha, why?
10:02 < muurkha> presumably a shorter strcpy would work fine on POWER9 but is slower?
10:02 < lkcl> because that SIMD article drastically under-emphasises the effect of the startup and teardown cost
10:03 < lkcl> you *literally* have to duplicate the algorithm at both startup and teardown, running at 16x SIMD then 8x SIMD then 4x SIMD then 2x SIMD then 1x scalar
10:03 < muurkha> I tore apart a DVD player a few years ago and was astounded to find that its main CPU was an 8051
10:03 < lkcl> in order to cope with all permutations up to 31 elements (16+8+4+2+1)
10:04 < muurkha> a gigantic 8051 integrated onto a chip with an MPEG decoder
10:04 < lkcl> haha yeah. with a hard-coded MPEG decoder silicon block, that wouldn't surprise me... yeah
10:04 < lkcl> you don't need more. i'm amazed it was even an 8051.
10:05 < muurkha> well, you can't really program a menu system with much less than an 8051
10:05 < muurkha> and I think the datasheet said it had like a meg of code space
10:05 < lkcl> so anyway, with Vertical-First, the programmer can still think sequentially, as long as they don't mind the idea of the loop-control being in hardware
10:05 < lkcl> wooow :)
10:05 < muurkha> I found the datasheet on the sort of Chinese site that you need a WeChat account to get access to nowadays
10:06 < kanzure> i want an emscripten/webassembly/llvm-opencl pipeline to hard silicon.
10:06 < lkcl> many of the 3D printer controller CPUs only have.. what... 48k? :)
10:06 < muurkha> 32K, a lot of them use an ATMega328
10:06 < kanzure> also, i think there needs to be a board/devkit that relays signals from (remotely) emulated/fpga-emulated chips so that you can test out driving screens, keypads and other peripherals without having fabricated a chip yet.
10:06 < lkcl> muurkha, i had to ask my contact to get things for me
10:06 < muurkha> because they're Arduinos
10:06 < muurkha> what kind of things?
10:07 < lkcl> kanzure, yeah Xilinx released their LLVM-IR thing last year
10:07 < juri_> kanzure: they make those.
10:07 < lkcl> i can't recall if it was the front-end or the back-end they released though
10:07 < kanzure> they make those? lemme look.
10:08 < kanzure> https://www.xilinx.com/about/blogs/ai-and-machine-learning-blog/2021/vitis-hls-front-end-now-open-source.html
10:08 < lkcl> Logic Analyzers are the modern version
10:08 < kanzure> https://github.com/Xilinx/HLS
10:08  * lkcl salutes juri_ 
10:08  * juri_ waves back.
10:08 < muurkha> logic analyzers don't usually allow you to inject signals, just sample them
10:08 < muurkha> as I understand it
10:09 < lkcl> my friend David used to work with an official Intel emulator of the 8086, back when the 8086 was actually being sold (!)
10:09 < lkcl> it was a DIL pin-compatible plugin (!)
10:09 < muurkha> yeah, ICEs have been common since the 01970s
10:09 < kanzure> "Back-end: This phase takes an LLVM IR input and performs FPGA-specific lowering and scheduling till the final step, RTL generation"
10:09 < kanzure> well that's cool.
10:10 < lkcl> ahh yeah that's the one.
10:10 < muurkha> in the 01980s even software programmers used ICEs
10:10 < muurkha> for debugging facilities
10:10 < lkcl> lol muurkha i love that you prefix dates with an extra zero
10:10 < muurkha> :)
10:10 < kanzure> https://longnow.org/ideas/02013/12/31/long-now-years-five-digit-dates-and-10k-compliance-at-home/
10:12 < muurkha> I think the standard development workflow for the Padauk chips uses an ICE
10:12 < nmz787> kanzure: I worked on remote-RTL-simulation test stimulus/response retrieval... SystemVerilog has the DPI interface so you can have C code running inside your RTL simulation, and can do stuff like network transport into and out of the simulation
10:12 < muurkha> because in a 3¢ CPU you can't afford to dedicate pins to debugging
10:13 < lkcl> nmz787, ooooOoo
10:13 < lkcl> oh wait, you mean like verilator?
10:13 < nmz787> idk, I never used that
10:14 < lkcl> verilator uses some well-defined RPC mechanism, i think it's called DPI...
10:14 < lkcl> yes! https://verilator.org/guide/latest/connecting.html
10:14 < lkcl> ok yes, i've used this technique
10:14 < nmz787> i owned a library that I'd shove into RTL testbenches, and then hook it up to Python so post-Si engineers could play around with their validation scripts before silicon arrived
10:14 < lkcl> a jtagremote interface which was compatible with openocd
10:14 < nmz787> the thing I owned also supported JTAG IR/DR access
10:15 < nmz787> I even hooked up xtensa to the simulations once
10:15 < muurkha> you can also use JTAG boundary scan as a sort of poor man's ICE, can't you?  as long as you don't care too much about timing
10:15 < lkcl> so i could use openocd as a bridge to connect to the simulatio
10:15 < lkcl> ooOoo
10:15 < lkcl> yes.
10:15 < lkcl> in our case, i followed what microwatt did, which is to assign some JTAG regs to read/write to Wishbone
10:15 < muurkha> how do you like Wishbone?
10:16 < lkcl> and also to DMI (Debug Memory Interface)
10:16 < nmz787> muurkha: JTAG is used for all sorts of programming and debug, bscan is only one thing it is commonly used 
10:16 < nmz787> (for)
10:16 < lkcl> muurkha, it's what i'd term a "take-it-or-leave-it" Contract of Sale Protocol
10:16 < muurkha> nmz787: yeah, of course
10:16 < nmz787> lkcl: yeah jtag2sideband is what we called anything like that
10:16 < kanzure> nmz787: was this for post-si engineers to get batch results later, or was it some sort of real-time connection, could it drive peripherals like a screen/printer/usb/whatever?
10:16 < nmz787> kanzure: it was real time
10:17 < lkcl> where AXI4, OpenCAPI and TileLink are more "House" Contracts: i.e. 3-step: Offer-Exchange-Complete
10:17 < lkcl> both have their uses
10:17 < muurkha> heh
10:17 < lkcl> nmz787, niiice
10:17 < nmz787> I set things up for batch processing too, but it never really got used
10:18 < lkcl> muurkha, summary is: if you want things like cache-coherence over wishbone you can forget it [or you have to "invent" it yourself, *over* wishbone]
10:18 < nmz787> kanzure: in practice though, peripherals were never connected, system level RTL sims are too slow
10:18 < lkcl> nmz787, i found simulations of DDR3, HyperRAM and Quad SPI online.
10:18 < nmz787> I mean, 2 weeks of simulating power-on and basic DRAM training is lame
10:19 < lkcl> and now have a fast enough machine that it wasn't too bad.
10:19 < nmz787> DDR subsystems are no problem to simulate training on, many hours, but not weeks
10:19 < lkcl> only took about... mmm.... 5-10 minutes to get initialised?
10:19 < lkcl> but that's with Micron's verilog simulation
10:19 < lkcl> *not* a SPICE model
10:20 < muurkha> lkcl: I see, thanks!
10:20 < lkcl> and definitely not with like the analog characteristics of the IO pads
10:20 < muurkha> yeah, how would you even do analog characteristics of I/O pads in Verilog?
10:21 < nmz787> I guess I was including compiling/elab... never included analog models, just digital
10:21 < lkcl> muurkha, with difficulty :)
10:21 < lkcl> i found this online and ran with it
10:21 < nmz787> usually link Matlab afaik
10:21 < lkcl> https://git.libre-soc.org/?p=gram.git;a=blob;f=gram/simulation/README.md;hb=HEAD
10:22 < muurkha> I have so much to learn
10:22 < lkcl> you have to download the proprietary ECP5 toolchain and extract the ECP5 verilog models
10:22 < muurkha> ew
10:22 < lkcl> but, astoundingly, it worked. uses Icarus Verilog
10:22 < lkcl> muurkha, i know. sigh
10:22 < muurkha> baby steps
10:23 < nmz787> lkcl: I have a feeling that 5-10 mins training encompassed far less than https://en.wikipedia.org/wiki/Memory_Reference_Code
10:23 < lkcl> there are so many rabbitholes you could go down
10:23 < muurkha> well, and more that need to be dug
10:23 < lkcl> nmz787, yeah it was reaal basic
10:24 < lkcl> more proof-of-concept, "get it up and running at 100 mhz"
10:24 < lkcl> but i did progress to actually running emulated instructions which performed the actual MRC job.
10:25 < lkcl> (again under Icarus)
10:25  * lkcl need to get up and walk about. it happens
10:25 < juri_> lkcl: sounds like you've been up to some seriously cool stuff. i'm kindof jealous. :)
10:26 < lkcl> juri_, serious rabbit-hole stuff, feels like i'm spinning wheels for weeks
10:27 < juri_> I'm currently writing the type system for an algebra of floating point precision loss when performing 2D projective geometric algebra on an FPU.
10:27 < muurkha> exciting developments.  libre-soc is definitely a bright spot, a nice contrast to Beijing lockdowns, SEO spam, and Mariupol
10:27 < juri_> if i get any more down the rabithole, i will dig into my own rear end. :)
10:27 < lkcl> juri_, ooOoo
10:27 < lkcl> hey do you need to do Formal Correctness Proofs of IEEE754 btw?
10:27 < juri_> hmm. maybe.
10:28 < lkcl> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=fp16mul_test.smt2;hb=HEAD
10:28 < lkcl> muurkha, i am so busy i totally ignore all that. been effectively a recluse for over 12 years
10:29 < lkcl> the hilarious thing was having *everyone else* join *me* in a reclusive lifestyle :)
10:29 < juri_> I've stumbled on a simple problem that has just the craziest level of rabit hole digging to find an answer.
10:29 < muurkha> lkcl: probably if I were to reclusify for a while I would get more done
10:30 < juri_> I'm hoping this is the last layer of algebra i need to decode, or i'm going to end up joining you. :)
10:30 < nmz787> lkcl: I've only been that way for about 4 years, but yeah "lockdowns" were not really even apparent to me
10:30 < lkcl> juri_, i know you don't do subtract-to-get-small-number-then-divide-by-that
10:30 < nmz787> actually I'm not even sure if my area faced lockdowns
10:30 < muurkha> they were apparent to me when they wouldn't let me ride the bus
10:30 < muurkha> so I couldn't get to my apartment
10:31 < lkcl> doh
10:32 < muurkha> the lamb stew rotted on the stove and I think was consumed by some kind of insect
10:32 < nmz787> how far was that to just walk?
10:32 < nmz787> (assuming you can walk well enough)
10:32 < muurkha> about 10km, but they were arresting people who did that
10:33 < nmz787> dang
10:33 < muurkha> according to the news
10:33 < nmz787> I don't think anything like that happened here, anywhere
10:33 < nmz787> I can only assume that's why your handle screams 'Merica when I read it
10:33 < muurkha> astoundingly the aloe plants on my balcony survived 8 months of lockdown without being watered
10:34 < nmz787> you couldn't get home for 8 months!!!???
10:34 < muurkha> right
10:34 < muurkha> I am in America, but I don't think this sort of lockdown is particularly characteristic of one continent or another
10:34 < kanzure> .title https://www.computer.org/csdl/proceedings-article/sp/2022/131600a687/1A4Q3q3W28E
10:34 < saxo> CSDL | IEEE Computer Society
10:34 < kanzure> grr
10:34 < nmz787> I thought you were in South America
10:34 < muurkha> that's right, I am
10:34 < muurkha> Argentina
10:34 < kanzure> "vSGX: Virtualizing SGX Enclaves on AMD SEV" https://www.computer.org/csdl/proceedings-article/sp/2022/131600a687/1A4Q3q3W28E
10:34 < nmz787> (which isn't 'Merica)
10:34 < muurkha> South America is the southern part of America.  it's literally in the name ;)
10:35 < nmz787> I mean in the typical US vernacular
10:35 < nmz787> I didn't know South Americans refer to their country(s) as 'merica
10:35 < muurkha> this reminds me of someone the other week who was trying to tell me Russia wasn't in Europe, when Moscow is literally the largest city in Europe (though of course part of Russia is in Asia)
10:35 < kanzure> muurkha: nmz787: y'all going to attend my workshop? https://www.blockchaincommons.com/salons/silicon-salon/
10:36 < nmz787> I seriously doubt Canadians go around calling themselves Americans
10:36 < nmz787> or changing "America, fuck yeah!"
10:36 < nmz787> chanting *
10:36 < muurkha> Simón Bolívar swore his life to liberate the "Americanos" from Spanish rule, not the "Sudacas"
10:37 < muurkha> I probably could have gotten to my apartment after a few months of lockdown because enforcement eased up, but I didn't want to risk being arrested while I'm an illegal alien
10:38 < nmz787> Americanos!=Americans though, up here
10:38 < muurkha> you do sometimes hear people say "Americano" to mean people from the US, especially the sort of people who aspire to move to Miami someday
10:38 < nmz787> Americano is a coffee drink :P
10:38 < muurkha> it's literally the same word though
10:39 < nmz787> it isn't, compare in any programming language using string comparison
10:39 < muurkha> the "o" is just an inflectional suffix
10:40 < kanzure> getting off-topic
10:40 < muurkha> anyway it's been a stressful few years.  I couldn't even get vaccinated for several months due to insufficient capitalism
10:40 < nmz787> well, how will humanity get plussed, if we can't even communicate this seemingly simple stuff?
10:41 < muurkha> probably through a small group of people who can
10:42 < muurkha> "muurkha" just means "idiot"
10:42 < muurkha> originally in Sanskrit
10:42 < nmz787> haha
10:42 < nmz787> my wife knows sanskrit, I'll ask her
10:42 < nmz787> this might be a great new joke
10:43 < muurkha> nowadays in hundreds of languages
10:44 < nmz787> .g number of languages in world
10:44 < saxo> https://blog.busuu.com/most-spoken-languages-in-the-world/
10:45 < nmz787> 7,100 languages
10:45 < nmz787> wtf
10:45 < nmz787> crazy
10:45 < muurkha> lots more than that 50 years ago
11:02 < nmz787> kanzure: idk, the meeting doesn't seem that interesting to me... from my perspective doing crypto is just logic design (IP authoring) which I'm not a big nerd about, as well as security stuff (which requires a large understanding of existing logic design (IP portfolio), OS/software/firmware interactions, attack surface... etc...) which I'm not all that knowledgable on (aside from that sentence I just 
11:02 < nmz787> spoke) 
11:03 < nmz787> https://www.youtube.com/watch?v=xBlwchTCHV0
11:03 < nmz787> .title
11:03 < saxo> Family Guy - Brian tries to speak Spanish - YouTube
11:04 < muurkha> kanzure: does eventbrite take bitcoin?
11:06 < kanzure> muurkha: i can send a coupon
11:06 < kanzure> done.
11:07 < muurkha> thanks!
11:08 < kanzure> hmm i would like an excuse to use verilator
11:17 < kanzure> .title https://github.com/Nic30/hwt
11:17 < saxo> GitHub - Nic30/hwt: VHDL/Verilog/SystemC code generator, simulator API written in python/c++
11:17 < kanzure> .title https://github.com/Nic30/hwtHls
11:17 < saxo> GitHub - Nic30/hwtHls: LLVM based HLS library for HWToolkit (hardware devel. toolkit)
11:56 < kanzure> .tw https://twitter.com/zetalyrae/status/1529084255812616192
11:56 < saxo> Drawing molecules in NanoEngineer-1 as a teenager was a great way to develop intuition for steric effects. (@zetalyrae)
11:56 < kanzure> you know what, if eudoxia doesn't return then we should just bridge his twitter
12:14 -!- mirage335 [~mirage335@64.79.52.86] has quit [Quit: Client closed]
12:15 -!- mirage335 [~mirage335@64.79.52.86] has joined #hplusroadmap
12:33 -!- mirage33591 [~mirage335@64.79.52.86] has joined #hplusroadmap
12:35 < kanzure> .tw https://twitter.com/kanzure/status/1529137749726478336
12:35 < saxo> Here's a sneak preview for the upcoming Blockchain Commons' Silicon Salon #1 -- take a look at my transcript of @lkcl's presentation on Libre-SOC, an open-source chip design project https://libre-soc.org/conferences/siliconsalon2022/ @ChristopherA @OpenPOWERorg (@kanzure)
12:36 -!- mirage335 [~mirage335@64.79.52.86] has quit [Ping timeout: 252 seconds]
12:37 < fenn> need a reaction-gif filter so i only see tweets that are actual messages
12:37 < fenn> i guess it wouldnt be that hard to go from gif to name-of-the-gif
13:23 -!- mirage33591 [~mirage335@64.79.52.86] has quit [Quit: Client closed]
13:24 -!- mirage33591 [~mirage335@64.79.52.86] has joined #hplusroadmap
13:48 < nmz787> fenn: just convert to ASCII art ;)
14:06 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has quit [Quit: brb]
14:11 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has joined #hplusroadmap
14:34 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has quit [Ping timeout: 240 seconds]
15:38 -!- spaceangel [~spaceange@ip-78-102-216-202.net.upcbroadband.cz] has quit [Remote host closed the connection]
15:46 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has joined #hplusroadmap
19:03 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::93] has quit [Quit: Leaving]
19:46 -!- darsie [~darsie@84-113-55-200.cable.dynamic.surfer.at] has quit [Ping timeout: 246 seconds]
23:51 -!- sivoais_ [~zaki@199.19.225.239] has joined #hplusroadmap
23:56 -!- Netsplit *.net <-> *.split quits: sivoais, muurkha
--- Log closed Wed May 25 00:00:33 2022