_whitelogger has joined ##openfpga
m_w has quit [Quit: Leaving]
m_w has joined ##openfpga
lexano has quit [Quit: Leaving]
amclain has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
philpem has quit [Ping timeout: 255 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
_whitelogger has joined ##openfpga
Zarutian has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 248 seconds]
ZipCPU|Laptop has joined ##openfpga
_whitelogger_ has joined ##openfpga
_whitelogger has quit [Remote host closed the connection]
DrStephenFalken has joined ##openfpga
DrStephenFalken has left ##openfpga [##openfpga]
digshadow1 has quit [Remote host closed the connection]
digshadow has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
fpgacraft2_ has joined ##openfpga
Hootch has joined ##openfpga
felix__ has joined ##openfpga
seu_ has joined ##openfpga
<azonenberg> Ok so, current project... I need to make a bridge that goes from a pair of named pipes to the antikernel/jtaghal jtagd protocol
<azonenberg> let's see how this works...
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2 has joined ##openfpga
felix_ has quit [Ping timeout: 240 seconds]
seu has quit [Quit: No Ping reply in 180 seconds.]
fpgacraft2_ is now known as fpgacraft2
eduardo__ has joined ##openfpga
<rqou> azonenberg: half-troll half-serious suggestion: json.v and/or protobuf.v
<azonenberg> rqou: no i'm using the antikernel jtagd protocol
<azonenberg> same protocol, just bridging it from a socket to a pair of pipes
<rqou> but how is that protocol specified?
<rqou> totally troll suggestion: asn1.v
<lain> lel
<azonenberg> The jtaghal source right now :p i'd love to document more formally
<azonenberg> and looool
<azonenberg> No :p
<rqou> at least asn1.v won't be an almost-guaranteed RCE vector
<azonenberg> rqou: this protocol is super simple, 8-bit opcode then a pile of data
<azonenberg> rqou: lol
<azonenberg> hey, the only asn.1 parsing bug i found wasnt RCE
<azonenberg> it "only" totally broke TLS cert validation
<rqou> nintendo also currently has one that totally breaks signature verification
<azonenberg> sorry i meant, x.509
<azonenberg> ... which was being used to auth firmware updates
<azonenberg> So i guess you could chain it to be RCE?
<rqou> nintendo's bug is that you can somehow malform the asn.1 so that it points past the end of the buffer
eduardo_ has quit [Ping timeout: 255 seconds]
<rqou> and the "calculated hash" buffer happens to be stored after the end of the "rsa output" buffer :P
<rqou> azonenberg: are you _sure_ your protocol isn't basically xilinx virtual cable except with different opcode bytes? :P
<azonenberg> yes
<azonenberg> it's higher level
<azonenberg> it supports things like "enter shift-DR"
<rqou> ah ok
<rqou> not "lol herp derp shift this stuff on TMS/TDI"
<azonenberg> as well as querying adapter name, serial number, etc
<rqou> along with a mysterious bug that tmbinc had to work around by following the state machine and ignoring some TMS shifts
<azonenberg> setting/reading TCK rate
<azonenberg> And pipelined transactions with a bunch of TDI writes followed by TDO reads later on
<azonenberg> to operate with higher performance over high latency links like FTDI JTAG (>1 ms round trip)
<rqou> wow, almost like it was designed by a real software person
<azonenberg> Lol
<azonenberg> oh, and also supports optional GPIO attached to the jtag adapter
<rqou> and not by using a silly set of incomprehensible bitmasks in a tcl file? :P
<azonenberg> Lol
<azonenberg> Exactly
<rqou> *cough* *cough* openocd
<azonenberg> I plan to eventually make bridges from it to/from openocd and xvcd
<azonenberg> So you can e.g. do GDB arm debug through a jtaghal adapter
<azonenberg> But yes, my tools are what happens when someone with actual software engineering background gets into EDA
<azonenberg> Rather than an EE who knows a little C :p
<rqou> super troll idea: bridge from MPSSE commands to jtaghal
<azonenberg> I have that, going the other way around
<azonenberg> But have no desire to do the inverse :p
<rqou> hook them together and formally verify the correctness :P
<azonenberg> My current project is something that will use $fread()/$fwrite()
<azonenberg> to bridge from a verilog simulation
<azonenberg> to a jtaghal compatible endpoint
<azonenberg> s.t. you can use jtaghal-compatible clients to do boundary scan of the simulated chip
<azonenberg> since you don't have a crbit spec/tool available
<azonenberg> this was the eaisest way to use my existing coolrunner flashing code to push a bitfile into my simulation :p
<rqou> i had a half-troll half-serious suggestion for one of the black magic probe devs to implement "just run mpsse bytes"
<azonenberg> oh also
<azonenberg> this same protocol?
<azonenberg> starshipraider will speak it
<azonenberg> for the jtag master virtual instrument
<rqou> he replied that it was possible but would never be an official feature because then people will stack really dumb software on top
<azonenberg> So you'll be able to just say, tdi on bank 0 channel 3
<azonenberg> tdo on bank 0 channel 4
<azonenberg> etc
<azonenberg> then run jtagclient on starshipraider:4141 and you're good to go
<azonenberg> indistinguishable from a PC-hosted jtagd attached to an FTDI cable
<azonenberg> except about 1/10 the round trip latency :p
<rqou> oh btw offtopic: the other day i discovered an amazing (/s) thing about asn.1: XER
<azonenberg> ???
<azonenberg> this cant be good
<azonenberg> asn.1 into xml?
<rqou> yeah
<azonenberg> ... wait you're serious?
<rqou> wikipedia says so
<rqou> i've never seen it used though
* azonenberg vomits
<rqou> just to have the right blend of startup-y and enterprise-y, we need to define a JER - JSON encoding rules :P
mifune has joined ##openfpga
mifune has joined ##openfpga
<azonenberg> But... do you have a ProblemFactory to go with your problem?
<rqou> maybe, but i needed another factory to construct it
<azonenberg> Ooh, a ProblemFactoryFactory
<azonenberg> i like it :p
<rqou> AbstractSingletonProblemFactoryFactory :P :P
<rqou> AbstractSingletonProblemFactoryFactoryBean
<rqou> AbstractSingletonProblemFactoryFactoryBeanApplet
<azonenberg> Needs some interfaces
<rqou> IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor
<azonenberg> ProblemFactory has to implement INuisanceFactory
<azonenberg> ditto for Problem and INuisance
<nrossi> you guys are missing an important part.... com.mycompany.IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor ;)
<azonenberg> nooo
<azonenberg> you have that all wrong
<azonenberg> com.defunctcompanythatweboughtipfrombutcantchangethenameof.IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor ;)
<rqou> com.mycompany.verysiloeddepartment1.devteam5.vendor.defunctcompanythatweboughtipfrombutcantchangethenameof.IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor
<rqou> which obviously cannot be casted into a com.mycompany.verysiloeddepartment1.devteam4.vendor.defunctcompanythatweboughtipfrombutcantchangethenameof.IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor
<rqou> and _certainly_ can't be casted into a com.mycompany.verysiloeddepartment2.devteam1.vendor.defunctcompanythatweboughtipfrombutcantchangethenameof.IAbstractSingletonProblemFactoryFactoryBeanAppletInjectorAttributeVisitor
<rqou> also don't forget that com.mycompany.StateBlob also cannot be casted into a com.mycompany.StateBlob
<rqou> why? because the first one came from VerySiloedDepartment1's custom classloader but the second one came from VerySiloedDepartment2's custom classloader
<rqou> isn't java great?
<rqou> serious question: what use cases were custom classloaders actually designed for?
* azonenberg did not even know that was a thing
<rqou> you didn't? how did you think the somewhat-deshittified minecraft mods worked?
<rqou> (all "advanced" mods essentially contain a classloader that (at least in the past) took in a byte[] and returned a byte[] corresponding to every .class file in the game)
<rqou> this is why modded minecraft needs the ASM library and why mod loading takes forever
<azonenberg> I assumed minecraft mods just patched the jar or something
<azonenberg> or used a documented mod api
<azonenberg> but never looked into it
<rqou> hah
<rqou> the mod "api" is third party (and very drama)
<rqou> they used to patch the jar until people realized that two mods couldn't exactly patch the same file at the same time
<azonenberg> so is there no supported mod api?
<rqou> so now it patches the jar in memory at runtime instead
<azonenberg> ...
<rqou> now as long as two mods don't patch the same methods (or basic blocks, if the programmer was smart (unlikely)), they won't conflict
<rqou> also, this might have changed since i last looked at it, but at least at one point the interface really was what i described above with byte[] inputs and outputs
<rqou> so every mod that wants to make a patch has to repeat the "find target method" and "visit opcodes" steps
<rqou> it can't be cached
<lain> Forge has a pretty nice looking mod api (unofficial)
<lain> most stuff uses it
<rqou> right, forge is what added this giant classloader mess
<rqou> also a whole bunch of hot attributes
<rqou> and other "design pattern" madness
<rqou> i actually never understood how the magic attributes in forge work
<rqou> i assume that the forge part of the classloader magic somehow hooks them up
<rqou> er, s/attribute/annotation/
<rqou> naming things is hard
<rqou> this is what happens when you combine *) java is poorly designed with *) minecraft is poorly designed
<rqou> azonenberg: i just had an unbelievably-trolly idea to implement for an april fools or something
<rqou> DCOM.v
* lain spits out her drink
<lain> that would be impressive
<rqou> hmm, is the DCOM wire protocol even documented?
<rqou> hmm, there's a 1998 article about it
<rqou> lain: i can't even figure out if DCOM still "really exists" anymore or not
<rqou> or if it's been added to the "giant stack of Windows tech that everybody else ignored"
mifune has quit [Ping timeout: 248 seconds]
<lain> no idea
<rqou> "Windows tech" is so weird
<rqou> heh it's pretty hilarious browsing questions tagged "com" on stack overflow
<rqou> most of them have absolutely no answers/attention because nobody cares about windows tech
<rqou> the others are about com ports rather than com the object model and also have no answers because nobody on SO cares about hardware either
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/vQVPn
<openfpga-github> openfpga/master 521bbcb Andrew Zonenberg: JtagPipeBridge: Initial implementation. Only does get name/serial/userid so far
<openfpga-github> openfpga/master 5254cce Andrew Zonenberg: Minor indentation fix
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
[X-Scale] is now known as X-Scale
X-Scale is now known as Guest69116
pie_ has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 260 seconds]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie__ has quit [Quit: Leaving]
qu1j0t3 has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
felix__ is now known as felix_
Guest69116 is now known as X-Scale
DingoSaar has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
amclain has joined ##openfpga
azonenberg_work has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
philpem has joined ##openfpga
<azonenberg> Grr oshpark lead times are a bit annoying
<azonenberg> its been 2 weeks and this board is still at fab
<azonenberg> But i'm already spending enough on PCBs, i don't need to pay extra for faster service :p
<qu1j0t3> :)
<azonenberg> I did 3 4-layer boards in june alone
<azonenberg> lol
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
mifune has quit [Ping timeout: 240 seconds]
DingoSaar_ has joined ##openfpga
DingoSaar has quit [Ping timeout: 248 seconds]
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
m_w has quit [Quit: Leaving]
Hootch has quit [Read error: Connection reset by peer]
<azonenberg> whitequark, rqou: Second Peltier arrived
<azonenberg> Top plate is a frosty -30C right now, in a 26C ambient garage
<azonenberg> if the ambient was a bit cooler and/or i had insulation around things, i think i could totally do -40
<balrog> add some foam insulation :P
<balrog> that would help a ton
<balrog> azonenberg: how hot is the heatsink?
<azonenberg> not that hot, maybe 30C iirc - it's in my notes somewhere
<azonenberg> bear in mind that's a giant 2U ATX heatsink meant to cool a core2quad
<azonenberg> i'm pushing maybe 15W through it
<azonenberg> So it's not gonna break a sweat
<azonenberg> i figure the cooler the hot side is, the less i leak to the cold side
<azonenberg> 56C differential is not bad, i just need to insulate the cold area and run my -40C tests at night with the garage door open
<rqou> how is this going to get coupled to the DUT?
<azonenberg> rqou: It will touch the DUT plus an I2C thermal sensor for feedback through either a layer of arctic silver or a silicone thermal pad, i have both and will experiment
<azonenberg> gonna try and insulate around the sides
<rqou> so no giant ZIF socket?
<azonenberg> The -30C number quoted is an IR thermometer at the coldest part of the peltier plate
<azonenberg> Correct, the ZIFs didnt seem to have an easy way to do a thermal plate
<azonenberg> and i didnt want to deal with building an environmental chamber
<azonenberg> (especially since some of the stuff on starshipraider probably won't handle -40C well, i used commercial range parts)
<rqou> heh i was expecting "i stuck the DUT in a beer fridge"
<rqou> this is already much higher tech than that
<azonenberg> U3 = DUT, U1 = thermal sensor
<azonenberg> i carefully picked a sensor with almost exactly the same package height as the DUT
<azonenberg> to ensure good contact
<azonenberg> header at left goes to gp devboard, header at bottom is i2c to starshipraider and/or peltier control board
<azonenberg> sgstair is gonna try and 3d print a mechanical brakcet of some sort to pinch the peltier/heatsink onto the board but that's TBD
<azonenberg> this is the level shifter board that goes from the starshipraider to the gpak devkit so i can test at voltages other than 3.3
<azonenberg> Both of these two boards are at fab now, should ship middle of next week
<azonenberg> i have parts and stencils already
<rqou> you can't just attach the peltier and the DUT with a clamp? :P
<azonenberg> i want something reproducible
<azonenberg> keep in mind i'll be doing like a dozen or more dies
<azonenberg> across multiple temp/voltage combos
<rqou> yeah i guess neither a quick-clamp nor a beer fridge are reproducible :P :P
<azonenberg> Plan is to do 1.71, 1.80, 1.89, 2.375, 2.5, 2.625, 2.97, 3.3, 3.63, 4.5, 5, 5.5V
<azonenberg> so 1.8 and 2.5 +/- 5%, 3.3 and 5 +/- 10%
<azonenberg> i may do 5% on the 3.3 and 5V as well, so if you have a tighter regulated PSU you can get better timing margins
<azonenberg> Which would add 3.135, 3.465, 4.75, 5.25
<azonenberg> Then -40, -20, 0, 25, 45, 85C
<azonenberg> then at least ~5 dies from lot P6001, 5 from 5P501, and 5 from the third lot silego promised me but hasn't sent yet
<azonenberg> Sooo that's 15 dies * 6 temps * 16 voltages = 1440 full-die timing measurements, plus more if i do additional dies
<azonenberg> for just one device family :p
<azonenberg> Whiiich is why i need to optimize my characterization code to not take an hour to do one set of measurements
<azonenberg> (measurements that aren't even all inclusive yet lol)
clifford has quit [Ping timeout: 260 seconds]
philpem has quit [Ping timeout: 240 seconds]
philpem has joined ##openfpga
clifford has joined ##openfpga
zino has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Client Quit]
DingoSaar_ has quit [Remote host closed the connection]
DingoSaar_ has joined ##openfpga