MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #glasgow
mjmdavis[m] has quit [Quit: Idle timeout reached: 172800s]
duskwuff[m] has quit [Quit: Idle timeout reached: 172800s]
meklort has quit [Ping timeout: 248 seconds]
meklort has joined #glasgow
trh has quit [Quit: weg]
trh has joined #glasgow
Tom has quit [Remote host closed the connection]
redstarcomrade1 has quit [Read error: Connection reset by peer]
mwk has quit [Ping timeout: 252 seconds]
mwk has joined #glasgow
jstein has joined #glasgow
jstein has quit [Ping timeout: 244 seconds]
jstein has joined #glasgow
Tom has joined #glasgow
mjmdavis[m] has joined #glasgow
<mjmdavis[m]>
esden: I was able to rework the vregs and the thing passes POST
<mjmdavis[m]>
Thanks for the pointer
esden[m] has joined #glasgow
<esden[m]>
Ohh! Ok! Glad to hear that! 🙂 I hope it serves you well!
<mjmdavis[m]>
I say "I", but it was one of the techs at work.
<mjmdavis[m]>
Is there an easy way to get the logic analyzer demo running with a client?
<opticron>
I successfully got the glasgow analyzer applet to read a can bus! (which with some manual debouncing decoded properly in pulseview and told me my timing values were wrong)
<mjmdavis[m]>
how did you read it?
<mjmdavis[m]>
GTKWave?
<whitequark[cis]>
nice
jstein has quit [Ping timeout: 252 seconds]
<opticron>
mjmdavis[m], by stuffing the low side directly into the glasgow and setting the read voltage as 3.3V since this particular transceiver was idling at 2.3V and I biased the midpoint closer to 1.3V since can is driven strongly away from idle
<opticron>
no transceiver necessary :D
<opticron>
and pulseview for reading/decoding
<opticron>
though I need to try gtkwave since pulseview has some issues
<mjmdavis[m]>
pulseview is very slow to read these files!
<opticron>
yes....I noticed
<opticron>
and if there's too much in the file it will eat memory until the system thrashes and dies
<opticron>
--pins-i argument is a comma-separated list
<opticron>
so you'd want 0,1, not 01
<mjmdavis[m]>
any tips for avoiding FIFO overrun?
<opticron>
*"0,1", not 01
<opticron>
none, I didn't need to capture that much data
<opticron>
I was essentially just letting the FIFO overrun kill the capture
<mjmdavis[m]>
it only seems to run for a few secs before dying
<opticron>
yeah...I think this is a known issue
<mjmdavis[m]>
I guess there's no "STOP" command
<opticron>
you just ctrl+c the capture to end it
wiebel[m] has joined #glasgow
<wiebel[m]>
There is a safe however.
<whitequark[cis]>
opticron: yrp
<whitequark[cis]>
* yep
<mjmdavis[m]>
been doing that, ok cool
<mjmdavis[m]>
Any insights as to the buffer overflow thing? Is it a libusb buffer not being emptied?
<opticron>
iirc, the suggestion last time this was brought up is that the glasgow really needs high speed buffer of some kind for this type of use case (and others), the suggestion being a hyperram module
<opticron>
if the ram-pak does end up getting made, I'm interested in having one
<whitequark[cis]>
yes
<whitequark[cis]>
we also need gateware for it, which i started prototyping but never quite pushed it to completion
<mjmdavis[m]>
that would be cool
<mjmdavis[m]>
lots for me to learn here but is USB isochronous not good enough for transferring 24MHz to the host?
<mjmdavis[m]>
The old Logic / all the clones did that with just the FX2
<mjmdavis[m]>
although I guess the main use case here is not LA but active logic for TRX etc...
<Wanda[cis]>
there's a single-digit (or low double-digit) number of prototypes of them already in circulation; the hardware is basically verified, we just need to write a bunch of code and integrate it into the glasgow framework
<Wanda[cis]>
mjmdavis[m]: USB isochronous is not something you want to use
<Wanda[cis]>
but also: the problem with the whole thing is not bandwidth, but rather small buffer sizes available on the glasgow + FX2, which coupled with how USB works easily results in overruns
<Wanda[cis]>
hence hyperram for extra buffering
<Wanda[cis]>
s/glasgow/ice40/
<mjmdavis[m]>
right, but the cheap logic analyzers manage
<mjmdavis[m]>
maybe because they just have to read and dump for PortA on the FX2?
<mjmdavis[m]>
The ram module makes a ton of sense though!
<whitequark[cis]>
mjmdavis[m]: they dont
<whitequark[cis]>
100 MHz @ 2ch basically never works in practice even on Linux
<mjmdavis[m]>
they cap out at 24MHz I think
<whitequark[cis]>
and if you cut the bandwidth to resemble what works with the cheap LAs you will find that it works with glasgow too
<whitequark[cis]>
oh, right, the FPGA less ones
<whitequark[cis]>
they sample with the FX2 directly
<mjmdavis[m]>
the original logic
<mjmdavis[m]>
lol
<whitequark[cis]>
you could try to make an applet that submits a single byte every other cycle
<whitequark[cis]>
that will probably give you pretty good results
<whitequark[cis]>
the current applet is being overly clever for uninteresting historical reasons
<mjmdavis[m]>
There's a ton of cool stuff you could do with the FPGA to get really high sample rates for sure.
<mjmdavis[m]>
How do people feel about webusb?
<whitequark[cis]>
the current applet tries to do delta compression which works for very sparse signals but fails for many "normal" ones in a way that simply streaming full bytes would not
<whitequark[cis]>
mjmdavis[m]: i ported openfpgaloader to websusb
<whitequark[cis]>
* i ported openfpgaloader to webusb
<whitequark[cis]>
also the entire foss fpga toolchain to wasm
<mjmdavis[m]>
Is there a build of the firmware with webusb descriptors?
<whitequark[cis]>
i dont believe any extant software reads those
<whitequark[cis]>
chromium hasnt cared in a very long time and firefox never had webusb i think
<mjmdavis[m]>
I believe Chrome does?
<mjmdavis[m]>
It would be very nice to be able to run the appelets in a browser with a UI.
<whitequark[cis]>
it does not
<whitequark[cis]>
and yes, glasgow-on-web has been the goal for a long time
<whitequark[cis]>
i do have a build of libusb for web but i do not have a port of python-libusb1
<whitequark[cis]>
if you could get that made and contributed it to pyodide repos that would be much appreciated
<mjmdavis[m]>
FWIW I got the glasgow analyzer to capture a trace, imported to Sigrok, exported a subset (only way to cut?) and then imported it again to get the SPI decoder to work and I was able to read bytes. So that does work. YAY
<mjmdavis[m]>
although the saleae experience is much nicer :P
<mjmdavis[m]>
I've been doing a lot of instrument control stuff in the web but it's mostly python async client to webserver to Svelte webapp
<mjmdavis[m]>
Might another way be to simply download existing bitstreams from a repo, push them in over webusb, and then read the output?
<whitequark[cis]>
no
<mjmdavis[m]>
I guess a lot of the params are compiled into the bitstream?
<whitequark[cis]>
basically all of thrm
<mjmdavis[m]>
ah
<whitequark[cis]>
s/thrm/them/
<whitequark[cis]>
we fundamentally treat bitstreams as disposable
<whitequark[cis]>
but also, the entire toolchain has already been ported
<mjmdavis[m]>
right
<whitequark[cis]>
porting that part to web will take maybe a day of work for me, to add some shims for pyodide
<whitequark[cis]>
the problems are (in increasing order) libusb1 and an UI
<mjmdavis[m]>
more comfortable with UI than libusb but I can give libusb a go for sure
<whitequark[cis]>
libusb1 is already ported to esm, you only need to make it play nice with pyodide
<whitequark[cis]>
UI... i really dont like the modern web stack
<whitequark[cis]>
its not as bad as it used to be since at least you dont need babel anymore, but people still go wild with SPA frameworks in ways im really not happy abouy
<whitequark[cis]>
s/abouy/about/
<whitequark[cis]>
its also not clear what kind of ui do we even wany
<whitequark[cis]>
s/wany/want/
<whitequark[cis]>
if it aims to expose a non command line version that will be stalled on a refactoring of the core that makes programmatic inspection of applets not be awful
<mjmdavis[m]>
I have become a fan of Svelte with JSDoc. However I understand the concerns around the web stack.
<whitequark[cis]>
a command line version is a very easy sell thougg
<whitequark[cis]>
s/thougg/though/
<whitequark[cis]>
that or code only
<whitequark[cis]>
like, if the proposal is to ship yowasp+pyodide+libusb+glasgow and monaco/xterm.js with esbuild im on board already
<whitequark[cis]>
if it is more invasive i am much less on board
<whitequark[cis]>
* with esbuild, im
<whitequark[cis]>
i specifically do not want it to have any kind of backend
<whitequark[cis]>
directory full of static files is perfect
<mjmdavis[m]>
that's easy to achieve
<whitequark[cis]>
yes
<whitequark[cis]>
yowasp is packaged as a bunch of very nice esbuild compatible typescript packages already
<whitequark[cis]>
you can even run it from the devtools with a oneliner
<whitequark[cis]>
the glasgow toolchain module will need another option that detects pyodide and picks yowasp as a (only) valid toolchain
<whitequark[cis]>
we dont have any C extensions in python deps besides libusb and some aiohttp stuff that i swear should just not use an extension in first place
<whitequark[cis]>
the aiohttp stuff is optional anyway
<whitequark[cis]>
after this you should be able to run the glasgow main in the browser
<whitequark[cis]>
xterm.js will do fine for invoking it but a valid question to ask is "how do i get files to/from the applet?"
<whitequark[cis]>
since its chrome only then the filesystem api might work
<whitequark[cis]>
at the moment (until the applet ui situation is less of a mess) i dont want something like HTML UI even if its optional
<whitequark[cis]>
but we could discuss the needed redesign
<mjmdavis[m]>
We use pydantic models for parameters for commands and then generate UI based on json schema generated from the pydantic model.
<whitequark[cis]>
this is one option to evaluate
<whitequark[cis]>
i dont super liked pydantic the last time i looked at it but i havent made any specific decisions yet
<whitequark[cis]>
s/dont/didnt/, s/liked/like/
<whitequark[cis]>
mostly i feel like its solving a related but different problem
<mjmdavis[m]>
well, it's kind of doing the typing stuff as well as the serialisation to json and typing in js
<mjmdavis[m]>
an you can be very specific
<whitequark[cis]>
well yes but what i want is some sort of abstract description of like, pins and Amaranth streams and stuff
<whitequark[cis]>
upstream libusb includes webusb code
<whitequark[cis]>
you can look at yowasp/openfpgaloader-web repo for an example
<mjmdavis[m]>
so it's just the pyodide libusb1 thing?
<mjmdavis[m]>
trying to grasp the problem statement
<whitequark[cis]>
pyodide has a list of packages they build yourself because they feature C extensions and you cant upload binary wheels for the web on pypu
<whitequark[cis]>
s/pypu/pypi/
<whitequark[cis]>
they build these packages using conda, which is upsetting but nothing you can do about it
<whitequark[cis]>
you understand why i didnt want to do it myself, yes?
<whitequark[cis]>
would be already done otherwise
<whitequark[cis]>
anyway, there is some way to build a C extension that includes inline JS snippets, like libusb1 does, and package it for pyodide, in their build system
<whitequark[cis]>
i would like you to do this (write a build script integrating existing python-libusb1 and libusb1 sources, most likely unmodified or almost unmodified) and submit it to the pyodide folks
<mjmdavis[m]>
writing it all from scratch in rust sounds more fun
<whitequark[cis]>
that's *sort of* planned but at the moment i do not have the bandwidth to guide or review that project
<whitequark[cis]>
but also i didn't make yowasp because it was fun (it was miserable); i did it because i wanted the users of glasgow to not suffer
<mjmdavis[m]>
How is the performance in wasm compared to python?
<whitequark[cis]>
performance of what?
<mjmdavis[m]>
compiling?
<mjmdavis[m]>
or is it called "synthesis"
<whitequark[cis]>
I'm confused
<whitequark[cis]>
we don't do synthesis in Python
<whitequark[cis]>
yosys is a C++ program
<mjmdavis[m]>
my bad
<whitequark[cis]>
prjunnamed, which we'll ideally replace it with some day, is a Rust program
<whitequark[cis]>
anyway, yosys is about as fast as a native application, nextpnr is about half the speed
<whitequark[cis]>
so it's not bad at all
<mjmdavis[m]>
yeah
<whitequark[cis]>
yosys has good performance because it does a lot of pointer chasing and wasm32 pointers are half as big
<mjmdavis[m]>
that's cool
<whitequark[cis]>
so it has great cache locality (i think)
<whitequark[cis]>
its completely usable to the point i use yowasp-yosys as my primary yosys
<whitequark[cis]>
* primary yosys binary
<mjmdavis[m]>
so the whole compile in browser thing is pretty realistic
<mjmdavis[m]>
and you can do it in a webworker probably
<whitequark[cis]>
yes, yowasp stuff works both on the main thread and in workerd
<whitequark[cis]>
s/workerd/workers/
galibert[m] has quit [Quit: Idle timeout reached: 172800s]