8 ms·

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

168 points by ahlCVA 1y ago

anitil 1y 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 1y 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 1y ago
This is amazing. Oh, no wonder this is so comprehensive and fearless. It's Andrew Zonenberg.
RainyDayTmrw 1y ago
In perhaps a feat of nominative determinism, both the website and the feature are named serdes.
- kmeisthax 1y ago
  SERDES is an acronym, it means serializer / deserializer, in the same way that MODEM is modulator / demodulator.
userbinator 1y 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.
- azonenberg 1y 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.
Taniwha 1y ago
This has generally been my experience of PHYs in general, lots of twisty passages all different
- stephen_g 1y 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…
  - Taniwha 1y ago
    of course eventually everything becomes a Broadcom chip ....
lttlrck 1y 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 1y 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 1y ago
  What i know from the past is for realtime guarantees ethernet does not cut it. So you might be right.
  - MrBuddyCasino 1y ago
    AFAIK Ethernet is used for realtime audio distribution, so that can't be completely correct.
    - rbanffy 1y ago
      There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.
      - thyristan 1y ago
        The usual terminology is hard, firm and soft realtime. In hard realtime, missing a deadline is a total failure and to be avoided at all cost, i.e. your reactor melts down, you car runs over someone, stuff like that. Firm realtime means that a missed deadline will not be a total catastrophic failure but it will make the result useless. E.g. when your printer control system mistimes the "fire ink now" in the printer, and the ink lands not on the page but somewhere else. Soft realtime means that your result will gradually degrade with missed deadlines, but not be totally useless. Audio is usually soft realtime, sometimes, e.g. when doing studio recordings, firm realtime.
gregfjohnson 1y 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 1y 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 1y ago
  The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?
  - znpy 1y 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.
    - mycatisblack 1y ago
      Offloading the liability for a compiler sounds like common sense to me. How many heads did this company pay? 100, 1000? Related, compiler bugs aren’t uncommon in the arm-none-eabi family. Especially the cortex m0 seems to have a few that recur every few years.
nemo8551 1y ago
I adore this series and other deep dives like it. If anyone can suggest others I would be grateful.
ACCount36 1y 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.
- junon 1y 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.
  - ACCount36 1y ago
    True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.
    - junon 1y ago
      Oh yeah definitely.
    - ants_everywhere 1y ago
      I don't do embedded work, but I see Broadcom and Qualcomm show up a lot in Linux bugs. I'd love to hear stories of what it's like to work with chips from these companies.
      - sumtechguy 1y ago
        When I worked at qcom it took 2 devs 3 managers and 2 directors to get another group to let us fix a single race condition in their code. Once I got a copy of the code I started handing off tons of memory overwrites and underruns back for them to fix and another 10 or so race conditions. Their initial stance was 'there is nothing wrong with the code it is your code that is broken'. That was internal in the same vertical. It would be awful to work as an external group with that lib. Other stacks I got to look into were in similar shape. Some groups if you got their code you knew it was going to be solid and you would learn a thing or two. Others groups you were kind of surprised it compiled.
0xTJ 1y 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.
deleted 1y ago
[deleted]
hwj 1y 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`
- AceJohnny2 1y 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.
Muktar7170 1y ago
[dead]

168 points by ahlCVA 1y 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 1y 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 1y ago

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

RainyDayTmrw 1y ago

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

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

userbinator 1y 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.

azonenberg 1y 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.

Taniwha 1y ago

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

stephen_g 1y 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…
- Taniwha 1y ago
  of course eventually everything becomes a Broadcom chip ....

lttlrck 1y 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 1y 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 1y ago
What i know from the past is for realtime guarantees ethernet does not cut it. So you might be right.
- MrBuddyCasino 1y ago
  AFAIK Ethernet is used for realtime audio distribution, so that can't be completely correct.
  - rbanffy 1y ago
    There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.
    - thyristan 1y ago
      The usual terminology is hard, firm and soft realtime. In hard realtime, missing a deadline is a total failure and to be avoided at all cost, i.e. your reactor melts down, you car runs over someone, stuff like that. Firm realtime means that a missed deadline will not be a total catastrophic failure but it will make the result useless. E.g. when your printer control system mistimes the "fire ink now" in the printer, and the ink lands not on the page but somewhere else. Soft realtime means that your result will gradually degrade with missed deadlines, but not be totally useless. Audio is usually soft realtime, sometimes, e.g. when doing studio recordings, firm realtime.

gregfjohnson 1y 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 1y 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 1y ago
The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?
- znpy 1y 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.
  - mycatisblack 1y ago
    Offloading the liability for a compiler sounds like common sense to me. How many heads did this company pay? 100, 1000? Related, compiler bugs aren’t uncommon in the arm-none-eabi family. Especially the cortex m0 seems to have a few that recur every few years.

nemo8551 1y ago

I adore this series and other deep dives like it. If anyone can suggest others I would be grateful.

ACCount36 1y 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.

junon 1y 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.
- ACCount36 1y ago
  True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.
  - junon 1y ago
    Oh yeah definitely.
  - ants_everywhere 1y ago
    I don't do embedded work, but I see Broadcom and Qualcomm show up a lot in Linux bugs. I'd love to hear stories of what it's like to work with chips from these companies.
    - sumtechguy 1y ago
      When I worked at qcom it took 2 devs 3 managers and 2 directors to get another group to let us fix a single race condition in their code. Once I got a copy of the code I started handing off tons of memory overwrites and underruns back for them to fix and another 10 or so race conditions. Their initial stance was 'there is nothing wrong with the code it is your code that is broken'. That was internal in the same vertical. It would be awful to work as an external group with that lib. Other stacks I got to look into were in similar shape. Some groups if you got their code you knew it was going to be solid and you would learn a thing or two. Others groups you were kind of surprised it compiled.

0xTJ 1y 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.

deleted 1y ago

[deleted]

hwj 1y 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`

AceJohnny2 1y 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.

Muktar7170 1y ago

[dead]