Trigger implementation on ADC-FPGA

[Syed Huq]

Hi,

I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.

From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.

If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.

I'd appreciate any ideas on this. Thanks!

 

[GaborSzakacs]

Syed Huq wrote:

Hi,

I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.

From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.

If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.

I'd appreciate any ideas on this. Thanks!

The standard way to do capture that includes the trigger event is to
continuously store all data in a ring buffer. When the trigger occurs
you continue storing data for some length of time, but not enough to
wrap around the whole buffer and overwrite the trigger event. For
example, if you have a 2K deep BRAM buffer (2K samples, that is) then
you'd have an 11-bit write pointer that continuously places each
consequtive sample at the next location in BRAM, wrapping to location
0 after writing location 2047. Now if you want to capture 10 samples
before a trigger and the remaining 2038 samples after the trigger,
you'd just keep storing samples in the buffer for another 2038 samples
after triggering (you might need to adjust that based on the trigger
delay). When you're done, the write pointer stops incrementing and
you stop storing data. If your write pointer increments after the
last write, it will be pointing to the oldest data in the buffer.
The newest data will be at the previous location. The sample that
occured closest to the trigger event would be at the write pointer + 10.

--
Gabor

 

[rickman]

On 5/27/2014 12:49 PM, Syed Huq wrote:

Hi,

I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.

From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.

If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.

I'd appreciate any ideas on this. Thanks!

Your trigger can do anything you wish. Typically a device like this
will store data into memory continuously in a wrap around buffer while
waiting for the trigger. Then when the trigger is detected the address
of the appropriate sample is noted and collection continues until the
desired amount of data is stored.

On oscilloscopes they do this and allow the user to select the amount of
data to be retained from before the trigger. If you don't need any
significant amount of data from before the trigger, then you can use a
simple FIFO buffer to hold the N samples that would be missed because of
the trigger delay. Essentially this is a small wrap around buffer.

--

Rick

 

[Tim Wescott]

On Tue, 27 May 2014 09:49:04 -0700, Syed Huq wrote:

Hi,

I'm trying to implement hardware trigger functionality by modifying the
FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5
FPGA, and then implementing it on our custom board but I had a few
questions with regards to it.

From what I understand of how the trigger works, the data keeps being
captured continuously by the ADC, but the trigger functionality would
only kick in when the data is being stored. Am I right in that
assumption? Maybe I need to keep checking the trigger and only when the
board is triggered, I allow the data to be stored inside the internal
RAM of the FPGA? Or is there an alternate way to do this? I'm currently
storing the data samples using the Block RAM of the FPGA.

If my thinking is right, when the the board is triggered, and the data
starts being captured, I lose a few data samples due to the delay in the
trigger registering and then the data being stored. How do I overcome
this? Even a few nanoseconds of data is important in this case.

I'd appreciate any ideas on this. Thanks!

You want something that's sorta kinda like an oscilloscope?

In "wait for trigger" mode, store data all the time, to a circular buffer
in memory. When you get a trigger event, count out some number of
samples, then stop storing data. Then when you read out the buffer,
alias it so that the oldest sample is 0, the next is 1, etc.

This way, you can even capture data before the trigger event, if that's
important.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Syed Huq]

On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote:

Syed Huq wrote:

Hi,



I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.



From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.



If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.



I'd appreciate any ideas on this. Thanks!



The standard way to do capture that includes the trigger event is to

continuously store all data in a ring buffer. When the trigger occurs

you continue storing data for some length of time, but not enough to

wrap around the whole buffer and overwrite the trigger event. For

example, if you have a 2K deep BRAM buffer (2K samples, that is) then

you'd have an 11-bit write pointer that continuously places each

consequtive sample at the next location in BRAM, wrapping to location

0 after writing location 2047. Now if you want to capture 10 samples

before a trigger and the remaining 2038 samples after the trigger,

you'd just keep storing samples in the buffer for another 2038 samples

after triggering (you might need to adjust that based on the trigger

delay). When you're done, the write pointer stops incrementing and

you stop storing data. If your write pointer increments after the

last write, it will be pointing to the oldest data in the buffer.

The newest data will be at the previous location. The sample that

occured closest to the trigger event would be at the write pointer + 10.



--

Gabor

Thanks for the detailed explanation. To explain the code better, the samples are captured by the ADC, they are remapped by the ADC Remapper and the samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is generated by up-counters. So on the trigger, would I just record the address at that particular time and store samples for maybe the next 8K depth in order to preserve roughly ~200 depth of samples before the trigger ? I'm not particularly sure if the addresses are recycled again since I'm still trying to understand the code provided by TI for the board.

 

[GaborSzakacs]

Syed Huq wrote:

On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote:
Syed Huq wrote:

Hi,
I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.
From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.
If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.
I'd appreciate any ideas on this. Thanks!


The standard way to do capture that includes the trigger event is to

