What Microchip doesn't (officially) tell you about the VSC8512

https://serd.es/2025/07/04/Switch-project-pt3.html

by ahlCVA • 1 year ago

168 100 1 year ago

anitil• 1 year ago

I'm really enjoying this series, and this one is a good example of how working with hardware can be really difficult as manufacturers aren't always fully open (or honest) about device's capabilities. But typically you don't find that out until you're already a long way through bring-up.

This was an impressive amount of research to get what he wanted out of the device!

Xss3• 1 year ago

The same is common in software. A real nightmare for me was a client insisting their entire library was single threaded only to discover one small but aspect wasn't deep into development and debugging. Had to refactor a huge chunk of the project.

kragen• 1 year ago

This is amazing.

Oh, no wonder this is so comprehensive and fearless. It's Andrew Zonenberg.

RainyDayTmrw• 1 year ago

In perhaps a feat of nominative determinism, both the website and the feature are named serdes.

kmeisthax• 1 year ago

SERDES is an acronym, it means serializer / deserializer, in the same way that MODEM is modulator / demodulator.

Taniwha2• 1 year ago

This has generally been my experience of PHYs in general, lots of twisty passages all different

stephen_g4• 1 year ago

It doesn’t help that this is a Vitesse Semiconductor part that became a MicroSemi part that became a Microchip part through a bunch of mergers and acquisitions…

Taniwha2• 1 year ago

of course eventually everything becomes a Broadcom chip ....

userbinator• 1 year ago

Microchip seems to be reasonably good at opening stuff up that it's bought from other companies; various Atmel security ICs which were previously very secretive now have full datasheets freely downloadable from their site.

azonenberg7• 1 year ago

Yes, Vitesse had been on my "naughty list" of companies that were permanently banned from getting a design win from me because of refusing to share any docs or sell parts at distributors or other engineer-hostile practices popular with the likes of Marvell and Broadcom.

After MCHP bought them and opened up (what I thought was) the full datasheet I gave them a second chance. Seems they still held some back.

lttlrck• 1 year ago

Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof.

I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".

badgersnake• 1 year ago

There were still using it for the desktops at IBM when I was there in 2001, although they were starting to phase it out.

wokkel• 1 year ago

What i know from the past is for realtime guarantees ethernet does not cut it. So you might be right.

MrBuddyCasino2• 1 year ago

AFAIK Ethernet is used for realtime audio distribution, so that can't be completely correct.

rwmj• 1 year ago

Off topic, but clabretro did a series on Token Ring if you want to relive the nostalgia: https://www.youtube.com/@clabretro/videos

mannyv• 1 year ago

The ideas behind token ring underlies DOCIS.

While not technically TR, it does use a token that moves from device to device.

It would be interesting to know if TR is better at contention management than broadcast ethernet - which nobody does anymore because everyone uses switches.

eqvinox4• 1 year ago

The ideas behind token ring underlies DOCIS.
While not technically TR, it does use a token that moves from device to device.

I assume you typo'd DOCSIS there, but no, DOCSIS does not use a token; it uses separate channels for down- & uplink, and the uplink channels are TDMA and/or CDMA depending on DOCSIS version.

AceJohnny22• 1 year ago

The chemical factory I did an internship at in 2001 was sticking with Token Ring at the time.

It was eye-opening.

gregfjohnson• 1 year ago

On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s some loophole, since otherwise EFF and folks would be going after them. Or perhaps they don’t know about this situation? Should I alert EFF to this situation

Cerium• 1 year ago

It's been this way forever... They do distribute source (but last time I checked it is with incomplete build info). I think there is also some BS fine print about the licensing fee being for the provided header files.

fragmede• 1 year ago

The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?

znpy• 1 year ago

I think that the issue here is the following:

    - you can charge money for things
    - anything that's not built with the "official compiler" is not "supported"

I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and told me "Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE.

They used ARM chips, so not even anything strange...

The real issue would come if they did not provide the source code for the gcc build they sell you, though.

extraduder_ire• 1 year ago

How much does it look like gcc? Can you run it on its own with a --version argument, or run it through strings to get the text out of it.

If it's actually gcc, a copy of the GPL should have come with the software. A bunch of other compilers mimic a lot of its interface for compatibility’s sake.

stephen_g4• 1 year ago

