umarcor|2 has quit [Read error: Connection reset by peer]
umarcor has joined #glasgow
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #glasgow
egg|laptop|egg has joined #glasgow
GenTooMan has quit [Ping timeout: 264 seconds]
Stormwind_mobile has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #glasgow
futarisIRCcloud has joined #glasgow
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 268 seconds]
PyroPeter_ is now known as PyroPeter
GNUmoon has joined #glasgow
<d1b2>
<NF6X> Hi! I'm late to the party. I first heard Glasgow mentioned in a vintage computer Discord quite recently, and then the new UNRE podcast episode thumped me on the head to learn more about it.
<sorear>
welcome
<d1b2>
<NF6X> I see that the instructions for using Glasgow under macOS want Homebrew installed for dependencies. I've always used MacPorts instead of Homebrew, and I'm not sure whether they can politely coexist on the same Mac. Has anybody here tried to use Glasgow on a Mac with MacPorts instead of Homebrew? Would I be in for an unusual level of pain if I were to try that?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
<d1b2>
<edbordin> This is all just "armchair analysis"... but it looks like brew is only required to install python and some fpga tools based on the instructions here https://github.com/GlasgowEmbedded/Glasgow#-with-macos . I wouldn't expect using your own python interpreter to be a problem and there are alternative ways to install the fpga tools.
<d1b2>
<NF6X> Ok, good. I've built all of the open source iCE40 tools a few times in the past while fiddling around with them. I haven't done anything real with them, but I've thought of designing around iCE40 with open tools before.
<d1b2>
<edbordin> I just listened to the podcast too 😄 as mentioned, probably the easiest option is to use the wasm builds. iirc nmigen will transparently detect if they're there
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<NF6X> It was a fun podcast!
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<d1b2>
<NF6X> Assuming that it is fit for purpose, is the sync header only intended for synchronizing two Glasgow devices, or is it thought to be potentially useable for more than two? I'm curious about just how many channels of logic analysis I might be able to achieve, and how hard it might be to blaze that trail if somebody else hasn't already gone there.
<d1b2>
<NF6X> For example, before its power supply died, my 36 channel (32 data + 4 clocks) HP 1663C logic analyzer was already feeling constrained when I was trying to debug stuff in my old Data General Nova 3 minicomputer. I've been thinking of getting a slightly less ancient mainframe-style logic analyzer with a lot more channels, such as an HP 16702B. I'm idly daydreaming about whether I might get were I want to be with an investment in new Glasgows instead of an
<d1b2>
investment in old dedicated logic analyzer hardware that I'd have to maintain and repair. Might it be possible to get four Glasgows working together?
<d1b2>
<Hardkrash> @NF6X I exclusively use the python.org python installers and successfully installed and ran the tools.
<d1b2>
<NF6X> Thank you!
<d1b2>
<Hardkrash> Note, I do use brew, but don't let it install python.
<d1b2>
<Hardkrash> I installed the tools before Kate's tap.
<d1b2>
<NF6X> I'm mostly using Python 3.8 at the moment, via MacPorts. I also installed the iCE40 tools before her tap (I assume that's a homebrew thing for some sort of package collection?). I assume that I've forgotten everything and I'd relive all of the frustration all over again, but at least I know that past-me managed to figure it out. 🙂
<d1b2>
<Hardkrash> Yes, taps are 2nd and 3rd party collections of packages that can be added to Brew. I'm sure I've forgotten everything I did as well.
<d1b2>
<NF6X> The older I get, the easier it is to forget everything. I'm getting really good at that.
<d1b2>
<Hardkrash> I wish I would remember that 6 months from now me would really appreciate some notes...
<kmc>
is the SYNC connector intended only for synchronizing clocks? it seems kind of hard to do anything else with only one pin
<kmc>
if so, seems like it should work with any number of Glasgows, having one generate the clock and the rest use it
<d1b2>
<Hardkrash> The SYNC pin is pulled up and open drain output. I recall that there was a question on the pull up value.
<kmc>
it seems pretty doable to get 4 Glasgows working together as a 64-channel logic analyzer, one of them clocking the other 3, and all 4 sending data over separate USB connections
<kmc>
but i'm new to all this so i don't know for sure if that's doable
<d1b2>
<NF6X> Interesting. I wonder if I would get bogged down in the software side of managing the four USB connections... I think in hardware more easily than software. I think my biggest consideration for whether or not to back the campaign is whether I'd actually do anything with the Glasgows, or just buy the hardware and not reach activation energy on the software side. Like I have with multiple SDRs so far. 🙂
<kmc>
yeah I have a bladeRF gathering dust in a box :/
<d1b2>
<NF6X> I just got two AirSpy HF+ receivers for a project that, let's face it, I probably will never complete.
<kmc>
ooh, I have one of those
<d1b2>
<NF6X> In my defense, they were on sale.
<kmc>
used it a bit as a panadapter with my HF rig and a T/R switch
<d1b2>
<NF6X> My (never to be completed) plan is to use one as a panadaptor dedicated to monitoring the 455 kHx IF output from one of my R390As, and the other as a transmitter monitor for whatever I'm transmitting (generally AM or FSK), possibly from my T-368C transmitter if and when I ever get around to re-fixing it.
<d1b2>
<NF6X> I see many apparent-humans here have BOT symbols. What's up with that? Are those bot accounts for folks talking here by some means other than the normal Discord app?
<kmc>
must be the IRC bridge; I'm chatting in Freenode #glasgow right now
GNUmoon has joined #glasgow
<d1b2>
<NF6X> Ah, cool. A few days ago, I had an excuse to dust off an old speech synthesizer from the mid 80s, and I thought it would be fun to write some hack to have it read Discord posts to me. Then I started reading up on the Discord API, and how using it required registering a bot account, and having the admin of each server manually approve the bot account... and lost interest really fast.
<d1b2>
<NF6X> I almost passed out just from the mention of oath2 keys and stuff alone.
NF6X has joined #glasgow
<NF6X>
I may or may not have joined the IRC and Discord at the same time. Will that make the universe implode?
<d1b2>
<NF6X> Aha! Now I'm a BOT, too! 😁
<d1b2>
<edbordin> One thing to note is that edits on discord don't show up on irc so it's generally worth avoiding that in these bridged channels
<d1b2>
<NF6X> Aha! Thank you for that.
NF6X has quit [Client Quit]
<d1b2>
<edbordin> Ideally the discord plugin would handle that edge case but you don't see me volunteering to fix it :P
<d1b2>
<NF6X> Sounds like software. Blech!
<d1b2>
<NF6X> (I kid. I like programming. I just get foggy when it gets too far away from nice, simple, low-level register fiddling.)
<d1b2>
<edbordin> I think it's some kind of javascript-esque language, I try to stay out of that world
<d1b2>
<NF6X> I'll nope the heck right out of that. I love me some Python or C, maybe even some C++ in a pinch, but I have no interest in Java, anything-sharp, anything remotely webby, etc.
<d1b2>
<NF6X> I'm undecided about whether I'd actually get nmigen. VHDL or Verilog I can understand and create.
<d1b2>
<NF6X> For a brief while at the last MegaCorp before I thankfully got laid off, I was thrust into the world of SystemVerilog. It kind of broke my brain.
<d1b2>
<NF6X> (in the context of test bench development)
<d1b2>
<NF6X> I'm impressed by the circuit block identifications on the Glasgow C2 PCB renderings. Now I just saw the "Manually calibrated" note and current calcs for the LEDs on the schematic diagram, and I felt a chill of excitement.
<d1b2>
<NF6X> You mean... the LEDs aren't going to have vastly different perceived brightnesses, with some of them causing permanent retinal damage? 🤤
<d1b2>
<NF6X> Even if I never plug it in, I'm starting to think I need to back this project just to encourage whoever went to the trouble of commenting the schematic so nicely.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<d1b2>
<Hardkrash> I'm excited and going to hopefully use glasgow in a number of cases where a Logic 16 and other adapters just don't do what I need. e.g. a timestamped UART data stream from a hardware timer derived from a reference 10MHz and UTC/GPS time synced.
<d1b2>
<Hardkrash> I also agree that the schematics and layouts were created with great care.
<d1b2>
<NF6X> As a hardware designer who tries to design schematics with great care, the Glasgow schematics are the song of my people. Now I've just been reading issue 135 as referenced on the schematic... this kind of subtle hardware fault analysis is so very relatable, and I think I'm in love with y'all.
<d1b2>
<NF6X> Are Glasgow add-on boards called Kilts?
<d1b2>
<Hardkrash> It's best to think of rev as hardware capability configurations. So revC1 is hardware configuration C with design spin 1, revC2 is the second design spin for the CrowdSupply campaign. you can see that revC3 is being tracked in this issue. https://github.com/GlasgowEmbedded/glasgow/issues/255
<d1b2>
<Hardkrash> No, they are addons
<d1b2>
<NF6X> I saw the term "kilt" used a few times in the revD discussion, and wondered.
GNUmoon has joined #glasgow
<d1b2>
<Hardkrash> The official term is addon. You can look at whitequark's message back on June 11th 2020. I just edited out the term from my comment.
<d1b2>
<NF6X> Cool.
<d1b2>
<NF6X> I would definitely see myself designing addons for some of the harebrained things I'd want to do with Glasgow.
<eddyb>
I wonder if it were possible to disable edits in a Discord channel
<eddyb>
*if it would be
<d1b2>
<NF6X> That, I don't know. It's possible in Slack, I believe, since the Slack at work only allows edits during a brief window after each comment is made.
<eddyb>
doesn't look like there is a way to do this :(
<d1b2>
<NF6X> I find the edit-disable in the work Slack to be annoying, but I can kind of see why some folks would need that in a business setting to avoid shenanigans. I'd be in favor of it here (it it was possible) because I doubt I'll remember tomorrow that edits weird out the IRC integration.
<eddyb>
they just don't translate to IRC at all AFAICT. similar to GitHub emails not including edits to comments
<eddyb>
the Matrix-IRC bridge sends the edited message with "* " before it, at least, so you can tell something happened
<d1b2>
<NF6X> Maybe I should fire up the ol' Amiga and use it to log in to the IRC, as long as I'm still working at home anyway!
<d1b2>
<esden> @eddyb unfortunately not. There is no dedicated permission that would allow me to disable message edits or limit message length. (which is another issue with the bridge)
<eddyb>
yeah I saw :(
<eddyb>
(I realized I can check a Discord server I have admin powers on)
<d1b2>
<NF6X> Well, that does it. Just based on quality of schematics and issue discussion alone, I have to back this campaign!
GNUmoon2 has joined #glasgow
DarthCloud has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 240 seconds]
DarthCloud has joined #glasgow
egg|laptop|egg has joined #glasgow
<d1b2>
<theorbtwo> If you are serious about never turning it on, consider donating it ?
egg|laptop|egg_ has joined #glasgow
egg|laptop|egg has quit [Ping timeout: 256 seconds]
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<d1b2>
<DX-MON> @NF6X: your retro interest might be tickled to know that Glasgow is getting things like keyboard adaptor addon boards to cleanly pair with the applets it already has for talking various old keyboard protocols such as being able to be a PS/2 host
<d1b2>
<DX-MON> hands-down one of the best and user-simplest yet most powerful tools I've ever laid my hands on
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
NF6X, Hardkrash: thanks for the kind words! :) it took many of us a great lot of time to design the hardware, especially those from software background (*cough*myself*cough*)
<whitequark>
Glasgow is pretty much my first serious hardware project, and I've tried to make sure it not only works for me, but also for other people for a good while into the future. for me this takes an eternity and a half to do, though other hardware folks on the team have an easier time, I think
_whitelogger has joined #glasgow
<d1b2>
<Attie> ... that 1000 backers goal is looking pretty real now!
<sorear>
really slowed to a trickle though
<d1b2>
<Attie> @whitequark - I'm going to do more on the slides today, and hoping I can put a first pass under your nose soon... would you prefer to do it in private (before the talk, i.e: email), or would you like me to share them here as i'm going
<sorear>
oh the talk is happening?
<d1b2>
<Attie> @sorear - yeah, would be interesting to see a graph
<d1b2>
<Attie> yes! \o/
<whitequark>
Attie: however you're comfortable with
<whitequark>
if you share them here you will get more feedback, which can be both good and bad
<d1b2>
<Attie> ok, I think i'd prefer private/email to avoid too much / committee input, and keep it a bit of a surprise (sorry everyone else)
<d1b2>
<Attie> i'll send through when I'm ready with a first draft
<sorear>
although fosdem is after the end of the crowdsupply campaign ...
<d1b2>
<Attie> oh, you're right - i thought the campaign ended just after
* sorear
wonders whether there are productive ways to raise awareness beyond the immediate team's immediate twitter followers
<d1b2>
<Attie> i'm hoping to stir a bit once the fosdem schedule is out... remembers to look for updated fosdem schedule
<d1b2>
<Attie> (it's not out yet)
<sorear>
hmm. we should make sure it's possible for people to place orders during the talk
<sorear>
will crowdsupply still take orders after the funding period or does 1bitsquared need to set up by then
<sorear>
it would be bad if the talk fell in the middle of an availability gap
<whitequark>
i'm slightly worried about promoting the project faster than we can set up structures to handle community contributions
<sorear>
fair
<whitequark>
re "raising awareness"
<d1b2>
<Attie> that's a good point - perhaps out-of-tree support is bumped up so that it's less painful for people to do maintain their own thing? (as a short-term fix / approach)
<whitequark>
that is already something on my list immediately after proper windows support
<whitequark>
but, you know, trying to work a little less over the holidays at least
<d1b2>
<Attie> ah, good
<d1b2>
<Attie> absolutely - didn't mean to apply pressure
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #glasgow
<d1b2>
<Attie> re the pull up/down/none... there was some conversation earlier about how it wasn't Hi-Z...
<d1b2>
<Attie> is this because the level shifter could be output (i.e: Lo-Z), or was it something else?
<whitequark>
it is because the pin can be driven
<whitequark>
yeah
<d1b2>
<Attie> cool, ty
<whitequark>
"Lo-Z" heh
<whitequark>
couldn't parse that at first, but hey, can't argue with it
<d1b2>
<Attie> hehe
<d1b2>
<Attie> @electronic_eel - do we have a "max safe" voltage for the Vsense pin? (I see abs max as 40v in the schematic, doesn't appear to be on the CS page)
<d1b2>
<Attie> ... thinking about it, it's looks like it's just the INA233 and Zener spec, so I'll go with 36v, unless you advise otherwise
<whitequark>
(36v sounds reasonable to me as well)
<d1b2>
<Attie> ok - i just read #221, which mentions 36v too
<d1b2>
<Attie> @whitequark - do you have a feel for how long an EEPROM (size of your choosing) takes to read out? A larger one (that uses a shift register) would be good
<whitequark>
tens of seconds is about right for megabyte-sized EEPROMs
<whitequark>
to get anything more precise i would have to measure
<d1b2>
<Attie> thanks! i think that's precise enough, unless you wanted to put a hard figure in (no rush for it)
<whitequark>
i do not, it will vary with a lot of factors anyway
<whitequark>
such as access time
<d1b2>
<Attie> sure
<whitequark>
is this for the talk?
<d1b2>
<Attie> yeah
<d1b2>
<Attie> just filling in some details i've left out previouslyt
<whitequark>
might be a good idea to mention that currently, applets are written more for simplicity and robustness than performance
<whitequark>
with the understanding that an FPGA lets us improve things later
<d1b2>
<Attie> fair point, will do!
<whitequark>
you definitely *could* have super-fast pipelined EEPROM readers that max out the chip's capabilities
<whitequark>
does anyone want the complexity you need for that? probably not
<d1b2>
<Attie> heh, indeed. it's nice to get a feel for what to expect... "tens of seconds" is good / very acceptable, "a couple of minutes" isn't great, etc...
<whitequark>
i think i'm underselling it but i don't feel like digging out an EEPROM right now
<d1b2>
<Attie> ah, no problem
<whitequark>
the applet also uses the read latency for the slowest chip that was reasonably popular, by default
<whitequark>
i don't normally change it because it doesn't really make a difference for me
<whitequark>
i think that might be the bottleneck in most cases
<d1b2>
<Attie> that's fair / sounds about right
<whitequark>
actually, i misremember things a bit, looking at the defaults, the read takes 500 ns, and the address shift takes 1.5 us
<whitequark>
for a 18 address bits eeprom
<whitequark>
so that's about a second to read a 256K EEPROM
<whitequark>
for 24 address bits (2 MB), the address shift takes 2 us, so it reads in 40 seconds
<d1b2>
<Attie> shiny - i might just say <10s for 1MiB?
<d1b2>
<Attie> oh
<d1b2>
<Attie> makes a larger difference than i expected!
<whitequark>
20 seconds for 1 MB EEPROM
<whitequark>
so let's say half a minute for 1 MB
<d1b2>
<Attie> sure
<d1b2>
<Attie> @whitequark - I've just remembered, I was playing with large (64-bit) registers the other day... for the edge counter, and had some unexpected problems
<d1b2>
<Attie> is that known / expected?
<d1b2>
<Attie> (the register occasionally read as a very incorect value in nMigen, and was then loaded into a counter that took forever to count a few zillion ticks)
<d1b2>
<Attie> ... i ended up backing off to 32 bit registers again, as there is no practical use for such large values there
<whitequark>
sounds like a CDC problem
<whitequark>
and it is something we should look into, because it is possible that 32 bit registers simply hide the issue
<d1b2>
<Attie> i think the notes are elsewhere for the 64-bit registers
<d1b2>
<Attie> i might have to re-run the issue to get info, but basically change 32->64 in that file, and you'll see it
<d1b2>
<Attie> it'll "hang", and if you inspect the counter, it'll be ... a big value
<whitequark>
looks like you are not synchronizing the reset
<whitequark>
hm. actually that might be harder to fix than it looks at first glance
<whitequark>
i'll have to think about it
<d1b2>
<Attie> np
<d1b2>
<Attie> i'll try to make an issue for the 64-bit registers, and dig into it at some point
<d1b2>
<Attie> re the exception i accidentally linked above... i have no idea what's going on there 🙂
aquijoule_ has quit [Remote host closed the connection]
bvernoux has joined #glasgow
richbridger has joined #glasgow
<electronic_eel>
sorear: Attie: with crowdsupply you can usually still buy after the first campaign is over. it is then renamed to "pre-order" and it is expected that the stuff bought then will be delivered later, when all the backers of the campaign have gotten their orders
<electronic_eel>
Attie: the max safe voltage for vsense is 36V. 40V won't kill the INA233, but the TVS diode could already begin to conduct
<electronic_eel>
also the accuracy isn't guaranteed anymore
<d1b2>
<Attie> @electronic_eel - thanks
<d1b2>
<NF6X> How much current can the Glasgow I/Os sink? I’m thinking of 5V TTL interfaces terminated in 220/330 ohm totem poles where drivers are expected to sink a lot of current, and wondering if those will need drivers on add on boards.
<d1b2>
<Attie> each I/O pin is rated for ~50mA
<d1b2>
<NF6X> Nice!
<electronic_eel>
NF6X: there are 33 Ohms termination/limiter resistors on the io pins. with 5v i measured around 100 mA source+sink, which is much more than what is specced
<electronic_eel>
and this seems to be safe for permanent usage, i ran it for 12h and marcan even longer
<d1b2>
<NF6X> That sounds more than sufficient.
<electronic_eel>
i couldn't measure any degradation, even though i really tried to find something
<electronic_eel>
so 5v ttl should work directly. only issue is if you have big fanout and have to drive a lot of paralleled inputs
<whitequark>
i think the one case where it gets out of spec is if you have a big fanout with small pullups
<whitequark>
and the deviation is also marginal
<kmc>
50 mA is the absolute max rating on the level shifter which drives the output pins (SN74LVC1T45)
<whitequark>
the combination of all three (ie with the deviation from spec causing incorrect logic levels to be read) seems to be so unlikely to happen in the wild that it is irrelevant
<kmc>
but i'm not surprised they're okay with more
<whitequark>
kmc: marcan tested them driving a dead short for 24 hours, iirc
<whitequark>
that gets quite toasty
<cyborg_ar>
nice
<whitequark>
and yet still there is no damage we could find
<electronic_eel>
kmc: yes. but we measured several specimen from different batches and couldn't fry it.
<kmc>
very good
<whitequark>
with the 33 ohm resistors i am confident they are virtually indestructible
<whitequark>
(other than by over/undervoltage)
<electronic_eel>
in my latest test the resistor packs got warmer than the level shifters
<marcan>
AMRs aren't "if you exceed this it dies", they're "we guarantee it won't die if you don't exceed this, mostly"
<cyborg_ar>
my guess is that the effect is possibly a shortened life... maybe it will last 20 years instead of 50
<cyborg_ar>
yeah AMRs are usually at the "knee" of where damage can happen, possibly with a bit of margin for process variation
<marcan>
sorear: oh, I never ran that test
<electronic_eel>
the shifter was 19 K warmer than ambient, at 20°C this is 39 °C. it will be a very long time till it dies from that
<marcan>
maybe electronic_eel can do it :)
<d1b2>
<Attie> AMR?
<whitequark>
absolute maximum ratings
<d1b2>
<Attie> oh, abs max ratings
<d1b2>
<Attie> ta
<cyborg_ar>
well temperature is not the only thing that kills semiconductors, there is also going over the max current density, but damage happens at a muuuuch longer timescale
<kmc>
yeah, and the datasheet gives a single max for all packages
<electronic_eel>
marcan: oh, +-12V tests. hmm, i think i'll better build up a small protoboard with that. don't want to fry my glasgow prototype, still got some tests to do
<whitequark>
yep
<kmc>
the tiny chip scale version may melt at a lower current than the one used in glasgow
<kmc>
anyway, i know how absolute max ratings work :) I was just observing that's where the 50 mA figure comes from
<d1b2>
<xabean> AMR: it's ASMR without the S for sizzle.
<kmc>
I believe 50 mA is also the rating on the clamp diodes (relevant to the thread sorear linked)
<kmc>
would be fun to come up with a minimal part count actual-RS232 adapter for Glasgow
<sorear>
so we have the milled case exactly match the shape of the level shifters so that it becomes a massive heatsink when installed,
<kmc>
need a few diodes and capacitors for a charge pump
<kmc>
sorear: :D
<marcan>
most RS232 sinks will take 0V/5V input as valid enough
<cyborg_ar>
max232, plus 3 capacitors
<marcan>
(some cheap-ass adapters do that)
<cyborg_ar>
:P
<kmc>
I have an ODROID case like that! the aluminum case makes a thermal contact with the SoC
<marcan>
which is why I was suggesting the straight TX into glasgow with a resistor, RX straight out
<marcan>
dumb af but will probably work with a huge subset of RS232 devices
<whitequark>
hm
<marcan>
if glasgow doesn't die on the current-limited +/-12V
<sorear>
kmc: i thought i was joking
<whitequark>
sorear: this is really common
<whitequark>
i have one like that for my limesdr
<marcan>
indeed
<marcan>
plenty of commercial devices do this
<marcan>
e.g. google home mini
<whitequark>
except i think it is anodized in a stupid way so it breaks selftest
<kmc>
"(2) The input and output negative-voltage ratings may be exceeded if the input and output clamp-current ratings are observed."
<electronic_eel>
most rs232 are just -5..+5 v these days. 12v is rare
<whitequark>
electronic_eel: i'd be concerned about having 0v as the low level
<whitequark>
if the input is a comparator with gnd...
<electronic_eel>
yes, 0v as low is really a concern, haven't tried that yet
* kmc
thinks back to that AVR app note on zero-crossing detection where 120Vac is wired to a GPIO
<marcan>
I think some converters get away with that...
<whitequark>
i think it will work sometimes but i doubt marcan's "huge subset" statement
<whitequark>
i may be wrong
<cyborg_ar>
current is current
<whitequark>
^ that
<sorear>
can you run glasgow's GND 1V or so lower than the RS232 GND
<cyborg_ar>
the only voltage rating you really care about is the one of the dropper resistor
<cyborg_ar>
and the current rating of whatever clamp diodes
<whitequark>
don't try that with stellaris
<marcan>
whitequark: VIT+ is 1.7Vm VIT- is 1.2V for MAX232
<whitequark>
lol
<kmc>
i mean the isolation voltage between the pins on an IC is not infinite :) but it's probably way over 12 V
<marcan>
so, every single device using a MAX232 will work
<cyborg_ar>
and, if the top clamp dumps the voltage into the positive rail, any overvoltage protections that would kick in if the rail soars
<whitequark>
marcan: ok, i doubt it much less now
<whitequark>
(i'm not sure how common max232 actually is)
<marcan>
yeah but everything cloned it
<marcan>
why would clones break this
<marcan>
also dealing with negative voltages *at all* makes everything more painful
<whitequark>
yeah that is a fair point
<marcan>
I bet everything just has a resistor/clamp to gnd and a normal inpuit
<whitequark>
yeah you're probably right
<d1b2>
<Attie> yeah, i thought a lot of "RS232-lite" interfaces have their threshold higher than zero
<cyborg_ar>
yeah the only reason they would deviate from the max part is if it was cheaper/simpler
<d1b2>
<Attie> the "real RS232" stuff will struggle of course
<marcan>
ST232 has the same specs
<marcan>
but yeah my point is everything "modern RS232" will handle this
<electronic_eel>
i still think we should design a "proper" industial io addon for Glasgow, with RS232 and RS485
<whitequark>
electronic_eel: agreed
<electronic_eel>
Attie has already done CAN
<marcan>
sure
<whitequark>
btw, did anyone else find that the max part is kinda prone to failure?
<d1b2>
<Attie> i was planning to get on VGA / RS232 / RS485 / etc... too
<d1b2>
<NF6X> Agreed! I'll want one for sure, even if I have to design it myself.
<d1b2>
<Attie> to avoid the pain of wiring things up each time
<d1b2>
<Attie> (separate - not on one board)
<electronic_eel>
whitequark: what do you mean exactly by "prone to failure"?
<cyborg_ar>
is the position/spacing of the headers part of the "API" ie: could it be set so things like shiends/hats could be made based on those dimensions and not be broken by otherwise electrically compatible revisions of the board?
<whitequark>
electronic_eel: i unintentionally killed two of them, i still don't know how (it wasn't overvoltage or overcurrent), and they remain the only ICs i ever killed without a clearly identifiable cause like "i swapped the power rails, oops"
<whitequark>
cyborg_ar: yes it is
<marcan>
which max part?
<d1b2>
<NF6X> I haven't personally noticed failures of MAX232, but I also reflexively avoid designing in Maxim parts based on being salty about their fantastic catalog vs. what you can actually buy.
<whitequark>
cyborg_ar: it has been effectively unchanged since revA
<cyborg_ar>
nice
<whitequark>
marcan: MAX232
<marcan>
oh huh
<cyborg_ar>
that's odd. i always found them pretty robust
<whitequark>
NF6X: yes, i haven't really used maxim parts because of that and also because i've had a few others behave in really strange ways
<electronic_eel>
whitequark: are you sure these were genuine maxim parts? there are a lot of fakes out there
<cyborg_ar>
was it a genuine(tm) part or one of the many clones?
<cyborg_ar>
so many clones
<whitequark>
electronic_eel: it was bought from the company that prides itself on being reputable. not that i trust it very much
<cyborg_ar>
though most clones work great
<marcan>
some clones work better than the originals!
<whitequark>
nowadays i would decap, but i was basically a child back then, it was so long ago
<marcan>
this is the case for FTDI devices
<cyborg_ar>
the only time i saw a max232 dead was when a wire got pinched and it got fed 110VAC
<whitequark>
yeah no i was using it as intended. at the time i suspected ESD
<cyborg_ar>
ULN2003s too
<cyborg_ar>
fireworks
<whitequark>
but ... unless it was orders of magnitude more susceptible to ESD than just about anything else i've handled, probably not?
<whitequark>
ok, except stellaris.
<electronic_eel>
hmm, i haven't used an original max232 for ages. there are a lot of better specced parts from maxim, ti, st,... out now. so i don't have any experience with the old parts
<cyborg_ar>
esd is such an annoying thing
<d1b2>
<NF6X> I'm mildly anti-FTDI because of their heavy-handed reaction to their counterfeiting problem. I still use them and even design them in, but I like to use other stuff first by default.
<cyborg_ar>
maybe the charge pump bits are more suceptible?
<whitequark>
NF6X: i'm heavily anti-FTDI. it is why i started this project
<whitequark>
which has then underwent severe scope creep
<d1b2>
<NF6X> LOL! Yeah, just a bit of scope creep.
<electronic_eel>
just a slight smidge of scope creep
<cyborg_ar>
lol
<whitequark>
there's still MPSSE gateware in the source tree. it has never been hooked to anything, ever
<sorear>
"glasgow" is an oblique reference to ftdi's headquarters
<hl>
honestly there are plenty of other reasons to be anti-FTDI, like their total lack of documentation
<hl>
it's farcical they became so popular
<d1b2>
<NF6X> Ah! I was just going to ask about the origin of the Glasgow name.
<cyborg_ar>
its because they had good drivers on windows
<electronic_eel>
^^^
<cyborg_ar>
why else would other companies clone it?
<d1b2>
<NF6X> I've actually had FT232 protocol docs under NDA before. Weren't hard to get, though A) that was before the counterfeit thing and B) it's not open-source friendly.
<cyborg_ar>
because until win10 it was a hellscape of no usb communication class drivers built in for serial
<hl>
let me get this straight, they have docs, don't publish them, and want an NDA? hahahahahahahahahahahahahahahahahahahaha
<cyborg_ar>
and even then, CDC is not really made to make a serial converter
<electronic_eel>
i actually wonder why there aren't any more chinese chips out ther now that win10 has the comm class drivers integrated
<whitequark>
wait. what
<whitequark>
windows did not have cdc acm?
<whitequark>
until win10?
<cyborg_ar>
the USB IF initially was actually hostile to the idea of having a proper usb->serial interface
<d1b2>
<NF6X> I'd rather just have FTDI-like parts that are USB CDC ACM. Microchip (used to?) makes one that's PIC-based, but it was less than a full 9-wire port as I recall.
<electronic_eel>
whitequark: no, that came later with an update to win10. even the original release didn't have it
<cyborg_ar>
as they felt it would undermine the whole idea of doing USB
<whitequark>
cyborg_ar: oh so THAT is why we are stuck with the insanity that is using CDC ACM for serial
<whitequark>
thanks, now i have one more reason to hate USB IF
<cyborg_ar>
whitequark: until win10 you need at least an .inf to have a cdc acm device recognized
<d1b2>
<NF6X> I don't personally care about Windows support for anything, but I'm kind of a compulsive jerk with respect to Microsoft.
<whitequark>
electronic_eel: cyborg_ar: depressing. i tested my FX2 impl of CDC ACM on a Windows VM and thought it just had that forever
<d1b2>
<NF6X> (and I know that for making a product, Windows support needs to be first-class, whether I like it or not)
<cyborg_ar>
whitequark: yea, they felt that if they just had a proper serial port class a lot of device manufacturers that already made serial devices would just use that instead of using the proper classes
<electronic_eel>
also stuff like usb audio 2.0 wasn't in win10 until ... i think last year or something like that
<cyborg_ar>
but yeah a lot of ugly in USB you can trace it back to microsoft windows
<whitequark>
just about everything about usb audio is aneurysm-inducing
<whitequark>
the only thing worse than usb audio is usb video
<cyborg_ar>
also until windows 7 it was not possible to do userspace usb without shit like zadig. and even then, you do have to put some nonstandard descriptors to get windows to install a dummy winusb driver on the kernel side
<electronic_eel>
unfortunately the alternative to usb audio/video is often just a pcie card with either no linux support at all or driver blobs
<whitequark>
electronic_eel: yes. i mean, glasgow uses usb for the same general reasons
<cyborg_ar>
whitequark: do you use a class driver or just raw bulk transfers?
<whitequark>
cyborg_ar: in which context? glasgow?
<cyborg_ar>
glasgow yes
<whitequark>
latter, it uses winusb
<whitequark>
which actually makes supporting windows tolerable
<d1b2>
<NF6X> So, did FTDI opinions directly lead to the Glasgow name? Is it Glasgow because it's a Scots Army Knife, or the other way around? Any opinions about Big Clive's Stottish MRE video? 🙂
<cyborg_ar>
do you have a WCID desctriptor?
<d1b2>
<NF6X> *Scottish
<whitequark>
yes. i got python-libusb1 to ship the libusb dll as well
<whitequark>
so with a bit more work, it will be ready to use with just one pip install command
<cyborg_ar>
it's so annoying that it is even needed
<cyborg_ar>
but the way windows supports hardware is rigid and archaic
<whitequark>
the worst part is that windows caches negative hits
<cyborg_ar>
it does
<cyborg_ar>
its a pain in the ass
<whitequark>
word
<cyborg_ar>
so much registry bureaucracy to load a stupid driver
<whitequark>
i assume it is because some devices crash on WCID request
<whitequark>
NF6X: it did, and the other way around
<cyborg_ar>
i think its just dumbness, why does windows need to be such a control freak about every single piece of hardware being married to a kernel driver
<cyborg_ar>
vs just allowing user space to access any device not currently bound to a kernel driver
<d1b2>
<NF6X> I've always felt that the way Windows deals with USB, e.g. "searching for a driver" again after plugging a class device into a different hole, was fundamentally broken. But I do have an anti-Windows bias.
<cyborg_ar>
it is infuriating
<cyborg_ar>
specially in old windows versions like 7
<electronic_eel>
i think the idea of userspace talking to a device was very strange for the devs at microsoft, so they never really considered this
<cyborg_ar>
it takes like 5 seconds for a mouse to be ready to use when you plug it in
<whitequark>
i think windows' handling of usb is actually the norm for any OS, it is the linux one that is exceptional
<electronic_eel>
cyborg_ar: depends on the speed of your harddisk. can also be 30 seconds
<cyborg_ar>
at least on 10, for most class devices they are ready to use immediately
<whitequark>
even in linux, almost no devices are handled the same way usb is
<whitequark>
(which is, i think, actually bad)
<cyborg_ar>
the thing with windows is that it treats usb devices a bit too much like devices connected to other buses, like PCI, when USB is clearly a much more volatile connection
<electronic_eel>
hmm, plugging esata at least looks similar for the user
<whitequark>
esata has one fixed function though
<whitequark>
ok, i guess the other bus that permits userspace drivers is scsi
<d1b2>
<NF6X> Hmm. Well, Windows is the only OS I'm personally aware of that (at least pre-10; not sure about now) doesn't just see a previously known device in different spot in the tree and go through user-visible setup shenanigans.
<whitequark>
yes, the way it handles class drivers is stupid
<whitequark>
but that it needs a kernel driver is not that unreasonable
<whitequark>
linux does the same thing as winusb elsewhere, consider vfio-pci
<cyborg_ar>
linux otoh seems to deal better with the idea that USB devices are removable. though that can be annoying, until relatively recently there was no reliable way to get a repeatable name for say a bunch of ACM adapters as they could be identified in random order
<electronic_eel>
they should sell laptops with 64 usb ports, so that you have one dedicated usb port for each of your gizmos
<whitequark>
electronic_eel: they should make the 64 ports as a cascade of 4-port hub chips, too
<d1b2>
<NF6X> Needing a kernel driver doesn't inherently bother me. It's the way it handles known hardware with registered driver moving in the tree that has always triggered me.
<cyborg_ar>
<3 /dev/serial/by-id/*
<whitequark>
electronic_eel: 8-port chips i guess.
<cyborg_ar>
yeah the thing is that windows does this whole marriage ceremony between an instance of a hardware device and the driver
<cyborg_ar>
and records it in the registry
<whitequark>
cyborg_ar: TIL /dev/serial, I always wrote per-device udev rules
<whitequark>
which works fine but is laborous
<electronic_eel>
are there any 8 port usb hubs out there for usb 3? haven't seen any yet, just 4 port
<cyborg_ar>
vs linux just wakes up the driver and lets it stick if the device is present
<cyborg_ar>
whitequark: :)
<cyborg_ar>
yeah it is great, specially if the devices have unique serial numbers
<whitequark>
which is rare
<d1b2>
<NF6X> Any idea on the timeline for rev D hardware beta testing? More ports really interests me. I was just thinking of SCSI-2 last night. 18 ios. Grr! Maybe I can squeeze by in 16 by not supporting parity, and overloading RST function from the power pin or something.
<cyborg_ar>
cant live without it on my lab setups
<cyborg_ar>
well not for me, i consciously make sure they do
<whitequark>
NF6X: no ETAs
<whitequark>
that said i was also thinking about SCSI
<whitequark>
actually have ordered another device i can test with
<cyborg_ar>
scope creeep
<d1b2>
<NF6X> I'm signed up for two Glasgows+cases. That Sync pin needs to be experimented with.
<electronic_eel>
would a slow scsi work with the atf cpld?
<d1b2>
<NF6X> atf cpld?
<electronic_eel>
or is it too slow?
<whitequark>
cyborg_ar: na, SCSI is within the current scope (it is a digital interface)
<whitequark>
electronic_eel: the atf cpld is quite fast
<whitequark>
NF6X: i completely reverse-engineered the ATF15xx CPLD series
<whitequark>
just to make pin extenders for glasgow
<d1b2>
<NF6X> Sweet!
<cyborg_ar>
how full does the FPGA usually get when loaded with gateware?
<whitequark>
cyborg_ar: most of the current applets use a small fraction of the available logic
<d1b2>
<NF6X> Aha! So, CPLD on an addon board is already a thought for this Scots Army Knife? Very cool.
<electronic_eel>
but the atf cpld has very few flipflops, so you can't easily latch stuff and switch between input and output
<electronic_eel>
or am i missing something?
<whitequark>
electronic_eel: the idea is to build fuse maps on demand, just like with the FPGA
<whitequark>
sure, flash has limited lifetime... which you will struggle to actually exhaust
<electronic_eel>
hmm, but what about a protocol where you need to send a command to a data port and then read the answer on the same port?
<d1b2>
<NF6X> I humbly propose going straight to 64 I/O for revD. One digital interface I'd like to play with is Pertec formatted magtape interface, with 51 I/O. 🙂
<whitequark>
electronic_eel: overprovision the CPLD
<whitequark>
NF6X: i don't think the largest FPGA package has enough balls
<electronic_eel>
whitequark: ecp5 would solve that
<electronic_eel>
would be quite a chunky board though
<whitequark>
yeah, i think revD is fine with 32 IO
<cyborg_ar>
i could see a small cottage industry of little boards with a connector on one end and either one or two glasgow headers on the other for all different kinds of buses
<d1b2>
<NF6X> Hmm. revE, maybe? 🙂
<whitequark>
yeah
<whitequark>
that one will be able to do what you want
<d1b2>
<NF6X> I would like to participate in that industry!
<whitequark>
cyborg_ar: we call those "addons", and yes
<d1b2>
<NF6X> For reference, I'm a PCB designer first and foremost, and I'd rather lay out a board than hand-wire an interface. One of my OCDish personality quirks.
<cyborg_ar>
i wonder if a couple of threaded holes could be added to the case design to allow for bolting things on
<cyborg_ar>
so addons could be mechanically robust
<d1b2>
<NF6X> If not on the official case, then maybe on home-made printed cases.
<cyborg_ar>
yeah i do plan to experiment with printing my own case(s)
<whitequark>
cyborg_ar: revE will use SYZYGY mechanical spec, which has that
<whitequark>
revABCD focused on hand-wiring stuff first and foremost
<electronic_eel>
cyborg_ar: hmm, the board and case is quite small, easily toppled by a thick usb cable
<whitequark>
also tht
<electronic_eel>
Attie did his can addon as an external board, connected with a ribbon cable. so he could fit all the connector options
<cyborg_ar>
hmm
<cyborg_ar>
yeah ribbon is probably the best
<electronic_eel>
for stuff like cpld extenders i would expect something similar
<whitequark>
(revE will have an option to use revCD level shifters on top of SYZYGY, for compatibility)
<cyborg_ar>
how much power can an addon pull from glasgow?
<d1b2>
<NF6X> What is the SYZYGY spec?
<electronic_eel>
cyborg_ar: 150 mA is guaranteed, but up to about 350 mA usually works
<cyborg_ar>
ahh... well there goes my concept for a hotdog cooking addon
<d1b2>
<NF6X> If/when I make a scsi addon, I think it may need external power if it's going to supply TERMPWR. That's supposed to be up to 900mA at 5V.
<cyborg_ar>
i guess that is one good thing about using USB... the exterial power for an addon can just be another usbc cable
<sorear>
if you split the SCSI or Pertec interface between 2/4 FPGAs, what would the interface between the FPGAs have to look like?
<d1b2>
<NF6X> True.
<sorear>
would you need a fat bundle of wires with as little as possible adding latency, could you get by with just clock synchronization, or somewhere in between?
<cyborg_ar>
i could see a small pelican case with a small powered hub, the glasgow and a bunch of addons and wires
<d1b2>
<NF6X> Not sure yet. The interface is 51 unidirectional single-function I/Os, and I haven't implemented the bus before.
<electronic_eel>
sorear: i guess you need the actual clock and some kind of bigger framing to sync multiple fpgas
<d1b2>
<NF6X> Ah, so SYZYGY is conceptually kind of like FMC, but with a friendlier connector? I've laid out boards with FMC before. It's... challenging for the home player.
<sorear>
each glasgow gets its own bulk data interface, so you can ship a horizontal slice of a request to each board and then just have a "starter pistol". maybe.
<electronic_eel>
sorear: maybe something like 8b10b?
<whitequark>
so i'm not actually going to use SYZYGY as a whole, but i am going to reuse their mechanical and electrical work
<d1b2>
<NF6X> Really, Pertec might be better served with a dedicated board. I just naturally see this shiny new Glasgow and start thinking about whether I can apply it to the worst-case things on my mental stack.
<whitequark>
sorear: yes that was the original idea, use SYNC as a trigger
<whitequark>
i think i overestimated how viable that would be
<cyborg_ar>
what is sync electrically? open drain?
<whitequark>
yes
<d1b2>
<NF6X> If anybody is idly curious, here's a summary of the Pertec formatted magtape interface: http://www.sydex.com/pertec.html
<sorear>
I don't think we really know yet how viable SYNC is or isn't
<whitequark>
yes, that's what i meant. i was certain it's viable, and i should not have been
<electronic_eel>
someone should test it out and when it doesn't work we can improve it for revD
<electronic_eel>
2 glasgow revD would be nice for wide parallel busses or parallel flash
<whitequark>
i think a single revD will handle almost any parallel flash well
<cyborg_ar>
whitequark: i can only see it working for simple things where both halves dont need to talk to eachother in the gateware level. ie simple enough or slow enough that the software can close the loop
<whitequark>
yes, you might need a shift register for really large 16-bit flash
<electronic_eel>
whitequark: tssop56?
<whitequark>
but if e.g. low 8 address bits are directly connected, the slowdown from the shift register is minimal
<cyborg_ar>
or things that can be naturally be divided in two halves
<whitequark>
cyborg_ar: yes, that was the extent of what it would be used for
<whitequark>
synchronized sampling for wide LA
<whitequark>
stuff like that
<electronic_eel>
ok, but that means you always need a dedicated addon with shift registers and whatnot. would be nice to be able to directly hook it up
<cyborg_ar>
i wonder what the timing uncertainty is compared to say, USB timings
<whitequark>
electronic_eel: do you really feel like manually connecting 56 wires is "nice"?
<cyborg_ar>
lol yea
<electronic_eel>
no, one big zif socket where you plug in an adapter
<whitequark>
otherwise you need a socket, and if you have a socket, just throw a few registers
<cyborg_ar>
if anything i kinda would like to have an addon that has a socket
<cyborg_ar>
yea
<whitequark>
a big zif socket that directly goes to glasgow pins won't work
<d1b2>
<NF6X> If sync works well for just a wider logic analyzer application, that'll be nice.
<whitequark>
you have to provide power and that changes depending on the package
<electronic_eel>
the adapter without shift regs can easily be bought
<whitequark>
also you still have to adapt it to the addon mechanical specs
<electronic_eel>
for power you use either jumpers or some fets that you build into it once
<cyborg_ar>
one with is not too far a step ahead, and you can even solder in headers in the right spot so you can just plug it on top of the board
<cyborg_ar>
look ma no wires
<whitequark>
electronic_eel: now you have a specialized adapter with more steps
<electronic_eel>
no, not specialized. you can plug anything into it from 8 pin eeprom to 56 pin parallel flash
<electronic_eel>
config is via software or jumpers
<whitequark>
ah, i see now what you're going for
<whitequark>
that's why i RE'd the ATF
<electronic_eel>
and not kicad and pcb manufacturing
<cyborg_ar>
but pcbs are so easy and cheap now
<electronic_eel>
problem with the ATF is that it is just 3.3 to 5v, not 1.8v
<whitequark>
there's the BE version...
<sorear>
my first impression of the pertec thing is that it could be made to work with a single sync line
<electronic_eel>
cyborg_ar: but pcbs need to be created and shipped. what if i want to adapt something today?
<d1b2>
<NF6X> Has anybody made something akin to a reference design using that CPLD on an addon yet?
<whitequark>
there is no toolchain yet
<sorear>
lot of details to work out and the sw architecture at this time is nonexistent
<whitequark>
electronic_eel: personally, i feel like parallel stuff by this point is legacy, so interfacing to it with dedicated addons is fine
<cyborg_ar>
we are back to wiring 56 things by hand
<whitequark>
glasgow is geared towards serial, low pin count interfaces, and that's intentional
<whitequark>
it still tries to support the old stuff well! it's just less of a focus
<cyborg_ar>
yeah tbh i dont mind it, specially if having to build a lot more front end would increase the price/size significantly
<cyborg_ar>
i like how pocketable and reasonably priced it is right now
<whitequark>
it would, especially the size
<d1b2>
<NF6X> I plan to almost entirely misuse Glasgow for old-timey obsolete stuff. 🙂
<cyborg_ar>
me too
<whitequark>
NF6X: well, it's not misuse, as you can conclude from the fact that it natively supports TTL
<cyborg_ar>
i will probably make a giant box with port expanders
<whitequark>
it just requires more steps than the modern stuff
<cyborg_ar>
i dont think there is really a way to misuse that board
<whitequark>
ha
<cyborg_ar>
:P
<cyborg_ar>
that could be a contest once the boards ship
<cyborg_ar>
find the most cursed way to use a glasgow
<cyborg_ar>
winner gets a copy of the JTAG specs
<d1b2>
<NF6X> My first exposure to Glasgow was when the floppy interface example came up in discussion of floppy imaging hardware in a retrocomputing Discord, and then the UNRE interview made me look at it in detail yesterday.
<electronic_eel>
cyborg_ar: whitequark is a master in stumbling upon cursed stuff. just read her twitter a bit
<cyborg_ar>
i do
<sorear>
also none of the Pertec pins have timing tighter than 200 ns, so you could have an expansion board that does N:1 muxing
<cyborg_ar>
ah yeah i wonder if using those analog fet muxes would work, 8 bitsX8, 64 IOs
<whitequark>
UNRE interview?
<cyborg_ar>
hmm not at the same time tho
<whitequark>
cyborg_ar: of the 1149.7 spec, specifically
<whitequark>
(this is a form of revenge)
<cyborg_ar>
i think it should be a thing, maybe hackaday would host it
<cyborg_ar>
figure out the most messed up way to use a glasgow
<cyborg_ar>
a lot of things would be gadgets people traditionally used parallel ports for
<d1b2>
<j4cbo> re: USB serial being a disaster: network-over-USB is also a disaster
<cyborg_ar>
parallel does have 17 ios though
<whitequark>
yes, it took them three attempts to stop making Ethernet worse
<whitequark>
just like it took them three attempts to stop making SCSI worse
<cyborg_ar>
i guess if you use the sync pin you get your 17th pin
<whitequark>
(four if you count RNDIS)
<d1b2>
<NF6X> Hmm, I hadn't thought of overloading sync with a flywire to an addon. And here I was eying the differential headers.
<d1b2>
<j4cbo> ECM, EEM, NCM?
<cyborg_ar>
i mean otherwise how am i gonna connect my dot matrix printer to the glasgow
<whitequark>
j4cbo: yeah
<whitequark>
cyborg_ar: that probably doesn't need all of the pins?
<d1b2>
<NF6X> I want a proper drum or chain printer, or at least band printer, but I'd hook it to my VAX-11/730. 🙂
<cyborg_ar>
iirc it does, since all the signaling happens through dedicated pins
<cyborg_ar>
there is one for out of paper
<electronic_eel>
wasn't there something for "printer on fire" too?
<d1b2>
<j4cbo> i recently discovered that somewhere along the line MS started shipping an NCM driver out-of-the-box (sort of, it only loads if you have their special weird windows USB descriptors)
<d1b2>
<j4cbo> so it's finally possible to make a device that works out-of-the-box on win/mac/linux without weird "sometimes it's RNDIS, sometimes it's ECM" trickery
<cyborg_ar>
printer on fire i think is when all the status bits are set
<sorear>
I think in the terminology of this conversation I'm talking about shift registers, not muxes
<cyborg_ar>
another silly addon would be an ISA interface, probably possible with the CPLD
<whitequark>
td-linux was making an ISA-to-LPC adapter
<cyborg_ar>
or just some simple muxes
<whitequark>
and any glasgow can implement LPC
<cyborg_ar>
ooh
<cyborg_ar>
yeah that's cleaner
<sorear>
so you could have an addon with 8 8bit 5V shift registers and do pertec with that (5 Msps on the external side, 40 Msps on the glasgow side)
<cyborg_ar>
another protocol that fits exactly on the glasgow is GPIB
<cyborg_ar>
16 ios
<cyborg_ar>
5 volts with good fanout
<whitequark>
yeah
egg|laptop|egg has joined #glasgow
<cyborg_ar>
another fun one would be USB... might be possible to keep up with 1.1 full speed in theory
<whitequark>
i dispute that it would be 'fun'
<cyborg_ar>
ah yeah the opposite of that
<cyborg_ar>
it is quite the well packed can of worms
<sorear>
you might imagine that "do we actually need the fx2 or can we bitbang usb" has been discussed to death and beyond here
<kmc>
lol
<cyborg_ar>
well no
<cyborg_ar>
im talking about usb 1.1
<cyborg_ar>
the fx2 is a pipe from usb2
<kmc>
my old tek scope has GPIB... I might play with that with Glasgow :)
<kmc>
just need some plug/adapter
<d1b2>
<NF6X> I'd call it more of a swollen can of worms. Probably botulism inside.
<cyborg_ar>
i have the connector PN
<kmc>
btw I was wondering, is it the case that all I/O voltage sense, change, pull up/down etc. requests are initiated from the FX2? or can the FPGA control these things directly
<whitequark>
technically it can but then you have multi-initiator i2c
<whitequark>
so i would strongly prefer not to
<kmc>
right
<whitequark>
that would also make applets a *lot* harder to write without some more abstraction
<whitequark>
ie they would get non-portable from revC to revD
<kmc>
why is that exactly?
<kmc>
is there a list of expected changes from revC to revD?
<whitequark>
or even between revC1 to revC2
<whitequark>
changes in I2C topology and parts
<whitequark>
revD doesn't exist yet
<whitequark>
but in general, I2C topology is considered an implementation detail
<electronic_eel>
revD will most probably have an i2c mux for multiple separated internal i2c busses
<whitequark>
i think there's no other option than the i2c mux
<cyborg_ar>
oooh i thought the fx2 was only a pipe to the fpga. so the i2c stuff is connected directly to the fx2?
<whitequark>
yes, the fx2 has dedicated i2c pins anyway
<cyborg_ar>
ahh i see. makes sense to not waste gateware on an i2c controller just for board supportr
<sorear>
no other option because the i2c parts don't have enough straps to give them 4 non-conflicting addresses?
<cyborg_ar>
does reduce the flexibility slightly
<kmc>
cyborg_ar: ty
<cyborg_ar>
that should plug straight into your scope
<cyborg_ar>
fx2 is an amazing interface chip i am glad Someone Else is programming the firmware for :P
<kmc>
aiui, voltage requests, pull-up/down requests etc. go from client-side code to the FX2 to the I2C bus
<kmc>
this does limit what glasgow can do as a standalone device
<d1b2>
<NF6X> The idea that Someone Else has abstracted the USB stuff between FPGA gates and Python code is a lot of the appeal for me. I've had many abortive attempts at making hardware only to run out of steam on the USB yak shaving.
<kmc>
I think even mirroring DUT I/O voltage is not possible without a computer connected?
<kmc>
yeah
<cyborg_ar>
yeah, i guess those are meant more to be initialize the board
<electronic_eel>
the firmware of the fx2 can work alone, without usb connection
<kmc>
it should also mean an easier upgrade path to USB 3 or Ethernet
<electronic_eel>
you'd have to configure it for that of course
<cyborg_ar>
if you need a switchable pullup as part of the protocol you may wanna use an IO pin for that
<d1b2>
<NF6X> Can't wait for Ethernet and 128 I/O channels... /me ducks behind sofa
<cyborg_ar>
ethernet would be sweet
<cyborg_ar>
probably the cheapest way to have high speed isolated io
<cyborg_ar>
good for interfacing with industrial shite
<d1b2>
<NF6X> Might even power it (optionally) with PoE?
<whitequark>
i'm starting to feel we need a FAQ
<d1b2>
<NF6X> Oooh, a 24VDC isolated addon interface card could make Glasgow handy for some pseudo-industrial applications.
<cyborg_ar>
yeah, when questions get asked frequently
<d1b2>
<NF6X> So, when can I bulk order Glasgows on Amazon at work? 🙂
<sorear>
besides parallel eeproms and the pertec tape interface, what could you do with an addon board that provides a bunch of 5V unidirectional shift registers? should such an addon exist? is there any change that would make it significantly more useful without ballooning the price?
<whitequark>
also unlike amazon mouser doesn't have grossly exploitative labor practices (that i know of)
<cyborg_ar>
mouser has been pretty good to me when i used them
<cyborg_ar>
specially the entire time digikey has been hopelessly broken
<cyborg_ar>
pissed me off enough i do all my orders through mouser first now
<d1b2>
<NF6X> I'd have to give a lot of thought to how much pain using shift registers with Pertec would be. Sure, fastest time scales are like 200ns, but every wire is kind of an interrrupt and latch trigger, and there are no wait states. The tape moves, and the interface must deal with it.
<sorear>
I'm imagining that there would be a python library abstracting that, so you write your applet in a 5MHz clock domain with access to all wires, and things are serialized for you
<whitequark>
NF6X: i haven't read your link, but just going from the backlog: isn't sorear's idea basically to time-division multiplex the bus? in that case you would start with demultiplexing it inside the FPGA and treat it as a wide one
<d1b2>
<NF6X> At the physical level, it's a 51-signal asynchronous interface with no clock reference and no possibility of wait states.
<whitequark>
sorear: oh, so far i haven't used abstractions for that because eg the PROM applet only multiplexes the address bus; so it uses ready/busy signaling explicitly
<whitequark>
an abstraction may or may not be in order but i think the first few applets should probably just do it directly
<whitequark>
also it would not be a 5 MHz clock domain
<whitequark>
it probably should use enables to work at an integer divisor of 48 MHz
<d1b2>
<NF6X> Right. Anything with wait states, interlocked handshaking, etc. will be a lot easier. Pertec formatted interface is an interesting thought experiment, even if it's a bad match for Glasgow.
<whitequark>
so, more of a control domain
<whitequark>
NF6X: is that unidirectional?
<sorear>
according to NF6X's link the fastest strobe has a minimum time of 200 ns, so if you're forcing everything violently onto a single clock it must be at least 5 MHz
<d1b2>
<NF6X> Yes. roughly half of the wires going in each direction.
<whitequark>
sorear: 6 MHz, then
<whitequark>
since that's a 1:8 fraction of 48 MHz
<whitequark>
(if you can live without a PLL, just leave PLLs alone)
<d1b2>
<NF6X> And it's entirely asynchronous, and determined by how fast the tape is moving. 6,250 characters per inch at 100 inches per second or more is in-scope.
<whitequark>
NF6X: ok, so it is bidirectional
<whitequark>
(at the interface level, not wire level)
<d1b2>
<NF6X> Right. It's for reading and writing, from an era where everything was discrete logic.
<cyborg_ar>
anyone knows from the top of their head how much RAM the FPGA has?
<sorear>
16 kB
<whitequark>
then i do not entirely understand sorear's proposal
<whitequark>
i thought it is unidirectional and there would be 8 latch signals and 8 data signals
<sorear>
there are 8 data signals, a valid strobe, and a bunch of random things in each direction
<whitequark>
sorry, i meant the interface between the glasgow and the adapter board
<d1b2>
<NF6X> 9 data signals, in each direction. Corresponding directly to the 9 parallel tracks on the tape.
<d1b2>
<NF6X> (sorry, I'm talking magtape)
<sorear>
the strobe is asserted for a minimum of 200 ns and the data must already be valid, so if you blindly sample everything at 6 MHz you're guaranteed to see the strobe as 1 and the data simultaneously valid on at least one clock
<sorear>
presumably followed by a strobe=0 clock before the next bit, although I didn't see anything explicit on fall-to-rise time
<d1b2>
<NF6X> (magtape context) all of those random things are interrupts tied to physical things, like an unlatched strobe as a physical end-of-tape marker whizzes by.
<d1b2>
<NF6X> Most of those 51 wires aren't strobed; they are strobes.
<sorear>
my proposal is to make something as dumb and generic as possible, to improve the "I found this in the trash, can I talk to it without making a bespoke PCB" UX
<whitequark>
that's... literally what i reverse-engineered the CPLD for
<d1b2>
<NF6X> 🙂
<whitequark>
it's like the glasgow approach to not having enough pins on the glasgow
<d1b2>
<NF6X> It's glasgows all the way down?
<sorear>
right, yes
<cyborg_ar>
whitequark: i had a quick look at those cplds, the are interesting, not cheap, not expensive. an open toolchain would definitely make them a lot more useful
<sorear>
the SYNC approach has the best UX (you need to stock glasgows, and cables) but technical limitations
<whitequark>
cyborg_ar: someone who is good at hand-drawing (no EDA) circuit diagrams should help me complete the last part of the documentation then
<d1b2>
<NF6X> Just to be clear, I'm not necessarily presenting Pertec magtape interface as something Glasgow should do. It's more of a thought experiment for something very old, conceptually different from most newer stuff, but maybe in-scope because it's not so old to be >5V logic.
<cyborg_ar>
would this go through the yosis/nextpnr rube goldberg machine or be something simpler?
<whitequark>
yosys/nextpnr is what makes glasgow possible in first place! you should be more respectful to it.
<whitequark>
now vendor toolchains, yes
<cyborg_ar>
whitequark: what needs to be done? i do have some drafting experience but dunno what exactly is needed
<whitequark>
like the pile of crap that no longer runs *even on windows* that microchip provides you for programming these CPLDs, yes, very much a rube goldberg machine
GNUmoon2 has quit [Ping timeout: 240 seconds]
<d1b2>
<NF6X> Once we get tired of Pertec, I can move on to bus&tag interfaces, and the conceptually similar SMD hard drive interfaces from the 70s/80s.
<whitequark>
i've briefly considered reverse-engineering it but it was actually *far* easier to treat it as a black box
<whitequark>
a very buggy black box that required lots of live silicon testing to figure out how the broken fuse maps it outputs actually function
<sorear>
what I'm trying to avoid here is "there are 50 different addon boards designed for a single application each, and the chances of you having the one you need for a given project are low"
<d1b2>
<NF6X> Thank you for taking that CPLD bullet for us.
<whitequark>
at one point i had to use a SAT solver to figure out the last few bits in the macrocell
<cyborg_ar>
lol wasnt meaning it in a disrespectful way. it's just a complicated thing because fpgas are complicated. cplds usually cannot do more than combinatory logic with some flipflops sprinkled onm
<whitequark>
cyborg_ar: FPGAs are actually a lot simpler than CPLDs in... most ways really
<d1b2>
<NF6X> I love the concept of one addon to rule them all. And in my >50 years, every time I've tried it or seen somebody else tried it, it ended in tears. 🙂
<cyborg_ar>
i stand corrected
<cyborg_ar>
speaking out of my ass
<whitequark>
the one particular way in which FPGAs are harder is that they're big
<whitequark>
building big CPLDs means wasting uneconomical amounts of silicon
<d1b2>
<NF6X> Big, but largely zillions of copies of the same simple things, right?
<whitequark>
yes.
<sorear>
at a very high level what are the CPLD's capabilities? is it programmable multiple times? IO is always 5V / no pulls? Per-IO direction control at runtime or only in the bitstream? Max speed?
<whitequark>
sure, on the high end, you can find things get somewhat more complex
<d1b2>
<NF6X> Oh, heck yea. But the Lattice architecture looks nice and simple, watching from the bleachers as I am.
<whitequark>
but a small CPLD's macrocell is already comparable in complexity to a mid-range FPGA
<cyborg_ar>
so cplds are small amount of complicated cells, vs mass scale of simple cells?
<whitequark>
and since you have fewer of them, synthesis and pnr for CPLD is way harder
<whitequark>
yes.
<whitequark>
CPLDs also use sum-of-products for combinatorial logic, which introduces its own issues
<whitequark>
like not being able to efficiently xor
<kmc>
whereas FPGAs are LUT based and can implement all truth tables equally well?
<whitequark>
seriously, computing 8-bit parity is like the worst nightmare for a CPLD, as far as i've seen so far
<whitequark>
(some of them have dedicated XOR logic...)
<whitequark>
kmc: yes
<kmc>
so why are CPLDs designed the way they are
<whitequark>
kmc: that started with PLDs (which we now call SPLDs), also known as GALs/PALs
<whitequark>
these were basically "i need a 74xx chip, and i want to stock only one for any xx"
<whitequark>
the first PLDs did not have the ability to have buried function
<whitequark>
ie all state was always exposed on pins
<whitequark>
you could trivially program them manually using pencil and paper
<whitequark>
then they got larger, then CPLDs arrived which were basically several PLDs glued together
<sorear>
i feel like my answer to any tech question is "path dependency and allometric scaling"
<whitequark>
the problem is that the simplicity of PLDs doesn't scale
<whitequark>
microchip stopped making the largest ATF devices because the silicon just got inordinately fucking huge
<whitequark>
some of them were probably not even made as engineering samples
<d1b2>
<NF6X> So, if I want to make an add-on board that has parity logic on it for something like scsi-2, would I be better off putting another small Lattice FPGA on it instead of a CPLD?
<whitequark>
like the 16 logic block version actually does not have a toolchain that I could find (there probably are some on old CD-ROMs or w/e) and the 32 logic block version has probably never existed as silicon ever
<whitequark>
this happens because the interconnect scales quadratically
<d1b2>
<NF6X> In hindsight, would it be better to just go back in time and not reverse engineer the CPLD, and just stick another cheap FPGA on an addon as needed?
<whitequark>
NF6X: for fixed function addons there are lots of options
<whitequark>
however, if you want bidirectional pins and 5V and individual direction control, there are few
<whitequark>
you could place a lot of SN74LVC1T45 devices on the board like glasgow itself does
<whitequark>
but this has quite massive cost at large pin counts
<whitequark>
the CPLDs are very cheap and they support 5V directly
<d1b2>
<NF6X> I think that most of the things I have in mind that might need I/O expansion would likely be fixed function, and don't necessarily need dynamic reconfiguration. Like, maybe use Glasgow to program a configuration PROM on the addon one time.
<whitequark>
NF6X: re parity logic, with good toolchain support, XOR can be done on ATF15xx
<whitequark>
my point is that XOR is inherently hard in SOP architecture
<whitequark>
not that it is impractical in this specific case
<sorear>
are the ATF devices PROM or SRAM?
<whitequark>
yes.
<d1b2>
<NF6X> Flash based, right?
<whitequark>
ATF15xxAS(V) versions are Flash, ATF15xxBE are Flash+SRAM
<whitequark>
and yes, you can reprogram the BE parts live
<sorear>
so you could keep an addon in your bag and not have to replace it every time you want to change the mux rules
<d1b2>
<NF6X> Ah, so the BE parts are SRAM-based with built in config ROM, essentially?
<whitequark>
sorear: it would probably be fully integrated in the flow the way the FPGA currently is
<electronic_eel>
you could also reflash it like 1000 times or something before the flash wears out
<whitequark>
NF6X: yes. sadly, you can only them in one wafer increments
<whitequark>
electronic_eel: no, they *guarantee* 1000 times
<whitequark>
well, a lot more than that actually
<whitequark>
i think it's 10k
<whitequark>
ah, wait
<whitequark>
the datasheet actually states 100 times because they do not test/guarantee this parameter
<whitequark>
there was an appnote about it somewhere, where they say that they use normal flash that has something like 10k cycles you would expect, but the datasheets say it's 100 as a CYA
<whitequark>
we should probably run flash wearout experiments
<kmc>
the 32 logic block version has probably never existed as silicon ever <-- what, so they gave it a catalog number out of wishful thinking, and then if someone says "we want to buy a million of these" then they'll figure out how to make it, and just how terrible the yield/price is?
<d1b2>
<NF6X> You may safely consider a lot of what I will talk about to be somewhat out-of-scope for generic addons, because much of what I care about would be single-purpose addons if for no other reason than avoiding hand-wiring specific interfaces.
<electronic_eel>
hmm, but probably a 1000 times is realistic with these old processes. you can read out the flash via jtag, right? so we would read out, check if changed and only flash on change
<whitequark>
electronic_eel: yes, of course that would happen
<sorear>
the actel^W microsemi^W microchip flash FPGAs have about 100 write cycles, but I assumed that was mostly because with flash cells directly connected to the LUTs, you can't do any ECC
<sorear>
so your part is dead as soon as *any* flash cell wears out
<whitequark>
you don't normally do ECC on NOR flash
<whitequark>
and you don't normally put data you care about in NAND flash
<whitequark>
like bitstream
<whitequark>
kmc: yes, precisely correct
<electronic_eel>
says whitequark today. tomorrow vendors decide to implement exactly that
<whitequark>
kmc: the datasheet said "preliminary data" and then the newer datasheet pretends it never existed
<whitequark>
someone might have actually asked and they decided they just never ever want to sell those
<d1b2>
<NF6X> specifically to spite whitequark
<sorear>
does it exist more or less than ecp4 and hx16k
<whitequark>
i don't know. you could probably ask microchip
<whitequark>
just email your FAE
<d1b2>
<daveshah> ecp4 did ship samples, I remember finding a mailing list post somewhere from someone who had them
<d1b2>
<daveshah> and you can still download the tools for it today!
<whitequark>
although i'm told that it has to be an "Atmel part of Microchip" FAE, not just any
<whitequark>
ok, then ATF1532SE exists less than ECP4; i have never found any indication that either the silicon or the toolchain existed
<whitequark>
actually wait
<sorear>
actel vs atmel is confusing
<sorear>
is there an atmeb
<whitequark>
sorry, ATF1532AE
<whitequark>
the SE was later
<whitequark>
ATF1516AE/SE may have existed at one point but i could not find any remnants of the toolchain
<whitequark>
the toolchain only exists for 1502, 1504, and 1508
<sorear>
which size would the glasgow addon board use? (which has the best cost per IO?)
<whitequark>
there are some official microchip distributors that claim they can sell you ATF1516AE ("contact sales")
<whitequark>
whether that is actually true is unknown. they may have lost them, or they may have actually some early 2000s chips in a warehouse somewhere
<whitequark>
i have absolutely no idea how you would program them
<whitequark>
i imagine microchip would also be interested what the fuck do you need them for
<whitequark>
sorear: idk, never went that far
<whitequark>
if you use the BEs, you actually have to order them in increments of one wafer size
<whitequark>
since they will only manufacture them on demand
<sorear>
is that realistic? are we talking 100s or 10000s
<electronic_eel>
so we can practially forget BE for glasgow addons
<whitequark>
no
<d1b2>
<daveshah> Probably they've stored wafers and package on demand
<cyborg_ar>
yeah i dont think they would tool a line for 1 wafer
<cyborg_ar>
but they will take a wafer out to package
<cyborg_ar>
i get the same with some LEDs
<whitequark>
it's possible
<cyborg_ar>
they will only sell to you if you buy like a wafer worth of them, they have them in storage and they are not taped until you buy
<whitequark>
the lead time is so high that i believe they actually manufacture the wafer on demand
<electronic_eel>
hmm, maybe because the packages corrode with time, so you can just store packaged parts like 2 years. but the wafer can be stored longer
<whitequark>
electronic_eel: no, this is microchip direct
<cyborg_ar>
yep
<whitequark>
it's for shit people mostly don't need
<cyborg_ar>
that is the case with LEDs
<sorear>
we have an optimistic demand for O(1000) of these, ignoring the obvious risk problems would that cover a wafer
<cyborg_ar>
also for parts on tape, the tape goes bad
<whitequark>
sorear: its multiples of 160 for ATF1502BE
<whitequark>
and they cost $1.79 per part
<sorear>
oh
<whitequark>
this is just 300 bucks for one order, the only limitation is that you need a business account
<electronic_eel>
ok, esden can take care of that
<kmc>
I think I'm missing context for why this weirdo Microchip part is the best way to make an expansion board for Glasgow
<whitequark>
fun fact: ATF15xxAS still uses the original line from late 90s
<whitequark>
they don't have anything else they can make on it
<whitequark>
and they are still using the 1999 datecode masks
<eddyb>
oh I misread as "they don't have anything else they can make it on"
<sorear>
it's one of very few native 5V CPLDs/FPGAs still in production
<eddyb>
that's just swapping the last two words isn't it
<whitequark>
it's the last one period
<electronic_eel>
kmc: because there is literally nothing else that can natually do push/pull 5v
<kmc>
oh, 5V
<sorear>
you can get other things NOS
<whitequark>
everything else is EOL, microchip effectively owns the market in 5V CPLDs
<whitequark>
this is why mouser still has regular shipments of thousands of the AS devices
* eddyb
stares at Skywater - could that do it?
<whitequark>
in fact, again based on some questions i got forwarded to a FAE, microchip thinks this is a promising CPLD line and they do not plan to EOL it any time soon
<cyborg_ar>
i guess if you dont need much, greenpaks work from 1.8 to 5v natively
<whitequark>
which is kind of a bizarre thing to hear in 2020 but here we are
<kmc>
and using 5V saves the complexity and expense of level shifters on every pin like the base Glasgow board has?
<sorear>
is there any reason _to_ use the BEs in glasgow? you have plenty of flash on the main board and initialization is a software problem
<whitequark>
eddyb: does that have flash
<sorear>
$300 and a business account are eminently solvable problems, but if there's no use there's no use
<whitequark>
that said, for skywater you would have to redesign the CPLD completely
<cyborg_ar>
GP5 is OTP, but can be overwritten through I2C
<cyborg_ar>
they did make a flash part but i havent used it yet
<eddyb>
whitequark: oh I must've missed that part of the conversation, sorry. there might be an OpenFlash design effort, but not for the first shuttle run I don't think?
<whitequark>
the original AE/SE/AS version is all hand laid out for that specific process
<eddyb>
or maybe someone will try to characterize some stuff? not in the loop enough to know for sure
<whitequark>
they had to redo the chip entirely for BE
<whitequark>
which is also why BE is a SRAM CPLD
<electronic_eel>
if you'd use skywater, you wouldn't have to design an cpld or fpga with flash, but just a fixed but properly arranged shift register
<sorear>
ignore last question, I misremembered what the options are
<whitequark>
electronic_eel: cyborg_ar: i was surprised to learn that some vendors will make exactly as many wafers as you order and no more
<eddyb>
I'm just amused at the thought of even vague potential opensource competition to Microchip in a niche but apparently lucrative product segment?
<whitequark>
there was some vendor, renesas i think?, which has a microcontroller line which is actually fused per-customer before packaging, and they also make all wafers to order, too
<whitequark>
if that sounds insane to you, well, it is not a good microcontroller line
<electronic_eel>
what i just don't know if the skywater process allows 5v
<sorear>
microcontrollers with mask rom are historically very normal
<whitequark>
you have to deal with stuff like gcc with AES decryption in the frontend
<hl>
whitequark: what the FUCK
<whitequark>
sorear: no, it has flash, the fuses are for the debug interface
<hl>
gcc with AES decryption?
<apo>
whitequark: wot
<eddyb>
electronic_eel: same, I was hoping it's just old enough to do 5V, but maybe not
<eddyb>
whitequark: okay I was gonna ask if at least the fuses are for some kind of hardware crypto, but wat
<sorear>
electronic_eel: there was a thing a while ago with x-fab supporting open tools on their 40V-compatible process
<whitequark>
hl: apo: that is one of the least insane parts of the whole thing
<cyborg_ar>
it can do 5v IO
<cyborg_ar>
skywater
<eddyb>
decryption? in frontend? I was expecting encryption in backend!
<cyborg_ar>
internally it runs 1.8
<hl>
whitequark: decrypting what?
<whitequark>
the chip support package and libraries
<eddyb>
cyborg_ar: ah! that rings a bell
<hl>
lolol what the _fuck_
<hl>
whitequark: and if you demand GPL source?
<d1b2>
<daveshah> I'm waiting for the first vendor to add AES decryption to Yosys
<electronic_eel>
cyborg_ar: so they have 1.8v to 5v shifters internally and a 1.8v vreg?
<whitequark>
you might ask "but how do i debug it", and the answer is that fuck you
<d1b2>
<NF6X> ISTR needing a key dongle for the compiler for Tensilica CPUs back in the 00s, even though it was GCC-derived?
<whitequark>
hl: you have to sign an NDA before they even give you a product brief
<cyborg_ar>
i think its the cell library
<hl>
whitequark: doesn't change your rights under the GPL
<whitequark>
shrug
<cyborg_ar>
you have the fastest transistor cells to work with 1.8 volts
<hl>
i guess they're assuming nobody will dare
<whitequark>
i honestly don't care what sort of illegal shit they will do
<cyborg_ar>
and io cells that are tolerant of 5 volts
<cyborg_ar>
in theory you can do whatever structures you want
<cyborg_ar>
but you would be going off library
<whitequark>
cyborg_ar: no, 5V *tolerant* CPLDs/FPGAs are plentiful
<whitequark>
well... sort of
<d1b2>
<NF6X> I've lost track of who we're hating on at the moment. 🙂
<whitequark>
5V *native* CPLDs are not though
<cyborg_ar>
well, not tolerant. it can also do 5v output with the SKY130
<whitequark>
ah
<sorear>
I don't think you can get thicker oxide by going "off library"
<cyborg_ar>
what i dunno is if you can do an LDO for the vcore on die
<cyborg_ar>
or you need to supply the 1.8 externally
<whitequark>
i'm going to happily ignore all the skywater stuff and let someone who isn't me to build that
<eddyb>
fair
<sorear>
maybe you could hack a horizontal transistor, possibly bipolar, but I'm far from confident it's even possible
<electronic_eel>
designing an glasgow mux asic would be fun though
<sorear>
am confident it would not be a good idea
<d1b2>
<NF6X> Should I google what Skywater is, or would that just make me angry?
<cyborg_ar>
anyway if you need a small TINY 5v native part that also works perfectly at 1.8v (and that you can even configure PER PIN the input thresholds) GP5 is great
<sorear>
a year or two i predicted this was the inevitable end state of STARSHIPRAIDER
<eddyb>
NF6X: see the #asic channel on Discord :P
<cyborg_ar>
there is also dual rail GP5s that allow you to set the VIO on either side at whatever you want between 1.8 and 5v
<d1b2>
<NF6X> On my way. I have everything but the two Glasgow channels muted. The 1BitSquared Discord is a bit overwhelming. 🙂
GNUmoon2 has joined #glasgow
<whitequark>
Discord is incredibly bad
<eddyb>
oh I mute all servers by default, otherwise it gets annoying
<eddyb>
same as with Zulip, really. idk why things assume these weird defaults
<whitequark>
cyborg_ar: is that still hella slow?
<whitequark>
GP4 has like 20 MHz top frequency, optimistically
<whitequark>
sorear: please just open the datasheet already
<cyborg_ar>
also it is this annoying 0.4 mm pitch qfn package i hate
<sorear>
mk
<whitequark>
it lies about the programming model constantly, but the rest is probably truthful
<eddyb>
NF6X: besides what's in there, there's also the fact that every 3 months or so Google plans to do free shuttle runs, you just need to make your design opensource (and there's a limited number per run)
<whitequark>
ignore everything it says about the macrocell though
<cyborg_ar>
though they make some TSSOPs now i think
<whitequark>
also don't forget that ATF1500 is *not* an ATF15xx device
<whitequark>
(please don't ask)
<d1b2>
<NF6X> Do we like Skywater, hate it, or is it complicated? I'm new here. 🙂
<cyborg_ar>
lol
<eddyb>
IIRC 40 designs, about 100 chips each (they get packaged and everything)
<cyborg_ar>
we dont care about it
<cyborg_ar>
:P
<cyborg_ar>
personally, i wanna see tools mature a bit
<whitequark>
NF6X: it's a pretty nice offering from google, far more usable than CMP
<cyborg_ar>
it is potentially very exciting
<whitequark>
individuals (... who are vastly overpaid) can still afford CMP
<eddyb>
NF6X: I brought it up because it's one of the few ways some random person can make custom silicon with minimal investment
<whitequark>
but then you have to deal with lots of complexity that google here is improving a lot
<eddyb>
and the context was the dedicated production line for specifically a 5V part
<cyborg_ar>
yeah also there is this impulse to improve the open source tools for asic design
<eddyb>
and I was hoping maybe 130 was old enough to make that feasible
<cyborg_ar>
right now if you wanna design an asic your best bet is to get student access to a cadence seat
<whitequark>
eddyb: the ATF15xx parts are made on a dedicated line not because that process is uniquely suited for 5V stuff in general
<eddyb>
cyborg_ar: cynical me a few months ago said the whole free shuttle run thing is so that Google can learn from other ppl's experiments, but it's still handy to have
<whitequark>
it's because it is not portable anywhere else
<d1b2>
<NF6X> I'm way out of the loop on small-run silicon. Even when I was in the ASIC world, folks would ask me about what process I was in, and I'd respond "What do I care? I write VHDL.". 🙂
<sorear>
the datasheet is (c) 2005 and has "100% Tested" as a top line feature
<whitequark>
sorear: yes, because this is a EEPROM CPLD
<whitequark>
OTP CPLDs cannot be... for obvious reasons
<cyborg_ar>
lol
<cyborg_ar>
i like my opto22 relays
<cyborg_ar>
they are 200% tested
<cyborg_ar>
(i guess they test them twice?)
<eddyb>
whitequark: sure, I just meant that I randomly thought of "wait, could Skywater let us build an alternative", partly because I haven't come up with great usecases for Skywater130 so far
<whitequark>
фр
<whitequark>
*ah
<eddyb>
other than experimentation and tooling improvements ofc
<whitequark>
i mean i would tape out my CPU
<d1b2>
<NF6X> I'm just waiting for Chris Gammel's chip printer, and mostly to annoy Dave Jones. 🙂
<whitequark>
once it's properly done
<eddyb>
I probably would've tried to hop onto the first shuttle run if I did have some neat ideas, but then again constant burnout and software deadlines, it's unlikely I would've had the time to get far into learning the tools anyway
<whitequark>
tape out some yamaha synth chips
<eddyb>
what's the RE status on those? I haven't kept up with any of it
<d1b2>
<NF6X> I don't see myself taking on something like a Skywater design myself. I've spent most of my live at least one abstraction level above physical IC design/layout/process/library level stuff.
<d1b2>
<NF6X> I need to turn off Discord for a while. Brain's gonna explode. Later, new friends!
<TD-Linux>
I haven't worked on GlasgISA for a while. but someone recently started writing a driver for the ISA card I want to use so that hopefully will motivate me
<eddyb>
whitequark: oh I vaguely remember seeing that tweet, but somehow didn't connect the dots
<eddyb>
hmm, so I work on Rust-GPU nowadays, and also I've been trying to understand GPUs in depth, their computational models, etc. this may be silly, but now I'm wondering if something like CXXRTL could be done that leverages the full SIMD width of a GPU compute unit. seems hard to do that kind of scheduling tho, even just to estimate the theoretical best-case wins
<d1b2>
<daveshah> Something that would fit a GPU even better is running multiple copies of the same design in parallel with different test vectors
<eddyb>
yeah, might even be able to run CXXRTL output directly via Metal or OpenCL or something else that can take C++
<whitequark>
optimistic
<whitequark>
in my experience clang doesn't even use normal SIMD
<eddyb>
you don't need SIMD, you just write scalar code, and it runs in parallel with itself
<eddyb>
like, shove CXXRTL output in a shader, with many invocations. for what daveshah said, anyway
<whitequark>
oh i meant for scheduling
<eddyb>
okay yeah
<whitequark>
what daveshah wants is clearly doable although CXXRTL has a surprising amount of branching
<whitequark>
*code generated from CXXRTL
svenpeter[m]1 has joined #glasgow
<d1b2>
<daveshah> Yeah, it's probably going to fit certain designs better than others
<eddyb>
does it do different things on both paths, or just skip a bunch of side-effects?
<d1b2>
<daveshah> The use case is from ages ago, to get maximum test coverage of complex DSP decompositions (where formal isn't viable)
<d1b2>
<daveshah> It might be a good fit to similar cases like verifying FPUs
<eddyb>
I think I've convinced myself I wouldn't write anything like an FPU without formal proofs (of the Coq/Agda/Lean kind)
<eddyb>
tho I can see how if you had a design already, you might want to take this route
<whitequark>
i'd like to see you verify HDL with Coq
<eddyb>
I'd like to see anyone do anything with Coq without massive amounts of codegen infrastructure on top, (that's how RustBelt works, from what I've heard)
<cyborg_ar>
put the HDL on your Coq
<eddyb>
then again, I suppose floats are less magical to me now, given the whole APFloat porting and whatnot. just a gazillion edge cases in IEEE :(
<eddyb>
(and, yes, I know, if you try to simplify anything, you get other issues)
<eddyb>
speaking of floats and GPUs, someone brought up that GPUs (used to?) emulate e.g. 32x32 integer multiplies using 24x24 multipliers (from the FPUs)
<whitequark>
oh WTF
<whitequark>
is that why 32-bit depth buffers weren't available?
<eddyb>
didn't even consider that until I saw it brought up (mostly because I'm used to e.g. using 16x16 multipliers to do this kind of thing, it's a bit weird with the float mantissa stuff)
<eddyb>
huh I don't really know
<d1b2>
<Hardkrash> I think that what the AMD Vega stuff was about, make it 32bit so that you can double down on 16bit and have 4x at 8 bit. As the full 32bit integer performance was becoming important for GPU compute, and having 2x 16 bit was good too..
<eddyb>
and from what I know, nvidia moved to more dedicated integer ALUs at some point, so yeah, I doubt this is true anymore on current-gen
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
bvernoux has quit [Read error: Connection reset by peer]