2
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Interesting.</p><p>The most complex JTAG topology I recall seeing was XC7Z with an ADIv5 TAP and a boundary scan TAP (IIRC the FPGA program/debug TAP was also the boundary scan TAP).</p><p>But there was an option to split the two via EMIO and have separate TAPs for the FPGA and ARM using FPGA GPIOs to debug the ARM, which I actually tried once.</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> Glasgow is my project</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> (also just one girl? I thought you were plural :P)</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> multidrop SWD is basically a requirement for some modern low-power RF SoCs from Nordic and stuff, it&#39;s kind of a big deal actually</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Multidrop SWD????</p><p>Honestly I find even multidrop JTAG is very rarely used. The most I see is like a boundary scan TAP and a programming/debug TAP on a single physical chip, but multiple packages in one scan chain are not common.</p><p>Vendor tooling being the main reason. I made a STM32 + Artix-7 board once and found it was near impossible to debug the system because I had to keep jumping between Vivado and OpenOCD and couldn&#39;t use both simultaneously to look at ILA and firmware view of the system.</p><p>And that&#39;s even before you get into voltage level compatibility issues.</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> anyway, my concept for building fast MCU/etc dumpers is that i want you to be able to describe an algorithm in a Python-based set of instructions (you could call it a DSL but it&#39;s really just a series of commands) that gets transformed into a command stream for the FPGA. you know, sort of like GPU command buffers</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> what scares me though is ADIv5.2 with complex stuff like multidrop SWD. it&#39;s just really expansive and i&#39;m like one girl</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> i have an unfinished branch. there are a few things in the core architecture that i want to improve that i had to make a detour into building Amaranth infra for first (streams in particular, they&#39;re basically AXI-Stream compatible)</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Do you have hardware ADIv5 support for fast dumping of modern MCUs?</p>