cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ik315717
Adventurer
Adventurer
8,013 Views
Registered: ‎02-17-2017

SGMII 1G Ethernet 16.0 to PHY on the board

Jump to solution

Hello,

 
I am currently trying to get the KCU116 SGMII 10/100/1000 Ethernet PHY working in a simple design. I am attempting to customize and instantiate a "1G/2.5G Ethernet PCS/PMA or SGMII (16.0)" IP Core in the top level of my design. Here are some details about my Project and IP:
 
I am running Vivado Design Suite 2017.1
I am targeting a : KCU116 Kintex Ultrascale+ Board (Set in Project Settings)
IP Core Details: 
Board Tab: DIFFCLK Board Interface - Custom
Data Rate Tab:  1 G
Standard Tab: SGMII
Core Functionality Tab:
Physical Interface -> LVDS Serial
Clock Selection -> Async
LVDS Ref Clock -> 625
Num of Lanes -> 1
TxLane0 -> DIFF PAIR 0
RxLane0 -> DIFF PAIR 0
TxInUpperNibble  -> 1
MDIO Management Interface -> Unchecked
Auto Negotiation -> Checked
 
SGMII PHY Mode Checked
Include Shared Logic in Core
 
The issue I am having:
There are too many nets that are unrouted. I have tried to debug this issue to the best of my ability. All the the unroutable nets that are listed are not at a hierarchal level that I can access. They are all deep in the generated core. I have come to the conclusion that I cannot remedy the situation at all by manipulating the input ports. The Evaluation Board has a a pinout and schematic. I have attached the schematic and have used all the original signal/net names. 
 
Attachments:
Trans-Only.zip  - This is my whole project zipped up
.pdf - This is the schematic for the evaluation board
Error-Messages - All the error messages from Vivado
 
 
Solution:
Since this design has absolutely no proprietary code of ours, just some top level code and xilinx IP from vivado, I would be very appreciative if a xilinx tech service agent could send me a project that Synthesizes, Places, Routes, and writes Bitstream with this one IP core implemented.
 
Thank you very much for your assistance.
0 Kudos
1 Solution

Accepted Solutions
ik315717
Adventurer
Adventurer
11,694 Views
Registered: ‎02-17-2017

@dwisehart

@nanz

 

@hchen213

@nanz

 

I have solved the issue that I was having. In the particular application of this IP I was using the following pins on the KCU116 Evaluation board - using the Kintex Ultrascale+ part 

TXP - N24

TXN - P24

RXP - U26

RXN - V26

SGMII_CLK_P - T24

SGMII_CLK_N - U24

 

This pin out requires the user to magically know that the TxLane0 must be set to Diff Pair 2

 

This pin out requires the user to magically know that the RxLane0 must be set to Diff Pair 0

 

With Tx in Upper nibble set to 0

 

After making these changes to my IP Wizard configurations, the design routes just fine.

 

View solution in original post

30 Replies
dwisehart
Scholar
Scholar
7,944 Views
Registered: ‎06-23-2013
Did you instantiate one port or multiple ports?
0 Kudos
nanz
Moderator
Moderator
7,928 Views
Registered: ‎08-25-2009

I think these are warning and not errors. Most of these warnings are okay.

They are coming from

  1. Not all bits of RIU data being used
  2. Some bits in BITSLICE-BITSLICE_CONTROL aren’t loaded and hence trimmed.
  3. Not all instance’s Rx_BtVal used.

 

Many of them are like connection between bitslice and bitslice control , there is hardly anything we can do in those cases.


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
ik315717
Adventurer
Adventurer
7,918 Views
Registered: ‎02-17-2017
@dwisehart I am only looking to instantiate one core with only one lane in the core. I included all of the details above and I included my project in a zip file. I would appreciate it if you could download the zip file and take a look in vivado. Thank you very much for your reply. Please get back to me with any more questions or more information at your earliest convenience
0 Kudos
ik315717
Adventurer
Adventurer
7,916 Views
Registered: ‎02-17-2017
@nanz there are a few input ports for the Riu data. As the example design did comma I tied all of these ports off to zero comma because they are for other lanes which I am not intending to use. There are Riu outputs comma but the example design also leaves these open. I would really appreciate if you took some time to download the zip file that is attached and open up the project in vivado so that you can see that there are indeed bit stream errors not warnings. The errors cannot be downgraded to warnings or critical warning. They are Drc RTSTAT - 1 Evers. Thank you very much for your reply and please get back to me with more information or more questions at your earliest convenience.
0 Kudos
ik315717
Adventurer
Adventurer
7,898 Views
Registered: ‎02-17-2017

@nanz

 

