genii has quit [Remote host closed the connection]
<rqou>
oh what
<rqou>
you can put a PNG in an SVG in a webfont
<rqou>
featureception
<rqou>
it's also nice to see that romhacking tools are the same disaster that they were a decade ago
<rqou>
oh and the _forums_
<rqou>
full of huge anime avatars and sigs
<whitequark>
do you have anything against huge anime avatars
<rqou>
avatars are usually find
<rqou>
*fine
<rqou>
sigs get annoying when the page gets too cluttered
<rqou>
although i don't think anybody can beat the old TDWTF forum's "signature guy"
<rqou>
(for those unaware, the old TDWTF forums ran some weird ancient forum software that had several known XSS vulns including in the signature. some forum members used this "cleverly" to inject a fake post below each of their real posts)
<whitequark>
bwahaha
<rqou>
there was also a trivial "log out" CSRF that annoyed the admins a lot
<rqou>
it also had "tags" that were always transmitted as a giant blob on every single page load
<rqou>
there was no limit to the number of tags that could be created
<rqou>
the tag database had to be manually reset on several occasions
<Bike>
remember when you had sigs with an image that would display the viewer's IP, like a monster with it on a sign or suchlike
<rqou>
somebody also managed to inject a rather popular tag that had a right-to-left override in it, making the rest of the tag cloud unusable
<Bike>
i thought that was magic
<rqou>
lol that was neat
<rqou>
minecraft had that at one point by accident but then mojang went and removed it
<pie_>
<rqou> you can put a PNG in an SVG in a webfont
<pie_>
what
<pie_>
meanwhile, damn i lost an important sticky note
<pie_>
no not the password one
clifford has quit [Ping timeout: 268 seconds]
clifford has joined ##openfpga
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
digshadow has quit [Ping timeout: 240 seconds]
oeuf has quit [Read error: Connection reset by peer]
<rqou>
whitequark what happened to your avatar?!
<Bike>
oh, it's
<Bike>
not "catullus", but that's funny so it's catullus
<whitequark>
Bike: what about Catulus spp
<Bike>
i don't even know what they look like
<Bike>
oh catulus is actually the title
<Bike>
remarkable
<whitequark>
Bike: wait um
<whitequark>
if you didn't know it was the title
<whitequark>
how did you arrive at "catullus"
<Bike>
i half remembered the title, or rather, completely remembered the title but not my confidence that it was the title. due to this weakness i further associated the sounds with the violent poet and not cats, and furthermore was distracted by the idea of a manga with a bunch of latin poets as catgirls
<cr1901_modern>
That is one hell of a msg
forrestv has quit [Ping timeout: 276 seconds]
<awygle>
I want to get back on Bike's wild ride
<whitequark>
Bike: you might be only drinking vodka but you don't *need* AKB-48
<Bike>
tragically i'm not drinking anything
<Bike>
the weird thing to me now is that the title is catulus syndrome, since "catulus" doesn't actually seem to have anything to do with cats
<Bike>
wikipedia's article on Gaius Lutatius Catulus actually says it means "puppy"
<whitequark>
wtf
<Bike>
which seems like a weird thing to call a naval commander, sidenote
<Bike>
i think even cu chulainn was a dog, not a puppy
<awygle>
gaius lutatius catulus in a Fate anime as a catgirl
<cr1901_modern>
No plz no more fate
<cr1901_modern>
Reminds me I need to finish Heaven's Feel sometime this century
<Bike>
as a doggirl, and her gag is yelling about proper latin like romanes eunt domus
<whitequark>
pffff
<awygle>
I still don't actually know what happens in heavens feel. I stalled out on the VN before I finished that arc, and haven't watched any of the F/SN animes
<cr1901_modern>
awygle: Same, but everyone says it's the best (read: most depressing) arc
forrestv has joined ##openfpga
<cr1901_modern>
I just... never got around to finishing it
<Bike>
anger manyu turns out to be an anonymous sin-eater produced by unit 731 during the third corrupted holy grail war
* whitequark
stares at Bike
<cr1901_modern>
Shut up Bike :P
<whitequark>
now I have to watch F/SN
<cr1901_modern>
There isn't a Heaven's Feel anime (yet)
<cr1901_modern>
And the other two arcs are meh
<Bike>
i don't think 731 is actually in it, for better or worse
<cr1901_modern>
Afaik, the whole crux of Heaven's feel is that the antagonist (your lover's grandfather) doesn't want to die and drags everyone else down w/ him in his quest to... not die
<whitequark>
Bike: also was it the one with the "19 pieces" scene
<Bike>
dunno. i haven't seen any fate things
<cr1901_modern>
But you clearly read the wiki if you know to mentio n angrya mainyu (sp)
<cr1901_modern>
that's not mentioned by name in the first 2 routes
<Bike>
over half the people i talk to regularly are into it in some form
<Bike>
including this channel, go figure
<cr1901_modern>
I was into it in 2012, and like Carnival Phantasm. That was te extent of my involvement. Now I think it's been milked too much.
<awygle>
I like fate/zero a lot
<awygle>
And some of the goofy spinoffs are fun
<Bike>
so, what, you don't want to see inkling hokusai throw down with trans da vinci
<cr1901_modern>
No, I want to see Gilgamesh get his smug face smacked. His face is very punchable.
<cr1901_modern>
awygle: How far did you get into Heaven's Feel?
<Bike>
epic of gilgamesh is also about a guy going to fairly extreme lengths to not die
<Bike>
makes you think
<awygle>
like ten minutes
<cr1901_modern>
Okay I got further than you lol
<awygle>
Grandpa Is Bugs
<cr1901_modern>
awygle: Don't give it away damnit
<cr1901_modern>
And I'm _pretty_ sure that's more than 10 mins in :P
<awygle>
I'm just inferring from the first scene
<awygle>
Lots of crawling imagery
<cr1901_modern>
Oh really?
<awygle>
I imagine Oogie Boogie from Nightmare Before Christmas
<cr1901_modern>
Well, yes. You find out later that Grandpa is Indeed Bugs and he harvests organs from random passerby to keep himself alive.
<awygle>
I should find a good vn to play, I haven't done that in a long time
<cr1901_modern>
YU-NO.
<awygle>
Not counting DDLC
<awygle>
cr1901_modern: do I need, like, a PC-98 emulator running on 32 bit mingw?
<cr1901_modern>
No, there's a Windows version
<cr1901_modern>
w/ the PC-98 soundtrack
<awygle>
Mk I'll check it out soonish
<cr1901_modern>
Yay, that's 2 ppl I've convinced to try it. Only about 1000 more :D
<cr1901_modern>
If you enjoy everything you hold dear being ripped asunder from you, you may also enjoy Muv Luv Alternative
<cr1901_modern>
(You can prob get away w/o playing the prequel, which is cute but meh)
Bike has quit [Quit: Lost terminal]
<cr1901_modern>
awygle: http://store.steampowered.com/app/802880/MuvLuv/ Actually perhaps this is easier to play/beat first compared to YU-NO. Less set up and I don't remember how I got it set up other than "it worked"
<cr1901_modern>
Both invoke a wide range of (different!) emotions...
<awygle>
you've got me feelin' emotiooons, deeper than i ever dreamed of
<cr1901_modern>
MLA invokes a sense of dread, despair, and lucidness about how things don't go according to plan. YU-NO... you just have to experience it, I can't really describe it other than "holy shit" when everything comes together.
<awygle>
there are a thousand variations of this reset supervisor and none of them make any functional difference
wpwrak has quit [Read error: Connection reset by peer]
<whitequark>
wait awygle
<whitequark>
do you have a EE degree or something
<awygle>
yes
<awygle>
well
<awygle>
berkeley is "EECS"
wpwrak has joined ##openfpga
<awygle>
why do you ask?
<whitequark>
oh you're from $FANCY_SCHOOL too
<awygle>
most of my practical engineering knowledge came from things i learned at work, but yes i went to berkeley lol
diadatp has joined ##openfpga
<whitequark>
oh you actually *worked* as an EE
<whitequark>
that explains why you're way more competent than me
<awygle>
i interned as an EE, then i worked for ~4 years as an "RF Communications Engineer" which practically meant EE, firmware, and systems engineering
<awygle>
close enough :p
<whitequark>
i just pretend to be one on IRC :P
wpwrak_ has joined ##openfpga
<whitequark>
hm shouldn't the two VCC pins in the D unit be stacked?
<awygle>
d'oh, yes, thank you
<cr1901_modern1>
>most of my practical engineering knowledge came from things i learned at work
<cr1901_modern1>
This. My experience has been "4 years of EE curriculum is not sufficient to give you the knowledge to bring a competitive product to market."
<whitequark>
i mean, it's not designed for that?
<whitequark>
bringing a competitive product to market is *so much more* than EE
wpwrak has quit [Ping timeout: 264 seconds]
<whitequark>
this is like saying that 4 years of ag cirriculum is not sufficient to give you the knowledge to run a competitive farm
<cr1901_modern1>
I meant _just_ the prerequisite EE requirements, not the business side
<whitequark>
yes
<awygle>
there's like, one main thing to learn about EE that everything else stems from, which was never even mentioned at school
<awygle>
which is "minimize loop impedance"
<whitequark>
lol
<awygle>
(it may technically have been mentioned but not in any useful way)
<awygle>
but it answers essentially every question i had, like "why do we need decoupling caps" for example
<cr1901_modern1>
awygle: How about "physics is not on your side"? :)
<whitequark>
awygle: sssweet I think I have everything I need now?
<awygle>
cr1901_modern1: wellll that's EE 201 :p
<whitequark>
do you think you can update the library in glasgow-jtag repo
<awygle>
sure
<whitequark>
kill the merged symbols too
<whitequark>
kicad seems to be able to replace symbols
<whitequark>
time to check if that works
<whitequark>
#yolo
<awygle>
whitequark: do you agree that what i have left is "cypress thermal via footprint variant" and "modified MSOP footprint for Micrel part"?
<awygle>
or am i forgetting something
* awygle
intends to knock all of this out tonight
diadatp has quit [Ping timeout: 263 seconds]
diadatp has joined ##openfpga
<cr1901_modern1>
awygle: In my core curriculum, I never learned the following things that I've had to teach myself:
<cr1901_modern1>
* Version control
<cr1901_modern1>
* PCB design (offerred as a seminar, I only went to the first of two.)
<cr1901_modern1>
* Dealing w/ CDCs on FPGA
<cr1901_modern1>
* DMA on microcontrollers/otherwise
<cr1901_modern1>
* Pipelining on CPUs (offerred in an elective, which I _did_ take)
<cr1901_modern1>
* Early/Miller effect (still don't understand the second one)
<cr1901_modern1>
* Details of any modern computer bus
<cr1901_modern1>
Did $FANCY_SCHOOL leave any of those out?
<openfpga-github>
Glasgow-JTAG/master 40a8c91 Andrew Wygle: Update local copies of as-yet-unmerged symbols
<awygle>
cr1901_modern1: we didn't really have a "core curriculum" per se, at least not for upper divs
<awygle>
i personally was not exposed to either the Early or Miller effect
<awygle>
but i didn't take anything heavily device-y
<cr1901_modern1>
Ahhh right I remember rqou saying something about that
<awygle>
i did at least learn _something_ about all the others, except maybe DMA? i already knew about that before school though so i might just not remember learning it
<whitequark>
awygle: sweet thanks
<whitequark>
could you hm also
<whitequark>
maybe add a CAT24C256WI-GT3 alias?
<whitequark>
just so we can say that 100% of them are upstream
eduardo__ has quit [Remote host closed the connection]
<whitequark>
awygle: btw you mentioned micrel
<awygle>
whitequark: on further consideration i'm not going to mess with the cypress footprint tonight unless you really need it. there just seems to be a fair amount of uncertainty on the part of the maintainer person
<whitequark>
yeah sure, it's not a big deal
<awygle>
cool
<awygle>
oh, yeah, i guess they're microchip now huh?
<whitequark>
was micrel like, known for something?
<whitequark>
this is the first time i encountered it
<whitequark>
wasn't sure if i want to use the regulator but i figured microchip wouldn't spend money on shit
<awygle>
micrel was pretty well known for regulators and other analog ics
<awygle>
they'd existed since 1978
<whitequark>
as in, known to make good ones?
<awygle>
i have only secondhand knowledge, but that's my impression yes
<whitequark>
i mean maxim is well known too.
<whitequark>
ah, good
<awygle>
a former coworker who worked in automotive spoke highly of them
<awygle>
similarly to linear
<whitequark>
much cheaper though
<awygle>
what's your beef with maxim?
<whitequark>
linear is just... page after page of perfect parts that are too expensive to use in any real design
<awygle>
no shade, i have irrational hatred of e.g. AD, just curious
<whitequark>
their battery controllers are also shit
<whitequark>
well the ones I tried
<awygle>
i've only ever used them for dirt-cheap, incredibly-low-power RF stuff
<awygle>
although i did have one experience where it was _impossible_ to replicate their dev board test results in simulation
<whitequark>
and frankly everyone i've talked to who used maxim parts has only bad things to say
<whitequark>
it's as notorious for shoddy scarce parts as linear is for excellent overpriced ones
<awygle>
i'm pretty convinced the MAX2640 can't actually be matched
<awygle>
in any useful way
<cr1901_modern>
Is it a bad time to say I like the MAX232 and their DC-DC inverters?
<awygle>
okay well, i'll update my priors on maxim for next time i'm picking parts
<cr1901_modern>
Am I a bad person for liking them?
<awygle>
this LNB board has a maxim downconverter actually
<awygle>
cr1901_modern: no. live your experience, chase your bliss
<whitequark>
i dunno, as long as you never give them to anyone else...
<awygle>
and test your products before you sell them
<awygle>
lol
<cr1901_modern>
Only one offs :). And I'd prob not use one today
<cr1901_modern>
'cept for vintage stuff
<awygle>
RS232 _is_ vintage stuff :p
<cr1901_modern>
fair
<cr1901_modern>
I've destroyed many lm2907s (freq to voltage converter) b/c I powered them with a voltage _within_ spec (12V), only to find they couldn't actually take it.
<awygle>
frequency to voltage converters are such a weird thing to exist
<cr1901_modern>
They're fun :D
<awygle>
like who had what problem that led them to that solution?
<cr1901_modern>
fan control?
<whitequark>
lol
<awygle>
in some ways i guess they're analogous to FM radio....
<whitequark>
"variable reluctance magnetic pickup" says the datasheet
<whitequark>
that part is *vintage*
<whitequark>
do they even still make it?
<awygle>
life cycle active
<whitequark>
also that's really weird, it's specified for up to 28V
<awygle>
TI makes all kinds of weird old shit
<whitequark>
are you sure you killed them with voltage and not something else?
<cr1901_modern>
whitequark: Prof asked me the same thing when I asked for advice.
<whitequark>
"Enhanced Diminishing Manufacturing Sources (DMS) Support" wtf does that mean
<whitequark>
it's an euphemism for something but not sure what
<cr1901_modern>
I then just connected it to a variable power supply, kept incrementing the voltage, a little bit after 10V a pin that should've read a voltage close to 10V started reading 0
<cr1901_modern>
then I did it again for another victim
<awygle>
it's milspeak for "people stop making things"
FabM_cave has joined ##openfpga
<azonenberg>
sounds like "we second sourced a part somebody else stopped making"
<whitequark>
oh.
digshadow has joined ##openfpga
<awygle>
"enhanced dms support" means "we will keep making this for X years", probably
<awygle>
that part's the QML variant, i think, so that makes sense
diadatp has joined ##openfpga
<cr1901_modern>
I can't actually find a date of origin for lm2907
<whitequark>
hm
<awygle>
those parts were the result of my boss saying "go find a chip on a >300 nm process"
<cr1901_modern>
Is "Variable reluctance magnetic pickup" a vintage term :P?
<whitequark>
awygle: those parts seem actually useful tho
<awygle>
mm, kind of
<awygle>
depends on what you need. like F/V converters
<whitequark>
awygle: oh btw
<whitequark>
can you explain JTAG to me?
<whitequark>
that is, why is its state machine so... sprawling
<whitequark>
i only have a fuzzy understanding of JTAG overall i guess?
<azonenberg>
whitequark: so jtag is actually a multilayered protocol
<azonenberg>
the physical layer is normally LVCMOS, voltage completely dependent on the chips involved (not specified in the standard)
* awygle
, relieved, sits back and lets azonenberg talk
<azonenberg>
Then layer 2 is the state machine, which allow you to read and write the instruction register (basically a pointer)
<azonenberg>
and data register (whatever the instruction register points to)
<azonenberg>
There can be multiple layer 3 protocols used by different data register(s)
<azonenberg>
for example "bypass" is just "spit out whatever came in"
<azonenberg>
The IEEE 1149.1 boundary scan protocol defines how to bitbang I/O pins
<azonenberg>
And you can have arbitrary application-defined protocols for flashing FPGAs etc
<whitequark>
I do understand this much
<whitequark>
but the state machine is very confusing
<awygle>
there are two important things to remember about jtag, imo. 1) it's designed to require the minimum resources _possible_ in the DUTs 2) it's a perfectly reasonable protocol for boundary scan testing that's been brutally forced into a programming application
<awygle>
i suspect the weird state machine is a consequence of 1)
<whitequark>
I can "shut up and follow it", but I don't really understand the design decisions / rationale / etc
<cr1901_modern>
Funny thing is I've never used JTAG for bscan (yet). Only programming (and created a crappy Rpi GPIO JTAG driver just to see how it worked).
<cr1901_modern>
It's like JTAG today has reversed roles
<azonenberg>
yeah i've never used bscan either
<azonenberg>
awygle: #1 indeed
<azonenberg>
also minimal pcb pin count
<azonenberg>
it's basically SPI with a different use for the CS pin
<azonenberg>
to allow better daisy chaining etc
<awygle>
shift registers are very cheap, the state machine is nicely self-starting (hold TMS high and clock five times, now you're in TLR), and i bet the control logic is very low-gate-count too
<azonenberg>
yeah it's tiny
<azonenberg>
So you dont even need a reset for it
<whitequark>
yeah I've noticed the resetless thing
<whitequark>
what's the point of Pause-IR and Pause-DR?
<azonenberg>
It's meant to allow you to freeze the device with a free-running clock
<azonenberg>
So that you dont need to have the ability to gate TCK in the tester
<azonenberg>
or possibly because the device needs time to perform some operation (never actually seen it used for this purpose)
<azonenberg>
i've pretty much never seen them used
<awygle>
that jtag master chip i linked has two modes, "gated tck" and "freerunning tck"
<awygle>
the latter uses pause-ir and pause-dr
<whitequark>
I thought Run-Test/Idle is for allowing the device to perform some operation
<whitequark>
awygle: *huh*.
<whitequark>
I suppose it makes sense if you're like...
<azonenberg>
Yes, this is if you want to freeze it in the middle of an operation
<azonenberg>
and your TCK comes from an oscillator you cant stop
<azonenberg>
or something
<whitequark>
if you have dynamic memory and you refresh it on TCK clock
<awygle>
tck might be clocking other logic, i guess
<azonenberg>
and if your tester is too slow to keep up with something and needs to wait for more data from the CPU or something
<azonenberg>
again i've never used it, i always gate tck
<whitequark>
what's the point of capture-ir?
<whitequark>
don't you load things into ir yourself?
<azonenberg>
capture is when the device loads the shreg from internally generated data
<azonenberg>
All jtag transactions are bidirectional
<whitequark>
sure but what is it used for
<azonenberg>
So for example, on coolrunner the capture data from writing the IR includes the "device is programmed" bit, the "device is locked" bit
<whitequark>
the captured ir value
<whitequark>
uhm
<azonenberg>
and a few other status tidbits
<whitequark>
but why IR
<awygle>
you can use it to figure out what devices you have in your chain, or get some status bits
<whitequark>
why is this not in DR
<azonenberg>
Because every time you write an instruction you get the current status
<awygle>
DR is variable width depending on the current value of IR
<azonenberg>
and you dont have to ask for it
<azonenberg>
awygle: no, capture data isnt used for that
<awygle>
azonenberg: i know about IDCODE lol
<azonenberg>
That's the proper way :p
<azonenberg>
if your device is too old to support IDCODE, screw you i dont want to deal with it
<azonenberg>
:P
<awygle>
whitequark: basically, the IR had to have _something_ in it, so they left it up to the device to put something useful in if they wanted to
<azonenberg>
yeah thats about right
<azonenberg>
i've seen parts that dont initialize IR, and the capture value is just the last instruction that was there
<whitequark>
ah okay
<whitequark>
that makes a lot of sense
<azonenberg>
But coolrunner, off the top of my head, does use it as a status register
<azonenberg>
whitequark: btw, are you planning to use jtaghal with glasgow?
<azonenberg>
would love to see patches for support of new devices etc
<whitequark>
azonenberg: indeed
<whitequark>
i see no reason not to, and some reasons to do it
<whitequark>
i don't like openocd, anyway
<awygle>
rqou: by the way if you're still keeping score, two of my PRs were merged today, one in ~2h and one in ~20m
* awygle
uses urjtag
<whitequark>
ew
<whitequark>
that's even more broken than openocd
<awygle>
i have some unpleasant memories associated with jtag at this point
<azonenberg>
whitequark: also, any objections to my planned migration of the custom binary wire protocol to protobuf at some point in the future?
<azonenberg>
This will make interop w/ other languages/tools easier
<whitequark>
azonenberg: have you considered flatbuffers?
<azonenberg>
whitequark: protobuf is pretty widely supported and i already have an FPGA backend in the works
<whitequark>
oh nvm
<azonenberg>
whats the benefit?
<awygle>
including "double-clocking TCK" and "custom JTAG instructions to select additional JTAG chains, leading to a JTAG chain of dynamic size"
<whitequark>
flatbuffers wont work on FPGA
<whitequark>
the benefit of flatbuffers is basically that you can use mmap instead of having to do packing/unpacking
<azonenberg>
ah ok
<azonenberg>
yeah i'm working on a streaming protobuf parser in fpga
<awygle>
see also cap'n proto
<azonenberg>
basically every clock you feed it a (for now) byte of data
<whitequark>
yeah protobuf is fine
<whitequark>
awygle: i don't like capnproto because they don't have a human-readable representation
<whitequark>
you can serialize it with a CLI tool but it's not really supported
<azonenberg>
then you get out periodic signals like "you're in field 3/6/1, value is a uint32 0xdeadbeef"
<whitequark>
flatbuffers has an officially supported json representation
<azonenberg>
etc
<awygle>
the impression i have is cap'nproto isn't as friendly but is strictly more powerful
<awygle>
because it has all that crazy RPC stuff
<azonenberg>
yeah a lot of the cool zero-packing stuff doesnt look as fpga-friendly
<whitequark>
capnproto isn't bad
<awygle>
which is awesome, but also feels like it would want to eat my entire world
<awygle>
well fellow humans, it's been real, but i need sleep so i can function tomorrow
<awygle>
night
<whitequark>
night
<azonenberg>
whitequark: i am also not opposed to creating a higher level server at some point
<azonenberg>
that supports commands like "walk chain, program device" etc
<azonenberg>
rather than the current server which is only raw layer 2 chain access
<azonenberg>
I also dont have full support for multi-device chains so i'd love a PR to implement that
<azonenberg>
those are so rare that i never bothered to implement it fully
<whitequark>
hmm
<whitequark>
are they really?
<whitequark>
any modern soc
<azonenberg>
i have my zynq configured with one set of jtag pins for the arm and one for the fpga
<whitequark>
on this board at $work we have the absolute stupidest arrangement
<azonenberg>
anyway, i detect and enumerate them but i don't pad correctly
<azonenberg>
Pretty much all of my chain access code is abstracted so it'd be drop-in
<whitequark>
there's a jtag switch
<azonenberg>
i have functions to scan IR for chip N , etc
<azonenberg>
That just assert-fail if N != 0 :p
<azonenberg>
whitequark: eeew
<azonenberg>
i've seen some chips that have internal jtag switches
<azonenberg>
also, xilinx devkits love i2c muxes
<whitequark>
it's there because there are daughterboards that also need jtag
<azonenberg>
rather than just dedicating a few more gpios to handle different buses and reduce address conflicts
<whitequark>
but there's a much better and much simpler chip that just shorts tdi and tdo
<whitequark>
and yes of course it has an i2c mux too
<whitequark>
and an openmmc controller that initializes the ethernet phy
<whitequark>
guess what we couldn't bring up for a half fucking year
<whitequark>
it also configures the power supplies (also badly)
<azonenberg>
eew
<awygle>
whitequark: oh my God I've lived this exact horror
<whitequark>
quote from sebastien: "I literally have nightmares about [board]"
<whitequark>
and by god do I understand him
<awygle>
Has anyone come up with a clever arrangement of surface mount resistors allowing you to mux in 0, 1 or 2 of the daughter boards as a load option?
<whitequark>
no, but the configuration port of the FPGA on the daughterboard can be connected to either the FTDI chip or the main FPGA via tiny 0-ohm resistors
<whitequark>
loading the bitstream from the main FPGA doesn't work and to this day no one knows why
<whitequark>
also on half the boards the resistors are in one configuration and on the other half it's the other
<awygle>
Oh man flashbacks
<whitequark>
have I mentioned the gmii clock pin routed to a non-clock-capable fpga pin by accident?
<whitequark>
not only that but due to a combination of factors the precise phase relationship of that clock matters immensely
<whitequark>
so on top of xilinx MMCME3_ADV cores that were breaking in inexplicable ways and had to be pinned down to physical location and then brute-force adjusted to have their phase relationship correct with post-routing tcl commands, you had the length of that wire
gruetzko- has joined ##openfpga
<whitequark>
running across half the board
<awygle>
if you're Y-routing JTAG all over the place watch out for double clocking TCK due to reflections
gruetzkopf has quit [Ping timeout: 264 seconds]
<whitequark>
it turned out that the only way to make MMCME3_ADV work was to specify them as PLLE2_BASE and let Vivado upgrade it to MMCME3_ADV
<whitequark>
no one figured out why
<awygle>
damn
<whitequark>
also, in the end ethernet only works with some switches and media converters and not others
<whitequark>
and no one knows why
<awygle>
Let me guess, the board is a Virtex Ultraplus or something similarly $$$ so you can't spin it
<whitequark>
bingo
<awygle>
get azonenberg in there with his crazy pcb mill
<azonenberg>
whitequark: what PHY?
<azonenberg>
one of the stupid marvell 88e1111s?
<azonenberg>
or the ti dp83867?
<whitequark>
awygle: it's an XCKU040
<whitequark>
the board costs around $10k
<awygle>
hm I'm also gonna guess... You've already shipped it to customers
<whitequark>
"sort of"
<whitequark>
it doesn't actually really work
<awygle>
Who complain constantly about all the broken shit even though you warned them
<whitequark>
oh and there's a bug with the 1V8 power supply that used to cause the FPGA to shut down in approximately 30 seconds after a power cycle
<whitequark>
so we rigged an arduino to poke the right pin in the ATX PSU powering in and tried loading the bitstream *really quickly*
<whitequark>
sometimes it could even send a single ethernet packet before it hung
<whitequark>
(that went nowhere because of other bugs)
<awygle>
I understand why you gave me side eye when I said boards were easy :-P
<whitequark>
so it has two I2C muxes
<azonenberg>
PSU bugs, my favorite
<azonenberg>
you remind me of a board i did a while ago
<whitequark>
both I2C muxes mux between the same 8 I2C busses
<awygle>
they randomly get stuck and no one knows why?
<azonenberg>
where the power rail that fed JTAG would shut off in sleep
X-Scale has quit [Ping timeout: 255 seconds]
<whitequark>
but the root port of one goes to the FPGA and the other to MMC
<azonenberg>
well, i loaded a firmware that put it to sleep and had a bug preventing it from waking up
<whitequark>
awygle: almost
<whitequark>
they get stuck if you reset the board while it's reading from a slave
<whitequark>
and i had to write a workaround for that.
<awygle>
PCA part number?
<whitequark>
TCA9548
<whitequark>
but it's not the fault of the mux afaict
<whitequark>
it's just i2c being shit
<whitequark>
well no
<awygle>
hmm I wonder if that's the one we had
<whitequark>
i2c being shit and the fact that half of the resets goes nowhere and the other half goes only to mmc
<awygle>
We had an identical issue and actually figured out how to fix it, iirc...
<whitequark>
you clock the slave until it fucks right off
<awygle>
Yeah that sounds right. Generally a good idea with i2c
<whitequark>
also, this just made me realize why you have the master NAK the slave in the end of a transmission
<whitequark>
otherwise you have no way to tell it to release the bus
<whitequark>
in such a situation
<whitequark>
just a stop condition is not sufficient
<awygle>
mhm
<whitequark>
oh there's another I2C bus
<whitequark>
this time between the SFP and the MMC
<whitequark>
I'm not actually sure what is it *useful* for
<whitequark>
so far the thing has been nothing but bugs
<whitequark>
hang on
<whitequark>
is this... IPMI?!
<whitequark>
like the Intel IPMI?
<azonenberg>
that's what i'm thinking
<azonenberg>
it sure looks like it
<whitequark>
what in the ever living fuck
<whitequark>
no wonder nothing works
FabM_cave has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.3/20180326230345]]
<whitequark>
azonenberg: the ethernet phy is max24287
<whitequark>
maxim
<whitequark>
that explains many things
<azonenberg>
very interesting, i had actually considered using that phy in my fpga cluster project
<azonenberg>
To interface spartan-6's to a 1000baseX backplane
<azonenberg>
Then i decided to deprecate spartan6 for future projects and go all 7-series and kinda forgot about it
<whitequark>
can't you just go full sfp
<whitequark>
wait hm
<azonenberg>
The idea was to not need 30 cables to each card
<whitequark>
cables?
<azonenberg>
So i had uart, i2c management, jtag, power, and ethernet
<whitequark>
not fibers?
<azonenberg>
all on one edge connector
<whitequark>
oh hm
diadatp has quit [Ping timeout: 260 seconds]
<azonenberg>
you'd have eight compute cards, one management card, and an ethernet switch on a backplane
<azonenberg>
two backplanes side by side in 3U
<azonenberg>
i have a mechanical mockup of it with no active components, plus abandoned kicad designs for the backplane and switch card
<azonenberg>
The project may still happen but starshipraider kinda grew out of the management card
<azonenberg>
the idea was to be able to jtag, uart, etc to each card in the rack over ethernet
<azonenberg>
and not have a zillion ftdi dongles hanging around
<whitequark>
azonenberg: integrate glasgow :P
<azonenberg>
lol no
<azonenberg>
i crunched the numbers and with all of the interfaces going
<whitequark>
well yeah it's a bad fit for your case
<azonenberg>
i'd potentially saturate gig-e with management traffic
<azonenberg>
Eight lanes of jtag at up to 66 MHz (Fmax for 7 series monolithic parts)
<whitequark>
oh
<whitequark>
so our 50 MHz jtag isn't that slow
<azonenberg>
That's 528 Mbps each way
<azonenberg>
Plus i2c and uart
<azonenberg>
and framing overhead
<whitequark>
some random thing i'm thinking about for glasgow is
<azonenberg>
whitequark: yeah that's a pretty reasonable limit
<azonenberg>
for starshipraider i wanted higher speed to do things like quad SPI @ 100 MHz
<azonenberg>
now imagine sniffing 100 MHz quad SPI with an oversampling LA
<whitequark>
whether to embed yosys into the glasgow management tool and generate bitstreams for any particular pin configuration on the fly
<azonenberg>
500 Msps doesn't look so overkill
<whitequark>
or to make an fpga-inside-an-fpga
<azonenberg>
you mean an io crossbar?
<whitequark>
basically
<azonenberg>
That's what starshipraider is doing
<whitequark>
can it be made fast?
<azonenberg>
Dont know, havent built it yet :P
<azonenberg>
all 32 GPIOs will be fed directly to the GPIO bitbang controller and the logic analyzer
<azonenberg>
then there will be a crossbar to all of the various soft IP for protocols
<whitequark>
actually i wonder if it's possible to coerce the ice40 toolchain into telling me which bits in the bitstream to poke to configure the io crossbar
<azonenberg>
so say there will be eight jtag cores
<whitequark>
instead of actually having it in the fpga
<azonenberg>
i most likely will have to add pipeline registers
<azonenberg>
but that shouldn't be a huge deal
<whitequark>
how so?
<whitequark>
if you have a bidirectional protocol
<azonenberg>
well the tougher part will be dealing with clock switching i think
<whitequark>
what I mean is
<azonenberg>
But protocol like say GMII are pretty latency tolerant
<azonenberg>
I2C is slow, you can handle lots of delay
<azonenberg>
SPI is unidirectional
<whitequark>
yes, it doesn't matter for I2C
<whitequark>
for SPI, what if you want to do something like loopback starshipraider-side?
oeuf has joined ##openfpga
<azonenberg>
there's not a lot of protocols that involve really short turnaround times on a bidirectional bus, to the point that an extra 2 ns is a huge problem
<azonenberg>
loopback? explain
<azonenberg>
mosi -> miso?
<whitequark>
yes
<azonenberg>
why would you want that?
<whitequark>
debug something
<azonenberg>
i mean, you could always do a custom fpga image for it that has the mux ahead of the crossbar
<azonenberg>
if it came to that
FabM_cave has joined ##openfpga
<whitequark>
ok let me rephrase
<azonenberg>
But until i build it, i wont actually know how fast it is
<whitequark>
let's say you're hooking up an spi flash
<whitequark>
oh nvm
<whitequark>
you can always slow down the clock when you need to flush out the pipeline
<azonenberg>
alternatively, say i'm running QSPI @ 100 MHz
<azonenberg>
that's a 10 ns cycle time
<azonenberg>
the SPI flash i'm looking at the datasheet of has 2 ns input setup time and 3 ns hold time
<azonenberg>
Worst case a single pipeline stage (2 ns delay @ 500 MHz) isnt going to kill you
<azonenberg>
But again, you're getting to stages of the design i havent done yet
<azonenberg>
So i do not have answers yet
<azonenberg>
To start, my SPI core will be a master only and not a slave
<azonenberg>
So it generates SCK and it's always phase aligned with MOSI
<azonenberg>
and i'll know latency through the crossbar and can sample MISO at the right time
<whitequark>
hmm
<whitequark>
i think arachne-pnr doesn't even tell me that
<azonenberg>
whitequark: also, if i really need great performance on the mux
<azonenberg>
I can use "poor man's partial reconfig"
<whitequark>
oh?
<azonenberg>
keep in mind, the mux is connecting pins of IOBUFs to IPs and doesnt care about what's bidir vs unidir
<azonenberg>
i have tristate, din, dout as separate mux signals
<azonenberg>
So, I don't expect agility of the mux to be super critical
<azonenberg>
This is something you set up once when you connect your probes
<azonenberg>
then maybe tweak when you discover there's jtag somewhere yo udidnt know about
<azonenberg>
etc
<azonenberg>
But a few ms to reconfigure the mux is no big deal
<whitequark>
a 16:1 mux is 9ns on ice40
<azonenberg>
no i mean, to change the mux settings
<azonenberg>
not latency through it
<whitequark>
yeah sure, I'm thinking out loud
<azonenberg>
anyway, you can use a SRLC32E as a 5-input LUT
<azonenberg>
and load new truth tables as you see fit
<azonenberg>
normally, you're limited to 4:1 mux in a lut6
<whitequark>
ooh that's true, I can definitely coerce the ice40 toolchain into letting me modify luts post-place
<azonenberg>
but i can do 5:1 in a lut5 if i reload the truth table
<azonenberg>
And with shift register ltus
<azonenberg>
luts*
<azonenberg>
you can do this post-part with no bitstream twiddling
<azonenberg>
Through fabric logic, no jtag or ICAP needed
<whitequark>
not on ice40
cr1901_modern has quit [Read error: Connection reset by peer]
<azonenberg>
yeah i dont know ice40 microarch well
<whitequark>
it has one LUT primitive.
<whitequark>
and it's, well, a LUT.
<whitequark>
that's it
<azonenberg>
anyway, basically my plan is to have maybe 2 levels of lut logic which would give me a 25:1 mux
<whitequark>
LUT4
<azonenberg>
i think that's enough for a decent crossbar
<azonenberg>
if i had 3 levels i'd have 125:1
<azonenberg>
at that point routing congestion would be my limit :p
<azonenberg>
And it won't be that big either... 1 + 5 + 25 = 31 LUT6s = ~8 SLICEMs per bitslice
<azonenberg>
times say 32 input bits, 32 output bits, 32 output enable bits is ~3 kLUT
<whitequark>
that's more than half of my FPGA :P
<azonenberg>
whitequark: lol you're not trying to do such a big mux as i am though right?
<azonenberg>
and i havent crunched the exact numbers, since i dont know how many IPs i'll be jamming in there yet
<whitequark>
i have only 16 bits
<whitequark>
but also only 4-LUTs
<whitequark>
so that's 2 levels of LUT logic giving me 16 bits exactly
bitd has joined ##openfpga
<whitequark>
azonenberg: huh, is it commonly possible to have multiple drivers for a wire inside an FPGA?
<whitequark>
this is impossible on greenpak and seems possible on ice40
<azonenberg>
whitequark: Most FPGAs do not have internal tristates that are adjustable at run time, so wires are intended to have only one driver
<azonenberg>
that being said, typically the routing fabric is just one-hot pass transistor muxes
<azonenberg>
Greenpak is the exception with dense-coded muxes
<azonenberg>
coolrunner for example is one-hot so you can trivially have multiple drivers
<azonenberg>
there's no way to disconnect them however, so you get bus fights if they ever disagree :p
<azonenberg>
in fact, this is how my "chip killer" bitstream for xc2c32a works
<whitequark>
that sounds fun
<whitequark>
oh?
<whitequark>
does it actually kill the chip?
<azonenberg>
I set half the FFs and macrocells to 1, half to 0
<azonenberg>
then activate every pass transistor
<azonenberg>
turning the whole routing matrix into a giant bus fight
<azonenberg>
I end up pulling about 100 mA on VCCINT of a chip that should pull <1
<azonenberg>
It's lethal after about 10-15 minutes
<whitequark>
interesting
<azonenberg>
~180 mW dissipated in... /me checks
<azonenberg>
about 0.06 mm^2
<azonenberg>
That's 3 megawatts per m^2
<whitequark>
that's a lot.
<azonenberg>
Yeah, i'm actually surprised it took so long to die
<azonenberg>
I did some sem/optical imaging and a few fib sections
<azonenberg>
the fault site was not obvious
<azonenberg>
but i didnt do any probing or voltage contrast imaging
<azonenberg>
Which probably would have found it quickly
<azonenberg>
i can always fry another one, they're cheap enough :p
<rqou>
whitequark: heh, maxim
<rqou>
i've heard similar bad things about them
<whitequark>
rqou: oh btw
<whitequark>
xc2c32a wouldn't work for glasgow anyway
<whitequark>
it only has two io banks
<rqou>
oh?
<whitequark>
even if we dumped 5V, i need one bank for talking to FPGA and two for two ports
<rqou>
get a 64a? :P
diadatp has joined ##openfpga
<rqou>
azonenberg: where's my ZIA map? :P
<whitequark>
but your tools don't support it?
<whitequark>
xc2c64a also has only two banks.
<rqou>
fine, then 128
<rqou>
the tool can probably be extended to support these
<whitequark>
two banks.
<rqou>
what
<rqou>
that can't be right
<whitequark>
xc2c256: two banks.
<rqou>
oh wait it is lol
<rqou>
nevermind
<rqou>
use 2? :P
<whitequark>
xc2c512 has four.
<rqou>
yeah
<rqou>
but nobody really uses that
<whitequark>
and it costs freaking 70 bucks
<whitequark>
that's more than my total BOM
<rqou>
yeah, that part is bullshit
<whitequark>
... by a factor of two.
<whitequark>
why does it even exist?
<rqou>
it's the one that azonenberg had me go look for in huaqiangbei because he didn't want to pay for one :P
<azonenberg>
whitequark: , wait what? the 128/256 are only two banks??
<whitequark>
yup
<whitequark>
just checked
<azonenberg>
whitequark: also, beacause massive crossbars are slooow
<rqou>
oh btw whitequark reading backlog about jtag muxes
<azonenberg>
there was originally going to be an xc2c1024
<azonenberg>
there's some references to it in old ise data files
<azonenberg>
i extrapolated from the known coolrunner die sizes
<rqou>
iirc there are arm socs that have (idk if standard or added by the vendor) an internal jtag "picker"
<rqou>
that splices taps into and out of the scan chain
<azonenberg>
the xc2c1024 would have had logic capacity comparable to a small-medium sized spartan3a
<azonenberg>
And a die about the size of an intel cpu of the era :p
<rqou>
otherwise apparently you hit things like debugging the e.g. dsp is slooow because you have to put all 2/4/8/etc. arm cores into bypass mode and still shift bits through them
<azonenberg>
rqou: yeah i've seen stuff like that
<rqou>
also, i2c is indeed a pile of shit
<azonenberg>
microchip has some weird stuff where there's only one device on a pic32's tap
<whitequark>
rqou: why is dsp slow there?
<azonenberg>
but it's either a microchip tap or a mips ejtag tap
<rqou>
the other taps are "in the way"
<whitequark>
what
<azonenberg>
and you have a command to switch
<rqou>
bypassed taps still occupy a bit
<azonenberg>
whitequark: it adds a few clocks of latency
<rqou>
also, sleep modes
<azonenberg>
i guess that matters?
<rqou>
e.g. "dsp is running but arm cluster is sleeping"
<whitequark>
yeah, why would that matter?
<azonenberg>
idk, i put great effort into reducing the impact of latency in my debug protocols
<whitequark>
it's just a few bits of latency
<whitequark>
also
<azonenberg>
Since usb latnecy is so much more
<azonenberg>
i wanted a ms here or there to not kill things more than it had to
<rqou>
anyways, when i was at BRCM working with a <redacted>, poking its i2c bus too soon after it was powered on (there was a power gate) would hang the bus forever
<whitequark>
why can't BYPASS mode connect TDI directly to TDO?
<rqou>
that's not what the spec says? :P
<rqou>
some people do that
<azonenberg>
rqou: what?
<whitequark>
yeah, why doesn't the spec say that?
<azonenberg>
whitequark: among other thigns
<azonenberg>
that's how you find out how many devices are on the chani
<azonenberg>
put everything in bypass, then measure latency through the chain
<azonenberg>
having a "combinatorial bypass" instruction might work, but there's still going to be ibuf/obuf latency
<rqou>
yeah now that i think about it the problem on socs is probably sleep states
<azonenberg>
you're better off registering to improve setup time at the next chip in line
<rqou>
e.g. i want to debug the dsp but the arm core is running at 32khz and therefore so is the jtag chain
<rqou>
select them out and you can run at full speed
<azonenberg>
rqou: um
<azonenberg>
normally the tap is using TCK
<whitequark>
azonenberg: what is the IR size?
<azonenberg>
and not locked to the cpu clock in any way
<rqou>
azonenberg: i thought there are "issues"
<rqou>
hence RCLK
<rqou>
especially in sleep states
<azonenberg>
whitequark: so, when the chain starts up in test-logic-reset
<azonenberg>
everyone's IR is set to IDCODE
<whitequark>
azonenberg: there are indeed issues
<azonenberg>
So you can then shift out N idcode's, each guaranteed to be 32 bit
<whitequark>
specifically if you're trying to poke the core registers via JTAG
<whitequark>
JTAG cannot be faster than core clock
<azonenberg>
identify each part on the chain and figure out the idcode size that way
<whitequark>
similarly for peripherals
<azonenberg>
whitequark: sure it can be
<azonenberg>
you need synchronizers, but you need them anyway
<whitequark>
not if it goes through AHB
<rqou>
only if you did it right :P
<whitequark>
and AHB is clocked from the core clock
<azonenberg>
whitequark: yes but is there not a sync from jtag to ahb?
<whitequark>
which is how I think ARM does it
<azonenberg>
i started implementing arm debug AP support in jtaghal but never finished
<whitequark>
I'm actually not sure if there is
<azonenberg>
i got far enough to find typoes in the coresight docs
<azonenberg>
Also, the AHB is normally at a divisor of the core clock
<azonenberg>
often you can adjust it
<whitequark>
yes, I know
<whitequark>
that further limits your jtag clock
<rqou>
this also makes stm32 bitbangers sad
<rqou>
although idk why people get so hung up on this problem
<rqou>
solution: don't use bitbang
<azonenberg>
rqou: isnt the bitbang on APB?
<azonenberg>
not AHB
<rqou>
er, not sure
<azonenberg>
whitequark: every chip i've ever designed with any kind of debug protocol has had a dual clock fifo, or at least a synchronizer, between jtag and core clock domains
<rqou>
but APB is attached to the AHB anyways
<azonenberg>
as long as you didn't push data too fast and overflow the fifo you could have a 1 kHz core clock and 1 GHz jtag and it wouldnt care
<rqou>
the problem is that ST is bad at bus arbiters or something and there are inconsistent delay states
<azonenberg>
i.e. send a bunch of data then wait for an ack before pushing more
<azonenberg>
are they doing stupid things like oversampling the jtag registers without synchronizing?
<rqou>
azonenberg: also no, STM32 GPIO blocks are on the AHB actually
<rqou>
gotta go fast :P
<azonenberg>
and relying on fcore being at least n* greater than the jtag?
<whitequark>
rqou: GPIO is on APB2
<whitequark>
in STM32F1
<whitequark>
but on AHB in L1
<rqou>
F4 (which for now is my preferred line despite unusable i2c) has them all on AHB1
<azonenberg>
whitequark: on that topic, if you want to help me improve the arm debug support in jtaghal at some point that would be nice
<azonenberg>
My goal was to be able to boot up a zynq's ARMs in jtag slave mode
<rqou>
azonenberg: or support esden/1bitsquared and buy a black magic probe? :P
<azonenberg>
Then port that code to an FPGA
<azonenberg>
rqou: you're missing the point
<rqou>
(says the person who uses a reflashed stlink :P )
<whitequark>
black magic is nice but it's a different device entirely
<whitequark>
i have one
<azonenberg>
I wanted a non-copyleft implementation i could port to an fpga
<whitequark>
i still want arm jtag in glasgow
<azonenberg>
The end goal was to have an artix7 jtag a zynq in slave mode
<azonenberg>
meaning, the zynq's fpga gets loaded first over jtag
<azonenberg>
Then i poke the coresight registers to initialize the CPU
<azonenberg>
i push my application into the OCM
<rqou>
hmm
<azonenberg>
then i poke registers to make $pc point to my entry point
<rqou>
btw azonenberg, you should dump the zynq hidden bootrom :P
<azonenberg>
then start executing
<azonenberg>
oh and, before i start executing
<azonenberg>
i create page tables that disable access to almost everything but one axi bus to the fpga
<azonenberg>
disable interrupts
<azonenberg>
and drop to user mode
<azonenberg>
At this point, in theory, you should be trapped in user mode forever
<rqou>
hmm interesting
<azonenberg>
with no way to break out or touch anything but your half of ram and the axi bus
<azonenberg>
Next step, make an axi-to-antikernel-noc bridge
<azonenberg>
And run two antikernel userland processes on the zynq CPUs, sandboxed from each other and the rest of the chip
<rqou>
btw i remember reading that somebody (in the mobile space) actually sets up hypervisor mode with no page table self mapping
<azonenberg>
The goal was to explore how antikernel would work with a modern CPU
<rqou>
to limit the potential for sploits disabling the hypervisor
<azonenberg>
and decent performance
<rqou>
azonenberg: does zynq have an iommu with ASIDs?
<azonenberg>
rqou: Dont know, dont care
<rqou>
er, a normal MMU in this case
<azonenberg>
they have a MMU
<azonenberg>
i was going to just unmap all of the hard IP
<rqou>
with ASIDs?
<azonenberg>
it's a cortex-a9
<azonenberg>
i havent looked into it in detail yet
<rqou>
to try and keep the processes isolated
<rqou>
yeah, idk anything about cortex-a
<azonenberg>
i was going to run one process per core
<rqou>
my arm experience is mostly limited to arm7tdmi-class devices and cortex-m
<azonenberg>
give each core half the OCM, maybe half the DRAM as local storage if i hooked up DRAM
<azonenberg>
Then one dedicated axi bus to the fpga
<azonenberg>
the fpga knows which process is which based on which bus it came in on
<whitequark>
thats
<azonenberg>
The CPU is in user mode, all interrupt vectors are nops/halt instructions/null/otherwise null
<whitequark>
not a very efficient use of resources
<azonenberg>
otherwise unusable*
<rqou>
btw for debug mode will you have a read-only page table self map so that you don't end up hating yourself? :P
<whitequark>
why?
<azonenberg>
rqou: no i'd debug over coresight
<rqou>
or can the debug interface bypass MMUs?
<whitequark>
^
<azonenberg>
which would still have access to everything
<azonenberg>
it's physical address based
<rqou>
ah ok
<azonenberg>
unlike actual antikernel
<whitequark>
azonenberg: so is there any standard for IR length?
<azonenberg>
whitequark: no
<whitequark>
how do you determine it?
<rqou>
trololololo jtag is garbage
<azonenberg>
you need the BSDL, or a priori knowledge based on the jtag idcode
<whitequark>
wtf
<whitequark>
that's so stupid
<rqou>
i thought you can put everything else in bypass
<azonenberg>
You can figure out the sum of IR lengths in the chain
<azonenberg>
and the number of chips
<azonenberg>
But not where the boundaries are
<azonenberg>
If there's only one unknown device in the chain you can calculate
<rqou>
hrm
<azonenberg>
rqou: in actual antikernel, if you want to read memory from userland processes
<azonenberg>
you need to ask the cpu's debug bridge
<rqou>
oh right, you need to know the IR length to put things into BYPASS :P
<whitequark>
the number of chips by using BYPASS, right?
<azonenberg>
and it can say no
<whitequark>
and BYPASS is just 1111111?
<azonenberg>
rqou: you do not need to know the ir length to bypass
<azonenberg>
go to shift-ir, clock a few thousand 1 bits
<azonenberg>
go to shift-dr
<rqou>
er, you need the IR length to bypass chips individually?
<azonenberg>
measure latency
<azonenberg>
Yes, to bypass individual chips you do
<rqou>
anyways, JTAG is a dumpster fire, news at 11
<azonenberg>
whitequark: the goal of that experiment was not to be a usable production system
<rqou>
also, afaik nobody likes actual pcb-level chains nowadays because things like clock skew kill your max freq
<azonenberg>
the goal was to simulate "custom arm cpu with antikernel patches"
<azonenberg>
by using coresight + custom logic to provide out of band management
<azonenberg>
then have the code on the cpu be completely sandboxed
<azonenberg>
with no ability to execute in supervisor mode whatsoever, or access anythign on the system without sending messages through the (memory mapped) antikernel noc
<azonenberg>
you could even do context switching over coresight if you're crazy enough
<whitequark>
ah
<azonenberg>
Halt the cpu, save registers, load a new page table with a different part of the ram enabled, load new registers, awake
<rqou>
anyways, more backlog reading: whitequark why don't you like having a "supervisory/management/PMIC" microcontroller?
<rqou>
sounds like a decent idea to me?
<whitequark>
rqou: because it's a piece of shit that does nothing but introduce bugs
<azonenberg>
then basically do a paper saying "hey look, if we had actually designed the cpu this way in the first place we could have a much faster bus / wouldnt have to do it over jtag"
<whitequark>
it's not that bad when it just does power management
<azonenberg>
whitequark: is you beef with a management mcu in general, or IPMI in particular
<whitequark>
it is one of those ideas that sound good on paper
<whitequark>
but in practice you now have a heterogeneous system where you have most of your tooling nicely geared for FPGA
<azonenberg>
incidentally, in my MARBLEWALRUS fpga cluster design
<whitequark>
and this ugly outgrowth at the side that does a bunch of critical functions
<azonenberg>
management was done via a dedicated per-blade I2C bus (no muxing, point to point from management card to each compute blade)
<rqou>
so what about a "supervisory/management/PMIC" FPGA instead? :P
<azonenberg>
plus a uart console
<azonenberg>
per blade
<azonenberg>
then jtag
<whitequark>
rqou: that sounds more sane
<whitequark>
azonenberg: whyyy i2c
<azonenberg>
whitequark: to talk to all of the INA226s hanging off my power rails
<azonenberg>
temp sensors
<azonenberg>
etc
<whitequark>
ah
<whitequark>
okay
<azonenberg>
One bus, no muxing
<azonenberg>
basically i wanted to be able to make realtime graphs of every blade's vccint, tj, etc
<rqou>
waiting for azonenberg to hit an address conflict
<azonenberg>
rqou: i carefully plan all of my buses to not have any
<azonenberg>
if i have unavoidable conflicts, like for a SFP+ that only has one address hard wired
<azonenberg>
i put in multiple buses
<azonenberg>
in fact, sometimes i have multiple buses even without conflicts
<azonenberg>
because i want to have different bus master cores attached to different subsystems in the soc
<azonenberg>
and not need an arbiter
<azonenberg>
extra gpios are sometimes the way to go
<pie_>
the only reason people (i.e. me) don't know there isnt a manga for literally everything is because they dont know japanese
<pie_>
meanwhile i just realized something
<pie_>
if iter doesnt actually work, what are they testing when they build it
genii has joined ##openfpga
<pie_>
(define: "doesnt work")
* pie_
goes and reads the wiki page
<pie_>
havent they been building ITER for ages now
<balrog>
"English and French versions to come soon"
<pie_>
"Tokamak assembly starts,[34][35] but the schedule is extended by at least six years; (e.g. first plasma in 2026).[36]" mehhhhhh
<pie_>
im gonna be an old man by the time iter gets anywhere
<pie_>
2035 Planned: Start of deuterium–tritium operation.[39]
<awygle>
I gave up on tokamaks long ago
<awygle>
(good morning)
rohitksingh has joined ##openfpga
<pie_>
tokamak on the moon when?
<awygle>
Polywell designs make way more e sense to me
rohitksingh has quit [Quit: Leaving.]
<Ultrasauce_>
the stellerator is pretty neato
<awygle>
that's a better design but still fundamentally thermal
<awygle>
The problem is that because ITER and DEMO exist and have sucked up a ton of research money, it's politically important for them to work.
<awygle>
So it's hard to get other approaches funded, or so my fusion friends say
<pie_>
huh/
<pie_>
* huh.
rohitksingh has joined ##openfpga
<awygle>
the thing I like best about the polywell designs is that they're not heat engines
<awygle>
this opens up a lot of possibilities for efficiency and also alleviates a lot of design challenges associated with thermal designs
<awygle>
(cresting some new ones of course)
<awygle>
*creating
rohitksingh has quit [Quit: Leaving.]
massi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
scrts has joined ##openfpga
Ultrasauce_ has quit [Remote host closed the connection]
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
wpwrak_ is now known as wpwrak
Ultrasauce has joined ##openfpga
digshadow has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
* awygle
is being taught not to click on suspicious emails by Kevin Mitnick of all people
mumptai has joined ##openfpga
diadatp has quit [Ping timeout: 265 seconds]
<rqou>
Ultrasauce: iirc the programming sequence for i2c on stm32f4 was needlessly complicated
<rqou>
especially if you were trying to operate as both a master/slave
<rqou>
and it's got a whole bunch of hardware errata
<rqou>
especially if one of the other devices on the bus messes up
<Ultrasauce>
oh yeah i can see a usecase like that being a huge pain in the ass
<rqou>
iirc i was operating on a shitty long cable and/or possibly misunderstanding how to program the controller
<awygle>
anything with multimaster or dual mode is a huge pita
<rqou>
i gave up on it once the hardware managed to set both the "detected start condition" and "detected stop condition" bits at the same time
<rqou>
awygle: IME atmel's works
<Ultrasauce>
i wouldnt go so far as to call st's unusable but it's definitely unwieldy
<Ultrasauce>
buuut i'd say the exact same thing about i2c in general
FabM_cave has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.3/20180326230345]]
<rqou>
i think i was hitting this issue:
<rqou>
"In Master mode, a bus error can be detected by mistake, so the BERR flag can be wrongly
<rqou>
ror interrupt if the interrupt
<rqou>
This will generate a spurious Bus Er
<rqou>
raised in the status register.
<rqou>
is enabled. A bus error detection has no effect
<rqou>
on the transfer in Master mode, therefore the
<rqou>
I2C transfer can continue normally."
<rqou>
also, this is brilliant (in the SPI): "Description
<rqou>
Work-around
<rqou>
n will be wrong if the polynomial is even.
<rqou>
When the CRC is enabled, the CRC calculatio
<rqou>
Use odd polynomial."
<rqou>
oh wtf
<rqou>
the sdio block is broken AF too
<azonenberg>
rqou: how about the pic32mz qspi block
<rqou>
i don't use pic32
<azonenberg>
in the first release die rev "this peripheral is nonfunctional"
<azonenberg>
or thereabouts
<rqou>
lol
<rqou>
typical MCHP
diadatp has joined ##openfpga
<azonenberg>
i forget exactly how it was phrased but basically "it totally doesnt work whatsoever"
<rqou>
workaround: use normal SPI mode :P
<azonenberg>
at least its not as bad as altera's "if you dont use the latest version of our software to fix up your bitstreams, your unused transceivers will die prematurely"
<azonenberg>
meaning if you have a devkit and do a lot of testing without transceivers in use
<azonenberg>
then try to use them
<azonenberg>
they might not work :p
<rqou>
oh yeah lol
<rqou>
how the heck does that happen?
<rqou>
i assume not receiving a signal somehow causes an analog bias current to become much larger than expected?
<azonenberg>
i think its more like
<azonenberg>
when they tied off signals for a GT that isnt instantiated in your design
<azonenberg>
(regardless of if a signal was fed in)
<azonenberg>
they screwed up somehow and set something too big, etc
<sorear>
there was some discussion earlier about the transcievers not liking being held in reset for too long
<sorear>
maybe involving bus fighting ;)
<azonenberg>
Lol
<azonenberg>
bus fight in reset? srsly?
<sorear>
that part is me making up stuff
<sorear>
"not liking being held in reset for too long" was from a discussion here a week or so ago
<azonenberg>
lol, wow
<pie_>
uhhhhh
<pie_>
man this scroll is fucked up.
* pie_
shields eyes
<azonenberg>
lol well i mean
<azonenberg>
a fully f/oss FPGA silicon project is not beyond the realm of plausibility down the road...
diadatp has quit [Read error: Connection reset by peer]
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 265 seconds]
<qu1j0t3>
azonenberg: aaaaargh @ ' your unused transceivers will die prematurely'
diadatp has joined ##openfpga
<pie_>
on that note...id sort of expect reconfigureable hardware to you know...protect itself from bad configurations?
<qu1j0t3>
b 33
<pointfree>
08:06 <whitequark> azonenberg: huh, is it commonly possible to have multiple drivers for a wire inside an FPGA?
<pointfree>
PSoC 5LP has 16 bits of routing fabric addressing but the wires are connected in over 8.5 million locations most of these connections aren't actively switched but they do bring lots of permutability.
<pointfree>
On the 5lp you can also route a net to multiple output gpios arbitrarily for fanout etc.
<pointfree>
The iCE40HX1K has 1280 4-input 1-output LUT's which makes for 5120 Boolean variables (how close to accurate is this??)
<pointfree>
The PSoC 5LP PLD's make for 4608 Boolean variables, but the 5lp's fabric seems orders of magnitude more flexible so I'd say the 5lp is effectively higher capacity than the HX1K.
<balrog>
pointfree: but you weren’t able to fry one right?
<pointfree>
balrog: I've fried a few with incorrect drive mode settings on gpios.
<balrog>
Ah.
<pointfree>
(not Cypress' fault)
<balrog>
Yeah
<azonenberg>
pie_: and no
<azonenberg>
reconfigurable hardware normally assumes the bitstream is sane
<pie_>
i guess
<azonenberg>
generally the bitstream is very low level mux settings
<pie_>
s/protect from bad configuration/impossible to misconfigure/
<azonenberg>
They assume the bitstream came from their tool
<azonenberg>
and they do DRCing to prevent such stuff during bitstream gen
<sorear>
rad-hard FPGAs might be interesting if you care about that
<sorear>
since they're generally intended to survive operation after a configuration bitflip
<azonenberg>
sorear: i think most of the time they do scrubbing with a CRC or something
<azonenberg>
then reboot
<azonenberg>
thats how xilinx's seu detection works at least
<sorear>
azonenberg: yeah but the chip needs to survive until the next scrub cycle
<azonenberg>
and microsemi/actel's ones are fuse based so physically impossible to SEU the config data
<azonenberg>
sorear: a bus fight isnt immediately lethal
<awygle>
they have rad hard flash FPGAs
<azonenberg>
It just causes eventual failure from overheating / electromigration
<awygle>
I bet their busses aren't one hot
<sorear>
granted this covers more of the "a few bus fights" than "oops every bus line on the chip is contended" case
<azonenberg>
and yes, that too
<azonenberg>
Frying the coolrunner in 15 minues took a worst-case bus fight with every one of the 8-input one-hot muxes shorting 4 Vdd to 4 Vss
<azonenberg>
It would easily survive a few seconds of a single bus fight if you did regular scrubbing
<awygle>
Not so much for any technical reason as because I can imagine trying to sell a Nasa or dod person on "yes these can cause contention but it's fine" and the conversation doesn't end well
<azonenberg>
awygle: i mean any DDRx SDRAM bus can get into a bus fight if you flip a state bit in the controller
<azonenberg>
But as long as you recover quickly it's fine
<azonenberg>
at the end of that burst both sides reset
<azonenberg>
and you're fine
<awygle>
yes but that's intrinsically transient
<awygle>
a config bitflip needs to be actively corrected
<awygle>
especially on a flash fpga
<pointfree>
balrog: A node in a 5lp route with a source but no sink can make a constant suck at 0. Setting a node with a sink but no source can make a constant suck at 1.
<pointfree>
...Of course an end-to-end connected route with sink and source takes the value applied to it. Port interfacing can select things.
<pointfree>
...I think these are all the ingredients for a Majority gate in the routing fabric.