jevinskie has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
indefini[m] has quit [Ping timeout: 250 seconds]
indefini[m] has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 252 seconds]
<sorear> day 2: iverilog segfaulted
Bike has quit [Quit: Reconnecting]
Bike has joined ##openfpga
genii has joined ##openfpga
<fseidel> I think instability is a requirement of writing a logic sim
genii has quit [Remote host closed the connection]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 252 seconds]
rohitksingh_work has joined ##openfpga
scrts has quit [Ping timeout: 244 seconds]
vup has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
vup has joined ##openfpga
prpplague has quit [Ping timeout: 244 seconds]
prpplague has joined ##openfpga
azonenberg_work has joined ##openfpga
fseidel has quit [Ping timeout: 252 seconds]
Bike has quit [Quit: Lost terminal]
fseidel has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
Ekho has quit [Ping timeout: 244 seconds]
fibmod has quit [Ping timeout: 244 seconds]
Prf_Jakob has quit [Ping timeout: 244 seconds]
fibmod has joined ##openfpga
mumptai_ has quit [Ping timeout: 244 seconds]
eightdot has quit [Ping timeout: 244 seconds]
mumptai_ has joined ##openfpga
Prf_Jakob has joined ##openfpga
eightdot has joined ##openfpga
Ekho has joined ##openfpga
galv[m] has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<cr1901_modern> q3k: It's Christmas In October!! I got a present for you :D! I managed to crash nextpnr again! https://github.com/YosysHQ/nextpnr/issues/90
<cr1901_modern> Why is this a present? B/c for once it's not PLL related
<cr1901_modern> (Hmm, I also made sure to recompile nextpnr, but I used the existing directory I already had- git sha didn't update...)
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/c04cfa79dc63...3d4763b46067
<openfpga-github> Glasgow/master 3d4763b whitequark: applet.nand_flash: slightly improve timings....
<openfpga-github> Glasgow/master 678f7b9 whitequark: Implement applet throttling for event analyzer....
<openfpga-github> Glasgow/master 8c896f8 whitequark: gateware.{fx2,analyzer}: simplify. NFC.
<travis-ci> whitequark/Glasgow#60 (master - 3d4763b : whitequark): The build passed.
m4ssi has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
wolfspraul has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
inode has joined ##openfpga
<q3k> cr1901_modern: grand, than you
<q3k> *thank
ovf has quit []
ovf has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/3d4763b46067...98edcec6c837
<openfpga-github> Glasgow/master 98edcec whitequark: target.analyzer: reset analyzer on USB interface reset....
<openfpga-github> Glasgow/master dda3895 whitequark: cli: dump analyzer traces as VCD files.
<openfpga-github> Glasgow/master b57b902 whitequark: gateware.analyzer: fix typo.
<travis-ci> whitequark/Glasgow#61 (master - 98edcec : whitequark): The build passed.
scrts has quit [Ping timeout: 252 seconds]
scrts has joined ##openfpga
<pie___> what do you guys think about what this says https://www.devever.net/~hl/intelme
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/98edcec6c837...5cb31c175fcb
<openfpga-github> Glasgow/master 5cb31c1 whitequark: gateware.analyzer: associate event sources with trigger types....
<openfpga-github> Glasgow/master 894a84b whitequark: gateware.analyzer: report accurate timestamp for DONE....
<openfpga-github> Glasgow/master f57d3d0 whitequark: target.analyzer: synchronize pin inputs.
<travis-ci> whitequark/Glasgow#62 (master - 5cb31c1 : whitequark): The build was broken.
<openfpga-github> [Glasgow] whitequark force-pushed master from 5cb31c1 to ba5fc0d: https://github.com/whitequark/Glasgow/commits/master
<openfpga-github> Glasgow/master ba5fc0d whitequark: gateware.analyzer: associate event sources with trigger types....
scrts has quit [Ping timeout: 244 seconds]
Laksen has joined ##openfpga
inode has left ##openfpga [##openfpga]
<openfpga-github> [Glasgow] whitequark created revC at 37b2e0d (+0 new commits): https://github.com/whitequark/Glasgow/commits/revC
<openfpga-github> [Glasgow] whitequark deleted rev-c at 364410d: https://github.com/whitequark/Glasgow/commit/364410d
scrts has joined ##openfpga
<openfpga-github> [Glasgow] whitequark deleted revC at 37b2e0d: https://github.com/whitequark/Glasgow/commit/37b2e0d
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/ba5fc0d18ce1...ca2f0c81ffcf
<openfpga-github> Glasgow/master ca2f0c8 whitequark: hardware: remove models present in upstream KiCad.
<openfpga-github> Glasgow/master fbc232d whitequark: hardware: update to revC0.
<openfpga-github> Glasgow/master 23ce81f awygle: hardware: update I/O cell to use SN74LVC1T45 level shifters.
<openfpga-github> [Glasgow] whitequark deleted usb_protection at d2df739: https://github.com/whitequark/Glasgow/commit/d2df739
<s_frit> pie___: interesting, hadn't seen the referenced book before.
<pie___> ¯\_(>_>)_/¯
Bob_Dole has quit [Ping timeout: 260 seconds]
Bob_Dole has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/5515256d3df48375167fbc4beef182c6b5f30f15
<openfpga-github> Glasgow/master 5515256 whitequark: gateware.analyzer: detect FIFO overrun and shut down gracefully....
Bike has joined ##openfpga
<travis-ci> whitequark/Glasgow#65 (master - 5515256 : whitequark): The build passed.
jevinskie has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
Prf_Jakob has quit [Changing host]
Prf_Jakob has joined ##openfpga
ondrej3 has quit [Quit: Leaving]
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined ##openfpga
<pie___> is anyone here any good with d3.js ;_;
gnufan has left ##openfpga [##openfpga]
<shapr> I want to steal that when you're done with it
<shapr> for my research paper annotation sharing tool
<qu1j0t3> real artists steal
s_frit has quit [Ping timeout: 244 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pie___> shapr, i can throw you the shit i have right now
<pie___> and you can make it done-er :P
<pie___> because im done with d3 for the moment xD
<pie___> super done xD
<pie___> fml
<pie___> shapr, also kind of wrong channel but whatever
m4ssi has quit [Remote host closed the connection]
<7YSAAU7JR> [Glasgow] whitequark commented on issue #28: Symbol merged. https://github.com/whitequark/Glasgow/issues/28#issuecomment-429373721
<17WAAVQG6> [Glasgow] whitequark closed issue #28: Lattice iCE40HX8K-BG121 121-ball caBGA https://github.com/whitequark/Glasgow/issues/28
<shapr> heh
rohitksingh has quit [Quit: Leaving.]
<pie___> like i bet this is super easy for someone who has a damn clue :/
mrpackthead has quit [Read error: Connection reset by peer]
<shapr> meh, we all have different clues
rohitksingh has joined ##openfpga
Dolu has joined ##openfpga
genii has joined ##openfpga
pie___ has quit [Ping timeout: 245 seconds]
eplum has quit [Quit: Connection closed for inactivity]
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
Miyu has joined ##openfpga
<whitequark> azonenberg_work: btw i'm going to try plugging glasgow jtag into jtaghal
<whitequark> so going to refactor it a bit
<azonenberg_work> refactor glasgow?
<azonenberg_work> or jtaghal :)
<whitequark> jtaghal duh
<whitequark> glasgow is already perfect
<whitequark> :P
<azonenberg_work> Lol
<azonenberg_work> what did you want to change?
<whitequark> azonenberg_work: factor out libusb stuff for glasgow
<whitequark> since that part is identical for jtag and swd
<azonenberg_work> ah, ok
<azonenberg_work> Makes sense
<azonenberg_work> I did that with FTDI recently if you look
<azonenberg_work> FTDIDriver is now used by both FTDIJtagInterface and FTDISWDInterface
<q3k> mwk: didn't you also want to refactor something in jtaghal? ^
<sorear> so if I wanted to understand JTAG software and JTAG dongles with a focus on tethered debug (all of the parts of the stack "above" 1149.1 and "below" gdb), anyone have recommendations on where to start looking
<azonenberg_work> sorear: tethered debug of what
<azonenberg_work> The protocols are completely different for each vendor/cpu family :p
<whitequark> sorear: start with 1149.1?
<azonenberg_work> 1149.1 then, if you're interested in ARM stuff, the ARM Debug Interface specification
<azonenberg_work> i forget the doc number but you can find it on google easily
<sorear> azonenberg_work: i'm probably going to invent a debug interface for this project b/c the draft riscv debug interface would be more than half of my LUT budget
<sorear> but I'd still like to talk to gdb with a "maximally normal" intermediate stack
<azonenberg_work> well ADI is specific to the arm architecture and theres probably a patent minefield if you use it for anything else
<azonenberg_work> If you want a minimalistic debug architecture i'd suggest you go with what MIPS has
<sorear> i believe the usual flow is gdb -> openocd -> ??? dongle drivers -> ??? dongles -> DUT
<azonenberg_work> Basically, you have a certain region of physical address space memory mapped
<gruetzkopf> sorear: how about mmodeless riscv?
<azonenberg_work> And a jtag register to read the address/data it wants to access and respond with data
<sorear> gruetzkopf: the debug protocol still has >100 bits of state
<azonenberg_work> sorear: you're worried about 100 dffs?
<azonenberg_work> how big is your whole soc
jevinskie has joined ##openfpga
* azonenberg_work looks over at designs using tens of kdffs
<azonenberg_work> gruetzkopf: anyway to load a debugger stub, you use a command/signal somewhere to make the cpu jump to that debug memory area
<azonenberg_work> you start feeding it instructions
<azonenberg_work> then it can memcpy data to/from that region
<azonenberg_work> etc
<azonenberg_work> so the hardware support is pretty minimal
<azonenberg_work> but you still need a few hundred bits of state just for jtag registers
<sorear> azonenberg_work: this project is "what is the absolute minimum if you don't care about CPI", which is currently looking like 200-400 LUT4+FF
<sorear> 75% a learning exercise for myself, but I'm going to publish it anyway in case somebody ever has a use for it
<sorear> since it's not a design point anyone else has really been pushing
<azonenberg_work> in that case the debug interface would be a single IRQ signal that makes it jump to a hard wired debug interrupt address
<azonenberg_work> And then you add your own system-dependent logic to the memory bus to do the rest
<azonenberg_work> i would avoid having a jtag TAP in the cpu core itself since a real soc will normally have more things to debug than just the cpu
<sorear> wouldn't that normally be handled by jtag chaining?
<azonenberg_work> Well, if you have 30 taps in a single chip it gets awkward :p
<azonenberg_work> in particular, the more taps you have the less efficient jtag is
<azonenberg_work> 2-3 is fine but 10-20 starts to add significant overhead
<azonenberg_work> since you need a padding bit for every tap
<azonenberg_work> extreme example, if you have 33 taps
<azonenberg_work> scanning a 32-bit register has 50% overhead vs a single tap
<azonenberg_work> scanning a 1-bit status register has 3200% overhead
<sorear> I take it that IR shifts are much less common than DR shifts, b/c nobody seems to talk about the much larger overhead of IR shifts
<azonenberg_work> Yeah they are a lot less common in performance critical code
<sorear> (why is there no mechanism to get the instruction register length during IDCODE probing?)
<azonenberg_work> Anyway the ARM debug protocol gets around this by having the jtag block give access to your memory bus
<azonenberg_work> then everything else is memory mapped
<azonenberg_work> So typicall an arm soc of any size will have two taps
<azonenberg_work> one for boundary scan and maybe some custom top-level commands (since the arm debug tap is an ARM IP you cant usually change)
<azonenberg_work> and one for debug of all cpus and peripherals
<azonenberg_work> sorear: and thats a good question, i wish i had an answer
<azonenberg_work> jtaghal does include logic to infer IR length in some cases
<azonenberg_work> in particular, for a jtag chain of any size
<azonenberg_work> if you have exactly one unknown device IDCODE you can calculate the IR length
<azonenberg_work> Since you can calculate the total IR length, and you can subtract the known IRs from that
<azonenberg_work> But for multiple unknown devices all you can tell is the sum of their IR lengths
<azonenberg_work> and not where in the chain the bits are allocated
<azonenberg_work> In jtaghal, i try to figure out based on full or partial IDCODE the IR length of as many chips as i can and then create a "filler" device if i find an unknown idcode
<sorear> anyway my question was more "what does jtaghal do, who are its consumers, what does it talk to, what alternatives to it exist"
<sorear> not "help me design a debug protocol"
<azonenberg_work> sorear: jtaghal is an API to jtag and (WIP) SWD
<azonenberg_work> at pretty much all levels of the stack, although not complete at the higher levels
<azonenberg_work> At the adapter level I support Glasgow via libusb, FTDI dongles via the blob API (and eventually the open library, have to review the PR for that)
<azonenberg_work> Digilent dongles via the blob API (maybe eventually some of them via libusb thanks to diamondman)
<azonenberg_work> and finally, arbitrary dongles (either a custom implementation with a LAN interface, or a socket server to one of the above devices) using my protobuf-based TCP socket protocol
<azonenberg_work> starshipraider will speak that protocol natively
<azonenberg_work> you could also, with some effort, write a bridge that speaks to a xilinx virtual cable, openocd device, etc
<azonenberg_work> none exist yet
<azonenberg_work> sorear: anyway, then I have a C++ API to a range of devices at higher levels
<azonenberg_work> i have full support for the 32-bit ARM debug interface, decent support for the 32-bit MIPS debug interface
<azonenberg_work> then as far as CPU debug vs just ram access
<azonenberg_work> i can halt-resume and inspect registers for Cortex-M CPUs
<azonenberg_work> There is no gdbserver yet but it wouldnt be hard to add
Laksen has quit [Quit: Leaving]
<azonenberg_work> There is no register modify support but it wouldnt be hard to add
<azonenberg_work> Cortex-A support is lagging because that is a lot more complex
<azonenberg_work> I have pretty solid support for programming and talking to xilinx FPGAs of various types
<azonenberg_work> Zero boundary-scan support, that was never a priority (I have a ticket for it but never went anywhere)
<sorear> what do you use jtaghal for if there's no gdbserver?
<azonenberg_work> mostly? FPGAs
<sorear> are there differences of kind between cortex-a and cortex-m debugging, or is it just "more registers"? (which does cortex-r more resemble?)
<azonenberg_work> The ARM support was added pretty recently
<azonenberg_work> My understanidng is cortex-R is mostly Cortex-A but with a simpler MMU
<azonenberg_work> I have a custom shell similar to the openocd CLI that lets you do raw memory read-write transactions on an arm device
<azonenberg_work> And i have scripted commands for things like dumping flash
<azonenberg_work> checking if a stm32 is read-locked
<azonenberg_work> etc
<azonenberg_work> STM32 support is pretty decent - I can dump flash, bulk-erase, set/clear protection. and flash a raw binary memory image (no ELF support yet, that's next on the list)
<azonenberg_work> it's only tested on... i think the F411
<azonenberg_work> But should in theory support most of the other parts
<azonenberg_work> if you add the idcode to the database
<azonenberg_work> sorear: Cortex-A and Cortex-M debug are completely different at the top level of the stack, below there it's the same
<sorear> does it use BSDL in any way?
<azonenberg_work> basically, the arm debug interface gives you access to a memory bus that talks to debug registers on each CPU
<azonenberg_work> and a ROM or hierarchy of ROM tables that stores metadata about what CPUs or other debuggable IP blocks are at what address ranges
<azonenberg_work> it's all self-describing
<azonenberg_work> But the SFR set for a Cortex-M vs a Cortex-A is completely different
<azonenberg_work> once you're on the debug bus there is nothing in common
<azonenberg_work> jtaghal does not use BSDL whatsoever, BSDL is actually of very limited use outside PCB self-test
<azonenberg_work> it assigns names to hex instructions and tells you the instruction length
<azonenberg_work> and the idcode
<azonenberg_work> thats it
<sorear> do fossi people just squat random idcodes?
<azonenberg_work> The only full jtag tap i made was a command-compatible clone of a xilinx part
<azonenberg_work> So i used their idcode
<sorear> 32-bits is kinda not large enough to reliably avoid collisions
<azonenberg_work> Yeah
<azonenberg_work> The proper option would be to go to jedec and register a vendor code
<azonenberg_work> aaanyway, jtaghal does not use bsdl because there isnt much of a point
<azonenberg_work> i have a hard coded database of device IDs that instantiate different C++ classes with different protocol support code
<azonenberg_work> If someone writes a f/oss bsdl parser (no good non-GPL ones exist to my knowledge)
<azonenberg_work> I will gladly add code that creates "dummy" devices if it finds a matching BSDL
<azonenberg_work> But you still wont be able to do anything other than seeing the chip ID
<azonenberg_work> and, if i add support, boundary scan of the IO pins
<sorear> so in the final jtaghal world it'll be gdb -> jtaghal -> libusb and/or libftdi -> [OS USB stack] -> [glasgow or ftdi] -> 1394.1 bus
<sorear> and jtaghal's scope *mostly* overlaps with openocd
<sorear> in that openocd implements a gdbserver and uses various libraries to talk to usb devices
<sorear> and they have that cute jtag over tcp thing
<azonenberg_work> sorear: it would be gdb -> jtaghal_gdbserver
<azonenberg_work> probably then talking to jtagd
<sorear> i have an openocd checkout here but I haven't managed to make much sense of it
<sorear> is jtagd a thing which already exists?
<azonenberg_work> jtaghal itself is a library, so you'd have to write a gdbserver that either calls into the library itself, or talks to jtagd (which bridges jtag out to a TCP socket using google protobufs)
<azonenberg_work> jtagd is roughly equivlanet to openocd's tcp server, or the xilinx xvcd
<azonenberg_work> but at a higher level (chain manipulation commands instead of raw TDI/TDO/TMS bits)
<sorear> how many tcp servers does openocd have? i only know about the hella low level 'remote bitbang' one
<azonenberg_work> So you have commands to do things like "set IR of device 3 in the chain to 0x41414141" and the padding bits are added server-side
<sorear> i have not heard of xvcd; would it be a good use of time to look at that?
<azonenberg_work> No
<azonenberg_work> xvcd is a xilinx proprietary cable server that is literally raw tdi/tdo/tms over tcp
<azonenberg_work> (oops last link should have been https://github.com/azonenberg/jtaghal/blob/master/jtaghal-net.proto?ts=4)
prpplague has left ##openfpga ["Leaving"]
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
<sorear> TIL about ?ts
pie__ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<sorear> azonenberg_work: is jtaghal_gdbserver a thing which is (a) ready to be done (b) could be done by someone with limited experience in the system
<azonenberg_work> sorear: a) yes, b) not sure
<azonenberg_work> however
<azonenberg_work> there is some refactoring that will probably be needed in the DebuggableDevice class for it to be really clean
<azonenberg_work> And some features, like modifying CPU registers, arent implemented yet
<azonenberg_work> I'd rather hold it off a little bit still
<sorear> once that exists, what would still be an appropriate reason to use openocd?
pie__ has quit [Ping timeout: 276 seconds]
<azonenberg_work> well, openocd has a much larger set of devices supported on the CPU side of things
<azonenberg_work> jtaghal started as an FPGA tool and gained CPU support recently
<azonenberg_work> But jtaghal is also IMO a cleaner API and is non-GPL if you care about such things
<sorear> are there other stacks I should look into besides openocd/jtaghal? do they look similar from 10000ft to openocd/jtaghal?
<azonenberg_work> None that i know of
<azonenberg_work> openocd is lke the de facto standard now and i made jtaghal to avoid working with it :p
<sorear> I'm guessing that at least a few of the silicon vendors used to have their own stacks, like how ARMCC used to be a thing
pie__ has joined ##openfpga
Bike_ has joined ##openfpga
Bike has quit [Disconnected by services]
Bike_ is now known as Bike
Miyu has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
Dolu has quit [Ping timeout: 245 seconds]
Bike has quit [Ping timeout: 256 seconds]
s_frit has joined ##openfpga
<qu1j0t3> that's like me buying a soda in cash
Bike has joined ##openfpga
emeb has joined ##openfpga
genii has quit [Remote host closed the connection]
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/5515256d3df4...8e2ca220d986
<openfpga-github> Glasgow/master 8e2ca22 whitequark: applet.jtag: new applet.
<openfpga-github> Glasgow/master bb177c4 whitequark: applet.nand_flash: synchronize input pins.
<travis-ci> whitequark/Glasgow#66 (master - 8e2ca22 : whitequark): The build passed.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
lexano has quit [Ping timeout: 272 seconds]
pie__ has quit [Ping timeout: 252 seconds]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/83fd1cd2b9318b744098cc97dd7351ac4f01be34
<openfpga-github> Glasgow/master 83fd1cd whitequark: applet.jtag: implement basic TAP scan.
lexano has joined ##openfpga
<travis-ci> whitequark/Glasgow#67 (master - 83fd1cd : whitequark): The build passed.
mumptai_ has quit [Quit: Verlassend]