Help us develop the next-generation software, now in alpha!

Add a synchronous state capture mode

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.

http://support.saleae.com/hc/en-us/articles/200591565-I-need-to-record-25-MHz-SPI-flash-data-How-can-I-do-this-with-Logic16-

  • Anders
  • Jul 11 2018
  • Future consideration
  • markb82 commented
    July 11, 2018 21:13

    @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 commented
    July 11, 2018 21:13

    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 commented
    July 11, 2018 21:13

    The more I use Saleae Logics, the more useful this woukd be!

  • John N commented
    July 11, 2018 21:14

    +1 for supporting external clock

  • KaKaRoTo commented
    July 11, 2018 21:14

    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 commented
    July 11, 2018 21:14

    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 commented
    July 11, 2018 21:14

    This feature would be tremendously useful. I'd give it all 9 votes if I could!

  • Admin
    Joe Garrison commented
    23 May 14:06

    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)