01:26 <mithro> https://arxiv.org/pdf/2311.03489.pdf talks about LLMs to generate Amaranth

01:33 <tpw_rules> strange that it describes amaranth as HLS

06:10 <tpw_rules> so i have 64 modules and every 16384 cycles at 50MHz they all produce a 16 bit word (on the same cycle, this can't be changed) and i want to shove them all into a FIFO in order. what's the best way to do this? a giant mux? some sort of OR tree? a giant shift register?

06:11 <tpw_rules> (most likely to pass timing and secondarily to reduce resource usage)

06:11 <tpw_rules> my money's on the shift register i think

06:52 <Wanda[cis]> yeah, just stuff them into a giant shift register; you'll effectively be doing a parallel write, serial read

06:52 <Wanda[cis]> doesn't really get cheaper than that

06:52 <Wanda[cis]> (nor easier to meet timing for that matter)

10:04 <galibert[m]> Wonder what it is, a little slow for a microphone array

16:40 <tpw_rules> the processing thereof :)

16:41 <galibert[m]> At 3Khz?

17:55 <tpw_rules> i just rounded the numbers heavily

17:56 <galibert[m]> Well, i any case, microphone arrays are cool

17:56 <tpw_rules> yeah some uni friends are handling the electronics and math. i signed up to tutor them on the fpga stuff

17:56 <galibert[m]> That's how I discovered fpgas 20 years ago, using one to read 32 stereo ADCs and turn the data into udp frames

17:57 <galibert[m]> At NIST

17:57 <tpw_rules> we're basically doing that + an ungodly quantity of processing

17:57 <tpw_rules> but i don't wanna talk too much, it's not my project

17:58 <galibert[m]> Yeah, at the time there was no way to do the processing on the fpga. The network was barely good enough to send the data in the first place

17:58 <galibert[m]> And the fpga was a spartan 2

17:59 <tpw_rules> how did you hook it to ethernet?

17:59 <galibert[m]> With a PHY. If was fast ethernet then, 25MHz was enough

18:00 <tpw_rules> we're passing it through a linux soc in large part because that's how the board is wired... and for learning

18:00 <galibert[m]> The bitstream did the ethernet frames (crc mostly), arp and udp

18:00 <galibert[m]> I don't remember if we had managed bootp

18:00 <tpw_rules> i also didn't want to try to do that stuff, i know linux networking is good

18:01 <galibert[m]> Still there: https://www.nist.gov/itl/iad/mig/nist-smart-space-project/nist-smart-space-project-microphone-array/mk3-downloads

18:02 <galibert[m]> Well, I was working on MKII, not 3

18:02 <tpw_rules> mmm, java, perl, endian swapping...

18:02 <tpw_rules> eagle

18:02 <tpw_rules> did you run this on a Sun too?

18:02 <galibert[m]> (and 1, I made 1 work too, it was using a tms dsp for the a/d)

18:03 <galibert[m]> Nah, linux already

18:03 <tpw_rules> :P

18:06 <galibert[m]> But yeah, nowadays going through a linux soc makes a lot of sense

18:07 <galibert[m]> the hardware and software panorama has changed a lot

21:12 <omnitechnomancer> Why do arp when multicast is right there

21:20 <galibert[m]> 2001, multicast was not really right there

22:12 <omnitechnomancer> I guess it depends on network topology and software

22:38 <ktemkin> just a heads up: I wrote up the /vendor code for Efinix FPGA support over the weekend, and plan on PR'ing soon

22:38 <whitequark[cis]> oh, nice! thank you ktemkin

22:42 <ktemkin> np ^^; hopefully it's palatable enough -- their toolchain is a PITA in that their required environment setup needs PYTHONHOME to be set to their python site

22:43 <whitequark[cis]> the build process is completely separate from the build tree construction process, so I think this is completely OK; there does not need to be any link between the two Python environments (in fact there should not be)

22:43 <whitequark[cis]> existing toolchains do similar things with environment variables, so I think something like AMARANTH_ENV_EFINIX=/path/to/toolchain/root would be the way to do it? with a PYTHONPATH=${AMARANTH_ENV_EFINIX}/lib/site-python or something like that in the build script

22:44 <whitequark[cis]> this is just a rough idea; I'm sure your implementation will be fine

22:44 <ktemkin> https://github.com/ktemkin/amaranth/blob/with_efinix/amaranth/vendor/_efinix.py#L149 <-- I'm trampolining, since I don't necessarily get the EFINITY_HOME variable until AMARANTH_ENV_EFINITY is evaluated

22:45 <whitequark[cis]> actually, I don't know if you've seen, but Glasgow now does something approximating hermetic builds based on Amaranth and yowasp; in these, the build script is executed in a controlled environment with almost (Windows stores processor type in the environment for some godforsaken reason) nothing but AMARANTH_* vars, and every input is checksummed

22:45 <ktemkin> neat

22:46 <whitequark[cis]> ktemkin: ah, are you essentially writing the small shell script I would normally make for this purpose (twice, once for *nix and once for Windows) in Python because Python will by definition be available if Efinity is installed?

22:48 <ktemkin> yep

22:48 <whitequark[cis]> sgtm

22:48 <ktemkin> (well, right now I'm running it using sys.executable, but by PR time, it should use Efinity's python so it doesn't break remote builds)

22:48 <whitequark[cis]> any chance the glob will return more than one value, or is it just "one version of Python but we don't know which

22:48 <whitequark[cis]> * know which"?

22:49 <ktemkin> not unless they start shipping more than one version of python, which they haven't yet

22:50 <whitequark[cis]> gotcha. seems fine to me

22:50 <whitequark[cis]> looking at line 203, I'm starting to understand how this works

22:50 <whitequark[cis]> this is kind of cursed

22:50 <whitequark[cis]> what the vendor is doing, I mean

22:51 <ktemkin> it's /almost/ not cursed; their whole toolchain is automatable from python, so you can do things like assign I/Os directly from a python API

22:51 <ktemkin> but, of course, it has to be _their_ python -_-

22:52 <whitequark[cis]> is run_efinity_platform_tool just something you are using for testing?

22:54 <whitequark[cis]> oh, and just a minor thing, you don't need a vendor/efinix.py; we stopped using vendor.platform per RFC 18 (https://amaranth-lang.org/rfcs/0018-reorganize-vendor-platforms.html) so now it's just from amaranth.vendor import EfinixPlatform

22:54 <whitequark[cis]> anyway, I can make a proper review when a PR comes in; don't have to do it right now >_>

22:54 <ktemkin> run_efinity_platform_tool> it's there until I figure out a better way to program their devices; honestly I might just write a programmer myself rather than use their deep script

22:55 <whitequark[cis]> ahhh I see

22:55 <whitequark[cis]> that's ... it's ... definitely cursed...

22:57 <whitequark[cis]> yeah that might be one of our weirdest platforms once it gets merged. I don't really see any significant issues with the approach, it's just weird

22:58 <tpw_rules> silly question: is this wrong? https://github.com/tpwrules/de10_nano_nixos_demo/blob/e92f9158b6c91803d0b49dc8ba365d0843b9e7f5/design/amaranth_top/amaranth_top/top.py#L40 should that be an instance of the platform rather than the class?

22:58 <whitequark[cis]> it should be an instance

22:58 <tpw_rules> ok

22:58 <whitequark[cis]> the way platforms work is that a platform file is used for dependency injection, and it contains all the state involved in doing so

22:58 <whitequark[cis]> er, platform class

22:59 <ktemkin> whitequark[cis]: it's a super weird toolchain -- they don't do verilog macro-instances for their hard IP; instead, they just configure the hard IP in an XML file and then treat the IP boundary like they're I/Os

22:59 <whitequark[cis]> tpw_rules: so the design is meant to be static during elaboration, and all of the mutable bits, and all of the platform specific bits go into the platform instance

23:00 <whitequark[cis]> in theory you should be able to create a design once and then build it several times with different platforms

23:00 <whitequark[cis]> though i don't know of anybody actually doing this

23:00 <tpw_rules> ok. cause it seemed to work not as an instance until it needed to call a function on the platform to generate a synchronizer

23:00 <whitequark[cis]> ktemkin: yeah I see. it makes some kind of sense but it also means you have to bring everything to the top because it's annoying

23:01 <ktemkin> their FPGAs are simple enough that the hard IP is only on I/O boundaries for now (e.g. MIPI CSI Rx), so it's not biting them in the ass Yet (TM)

23:05 <whitequark[cis]> ahhh

23:05 <whitequark[cis]> makes sense

23:15 <omnitechnomancer> I assume they have no DSP blocks then?