Andrew Zonenberg
@aleksorsist @urja No, you're missing the point.
Because you're running on the output of the 8:1 serdes, your trigger logic is at 125 MHz. But the *input* can still toggle faster than that (remember the frontend BW is what. 300+ MHz?)
So you need to consider what happens if you have >1 toggle in that 8-bit stream of samples. You may need to advance more than one state in a single clock cycle.
✧✦Catherine✦✧
@azonenberg @aleksorsist @urja you would unroll the state machine N times and pipeline, I think
Andrew Zonenberg
@aleksorsist @whitequark @urja What I don't know is what the cleanest programming model for an end user developing triggers for this is going to look like.
✧✦Catherine✦✧
@azonenberg @aleksorsist @urja RTL and partial reconfig :p
Andrew Zonenberg
@aleksorsist @whitequark @urja Lol.
A VLIW processor may actually end up being the logical implementation of this. Who knows.
But the more I think about it, the more I lean towards a two-part system with a bunch of parallel function blocks that output one or more bits every cycle (each block having a bunch of config registers to specify muxing and thresholds and such), then a serial state machine operating on their output.
Andrew Zonenberg
@whitequark @aleksorsist @urja Exactly what I was getting at. It's solvable, but not trivial.
You'll probably need multiple replicated copies of the logic and some speculation or replication to handle multiple cases in parallel then figure out what happened the next cycle or something.
Aleksorsist
@azonenberg @whitequark @urja I joked about it being a quasi CPU and it is quickly becoming straight up a CPU, I love it
Aleksorsist
@azonenberg @whitequark @urja guess we doin HDL now. Once I finish these damn boards
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.