UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
11,408 Views
Registered: ‎03-30-2012

TRN to AXI Migration for Kintex-7 with ISE14.7

Hi everyone,

We're trying to migrate our existing PCIe design (TRN interface) to the Kintex-7. The "7 Series Integrated Block for PCI Express" IP core (v1.11) only supports the new AXI interface. To generate this core, we used the Coregen utility distributed with ISE Design Suite 14.7.

 

To convert from the TRN to AXI interface, we followed to the letter the "Step-by-Step Migration Guide" described in PG054 (v1.8), page 407. Regarding these Migration steps, one of them seemed a little strange:  is it necessary to change the polarity of signals coming out of port user_clk_out  of the IP core block to connect it to the trn_clk port of our existing circuitry?

Doing so creates paths with a relative clock speed of twice the normal clock rate between sequential elements of the core and our own logic.

 

Is this a typo on PG054 or is this absolutely necessary? And if required, what is this used for?

 

Regards,

 

 Mike - Member of the FPGA Group, OPAL-RT TECHNOLOGY INC.

 

0 Kudos
4 Replies
Explorer
Explorer
11,365 Views
Registered: ‎06-22-2011

Re: TRN to AXI Migration for Kintex-7 with ISE14.7

Hi,

 

I am also confused. Since in TRN and AXI, the signals are sampled on rising edge of clock, why shoud the clock be inverted?

 

Have you done your migration? I believe the author of the guided didn't do it either.

 

Xiang Chao

0 Kudos
Adventurer
Adventurer
11,347 Views
Registered: ‎03-30-2012

Re: TRN to AXI Migration for Kintex-7 with ISE14.7

We did the Migration and it it currently under test. Currently, we do NOT invert the polarity of the signal user_clk_out when we connect it to the trn_clk port of our existing design.. And so far, it seems to be working pretty well.

 

I really wonder why the Xilinx support people cannot answer this simple question.

 

Anyway, I will report my final results when the tests will be completed.

 

Thanks for your reply,

 

 Mike - Member of the FPGA Group, OPAL-RT TECHNOLOGY INC.

0 Kudos
Explorer
Explorer
11,335 Views
Registered: ‎06-22-2011

Re: TRN to AXI Migration for Kintex-7 with ISE14.7

Hi,

 

I'm also trying to do the same work, just getting started.

 

I got another question in the migration guide. It's about the trn_trem_n logic:

 

this is the code nippet in the guide:

 

if s_axis_tx_tlast == 1 //in a packet at EOF
s_axis_tx_tkeep[7:0] = user_trn_trem_n ? 0Fh : FFh
else //in a packet but not EOF, or not in a packet
s_axis_tx_tkeep = FFh

 

Since trn_trem_n is active low, when it is 0, s_axis_tx_tkeep[7:0] should be 0Fh. So I think the code should be:

 

s_axis_tx_tkeep[7:0] = (user_trn_trem_n=0) ? 0Fh : FFh

                                                                  ^^^^^^^^^^^

 

Is this a mistake of the maual? Or I made a mistake?

 

Thanks

 

Xiang Chao

 

 

0 Kudos
Adventurer
Adventurer
11,319 Views
Registered: ‎03-30-2012

Re: TRN to AXI Migration for Kintex-7 with ISE14.7

Hello 'pumpkin',

 

Regarding the equation to generate signal s_axis_tx_tkeep[7:0] from user_trn_trem_n, I beleive that the code provided by Xilinx is correct.

 

In pseudocode as well as in Verilog, a mux is written as following:

mux_val = mux_sel ? mux_val_if_sel_is_ONE : mux_val_if_sel_is_ZERO;

 

From UG517, v5.1, p34:

• trn_trem_n =0, packet data on trn_td[63:0]

• trn_trem_n =1, packet data on trn_td[63:32]

 

Therefore, the following equation for 64-bit interface seems OK  because you want to keep only half the bytes (0Fh)  when user_trn_trem_n is ONE and all the bytes  (FFh) when user_trn_trem_n is ZERO

    s_axis_tx_tkeep[7:0] = user_trn_trem_n ? 0Fh : FFh

 

Regards,

 

 Mike - Member of the FPGA Group, OPAL-RT TECHNOLOGY INC.

0 Kudos