"Many of them are like connection between bitslice and bitslice control , there is hardly anything we can do in those cases."

 

Okay if there is nothing I can do, how do I get the build to pass write_bitstream. The build does indeed have errors. Your statement below is incorrect for write_bitstream - it is correct when only looking at implementation.

 

"I think these are warning and not errors"

 

If there is a way for bitstream to not error out on the DRC RTSTAT-1 Error - which I cannot downgrade to a critical warning, please let me know.

0 Kudos
dwisehart
Scholar
Scholar
7,897 Views
Registered: ‎06-23-2013

As provided, the project won't synthesize.  open_project shows missing paths local to your system:

 

 

Two of them are in your triple.xpr file:

 

<Option Name="IPRepoPath" Val="$PPRDIR/../../../../../dist/fpga/xilinx/Vivado/2016.3/data/ip"/>
<Option Name="IPRepoPath" Val="$PPRDIR/../../../../../../local/Xilinx/Vivado/2017.1/data/ip"/>

 

The last two are in your TripleAsync.tcl file:

 

set_property ip_repo_paths {
/teza/dist/fpga/xilinx/Vivado/2016.3/data/ip
/local/Xilinx/Vivado/2017.1/data/ip
} [current_project]

 

Additional files are under: /teza/home-ln/ikennedy/Development/

 

Referenced from: // Host        : sportking.teza.com running 64-bit unknown

 

First question: are you intentionally using IP from both 2016.3 and 2017.1, because you are using IP from both.

 

Second question: why do you have two copies of the TripleAsync IP attached to the project?  This may be confusing implementation.

This will be sufficient to build the project:

After making this change and resynthesizing the project, look through the synthesis warnings about code that is being eliminating.  I suspect an unconnected top level port is having the unintended consequence of eliminating logic you need to complete the implementation and build a bit file.

 

Daniel

 

0 Kudos
ik315717
Adventurer
Adventurer
7,893 Views
Registered: ‎02-17-2017

@dwisehart

 

Thank you, yes I am aware of the two existing repos. I am sorry that the project was not "out of the box" ready to synthesize, it was my intention to do so, but I didn't think about those specific aspects.

 

When I created the IP I was targeting the IP in the 2017.1 repo. In a previous project I attempted to use the deprecated version.

 

It seems to me that you have provided me with a solution, but for some reason I cannot see the attachments that you have included in the post.

 

//-------

This will be sufficient to build the project:

 

<cannot access attachment>

 

After making this change and resynthesizing the project, look through the synthesis warnings about code that is being eliminating.  I suspect an unconnected top level port is having the unintended consequence of eliminating logic you need to complete the implementation and build a bit file.

 

Daniel

///-------

 

 

Would you mind sending me the solution via another form of communication? my personal email is ian.L.kennedy93@gmail.com
Or you can send me a personal message with the info and attachments.

 

I will try to look at the community forum response in other browsers.

 

Thanks again! I will accept the solution and distribute the info once I get it working on my machine, when I get the attachments.

0 Kudos
dwisehart
Scholar
Scholar
7,890 Views
Registered: ‎06-23-2013

Sorry about that.  It looks like my browser was showing them to me, but the forum did not capture them, because I do not seem them in the flow now either.

 

See if you can see these two captures which I am attaching as files.  The first shows me what I see you have now and the second shows me what I see after I delete the second IP instance.

 

Daniel

 

2017-06-09_11-57-29.jpg
2017-06-09_11-58-41.jpg
0 Kudos
dwisehart
Scholar
Scholar
7,887 Views
Registered: ‎06-23-2013
And I still see them this time after leaving the forums and returning. Hopefully you see them and this will be some help in solving your problems.

Daniel
0 Kudos
ik315717
Adventurer
Adventurer
7,496 Views
Registered: ‎02-17-2017

@dwisehart

 

Okay I can see them now. Yes there were two different IP cores set up, because I was iterating through the different configuration combinations. 

 

In my original, first post I included the intended IP configuration details (complete details).

 

I have attached a project again, this time I do not see any Synthesis warnings at all. But I still get my unrouted critical warnings in implementation then errors in write_bitstream.

 

Please let me know if you have any ideas now that there are zero synthesis warnings. Thanks again!

 

 

 

 

 

0 Kudos
ik315717
Adventurer
Adventurer
7,495 Views
Registered: ‎02-17-2017

@dwisehart

 

Yes I see them now. 

 

Thank you very much for your time and effort, I do appreciate it.

 

I have replied to a previous post of yours on this thread with a new project, without the repeated IP.

 

If you have some more time to continue helping me through this issue, please let me know of any ideas. 

 

THanks!

0 Kudos
dwisehart
Scholar
Scholar
7,484 Views
Registered: ‎06-23-2013

