• State Resolved
  • Locked Locked
  • Replies 25 replies
  • Subscribers 10 subscribers
  • Views 1301 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.

AFE7444: IP support for the reference design KCU105 AFE74xx XCVR 2x44210 to replicate on Vivado 2018.2

Chan100
Genius 3040 points
Part Number: AFE7444

Hi everyone,

I am currently studying the reference design KCU105 AFE74xx XCVR 2x44210. The reference Vivado project is implemented on Vivado v2016.1. However I would like to port it to Vivado v2018.2 and started building the block design from scratch. I see some of the IPs are not present in the IP repository of Vivado v2018.2.

After searching through reference design, I was able to add the following IPs in Vivado v2018.2, by adding the path of repository directory 'repository_0' from the reference design.

1.iobufs_ti_v1_0
2.leds_v1_0

However, the following IP (source) is still missing

1.transport_layer_afe768x_44210_0

Does ti provide support for this? How can I obtain this IP so I can complete re-building the block design on Vivado 2018.2?

Can someone help me with this?

Thanks in advance,

-Chandrasekhar DVS

  • 0
    TI__Genius 10505 points

    Hi Chandrasekhar,

    The verilog file is located at below location on the PC where KCU105 firmware is unpacked: 

    C:\Program Files (x86)\Texas Instruments\KCU105 Firmware\AFE74xx XCVR 2x44210\Source Code\KCU105_AFE74xx_XCVR_2x44210_7p3728G\KCU105_AFE74xx_XCVR_2x44210_7p3728G\prj_MyKcu105_TI.srcs\sources_1\new\transport_layer_afe768x_44210.v

    This file can be added to your v2018.2 project.

    Reference design is given in Vivado version 2016 as a reference starting point for FPGA development. Unfortunately, TI can not provide reference designs in different versions of Vivado.

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    So I would like to atleast obtain the IP project for 'transport_layer_afe768x_44210_0'  IP in the block design. In the reference design, it is locked. With an unlocked custom IP, it is possible to upgrade it, so as to be used in Vivado 2018.2.

    Can you please provide us that module? As the Vivado environment is new to me, I would like this resource supplied.

    Thanks in advance,

    Awaiting a reply soon,

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Hi Chandrasekhar,

    I have contacted our firmware support team to find what we can provide to support this. Please give me until Friday to get back.

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Thanks! That would greatly help.

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Guru* 91947 points

    Chandrasekhar,

    Please download the file from the link below. This may have what you need.

    Regards,

    Jim

    txn.box.com/.../v9u6g0qgfa01ieyukypw4qb40n418jkw

  • 0 in reply to jim s
    Genius 3040 points

    Sorry but what version of vivado was used for this? I am using vivado 2018.2. When I try to open the project, it says the project has been created with an even newer version. I might not be able to open this. 

    Can you help me here?

    Thanks in advance,

    -Chandrasekhar DVS 

  • 0 in reply to jim s
    Genius 3040 points

    Also I was using KCU105 not Zync board! I see that this project is for Zync board?

  • 0 in reply to jim s
    Genius 3040 points

    Hi Jim s,

    Thanks for the reference project for 2016.1. However we already have this by filling out the form while looking at one of the afe7444 related documents. I was asking for the locked IP 'transport_layer_afe_2x44210'. This is probably because while the reference project was being created, this custom IP project path was added to the IP repository. That custom IP project is not included with the reference design that was causing 'locked IP' problems. Anyways, I was able to  create custom IP for 2018.2, simulated and tested its functionality.

    Thanks for the support,

    -Chandrasekhar DVS

  • 0 in reply to jim s
    Genius 3040 points

    Hi Jim s and Vijay,

    So I have the following things to ask regarding the reference design

    1) In the included Vivado 2016.1 project from the reference design, I see that the data output lanes from the JESD204 TX IP are not mapped to any physical pins in any of the included constraint files. Also in the implemented design, there is no automatic mapping of data output ports 'txp_out' and 'txn_out' to any physical pins(which also should not be expected as the mapping needs to be specified in a constraint file). I see that they are there for the 'rxp_in' and 'rxn_in' input ports to the top level module. Why are they not there for 'txp_out' and 'txn_out'?

    2) Based on the Encoding type (8B/10B), the JESD204B subclass two is being used in the reference design. If that were the case, the deterministic latency is determined by the SYNC~ signal (for subclass 2). Then why is SYSREF (for subclass 1) being used still?

    3) From the datasheet of AFE7444 and schematic of AFE74XXEVM , I see there are so many SYNC~ signals (syncbcmos 1- 3, ADC_SYNC, DAC_SYNC and ADC_ALT_SYNC (4+1+1+1)). Why are there so many? If it is that, there is facility to use seven independent SYNC~ signals, what are the SYNC~ used in the reference design?

    Can someone please answer the above?

    Thanks in advance,

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Hi Chandrasekhar,

    Please find my answers below:

    1) In the included Vivado 2016.1 project from the reference design, I see that the data output lanes from the JESD204 TX IP are not mapped to any physical pins in any of the included constraint files. Also in the implemented design, there is no automatic mapping of data output ports 'txp_out' and 'txn_out' to any physical pins(which also should not be expected as the mapping needs to be specified in a constraint file). I see that they are there for the 'rxp_in' and 'rxn_in' input ports to the top level module. Why are they not there for 'txp_out' and 'txn_out'?

    [Vijay]: You don’t have to explicitly mention the SERDES pins as these are usually Hardware blocks and are inferred by Vivado. When you specify the number of lanes used in the JESD PHY block, it will assume that the SERDES lanes used are the first set if not specified. If you want to override this, you may specify the SERDES pin mapping explicitly. You may open the IO Planning view of Synthesized or the Implemented (Recommended) designs to see the SERDES pins assigned by Vivado.

    2) Based on the Encoding type (8B/10B), the JESD204B subclass two is being used in the reference design. If that were the case, the deterministic latency is determined by the SYNC~ signal (for subclass 2). Then why is SYSREF (for subclass 1) being used still?

    [Vijay]:The Subclass is not specified by the Encoding type. The JESD204B standard supports only 8B/10B encoding in a variety of Subclass types 0 (No deterministic latency), Subclass 1 (SYSREF enabled determinism) & Subclass 2 (SYNC Signal enabled determinism). The Subclass used by the JESD204B Base IP is specified by configuring a register in the IP. Take a look at the Xilinx Product Guide for the JESD204 IP (PG066). If Subclass 2 is used, the IP will ignore the SYSREF signal and use the SYNCB signal for deterministic latency.

    3) From the datasheet of AFE7444 and schematic of AFE74XXEVM , I see there are so many SYNC~ signals (syncbcmos 1- 3, ADC_SYNC, DAC_SYNC and ADC_ALT_SYNC (4+1+1+1)). Why are there so many? If it is that, there is facility to use seven independent SYNC~ signals, what are the SYNC~ used in the reference design?

    [Vijay]:The AFE7444 JESD204B interface has two differential LVDS SYNC outputs and two differential LVDS SYNC inputs. The AFE7444 also has four single-ended CMOS GPIO pins that can be programmed as SYNC outputs or SYNC inputs. Refer to section "7.3.5.1.1 SYNC Interface" in datasheet for more information on how to configure SYNC signals. By default GUI configuration, one differential LVDS sync input and one differential LVDS sync output, ADC_SYNC_P/N and DAC_SYNC_P/N are used for all Rx channels and all Tx channels respectively. 

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

     

    Thanks for the elaboration Vijay. However I would still need clarification regarding the following

    Vijayendra Varma Siddamsetty said:
    The Subclass used by the JESD204B Base IP is specified by configuring a register in the IP.

    I did take a look into PG066. It says there is a field named subclass in the register. However there is no explicitly choosing the subclass in the GUI atleast (As shown in Figure 4-2 of the same document(PG066) or in the GUI for JESD204 IP v7.2 used in Vivado 2018.2 design). I

    Please explain if implicitly changing the design to support subclass 1 is as follows (if not, please mention the procedure)

    In the JESD204 ->Re-customize IP->Default Link Parameters

    1) Default SYSREF Always: It is currently 'SYSREF Always Off'. Need to be changed to 'SYSREF ALWAYS On'

    2) Default SYSREF Required on Re-Sync: 'SYSREF Not Required'. Need to change it to 'SYSREF Required'

     

    Edit 1:  I removed the  part where I spoke about the FMC pins on AFE side, not corresponding to FMC pins on FPGA side. It seems I was a little confused regarding the FMC pin names and FPGA pin names. Excuse that.

    If we were to change to subclass 1, can we remove 'tx_sync', 'rx_sync' and 'rx_alt_sync' from the reference design? Because as you said, if either of SYSREF or SYNC~ signals were to be used, based on the subclass of operation, they are not needed in subclass 1? Would the design with SYSREF then work with KCU105?

     

    Also, which of the sub-classes (subclass 0 or subclass 1) is preferred generally? (a small merit-demerit comparison would be helpful). 

     

    Thanks in advance,

     

    Chandrasekhar DVS.

     

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Hi Chandrasekhar,

    Subclass 0 does not support deterministic latency. Sub class supports SYSREF based deterministic latency. This doesn't mean SYNCB signal is needed in subclass 1. It is needed for JESD SYNC to be established. But it's not used for deterministic latency.

    AFE7444 only supports subclass 1 based deterministic latency.

    Regarding your question on how to design for subclass 1 support, let me check with our firmware team.  I will get back by Friday.

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    Thank you for your answer. 

    We are still a bit confused. So I am summarizing my understanding:

    1) AFE7444 only supports subclass 1 based deterministic latency 

    2) However the reference design does not implement deterministic latency (which in this case is subclass  1 based)

    3) No matter which subclass, SYNC is always needed

    A few questions here:

    1) What is the role of SYNC in subclass 1 design?

    2) In subclass 2, does SYNC have any other role apart from ensuring deterministic latency?

    3) What is better, subclass 1 or subclass 2?

    4) What is the role of SYNC in the reference design?

    Awaiting a reply,

    -Chandrasekhar DVS

  • 0 in reply to jim s
    Genius 3040 points

    Hi jim s,

    Can you confirm if this reference design would work with Vivado 2018.2? I mean if the design were to be recreated on Vivado 2018.2. Also if you have any idea of confirming it, that would also help us greatly.

    If there are any inherent bugs in 2018.2 that were fixed in the latter version, the fixes that are necessary for reference design to work, please also mention them as that would greatly help us in starting-off at a better point to work on this design.

    Unfortunately, we have not foreseen this and deleted the reference design file you referred. Can you also provide access to the reference design link you provided, using Zync Ultrascale+ board?

    Thanks in advance,

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Chandrasekhar,

    Please find my answers below:

    1) What is the role of SYNC in subclass 1 design?

    [Vijay]: During initial JESD link-up or if link is lost during operation, JESD receiver asserts SYNC signal to request link re-initialization from JESD transmit. This usage of SYNC is common for subclass 1 and 2.In subclass 2 SYNC is also used to ensure deterministic latency.

    2) In subclass 2, does SYNC have any other role apart from ensuring deterministic latency?

    [Vijay]: See answer for (1)

    3) What is better, subclass 1 or subclass 2?

    [Vijay]: Please go through app note below. Since SYNC meeting setup and hold time becomes a challenge at higher sampling rates, it is recommended, as per standard, to use Subclass 1 for speeds above 500MSPS for both ADC and DAC

    4) What is the role of SYNC in the reference design?

    [Vijay]: Reference design is using subclass 1 (This is default for Xilinx IP). Role is as described in answer for (1)

    Please refer to appnote on JESD204B subclass 0,1 and 2:

    Regarding your question if this reference design would work with Vivado 2018.2, here is the response from our firmware team:

    "JESD204B is a relatively stable IP released by Xilinx as it has been out for quite sometime. There should not be any bug fixes in the later version. That being said, it is always recommended to develop with the latest tools available when you are starting with the design. The other IPs may also have some changes forcing you to make some firmware changes. Please refer to the "All IPs changelog information" for the Vivado version you are targeting. The changes will also be available in a log file when you upgrade the design to a newer version of Vivado (refer the Report IP Status option in Vivado for more information)."

    Regards,
    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    TI__Genius 10505 points

    Chandrasekhar,

    Reference design link Jim provided earlier:

    https://txn.box.com/s/gh41no11wcvrmcli8w0y0e5ov1fabkwd

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    Thanks for the elaboration!

    Also one more thing I wanted to ask.

    In the reference design (for KCU105 and AFE), there is the JESD204 IP configured as transmit. The output ports (gt0_txdata, gt1_txdata.....gt7_txdata) are each 32 bit wide parallel lines. I would like to know how the data is mapped from input port tx_tdata[255:0] to these output ports (gt0_txdata, gt1_txdata.....gt7_txdata) for the JESD204 IP block. When I say how the data is mapped, the reference design is 2x44210 mode for which the sample format is

    at the JESD204 output side, each of the gtN_txdata (each lane) have 32 bits in parallel. Let us talk about Lane 0 which would correspond to gt0_txdata.

    How are A-i0 and A-i1 arranged over these 32 bits of gt0_txdata? Can you tell me to what bits of gt0_txdata, is A-i0 mapped to. Also for example, IF  A-i0 is mapped to gt0_txdata[31:16], which bit in gt0_txdata[31:16] is the least significant bit of A-i0?

    Thanks in advance,

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Hi Chandrasekhar,

    I'm waiting for the response from our firmware team for your question. Please give me until Friday to get back.

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    Sure. Awaiting your reply.

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Chandrasekhar,

    Please view the “Transport layer” of PG066 for information on the sample packing.

    The transport layer designed looks like this –

    1. The 256b input to JESD204 IP (tx_tdata[255:0]) is split to the corresponding lanes like below–
      1. Gt0_txdata – tx_tdata[31:00]
      2. Gt1_txdata – tx_tdata[63:32]
      3. And so on.
      4. The Lanewise data is further sent out on the SERDES lanes as –
        1. First bit out of lane 0 is the MSB of the Lower significant Byte of gt0_txdata.
        2. Lane 0 – First sent - {gt0_txdata[7:0], gt0_txdata[15:8], gt0_txdata[23:16], gt0_txdata[31:24]} – Last sent
        3. In the 2x44210 mode you have described, A-i0 will appear as –
          1. A-i0[15:08]          -              Tx_tdata[07:00]                -              gt0_txdata[07:00]
          2. A-i0[07:00]          –             TX_tdata[15:08]                -              gt0_txdata[15:08]
          3. A-i1[15:08]          -              tx_tdata[23:16]                 -              gt0_txdata[23:16]
          4. A-i1[07:00]          -              tx_tdata[31:24]                 -              gt0_txdata[31:24]
          5. A-q0[15:08]        -              Tx_tdata[39:32]                -              gt1_txdata[07:00]
          6. A-q0[07:00]        –             TX_tdata[47:40]                -              gt1_txdata[15:08]
          7. A-q1[15:08]        -              tx_tdata[55:48]                 -              gt1_txdata[23:16]
          8. A-q1[07:00]        -              tx_tdata[63:56]                 -              gt1_txdata[31:24]

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    So I have been trying to open this reference design with Vivado 2018.2 in read-only mode atleast, so that I can begin with the project. However I see that I am unable to open the block design (design_1.bd) in the project folder. I also tried extracting the folder again from the provided .zip file but nothing resulted out of it. Following is the error I see, when I try opening the 'design_1.bd'

    Can you help me in how can I open it with Vivado 2018.2 so I can look at the block design and the configuration settings for the IP used, to recreate the design?

    Thanks in advance,

    -Chandrasekhar DVS

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    We will be using AFE79xxEVM to use the reference design. Hence the documents in the reference design talk about configuring AFE74xx for a modeusing AFE GUI. When referred to the AFE79xxEVM user guide, the supplied .py scripts automatically configure AFE79xxEVM and will also try to automate HSDC pro software to bring up JESD204B link. However because we will be using ZCU102, I see that something needs to be changed in the python scripts? To probably automate configuring ZCU102 using SCUI along with automatic configuration of AFE79xxEVM?

    We would like to atleast remove the 'configuring using HSDC Pro' part from the python scripts. This is because we see that HSDC pro is not compatible with ZCU102 board, from the release notes.

    Can you suggest what can be done here and am I right in my suspicions?

    Thanks in advance,

    -Chandrasekhar DVS

  • 0 in reply to Chan100
    TI__Genius 10505 points

    Hi Chandrasekhar,

    As AFE79xx is not yet publicly released (except for wireless applications), I will take close this e2e post and send you an email directly.  

    Regards,

    Vijay

  • 0 in reply to Vijayendra Varma Siddamsetty
    Genius 3040 points

    Hi Vijay,

    Sure. I too think its time to close this thread. 

    Thanks for all the inputs that were given! They were of great help.

    -Chandrasekhar DVS