cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
freemint has joined ##openfpga
freemint has quit [Client Quit]
X-Scale has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
<GenTooMan> so essentially they paid 1000 people for 1 year at 175k per person with 25k for benefits.
<GenTooMan> they most have been in CA only place in the US with salaries high enough for that.
<sorear> CA has rather high "payroll taxes" which are paid by the company, separate from income taxes
<sorear> don't assume that 175k "pre-tax salary" + 25k benefits = 200k total cost to the company
<GenTooMan> CA is it's own little world. 175k is just the CPP (cost per person) I estimate the people are likely paid between 95 and 130k the rest is likely taxes. So I see you point.
<sorear> it's also not a monolith and SF-area costs are twice socal costs
<GenTooMan> Yes... they've made world news over and over again about many of their challenges. I am just happy to be alive these days.
rohitksingh has quit [Ping timeout: 245 seconds]
genii has quit [Quit: Welcome home, Mitch]
Bike has quit [Quit: Lost terminal]
nrossi has joined ##openfpga
<OmniMancer> are JTAG devices which support IDCODE supposed to just spit it out when you reset their JTAG state machine?
<azonenberg> OmniMancer: IR is loaded to IDCODE upon reset
<azonenberg> you need to go to SHIFT-DR and clock 32 bits out
<OmniMancer> azonenberg: is it possible for the IR to not be loaded to IDCODE upon reset but the device to support an IDCODE instruction?
<azonenberg> Not while being compliant with the spec, no
<azonenberg> a proprietary ID instruction that isn't loaded at reset is certainly possible but would not be 1149.1 compliant
<azonenberg> What are you trying to do?
<azonenberg> libjtaghal has pretty well commented chain discovery algorithms i think
<OmniMancer> it might just be urjtag being bad at its job, or the jtag cable driver being strange
<OmniMancer> also USB forwarding to virtualbox is being a pain now :/
<OmniMancer> azonenberg I suspect the device is working as expected
<OmniMancer> azonenberg I am trying to get this to work with my Anlogic device https://github.com/Icenowy/urjtag-anlogic
<OmniMancer> which bit order is JTAG in? little?
Bird|ub3rghosted has joined ##openfpga
Bird|ghosted has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
<OmniMancer> azonenberg, for some reason when it tries to do detection it doesn't get an ID code out after reset, but if you just do only what is needed to get the ID code that works
<azonenberg> interesting
<OmniMancer> it does a reset, then captures the DR and clocks one bit out
<OmniMancer> checks if it's a 1
azonenberg_work has quit [Ping timeout: 246 seconds]
<OmniMancer> it does not get a 1, and if I try to get the rest of the bits they also seem to all be 0s
Maya-sama has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
Maya-sama is now known as Miyu
<OmniMancer> why is the JTAG interface so annoying to drive from a micro controller :/
Miyu is now known as hackkitten
jn___ is now known as jn__
show1 has quit [Ping timeout: 240 seconds]
show1 has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
OmniMancer has quit [Quit: Leaving.]
<keesj> urjtag never failed on me, jtag adapters did
mickdermack has quit [Quit: The Lounge - https://thelounge.chat]
<GenTooMan> JTAG ... sigh.
mickdermack has joined ##openfpga
emeb has joined ##openfpga
<whitequark> jtag is such an elegant protocol
<whitequark> too bad 98% of the real world uses of jtag are actively sabotated by this elegance because they do not fit its domain at qll
mumptai has joined ##openfpga
<GenTooMan> Well yes sometimes necessity and reality countermand ones aesthetic ideals of how something should be used. It's original intended purpose turned out to be less important than having a usable interface for configuration debug et al.
<whitequark> or you could simply not use JTAG for those
m_w has joined ##openfpga
azonenberg_work has joined ##openfpga
m_w has quit [Quit: Leaving]
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
rohitksingh has quit [Ping timeout: 265 seconds]
nrossi has quit [Quit: Connection closed for inactivity]
<GenTooMan> Unfortunately their is no obvious solution to the problems created by the use or lack of use with JTAG. Companies have to use something, at least JTAG is still a sort of standard.
<whitequark> the use of JTAG for configuration or debug is anything but standard
<whitequark> the best you get is IEEE 1532, which doesn't buy you much
<whitequark> in fact, since both of those applications use JTAG as a framing, something it is unsuited to be, they are very inefficient when layered over JTAG. this helps no one except a bunch of companies that reap absurd profit selling overpriced JTAG probes
<mwk> IEEE 1532 barely standardizes anything at all
<whitequark> mwk: hence "doesn't buy much"
<mwk> yeah, I fully agree
<whitequark> I think IEEE 1532 at least prevents you from using the infinite DR trick
<mwk> ... okay, fair point
<whitequark> so in a way it really makes sure that your configuration process is as slow as possible
<tpw_rules> so do those overpriced jtag probes actually do anything? what's the value in a j-link? i've never worked it out
<whitequark> they do, and it's very simple conceptually
<whitequark> a generic jtag adapter has the host software (eg openocd) generate the test vectors, and most of them need to be responses to something the previous vector returned. this goes contrary to the intended primary use of JTAG, well, boundary scan, which can be pipelined indefinitely
<whitequark> if you do lots of roundtrips to the adapter (when debugging a MIPS CPU via EJTAG, one "stepi" in gdb means a few hundreds of roundtrips), the latency of the adapter interface tends to become an issue
<whitequark> this is very acute with USB
<whitequark> again using MIPS EJTAG as an example, a single stepi for MIPS EJTAG takes something like a second with Glasgow, and Glasgow's USB interface is very fast
azonenberg_work has quit [Ping timeout: 240 seconds]
<whitequark> so an expensive JTAG probe implements the debugging logic in hardware, where you're limited solely by the speed of the interface itself
<tpw_rules> couldn't glasgow do that too though? at least in gateware
<whitequark> in some cases it can also blast the JTAG interface itself really fast, but you get quickly limited by the TCK capacitance
<whitequark> glasgow could, if someone put in the work, yes
<whitequark> it doesn't do it right now so it's comparable to a dumb USB probe
<tpw_rules> ok
<tpw_rules> so there is value, but of course not as much as they charge.
<GenTooMan> you are paying for custom software which is in high demand but not volume.
<whitequark> reportedly devices that can do weird shit like DDR over JTAG cost some tens of thousands
<whitequark> GenTooMan: yeah and this demand is created solely by picking an interface unsuitable for the task
<whitequark> genius move, really
<GenTooMan> all for the greater good obviously
<TD-Linux> the black magic probe is an open source example of a jtag probe with all the logic on it
<TD-Linux> I suppose you could port the firmware to a soft cpu and run it on the glasgow
<tpw_rules> but it seems to be targeted only to arm cortex?
<tpw_rules> but yeah i knew about that one
<tpw_rules> is SWDIO any better
<whitequark> TD-Linux: won't fit
<davidc__> And a bunch of the custom is just adding workarounds for all the "unique features" in various supposedly compatible silicon
<whitequark> tpw_rules: SWD is kind of weird because it's a different serialization for the ARM JTAG debug port
<GenTooMan> the legal term is "allegedly" compatible :D
<whitequark> it's more reasonable, certainly. lower pin count too
<tpw_rules> but not 1
<tpw_rules> :P
<whitequark> better than many other low pin count JTAG serializations out there (*cough* MSP430)
<whitequark> it's hard to do a truly 1 pin debug port because it has to be self-timed
<tpw_rules> well yeah, but then marketing happened
<whitequark> it's called "Serial Wire Debug", no?
<GenTooMan> yeah SBW is a mux of 3 or 4 JTAG pins using a serial clock for it.
<whitequark> i know what SBW is, i implemented it
<tpw_rules> oh i guess it is
<GenTooMan> I commiserate for you then.
<tpw_rules> i always had it in my head that it was single wire debug
<tpw_rules> which it plainly wasnt
<TD-Linux> obviously the solution is MFM JTAG
<tpw_rules> RLL*
<GenTooMan> but which RLL encoding? 4:6 4:5 ... etc.
<mumptai> btw, anyone used the xilinx virtual cable protocol with a custom/diy jtag adapter?
mumptai has quit [Quit: Verlassend]
Asu has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
biot has joined ##openfpga
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
emeb has quit [Quit: Leaving.]