Yeah I’m really not a fan - we had some designs with PICs on them and ended up switching to NXP micros (MCX-A and i.MX-RT) instead, partly because of MPLAB and also because the Microchip ones had some annoying quirks. NXP’s documentation I find a lot better too. I literally try to avoid Microchip where I can from the experience…

jmiskovic2• 1 year ago

Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns.

I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.

If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.

msgodel• 1 year ago

That's such a weird thing to do. MPLab used to be completely free to encourage people to use their chips.

Tuna-Fish2• 1 year ago

The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.

immibis• 1 year ago

In some jurisdictions you may even be able to sue them for the source code without bothering GNU.

lmz2• 1 year ago

Of course that depends if the optimization was compiled into the version they have. One can imagine two binaries with the optimizations just missing from the free one.

dmitrygr• 1 year ago

Ran into this at Google. Qualcomm compiler for their DSP was an expensive branch of GCC. I asked my manager if we could just ask them for source instead of paying per-seat license. He said that “ our contract with Qualcomm specifically prohibits us from asking them for the source of this compiler”. They found the workaround tor GPL I guess.

howerj• 1 year ago

I have heard that this is how it is done before. I wonder how that works with a third party? If they happened to come across the binaries some how they could demand the source. I also wonder if that clause is enforceable.

TexasMick• 1 year ago

They have the source code on their website: https://www.microchip.com/en-us/tools-resources/archives/mpl...

nemo8551• 1 year ago

I adore this series and other deep dives like it.

If anyone can suggest others I would be grateful.

ACCount363• 1 year ago

The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.

junon4• 1 year ago

Microchip in particular is very bad at developer experience and tooling. The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason.

I've heard good things about Nordic, though. Might try them out at some point.

Microchip's own IDE and project generator spit out a hello world project that didn't even compile. NXP wouldn't even let me download their tooling even after their obfuscated sign up flow.

ACCount363• 1 year ago

True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.

Gracana• 1 year ago

I was on the Microchip bandwagon until the PIC32. Little MIPS MCUs with onboard RAM and graphics, awesome! ...except they came with an errata that listed huge problems with every interesting peripheral, and it didn't improve for ages. They may still suck, I don't know.

A while back I tried out Espressif's esp32 and I was impressed by what they were offering. Their devices seem to be well documented and the esp-idf framework is really pleasant to use. It's much easier to work with than STM32Cube and ST's sprawling documentation.

stephen_g4• 1 year ago

Which NXP tooling did you have trouble with? I’ve downloaded MCUXpresso earlier this week, no NDA or anything (yes you do need an account), it’s never been hard to get…

Aurornis3• 1 year ago

The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason.

ST has good documentation most of the time, but for a while some of their higher end MCUs had a lot of weird bugs and errata that were simply not documented. I haven’t used any of their modern parts recently but I’ve heard the situation has started improving. I have some friends who were ready to abandon ST altogether after losing so much time on a design to undocumented bugs and parts not behaving as documented.

HeyLaughingBoy2• 1 year ago

Good god. I literally just uninstalled MPLAB IDE for a project that we cancelled. It freed up something like 30Gb on my system. I built the existing project once!

I also really like ST. At a previous job our go-to processors were Nordic for wearables or anything that needed BLE, and STM32 for pretty much everything else. Wasn't unusual to have an STM32 for all the peripheral I/O and an nRF52 hanging off an I2C port just to talk to an app.

Nordic is OK. Starting up a new project is nowhere near as easy as STMCubeMX and they do tend to update their SDKs frequently which can be annoying if you have to support legacy projects, but we used them for years with no problems.

tliltocatl• 1 year ago

Nordics are good with documentation and devex indeed. Zephyr is still a bloated and somewhat buggy disaster for this scale of MCUs. Doesn't really beats ST unless you are power-constrained and need wireless connectivity - the hardware is a bit too quirky.

GeneralSyb• 1 year ago

I'm not really an embedded engineer, just getting my degree in EE and doing hobby projects with embedded. For one particular project I've been using a number for different BLE microcontrollers to see what works best. Started out with the ESP32 where I got everything running pretty quickly but the current consumption was about 10x as high as I wanted it to be. Then made a design with an STM32 and at first I liked the IDE and the documentation, but I sort of ran a ground and also disliked how incredibly expensive this particular microcontroller was. Now on my desk I have one which I think is the cheapest BLE microcontrollers from Silicon labs. EFR22BG22CC something. Neat little thing in a QFN-32 package, a simple hardware design and a lot cheaper than the STM32. The IDE seems pretty simple and I think that most of their tooling is open source since there is also an implementation for it in visual studio code. Documentation isn't as great, but I can get by. And also, despite the wide range of microcontrollers they offer, they do seem to be available in large quantities. The one I used mouser had like 350k of and more on the way.

