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.

Can the RM44L520 read from an ADC at 40 MHz?

Other Parts Discussed in Thread: RM44L520

Hi,

Short version

Can I get an RM44L520 to read data bursts from an ADC at 40 MHz? If so, what kind of clock speeds does the MCU have to run at to manage this?
The data comes out of the ADC as parallell data, the bursts are 2.5 uS (100 samples) long, but there are multiple bursts (32 bursts) in sequence.

Longer version

The system we are designing generates an 250 nanosecond long RF pulse, switches the system from transmission to listen, and after approx 1 microsecond, starts reading from the ADC. The ADC outputs the baseband of the RF signal in two channels at 9 bit each.

The data bursts coming out of the ADC are 2.5 microseconds long.

The plan is to use the HET to generate the control signals for the RF pulse and then store the data from the two channels in two FIFOs, external to the MCU.
Write enable signals to the FIFOs will also be controlled from the HET.

However, I am thinking that maybe I can skip the FIFOs and write data straight into the MCU.

There are some more details than this involved, but is this even possible?
And what clock speed does the MCU need? Can it do this at less than 80 MHz, or does it have to run far faster than the ADC to manage this?

Best Regards

Audun Lonmo Knudsrod

R&D Engineer, Kongsberg Maritime

  • Hi Audun,

    I don't think you can interface these ADCs directly with the RM44.
    There's not a port that can sustain a 40MHz input on this device.

    Can you please provide a few more details:
    1) what it is the width of each adc conversion result (in bits)
    2) what is the time interval between these bursts of 100 samples?

    With that we can think about the problem and maybe suggest something.

    One issue with using HET is that it cannot sample it's own pins in parallel directly.
    It can "BR" on the state of a pin so the fastest way to build a parallel input
    would be to have multiple branches in a tree... say 4 levels deep each terminating with an OR+SHIFT that gives the result of one nibble of data.. That would take roughly 6 HET execution cycles for a nibble.

    So a byte is going to take at least 120ns and that's much slower than your ADC .. this is why I don't think you'll get rid of the external FIFO.

    On the other hand I'm even worried about you keeping up w. this rate if the repetition interval is too short...
  • I have some follow-up questions on this topic. If I should open a new thread instead, please let me know.

    To answer the questions in your reply:
    * Data width is 9 bit in 2 channels (18 bits total)
    * Timing between bursts will vary. Search mode: 100 microseconds. Measurement mode: Down to 20 microseconds
    (I never answered this in the first place as the content in your reply rejected the idea of a FIFO-less design in general)

    Follow-up questions:
    * Assuming we do use a FIFO to buffer data, how can the Hercules controller move data from FIFOs into system RAM without involving the CPU directly? (For example, by means of the NHET/HTU, or via a shift register and SPI/DMA).

    With such a design, the intent is to reduce the % amount of time which the CPU spends on retrieving data from the FIFOs.
    For example, in "Search Mode", the system must continuously send search pulses (and receive corresponding data bursts) every 100 microseconds. If the data loading from FIFO to RAM is handled directly by software, I suspect this will eat a lot of time. If it can be done by other means, software will only need to process the data once it is loaded into RAM.