05-19-2017 12:01 AM
My generated 4-lane Aurora 64b66b simplex TX output "reset2fg" sometimes goes active. During that time TREADY also goes low (not accepting transmitting data) and cause my transmitted data to overflown. The Aurora user guide does not describe much about the signal reset2fg beside saying it is used to reset the frame generator in the example design.
My question is why the reset2fg goes active and TREADY drop. What is the cause and how to fix it.
I notice that all 4 lanes stay up, channel is still up, mmcm does not go out of lock at all.
06-16-2017 10:40 PM
06-19-2017 02:09 PM
Thanks Venkata for your response.
I have found out this is a big issue for my design because not just to reset the frame generator or frame checker, the Aurora IP stops transmitting data during that reset time, and hence causing a big back pressure on transmitted data.
According to IP manual, since I am using simplex TX mode, the Aurora IP, once a while, stops transmitting data, switching to its own channel bonding cycle to make sure the receiver can stay in sync with the transmitter. There is a parameter to specify how often this channel bonding cycle will happen, but it does not help in my case.
I finally have to tweak the design to make the channel bonding cycle happen only during my idle HSync time, when no data is transmitted.
BTW, according to IP user manual, this happen only in Simplex mode. But I have not tried the other modes yet.
03-15-2019 09:18 AM
The time that TX_READY is low is huge. From your screen capture it looks to be 600 clks. That's huge. I am experiencing the same thing. When I simulate the example design I see I pause in the TX_READY that seems to last only 9 clks. So, I designed for that. But, running the synthesized design in a Virtex 7 and using the ILA cores to capture I can see that the TX_READY goes low for this huge amount of time (4us+) and occurs periodically as explained in PG074. How were you able to get a work around for this huge down time in transmission. My receiver eventually runs dry because of this.
08-07-2019 07:09 AM
In simplex mode, the Xilinx Aurora IP periodically stops the normal data transfer to perform Channel Bonding (CB) sequence. Xilinx provides a parameter to set how often CB happen. This method doesn’t fit well in my application. I have to modify Xilinx IP, stop the counter that triggers the CB, and bring the trigger out so that my application can trigger CB when best. Hope that it helps. TD
08-07-2019 07:57 AM
Thanks for replying, I appreciate it.
I was surprised to find that this was considered 'normal' behavior for simplex TX mode. Your core modification sounds like an interesting idea. In my application I was able to add a deep enough fifo to help absorb the gaps, but that won't work for everyone as it depends on the ingress and egress rates.
08-14-2019 06:53 AM
Hi Edward. My application is in video domain. So I can make the mod to stop the auto CB, and kick start the CB cycle during Vertical blank, where I have no transmitted data. Hope that this technic works for you. Otherwise, can you use the duplex mode? I think only simplex requires CB cycles. Regards,
11-20-2019 02:22 PM
Hi @venkata ,
I am running a loopback simulation on the Aurora 64b66b on Ultrascale+ .
The final design for this unit test would be to have the Aurora connected on the FMC connector 33 ( FMCP_HSP pins ) .
On this connector is plugged an FM-S14 card with 4 sfp channels and on one of those channel it is applied a loopback bridge.
The loopback test runs fine in Behavioral simulation since the feddback signal "s_axis_tready " is set up to high and remains like that. Conseuquently i see the signal sent and received inside the core.
While during Post-Synthesis simulation the "s_axis_tready " stays low all the time . What it is necessary to do to make the Aurora Core to set this signal to high value and consequently allow the loop back communication.
I took care to provide through the FPGA design the proper activation signal to the FM-S14 card.
Can you please give me any help , I am completely blind in this
Thanks a lot
11-20-2019 02:43 PM
I doubt if your observations are because of not speeding up the post-synth simulation.
Have you set the attributes required to speed up the post-synth simulation? If not, please refer to the details are available on page 100 of PG074.
11-20-2019 03:00 PM
I do not understand where to set up that parameter.
Shoul i write set c_example_simulation true in the TCL console before tu run the Behavioral simulaiton?
Should I add it to the constraint file ?
11-20-2019 03:32 PM
I tried to run the Aurora example provided by vivado 2018.2 (which is the same I think described by the aurora manual)
and it synthesize but if I try to run the Post-synthesis simulation I got the following error message
[XSIM 43-3138] "c:/..../aurora_64b66b_0_ex/imports/aurora_64b66b_0_tb.v" Line 328. Cross Language Hierarchical name(aurora_example_1_i.rx_tvalid_r) is not supported in this context.
11-21-2019 06:43 AM
I managed to have the Aurora64b66b Example running in Post-synthesis simulation ( so I fixed the error message of yesterday).
The thing is that in Post-Synthesis simulation again also this example , like my project, has the issue that the s_axis_tready never goes high , as now I have been running it for 10ms (I noticed that it goes high for few nanoseconds at the very beginning of the simulation). So (???)
While , as it happens in my project, all is fine in Behavioral simulation.
Could you give me any help please?
11-22-2019 07:13 AM
Hi @venkata ,
do you have any updates ?
Another question, I noticed that there is an information which seems missing in the manual of the vcu118 Ultrascale+ (ug1224-vcu118-eval-bd) but which is present for example in the VC707 (Virtex 7 manual).
So regarding the Ultrascale+, where I can find the relation between the GT transceivers Quad number and the clock region ?
EXAMPLE: In the manual ug1224-vcu118-eval-bd.pdf at page 51, GTY transceivers, the transceiver QUADS are named with numbers 120 to 127.
But if I go in my project and double click on the Aurora64b66b, the Quad are indicated by clock region (specifically with two fields named "Starting GT Quad and Starting GT Lane ").
WHere is the relation between the QUAD numbers (QUAD 120, QUAD 121, etc.. ) and their corresponding clock regions ?
(Please reply to my request)
11-24-2019 09:52 AM
I noticed it's gone from the manual as well - very frustrating and un-necessarily difficult to figure out.
I ended up opening an implemented design an manually look at what's there. Select the gt's in the device view and see how they're named/numbered etc. Hopefully someone on the forum can provide you with a better solution.
11-24-2019 02:16 PM
thanks a lot. At the end I found my design generates the bitstream using the following pins fro the given GTY:
### GT CLOCK QUAD 120
set_property PACKAGE_PIN AK39 [get_ports MGTREFCLK0_N]
set_property PACKAGE_PIN AK38 [get_ports MGTREFCLK0_P]
# AURORA -SFP - CHANNEL 0 pins
set_property PACKAGE_PIN AJ45 [get_ports rxp_in]
set_property PACKAGE_PIN AJ46 [get_ports rxn_in]
set_property PACKAGE_PIN AL40 [get_ports txp_out]
set_property PACKAGE_PIN AL41 [get_ports txn_out]
Another question, i noticed that my Aurora core never gets ready (tready = channel_up= lane_up =0 always) .
It works only in Behavioral simulaition. My goal is to implement a loop back test on a sfp channel 0 on a FMC to sfp+ card mounted on the FMC connector 33 of the ultrascale. The Card is FM-S14 and I am providing it with the activation signals (i.e. rate_sel1 <= '1'; tx_disable1 <= '0';).
The loopback is realized by placin on the sfp module a Molex loopback bridge.
Have you ever done something similar? Any suggestions on how to fix it?
11-26-2019 12:29 AM - edited 12-01-2019 12:15 PM
11-26-2019 06:30 AM
just go on goolge and type pg074-aurora-64b66b.pdf and the AURORA64 manual will show up
11-26-2019 08:37 AM
are you able to get your Aurora core working during Post-Synthesi and real FPGA operation?
I have attached here a draft of my schematics.
My issue is that the Aurora core output signal s_axis_tx_tready is never asserted to "1" meaning the core never gets ready.
I am using Ultrascale+ vcu118 . Can you give me any suggestions on how to activate the core?
The user logic is a counter. I am providing:
gt_ref_clk (p/n) 250MHz,
pma_reset and reset pm constrained to kitboard push buttons.
Aurora core is connected to FMCP-HCS connector on the board on which it is plugged an FM-S14 card which has 4 sfp+ channels and I am activating only channel 0.
11-26-2019 08:39 AM
one thing: in my Aurora Interface there are not any DRP_clk signals to be fed (even if i indicated that in the schematic)