Impact of high, derived clock rate

[sbailey64]

Hi PCorcs,

Actually, the counter we plan to gate will be counting pulses arriving from a photon counting PMT. The photons are the result of fluorescence caused by the laser pulse. The bandwidth of the PMT is relatively low (5 Mhz), so that should not be a problem for C-module I/O...correct?

You mentioned you had successfully compiled a simple counter in an SCTL with a 200 Mhz clock. Was this on a Compact RIO system and if yes, which chassis did you use?.

Finally, in addition to the 200 Mhz clock SCTL, we would like to add SCTLs which run at the base clock rate (40 Mhz). Therefore, can one 200 Mhz SCTL coexist with possibly three 40 Mhz SCTLs?

Thanks again,

Steve

[Pcorcs]

Steve,

A 5 MHz input should be fine for both the 9401 and 9402 C-Series Modules. You may review their specifications for the minimum pulse width. I believe they are 100ns and 55 ns respectively. 

The simplified application was compiled on an R-Series device with a Virtex II 1 M Gate FPGA (our "smallest" chip). The amount of logic you have discussed implementing in this application will not cause any issues with FPGA space. The main concern for code optimization will be timing parameters. For reference, and explanation of FPGA logic benchmarks for both the Virtex II Series and Virtex 5 series may be found here. These same FPGA chips are used in the cRIO chassis, and will be functionally the same with respect to FPGA programming. 

Hope this helps!

[sbailey64]

Hi again Pcorcs,


We just got our CompactRIO system from NI. I was immediately able to program it in both the "Scan Mode" and "FPGA Mode". Unfortunately, I am having problems combining SCTL's with different time bases in the same VI. For example, I have one SCTL with the base (40Mhz) clock and another with a 200Mhz derived clock. I get the following messages when I compile:
 

"Object(s) are requesting access to a resource through resource interface(s) from more than one clock domain.

 The resource interface does not support access from multiple clock domains because of the possiblity of corrupting data.

 Alter the VI such that all objects requesting access to the corresponding resource interface are in the same clock domain".
 

 As we discussed in our last few messages, this was supposed to work. Am I missing something here?
 

Regards,

 

Steve
 

 

[Pcorcs]

Hello Steve,

Certainly, multiple SCTLs at multiple derived clock rates can coexist; however, it sounds like a single I/O resource is being used in multiple clock domains (i.e. race conditions are guaranteed). Could you post your FPGA VI? Or a screenshot of the code?

Thanks,

[sbailey64]

Hi PCorcs,

I have attached both the VI in question along with its project file. As you will see, I have two SCTLs.

The 200 Mhz SCTL uses port 0 (Input 200 Mhz) and port 1 (Output 200 Mhz) from a NI-9402.

The 40 Mhz SCTL uses port 2 (Input 40 Mhz) and port 3 (Output 40 Mhz) from the same NI-9402.

Any idea what is wrong?

Thanks,

Steve

[Pcorcs]

Hi Steve,

I reviewed the code an did a bit of research on the modiule interaction. In your initial test case, a single digital module can only manage throughput as a single I/O resource; therefore, I/O channels on the same module cannot be attributed to multiple clock rates, as the bus has no way to separate and mitigate data transfer through the module at multiple rates. 

That said, spanning the I/O to multiple modules can have a similar problem, as many timing and transfer lines are shared on the FPGA backplane. Fortunately, I believe the methods provided in this Knowledgebase Article will provide a suitable workaround for the system. 

Essentially, using a single derivied timing source we may treat select timed loops as counters with respect to an accelerated timing source, gated to match the reduced input timing level you would like to replicate.

I hope this provides a path forward on the system. Please post back any additional questions.

Thank You,