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.

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.

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!

Reply to
Syed Huq
Loading thread data ...

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
Reply to
GaborSzakacs

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
Reply to
rickman

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 
 Click to see the full signature
Reply to
Tim Wescott

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.

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.

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.

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.

Reply to
Syed Huq

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
Reply to
GaborSzakacs

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.

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.

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.

  1. >

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.

Reply to
Syed Huq

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

Reply to
Tom Gardner

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
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.