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.
Anders
@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.
Attachments Open full size
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.
Attachments Open full size
The more I use Saleae Logics, the more useful this woukd be!
Attachments Open full size
+1 for supporting external clock
Attachments Open full size
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.
Attachments Open full size
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....
Attachments Open full size
This feature would be tremendously useful. I'd give it all 9 votes if I could!
Attachments Open full size
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)
Attachments Open full size