Forum Discussion

kharitonow's avatar
kharitonow
Icon for New Member rankNew Member
1 day ago

GTS DirectPHY simple simulation VHDL

Hello everyone,

I'm trying to do a simple GTS Direct PHY simulation in VHDL.

I've created a simple design in platform designer to try out the GTS transceivers in a serial loopback mode:

As one can see, most of the ports are exported to the testbench which handles almost all of them.
After asserting i_tx_reset, i_rx_reset and waiting until acknowledge flags go up and deasserting of the resets i_tx_reset and i_rx_reset, I expect that o_tx_ready and o_rx_ready go high. In my case, I see only o_tx_ready is asserted but o_rx_ready not.
Using QuestaSim I do the following:

set TOP_LEVEL_NAME tb_gts
set USER_DEFINED_ELAB_OPTIONS "-t fs"
source msim_setup.tcl
dev_com
com
vcom +acc -2008 ../../../tb/tb_gts.vhd
elab_debug
add wave -position insertpoint sim:/tb_gts/dut/gts_0/*
add wave -position insertpoint sim:/tb_gts/dut/s10_user_rst_clkgate_0/*
add wave -position insertpoint sim:/tb_gts/dut/gts_reset_seq_0/*
run 200 us

Quartus version: 26.1
QuestaSim version: 2023.4, 2026.1
The test design is in the attachment.

What could lead to such behavior? Any ideas?
It must be something I did wrong. Can someone, please, help find out where is the problem?

Thank you.

2 Replies

  • Ash_R_Intel's avatar
    Ash_R_Intel
    Icon for Regular Contributor rankRegular Contributor

    Hi,

    Few things to checkout first. 

    1) Are the Tx and Rx serial lines connected at the testbench? Rx lines must have data incoming on it at the configured data rate for it to lock to data and to assert rx_ready signal.

    2) Check the reference clock frequency to the system pll.

    3) If all the connections are correct and the input clock frequencies are also as configured in the IP, then try running it for some more time. Run upto 1ms and see.

     

    Regards

  • Hi,
    thanks for the hints.
    I don't want to use the system pll clocking mode as it forces me to use elastic mode for FIFO TX PMA interface, which would cause additional datapath latency.

    It seems, that a complete clean up was needed. After clean up the o_rx_ready signal was there.

    If I may ask one more question.

    What is the best configuration for the lowest latency in the transceiver path?
    Currently I have the following:
    Datapath clocking: PMA,
    PMA width: 32,
    TX PMA interface FIFO mode: register,
    TX core interface FIFO mode: phase compensation,
    tx_clkout clock source: word clock divided by 1,
    RX PMA interface FIFO mode: register,
    RX core interface FIFO mode: phase compensation,
    rx_clkout clock source: word clock divided by 1.
    No FEC,
    No PCS.

    Is there something I can do else to reduce the GTS transceiver latency?

    Best regards.