TI-JESD204-IP: The simulation on the Vivado

Hi Haginoya,

I am talking to our team about this and will get back to you with their response.

Regards,

David Chaparro

Hi David,
Thank you for your response.
I shall wait for your next response.
Regards,
Naoki Haginoya

Hi,

The TI204c JESD IP supports simulation in Vivado. When you changed the target device, please ensure that you regenerated the xci for the new transceiver with the same parameters as the original. This is described in section 8.7 in the IP user guide. 

If this has been done correctly, you can connect the Tx and Rx in loopback and follow the reset mechanism described in section 8.6. 

For loopback, connect all Tx lanes to Rx lanes and the tx_sync_n to rx_sync_n.

1> Start with master_reset_n set to '0' and rx_sync_reset and tx_sync_reset set to '1'. 

2> Set master_reset_n to '1'. Until this is done, the transceiver will not be released from reset. Run for approx 5us. After this, the QPLL0 locked signals should be set to "11", indicating that both Quad PLLs have locked. Please note that this will happen only if the reference clock is correctly routed to the PLL in each Quad.

3> Once the PLL locked value is "11", set tx_sync_reset and rx_sync_reset to '0'. Run for about 100us (the time depends on the transceiver model) and you should see the Tx and Rx IP's importing and exporting data.

Regards,

Ameet

Hi Ameet,

Thank you for your answer. But I couldn't get the hoping result.

I checked the gtx_8b10b_rxtx.xci of the changed deveice.
I found only different for device name, speed grade, architecture and package.

Also, I changed your listed singles from inside signal to port signal of the 'TI_204c_IP_ref.sv' because I did'nt understand the working about inside the IP which named 'vio'.
The signals are master_reset_n, rx_sync_reset and tx_sync_reset.
I gave their signal from my testbench, they were working which you taught me.

I think if the TI IP require something option of Vivado, please teach me that.

Regards,
Naoki Haginoya

Hi Ameet,

Do you have any uodate?

Thanks

Muk

Hi Mukuno,

Kindly send me the following files:

The XCI file of the transceiver (after you remapped the design to the xc7k FPGA)

The top level testbench file where you are carrying out the clock and data loopback connections.

I will take a look at the above and see if I can spot some issues. Vivado should not require any special settings for simulations, because the same files are used for synthesis and P&R.

The VIO module is used for controlling signals in the FPGA during runtime. This allows the designer to set signals to 1/0 through the Vivado HW manager.

Regards,

Ameet

Hi,

I also noticed on more point in your first message. The sys_clk input to the reference design should also be 156.25MHz (illustrated in the diagram in section 8.1.2), but your message says it is 78.125MHz. This clock is used by the PLL in the reference design to generate the rx_sys_clock signal, which is supposed to be 78.125MHz. In your case, it will create half of the required rate (39.0625MHz). Even in this case, the IP will still initialize and release the lanes, however, you will see buffer overflow errors (rx_lane_buffer_overflow outputs will be non zero). This is because the rx clock that you are providing is too slow compared to the rate at which the link is sending data.

I have been able to run the simulations for both the xc7z and xc7k devices and in both cases the link comes up properly. I have attached a waveform for this. 

1> 4us: The QPLL0 first changes from 0x0 to 0x3 (indicating that both Quad PLLs have locked)

2> 5us: The rx_sync_reset and tx_sync_reset are changed from '1' to '0'

3> 34us: The transceiver finishes initialization and you can see activity on the TxP/TxN and RxP/RxN ports

4> ~52us: The tx_data_ready signal changes from '0' to '1'. At this point, the Tx IP is ready to accept data from the user side. 

4> 54us: The Rx locks to the Tx and the sync_n signal goes from '0' to '1'. This allows the link to change from CGS mode (control characters) to Data

5> 55us: The Rx data lanes release on the user side, and the Tx data is reflected on the Rx. The rx_lane_buffer_overflow signals remain '0', because the rx_sys_clock (generated by the PLL) is 78.125MHz.

Please note that the simulation will work even if sys_clk is set to 78.125MHz (making rx_sys_clock 39.0625MHz). However, in that case once the Rx data lanes release, you will also see the rx_lanebuffer_overflow signals change from '0' to '1'.

Regards,

Ameet

Hi Ameet,

Thank you for your response, your waveform and you found out my mistake.
Also, I might find the cause, it's setting of the timescale sentence.
The "1ns/1ps" setting is lock the PLL, but the "1ps/1ps" setting doesn't seem to lock it.
I will continue the simulation of using TI IP.

Regards,
Naoki

Hi Ameet,

The result of simulation is wrong yet.
The Rx data doesn't match the Tx data like the attached wave.

The mgt_lane_rx(p/n) is like correct, but the rx_lane_data[7:0] is same value.

And I only connected the lane of zero in the adc_lane_rx(p/n), the rx_lane_data[7:0] was same value.
Why doesn't the rx_lane_data[7:1] match the 'Z'?
Do you think where do I have any mistakes?

Regards,

Naoki

Hi Ameet,

I found the way to solve the upper problem.
The simulator of XILINX doesn't work the below setting in the jesd_link_params.vh.

`define LANE_ADC_TO_GT_MAP {7,6,5,4,3,2,1,0}

It works if I changed to below.

`define LANE_ADC_TO_GT_MAP {3'b111,3'b110,3'b101,3'b100,3'b011,3'b010,3'b001,3'b000}

Regards,
Naoki