Sorry for the delay.

 

I looked through your latest project and it is as I suspected: parts of the design you need are being optimized away.  I am not sure why this is not mentioned in the synthesis or implementation.

 

Looking at the implementation schematic, you can see the routes that are not routing.

2017-06-10_03-36-48.jpg

 

Now the first hint of a problem is that the remaining unrouted routes are connected to a module named clock_reset_i, because you would expect the data to do more than reset.  Looking at the outputs of this module, it is doing a lot more than reset, but the output bytes (Rx_BitVal_X) are mostly not connected.

 

Pulling back to the top level implementation schematic, the received data is not connected here either:

 

2017-06-10_03-41-05.jpg

 

Looking back at your Verilog source, you have wires for the received data, but they are only connected to the receive port, not to anything else.

 

2017-06-10_03-43-32.jpg

 

That is your problem.  With the RX data not being used, the implementation is optimizing away parts of the design you need.  You are going to have to do something with the RX data to make the implementation complete.  The implementation tools are not that smart: you can probably simply connect these wires from gmii_rxd_0 to gmii_txd_0 without any other control signals and make the tools happy.  It is possible you will have to also use rx_btval_X and/or change some of the IP inputs, but I kind of doubt it.  Let us know.

 

Daniel

 

0 Kudos
ik315717
Adventurer
Adventurer
7,473 Views
Registered: ‎02-17-2017

@dwisehart

 

Thank you for your response.

 

I actually walked through the same exact analysis in my tools as I have been continuing to work on this task. My first instinct to connect them to unused wires was due to a DONT_TOUCH configuration on the TRIPLE IP.

 

I have connected the RX pins on the IP core to actual top level port pins which promised to never optimize away. I am still receiving the same errors. I will attach my project as soon as possible.

 

Please take a look when you have time. I for sure thought that it was the RX pins as well, and I completely agree with all your analysis, but after adding in top level port pins the errors still occur. With no warnings at all in synth.

 

Thanks again, I will post again soon

0 Kudos
ik315717
Adventurer
Adventurer
7,471 Views
Registered: ‎02-17-2017

@dwisehart @nanz

 

Hey Daniel,

 

As promised, here is my project again. I have connected the Rd gmii bus up to pins on the top level. I have checked the schematic again and see that it is now indeed connected up.

 

It seems as though many routes are unreasonable unrouted. I have been looking over the results over and over again. Thank you so much for your time and effort. 

 

I look forward to hearing from you. Enjoy the weekend!

 

-Ian

0 Kudos
dwisehart
Scholar
Scholar
7,447 Views
Registered: ‎06-23-2013

Ian, I believe there is a difference between keeping a route with DONT_TOUCH, and having a route that is used.  In the case of DONT_TOUCH, the route is there, but there is no timing from the source DFF to the destination DFF, because there is no destination DFF (or port).  To make this design work I think you need to actually use the RX and TX paths.  Otherwise the implementation does not know to keep other parts of the design that feed a wire that is there but goes nowhere.

 

I see you are now using both the RX and TX paths, but some of the same routes are failing.

 

The TripleAsync_ooc.xdc clock period is 1.6.  Is the clock 625 or 125 as you have listed in your constraints?  Even this is probably not important.  You can try modifying that clock period from 1.6 to 8.0 and resynthesizing the TripleAsync, but I am not sure that will change much.

 

I traced out a couple of the "no routable loads" nets and they have routes, but the router does not find paths for them:

 

2017-06-12_03-59-04.jpg

 

If changing the timing constraint does nothing, I would delete the IP--including the files--and then shut down Vivado.  Restart Vivado and create new IP with the same parameters.  If that does not fix it I do not know.  The Bitslice silicon is obviously important to what you are trying to do.  It seems like there is an incompatible configuration somewhere.  

 

You might try selecting a standard of "Both" instead of "SGMII" in the IP configuration, but that is grasping a bit.

 

When I open the IP Example Design (right click on the Triple IP), the example design is very similar to yours now.  Does the example design synthesize and implement for you?  If it does, you should be able to add your design to the example design a little bit at a time and see where it breaks.

 

Sorry I could not help more,

Daniel

 

 

 

0 Kudos
ik315717
Adventurer
Adventurer
7,440 Views
Registered: ‎02-17-2017

@dwisehart

 

Thank you very much for your efforts!!

 

I will be sure to let you know the solution when I figure it out. If ever.

 

I will attempt to re create the IP in total and also I will try to use a different significant configuration as you suggested "Both".

 

This issue definitely seems like some sort of incompatibility and/or vivado file generation bug of some sort. I have never had this much trouble getting the tools to work. Also, no, the example design does not route for me if I throw a simple board targeted top file around it. 

 

