Jack.MeterEye
Posts: 5
Joined: Wed Sep 26, 2018 2:08 am

LAN9514

Wed Sep 26, 2018 2:49 am

Hi guys,

I have a Raspberry Pi 3 Model B V1.2 which is running fine. I find that some pin connections of LAN9514 on this board are different from the reference design document of the chip:

On Raspberry Pi board: pin 40, 29, 30,32 are connected to ground(see attached photo for Raspberry Pi board)
On LAN9514 reference design: these pins are connected to +3.3V ( http://ww1.microchip.com/downloads/en/D ... 14_sch.pdf )


Which one should I follow to layout my PCB? Thank you.
Attachments
LAN9514.jpg
LAN9514.jpg (197.8 KiB) Viewed 1160 times

W. H. Heydt
Posts: 9061
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: LAN9514

Wed Sep 26, 2018 4:02 am

What are you actually planning to do?

Jack.MeterEye
Posts: 5
Joined: Wed Sep 26, 2018 2:08 am

Re: LAN9514

Wed Sep 26, 2018 4:09 am

I'm going to build a board to run Raspberry Pi computer module 3 on my board.

hippy
Posts: 3898
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: LAN9514

Wed Sep 26, 2018 9:28 am

Jack.MeterEye wrote:
Wed Sep 26, 2018 2:49 am
On Raspberry Pi board: pin 40, 29, 30,32 are connected to ground(see attached photo for Raspberry Pi board)
On LAN9514 reference design: these pins are connected to +3.3V ( http://ww1.microchip.com/downloads/en/D ... 14_sch.pdf )

Which one should I follow to layout my PCB? Thank you.
40 = TEST3
29 = JTAG TMS
30 = JTAG TDI
32 = JTAG TDC

On the Pi B schematic TEST3 of its LAN9512 is connected to 3V3 and the JTAG pins are brought out to a connector.

There is no published Pi 3B schematic which shows the LN9514 connections.

According to the Microchip and SMSC 9514 datasheets I have, TEST3 is "Used for factory testing, this pin must be connected to VDD3V3IO for proper operation" -

http://ww1.microchip.com/downloads/en/d ... 02306a.pdf

I would double-check your reverse engineering effort is correct, and perhaps figure out what the other TEST pins connect to. Maybe it's a design error, maybe it doesn't actually matter, or maybe the RPT know something that Microchip haven't publicly disclosed.

As you are building your own circuit, then perhaps the best option is to try both combinations during prototyping.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20741
Joined: Sat Jul 30, 2011 7:41 pm

Re: LAN9514

Wed Sep 26, 2018 9:43 am

We are just looking in to this. Will get back when the results are in!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

wj_12
Posts: 15
Joined: Mon Jul 30, 2018 8:30 am

Re: LAN9514

Wed Sep 26, 2018 9:56 am

I have found following Microchips' reference design to work well for me. I have a custom carrier board for the CM3L and the LAN9514 now works well. I had some issues (all of which turned out to be my doing! see my posts for details)

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1331
Joined: Sat Sep 10, 2011 11:43 am

Re: LAN9514

Wed Sep 26, 2018 9:57 am

The reason we have this different setup is due to undocumented changes to reduce power consumption of the 9514 device. I'm sorry but we can't release the documentation to you on this. I would suggest you just wire it up like the app note and ignore the way the Raspberry Pi is wired.

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

hippy
Posts: 3898
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: LAN9514

Wed Sep 26, 2018 10:43 am

gsh wrote:
Wed Sep 26, 2018 9:57 am
The reason we have this different setup is due to undocumented changes to reduce power consumption of the 9514 device. I'm sorry but we can't release the documentation to you on this.
That's fair enough but I do hate it when chip manufacturers provide selected customers with information which they don't or won't disclose publicly or to all customers. That gives those selected customers an unfair advantage over the others, creates an uneven playing field, and seems deliberately intended to do that

I would consider that to be an antitrust issue and anti-competitive behaviour which is probably why they put non-disclosure agreements on those they do tell because they know that as well.

I can't really blame the RPT for using information not documented, published or disclosed to others to their advantage but it is all rather unethical in my opinion. Once one sees getting an unfair advantage as acceptable the implication is that being given an unfair disadvantage is also acceptable as well.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1331
Joined: Sat Sep 10, 2011 11:43 am

Re: LAN9514

Wed Sep 26, 2018 10:54 am

No, the undocumented features are actually test modes of the device. It is completely normal not to document test modes. We just came up with an idea of how to use one of their test modes.
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

hippy
Posts: 3898
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: LAN9514

Wed Sep 26, 2018 11:51 am

That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20741
Joined: Sat Jul 30, 2011 7:41 pm

Re: LAN9514

Wed Sep 26, 2018 12:23 pm

hippy wrote:
Wed Sep 26, 2018 11:51 am
That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.
Standard industry practice. Different customers get different levels of support. Some might get bells and whistles, others might have to use them as standard. Poeple who buy the chip get exactly what they paid for. It's described in the datasheet.

Want something better? Pay more.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1331
Joined: Sat Sep 10, 2011 11:43 am

Re: LAN9514

Wed Sep 26, 2018 12:38 pm

The great thing about a competitive landscape for components like this is that you get to vote with your feet. There are many other devices available to you. The idea we had was 'our idea' - we asked them whether it was possible - they gave us a method for implementing it

This isn't a case of them giving us a special handshake document that isn't available to you, it's a case of us having an idea and asking whether it would be possible. If you have the same idea I'm sure they'll give you the same information.

We do not know what the test modes are, they didn't tell us...
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

aBUGSworstnightmare
Posts: 1074
Joined: Tue Jun 30, 2015 1:35 pm

Re: LAN9514

Wed Sep 26, 2018 8:47 pm

hippy wrote:
Wed Sep 26, 2018 11:51 am
That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.
and maybe have a different business case.
Those with access to special documentation are usally required to sign an NDA. Manufactures need to keep their IP secret, it's not everything public domain info (although many people think as such)

John Westlake
Posts: 84
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514

Wed Sep 26, 2018 9:55 pm

The “undocumented mode of operation” is related to reducing the total power consumption and heat dissipation of the LAN9514 – but at the potential expense of performance.

Essentially, the LAN9514 internal 3.3V to 1.8V LDO’s that power the USB PLL, LAN PLL circuits and Cores are externally powered from the Pi’s 1.8V switching regulator – thereby reducing the thermal dissipation of the LAN9514 (its internal linear LDO's are disabled) and therefor making for a more power efficient design.

There are two negatives to this mode of “external 1.8V” operation:-

1. The Clock Jitter performance of the LAN9514 PLL is effected by the external noise of the 1.8V switching regulator – this noise is heavily correlated by the Data being processed by the memory / CPU – if the jitter spectrum of your USB output is important (such as for Audio systems) then its better to power the LAN9514 PLL’s etc from either the internal LDO’s (and live with the resultant increased thermal dissipation of these internal LDO’s – the LAN 9514 does indeed run hot, so make sure you use correct PCB thermal design (Take care with the PCB vias around the LAN9514 Thermal Pad)) – and use a low Phase noise 25MHz clock (do not use the 25MHz Clock generated by the CM3).

2. You also have to be careful with the power sequencing of the now separated 1.8V and 3.3V supplies to the LAN9514 to prevent latch-up damage or unstable operation of the LAN9514..

The above two points are very design sensitive – most digital designers struggle with “Analogue” characteristics of a system, so as Microchip has only limited field support engineers it has to avoid introducing “Edge design cases” – its needs a design that works with little skill – hence not mentioning some of the more silent modes of operation (That requires in-depth understanding, and worst which by getting wrong would just introduce a whole bag of 'Random' hurt)… Microchip does not have the resources to handhold every design….

The other difference are related to the grounding of the JTAG connections and over-current protection pins – but none are really a show stopper, the Microchip App. note works well, but make sure to connect the LAN_Run (Reset) to a CM3 GPIO so the CM3 can Reset the LAN9514 upon any reboot event.

Do take some care with the USB HOST power over-current protection circuits, I’m guessing RPi faced issues with the over-current trip circuits (timing) as they introduced a lets say ‘funky’ delay circuit, which one can only presume is to keep the LAN9514 ‘Happy’ during continued overload events (rapid tripping)…. but that’s just conjecture on my behalf…
Last edited by John Westlake on Mon Oct 01, 2018 8:30 pm, edited 2 times in total.

Jack.MeterEye
Posts: 5
Joined: Wed Sep 26, 2018 2:08 am

Re: LAN9514

Thu Sep 27, 2018 1:45 am

Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20741
Joined: Sat Jul 30, 2011 7:41 pm

Re: LAN9514

Thu Sep 27, 2018 9:55 am

Jack.MeterEye wrote:
Thu Sep 27, 2018 1:45 am
Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.
Just don't use it. Stick to the datasheet. Anything else and you are on your own, both from us and Microchip. It's undocumented for a reason.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

hippy
Posts: 3898
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: LAN9514

Thu Sep 27, 2018 4:33 pm

Jack.MeterEye wrote:
Thu Sep 27, 2018 1:45 am
Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.
The stock foundation supplied firmware with other open source software, including Raspbian, appears to work okay with Pi 3B boards which have the non-datasheet configuration so I would have expected it to work if replicating that same non-datasheet configuration LAN9514 hardware for a CM3.

It would seem unlikely that the firmware were coded to only allow the non-datasheet configuration on an actual Pi 3B board but it is possible. Given that pin naming and connections differ between the BCM2835 on a CM1 and a Pi B, and the camera seems to be handled differently depending on whether a CM or Pi board, you might have to reverse engineer a Pi 3B to fully determine what differs from a CM3 replicating a 3B board and a real Pi 3B board, at least to the extent of all connections to the SoC and LN9514.

Probably the best way to see if the non-datasheet configuration works with a CM3 is, as suggested earlier, try it; develop prototype boards which can be used either way, test and analyse the results.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20741
Joined: Sat Jul 30, 2011 7:41 pm

Re: LAN9514

Thu Sep 27, 2018 8:15 pm

Or just use the chip as intended.....that way you won't blow anything up and it should just work.

I doubt there is much difference between the two options.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

John Westlake
Posts: 84
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514

Fri Sep 28, 2018 3:57 am

Jack.MeterEye wrote:
Thu Sep 27, 2018 1:45 am
Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.
I really cannot recommend using the LAN9514 in this way - its undocumented by Microchip for a reason as I went into some length to explain...

As others have already posted - just use as per the Microchip design application note which works well and is stable - we are nearing 10K units manufactured using the CM3 and I'm not aware of any issues with the LAN9514 following the manufacturers reference design.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20741
Joined: Sat Jul 30, 2011 7:41 pm

Re: LAN9514

Fri Sep 28, 2018 8:59 am

John Westlake wrote:
Fri Sep 28, 2018 3:57 am
Jack.MeterEye wrote:
Thu Sep 27, 2018 1:45 am
Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.
I really cannot recommend using the LAN9514 in this way - its undocumented by Microchip for a reason as I went into some length to explain...

As others have already posted - just use as per the Microchip design application note which works well and is stable - we are nearing 10K units manufactured using the CM3 and I'm not aware of any issues with the LAN9514 following the manufacturers reference design.
#

I cannot upvote this post enough.

Use the reference design.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1331
Joined: Sat Sep 10, 2011 11:43 am

Re: LAN9514

Fri Sep 28, 2018 9:26 am

Also upvote John's post...
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

Jack.MeterEye
Posts: 5
Joined: Wed Sep 26, 2018 2:08 am

Re: LAN9514

Mon Oct 01, 2018 4:31 am

Thanks every body, I think I should build a board to find it out. Here is the board layout(4 layers), I will test it with deferent pin connections, and let you know once I have the testing results.
The crystal is Kyocera CX3225SB25000D0FFFCC (25MHz 10ppm 8pF 50R). Except the pin connection, I follow Microchip's reference design and layout guideline.
Anything do I miss?
Attachments
LAN9514_PIN_SETUP.png
LAN9514_PIN_SETUP.png (179.54 KiB) Viewed 666 times

John Westlake
Posts: 84
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514

Mon Oct 01, 2018 8:33 pm

To improve your Ground "decoupling path" you can simply Ground pins 29, 30 & 32 - this gives you a tight direct Ground connection to the two local PSU decoupling capacitors.

We Ground these pins on our designs....

Jack.MeterEye
Posts: 5
Joined: Wed Sep 26, 2018 2:08 am

Re: LAN9514

Tue Oct 02, 2018 11:59 pm

John Westlake wrote:
Mon Oct 01, 2018 8:33 pm
To improve your Ground "decoupling path" you can simply Ground pins 29, 30 & 32 - this gives you a tight direct Ground connection to the two local PSU decoupling capacitors.

We Ground these pins on our designs....
In this special prototype layout, I make these pins can be easily connected to +3.3V or ground for testing, and I will do what you say if I decide to connect the JTAG pins to ground after test.

what about pin40? do you connect it to ground as well? Thanks.

Return to “Compute Module”