Trigger implementation on ADC-FPGA

Hi,

I'm trying to implement hardware trigger functionality by modifying the FPG=
A 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 wit=
h regards to it.=20

From what I understand of how the trigger works, the data keeps being captu=
red 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 ne=
ed to keep checking the trigger and only when the board is triggered, I all=
ow the data to be stored inside the internal RAM of the FPGA? Or is there a=
n alternate way to do this? I'm currently storing the data samples using th=
e Block RAM of the FPGA.=20

If my thinking is right, when the the board is triggered, and the data star=
ts being captured, I lose a few data samples due to the delay in the trigge=
r 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!

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

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

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

On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor  wrote:
> Syed Huq wrote:
>=20
> > Hi,
>=20
> >=20
>=20
> > I'm trying to implement hardware trigger functionality by modifying the=
 FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 F=
PGA, and then implementing it on our custom board but I had a few questions=
 with regards to it.=20
>=20
> >=20
>=20
> > From what I understand of how the trigger works, the data keeps being c=
aptured continuously by the ADC, but the trigger functionality would only k=
ick 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 the=
re an alternate way to do this? I'm currently storing the data samples usin=
g the Block RAM of the FPGA.=20
>=20
> >=20
>=20
> > 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 tr=
igger registering and then the data being stored. How do I overcome this? E=
ven a few nanoseconds of data is important in this case.
>=20
> >=20
>=20
> > I'd appreciate any ideas on this. Thanks!
>=20
>=20
>=20
> The standard way to do capture that includes the trigger event is to
>=20
> continuously store all data in a ring buffer.  When the trigger occurs
>=20
> you continue storing data for some length of time, but not enough to
>=20
> wrap around the whole buffer and overwrite the trigger event.  For
>=20
> example, if you have a 2K deep BRAM buffer (2K samples, that is) then
>=20
> you'd have an 11-bit write pointer that continuously places each
>=20
> consequtive sample at the next location in BRAM, wrapping to location
>=20
> 0 after writing location 2047.  Now if you want to capture 10 samples
>=20
> before a trigger and the remaining 2038 samples after the trigger,
>=20
> you'd just keep storing samples in the buffer for another 2038 samples
>=20
> after triggering (you might need to adjust that based on the trigger
>=20
> delay).  When you're done, the write pointer stops incrementing and
>=20
> you stop storing data.  If your write pointer increments after the
>=20
> last write, it will be pointing to the oldest data in the buffer.
>=20
> The newest data will be at the previous location.  The sample that
>=20
> occured closest to the trigger event would be at the write pointer + 10.
>=20
>=20
>=20
> --=20
>=20
> Gabor

Thanks for the detailed explanation. To explain the code better, the sample=
s are captured by the ADC, they are remapped by the ADC Remapper and the sa=
mples are stored in 256 bit x 8192 BRAM. The address for the BRAM is genera=
ted by up-counters. So on the trigger, would I just record the address at t=
hat 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 part=
icularly sure if the addresses are recycled again since I'm still trying to=
 understand the code provided by TI for the board.

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

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:
>=20
> > On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor  wrote:
>=20
> >> Syed Huq wrote:
>=20
> >>
>=20
> >>> Hi,
>=20
> >>> I'm trying to implement hardware trigger functionality by modifying t=
he 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 questio=
ns with regards to it.=20
>=20
> >>> 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? Mayb=
e 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 t=
here an alternate way to do this? I'm currently storing the data samples us=
ing the Block RAM of the FPGA.=20
>=20
> >>> If my thinking is right, when the the board is triggered, and the dat=
a 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.
>=20
> >>> I'd appreciate any ideas on this. Thanks!
>=20
> >>
>=20
> >>
>=20
> >> The standard way to do capture that includes the trigger event is to
>=20
> >>
>=20
> >> continuously store all data in a ring buffer.  When the trigger occurs
>=20
> >>
>=20
> >> you continue storing data for some length of time, but not enough to
>=20
> >>
>=20
> >> wrap around the whole buffer and overwrite the trigger event.  For
>=20
> >>
>=20
> >> example, if you have a 2K deep BRAM buffer (2K samples, that is) then
>=20
> >>
>=20
> >> you'd have an 11-bit write pointer that continuously places each
>=20
> >>
>=20
> >> consequtive sample at the next location in BRAM, wrapping to location
>=20
> >>
>=20
> >> 0 after writing location 2047.  Now if you want to capture 10 samples
>=20
> >>
>=20
> >> before a trigger and the remaining 2038 samples after the trigger,
>=20
> >>
>=20
> >> you'd just keep storing samples in the buffer for another 2038 samples
>=20
> >>
>=20
> >> after triggering (you might need to adjust that based on the trigger
>=20
> >>
>=20
> >> delay).  When you're done, the write pointer stops incrementing and
>=20
> >>
>=20
> >> you stop storing data.  If your write pointer increments after the
>=20
> >>
>=20
> >> last write, it will be pointing to the oldest data in the buffer.
>=20
> >>
>=20
> >> The newest data will be at the previous location.  The sample that
>=20
> >>
>=20
> >> occured closest to the trigger event would be at the write pointer + 1=
0.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> --=20
>=20
> >>
>=20
> >> Gabor
>=20
> >=20
>=20
> > Thanks for the detailed explanation. To explain the code better, the sa=
mples are captured by the ADC, they are remapped by the ADC Remapper and th=
e samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is ge=
nerated 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 or=
der 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 tryin=
g to understand the code provided by TI for the board.
>=20
>=20
>=20
> If by 8K you mean 8,000 and not 8,192 then what you said is correct.  As
>=20
> for recycling the address, any simple up-counter would go back to zero
>=20
> after it reaches 8,191.  The real question is whether the counter and
>=20
> BRAM write enable are active all the time, or just after you trigger the
>=20
> core.  Of course you'd need to look through the code or ask someone
>=20
> at TI if that is the case.
>=20
>=20
>=20
> --=20
>=20
> Gabor

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.

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