66AK2L06: JESD DATA CONTROL FLOW

Thanks for feedback, do you know when I should anticipate an answer from your experts.  Please add also that if running without DDR3L (our program/data all fits easily in internal memory) for the JESD flow is possible, which memory internally would they suggest be best to stream samples to and from?

Hello,

We have no example applications, without DDR3.   A possible reduction is  to convert the 64bit interface to a 32bit interface.  If you are using the RFSDK2 software, this requires a Linux ARM subsystem, which is loaded into FLASH, and then copied to DDR3 RAM.

I suggest you build up your application, to work with the existing 66Ak2L06 EVM, then once it works you will need to follow the Adjacent Market design 1, 4 there is an existing DLC card to adapt the CN16 FMC connector to (2) JESD connectors, one for ADC, and one for DAC.  

The RFSDK2 is based around the TI JESD data converters ADC12J4000, ADC32RF80, ADC14x250, DAC38J84 (there are no DACs with the same JESD formfactor).

If you then take the form factor of the EVM (you will notice with less flexible IO, you can remove the FPGA).   Several companies have converted from the EVM form factor to their products.  Note: some customers still retain SPI, GPIO switching in a CPLD.

If you follow the Keystone 2 Hardware Design Guide, and Keystone 2 DDR3 User Guide, Processor SDK User Guide a second 66AK2L06 EVM could be reworked to test 32bit DDR3, with reduced performance.

Regards,

Joe Quintal

Hi Joe, I also wanted to make sure that the DAC (AD9152: Dual, 16-Bit, 2.25 GSPS, TxDAC+ Digital-to-Analog Converter, supports input data rates up to 1.125 GSPS, uses flexible 4-lane JESD204B interface, and has 1×, 2×, 4×, and 8× interpolation filter) I called out in the thread as well as the ADC (AD9250: 14-Bit, 170 MSPS/250 MSPS, JESD204B, Dual Analog-to-Digital Converter). Both of these devices support the JESD204B Subclass 1 which the 66AK2L06 supports. Do you have any reason to believe why either one of these devices would not work directly with the 66AK2L06? We will not have an FPGA in between but a direct connection from these devices to the 66AK2L06. Thanks in advance. -b

Hello again Joe, any more thoughts on this?  I am nearing completion on the first prototype schematic and really need to know these answers.  What would we have to do to run a system without the DDR3L?  What changes would need to be made for the boot, drivers, etc..  that we would have to do if it was possible.  If it is not possible why not?  This is indicating that it is resolved, but I do not think is has been.  Let me know what more I can do to get some of these answered.  thanks  -b

Hi Bryan, 

Joe may correct me, but I believe if you are going to use the RFSDK then you have to have Linux running. If you have Linux running, you have to be able to load the kernel and drivers into a program memory and the DDR3L space is the only one big enough for this purpose.

Have you been able to get past this limitation on the 66AK2L06 EVM already and enable RFSDK, and its JESD/DFE drivers, without utilizing the onboard DDR3L memory space?

Thanks,

Randy 

Hi Randy, we have been waiting for an answer and our software guy is on vacation.  Can you verify this in any way?  If we do not use the RFSDK can't we write the control drivers for the JESD/DFE ourselves by scratch and maybe utilize portions of the RFSDK?  The reality is that we wanted to be able to scale down all of our software to just boot from serial flash and run from internal memory using it for all of our code and data without needing an operating system.  Is this just not possible with these KeystoneII devices and we must use the DDR3L no matter what?

  I have been assuming all along that we can boot from serial flash and run from internal memory both the DSP and ARM units once they have all booted without ever using the DDR3L.  Once we are running we could stream data to and from internal memory to exercise the DFE/JESD without DDR3L use as well....is this a completely wrong assumption?

Also can you check on the other inquiry

"We are interfacing the JESD to the AD9250 (ADC) and the AD9152 (DAC) residing on the IF board which will be board-to-board attached. These devices conform to the JESD204B compliant subclass 1 so I have assumed there will be not issues controlling them from the 66Ak2L06"

Hi Radio-Joe and Randy, I was hoping that I could have closure on this topic, but it seems that the answer is that my initial design should have DDR3L and until the time comes when we can prove to ourselves that we don't, by writing whatever software/drivers would be required, for this type of operation. So my last question with all of this is if the DDR3L I have now selected will be appropriate and to verify that the 66ak2l06 device supports the 1.35V rather than the 1.5V as required by the DDR3L. The one I selected is the MT41K256M-107-AAT:P. Can you confirm that this device which is automotive grade DDR3L will work?

...see also  https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/615217/2292821#2292821

Hello Bryan,

The standard RFSDK solution is to use Linux, and the RFSDK, which requires DDR3.   There are two third party customization companies for the RFSDK, Azcom in Italy, and Commagility in England.   

There are two sections in your email about control.   There is no standard SPI control-software for JESD ADC, JESD DAC in the RFSDK, other than for the AFE7500 Transceiver.   In most of the TI reference designs, this is done by first loading the EVM configuration software for both the ADC and DAC, then running the RFSDK without reprogramming these devices.   

JESD204B sequence control is provided in the DFE section.    Related to real or complex data rates.   The maximum transfer rate is based on the maximum serdes rate.   In Adjacent market design 1 (ADC12J4000, DAC38J84) and design 4 (ADC32RF80, DAC38J84) a 7.3728Gbit serdes rate is used.   We would use 2 JESD lanes for each complex signal, the JESD parameters are 222 for one stream or 442 for two streams.  

Customization of RFSDK without DDR3 is not a standard method.  You can try a 32bit implementation of DDR3 vs the 72bit, to reduce the DDR3 footprint.  

REgards,

Joe Quintal