Thanks again!

0 Kudos
ik315717
Adventurer
Adventurer
11,695 Views
Registered: ‎02-17-2017

@dwisehart

@nanz

 

@hchen213

@nanz

 

I have solved the issue that I was having. In the particular application of this IP I was using the following pins on the KCU116 Evaluation board - using the Kintex Ultrascale+ part 

TXP - N24

TXN - P24

RXP - U26

RXN - V26

SGMII_CLK_P - T24

SGMII_CLK_N - U24

 

This pin out requires the user to magically know that the TxLane0 must be set to Diff Pair 2

 

This pin out requires the user to magically know that the RxLane0 must be set to Diff Pair 0

 

With Tx in Upper nibble set to 0

 

After making these changes to my IP Wizard configurations, the design routes just fine.

 

View solution in original post

dwisehart
Scholar
Scholar
7,369 Views
Registered: ‎06-23-2013
Wow! That is a fantastic find. How did you figure it out? Congrats!
0 Kudos
trm61
Visitor
Visitor
7,178 Views
Registered: ‎06-25-2017

This is for the KCU116 board issue? 

You are saying it now works?

I really need to know, because if it doesn't, I cannot allow my order to draw payment if they do not cancel the order.

The only reason I ordered that board is the Ethernet.

Thanks @ik315717!

0 Kudos
trm61
Visitor
Visitor
6,751 Views
Registered: ‎06-25-2017

I am confused, you are still having issues with the PHY LEDs not coming on (phy not working), or not?

Thanks @ik315717

0 Kudos
ik315717
Adventurer
Adventurer
6,736 Views
Registered: ‎02-17-2017

@trm61

 

This accepted answer is strictly for instantiating the IP Core mentioned. I needed to first complete this step to implement the design I wanted on the KCU116. After moving on, when this IP core placed and routed, I discovered that I could NOT POWER THE PHY.

 

So no, I have not resolved that other issue of powering the PHY.

0 Kudos
trm61
Visitor
Visitor
6,729 Views
Registered: ‎06-25-2017

@ik315717

 

Thanks, I wonder if they can provide a work-around. 

If not I need to get them to cancel this order and find an alternative.

This is kind of life and death for me :(

 

0 Kudos
ik315717
Adventurer
Adventurer
6,725 Views
Registered: ‎02-17-2017

@trm61

 

The KCU105 works great. It has an Ultrascale part though, not Ultrascale plus. 

0 Kudos
trm61
Visitor
Visitor
6,719 Views
Registered: ‎06-25-2017

@ik315717 Thanks, but that doesn't have Pcie DMA free license and I do need the larger FPGA.

0 Kudos
trm61
Visitor
Visitor
6,683 Views
Registered: ‎06-25-2017

@ik315717

 

Maybe I am misunderstanding.

Does the KCU105 board require purchase of a license from Xilinx or Northwest Logic to use the Pcie DMA?

If so, how much?

Is that required to function via Pcie, or can you use other IP from the integrator?

Can the board be used standalone?

Are the provided drivers modifiable for a customer purpose?

 

A second check looks like this FPGA is actually larger than the one on the KCU116 board, correct?

 

Thanks!

 

0 Kudos
ik315717
Adventurer
Adventurer
6,678 Views
Registered: ‎02-17-2017

@trm61

 

I am sorry but I do not have that information. I am not experienced with the use of PCIe on these boards.

0 Kudos
trm61
Visitor
Visitor
6,668 Views
Registered: ‎06-25-2017

Just fyi, they want $22k to unlock the pcie dma so it doesn't need reset every 12 hours :(

That means if I did design something I wanted to run, I couldn't.

0 Kudos
josesmn
Visitor
Visitor
4,395 Views
Registered: ‎06-15-2018

I have tried to implement the 1G/2.5G Ethernet PCS/PMA or SGMII IP 16.1 as a GMII to SGMII converter in 1G data rate and in SGMII std in VCU108 board using Vivado 2017.1 . The system is working in loop back mode (config_vect(1) == 1) in board. But it seems not communicating with the Marvell PHY on the board. The  link between on board PHY and PC is up (verifiable through the LED on RJ45). In VCU108 board the clock output to the IP is 625MHz. The ip is generated for this frequency. Clock output of 125MHz is coming out from the IP and is fed to the GMAC core.  The physical interface chosen is LVDS Serial.

 

What could be the reason? Please help.

 

Jose.

0 Kudos
dwisehart
Scholar
Scholar
4,388 Views
Registered: ‎06-23-2013

You probably need to start a new topic to get a good response.

 

Daniel

 

0 Kudos