<mcc111[m]>
Some interesting friction trying to run gtkwave— I was hoping to execute the x11 version from a Mac so I could run it headless. I WAS able to install a version from Homebrew, which is a regular Mac app. When I tried to build (what I think is?) the x11 version, the -gtk3 branch in SVN, it failed because it can't find a function related to gtkplug. Gtkplug is documented as not present on all platforms. So it appears either this is a
<mcc111[m]>
new bug in most recent gtkwave, or gtkwave Mac can only be mac not x11
<mcc111[m]>
(again not a problem tho because I can run the homebrew version)
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 260 seconds]
<galibert[m]>
Damn, the rkx7 is a little too expensive for a hobby
galibert[m] has joined #amaranth-lang
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
nyanotech has joined #amaranth-lang
<mcc111[m]>
Yeah, I'm not exactly saying I'm considering buying one lol
robtaylor has quit [Read error: Connection reset by peer]
<whitequark[cis]>
mcc111: yeah gtkwave is unfortunately not great
vipqualitypost[m has joined #amaranth-lang
<vipqualitypost[m>
i thought gtkwave was just a viewer... what can you do with it headless?
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 246 seconds]
<mcc111[m]>
<vipqualitypost[m> "i thought gtkwave was just a..." <- What I mean I was intending to use the X11 protocol to run it on a headless machine (while viewing the GUI on a headful machine)
GenTooMan has joined #amaranth-lang
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
<mcc111[m]>
So would it be correct to say gtkwave doesn't simulate verilog, rather, the amaranth simulator simulates amaranth and gtkwave views the output of the amaranth simulator?
vegard_e[m] has joined #amaranth-lang
<vegard_e[m]>
correct
<vipqualitypost[m>
yes
adamgreig[m] has joined #amaranth-lang
<adamgreig[m]>
you could just copy the .vcd trace file from the machine running amaranth onto the machine that can run gtkwave, I guess
<whitequark[cis]>
mcc111: rkx7 uses a Kintex-7 chip that is supported by Amaranth, though you *will* need to deal with Xilinx's toolchain for it, Vivado
<whitequark[cis]>
I can't imagine how you would apply a spectrum analyzer here, and a soldering iron isn't something that would help you much
<whitequark[cis]>
generally, bringup of such devices involves a lot of staring at UART, and getting an internal logic analyzer working on the FPGA
<whitequark[cis]>
which is really just a buffer you can read out over UART and then stuff into gtkwave
<mcc111[m]>
adamgreig[m]: (It's not a problem, I just hit the kvm switch)
<mcc111[m]>
whitequark[cis]: Okay. And the UART can be USB these days I assume
<whitequark[cis]>
in theory yes, in practice I recommend going with just a normal UART on the target device
<mcc111[m]>
whitequark[cis]: Does that cost money$?
<whitequark[cis]>
whitequark[cis]: yes, you could use LUNA, but LUNA is kind of ... borderline abandonware
<mcc111[m]>
whitequark[cis]: Sorry I mean, will I need hardware other than a USB port on the *viewing* side to monitor the UART
<whitequark[cis]>
mcc111[m]: I think the Kintex-7 chip on it might be included in WebPACK (free version)? but also see DM
<mcc111[m]>
Thanks. I probably will not get this laptop I'm just curious
<whitequark[cis]>
mcc111[m]: you can have a USB-UART adapter
<whitequark[cis]>
they're like $2 on Amazon
<mcc111[m]>
👍
<mcc111[m]>
One more question, this is the dev board I have https://github.com/dadamachines/doppler/ I am a little confused about the difference between FPGA chips and "boards". Would you imagine Amaranth would need to support this dev board specifically, or is it just "well amaranth supports ICE40UP5K so it will support this"
<whitequark[cis]>
you will need to write a "platform class" for this board. you can look at how it's done in the amaranth-boards repository
<mcc111[m]>
ok, i will do my best
<whitequark[cis]>
the platform class just says which resource (like a LED or a button or a clock generator) is connected to which pin
<mcc111[m]>
ah
<mcc111[m]>
that i can do
<whitequark[cis]>
and which FPGA it is, etc
<whitequark[cis]>
by the way, the ice40 "ultra plus" series is the second slowest FPGA on the planet
<mcc111[m]>
I might try to look into getting a different board. This thing has been abandonware more or less since the day it was released and I think 100 or fewer exist (in the world)
<whitequark[cis]>
(the slowest one is called "quick logic")
<mcc111[m]>
whitequark[cis]: that makes sense
sszilvasi[m] has joined #amaranth-lang
<sszilvasi[m]>
Could you elaborate on LUNA being abandonware?
<whitequark[cis]>
the primary developer has quit
<whitequark[cis]>
I don't think anyone's doing the kind of major maintenance and refactoring that LUNA already needs / will need even more after streams land
<sszilvasi[m]>
I wonder where that leaves Cynthion.
<whitequark[cis]>
maybe GSG will hire someone to work on it?
<whitequark[cis]>
it's mostly just that the pool of people who have the relevant knowledge and skill is very small and I probably know most of them already >_>
<whitequark[cis]>
I've also seen @VioletEternity (who did some LUNA work to make it actually work reliably on USB3 with ECP5 transceivers, instead of breaking 10ms after being enumerated) use the USB 2 based UART debug port in LUNA
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
vegard_e[m] has quit [Quit: Bridge terminating on SIGTERM]
mcc111[m] has quit [Quit: Bridge terminating on SIGTERM]
OwenAnderson[m] has quit [Quit: Bridge terminating on SIGTERM]
charlottia has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
vipqualitypost[m has quit [Quit: Bridge terminating on SIGTERM]
sszilvasi[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has joined #amaranth-lang
<whitequark[cis]>
and it did not inspire a lot of confidence
_catircservices has joined #amaranth-lang
galibert[m] has joined #amaranth-lang
<galibert[m]>
What’s Luna actually?
<whitequark[cis]>
USB 2 and 3 stack in Amaranth
<galibert[m]>
Interesting, using what, bare phy?
<whitequark[cis]>
depending on how things go, ChipFlow might contribute a significant effort to LUNA development, but this isn't a given
<whitequark[cis]>
galibert: ULPI for USB2, transceivers or the TI USB3 PHY for USB3
<galibert[m]>
Yeah, not something I have access to on the two fpga boards I have handy
<galibert[m]>
It’s a little sad but I can’t do hardware design worth shit :-)
<whitequark[cis]>
get an OrangeCrab for example?
<whitequark[cis]>
that said, unless you're really good with gateware, I cannot recommend using LUNA. I'm not recommending against it either, it's just that it is a very challenging task and LUNA is basically a proof of concept that was shipped as a production library
<galibert[m]>
I want to become really good with Gateware because I like the stuff
<whitequark[cis]>
specifically the reason I suggested mcc111 use a hardware UART on the sender side is because with LUNA it's easy to end up having to debug timing issues caused by inserting a fairly big USB odule into your design
<whitequark[cis]>
s/odule/module/
<whitequark[cis]>
it wouldn't be much of a problem on something like a Virtex or even a Kintex
<whitequark[cis]>
but on an ice40 this can by itself make your design not function
<whitequark[cis]>
if you're an experienced designer you might decide to just deal with that, add the necessary pipelining stages for example, etc
<whitequark[cis]>
but if you're just getting started this is a good way to quit in frustration
<galibert[m]>
I see
sszilvasi[m] has joined #amaranth-lang
<sszilvasi[m]>
Can you quantify how slow is the iCE40UP?
<whitequark[cis]>
the fastest you could run picorv32 on it is something like 20 MHZ
<whitequark[cis]>
for Glasgow, which started out with iCE40UP, we had to lower the FX2 bus frequency from 48M to 30M because timing closure at 48M for applets was infeasible
<sszilvasi[m]>
Is the ECP5 any better?
<whitequark[cis]>
even iCE40HX series is better
<whitequark[cis]>
with HX, you could run picorv32 at 50-60 MHz, which is good enough for many common applications
<whitequark[cis]>
ECP5 is significantly faster than that
<whitequark[cis]>
it's specifically the iCE40 Ultra and UltraPlus series that are incredibly slow
<whitequark[cis]>
(the Ultra refers to ultra-low power consumption)
nak has joined #amaranth-lang
cr1901 has quit [Quit: Leaving]
cr1901 has joined #amaranth-lang
zyp[m] has joined #amaranth-lang
<zyp[m]>
FWIW I'm actively using LUNA, and it's working well enough for me
<zyp[m]>
not to say I haven't spent hours tracking down and fixing issues with it though
mcc111[m] has joined #amaranth-lang
<mcc111[m]>
So the semi-discontinued ICE40 I have… you can't program the fpga directory, rather there's an attached CPU and you need to upload a small program to it that feeds the FPGA its file.
<mcc111[m]>
In your opinion, how clownshoes is this? specifically what I'm :/ at is the delay(50) after the sendSPI16().
<cr1901>
Which board is this again? Having a microcontroller that feeds the FPGA its bitstream isn't all that strange/clownshoes to me.
<mcc111[m]>
That part does not seem exceptionally weird to me, I'm just curious if anyone more familiar with modern firmware than me knows whether the manual delay is an "unusual" way to engage with SPI in the modern era
<cr1901>
I would figure that the onboard Atmel CPU can somehow be polled whether it's still busy writing a particular SPI chunk to the FPGA, rather than hardcoding a delay. But for a one-off/your own personal upload code, I'm not gonna judge you for hardcoding delays
<zyp[m]>
the stuff in loop()is runtime demo code for some particular bitstream, the upload happens in setup()
<zyp[m]>
it just sends an incrementing integer every 50ms or whatever the unit is
<cr1901>
Oh. Well, my comment about hardcoding still applies. Maybe for a demo bitstream, they didn't want to add a way to poll over SPI whether the device was ready for new data
<cr1901>
s/the device/the FPGA/
<zyp[m]>
if you need to send something at a rough period, that's a simple and not entirely awful way to do it, but it doesn't account for the time spent in the rest of the loop outside the delay function, so it's not perfectly accurate and the actual period will end up being longer
<zyp[m]>
in this case the exact period probably doesn't matter, which makes this entirely fine
vipqualitypost[m has joined #amaranth-lang
<vipqualitypost[m>
that doppler board is cool. wonder if it inspired the led array on the new arduino r4
<mcc111[m]>
<cr1901> "Oh. Well, my comment about..." <- That makes sense
<mcc111[m]>
<vipqualitypost[m> "that doppler board is cool..." <- Operating the LED array *was* kinda fun to have as an option. My main problem with it is that certain arduino API features (specifically analog control of the PWM outputs) never worked.
nak has quit [Ping timeout: 240 seconds]
attiegrande[m] has joined #amaranth-lang
<attiegrande[m]>
whitequark (@_discord_182174208896401419:catircservices.org) - you appear to be missing from #glasgow ... are you here / is the bridge ok?