cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jg_bds
Scholar
Scholar
3,287 Views
Registered: ‎02-01-2013

OSERDES3 Implementation in (Zynq) Ultrascale+

Jump to solution

I've been trying to implement an AXI Ethernet MAC with an RGMII interface in a Z3U.  For other reasons (ok... timing headaches) I've pushed down into the implemented design.  Below are a screenshot of the schematic of the implemented design (zoomed in to show a particular OSERDES3 instance within the Xilinx IP), and a page from the pertinent SelectIO UG. 

 

Can anyone please reconcile these for me?

 

TEMAC_RGMII_1.jpg
TEMAC_RGMII_2.jpg
0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
4,653 Views
Registered: ‎01-23-2009

We are running into the fact that the tools are trying to help you. This is not an OSERDESE3 instantiation...

 

If you look a the same document (UG571), under Figure 2.9 it says:

 

"Note: ODDRE1 components used in a design are translated and implemented by the Vivado design tools as OSERDESE3 components."

 

In other words, there isn't really such a thing as an ODDRE1 - the tools describe one, and allow you to instantiate one, but in reality they get implemented in an OSERDESE3.

 

This is different than an OSERDESE3 in ODDR_MODE, which is using multiple shifters in the OSERDES to implement the D and T output DDR registers (using a frankly bizarre mapping...).

 

So what you are looking at is actually an ODDRE1 translated into an OSERDESE3. This makes sense since the RGMII doesn't really need either deserialization (it is truly taking GMII and transmitting it DDR), and it doesn't need the tristate flip-flops. Since this is just a "vanilla" ODDR, it makes sense that it only needs CLK and not CLKDIV.

 

Avrum

View solution in original post

0 Kudos
7 Replies
hpoetzl
Voyager
Voyager
3,283 Views
Registered: ‎06-24-2013

Hey @jg_bds

 

Does that OSERDES3 have ODDR_MODE set to "TRUE"?

 

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
jg_bds
Scholar
Scholar
3,276 Views
Registered: ‎02-01-2013

Yes; note the circle in the Cell Properties window in the upper image.

0 Kudos
jg_bds
Scholar
Scholar
3,272 Views
Registered: ‎02-01-2013

@hpoetzl               

 

Thanks for the input.

 

Yes; note the yellow circle in the Cell Properties window in the upper image.

 

 

0 Kudos
hpoetzl
Voyager
Voyager
3,269 Views
Registered: ‎06-24-2013

Ah, sorry, I clearly missed that one ... :/

-------------- Yes, I do this for fun!
0 Kudos
avrumw
Guide
Guide
4,654 Views
Registered: ‎01-23-2009

We are running into the fact that the tools are trying to help you. This is not an OSERDESE3 instantiation...

 

If you look a the same document (UG571), under Figure 2.9 it says:

 

"Note: ODDRE1 components used in a design are translated and implemented by the Vivado design tools as OSERDESE3 components."

 

In other words, there isn't really such a thing as an ODDRE1 - the tools describe one, and allow you to instantiate one, but in reality they get implemented in an OSERDESE3.

 

This is different than an OSERDESE3 in ODDR_MODE, which is using multiple shifters in the OSERDES to implement the D and T output DDR registers (using a frankly bizarre mapping...).

 

So what you are looking at is actually an ODDRE1 translated into an OSERDESE3. This makes sense since the RGMII doesn't really need either deserialization (it is truly taking GMII and transmitting it DDR), and it doesn't need the tristate flip-flops. Since this is just a "vanilla" ODDR, it makes sense that it only needs CLK and not CLKDIV.

 

Avrum

View solution in original post

0 Kudos
jg_bds
Scholar
Scholar
3,151 Views
Registered: ‎02-01-2013

@avrumw ,

 

Thank you for your reply.

 

I was aware that the OSERDESE3 was being translated from a ODDRE1 instance in the underlying code.  I didn't mention it, since my puzzlement involved only the OSERDESE3 instance.

 

This part your post appears to be key: "This is different than an OSERDESE3 in ODDR_MODE..."  It seems to me the difference you raise compels at least two separate types of ODDR_MODE operation for the OSERDESE3:

 

  1. When the OSERDESE3 is translated from an ODDRE1 instance, which causes the ODDR_MODE attribute to get set to TRUE, but the instance is clocked by the CLK pin--not by the CLKDIV pin--and
  2. When the OSERDESE3 is inferred from another source, which causes the ODDR_MODE attribute to get set to TRUE, but the instance is clocked by the CLKDIV pin, not by the CLK pin.

That is one tricky distinction.  My instant design appears to use the former type of operation.  The documentation seems to only cover the latter.

 

Thank you (and everyone) for the help.

 

0 Kudos
amaheshwari
Visitor
Visitor
279 Views
Registered: ‎08-31-2017

@jg_bds 

This is a fairly old thread, but I got here so this may be helpful for someone else.

The statements

  1. When the OSERDESE3 is translated from an ODDRE1 instance, which causes the ODDR_MODE attribute to get set to TRUE, but the instance is clocked by the CLK pin--not by the CLKDIV pin--and
  2. When the OSERDESE3 is inferred from another source, which causes the ODDR_MODE attribute to get set to TRUE, but the instance is clocked by the CLKDIV pin, not by the CLK pin.

That is one tricky distinction.  My instant design appears to use the former type of operation.  The documentation seems to only cover the latter.

Seem to be incorrect.  The device in question is mentioned as (Zynq) UltraScale+ but the data sheet page cited is for UltraScale (not UltraScale+).  According to AR# 67261 (Clock Difference Between OSERDESE3 ODDR mode in UltraScale and UltraScale+ devices), "When performing the transformation from ODDR to OSERDESE3 in UltraScale and UltraScale+ devices, differing clocking results will be found in the implemented design. In UltraScale, the clock is connected to the OSERDESE3 CLKDIV port and in UltraScale+, the clock is connection to the OSERDESE3 CLK port."

0 Kudos