element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet & Tria Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
AUBoard 15P AUBoard 15P SFP+ clock config
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Verified Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 261 subscribers
  • Views 228 views
  • Users 0 members are here
  • AUBoard-15P
  • sfp+
  • renesas
Related

AUBoard 15P SFP+ clock config

thill
thill 22 days ago

Hello,

I'm an AMD dedicated FAE at Avnet. My customer recently purchased AUBoard 15P to begin prototyping an SFP+ solution. It appears that the 10G SFP+ clock needs to come from component U56. Quick summary of what I have figured out so far:

  • U56 = Renesas 8T49N241-998NLGI
  • U56 provides clock to quad 226 MGTREFCLK0 (HDMI_CLK_8T49N241_N/P)
  • U56 has an I2C interface accessible by pins R22 (SDA) and R23 (SCL)
  • U56 expects RST pin connected to G22 to be driven HIGH to be enabled

Is there a bring up and register write sequence we need to apply to U56 via the I2C connection to enable pass through instead of clock recovery, and program it to 156.25MHz for the SFP+ Module? Customer attempted to enable U56 by driving G22 reset pin high but did not see an output.

Is the EEPROM available to the HDMI subsystem (U37) already programmed? They did attempt to apply the clock configuration example design that configures U57 EEPROM to U37 by changing the I2C pinout from B9/A9 (U57/U58 I2C bus) to R22/R23 (HDMI I2C bus) and running the IDT Timing Commander Tool -> EEPROM configuration tool, hopefully this attempted write did not cause U37 EEPROM to become misconfigured. Is there a way to verify U37 is correctly programmed?

Are there any example designs available for this board that use the SFP+ module on quad 226?

Thanks!

Trevor

  • Sign in to reply
  • Cancel

Top Replies

  • iksevas
    iksevas 21 days ago in reply to thill +1 verified
    Yes
  • iksevas
    0 iksevas 21 days ago

    Trevor - there is a reference design on the website for the clock generator. 

    https://www.avnet.com/wcm/connect/85941556-1002-4b59-9fc6-7ef59e1df223/aub-15p-dk-clkgen-v1p0.zip?MOD=AJPERES&ContentCache=NONE&CACHE=NONE&CVID=pikNCkz

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • thill
    0 thill 21 days ago in reply to iksevas

    Thanks for the reply. This flow configures U58 EEPROM (24AA025T) for the U57 clock generator. We need to configure the U56 clock generator which uses the U37 EEPROM (M24C64-RDW6TP). SFP+ shares a quad with the HDMI transceivers, and so we must use the HDMI clock generated by U56. The second clock generator does not route to quad 226 where SFP+ is bonded. <== For any future readers, this is the misconception. Clocks can be shared from two quads away.

    "For this guide, we will focus specifically on configuring the second programmable clock source, U57,
    through its associated EEPROM (24AA025T). This EEPROM stores the configuration data that customizes
    the clock generator settings, which are then applied during power-up.
    The 8T49N241 clock generator is a programmable device that supports both single-ended and differential
    outputs. The configuration values for the EEPROM will be generated using the Timing Commander Tool
    from Renesas,"

    So I think to adjust the example from targeting U58 24AA025T to U37 M24C64-RDW6TP. Is that right? So the flow would be:

    1. Change I2C pins from A9/B9 to R22/R23

    2. Use the same IDT commander tool to generate config data

    3. Program the data via microblaze/I2C?

    These EEPROMs are sized differently, and it makes me think the U37 EEPROM has additional data stored in it fro the rest of the HDMI subsystem. Does this example design still apply to the clock generator U56? 

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • iksevas
    0 iksevas 21 days ago in reply to thill

    That eeprom is targeted for hdmi EDID data. I’m not certain if the clock generator can be configured from that device. I certainly haven’t tried it as it’s not a use case for us. 

    Your logic sounds correct, whether it would work is another story. You need to verify structural differences in the memory as well as access differences particularly with reference to the clock generator I2C.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • thill
    0 thill 21 days ago in reply to iksevas

    That is generally the flow we tried but the write failed. Was the SFP+ Module on this board ever tested? How is the clock for this SFP+ port meant to be configured? It shares a quad with HDMI transceivers and only has access to the HDMI rx recovered clock, and the clock generated by U56. Any more detailed guidance on how to verify structural differences in the memory? Will that involve making modifications to how microblaze is writing to I2C?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • iksevas
    0 iksevas 21 days ago in reply to thill

    The SFP port has been tested at full line rates using the clock generator in the reference design. Not sure why you think you can’t use that clock.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • thill
    0 thill 21 days ago in reply to iksevas

    I think I see what I missed, I thought I could only share clocks from one quad away, but it seems you can share clocks 2 quads away if under 16.375 Gb/s. I assume you shared the clock source from quad 224 to quad 226 in your SFP solution?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • iksevas
    +1 iksevas 21 days ago in reply to thill

    Yes

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Reject Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube