<whitequark[cis]>
this is an official board from Lattice, it has the fastest iCE40 FPGA available, it works well, it is cheaper than iCEBreaker that is well designed but has the same slow UP5K FPGA
<whitequark[cis]>
actually, no, almost exact same price
<whitequark[cis]>
the MCU only has USB 12 Mbps but it might be enough for your purposes
<sorear>
how usable is the oss xilinx7 tools these days compared to ecp5 or ice40?
<whitequark[cis]>
they're still vaporware I think
<whitequark[cis]>
I would not recommend them to a beginner under any circumstances, especially considering that Vivado isn't ISE and is a reasonably okay toolchain
<whitequark[cis]>
other than, you know, wanting all of your disk space a few times over
<whitequark[cis]>
the link I posted has a bundle too
<whitequark[cis]>
and that's what I would recommend to buy since the MCU is on the baseboard
cr1901 has quit [Ping timeout: 248 seconds]
omnitechnomancer has quit [Quit: Idle timeout reached: 172800s]
gatin00b[m] has quit [Quit: Idle timeout reached: 172800s]
jevinskie[m] has joined #amaranth-lang
<jevinskie[m]>
There are still two Versa ECP5-5G in stock at Newark, likely the last two left on earth. I got the last one from mouser last month after one suddenly appeared in stock. I had ordered a Versa ECP5 (lead time was shorter than ECP5-5G at the time) on backorder from mouser last august but the ETA kept getting pushed back every month and it’s into October now (reminds me I need to cancel the order). I have plans to use it for PCIe
<jevinskie[m]>
sniffing/MITM since there is an incomplete FOSS implementation of PCIe IP that I think with enough work could be used as a root complex. Looking at it now I don’t think there is Lattice IP that provides root support though so I probably won’t get a second one to complete the sniff/MITM bundle since I don’t feel like I have the skills to complete the FOSS implementation or add root support to it. Either way here is the link,
<jevinskie[m]>
I think I’m going redirect my efforts into using Gidel HawkEye-20G-48 accelerator cards, since I’ve amassed 3 or 4 of them between $125 and $200 on eBay. The hard PCIe IP seems to support both endpoint and root via Avalon Streaming of TLPs. Plan is to send the TLPs back and forth over Ethernet on one of the SFP ports (for MITM I’d use a soft-core for the modifications and I suppose I could use both SFP ports to increase
<jevinskie[m]>
bandwidth) and for sniffing I’d use the other SFP port on either device to dump the TLPs over Ethernet to a PC for logging. I’ve got the top level verilog module that has the connections to the other ICs on the board and the Quartus pin config file from Gidel. I’ve gotten blinky working but have been put off by the complexity of configuring the hard IP block (I can’t stand to use Quartus MegaWizard IP GUI configuration and
<jevinskie[m]>
implementing everything above the PIPE interface myself. There’s not a lot of GPIO but it is a beefy FPGA for the price and you can add a DDR4 SODIMM on the back of the board. $175 shipped. https://www.ebay.com/itm/265450537532
<jevinskie[m]>
the block itself is quite daunting to me, so I’ve been procrastinating on wrapping the hard IP block with amaranth or LiteX). I’m pretty sure I can get all the TLPs via Avalon-ST unlike Xilinx hard IP that automatically handles some of the bringup packets which I fear would make the setup non-transparent. If all else fails the hard IP also exposes a PIPE interface which should allow complete transparency at the cost of
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #amaranth-lang
<jevinskie[m]>
mcc11: I also went on a buying spree when the Terasic DECA was being sold off for $35. I think I have enough to spare if you want one of mine. It’s a really nice board.
<galibert[m]>
Afaict the Altera cyclonev in the de10-nano does arm integration reasonably sanely. But I may have missed a kink or two at this point
<jevinskie[m]>
The one thing that bothers me about hard processor FPGAs (Cyclone V, the variants of Zynq I’ve seen in boards affordable to me) is all the boards I’ve seen only have memory controllers attached to then hard processor and none with a MC dedicated to then programming logic fabric and I wan’t the lowest latency access to DRAM as possible from the PL side =\
<jevinskie[m]>
And at least Zynq requires HPS running to configure/use the PL. At least the Cyclone V can be brought up with just the PL and you can ignore the HPS.
<galibert[m]>
De10-nano has the good idea to be used in the mister so people make sdram extensions for them. From what I understand the quality of the design is not spectacular, but it exists
<M8c4db68ff02f4fa>
Earlier it was mentioned to get a good mcu and fpga, and just connect 5 wires, and that’s basically what I did. Went a bit overboard and designed my own RP2040 dev board and ice40lp384 pmod. The RP2040 runs circuitpython and loads the bitstream into the fpga.
<M8c4db68ff02f4fa>
I still have a bunch of HX8K chips, and want to design a pmod with that.
<mcc111[m]>
<whitequark[cis]> "mcc111: how do you feel about..." <- I know how to do it and have done at least one complex build (under some supervision) but i don't own a soldering iron and my living/working space is *extremely* short on space which would create problems with acquiring and storing a soldering iron. There used to be a makerspace I'd go to to use the one at but it closed :( If I had regular soldering to do tho I bet I'd figure
Wanda[cis] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
there is nothing specific about SPI that's currently included in Amaranth
<whitequark[cis]>
<galibert[m]> "Afaict the Altera cyclonev in..." <- No it's not, try to use it in Amaranth and you'll see
<galibert[m]>
I haven’t had the time to build an axi interface yet to see how it goes
<whitequark[cis]>
It's one giant opaque instance that's very difficult to manage
<whitequark[cis]>
I can't imagine people enjoy doing this in bare Verilog either
<galibert[m]>
Oh, you mean the interface exposed by quartus?
<galibert[m]>
Didn’t look at it much, as you know I’m lower level
<whitequark[cis]>
I think that's the lower level one
<whitequark[cis]>
I'm talking about an undocumented primitive with a hundred or two of ports
<galibert[m]>
IIRC it’s mostly a dual 32 bits register (one per direction), an axi for hps->fpga, another for the other way around, six ports for direct lpddr access and 32 interrupt lines
<galibert[m]>
Sure you’re not talking about the pcie interface which looks batshit ?
<whitequark[cis]>
hmm
<whitequark[cis]>
I may be misremembering
<whitequark[cis]>
I'd have to look more closely at it
<galibert[m]>
(Perhaps understandable by someone who understands pcie, that would not be me)
<whitequark[cis]>
can you show me the PCIe primitive?
<whitequark[cis]>
I think I probably do understand PCIe, or at the very least I can ask someone who I know does
<galibert[m]>
Not from my phone
<galibert[m]>
I couldn’t find any evaluation board with a cyclonev and a pcie port, so maybe it’s not that useful to expend energy on it
<galibert[m]>
The boards with one tend to have beefier fpgas
<galibert[m]>
Awesomely more expensive fpgas obviously
<mcc111[m]>
<whitequark[cis]> "there is nothing specific..." <- okay. is there a library, or a best practice?
<mcc111[m]>
do i… create a fifo, to a clock domain that's at SPI speed, and bitbang in that other domain?
<mcc111[m]>
* library, or an existing open source example, or a best
<mcc111[m]>
* okay. is there a library, or an existing open source example, or a best practice?
<mcc111[m]>
if i do it myself do i… create a fifo, to a clock domain that's at SPI speed, and bitbang in that other domain?
<whitequark[cis]>
this is an excellent question! the answer is that "it depends" and it's not me being evasive, it really does depend on the application and your requirements (which is a part of why it's not in the stdlib; it's a surprisingly complex topic in an FPGA)
<whitequark[cis]>
can you tell me more about your application? especially about clocking
<whitequark[cis]>
literally every device with SPI includes its own spec for what the "SPI" peripheral actually does
<whitequark[cis]>
(this is important, sometimes they happen to be subtly incompatible in some of the rarer modes)
<whitequark[cis]>
s/peripheral/module/
<mcc111[m]>
anyway, i guess, my hope is the samd will turn out to have a non-blocking method of reading the spi if i can find this C++ class's header file, and i can periodically read that to see if there's a byte with a 4-bit update from the fpga.
<mcc111[m]>
Oh.
<whitequark[cis]>
the wikipedia page, and anything else you'll read, is a product of someone reading a bunch of those datasheets and writing an overview to the best of their ability
<whitequark[cis]>
just to be clear on what you're dealing with here
<mcc111[m]>
Well, as you've seen, the Doppler appears to be somewhat underspecified.
<mcc111[m]>
But I've found the SAMD's manual before and it surely is quite specific what it means by SPI.
<whitequark[cis]>
yes.
<whitequark[cis]>
you can (and should) use that when implementing your peripheral. in this case wikipedia is likely ok, but this is a good habit to get into
<whitequark[cis]>
because in more complex cases (as soon as I2C gets brought up for example) you will hit incompatibility
<mcc111[m]>
ok
<mcc111[m]>
I don't know if there are communication lines other than SPI. I was going with SPI because I thought it would be the easy one. I guess I could just ignore the SPI spec, have the FPGA directly drive the four pins supposedly reserved for SPI (hoping that's allowed) and have the SAMD read them.
<whitequark[cis]>
which device is the clock master is important
<whitequark[cis]>
let me check the schematic
<mcc111[m]>
But, to the extent this is a learning project, it seems like if I can't maintain some kind of serial connection with the outside world I won't be doing much interesting in my fpga
<whitequark[cis]>
I think they're probably reusing the configuration pins for SPI comms
<whitequark[cis]>
I should just print it out heh
<mcc111[m]>
the C++-side interface has a `ice40.initSPI()` function.
<mcc111[m]>
this implies if this function is *not* called, then those pins are available for GPIO
<whitequark[cis]>
why does it print a million blank pages >_<
<mcc111[m]>
I guess it turns out it's a SAM D5x, not a SAMD 5x as I'd assumed
<mcc111[m]>
but whatever
<whitequark[cis]>
I just want to state it for posterity that I really don't like this schematic
<whitequark[cis]>
it's actively hostile to doing anything useful with it
<mcc111[m]>
Yes, I don't like it either, I was confused because I've sometimes made sense of some schematics before but this one i'm baffled by
<mcc111[m]>
so if you're also confused maybe this is not entirely me
<whitequark[cis]>
no it is an objectively terrible schematic that is broken in ways I have not previously seen
<whitequark[cis]>
and I've read probably hundreds if not thousands of schematics
<mcc111[m]>
this is another reason I would perhaps find it acceptable to leave some things about this board mysterious, if I can complete my immediate goals, as I have two entirely other fpga boards on the way from aliexpress
<whitequark[cis]>
once the FPGA is configured the pins are released for the user bitstream
<whitequark[cis]>
s/bitstream/application/
<whitequark[cis]>
these are connected to PB02, PB03, PB22, PB23
<whitequark[cis]>
which are SERCOM5.[0-3]
<whitequark[cis]>
do you know which serial port is being used on the SAMD?
<mcc111[m]>
Does it have more than one?
<whitequark[cis]>
it has at least 6!
<whitequark[cis]>
it's exactly 6, actually
<mcc111[m]>
"Up to eight Serial Communication Interfaces (SERCOM), each configurable to operate as e" oh.
<mcc111[m]>
i guess not, so i guess i really do need to find the C++ implementation of that ICE class.
<whitequark[cis]>
I think the last 2 are not available on this package
<mcc111[m]>
ok
<mcc111[m]>
note, i do have a verilog implementation of SPI for this device, though I think it might only be fpga-reads
<whitequark[cis]>
actually, I think I can simplify the approach for you, I can figure some of this out from the schematic
<mcc111[m]>
ok
miek[m] has quit [Quit: Idle timeout reached: 172800s]
<mcc111[m]>
any help appreciated D:
<whitequark[cis]>
no, I cannot sadly, there is a ton of pins connected between the FPGA and the MCU
<mcc111[m]>
ok.
<mcc111[m]>
I am leaning to the "abuse the spi pins so i can communicate my four bits" approach at this point
<whitequark[cis]>
so ideally I'd need the source of that clas
<whitequark[cis]>
s/clas/class/
<whitequark[cis]>
four bits? can you elaborate?
<mcc111[m]>
For the current application, which depending on how quickly that other kit arrives may be the only fpga application i ever write for this board, the only communication i need to send is the current state of one four-bit register, which is updated infrequently and not on a consistent schedule.
<mcc111[m]>
Therefore, if I have four pins connecting the FPGA and MCU, even if they are intended for some other purpose, I could just drive them from the FPGA side and continuously read them from the MCU side, and then I would not need SPI for this project.
<whitequark[cis]>
ah! yes, this absolutely works
<whitequark[cis]>
so let me give you a pin correspondence
<mcc111[m]>
I would have considered setting up SPI just for the experience, but it is looking like getting SPI working here will be a little bit of learning about SPI and a lot of trying to decode what dadamachines did but did not clearly document.
<whitequark[cis]>
incidentally, this thing you're encountering right now? work around completely bonkers documentation, failures of others, opaque toolchains, etc? this is easily 70% of what all embedded development is
<whitequark[cis]>
s/work/working/
<mcc111[m]>
ok
<mcc111[m]>
well maybe it will be worth it if it is not for a board which is (1) discontinued (2) now 6x the cost of comparable devices on aliexpress
gatin00b[m] has joined #amaranth-lang
<gatin00b[m]>
Adding those two would make it ~85% of what embedded dev is.
<whitequark[cis]>
yep
<whitequark[cis]>
the other 15% is trying to get the companion MCU to do something at all reasonable
<whitequark[cis]>
embedded dev is a really good field of work if you're a masochist
<gatin00b[m]>
Or if you enjoy trauma bounding
<gatin00b[m]>
Very inclusive, everyone suffers.
<whitequark[cis]>
hey why would you call me out like this
<gatin00b[m]>
That also explains why we all end up making our own FPGA+MCU platform
<M8c4db68ff02f4fa>
At least then I know who to blame for bad documentation
<M8c4db68ff02f4fa>
though I'm not quite sure what is worse, doing software or hardware at scale.
<whitequark[cis]>
hardware.
<whitequark[cis]>
absolutely, hardware.
<galibert[m]>
mcc111: “discontinued ” tends to be the normal state of affairs though
<jevinskie[m]>
You can also get PIPE interface bypassing Avalon-ST
<whitequark[cis]>
ohhhh I see
<whitequark[cis]>
that's actually kind of convenient?
<jevinskie[m]>
Yeah if there was good FOSS PCIe PIPE IP :(
<whitequark[cis]>
you could probably pay @VioletEternity to develop it
<jevinskie[m]>
And you can even go lower than PIPE to the, iirc PCS interface?
<whitequark[cis]>
yeah! though if you have PIPE you can implement USB3 on top of this already
<whitequark[cis]>
well... probably, as I've been corrected
<whitequark[cis]>
it depends on how exactly they implemented PIPE
<jevinskie[m]>
I’ve seen https://github.com/enjoy-digital/usb3_pipe but it’s still unclear to me what PCIe PIPE to usb3 would look like. Does it require a different driver on the host or does it show up as an XCHI controller hanging off PCIe?
<whitequark[cis]>
that repo barely works
<whitequark[cis]>
the clock tree in it is completely bonkers and not really suitable for USB
<jevinskie[m]>
I have a sfp2usb adapter but haven’t tried using it yet :)
<whitequark[cis]>
USB3 MAC can use a PIPE transceiver to talk to the other side
<whitequark[cis]>
PIPE is a converter between (USB|PCIe) to diffpairs
<whitequark[cis]>
in newer versions they added in SATA and something else
<whitequark[cis]>
@VioletEternity spent like a week cursing at the choices done in usb3_pipe that ended up getting blindly copied to LUNA
<jevinskie[m]>
Gotcha. And ugh that’s not good news because I was going to say LUNA has PIPE support too and was wondering how they compared
<whitequark[cis]>
in essence that commit changes the clocking architecture so that there is one PCS-side clock (generated by dividing the TXPLL clock, I think?) and the PMA->PCS elastic buffer is used for CTC and SSC, instead of having two largely independent RX and TX halves that are unified later, post-PCS
<whitequark[cis]>
there were a few more issues like not really following the Xilinx erratasheets correctly, but she would be in a better position to discuss that in detail
<whitequark[cis]>
I mostly just was a fly on the wall seeing her work on this and the amount of disappointment I ended up having in both usb3_pipe and LUNA was immense. though LUNA should be a lot better now; I have a reasonable amount of confidence in the PIPE part, and I've seen retransmits actually work
<whitequark[cis]>
it has influenced my decision to not use LUNA in the next version of Glasgow unless it is significantly improved and much more widely tested from the state it's currently in
<whitequark[cis]>
I do know the LUNA PIPE interface (still) does not handle power management at all and unless you turn off everything below L0, you'll get spurious disconnects (@miek, could you have been hitting that?)
<whitequark[cis]>
that's a part of why I think it cannot be shipped in Glasgow, it's not really an option to not handle the non-optional power states
<whitequark[cis]>
there are some more issues, like that the EP0 is written in a way that you cannot close timing on ECP5, and she had to test PIPE with --allow-timing-fail
<whitequark[cis]>
considering that on Glasgow the FPGA would be shared by a (often sizable) applet gateware, that doesn't seem like something I can ship
<jevinskie[m]>
I guess I lucked out when I used LUNA with the ULPI PHY on my DECA board and got good results. I did need a beagle480 to debug *my* bulk transport protocol issues though
<whitequark[cis]>
most of the things I'm mentioning are not an issue for LUNA-on-USB2
<whitequark[cis]>
this is specifically USB3 issues
miek[m] has joined #amaranth-lang
<miek[m]>
<whitequark[cis]> "I do know the LUNA PIPE interfac..." <- ooh, that does sound familiar actually. let me see if i still have the capture
<whitequark[cis]>
I can say this is something she definitely encountered and had to work around in order to not have the interface fail very quickly; she mentioned she did not fix it because the MAC changes required were not in scope for the contract
<jevinskie[m]>
Not sure why my message containing the link to usb3_pipe repo suddenly descended way down and is now only a few messages above current. Element.app quality I guess.
<whitequark[cis]>
yeah I've seen other people mention hitting that issue
<galibert[m]>
Me too [tm]
<jevinskie[m]>
It just did it again!
<whitequark[cis]>
restart the app?
<galibert[m]>
Are you saying a pcie fpga hard ip could somehow be turned into usb3?
<jevinskie[m]>
With a crowbar perhaps…
<zyp[m]>
galibert[m]: the lower layers are pretty similar
<galibert[m]>
I really don’t understand the links between pcie, usb3, usb c, Thunderbolt, etc
<jevinskie[m]>
And yes Catherine that seems to have fixed it :)
<whitequark[cis]>
galibert[m]: the lower layers are not just similar, PIPE is explicitly designed to support both PCIe and USB3
<whitequark[cis]>
@VioletEternity's work could (with some modification) be a base for a PCIe device written in Amaranth
<zyp[m]>
I considered writing identical, but then somebody would argue that the speed modes or something are different
<whitequark[cis]>
some vendors (such as ... @VioletEternity) implement only a subset of the modes. she only implemented the USB3 mode, since that's what she was contracted to do
<whitequark[cis]>
so her PIPE implementation is not fully compliant. however I don't know if Intel's is fully compliant either. that's why I made a guarded statement in the end
<whitequark[cis]>
they've considerably simplified PIPE in PIPE 4 and above (for PCIe Gen4), with the introduction of SerDes PIPE
<whitequark[cis]>
@VioletEternity ended up working with that at work and she's got a lot of training materials from MindShare that explain PCIe 5 and PIPE 5 in detail
<whitequark[cis]>
which were really interesting to peek at
<whitequark[cis]>
actually, maybe it was PCIe Gen6? I don't quite recall anymore
Maya[m] has joined #amaranth-lang
<Maya[m]>
It was PIPE 6 and PCIe Gen5
<galibert[m]>
So many things to learn
<whitequark[cis]>
ah here you go
<whitequark[cis]>
she also ended up learning about DDR4/5 and LPDDR4/5
<whitequark[cis]>
very cool tech, I don't know anyone else who worked with top-of-the-line DDR and PCIe
<whitequark[cis]>
huh, it looks like @VioletEternity is the wrong highlight and I should've been using Maya all this time, oops
<Maya[m]>
My username is Maya (@_discord_986698417407410176:catircservices.org), not @VioletEternity, so that might be the reason Discord doesn't pick up the highlight
GenTooMan has quit [Ping timeout: 246 seconds]
<mcc111[m]>
Is there actually a difference between SB_LVCMOS and SB_LVCMOS33?
GenTooMan has joined #amaranth-lang
<whitequark[cis]>
not really. in general IOSTANDARD mostly matters for the PNR telling you "you can't combine 3.3V and 2.5V IO in one bank"
<whitequark[cis]>
but nextpnr doesn't actually do that anyway
<Wanda[cis]>
huh, does IOSTANDARD really have no effect for ice40? xilinx uses it for a few things (regulating drive strengths + picking the right input buffer)
<whitequark[cis]>
only for the LVDS inputs in bank 3, and even then there are 2 threshold options iirc
<Wanda[cis]>
I see
<Wanda[cis]>
xilinx has... rather a fuckload of iostandard-controlled options in IOB actually
<mcc111[m]>
Left button scrambles the LEDs, right button progresses a rule 30 CA, top row status is being pushed to a microcontroller which is creating audio (a chord sequence) from it
<jevinskie[m]>
Oh, Maya, I didn’t notice you were in here, (I was looking for VioletEternity as well). I sent you an email about a potential commission for an open source Amaranth wrapper for the Arria V PCIe hard IP block we’ve been discussing.
<whitequark[cis]>
mcc111: oh wow this rules
<Maya[m]>
jevinskie (@_discord_335628456182415361:catircservices.org) I will respond shortly. Thank you!
<jevinskie[m]>
Thanks you! :)
<jevinskie[m]>
* Thank you! :)
<jevinskie[m]>
And I’ve accidentally been calling it Arria V, when it’s actually for Arria 10.
<mcc111[m]>
<whitequark[cis]> "mcc111: oh wow this rules" <- Secret to generative audio: Just make a minor chord. Pick any minor chord. It'll just sound good.
<mcc111[m]>
(Other secret to generative audio: If it sounds bad, add echo. I was planning to add echo on this one but it already sounded pretty good so it didn't matter.
<mcc111[m]>
(The advanced version of the secret I describe above is to use a pentatonic scale.)
<mcc111[m]>
(…Actually, it's possible "use a pentatonic scale" is the easy mode and "make a minor chord" is the advanced one.)
<mcc111[m]>
Since I have (other than the SPI stuff qua SPI) now tested this board def quite a bit, maybe I will PR it into amaranth-boards and credit adamgrieg, charlotte and whitequark in the commit/PR?
<whitequark[cis]>
yep sure!
notgull has quit [Ping timeout: 240 seconds]
<mcc111[m]>
By the way, one more question: What is the general shape of "working with floating point" in Amaranth? I know I am poking a bees nest here
<whitequark[cis]>
you are entirely on your own
<gatin00b[m]>
It's not just Amaranth, it's pretty much any HDL out there.
<gatin00b[m]>
Except maybe HLS, but like Catherine said, you're pretty much on your own on that one.
<mcc111[m]>
ok
<mcc111[m]>
i notice it's very easy to find RISCVi softcore source but RISCVf not so much
<whitequark[cis]>
you won't be able to fit FP in ice40
<mcc111[m]>
What about on the "ECP5U-25"?
<mcc111[m]>
Or the… "GW1NR-9"? (These being the chips I believe to be on the Colorlight i5 and Tang Nano 9K boards you've previously spoken well of.)
sys64738_2574[m] has joined #amaranth-lang
<sys64738_2574[m]>
the ECP5 should have plenty of room for that. the gowin part less so (plus it's not as well-supported as the two lattice parts)
<sorear>
"entirely on your own" extends to knowing exactly how much precision, exponent range, operations, and support for special cases you need. you can probably make fp8 work
<zyp[m]>
a google search suggests a typical single precision FPU will consume around 20kLE, so I'm not sure you can fit one in either of those
<zyp[m]>
but the colorlight i9 is a drop in replacement for the i5, with the larger ECP5U-45
<mcc111[m]>
Could FP be done in smaller constraints if one abandoned some parts of the standard (for example, supporting only normals)?
<zyp[m]>
probably
<whitequark[cis]>
GW1NR-9 is about as big as ice40hx8k
<sorear>
you can also save a lot by going to a multicycle design
omnitechnomancer has joined #amaranth-lang
<omnitechnomancer>
vegard_e (@_discord_157944445168254976:catircservices.org) does the 20k le include the big MAC?
<omnitechnomancer>
You could also always just implement the registers or whatever and make the operations trap and get done in software
<zyp[m]>
uh, I don't know what goes into it and I'm not even sure that number is right, I might have misread :)
<whitequark[cis]>
<omnitechnomancer> "vegard_e (@_discord_157944445168..." <- what bigmac?
<whitequark[cis]>
oh, the multiply and accumulate unit
<sorear>
worth noting that riscv-pk/bbl includes a FP emulator already and it was heavily used in 201x
<omnitechnomancer>
Yea the big multiply accumulate that you need