• State TI Thinks Resolved
  • Locked Locked
  • Replies 32 replies
  • Answers 10 answers
  • Subscribers 46 subscribers
  • Views 3341 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TSW14J56EVM: Real-time streaming and processing possible?

ADC32RF45EVM: Real-time streaming and processing possible?

Aravind Venkitasubramony
Intellectual 825 points
Part Number: ADC32RF45EVM
Other Parts Discussed in Thread: ADC32RF45, , TSW14J57EVM, ADS54J40EVM

My application is similar where ultimately I need to do everything on the fly and store only an average and/or peak for each frequency bin. But initially I am interested in collecting the raw data alone and having an option to look at it or do some other higher order statistics as well. My aim is to use the two channels of the ADC32RF45 EVM to collect data at 1GS/s per channel using the TSW14J56 EVM. So if I am understanding it correctly, I can fill up the memory 2GS deep before having to transfer to the PC through HSDC pro software. Through the USB 3.0 interface if I get the max rate of 640MB/s, it could take up to 6.5 seconds to transfer it to the PC to be ready for another acquisiton of 1second. 

1) Is my understanding correct? 2) Have you ever achieved the max throughput of 640MB/s through the USB 3.0 interface and if not what is the max rate you have acheived? (using my laptop PC i have never seen more than 400MB/s) 3) In order to make it a continuous data grabbing interface and also get the theoretical maximum of 640MB/s, we have to interact with the USB 3.0 cypress interface directly to write to the PC? 

  • 0
    TI__Intellectual 2750 points
    Hello Aravind,
    (1) Mostly correct. You can utilize the DDR on the TSW14J56 to take a deep memory capture then pull it back over to the PC. With the current HSDC Pro software this transfer will be... slow due to some software and hard drive caching overhead. The architecture of the TSW14J56 board supports ~3.2Gbps offload through the USB3.0 device.
    (2) The max throughput of 640MB/s (5.12Gbps) is the USB 3.0 maximum including packet overhead. In this hardware we are utilizing a FPGA -> USB3 controller that moves data at 3.2Gbps (~400MB/sec). We are not able to achieve this throughput in the current version of HSDC Pro, but we are working on a solution to get there in the future.
    (3) If you were to write your own interface directly to the USB 3.0 Cypress device you would get close to 3.2Gbps throughput, but we cannot support the software/hardware at this level.

    Based on your application description it sounds like you will probably need to develop some of this processing on the FPGA directly (due to sample rate + real time requirement). We do have firmware designs available for the ADC32RF45. You can download them from the ADC32RF45EVM page.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points
    Thank you for the quick reply.

    Yes, I am working towards implementing a lot of the processing on the FPGA itself and have been looking around for a solution for that for a while now and thought this might work.

    So if I need to do some processing on the data stream coming out of the ADC32RF45 to the TSW14J56 and then only transfer the processed data which is going to be at least 1000 times lesser, that is possible ( mostly FFT of each channel and some statistics) by modifiying the firmware design you mentioned here? In that case can I still use the HSDC pro to write the processed data or do I have to write to directly talk to cypress 3.0 (which you have mentioned as something that cannot be supported)?
  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    There are some HDSC Pro automation examples that you might be able to work with to interface with the USB3 device and FPGA through HSDC Pro. See C:\Program Files (x86)\Texas Instruments\High Speed Data Converter Pro\HSDCPro Automation DLL\Manual and Examples

    The purpose for TI to release the firmware designs are for customers to see architecture example to learn how to interface with the converter, then expand it in the direction of their application. I hope this is helpful for you.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points
    Brian

    Is the firmware design present in the exe files for the Arria and Kintec ? Also I am not sure if customizing the ADC32RF45 firmware will help in real time processing of the ADC data ? it should only help if any with the JESD204 interface and its rate? For real time processing such as FFT, I will need to process the data in the TSW board right?
  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    Yes, what you download is an installer with license, etc. When it has installed it extracts source project files that you can open with the appropriate tool for FPGA development.

    The project serves as a starting point to get the ADC interfaced to the FPGA (eg incoming data to block RAM). There is no processing of the data in the reference design. Since your need is real-time then you must do the processing on the FPGA fabric.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    I understand that I will need to expand a lot on the reference design to get to what I envision. My confusion was that  - since the FPGA is in the TSW14J56 board and that is the one that needs to do be programmed to do the RT processing, I was wondering why we are connecting the ADC32RF45EVM to the Kintex or Arria dev board to modify the firmware. Seems like I am not understanding the flow fully. Admittedly I am not an expert in the whole FPGA/embedded system programming. So pardon the beginner level questions.  Could you clarify the process I will need to follow to get the real time processing going on (somewhat at a high level).

    Also this means that in addition to the TSW14J56 and ADC32RF45 EVMs , I will need one more ( either Kintex or Arria dev kit to modify the firmware - from a hardware and cost perspective) 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    No problem. We try to support our converter products on three evaluation 'phases'

    Evaluation - Customer utilize a converter EVM and a TSW platform board along with Device GUI and HSDC Pro software to evaluate converter performance and configuration. This is well supported because it uses our tools as-is.
    [TI EVM, TSW platform, Device GUI, HSDC Pro]

    Integration - Customer utilize EVM, Device GUI, and possibly HSDC Pro with an adapter board to connect with a vendor FPGA platform such as a Xilinx or Altera development kit. We have limited support to get our firmware designs running on the supported boards.
    [TI EVM, Device GUI, Adapter card, Firmware reference design, HSDC Pro]

    Solution - Customer utilize configuration and code from previous steps to build final product (custom board).
    [TI Firmware reference design]

    For your work you are somewhere between Evaluation and Integration where you need to begin to merge your design over the top of our evaluation platform.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    I think these two boards is a likely way forward for our project. I will be interested in talking to someone more in person over phone to gain more knowledge on the boards and the path forward to building a custom solution for our problem. What would be the best way to get a quote for the ADC32RF45 and TSW14J56 boards and also talk to someone to get answers for the technical questions? Please let me know

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Hello Aravind,
    We try to handle communication through the forum when possible so that we can keep reference of the discussion.

    To order the boards you are able to see purchase options from the adc32rf45evm product page (the link should take you to the product page). We recommend the TSW14J57EVM platform board to pair with the ADC32RF45. The two can be purchased together as a 'bundle' on the EVM page above.

    For any additional technical questions please try to utilize the forum. We are able to support more quickly this way. If the questions are unrelated to our conversation you can start a new post (for instance if you have questions about the ADC32RF45 specifically we can direct them to an engineer that works with the device).

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    It would be good to have a phone support number to ask any questions especially before buying items that are costly ( both these combined will cost around 3750). I can continue the technical discussions in the forums for the common good for future users as well, but we would like a phone number to reach out just in case. 

    1. Do you offer any discounts for academic institutions such as Universities? 

    2. Of the KCU105 and the Arria 10 development boards, is there a preferred one that might make it any easier, (especially since the TSW has an Arria FPGA on it, is Arria 10 more preferred?)?

    3. The ADC32RF45EVM GUI is used only for configuration settings and standalone it cannot be used for any data logging/streaming purposes? ( One needs TSW board also to verify ADC32RF45EVM functionality?)

    4. The user guide for TSW says that the configuration file is received from the ADC32RF45. This the .ini files or .bit files ? As in is the .ini file being referred to as the FPGA firmware file?

    5. My understanding is that this .ini file contains only information on the format of the data coming from the ADC32RF45 module to the TSW board and in no way contains any information of what processing is being done on the received data. We are not modifying ( or able to modify) the firmware on the Arria V FPGA on the TSW that processes the data and interacts with the HSDC Pro GUI. 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    1) We do not have any general academic discount
    2) Both dev boards will work. We do have some support for the KCU105 platform, including interface with HSDC Pro. See this app note SLAU711.
    3) You are correct the device GUI is for system control, and does not access the data stream
    4) We use .ini files in HSDC Pro to configure our software for a specific device, as well as point to the FPGA firmware. The ini files are selected when you enter HSDC Pro. The FPGA firmware is saved target specific (eg .rbf file for Arria device)
    5) Your statement is correct
    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points
    Can I use the KCU105 board + ADC32RF45EVM +HSDC Pro to do essentially the same things that I could do with TSW14J56+ADC32RF45EVM+HSDC Pro? In terms of storing data upon a capture trigger for a preset time and then transferring it to the PC for analysis? Or is there a mode of operation that only the TSW14J56 ( or KCU105) could provide?
  • 0 in reply to Aravind Venkitasubramony
    Intellectual 825 points

    Can I use the KCU105 board + ADC32RF45EVM +HSDC Pro to do essentially the same things that I could do with TSW14J56+ADC32RF45EVM+HSDC Pro? In terms of storing data upon a capture trigger for a preset time and then transferring it to the PC for analysis? Or is there a mode of operation that only the TSW14J56 ( or KCU105) could provide?

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    We have a KCU105 binary and ADC32RF45 config for this setup.

    I would recommend you pull down the KCU105 firmware (instructions are in the SLAU711)
    to confirm you will be able to modify the code from there.

    This might be your best option for modifying firmware on FPGA.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    Thanks for the document. Looking through the instructions in http://www.ti.com/lit/ug/slau711/slau711.pdf, I notice that it says in Introduction, "Texas Instruments has created a platform where the KCU105 can interface with TI’s latest and most popular JESD204B-based high speed data converter evaluation modules (EVM) as if it were connected to a TI development board". I would interpret this as "KCU105 can do everything a TSW14J56 can do". Hence my earlier question.

    Also looking through the KCU105 spec sheet, it has 2GB DDR4 memory whereas the TSW14J56 has a 4GB memory. So I would think that in the case of raw data acquisition, KCU105 can do half the duration of data that a TSW14J56 can acquire in one continuous capture. So in the firmware, is the data being acquired and stored to the 2GB DDR4 memory and then transferred to the PC over a slower interface? 

    Also in page 21, in the example where TSW14J56 is interfaced with an ADC32RF45EVM in the DDC bypass mode ( something I am interested in) it says "Verify the number of samples do not exceed 32,768." - I am interested to know where and why this restriction is present and what is its impact? 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Hello Aravind,
    My understanding is that the Xilinx published FPGA project is a capture to DDR build for the KCU105. Please confirm if you are able.

    All of our (TI) published firmware builds are set up to do an acquisition to memory (BRAM) and then you would request an offload from the FPGA board that would be transferred over USB.

    I have not worked with the board you are discussing, but it sounds like that build is only capable of 32k samples (BRAM build?) I will discuss with a colleague and get back to you on it.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    Thanks. I will wait for your update. Also I think I saw only one firmware .exe file in the website ( not sure if there is a Xilinx version and a TI version of the firmware?)

  • 0 in reply to Aravind Venkitasubramony
    Intellectual 825 points

    Hi Brian

    Did you get to know any more on this? 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    Sorry this is taking longer, I still intend to follow-up on the capture size question.
    Regards,
    Brian
  • 0 in reply to Brian2001
    TI__Intellectual 2750 points
    Aravind,
    The latest firmware builds for the TSW14J56 and TSW14J57 can capture to DDR so they can capture significantly more than 32k. The firmware builds are distributed with the HSDC Pro installer.

    I think that we need to update our user guide (it seems it was based on a BRAM build)

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points
    So the latest firmware builds that ship with the HSDC Pro can capture to the 4GB DDR3 in TSW14J56 and the 2GB DDR4 in KCU105? That's good to know. Does this mode of operation limit the throughput in any capacity or it is the same as writing to the BRAM?

    Could you also confirm if the entire DDR in either TSW14J56 (4GB) or the KCU105 (2GB) boards can be fully filled before initiating a data transfer to PC or is there a limit to that?
  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    The KCU105 firmware is capable of 268 435 456 (16bit samples across all channels), in multiples of 4096
    The J56 firmware is capable of 2 147 483 648 (16bit samples across all channels), in multiples of 4096

    The capture sample is error-checked in HSDC Pro, so if you enter a value out of range it will be adjusted down to the next valid sample count (you can see this by hitting tab after entering the number)

    The acquisition cycle will fill the FPGA buffer to your sample count and then transfer the data as a block back to the PC. Right now this operation (on J56) is not very efficient because of our PC side driver layer but an update is pending release that will improve this cycle dramatically.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Thanks Brian! That is very useful information to have. So with the J56 we can fill up the entire 4GB of the DDR memory before initiating a data transfer but only 500MB with the KCU105. But when you mention "Right now this operation (on J56) is not very efficient because of our PC side driver layer", I believe it is the same for both KCU105 and J56 right? I am asking this explicitly only because you mentioned J56 in the brackets and not KCU105. I don't think it is any faster with KCU105?  

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    The J56 has a USB3.0 device to transfer data back to the PC. Our driver is admittedly inefficient right now. We have internal testing on a much faster implementation that we will roll out in the next few months. With the new driver we will be moving over >3Gbps during transfers

    The KCU105 utilizes the ethernet port to move ~<1Gbps from the board to the PC. I have not verified its actual realized transfer rate.

    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Brian

    Is there any major operational advantage we get by going for a J57 board than a J56 board. I see that the J57 has an Arria 10 whereas the the J56 has an Arria V and also the J57 has more JESD204B lanes. But I see that the memory in J56 is more than (double) the J57. Is there any functionality only available in either boards? 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points

    Aravind,

    The J57 can run 16 lane mode at full rate with the high lane count converters.  It has less memory but the memory has more bandwidth.

    The only other difference is that the J56 does not support a specific high rate external clock mode (meaning, it is not using the on-board LMK device).  Let us know if you are running this configuration and we can discuss the issue in more detail.

    Regards,

    Brian

  • 0 in reply to Brian2001
    Intellectual 825 points
    We are not looking at more bandwidth for our present application, so I guess that is not a major difference to us. I am sorry I did not fully understand the other difference. Could you explain it a little more to see if I am ever likely to encounter that?
  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Some customers utilize an external sample clock at full sample rate for their system. In a few special cases the J56 will reset during reconfig in this condition. For those customers we recommend they utilize the J57. There are no issues with the J57 board, and all converter boards that can use J56 can also use J57.
    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points

    Thanks for the explanation.

    So if I am running an ADC32RF45EVM at 3GSPS  ( or an ADS54J40EVM at 1GSPS ) using an external clock  and using the TSW14J56 to capture the data, then that could cause the capture card to behave this way (occasionally only?) . But if I use the onboard clock chips this is not an issue ( ever? ) . Is this understanding correct? 

  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Aravind,
    We do not have any known issues with those devices on the J56 platform.
    Regards,
    Brian
  • 0 in reply to Brian2001
    Intellectual 825 points
    Thanks Brian!

    I got a TSW14J56 and an ADC32RF45EVM and am currently trying to go through the ADC32RFxx-EVM guide slau620D.pdf found on the TI website. I have a question on section 3.2 step 4. It asks me to connect an analog RF signal to AINP SMA (J2). When I look at the board, the connector J2 is AINM and AINP is actually J1 and it does not have an SMA connector soldered to it. I want to confirm if this a typo ( I am supposed to connect to AINM and not AINP) OR am I supposed to solder an SMA connector to AINP and continue with the test. Please clarify. Even the Fig 1 in the document shows AINP as J1 and AINM as J2.
  • 0 in reply to Aravind Venkitasubramony
    TI__Intellectual 2750 points
    Hello Aravind,
    I am sorry I missed this question. I would like to suggest you start a new thread with the ADC32RF question. We can get you directed to someone that can help specifically with the device.

    Regards,
    Brian