real-time processing at high data ratessme

[manikg]

Hi,
Have folks addressed ways of processing the ADC data at a faster clock rate in a non-linear access pattern (non FIFO), and where some samples may be needed again few iterations later.

Basically, the issues we ran into are as follows:

1. Top-level clock seems to be set at 20MHz (Configuration Clock) for the target.
    ( I was unsuccessful at using the DAC IQ clock as the top-level clock. Also, it isn't clear how this may work)
2. BlockRAMs are not supported within Single-cycle timed loops or across multiple-clock domains.

Therefore, for transferring ADC data to a faster clock domain, FIFOs seem like the only option, which doesn't exactly fit our access
pattern.

Thanks.

-M








LabVIEW FPGA does not allow





We're targetting a ADC IQ Sample Rate between 1-20 MHz

[Ex-NISH2]

Can you try the RTSI clock, which can be configured to higher rate, for SCTL?

I saw the config, but not sure if it is OK.

[Mauricio Capistran-Garza]

Hi Manik,

You should be able to set your Top-Level clock on the Target properties. I do not advise to use the DAC IQ Clock as the top level clock because you must configure the DAC interpolation to get the rate that you want. I would advise to use the RTSI Ref Clk, and then use the Configure Timebase.vi to choose the clock divisor for this clock (by default the divisor is set to 16, which would give you a 12.5 MHz clock).
You are right about block RAMs not being able to cross clock domains. Nevertheless, they ARE supported in SCTL. The only caveat is that the output of the memory read must be directly wired to an uninitialized shift register. And by "directly" I meant that it cannot even go through a tunnel of a case structure and it can not be wired anywhere else but the uninitialized shift register.
So what I suggest is using a small local FIFO just to send the data from the ADC clock domain to the RTSI clock domain. Then on the RTSI clock domain read the data form the FIFO and write it the block RAM. Now you can do random accesses to the data on the RTSI clock domain.

- Mauricio

[manikg]

Hi Mauricio, Thanks for your reply! We are using the memory extension utility, am attaching the error we get. We would like to be able to use it with the Write? wired to a constant. >You should be able to set your Top-Level clock on the Target properties. OK. We had chosen the RTSI clock as the top-level clock, but the synthesis results seemed to suggest this didn't work (the compilation summary is attached).  How are the clock frequencies set in the Project Explorer used by LabVIEW? Also, with RTSI as top-level clock, how is this done with the FPGA (intial frequency, transitioning when Configure Timebase VI is called,...). Appreciate your help. -M PS: In the Compilation summary it shows a timing voilation for the RTSI clock (top-level clock). The code seems very basic.

[manikg]

Hi Mauricio,
Thanks for your reply!

We are using the memory extension utility, am attaching the error we get. We would like to be able to use it with the Write? wired to a constant.


>You should be able to set your Top-Level clock on the Target properties.

OK. We had chosen the RTSI clock as the top-level clock, but the synthesis results seemed to suggest this didn't work (the compilation summary is attached). 

How are the clock frequencies set in the Project Explorer used by LabVIEW? Also, with RTSI as top-level clock, how is this done with the FPGA (intial frequency, transitioning when Configure Timebase VI is called,...).

Appreciate your help.

-M

PS: In the Compilation summary it shows a timing voilation for the RTSI clock (top-level clock). The code seems very basic.

[Mauricio Capistran-Garza]

Hi Manik,

I wasn't aware you were using the memory extension utility. Unfortunately, only regular memory blocks are supported in SCTL in LabVIEW 8.0.
As far as the compilation error, you can go to the clock properties (by right-clicking the clock in the project explorer) and select at which rate do you want to copile the design. The rate specified there is used in the timing analysis of the FPGA. From your screenshot, it seems like you are compiling for a 200 MHz clock, which is pretty fast. Assuming you are not really running the clock that fast, you can just change that number. If you do need to run the clock that fast you will need to pipeline your design in order to reduce the max. propagation delay in order to be able to achieve a 200 MHz rate.
About changing the top level clock rate on-the-fly, what I would recommend is to download the FPGA but don't run it until you have configured the clock. To do that, right-click on the Open FPGA VI Reference.vi and select "Open" instead of "Open and Run". Then configure the timebase, and once that is done, you can use an Invoke Method node to start running the FPGA.

- Mauricio

[manikg]

Mauricio,
Hi. I apologize for not mentioning the use of Memory Extension Utility in my first message.

1. I am attaching a screenshot of the FPGA VI which gave the timing voilation (for a top-level clock frequency of 200MHz). Regarding propagation delays, I'm not sure what improvements can be made. The only code outside the SCTLs is a while loop where I perform a FIFO read. Please let me know if you have any suggestions !

2. I was reading the 'Successful Compile Report' incorrectly and as a result misinterpreted the top-level clock to be static at 20MHz. I see my mistake now.

Thanks !

M

[manikg]

Here is the attachment (Sorry but i seem to be having trouble with the 'Edit as HTML' option).