I've yet to see anyone here talk about silicon labs microcontrollers. Why's that?

traverseda• 1 year ago

Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.

dgfitz• 1 year ago

I think the short answer is because manufacturers don’t care.

ACCount363• 1 year ago

Perhaps they think that by forcing everyone to go through the sales dept just to get the basic docs, they'll get better sales opportunities.

How do you upsell a hardware engineer who just wants to buy a specific chip, and already has everything to evaluate and use it? You don't. So you force everyone to go through sales, and then sales wants to talk to non-engineering higher-ups, and then the upsell happens - while the people who actually knew what they wanted remain as far away as possible.

And if you don't have the pockets deep enough for the sales dept to acknowledge your existence, then you might as well not exist.

Aurornis3• 1 year ago

When you get into high volume production, the vendors have their own engineers who will work with you directly. Depending on the arrangement and your volume they might bill you for the time, require you to buy blocks of support hours, or they might bend over backward to help you out in any way possible if you’re buying enough parts from them.

Dealing with small clients is not a priority for most part vendors. Many of them won’t even sell you chips at all until you can qualify yourself as a big customer or, in some cases, buy a license to start designing with their parts for six figures or more.

Unfortunately for the small players, it’s not a priority for most companies to support small customers who might only buy a couple thousand parts or less.

gosub100• 1 year ago

Guessing: if you publish too much about your design, competitors can use it against you during sales negotiations. "Don't buy theirs, ours has better pin placement, better IF, better thermals, etc"

rcxdude2• 1 year ago

There's certainly cases where the documentation basically doesn't exist, or it's essentially the same as the design documentation, and the strategy is basically that if you're a big enough customer then you'll be getting some engineer time to make things work, and if you're a smaller customer you'll be told to pound sand anyway, it's not worth them fixing up their documentation to get your business. Generally the more complex and specialised the hardware the more it'll look like this, and it basically saves them on R&D because they have only a few applications to actually focus on.

Kirby643• 1 year ago

Because creating good documentation suitable for external consumers costs money, and even if you have decent documentation, people buying small quantities of parts can end up costing companies money just to interact with one of their application engineers. If you're not set up for it (very few companies are), it literally is negative value to answer support questions for small time customers.

bgnn3• 1 year ago

Because the margin per chip is low and supporting more customers cost more. They sell these parts for couple of bucks/part at volume, although it costs 20-30 million NRE. With the fixed production costs added, they have tens of cents per part margin. At that point less than 1M part customer becomes irrelevant.

FpUser2• 1 year ago

My last experience with embedded MCUs was few years ago with ATMEL and all was fine

InitialLastName• 1 year ago

Atmel hasn't existed for almost 10 years (Microchip bought them in 2016). The situation has not improved in the intervening time.

bardak• 1 year ago

One of the biggest advantages I saw from the Raspberry Pi rp series for amateurs is they they have great documentation.

0xTJ• 1 year ago

I wish that Microchip would officially publish the programming algorithms and EE bit maps for the Atmel ATF16V8, ATF22V10 SPLDs and ATF15xx CPLDs. They programming algos have been mostly reverse-engineered (or otherwise figured out), but it'd be nice to have those published in the open, and I don't think the ATF15xx maps are completely known.

The ATF15xx have BSDL files released, but that's only for testing/bypass.

hwj• 1 year ago

Texas Instruments has awesome documentation. Every single MSP430 microcontroller comes with:

- a family guide describing all features of microcontroller family, usually >500 pages long

- concrete microcontroller guide describing specifics of a single microcontroller, usually >50 pages long

- errata guide describing all(?) known silicon bugs with their workarounds

Also, Clang has a backend for MSP430 by default: `clang -print-targets`

AceJohnny22• 1 year ago

Sure, but that's irrelevant. The MSP430 is not (in) an Eth PHY.

As the Author demonstrated, the network IC world is very unaproachable.

What Microchip doesn't (officially) tell you about the VSC8512

Related Stories