Having a way to designate one of the signals as a clock and registering the other signals would be a great addition for sniffing higher speed synchronous buses such as JTAG or SPI, even DDR SDRAM. This would allow capturing 2x to 4x faster clock rates than is currently feasible because you only need to record one sample per clock, not 4 or more.
For some things, it's also easier to just see it from the point of view of what was registered on the bus, without worrying about exactly when. It's a little-bit higher level.
Now that you have that spiffy Spartan-6, let's put it to work! It should be fairly straight-forward to use its IO resources, DDR flip-flops and clock muxes to select a clock and to register the other signals.
markb82 Jul 11, 2018
@Mark Garrison: 99% that's pretty high slice usage :) Maybe an opportunity to play with partial reconfiguration? Too bad none of the pins go to a GCLK, but a work around could be to use a non-GCLK pin and suffer the delay (Xilinx tools will complain), then match the same delay using IODELAY2 primative. Just a thought.
Mark Garrison Jul 11, 2018
We're definitely keeping an eye on this, but it will have to wait for new hardware. The current products don't have any FPGA clock pins on the input bus. Also, fun fact - Logic Pro 8's FPGA has over 99% utilization - only 1 free slice remains :). Optimizing that is part of the reason the product launched later than expected.
We'll need to extensively look at what features people need from this before designing the next device. Especially for recording data clocked at 500 MHz.
MattSR Jul 11, 2018
The more I use Saleae Logics, the more useful this woukd be!
John N Jul 11, 2018
+1 for supporting external clock
KaKaRoTo Jul 11, 2018
I totally agree, you get my 3 votes! When it says 500MS/s, I'd like to be able to capture 500MHz signals, not just 125MHz due to the 4x oversampling.
Jazman Jul 11, 2018
This would also be a way to do the slow capture functionality where we want to use it as a data logger for a week or more. Just provide it with a very slow input clock to capture at whatever rate you want....
David Jul 11, 2018
This feature would be tremendously useful. I'd give it all 9 votes if I could!
Joe Garrison May 23, 2019
Is the main reason this is helpful is because of the increased sample rate? e.g. If the sample rate was 2G Samples/sec and the 'digital bandwidth' was let's say 500MHz, would that be sufficient?
I just want to gauge how much this issue goes away with higher sample rates and bandwidth. (Current digital bandwidth is 100MHz even if sampled synchronously I'm afraid)