electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
<d1b2>
<h0m3us3r> @brainstorm i did a bit of digging, and it looks like currently only TNM5000 supports your chip. Unfortunately for you (I assume), that is a $800+ device.
<electronic_eel>
I guess a glasgow addon with one of the ATF15xx cplds would be the perfect solution for a TSOP56 flash
<electronic_eel>
(once Project Bureau is finished)
<whitequark>
yup
<whitequark>
there's a reason i started it :)
<electronic_eel>
I was reading the datasheet of this particular flash, and there seems to be a version with 1.8v io. So for that special version we'd need a different solution
<d1b2>
<h0m3us3r> Any specific reason for chosing atf15?
<whitequark>
h0m3us3r: last true 5V CPLD in active production
<whitequark>
btw
<whitequark>
#prjbureau on freenode
<d1b2>
<h0m3us3r> > @h0m3us3r last true 5V CPLD in active production @whitequark#0000 is that actually significant for the task?
<electronic_eel>
not for this particular model, but there are many other 5v memory ics out there that need wide parallel busses.
<whitequark>
not just memory ICs
<whitequark>
all kinds of stuff really
<whitequark>
ISA for example
<whitequark>
i kinda want to make glasgow drive ISA cards at some point
<whitequark>
the perfect blend of modern and obsolete
<noopwafel>
this would be amazing
<whitequark>
anyone wanna help with it? i have a few low-complexity mid-effort tasks for prjbureau
<whitequark>
like the SVF<>JED mapping for ATF1504/ATF1508
<whitequark>
*help me with it
<whitequark>
ping me on #prjbureau if you do :)
<noopwafel>
I think I learnt previously not to promise things I don't have the time for right now, but this sounds like a good place to idle
<d1b2>
<h0m3us3r> Honestly, I think 1v8 is more important than 5v going forward
<d1b2>
<h0m3us3r> And lattice stuff is 5v tolerant
<whitequark>
glasgow can already do 1v8 just fine though
<whitequark>
well
<whitequark>
there's a few things
<whitequark>
a *lot* of 5v stuff is parallel. it could even be that most of 5v-only stuff is parallel
<whitequark>
compared to this, most of 1v8 stuff is already serial
<whitequark>
there are some outliers, of course
<d1b2>
<h0m3us3r> I mean fast high pin count 1v8
<whitequark>
so i expect that for 1v8, revD will cover the ground revC doesn't
<whitequark>
and revC should cover most ground
<whitequark>
that's the first consideration
<whitequark>
the second consideration is: sure, you don't care about 5v. meanwhile, i don't care nearly as much about the new stuff as the old stuff. there's no shortage of ways to interop with new devices, glasgow being just one of them, and frankly, it's all converging to very few interfaces in ways that make interfacing with it fundamentally unproblematic hardware-wise
<whitequark>
conversely if you want to actually usefully run 5v tech, you... don't have that many options. sure you can hook up a 5v arduino if you can spend a day dumping a 5v flash
<whitequark>
you want to do something as boring and ordinary as dump a floppy on flux level? better pay the kryoflux racket
<whitequark>
this is bullshit
<whitequark>
because this is bullshit i'll make it better
<whitequark>
i'm actually not that big of a fan of retro tech personally, i mean, the whole package. i technically own a retro pc but i don't run it because it's a pain in the butt and isn't fun beyond the nostalgic first few hours
<whitequark>
i do like old *components* though and moreso than that i like helping other people get the most out of them
<electronic_eel>
also if a addon with an ATF15xx is done and working, another addon with different cpld/fpgas, but 1.8v compatibility, could be developed and both could use the same protocol
<whitequark>
indeed
<whitequark>
hell, we can even reverse engineer ispMACH
<whitequark>
i've just started with ATF15xx because it provides the absolute highest value for the RE effort
<d1b2>
<h0m3us3r> Why not a single addon for both tho? That was my question
<whitequark>
because "5V tolerant" doesn't mean it will interoperate with 5V devices
<whitequark>
3.3V is below Vih for many of them
<electronic_eel>
you want push-pull cmos out for full 5v interfacing
<whitequark>
^
<whitequark>
ive actually started REing ispMACH 4A5, iirc
<whitequark>
and then discovered that it won't work for a significant chunk of devices
<d1b2>
<h0m3us3r> Maybe just drop something like LSF0108 in between?
<whitequark>
lol
<whitequark>
bidirectional voltage translators
<whitequark>
a great way to make sure your design never quite works
<whitequark>
*autosensing bidirectional voltage translators
<d1b2>
<h0m3us3r> Its just a mosfet with some pulse shaping tho..
<whitequark>
yeah and it doesn't work
<whitequark>
well, if you have something really slow and open-drain like i2c it might occasionally work
<whitequark>
beyond that it's just an attractive nuisance
<whitequark>
the pulse shaping part is an excellent way to introduce noise in all the places you would hate it to be
<whitequark>
especially if we're talking about old cmos parts with async inputs and no noise rejection
<d1b2>
<h0m3us3r> Idk, ive used their TXS series parts quite successfuly
<d1b2>
<h0m3us3r> Under 20MHz though
<whitequark>
glasgow started out with FXMA108 and it would be easier to enumerate successes with that translator than it would be to enumerate failures
<d1b2>
<h0m3us3r> So I see your point
<tnt>
You can build a glasgow revB if you want a TXS :)
<whitequark>
FXMA is probably the single worst autosensing translator ever made
<whitequark>
the LSF part you linked avoids some of its pitfalls
<whitequark>
but i still don't see it being reliable enough in wide enough variety of conditions for me to be comfortable shipping it in any form
<tnt>
(oh yeah, my bad it was fxma not txs)
<whitequark>
the one kind of autosensing translators i think are reasonable are the ones that use purely a pass FET
<whitequark>
no pulse shaping, nothing weird like that
<whitequark>
but... that's not fast at all
<whitequark>
the moment you are using a device that does something strange with the edges or the levels, you're always one minor design mistake from having it backfire
<whitequark>
speaking in the general sense, of course
<whitequark>
if you don't have the kind of constraints that glasgow has, e.g. if the IOs you are using autosensing shifters on are purely synchronous *and* the clock is routed well away from that using a normal shifter, you might even have an FXMA reliably work
<d1b2>
<h0m3us3r> FXMA looks like ti's TXB series, which does have issues...
<whitequark>
the reason glasgow wouldn't be able to use TXS is because of the Vcca/Vccb restrictions
<whitequark>
either you can't do 5V or you can't do 1.8V
<whitequark>
well, unless the glasgow side is driving everything from 1.8V, which has its own unrelated issues
<whitequark>
oh wait, nevermind, TXS also uses one-shot accelerators
<whitequark>
so it's going to be the same kind of disaster as FXMA
<whitequark>
LSF seems like it doesn't have one-shot accelerators, so it's just limited by Vcca/Vccb restrictions
<whitequark>
and possibly by the way it behaves in presence of pull resistors, i'd have to think about that
<d1b2>
<h0m3us3r> TXS works fine with pulls, I havent tested LSF personally. I dont really know the glassgow requirements (new here, sry), but I did run TXS shifters at 10MHz (clock + data, 2 channels only) over a 3ft typec cable together with usb2 running over the second pair and had zero issues. Not pushing for TXS in any way btw, just sharing my experience with them and trying to understand their limitations as I was trully not aware or most issues you are
<d1b2>
describing.
<whitequark>
so, FXMAs caused truly massive crosstalk issues because effectively both sides of it behave similarly to a high-impedance inputs
<whitequark>
oh, here's something you can try
<whitequark>
grab a TXS or LXF or whatever autosensing level shifter you have, and try to drive a good old HD44780 chargen display with it
<whitequark>
on those displays, the E input is extremely sensitive to glitches and crosstalk, and will cause constant (and quite visible) issues where otherwise you might not notice it unless you run it for a lot of time
<whitequark>
with FXMAs, it was essentially impossible to get the display through the init sequence at all
<whitequark>
interestingly, i could not actually see the glitches with my scope, a 100 MHz rigol; i could only infer their presence by trying to increase or reduce crosstalk
<d1b2>
<h0m3us3r> Alright, sounds like a plan, will do when I have my next day off. Quite interested myself in the result now.
<whitequark>
make sure it's not one of the newer chipsets though
<whitequark>
i think some of those might have more sensible input buffers
<whitequark>
grab the cheapest, crappiest, most ancient display you can find :p
<d1b2>
<h0m3us3r> I think I should have some in my collection
<whitequark>
great
<whitequark>
looking forward to it
<whitequark>
soe
<whitequark>
*so, one thing i could find with the display that wasn't obvious otherwise is uh
<whitequark>
I worked on a NAND flash applet
<whitequark>
(the applet currently in the tree is quite bad, don't use it for anything important)
<whitequark>
and the very same glitches caused a few pages to read as 00s or FFs (depending on the flash) out of a gigabyte or so
<whitequark>
for the same reason, the flash was just less sensitive to it
<whitequark>
i think there were also more bitflips in the page content than is warranted, because when i retried it with revC, not only i haven't got any 00/FF misreads, but the amount of bitflips also went down considerably
<whitequark>
but... the display made the problem really obvious in comparison
<whitequark>
oh, also, make sure you use the 4 bit mode
<whitequark>
because that amplifies the problem even further
<whitequark>
since if it's in 4 bit mode, then *any* glitch on E is going to result in a visible screwup
_whitelogger has joined #glasgow
Foxyloxy has quit [Quit: Leaving]
Foxyloxy has joined #glasgow
_whitelogger has joined #glasgow
<d1b2>
<atx> Has anyone ordered the PCB from JLC? Looks to be right at the edge of their capabilities
m4ssi has joined #glasgow
<noopwafel>
Glasgow revC1, you mean?
<d1b2>
<atx> Yeah
<noopwafel>
I bought a bunch of PCBs+stencil from them, they are fine, I have working boards
<d1b2>
<atx> Ok, nice
<noopwafel>
this was ENIG, though
<d1b2>
<atx> The PCBA they offer is very convenient (and cheap)
<d1b2>
<atx> I am never populating hundreds of passives ever again
<noopwafel>
do they stock the ice40 now?
<Twix>
I also bought mine at jlc. I modified the via size, if i remember correctly.
<d1b2>
<atx> Nope
<d1b2>
<atx> The part selection is very limited
<d1b2>
<atx> Still great for prototyping as they at least have all the capacitors and resistors
<noopwafel>
I'd rather populate the passives than try to do the BGA after without being able to stencil
<d1b2>
<atx> Hm, you wet-solder BGAs?
<d1b2>
<atx> I was honestly unable to find which method is best for hand populating
<d1b2>
<atx> And, I was thinking of having them assemble the back side anyway, as it has most of the passives
<noopwafel>
honestly I found the caps/resistors on glasgow to be extremely quick
<noopwafel>
assuming paste
<noopwafel>
but I can understand not wanting to do them :D
<d1b2>
<atx> I did dry solder some MAX10s few years back, my success rate was around 50%
<d1b2>
<atx> It does go much quicker with a stencil that's true :D
<d1b2>
<atx> But still, annoying and boring
<noopwafel>
I guess their crazy 4-layer deal makes this so cheap now
<d1b2>
<atx> Indeed
<d1b2>
<atx> Depending on how many components you have, its like 20-30$ for 5 PCBs
<d1b2>
<atx> (if you only use the "basic parts", which most resistors/capacitors are)
<d1b2>
<atx> Argh, the only place that stocks the FPGA is Digikey
<d1b2>
<atx> Oh, they do free shipping for orders above 60$ to europe now
<noopwafel>
yeah, I also ended up ordering from digikey for mine (start of the year)
<noopwafel>
I also I think drained the whole supply of the pink LEDs at the time
<noopwafel>
from TME
<d1b2>
<atx> My last PCBA order from JLC came with red LEDs instead of green+yellow+orange for whatever reason
<electronic_eel>
@atx you could also wait like 2 or 3 weeks and then order revC2. it'll have some improvements regarding manufacturability
<electronic_eel>
some parts in revC1 that turned out to be hard to solder (level shifters, tvs diodes) were replaced with parts in easier-to-solder footprints
<d1b2>
<atx> I need to finish my bachelors thesis and study for the final exam, so I should not procrastinate anyway :P
<electronic_eel>
regarding soldering the bga, you could use a hotplate. search for a video by niklas fauth, he showed soldering some glasgows this way a few weeks ago
<noopwafel>
hehe, I should really finish my remaining revC1 boards
<noopwafel>
before revC2 comes out
<d1b2>
<atx> Interesting, unfortunately I do not have a hotplate
<d1b2>
<atx> Only a hot air station
<noopwafel>
but .. those parts are indeed so annoying :p
<d1b2>
<atx> I could get access to an IR oven, but that seems like a bit overkill
<d1b2>
<atx> Last time I tried that, the flux started bubbling and it shifted the whole BGA
<electronic_eel>
the flux from the paste or did you add extra flux?
<d1b2>
<atx> I used no paste, just flux
<electronic_eel>
hmm, maybe not the right kind of flux for this kind of application?
<d1b2>
<atx> Ah interesting, the version Niklas has is with a USB-C connector
<d1b2>
<atx> Which was one of the mods I wanted to make
<electronic_eel>
revC2 will have USB-C too
<d1b2>
<atx> Ooh nice :)
<whitequark>
tbh i still kind of want microUSB revC2
<whitequark>
maybe as an option or something
<whitequark>
not a strong preference
<d1b2>
<emeb> runs to dollar store to stock up on USB-C cables.
<d1b2>
<atx> Micro USB is EVIL
<d1b2>
<the_art_of_giving_up> why do you have a non-negative microUSB preference?
<d1b2>
<the_art_of_giving_up> it's not evil, it's just inconvenient. USB-C is convenient and evil
<d1b2>
<atx> Less evil than mini USB but still evil
<electronic_eel>
@atx you have to look at the kicad files, the pdfs are not yet updated
<whitequark>
atx: like, i know all the rich nerds in the west upgraded *everything* to type-C
<whitequark>
i haven't and i know quite a few people who haven't
<noopwafel>
electronic_eel: is there anything in revC2 which is super useful/critical or is it mostly just ease of manufacture?
<electronic_eel>
noopwafel: revC2 will also have current sensing capability, with programmable hardware overcurrent shutoff
<electronic_eel>
and most probably we'll also add a reset button for fast shutoff / safe mode in case some dut starts smoking
<d1b2>
<the_art_of_giving_up> I'm really excited for Glasgow. Segger on suicide watch
<d1b2>
<atx> electronic_eel: Ah, nice, the new IO buffers are in package they have on JLC
<whitequark>
the_art_of_giving_up: do note that right now glasgow isn't a fast debugger
<whitequark>
single stepping on MIPS EJTAG is something like 1s per step
<esden>
electronic_eel: what was the capacitor footprint type you were proposing?
<whitequark>
ARM JTAG isn't so pathological but it's the same order of magnitude I think
<whitequark>
maybe an OOM faster?
<electronic_eel>
esden: 6.3mm diameter
<d1b2>
<the_art_of_giving_up> well, somehow my stepping with chinese STLink v2 knockoffs with OpenOCD in VSCode already is that bad
<d1b2>
<the_art_of_giving_up> on that note, bump on SWD JTAG
<esden>
whitequark: do we have a consensus where you want the "emergency stop" button connected?
<esden>
I thought at first this was supposed to be connected to a software readable pin somewhere so it can shut down things gracefully.
<d1b2>
<the_art_of_giving_up> similar sluggishness observed in Atollic with a legit STLink v2 as well. SWD running at 2MHz
<electronic_eel>
esden: when we want the same button logic for revD, it'll get tight regarding ios on the fx2
<whitequark>
the_art_of_giving_up: yeah, i know SWD is very much wanted
<whitequark>
my health comes first though
<whitequark>
anyway
<whitequark>
regarding JTAG, it will only be truly fast once some of the JTAG logic runs on the device itself
<whitequark>
it is not yet clear how that will happen
<whitequark>
the capability is there (it's an FPGA after all), but it won't be actually used upstream until i decide what would be a nice maintainable way to do it
<d1b2>
<atx> Current sensing seems nice, could be combined with ETM/ITM to get a code power consumption heatmap like those Gecko devkits have
<whitequark>
esden: besides what electronic_eel highlights, there is another reason to do it *not* in software
<whitequark>
since i want the estop button to be a safety mechanism, i want you to be able to *always* rely on it
<d1b2>
<the_art_of_giving_up> > health oh yeah, for sure. BTW I'm willing to contribute and test features, within the confines of my ability and energy
<whitequark>
which means it should just reset the whole thing, basically equivalent to pulling the cable and re-plugging
<whitequark>
but less violent towards the connector
<whitequark>
the_art_of_giving_up: so the thing is that it's almost always much harder for me to review code than to just implement it from scratch
<whitequark>
this is unfortunate and will impede the community around glasgow in the long run
<whitequark>
but in the short run i'm going to keep doing it until i'm in a better place in my life in general
<esden>
whitequark: ok sounds good. I will do my best to find a spot for the button, and hook it up to the reset circuitry of the device. And when I have it I will put it up for review. :D
<esden>
If that is ok.
<whitequark>
at some point i'll figure out some sort of staging process and make sure there are clear guidelines for acceptable code
<whitequark>
but this is medium to long term
<electronic_eel>
esden: this is how I envision how the reset should be done: a resistor on the vcc for the new reset ic, the button pulls the vcc down a bit (via another resistor), resistor values will have to be calculated yet
<electronic_eel>
esden: this will ensure that we do a full reset cycle, including the 3v3 rail
<esden>
electronic_eel: yeah that is pretty much what I thought too.
<electronic_eel>
esden: I think the button would fit nicely where the fx2 eeprom is now. both eeproms could be shifted up a bit and the new cap a bit left
<d1b2>
<the_art_of_giving_up> yeah, managing others is massive overhead and not worth unless you have faith the person you're putting energy into isn't going to flake on you
<electronic_eel>
esden: I posted a alps button mfg no a few days ago, I think that will work nicely
m4ssi has quit [Remote host closed the connection]
<d1b2>
<the_art_of_giving_up> I think the risk of exporting testing might be lower than the risk of exporting dev
<esden>
electronic_eel: I would use the same button as the one on the icebreaker. They have very nice tact feel and I have a very low cost source for them.
<electronic_eel>
esden: what size is it?
<whitequark>
the_art_of_giving_up: indeed, i very much welcome bug reports
<whitequark>
code is harder... there are a few PRs sitting in the queue that are basically perfect
<whitequark>
i just haven't been able to give them the needed attention
<whitequark>
- glasgow can only load applets from its own source tree, never externally
<whitequark>
- there's no "staging" tree where less-perfect applets could go
<whitequark>
- the way you write a good applet is undocumented and implicit in existing code
<whitequark>
- the existing code is inconsistent and some of it is kind of stuck in the middle of some migration
<whitequark>
- even the bits which are consistent are just kind of bad, e.g. the pin assignment stuff and the CLI in general just sort of suck
<whitequark>
my goal back when i wrote the current framework was to get out a "preview" version we can use and iterate to gather feedback
<whitequark>
in that sense, it was a success: glasgow is super useful right now
<whitequark>
but there's a significant amount of technical debt and not enough bandwidth to fix it and in many cases not even a consensus on what needs to be done
<electronic_eel>
esden: yeah, that should work well. I thought about ALPS SKRPABE010, it is cheaper on LCSC than yours. Same footprint. But if you got a cheap source that is good
<whitequark>
i don't think any of this is an immediate major issue, it seems that a lot of people are successfully using glasgow to achieve many different goals. but it is a long term major issue.
<whitequark>
here's something that would be incredibly helpful to me: migrating all of the remaining applets that use nmigen.compat to nmigen proper
<whitequark>
it's a relatively mechanical transformation that anyone with (n)migen knowledge can do
<whitequark>
it's not very fun tho.
<esden>
whitequark: I was about to ask about that. :D Good to know that could be a fun thing to do to get also more familiar with nmigen.
<whitequark>
hah
<whitequark>
i guess i'm just tired these days
<whitequark>
so i don't see it that fun
<whitequark>
i do it when i work on some applet, usually...
<whitequark>
we also need to migrate the SPI applet to the new pin names
<esden>
I do actually like those mechanical transformations. The goal is clear, and progress is relatively easy to achieve.
<d1b2>
<the_art_of_giving_up> same as esden.
<whitequark>
that's been bothering me since... just about the time when i first committed the SPI applet, frankly
<whitequark>
except back then there was no consensus on the terminology
<whitequark>
now there is, so, someone should just do it
<whitequark>
this is complicated by the fact that a ton of stuff uses the SPI applet as a base, and it's all fragile
<whitequark>
but it's doable
<whitequark>
once everything is on nmigen, we are free to venture into some advanced territory
<whitequark>
for example, right now JTAG is realistically limited to about 6 MHz
<d1b2>
<the_art_of_giving_up> do you need hardware to verify the bits you're rewriting retain function?
<whitequark>
because instead of using IOB registers it uses... some stupid crap i wrote as a standin
<whitequark>
the_art_of_giving_up: yes and no
<whitequark>
well
<d1b2>
<the_art_of_giving_up> Or is it just like different naming for same nmigen functionality so synthesis/compile-time errors are going to lead you on the right path sufficiently
<whitequark>
ok so look
<esden>
I have to refocus on the glasgow hardware to finally get that knocked out and prototypes ordered. Hopefully we can get that wrapped up. :D So I am not saying I am available now to do the migen compat to nmigen conversion. Thus if you the_art_of_giving_up want to start working on it go for it. :D
<whitequark>
with JTAG, i invented (tongue in cheek, the idea is pretty trivial) something i call "SERDES + sideband"
<whitequark>
the idea is that with a serial protocol like JTAG you have your actual protocol you're most interested in, which is high speed
<whitequark>
but you also have some "sideband" signals that are mostly just GPIOs, like resets, strobes, stuff like that, toggling them or polling them has no need to be efficient
<whitequark>
however, what is important is getting the timing of the "SERDES" part and the "sideband" part relative to each other right
<whitequark>
you don't want to toggle "sideband" signals via for example I2C because it's not inherently synchronized with the rest of the applt
<whitequark>
well guess what most applets do? toggle them via I2C because i didn't know better
<whitequark>
with some gross code to synchronize everything together
<whitequark>
it's reliable, it's just... bad
<whitequark>
so, since the sidebands are basically just GPIOs, *if* SPI applet used SERDES+sideband architecture, *then* migrating all the dependents would be trivial, since none of those applets actually do anything interesting with the sidebands
<whitequark>
and simple code review would suffice to make sure that "yeah, it stuffs the pins for the sidebands into the right place"
<whitequark>
but it doesn't
<whitequark>
so you actually do have to check it with the hardware
<whitequark>
:/
<whitequark>
i'd do so many things differently had i had the knowledge i obtained by doing them the way they currently are
<whitequark>
such is life
<d1b2>
<the_art_of_giving_up> I think I don't know enough about the current design of glasgow. When you're saying you're toggling with I2C, you mean you're manually toggling the pins in a different clock domain which is problematic?
<whitequark>
no
<whitequark>
well, that could happen, but it currently doesn't in any of the applets
<d1b2>
<the_art_of_giving_up> (said different clock domain being designed for being an I2C controller) dangit. I'm failing to grok what toggling GPIOs with I2C means
<whitequark>
the problem is that when you use the usual applet FIFOs, there's a ton of buffering going on
<whitequark>
you have the buffer in the FPGA, the buffer in the FX2, the buffer in the OS, and the buffer in python code
<whitequark>
this is required to get the massive throughput we support (you can actually saturate the USB 2 bus with just idiomatic Python code. you don't wanna know how much i spent getting that to happen)
<whitequark>
*how much time
<whitequark>
but
<whitequark>
what this makes really hard is writing a byte and then knowing when it actually ends up being parsed by the applet
<whitequark>
(thus initiating some kind of transaction on the bus)
<whitequark>
another feature we have, besides the applet FIFOs, is I2C registers
<whitequark>
so the FX2 is an I2C initiator, and you can ask it via USB to do some transaction or the other (sorry electronic_eel i still haven't finished that feature you need for the testbench...)
<whitequark>
the FPGA is an I2C target
<whitequark>
and there are some nice functions you can use to add a few arbitrary-width registers to the FPGA
<whitequark>
can make it a baud rate word for the UART or say a reset line for AVR
<whitequark>
the I2C register reads and writes are more or less synchronous, but the FIFO writes aren't, even after you flush
<whitequark>
so it could be that you do some FIFO transaction, then assert reset, and reset actually arrives before the entire FIFO transaction finishes
<whitequark>
there are also issues when the datasheet calls for a timed reset or something like that
<noopwafel>
(this is super informative btw, I am learning things)
<d1b2>
<the_art_of_giving_up> oh boy. And this calls for proper nmigen?
<whitequark>
basically, you really really want the main serial data stream and the state changes (or polls) for the sidebands to be multiplexed into the same raw stream
<whitequark>
but this is currently only done for JTAG
<whitequark>
where ... it's not that important because usually when you JTAG something you only use the JTAG pins anyway
<whitequark>
:/
<whitequark>
noopwafel: yeah this should be in some kind of doc
<whitequark>
mainly, i don't like to document things that i know are bad
<whitequark>
but i also don't have the energy to fix them lately
<whitequark>
which results in this pathological situation
<d1b2>
<the_art_of_giving_up> in my racing team, whenever somebody goes on a goood rant, I just take it and dump it into a separate page on docuwiki as a temporary thing lol
<whitequark>
the_art_of_giving_up: no, not directly
<whitequark>
the link to nmigen is much more banal
<whitequark>
fixing SPI dependent applets to use SERDES+sideband will require hardware revalidation of every applet
<whitequark>
migrating SPI dependent applets to nmigen without fixing them will also require hardware revalidation
<whitequark>
but, it won't be necessary if we migrate them to SERDES+sideband first
<whitequark>
but, that's way more effort i can't necessarily support right now
<whitequark>
:/
<whitequark>
fortunately none of the SPI dependent applets use obscure hardware at the moment
<whitequark>
just a bunch of super common stuff like ice40 chips and spi flash and avrs
<whitequark>
also
<whitequark>
we do have tests! ... sort of
<whitequark>
testing is hard. testing hardware you don't have software models for is harder. making sure these tests can be run without the actual hardware is damn near impossible
<whitequark>
of course, glasgow has some code that does it
<whitequark>
see commit bafd6096ed5d52c9a482b7013e889f6626b35dbe
<whitequark>
for example
<whitequark>
so the way this works is
<noopwafel>
can the SPI dependent applets be migrated one-by-one?
<whitequark>
you write some tests against a live device on your desk
<whitequark>
when you run them for the first time, the calls that the (in this case) AVR programming applet issues to the *underlying* applet, which is the SPI applet in this case, are recorded
<whitequark>
the next time you run it, the testing framework pretends to be the AVR on your desk, makes sure you give it exactly the same inputs, and responds in exactly the same way
<whitequark>
this makes it unnecessary for you to write a behavioral model of the AVR programming core, which is impossible anyway
<whitequark>
it's relatively robust in the sense that you can freely change the way the SPI applet works as long as the public interface stays the same
<whitequark>
plus the record/replay dumps are JSON, which means you can fix e.g. argument renamings with just sed
<whitequark>
it's relatively fragile in the sense that you can't do refactors that, say, reorder some calls without having to revalidate against real hardware even if the change is "trivial"
<d1b2>
<the_art_of_giving_up> the testing framework runs on what, and is connected to the outputs how?
<whitequark>
like maybe you know you can split an SPI transaction while passing hold_cs=True but the testing framework doesn't know it
<whitequark>
< noopwafel> can the SPI dependent applets be migrated one-by-one?
<whitequark>
to the SERDES+sideband system? yes
<whitequark>
to the new pin names? nope
<whitequark>
to nmigen? uhhh i plead the fifth
<whitequark>
<the_art_of_giving_up> the testing framework runs on what, and is connected to the outputs how?
<whitequark>
the testing framework runs entirely in python
<whitequark>
in fact there's not much of the "framework", i call it a framework because it intercepts your calls using magic that you won't be able to easily debug when it breaks
<whitequark>
what it really is, is just two mocks
<whitequark>
the first mock records all calls to some json file
<whitequark>
the second mock validates all calls against the same json file
<whitequark>
the idea is that glasgow already has the thing where applets are built like a tower
<whitequark>
so something like an AVR SPI programmer probably composes an AVR programmer and an SPI transport
<whitequark>
this means that there's an SPIControllerSubtarget used as-is, and an SPIControllerInterface that the AVR applet issues calls to
<whitequark>
so you can mock the SPIControllerInterface and as long as the applet doesn't do anything weird it'll just work
<whitequark>
spoilers: applets do weird things. for example. applets twiddle the I2C, which is not mocked by the testing framework at all, and currently crashes if you try to replay
<whitequark>
:/
<d1b2>
<the_art_of_giving_up> I see. So the testing framework needs some tlc...
<whitequark>
all of glasgow does :/
<noopwafel>
as you said, it's easy to criticise how you wrote the code given the hindsight granted by writing and using the code
<d1b2>
<the_art_of_giving_up> is the project stuck on a lack of time allocation by the contributors rather than a lack of skilled contributors?
<whitequark>
the_art_of_giving_up: the project isn't quite stuck
<whitequark>
for example, the hardware is proceeding nicely
<electronic_eel>
I'd say review is the bottleneck
<whitequark>
thanks to the efforts of esden and electronic_eel
<d1b2>
<the_art_of_giving_up> sorry, bad wording. Slowed down*
<whitequark>
yes
<whitequark>
review is the bottleneck, and seeing as i'm neither likely to compromise on quality nor currently have the ability to make the path for new contributions more smooth, it's probably going to remain the bottleneck for some time
<whitequark>
you probably should make peace with that fact
<whitequark>
i absolutely do admit that it's a problem though
<electronic_eel>
but on the other hand python and "setup.py develop" makes it really easy to switch branches, so you can easily pull in some PR and test or use it
<whitequark>
i think we can move *some* things forward though
<whitequark>
- i'll be happy to merge applets rewritten in nmigen
<whitequark>
and that helps the project a lot
<whitequark>
- i'll likely introduce some sort of "glasgow-staging" where community applets can all live in peace even if they're not quite up to my standards
<d1b2>
<the_art_of_giving_up> It makes me mad that meaningful projects get bogged down by circumstance. It just feels intuitively obvious to me that open tools for R&D are such a core thing for progress. Such things should actually get funded from basically research grants... It should actually fit the purpose of grants, creating something for the public good rather than the good of some one random corporation
<whitequark>
this does carry the risk that the first thing anyone hears is "install glasgow-staging to do any real work", sadly
AHMED--- has joined #glasgow
<whitequark>
but... even if it does, i don't see a path forward without some kind of staging area at all
<whitequark>
the_art_of_giving_up: well, it's not circumstance.
<whitequark>
i'd have a lot more free time had i not spent the previous five years or so in an abusive work environment
<whitequark>
and it's not something that money can help with, fundamentally
<whitequark>
it can for the most part stop things from getting worse
<d1b2>
<the_art_of_giving_up> anyway, I plan on getting into nmigen. If my Pynq shows up. Hopefully, I'll just appear in like two months with glowey eyes and start coding Truly Pythonic applets
<d1b2>
<the_art_of_giving_up> sadly I'm only a random firmware intern while I "study full time" for now so I'm not exactly affluent
<esden>
It was a general AD :D Not specifically targetted at you taogu :D
<whitequark>
the_art_of_giving_up: tbh, don't feel too much pressure to make perfect applets the first time
<whitequark>
it's entirely on me to provide clear coding guidelines, not on you to guess my intent
<awygle>
howdy the_art_of_giving_up :p
<d1b2>
<the_art_of_giving_up> hi there
<d1b2>
<the_art_of_giving_up> I am going to be happy if I manage to write a functional applet. Anyway, I think most discretion still lies on the sound mind of the programmer rather than the coverage of possible errors by the coding standard. I might just be jaded from the dozens of empty else clauses MISRA forces me to write
<awygle>
if you get stuck trying to get an applet off the ground i can help with getting to the point of, like, getting it to show up in the CLI and run, at least
<awygle>
(since wq patiently coached me to that point a while back)
<whitequark>
the_art_of_giving_up: i'm not talking about something like MISRA, and i of course agree that (in case of glasgow anyways) most of correctness stems from the programmer effort and the code review
<whitequark>
what i mean is mostly two things:
<whitequark>
- making the UI consistent with what's already there
<whitequark>
- making the API (which might be used by other applets, or driven through some sort of a script by an end user) consistent with what's already there
<electronic_eel>
the_art_of_giving_up: just a hint: not every applet needs to have it's own nmigen gateware part. if you for example write an interface for a i2c or spi ic, you can just reuse the existing nmigen gateware for these interfaces and just to the interfacing and cli parameter handling in python
<whitequark>
it's not so much correctness directly (though good interfaces absolutely do positively influence correctness) as just consistency in arbitrary ways
<whitequark>
hence, coding guidelines are useful
<whitequark>
esden: technically i'm on a vacation right now...
<whitequark>
so i probably shouldn't discuss work *sigh*
<electronic_eel>
whitequark: is glasgow work or hobby for you?
<esden>
whitequark: shoo, go play a game or something :P
<awygle>
on the other hand you can't really do vacation "wrong", so no need to beat yourself up for whatever you choose to do
<d1b2>
<the_art_of_giving_up> this summer has been the first summer in my life I haven't gotten deeply depressed, almost certainly precisely because I was kept sufficiently busy by work & thesis
<esden>
awygle: also true...
<whitequark>
electronic_eel: a bit of both. it is *definitely* work when i have to review pull requests
<_whitenotifier-b>
[glasgow] miek opened pull request #197: applet.interface.jtag_probe: convert to nmigen. - https://git.io/JJMCP
<whitequark>
but... what kind of work is it?
<miek>
err.. don't look at that then :p
<d1b2>
<the_art_of_giving_up> wow what timing
<whitequark>
it's work in public interest that will benefit people long after it's done
<whitequark>
so it's not just some stupid webdev bullshit that the next deploy will wipe anyway
<electronic_eel>
awygle: I get vacation wrong sometimes. when I have tons of ideas an plans what I want to do and then get depressed from my todo list and nothing done
<awygle>
electronic_eel: the "i have fucked up through overambition" bit and the "i am nominally on vacation" bit are independent for me :p
<esden>
I did not get the closest thing to vacation I have this year. But I hope ToorCamp happens next year... that said, I should probably take the car and go somewhere into the nature for a weekend at least.
<d1b2>
<the_art_of_giving_up> I'm sad Hackaday Belgrade didn't happen. That would've been great.
<awygle>
i am gonna take two full weeks off work as soon as this project is finished, i need it _badly_. i accidentally talked myself out of vacation because i was working from home so i "didn't need it". false.
<d1b2>
<the_art_of_giving_up> false af.
<d1b2>
<the_art_of_giving_up> I have a colleague at work who is still taking out vacation days from his last year's allocation :D
<whitequark>
this vacation is the first time in my life i took one (as opposed to sick leave...)
<whitequark>
i've been working for uh. almost a decade?
<awygle>
i have a colleague who tried to tell me i was an idiot for taking my vacation days since "they're the least valuable now that they will ever be, assuming we get raises"
<d1b2>
<the_art_of_giving_up> Jesus Christ
<awygle>
which is both true and totally beside the point
<d1b2>
<the_art_of_giving_up> Haha the model of the point of vacation being "doing as much financial damage to your employer" is something else
<d1b2>
<EmilJ> (renamed from the_art_of_giving_up)