balrog has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
<pie_> rqou, you should just get a red phone to azonenberg's house :ppp
<rqou> lol
<rqou> but azonenberg isn't russian :P
<rqou> and i usually don't need to bother whitequark nearly as much :P :P
<awygle> get a batphone
<pie_> haha
<rqou> wait, awygle i think i can bother you with this question too
<rqou> awygle: how familiar are you with jtag?
<awygle> rqou: pretty. Why?
<rqou> the max v has a jtag primitive that is undocumented
<rqou> and their high-level wrapper is encrypted
<rqou> but i can look at the primitive itself and see the port names and directions
<awygle> Okay..
<rqou> so i'd like some guesses as to what the jtag block is doing
<rqou> *might be doing
<rqou> anyways, the jtag block has an input (from the fabric, to the block) called "tdouser"
<awygle> TDO from the User, sure
<rqou> and then outputs (from the block, to the fabric) tmsutap
<rqou> clkdruser
<rqou> shiftuser
<rqou> tckutap
<rqou> updateuser
<rqou> tdiutap
<rqou> runidleuser
<rqou> usr1user
<rqou> the way this is "supposed to work" is that there are two opcodes, USER0 and USER1
<rqou> and these somehow cause the jtag block to forward the information to the fabric
<awygle> sure
<rqou> and that's all the info available
<rqou> i'm probably going to need to use a logic analyzer and test against the hardware, but having some guesses now might be helpful
<awygle> looks like it just exposes a TAP to fabric and a bunch of status signals telling you what state the jtag state machine is in
<rqou> but it also just gives me access to tms/tck?
<awygle> is there a usr0usr?
<rqou> no
<awygle> that's a bit surprising
<awygle> but everything else makes sense
<awygle> I'd run it to see whether you *always* see tms/TCK or only when you're in USER0 or USER1, that's about it
<awygle> I'd guess USER0 muxes this TAP into the chain and USER1 is for access or something like that
<rqou> no
<rqou> the documentation for the high-level primitive explains that it creates a second "virtual" jtag state machine
<rqou> and whether the virtual state machine enters shift-ir or shift-dr is decided by whether the real jtag gets a user0 or a user1
<rqou> yeah, big overcomplicated thing
<awygle> that's... a weird design
<awygle> But not the weirdest I've seen
<awygle> I wonder if it matches the ASPs actually... Sec
rohitksingh_work has joined ##openfpga
<rqou> it also has a fancy mux thingy so that you can have your custom function, NIOS debugging, _and_ the internal logic analyzer all at once
<rqou> it's also huge and unsuitable for max ii/max v, but altera basically seems to say "too bad, suck it" to those people
<awygle> mm no not really
<awygle> anyway I don't have any particular insights but it doesn't seem too complicated. if your tests show weirdness I might be able to help with that.
<rqou> i don't get why this primitive is undocumented in the first place
<rqou> the flash memory block is documented
<rqou> even though it has a warning that if you mess it up you will corrupt the flash
<rqou> oh, the flash memory also has some undocumented wires, but idk if they actually exist or not
<awygle> ah yes, They Might Be Wires
<awygle> Make A Little JTAG In Your Soul
wpwrak has quit [Ping timeout: 240 seconds]
<tnt> esden: just randomly watched your stream from yesterday. And if you ever want to make that BBS thing, something I've been playing with recently is implementing an E1 interface on a ice40 :)
wpwrak has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<azonenberg> That actually looks very much like xilinx's stuff
<azonenberg> except xilinx has the mux in hardware
<azonenberg> And you have four BSCAN primitives, one per instruction
<azonenberg> Conjecture: tck/tdi utap are tck/tdi from the outside of the chip
<azonenberg> shift/clkdr/update/runidle are one-hot state flags (no capture or reset option? interesting)
<azonenberg> i guess you have to do that yourself off TMS if you think you might need it
<azonenberg> tdouser is outbound TDO
<azonenberg> then usr1user is a boolean
<azonenberg> 1 = user1, 0 = user0
<rqou> azonenberg: want to speculate on something else?
<rqou> the flash memory block has an undocumented set of wires called "sbdin" and "sbdout"
<rqou> one is input, one is output
<rqou> what do you think these do?
<azonenberg> input and output for SBD, duh
<azonenberg> So the question is, what's SBD?
<azonenberg> first guess: single bit something
<azonenberg> but it could also be serial something
<rqou> well, the whole interface is serial :P
<rqou> there's an address shift register and a data shift register
<rqou> and then program/erase/busy signals
<rqou> i don't know what else they would put here?
<rqou> the sim model just directly connects the wires together
<azonenberg> awygle: ping
<awygle> azonenberg: I'm here but on my way out
<awygle> what's up?
<azonenberg> awygle: see my tweet thread with harmon instruments when you get a chance
<azonenberg> See what you think about the jitter numbers i calculated based on his frequency-dependent dispersion graphs
<azonenberg> i dont know if i'm doing it right
<azonenberg> but tl;dr i calculate for the worst case backplane path, about 0.28 UI of horizontal eye closure due to backplane effects
<azonenberg> (this is on top of jitter in the SGMII data)
<awygle> located. let me skim it... I'll do math tomorrow
<awygle> (also, "the prototype vna" is very relevant to my interests)
<awygle> lots of interesting (and counterintuitive) data in that thread
<awygle> your approach seems reasonable offhand, I'll dig in more tomorrow
<awygle> I think the ps-to-UI conversion may not be that straightforward but I want to check some stuff
* awygle zzz
<azonenberg> 1 UI = 800 ps @ 1250 Mbps
<azonenberg> The question is, how does that dispersion actually shrink the eye? I'm modeling it as if the entire eye shrinks, but i'm not so sure it works like that
<azonenberg> in particular the really high harmonics likely dont play a huge role
<azonenberg> But the dispersion is mostly at the low end
<azonenberg> Which is kinda key
<azonenberg> The other thing is, the major dispersion is at the very low end of the spectrum
<azonenberg> ... derp
<azonenberg> it's worse than i thought
<azonenberg> the worst case for 8b10b is, i think, five of one bit and five of the other in a row
<azonenberg> so 1/10 the baud rate
<azonenberg> or 125 MHz, not 250
<azonenberg> so dispersion in that case (which is unfortunately very close to what you'd get with 8b10b comma characters during a SGMII idle/bringup) would be pretty bad
mwk has quit [Ping timeout: 265 seconds]
mwk has joined ##openfpga
ondrej2 has joined ##openfpga
bitd has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 256 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
pie_ has joined ##openfpga
Bike has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 255 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work> rqou: do you think i've given whitequark enough CPU architecture puns? :P
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
azonenberg_work has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
G33KatWork has quit [Ping timeout: 265 seconds]
wpwrak has quit [Ping timeout: 240 seconds]
G33KatWork has joined ##openfpga
wpwrak has joined ##openfpga
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale has joined ##openfpga
mumptai has joined ##openfpga
m_w has joined ##openfpga
lexano has quit [Ping timeout: 264 seconds]
<rqou> whitequark why are you working on electrical problems?
lexano has joined ##openfpga
<esden> tnt: that sounds very useful. I was talking with Jared about this, he is considering or even working on implementing T1 on an ice40 ;-) I have the feeling he avoids bigger channels and IRC in general as it is a big distraction, but it would be good if more heads could be put together to get some interesting IP together... :)
<tnt> esden: E1 and T1 are basically the same thing just a different clock rate and a different number of time slot.
<tnt> but going from one to the other is nearly trivial.
<esden> yeah, that is what I figured. ;-) I bet an ip with enough params would be able to be used for most of the encodings/modes...
<esden> if you have it published somewhere I could point Jared that way ;)
<rqou> esden, tnt: do you want me to try to nerdsnipe my father into helping? he has very extensive experience with T1/E1
<esden> still, the softmodem functionality would have to be implemented on top of that obviously... but having the lowlevel part done is for sure good improvement
<tnt> rqou: it's basically done already ... at least the E1 part.
<esden> rqou: definitely, especially if he has some test equipment for that stuff. It would be good to test against some real equipment, as shadytel is running usually standard AT&T hardware so we will have to talk to that ;)
<esden> tnt: sounds good, but have you tested it for robustness and compatibility with real equipment?
<rqou> what exactly _is_ shadytel?
<rqou> other than a joke birbsite account?
<esden> rqou: :P
<tnt> now I'm working on the 'USB' part (since what I'm trying to do is a E1 <-> USB adapter because most E1 card are PCI and that's just inconvenient for modern SBC and rpi-like stuff).
<esden> rqou: they are the "telephone company" of toorcamp at least :)
<esden> you get your landline connection to your tent from them... after you fill out a pretty massive application form and bribe them accordingly
<esden> it is a fun thing to do at toorcamp ;-)
<tnt> esden: I tested it against a E1 card and against the official 'test cases' from the specs. But it's really simple ... E1 is really just a way to frame 32 time slots of 8 kbits, there is really nothing to it.
<esden> that is why I want to provide a BBS there in two years... but knowing that in the past CCC also had a landline service, I might want to bring that to CCCamp next year too...
<tnt> All the higher level call-control and stuff like that is a layer above and not part of E1/T1 itself.
<rqou> ok, apparently my father has a T1/E1 test set
<esden> tnt: fair enough :)
<rqou> currently asking if it's in the garage or on loan to somebody :P
<esden> rqou: that might do more than just the lowlevel basic E1/T1 stuff too?
<rqou> i don't know
mumptai has quit [Quit: Verlassend]
<esden> if it is a handset, then it will also decode the channels to audio ...
<esden> I would assume
<rqou> ok, apparently it's in the garage so i can go check this evening
tinyfpga has quit [Ping timeout: 245 seconds]
<esden> rqou: make PHOTOS! :D
<tnt> esden: Pretty sure if you ask the POC guys they'll be able to give you an E1 :) I think at some point we had our GSM network connected to the POC via E1. We also ran some Nokia BTS over E1 a couple of camps ago.
<esden> tnt: that is what I vaguely remembered, I just never cared enough to retain any of it :D
tinyfpga has joined ##openfpga
<rqou> esden: apparently it's a FIREBERD 6000A
<dfgg> whitequark: nice fan mate.
<esden> rqou: ohh cool, nice VFD on that specimen :)
<esden> <- that thing right?
<rqou> i think so
<openfpga-bot> [jtaghal-apps] azonenberg pushed 1 new commit to master:
<openfpga-bot> jtaghal-apps/master d63e929 Andrew Zonenberg: Added command line argument for FTDI layouts
<openfpga-bot> [jtaghal] azonenberg pushed 4 new commits to master:
<openfpga-bot> jtaghal/master e5a2e53 Andrew Zonenberg: Reformatted error messages
<openfpga-bot> jtaghal/master 61296b0 Andrew Zonenberg: Added support for FTDI layouts and jtagkey
<openfpga-bot> jtaghal/master b3a5e96 Andrew Zonenberg: Reformatted exception messages
<openfpga-bot> [jtaghal-cmake] azonenberg pushed 2 new commits to master:
<openfpga-bot> jtaghal-cmake/master 05e5041 Andrew Zonenberg: Updated to latest jtaghal and apps
<openfpga-bot> jtaghal-cmake/master d262791 Andrew Zonenberg: Added gitignore for build directory
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
Bike has quit [Ping timeout: 260 seconds]
<q3k> random twitter thread that reminded me people don't use mag holders often enough for holding scope probes:
<ZipCPU> Just updated my pipelined FFT generator, for anyone interested. You can find it at (Now I just need to update the document describing it ...)
Bike has joined ##openfpga
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master:
<openfpga-bot> jtaghal/master a8cb0ef Andrew Zonenberg: Added ARM stuff to CMake scripts. Now calculate # of IR bits in preparation for bypassing unused devices
<azonenberg_work> q3k: when i heard "mag holder" i thought something very different
<azonenberg_work> rqou: so guess what?
<azonenberg_work> jtaghal is finally going to be getting multi-device support
<azonenberg_work> Doing some research stuff for $work and i pretty much have to support it
<cr1901_modern> So I just re-discovered ice40 is 5v tolerant. I've been attaching the GPIO breakout of icestick to pullups to 5V for over a year now lol.
<cr1901_modern> Someone else did that in this channel before but I forget who
bitd has quit [Ping timeout: 245 seconds]
m_w has quit [Quit: Leaving]