redstarcomrade has quit [Read error: Connection reset by peer]
FFY00_ has joined #glasgow
FFY00 has quit [Ping timeout: 255 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
joshua_ has quit [Ping timeout: 240 seconds]
joshua_ has joined #glasgow
pg12 has quit [Remote host closed the connection]
pg12 has joined #glasgow
<cyrozap>
Has anyone created an applet specifically for sniffing SPI transactions? Or even just a "state-mode" logic analyzer? I'm looking for something where I can connect the four SPI signals to the SPI flash (or whatever SPI peripheral) while it's in-circuit and glasgow will record the state of those signals on every tick of the SPI clock.
<cyrozap>
I was planning on writing this myself, but if one already exists it would save me a lot of effort.
<cyrozap>
My use case is monitoring SPI flash reads/writes of devices that boot from SPI flash, but where the SPI clock being used is faster than one quarter of my logic analyzer's max frequency.
<cyrozap>
My thinking is, I shouldn't need to do 4x oversampling if the sampling is synchronous to the SPI clock, but the cheap logic analyzers I normally use (FX2-based) don't support synchronizing to an external clock signal.
<whitequark[cis]>
glasgow doesn't fully support it either
<whitequark[cis]>
mostly because async applets are still broken due to an amaranth bug
<whitequark[cis]>
and, what is worse, there is so little memory on the fpga you will struggle at high clock rates anyways
<omnitechnomancer>
what clock speed is the SPI running at?
<theorbtwo[m]>
It's an interesting one... Especially the link at the end.
<whitequark[cis]>
the template nearly everyone uses has an energy of a corporation trying to sound personable, which i don't really like
<whitequark[cis]>
s/an/the/
<whitequark[cis]>
and i don't feel like it reflects my values or approach to life, either
<whitequark[cis]>
o
<whitequark[cis]>
* i've seen it be used as a cudgel to silence any objection to, for example, the military-industrial complex participating in your project
K900 has joined #glasgow
<K900>
I like it
<theorbtwo[m]>
I rather like your CoC.
<K900>
It feels very honest
<whitequark[cis]>
and i think it's a lot more honest to say what you stand for, and what you will do, rather than hide behind values you don't really profess, except for show
<K900>
Wish more projects had codes of conduct like that
<K900>
(/me stares at you know where)
<whitequark[cis]>
perhaps they will. someone already told me they will take inspiration for the next one they write
<K900>
Here's hoping
<theorbtwo[m]>
Unrelatedly, there's a lot of good documentation slightly buried in the code that I wish was nicely visible on the web site. Some of that can be more exposed by linking to the place that I assume exists where python package documentation is visible on the web...
<whitequark[cis]>
it's not
<whitequark[cis]>
it's just in the code
<whitequark[cis]>
making documentation publishable is a lot of work on top of just writing it
<whitequark[cis]>
because there's a lot of context within that code that is lost on someone reading an html
<whitequark[cis]>
i also just didn't have the skills to write good docs until fairly recently
<whitequark[cis]>
my current level of skill is well reflected in the amaranth docs
<theorbtwo[m]>
Hm. Half of me says that I'd like to try. The other half says that I do not have the Python experience to make something reasonable.
<whitequark[cis]>
given how little review bandwidth we have right now (almost none), I'd recommend doing something else for the time being
<whitequark[cis]>
I'll need to find a way to reconcile leadership of Glasgow with my full time job and/or transfer knowledge to someone else who can perform at least parts of my role, eventually, or we'll be stuck in an unfortunate way
<whitequark[cis]>
unfortunately this is difficult
<theorbtwo[m]>
A fair bit feels like it just needs reformatting and moving about. The giant comment at the top of the floppy code can be moved en masse to a separate .md file.
<whitequark[cis]>
actually, I rather like that each applet is relatively speaking self-contained
<whitequark[cis]>
we used to have the testcases in the same file as the main applet code, but had to reconsider that because of fixtures and also how unittest works
<whitequark[cis]>
the original idea was that the single applet file could contain everything, sort of like how each windows .exe can be run entirely on its own (from a certain era and school of programming, anyway)
<whitequark[cis]>
so if you, say, are interested in floppy drives, you sit down and read the entire thing top to bottom, and at the end you have the knowledge of both the conceptual background and the implementation
<whitequark[cis]>
this is heterodox to how most code is written today, i think
<whitequark[cis]>
it also assumes a reader who is very motivated and has a broad background in first place
galibert[m] has joined #glasgow
<galibert[m]>
Not necessarily, some classes coming with documentation and unittests sound similar
<theorbtwo[m]>
It is, and I like that. I would prefer it stay *written* like that, but have a lot more choice in how it is *read*.
<jn>
i'm still interested in glasgow review sessions, but not confident enough in my skill or planning to request them unprompted
<whitequark[cis]>
last time i looked, the entire typechecker of tsc was one 10kloc file
<galibert[m]>
There’s a tendency to make classes kinda too small for that to make sense though
<whitequark[cis]>
theorbtwo[m]: oh yeah. so if it was converted to a docstring, it could be embedded in the web docs
<whitequark[cis]>
I just don't think I can commit to coming up with guidelines for doing that to applets, and I don't want this to be done on an ad-hoc basis
<whitequark[cis]>
in the end, I suspect that we're on a trajectory to have a situation in Glasgow similar to that in Amaranth: for a few years not much will happen after which we'll suddenly get a trove of high-quality browsable docs
<theorbtwo[m]>
I think it'd be a good place to start with having a page that lists the taxons and short descriptions of the applets on one page.
<whitequark[cis]>
that would definitely be nice
<whitequark[cis]>
there's sphinx-argparse, but iirc it produces suboptimal output
<whitequark[cis]>
I think it should definitely be automated, perhaps with (sigh) a custom Sphinx plugin
<whitequark[cis]>
one major thing that's blocking stuff is that the current way in which applets expose their configuration is ... not great
<whitequark[cis]>
it's imperative and argparse-dependent, and the interface is just not very convenient in first place
<whitequark[cis]>
so I'd loathe to build complex infra on top of it that'd have to be torn down shortly after
<cyrozap>
omnitechnomancer: One of the targets is 40 MHz, but I'd like to be able to go higher if needed.
<whitequark[cis]>
40 MHz is only going to be viable either in short bursts, or with the HyperRAM addon
<theorbtwo[m]>
Have to go now, will think on this further, and probably read a load of sphynx[-argparse] docs.
<whitequark[cis]>
cyrozap: you have something like 16K of BRAM, so if a burst exceeds that, and the USB decides to spike in latency, you're going to have a hole in your capture
<whitequark[cis]>
40 MHz of SPI is only about 5 MB/s of traffic, where we have like 40 available, so it's not as bad as say video, but it's still an appreciable volume of data
<jn>
cyrozap: a bit off-topic, but i'm going to build a SPI flash tracer based on rp2040 this year
<cyrozap>
whitequark[cis]: The USB latency shouldn't be too high, I think--the computer I'm using has a root port I can dedicate to the glasgow if needed.
<whitequark[cis]>
cyrozap: `glasgow run benchmark latency` should give you some idea
<whitequark[cis]>
the worst metric is the one that will be limiting
<cyrozap>
oof, worst I saw was 26 ms, even on the dedicated port, and the best of the worst was only 16 ms. mean and stddev seemed decent, though (mean: 203.52 µs stddev: 281.41 µs worst: 25609.64 µs), so I guess I might as well try it and see if it works.
<whitequark[cis]>
yes, this is about what I'd expect
<whitequark[cis]>
these latency spikes are really prone of ruining your day if you want an LA
<whitequark[cis]>
this is why the hyperram board is so valuable
<whitequark[cis]>
at least 16 bits per cycle is a ton of bandwidth
<cyrozap>
jn: Thanks, please let me know once you've released the code. I have a bunch of those boards, so that would be really useful to me. I've found flash access tracing to be an invaluable tool for reverse engineering firmware image layouts.
<jn>
cyrozap: will do!
<whitequark[cis]>
I definitely do want SPI/eSPI/LPC tracers
<whitequark[cis]>
actually, writing an LPC tracer was one of the motivations for building Amaranth itself
<whitequark[cis]>
because Migen was unfit for that goal (no async domains)
<whitequark[cis]>
* (no async reset clock domains)
redstarcomrade has joined #glasgow
<cyrozap>
I can drop down to Verilog for the async parts, if need be. I did something like that for the event counter in my "glitchcore" (very basic voltage glitching tool based on an iCEstick): https://github.com/cyrozap/glitchcore
<whitequark[cis]>
Amaranth does have async reset clock domains
<whitequark[cis]>
but that's only a part of the story
redstarcomrade has quit [Read error: Connection reset by peer]
<cyrozap>
btw, not sure if I've missed something, but I can't find in the docs the device pinout or an explanation of the connector labels on the case. I assume "G" is ground, "V" is power, but what's "S"? "voltage Sense"? And can I assume the two dots on each connector label are NC?
<whitequark[cis]>
S is sense, yes. dots are NC on all current revisions and most likely will remain NC
<whitequark[cis]>
interestingly, S should be OK up to like 40 volts
<gruetzkopf>
iirc that's also described on the post-card sized cheat-sheet?
<whitequark[cis]>
neither seems like a particularly easy fix
<whitequark[cis]>
and that's not something where you can drop down to verilog easily, either
chmod750[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #glasgow
notgull has quit [Ping timeout: 260 seconds]
esden[m] has quit [Quit: Idle timeout reached: 172800s]
<cyrozap>
gruetzkopf: Oh, interesting, I saw the card in the box but hadn't really looked at it. Is the source image online somewhere?
<cyrozap>
whitequark[cis]: I wouldn't be making the whole thing async, just part of it. i.e., if I were to perform the synchronization/CDC in Verilog, would that work? Or am I missing something?
<whitequark[cis]>
you need an async FIFO that handles (async) reset
<whitequark[cis]>
you can't actually bring it using Verilog because Glasgow only supports Amaranth
joshua_ has quit [Ping timeout: 246 seconds]
Guest93 has joined #glasgow
joshua_ has joined #glasgow
Guest93 has quit [Quit: Client closed]
<whitequark[cis]>
current status: getting high on progesterone and implementing RGMII as an applet
<whitequark[cis]>
incidentally this involves two async FIFOs
<whitequark[cis]>
(why RGMII and not RMII, despite ice40 really not being likely to pull off gigabit in a meaningful way? RMII has some stupid quirks around multiplexing--you can't put TX and RX back to back to form a repeater--meanwhile RGMII has no such issue)
<whitequark[cis]>
(although 1GBASE-T's 125M clock rate is not completely out of question, you're just going to get a Lot of retransmits at high load)
<gruetzkopf>
lol
<whitequark[cis]>
to which
<gruetzkopf>
common complaint about RMII.
<whitequark[cis]>
even wiki lists it!
<cyrozap>
whitequark[cis]: Can't I use `Instance()` and do a `platform.add_file("whatever.v")` to add the Verilog file to the build? Or did you mean "supports" as in "it'll technically work, but you're on your own if it breaks"?
<cyrozap>
*"only supports Amaranth" as in "Verilog will technically work..."
<whitequark[cis]>
you can definitely try but i think it'll just fail with a build failure due to what Glasgow does with the Amaranth build code
<whitequark[cis]>
it's not impossible to support for sure, I just never felt the motivation
<whitequark[cis]>
I also feel that fixing AsyncFIFO has a higher benefit/cost ratio
<gruetzkopf>
arp request from 192.168.0.214 to 1.2.3.4
<gruetzkopf>
(i have stared at hexdumped ethernet frames FAR too much)
<whitequark[cis]>
checks out ty
<whitequark[cis]>
currently working on dumping it to something different
<whitequark[cis]>
i picked rfc1761
<whitequark[cis]>
for no particular reason
<whitequark[cis]>
i was like "ok, can wireshark load a bin dump?" and the answer is apparently "no, but it can load at least 20 completely obsolete formats no one has ever heard of"
<gruetzkopf>
hey, i've *used* snoop!
<whitequark[cis]>
is it any good
<gruetzkopf>
it's what the sparcstation had? my path was also "import into wireshark"
<omnitechnomancer>
you can import hexdumps, but without some information about framing it will only load it as one big packet
<whitequark[cis]>
it can cut them at the codewords!
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<omnitechnomancer>
what codewords
<whitequark[cis]>
data + crc
<whitequark[cis]>
which is how the ethernet mac knows the packet is done
<whitequark[cis]>
usually
<whitequark[cis]>
i think
<vegard_e[m]>
AIUI the MAC knows that the packet is done when the PHY deasserts rx valid
<omnitechnomancer>
I'm pretty sure the mac tells the packet is done by the RX_CTL signal
<omnitechnomancer>
yea
<vegard_e[m]>
how the PHY knows whether the packet is done depends on the physical layer, varies from loss of carrier to an explicit EOP token
<omnitechnomancer>
Yea the specific media modes have some way of indicating framing
<omnitechnomancer>
either way you need to provide framing
<omnitechnomancer>
If it were done by trying to look for valid CRCs what happens if some data in the middle of the packet is a valid CRC for all the data in the packet up to that point?
<vegard_e[m]>
yeah, a decoder that didn't care about rx valid could be fooled by following a fake crc with a preamble/SOP to spoof another packet
<omnitechnomancer>
Well the PHY<->MAC interface doesn't get the preamble/SOP AFAIK?
<vegard_e[m]>
FWIW a google search suggests in 8b10b GbE, EOP is signalled as a K29.7
<vegard_e[m]>
IIRC it does
<omnitechnomancer>
Ah it does get the start of frame delimiter
<vegard_e[m]>
I'd guess it's MII-specific whether the preamble is included
<omnitechnomancer>
Apparently some of the preamble is allowed to be lost, so you may not get all of it for all packets
<vegard_e[m]>
yeah
<vegard_e[m]>
«The KSZ9031RNX removes all 7 bytes of the preamble and presents the received frame starting with the SFD (start of
<vegard_e[m]>
frame delimiter) to the MAC.»
<vegard_e[m]>
so I guess preamble is optional, SFD mandatory
<whitequark[cis]>
yeah, should be rx_ctl
<whitequark[cis]>
this is the first time i implement a MAC, and it shows :)
jstein has quit [Ping timeout: 256 seconds]
<vegard_e[m]>
the MAC should ideally not care about which MII is used (and hence the exact semantics of rx_ctl), it should take a standard packetized stream towards a MII interface that takes care of those details
<omnitechnomancer>
I think most things also want to have to transport as little as possible so discard everything that isn't necessary as soon as possible
<vegard_e[m]>
absolutely
<omnitechnomancer>
often including the fcs
notgull has joined #glasgow
<vegard_e[m]>
meanwhile I've made one of the exceptions to that, I've got an ethercat-like thing that rewrites frames and passes them on, so in my case it'd be beneficial to retain everything from the original frame and just rewrite what I need to
<vegard_e[m]>
it's currently built on top of a standard liteeth MAC, so it spends extra effort extracting the ethernet headers, passing them separately and then adding them back
violetblob[m] has quit [Quit: Idle timeout reached: 172800s]
oakwhiz[m] has quit [Quit: Idle timeout reached: 172800s]