<azonenberg>
SMA test board now has a 4 GHz bandpass on it
<azonenberg>
as a test
<monochroma>
oooooo!
<monochroma>
RF black magic
<azonenberg>
Can you figure out how it works?
<monochroma>
looks like an RC filter? capacitive coupling filter and stubs
<azonenberg>
Not quite
<azonenberg>
So the first stage is a hairpin bandpass filter. It's basically the classic "parallel coupled lines" filter but folded over on itself to form a 2D layout rather than a substantially 1D layout that's super long and skinny
<azonenberg>
the idea is that each U resonates at the target frequency, and is coupled over half a wavelength to the next one
<azonenberg>
sorry a quarter wavelength
<azonenberg>
That already is a fairly decent bandpass for 4 GHz, but it also passes harmonics at 8, 12, 16, ...
<azonenberg>
the three stages of stubs are tuned to 8, 12, and 16 GHz to notch out the harmonics
<azonenberg>
And then past 16 GHz i didnt care because losses on oshpark pcb are too high for it to make a difference anyway :p
<monochroma>
hehe
<azonenberg>
I'm only going to be able to VNA this to 6 GHz but i'm gonna try and get derek from gnuradio to throw it on a higher spec VNA and see how the stubs work at suppressing the harmonics
<azonenberg>
I chose 4 GHz as the passband because it was high enough frequency that it was going to produce tolerably small filters
<azonenberg>
but low enough that i'd still have some room to see the stopband before my vna maxed out
<monochroma>
heh
<azonenberg>
With just the hairpin, the 8 GHz passband was almost as strong as the fundamental
<azonenberg>
and 12/16 were just a mess, i'm not sure what happened there
<azonenberg>
i think probably some other dimension of the structure - perhaps the spacing between hairpins - was resonating
<azonenberg>
which makes sense considering that the 16 GHz notch stub at far right is about the same size as the gap across the U of the hairpin
Tost has joined #scopehal
<Degi>
How much do the stubs capacitively load it at 4 GHz?
<Degi>
Oh, it has like -6 dB at 4 GHz
<azonenberg>
Yeah. That's mostly from the tiny capacitance i think
<azonenberg>
I couldnt make them any closer on oshpark design rules
<azonenberg>
the hairpin was like that originally
<azonenberg>
the stubs dont make it any worse really
<Degi>
Hm, I mean the 8/12/16 GHz stubs
<azonenberg>
There's a small amount of insertion loss but not much
<azonenberg>
more importantly that loss is pretty flat
deanforbes_ has quit [Read error: Connection reset by peer]
kc8apf has quit [Read error: Connection reset by peer]
deanforbes_ has joined #scopehal
kc8apf has joined #scopehal
wbraun has quit [Ping timeout: 276 seconds]
wbraun has joined #scopehal
<d1b2>
<mubes> Anyone who knows the SWD Decoder...do you know why the bits were slipped to align with the Target Reads rather than Host Writes? All the ARM documentation is Host-Write aligned and it's much more natural feeling. Here it is TargetAligned;
<d1b2>
<mubes> The host-alignment is a one line change and it was already in there and commented out, so it was obviously a concious decision to go this way, but personally I'd rather align with the ARM documentation, especially when I'm bug-hunting, which looks like this;
<d1b2>
<mubes> It doesn't affect the decode , only the relative positioning of the decode onscreen.
<azonenberg>
mubes: howabout making it configurable?
<azonenberg>
add an enum parameter to the decode, make it default to host aligned
<azonenberg>
i dont have strong feelings one way or the other though
<azonenberg>
if you think it makes more sense to always be host aligned that works too
<d1b2>
<mubes> I've never seen it shown target-aligned (although it's sampled at the rising edge in the middle of the bit time, obviously). I personally think it's confusing but just wondered if there were other arguments....whoever wrote this (you?) obviously considered making it host-aligned because the line to do it is there but commented out...for 'normal' protocols you'd obviously do it that way, but ARM are a rule until themselves 😕
<d1b2>
<mubes> I'll do a patch
<azonenberg>
yeah i probably just wasnt THAT familiar with the arm convention
<azonenberg>
i'm pretty sure i wrote this decode
<d1b2>
<mubes> fair enough. I'll move it to 'arm convention' as opposed to 'normal' then 🙂
<azonenberg>
i'll be honest you're probably the first person to actually use the SWD decode seriously
<azonenberg>
Wouldn't surprise me if you find other issues too
<azonenberg>
But hey, glad to see it's useful :)
<d1b2>
<mubes> Yeah, there are a couple of hiccups. Most serious outstanding one being that it doesn't recognise line resets
<d1b2>
<mubes> ...but it sorts itself out in the end
<azonenberg>
Feel free to send patches for any such fixes. it would be nice to recognize resets and maybe even decode the reset sequence as an event in the decode stream
<azonenberg>
as upper layer decodes might want to know the link was reset
<d1b2>
<mubes> So you get this, which is a bit messy;
<azonenberg>
very likely i just never saw a reset in the test waveforms i wrote the decode from
<azonenberg>
and completely missed it
<d1b2>
<mubes> Oh, I'
<d1b2>
<mubes> ve got no problem generating resets 🙂
<azonenberg>
lol
<d1b2>
<mubes> It's the other bloody stuff I can't get my head around
<azonenberg>
Meanwhile, here I am deep enough in Intel specification hell that I'm trying to figure out how to report documentation errors
<azonenberg>
i spent way too much time looking at the wrong figure
<azonenberg>
because the documentation for a particular bus command references figure 37 when it should say figure 35
<azonenberg>
so of course everything wasn't lining up
<d1b2>
<mubes> At least at ARM there are eventually humans you can talk to who design the stuff. Intel, I'm not so sure.
<azonenberg>
I have successfully reported errors in coresight manuals before
<d1b2>
<mubes> AMD were great for easy access back in the day (29K bitslice stuff), but you had to constantly stop yourself pinging design authority and keep it for special occasions.
Tost has quit [Ping timeout: 240 seconds]
<azonenberg>
When I was working on the GreenPak HDL toolchain back in the day
<azonenberg>
I reported so many errors that eventually i had direct access to their datasheet engineers
<d1b2>
<mubes> Ha ha, @zyp has just started a love affair with those chips
<d1b2>
<mubes> ...he managed to wangle two onto our board
<d1b2>
<mubes> for sure, I was impressed. The dinky linear regulators are great for the price
Stephanie is now known as Stephie
<_whitenotifier-5>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JOaLT
<_whitenotifier-5>
[scopehal] azonenberg b6e7607 - eSPI: Implemented wait states in response. Added parsing of Put I/O Write Short command. See #407.
<_whitenotifier-5>
[scopehal] azonenberg 781cfca - eSPI: Added parsing of split completions. Can now merge I/O write completions with the original request. See #407.
<azonenberg>
for something whose name implies it's just a variant of SPI
<azonenberg>
eSPI is... quite complex
<azonenberg>
and the best part is it's *not* even spi
<azonenberg>
they have a 2-cycle bus turnaround between read and write
<azonenberg>
which is a byte long in quad mode, but in x1 mode is only two bits long
<azonenberg>
so a byte oriented spi parser can't read it :p