This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F28379D: Fetching ADC data directly in CLB

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: C2000WARE

Hi,

I have an application which needs the following -

  • Fetching of ADC data to CLB
  • Multiplication of data with a scalar (this I'm assuming we could do with bit shifting within CLB)
  • Then generation of complex PWM signals (again this is possible in CLB)

I want the entire process to happen at the rate of atleast 10MHz and it seems to me that the first step could be bottleneck.

I'm also worried about inaccurate ADC values which could potentially wrong control implementation.

Could you please advise on this?

P.S. I'm thinking of using F28379D for this project but if you have a better suggestion, please let me know.

  • Hello Anurag,

    Fetching of ADC data to CLB

    This will be a bit slow as you've stated, since there is no direct way to transfer an ADC conversion to the CLB. Instead you would likely have to use the GPREG bit in the CLB as the input. I will check with another expert to see if this is possible.

    Multiplication of data with a scalar (this I'm assuming we could do with bit shifting within CLB)

    This would work for powers of 2 for the scalar, are you planning to multiple by a scalar that's not a power of 2?

    Then generation of complex PWM signals (again this is possible in CLB)

    There are some example provided in C2000Ware: C2000Ware_5_00_00_00\driverlib\f2837xd\examples\cpu1\clb. You can also find a list of these examples and their descriptions in the CLB Tool User's Guide.

    I want the entire process to happen at the rate of atleast 10MHz and it seems to me that the first step could be bottleneck.

    The CLB itself has a maximum frequency of 100 MHz so this should be feasible (given the constraint that you brought up with the ADC doesn't bottleneck this).

    P.S. I'm thinking of using F28379D for this project but if you have a better suggestion, please let me know.

    This will depend on what you're looking for as far as the CLB and any other peripherals you plan to use on the device. For CLB, the tile itself is the same but the number/types of input/output connections vary as well as some additional configurations for pipelining and clock prescalars.

    Best regards,

    Omer Amir

  • By the selection of DSP - I meant if there were any particular advantages in any of the other DSPs which would enable me to do all of these operations at my intended rate (10MHz). Superior DSPs in terms of ADCs or the CLB tile which would help me.

    Yes, I intend to multiply factors of two as of now. 

    Please let me know about the ADC bottlenecking issue. 

    Thanks

  • Hi Anurag,

    Would you be able to provide more information about your specific application? As of now, if you are still in the part selection, it would be helpful to take a look at our peripheral guide to see iterations of the IP between different device families. For example, the device you have chose F28379D is limited to Type 1 CLB. You can take a look at the benefits of Type 2 and Type 3 and if they would be necessary for your application, you can choose a newer device.

    https://www.ti.com/lit/spru566

    Regards,

    Peter

  • Okay I will go through that, thanks!

    My main concern is more with delay incorporated with the ADC data being fetched in the CLB. Can you provide information on that?

  • Hi Anurag,

    Are you needing to perform this fetching of the ADC data after every time the ADC is sampled, or could you process them in different chunks. Why I saw this is because you will need to utilize an interrupt after your EOC where the result of the ADC is read and then transferred to the CLB. There is a FIFO interface for transferring information to the CLB and this FIFO is 4 words like. So depending on your requirements, you could setup your SOC0-3 to read 4 ADC samples then issue the EOC and then push this ADC data to the CLB.

    Regards,

    Peter

  • Yes, I need to perform control action on every ADC sample I receive.

  • Hi Anurag,

    It would benefit you to take a look at our C2000 signal chain benchmarking application report which details the signal chain latency from ADC sampling: https://www.ti.com/lit/spracw5

    Once you have successfully converted your ADC input and gotten the result, the latency from the CPU to the HLC should be very minimal, only in the order of a few SYSCLK cycles. Please refer to our TRM which details the specific timings for the CLB operations

    Regards

    Peter

  • Hi Peter,

    Thanks for the document. I had few more question.

    Do I need to call the ADC ISR to transfer the results to the CLB HLC? And what I understand from your statement is that the latency from sampling to transferring data to CLB should be few SYSCLKs. Is that correct?

  • Hi Anurag,

    Yes that is correct, you will need to use the CPU to transfer the data from the ADC results to the CLB HLC as there is no other direct route from ADC data to CLB. For the few SYSCLKS, this is only in reference to using the FIFO to send the ADC data from CPU to CLB. The sampling latency is dependent on your ADC configurations (such as how long your ACQPS is configured to) so that would require testing and evaluation to understand how many clock cycles this entire chain would take.

    Regards,

    Peter

  • I just had one last question. In the whole process that you mentioned does the type of CLB (type-1, type-2 or type-3) make a difference. I'm asking this because I'm using a F28379D which has type-1 CLB, so I was wondering if CLB type-2 or type-3 devices are better suited for 'specifically' what I'm trying to do?

  • Hi Anurag,

    I don't believe it should make a difference but here are the main differences:

    Type 2 adds the ability for a counter to be used as a shift register/serializer. You still have shift functionality on type 1 CLB though. Type 2 also adds an AOC block which can be used to invert/gate the output of the CLB. Type 2 CLB can detect the falling edge of actions (Type 1 can only detect rising edge but you can still use LUTs to invert your logic as a workaround). Type 2 has 32 overriding outputs per tile (Type 1 only as 16), this just results in better connections with peripherals on the device but doesn't affect ADC. And then finally, Type 2 CLB can generate NMIs.

    Type 3 changes are more minor. You have the ability to PIPELINE the counter and use uses events from the immediately previous clock cycle. And the HLC module can work with outputs delayed one clock cycle.

    So these improvements don't necessarily affect ADC->CLB chain. It is important to note that type 1 CLB is limited to 2 outputs to OUTPUT XBARs or other CLB tiles so if you need to output a lot of signals from the CLB, you should take this inter consideration.

    Regards,

    Peter

  • Thanks for the great explanation.