Whole-known-network
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> The other challenge will be how to handle higher speed serial-ish protocols that might change states quickly.</p><p>With 4-channel mode it's easy because you can run trigger logic at 250 MHz and have one set of updates per cycle.</p><p>But with 1-channel mode you can't clock the trigger logic at 1 GHz, so you have to consider what happens if you have more than one transition in the signal in a single clock cycle of the trigger state machine. This will only get worse as you transition to faster ADCs in the future and the number of ADC samples per FPGA clock grows.</p><p>I don't have all the answers, just pointing out design considerations.</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> Running completely based on sample counting won't work for any kind of firmware based DUT that has jitter in timing (e.g. bitbanged SPI bus that might have unpredictable frequency based on interrupts)</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> So maybe instead you have</p><p>state 3) wait 1ms, if A still low trigger, else go to 1</p><p>(to catch a SPI transaction that gets stuck and never terminates)</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> You can add support for fixed time delays as well as edge detection based timing. Different protocols (e.g. SPI vs UART) would work more naturally for one or the other.</p><p>They're all just event sources feeding into the state machine.</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> When I say "clock" I mean in the digital domain.</p><p>You're doing everything in the ADC sample domain anyway, but you can emulate clocked logic by looking for a 0-1 transition on the clock input and gating the enable to the block on that</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> ah, you want to clock off the signals, gotya. I was thinking of basing everything off of counting samples so it'll work more generally for say, analog / power sequencing stuff</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> Yeah. So what you want IMO is a series of always-enabled data processing blocks, then microcode/state machine that acts on their output.</p><p>So for example</p><p>HARDWARE BLOCK CONFIG<br />A) edge detect CH1<br />B) edge detect CH2<br />C) edge detect CH3<br />D) 8-bit shift register, clk=CH2 rising, data=CH3, reset=CH1 falling</p><p>STATES<br />1) on falling edge A: go to 2<br />2) on data available D: go to 3 if 0x41, else go to 1. On rising edge A, go to 1<br />3) on data available D: trigger if 0x42, else go to 1. On rising edge A, go to 1</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> that's actually more what I'm thinking. Basically the modules are always looking at the data, it's just new parameters that get clocked in once the previous condition is met. I can't think of a trigger that doesn't need a sequential list of conditions (with commands across channels treated kinda like multi-threading)</p>
<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@aleksorsist" class="u-url mention">@<span>aleksorsist</span></a></span> <span class="h-card" translate="no"><a href="https://social.treehouse.systems/@urja" class="u-url mention">@<span>urja</span></a></span> but my vision is less of a CPU and more of a coarse grained dataflow architecture where you have different modules analyzing the data in parallel, then outputs that feed into some kind of decision block</p>