Skip to main content ↑ ↓
Topic: Captures above 4K\8K not accurately recording data (Read 4039 times) previous topic - next topic

Captures above 4K\8K not accurately recording data

I am running version 2.04 of the FPGA firmware and 0.4v of the pic software but I had this issues on the previous releases as well.  When I try and capture over 8K x 32 channels samples and trigger on a pulse the triggered data does not show up, the trace does not appear to change state.  It works with 4K8K and under sample depth, I have had it not work a few times at 8K so that seems to be the tipping point.

Here is how to recreate the issue:
1) Record 32 channels
2) Record over 8K sample depth, I did 16K in the picture below
2) Sample rate 100Mhz or 50Mhz, the pulse I am triggering on only last a few cycles at 50Mhz
3) Trigger on a data line that pulses quickly

Below is a screen capture at 4K & 16k.  At 4K you can see that it captures the pulse fine at 16K you see the trigger line but no pulse??  I am triggering when channel 1 goes low.

Re: Captures above 4K\8K not accurately recording data

Reply #1 –
How many channels did you use at 16k? If I remember correctly, it supports only 4k samples for 32 channels, but more for 16 or 8 channels. So it sounds just like an issue with the software not enforcing the hardware limits.

Re: Captures above 4K\8K not accurately recording data

Reply #2 –
alm,, you are correct! Bitstream release 2.04 only supports up to 4k samples for 32 channels. Up to 8k samples are supported for 16 channels (requires channel groups 3 and 4 to be disabled in the capture window of the latest version of the SUMP Java client (analyzer.jar - included in 2.04TestRelease.zip)!

Re: Captures above 4K\8K not accurately recording data

Reply #3 –
I have now set the sample depth to 16K on 8 channels but still have the same problem, no data line change on the trigger, 8K sample depth and below works.  According to this write up 16K by 8 channels is supported, has this changed in v2.04?  This happens with or without the updated the analyzer.jar file.

Also I found a whole new issue, when RLE is enabled with a constant clock signal on channel 0 with groups 0, 0-1, or 0-2 selected (works correctly with 0-4 selected) the captured data on all other channels is the same as the clock signal on channel 0.

Re: Captures above 4K\8K not accurately recording data

Reply #4 –
Quote
Also I found a whole new issue, when RLE is enabled with a constant clock signal on channel 0 with groups 0, 0-1, or 0-2 selected (works correctly with 0-4 selected) the captured data on all other channels is the same as the clock signal on channel 0.

I think this is a current limitation of the SUMP bitstream. RLE is a late addition (not part of the original design), and I believe it only works in 32bit mode because of  how it stores an extra bit.
Got a question? Please ask in the forum for the fastest answers.

Re: Captures above 4K\8K not accurately recording data

Reply #5 –
LukeS, I spoke with Jack a few hours ago and he confirmed that only the features listed in ChangeLog.txt are currently supported in bitstream release 2.04 provided you use the latest SUMP Java client (included in 2.04TestRelease.zip):

Quote
5/25/2010 Test Release 2.04
   -Still uses SPI mode
   -If channel group 3 and 4 is disabled the 8K of memory depth is available.
   -When all channel groups are selected then 4k of memory depth is available.
   -Supports inside and outside number scheme.
   -Supports Test mode.

The 8 channel modes are not supported by the release 2.04 bitstream! It is the goal to merge the seperate bitstreams for 32, 16 and 8 channel captures into one bitstream. To accomplish this and to make the different configurations selectable from the client, Jack had to extend the original protocol, modify the client in addition to implementing and testing the VHDL code for the bitstream. Due to the reports of the communication problems with the UART he shifted the priority towards the SPI interface and rolled the 2.04TestRelease out without support for 16k samples for 8 channels. It's main purpose is to run a beta test to get the new SPI interface tested. For now only
- up to 4k samples for 32 channels
- up to 8k samples for 16 channels (if channel groups 3 and 4 are disabled in the capture menu)
- test mode
are available in release 2.04. No checking is performed if the selected recording size matches the available memory in the FPGA.