continuously store all data in a ring buffer. When the trigger occurs

you continue storing data for some length of time, but not enough to

wrap around the whole buffer and overwrite the trigger event. For

example, if you have a 2K deep BRAM buffer (2K samples, that is) then

you'd have an 11-bit write pointer that continuously places each

consequtive sample at the next location in BRAM, wrapping to location

0 after writing location 2047. Now if you want to capture 10 samples

before a trigger and the remaining 2038 samples after the trigger,

you'd just keep storing samples in the buffer for another 2038 samples

after triggering (you might need to adjust that based on the trigger

delay). When you're done, the write pointer stops incrementing and

you stop storing data. If your write pointer increments after the

last write, it will be pointing to the oldest data in the buffer.

The newest data will be at the previous location. The sample that

occured closest to the trigger event would be at the write pointer + 10.



--

Gabor

Thanks for the detailed explanation. To explain the code better, the samples are captured by the ADC, they are remapped by the ADC Remapper and the samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is generated by up-counters. So on the trigger, would I just record the address at that particular time and store samples for maybe the next 8K depth in order to preserve roughly ~200 depth of samples before the trigger ? I'm not particularly sure if the addresses are recycled again since I'm still trying to understand the code provided by TI for the board.

If by 8K you mean 8,000 and not 8,192 then what you said is correct. As
for recycling the address, any simple up-counter would go back to zero
after it reaches 8,191. The real question is whether the counter and
BRAM write enable are active all the time, or just after you trigger the
core. Of course you'd need to look through the code or ask someone
at TI if that is the case.

--
Gabor

 

[Syed Huq]

Well the folks at TI are not much help since they themselves outsourced the coding for the FPGA. The way I want the Trigger to work is that, when the trigger occurs, the data samples are stored for a few seconds. I also want to ensure that there is a bit of hold-off time within which another trigger cannot occur. How would I do that ?

On Wednesday, 28 May 2014 13:13:49 UTC-5, Gabor wrote:

Syed Huq wrote:

On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote:

Syed Huq wrote:



Hi,

I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it.

From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA.

If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case.

I'd appreciate any ideas on this. Thanks!





The standard way to do capture that includes the trigger event is to



continuously store all data in a ring buffer. When the trigger occurs



you continue storing data for some length of time, but not enough to



wrap around the whole buffer and overwrite the trigger event. For



example, if you have a 2K deep BRAM buffer (2K samples, that is) then



you'd have an 11-bit write pointer that continuously places each



consequtive sample at the next location in BRAM, wrapping to location



0 after writing location 2047. Now if you want to capture 10 samples



before a trigger and the remaining 2038 samples after the trigger,



you'd just keep storing samples in the buffer for another 2038 samples



after triggering (you might need to adjust that based on the trigger



delay). When you're done, the write pointer stops incrementing and



you stop storing data. If your write pointer increments after the



last write, it will be pointing to the oldest data in the buffer.



The newest data will be at the previous location. The sample that



occured closest to the trigger event would be at the write pointer + 10.







--



Gabor



Thanks for the detailed explanation. To explain the code better, the samples are captured by the ADC, they are remapped by the ADC Remapper and the samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is generated by up-counters. So on the trigger, would I just record the address at that particular time and store samples for maybe the next 8K depth in order to preserve roughly ~200 depth of samples before the trigger ? I'm not particularly sure if the addresses are recycled again since I'm still trying to understand the code provided by TI for the board.



If by 8K you mean 8,000 and not 8,192 then what you said is correct. As

for recycling the address, any simple up-counter would go back to zero

after it reaches 8,191. The real question is whether the counter and

BRAM write enable are active all the time, or just after you trigger the

core. Of course you'd need to look through the code or ask someone

at TI if that is the case.



--

Gabor

 

[Tom Gardner]

On 02/06/14 19:43, Syed Huq wrote:

The way I want the Trigger to work is that, when the trigger occurs,
the data samples are stored for a few seconds.I also want to ensure
that there is a bit of hold-off time within which another trigger
cannot occur. How would I do that ?

With a finite state machine, a clock, and a few counters.

 

[rickman]

On 6/2/2014 2:43 PM, Syed Huq wrote:
> Well the folks at TI are not much help since they themselves outsourced the coding for the FPGA. The way I want the Trigger to work is that, when the trigger occurs, the data samples are stored for a few seconds. I also want to ensure that there is a bit of hold-off time within which another trigger cannot occur. How would I do that ?

I'm not sure what you are asking. That is called logic design. I have
not looked at the existing code, but clearly the data is stored in a
memory with an address. You just need to set up a counter to generate
an address which increments each time a sample is stored in memory.
Obviously this would be either a pipelined design if a sample is stored
on each system clock or if the ADC to memory transfers are not so fast a
finite state machine can be used to control it all.

Does any of this mean much to you? What level is your background in FPGAs?

--

Rick