Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

serd.es

Post reply on HN
Print view View original

91–100 of 103 posts

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

#91

Post by azonenberg »

ranma42 wrote: post #78
azonenberg wrote: post #50

Earlier quoted context omitted.

This is why I used a VSC PHY. After they bought Microsemi (and Vitesse as a division of Microsemi) it looked like the only viable option to get a QSGMII PHY since all the other players were much worse. When I first started the project in 2012-13, Vitesse was just as NDA-happy and I ruled them out. The original roadmap called for a 24-port switch with 24 individual TI DP83867 SGMII PHYs on three 8-port line cards.

BTW looking at the 8051 patch bytes, they look like 8051 code to me. 0x02 is the ljmp opcode, so this is a jump table: 0x02, 0x40, 0x58, 0x02, 0x40, 0x4e, 0x02, 0x44, 0x00, 0x02, 0x42, 0x2b, 0x02, 0x41, 0x82 I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest:…

Those addresses all make sense, as 0x4000 - 4fff appears to be where the 8051 has its RAM mapped (all of the peek/poke addresses used for accessing serdes fields are on the high end)

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

#92

Post by Kirby64 »

Dylan16807 wrote: post #90
Kirby64 wrote: post #89

Earlier quoted context omitted.

> Are you saying that releasing documentation is going to increase the number of support questions? Yes, absolutely. Notoriously, smaller customers are more needy in fact. The bigger the customer, the more competent their engineers tend to be (or, the more time they have to spend figuring out how to use your stuff). Smaller customers try to offload support onto vendors, which pushes burden onto internal vendor teams…

Smaller customers are more needy, sure, but there's a couple steps missing here. Is better public documentation going to bring in a lot more small customers, more than it solves problems? Is an NDA by itself keeping away lots of small customers?

> Is better public documentation going to bring in a lot more small customers, more than it solves problems?

Maybe. The other thing is that public documentation gets a lot more scrutiny than internal documentation. You don't have any resource to talk to, so something like typos or mistakes need to be corrected rather than just papered over by a helpful applications engineer.

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

#93

Post by bgnn »

ants_everywhere wrote: post #32
ACCount36 wrote: post #26

Earlier quoted context omitted.

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

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.

I don't know what's it like to work with their chips, but I worked at one of them designing chips. There is often a block designed by someone 10 years ago but left the company, it has bugs, but nobody dares to touch it and fix it because "we knyiw ots bugs" and nobody really knows what's happening under the hood. So someone writes a wrapper for the next gen, to add new features. This person soon leaves the company.. rinse and repeat. I've seen wrapper of a wrapper of a wrapper on 10th gen of a product in 5nm process of a product line started its life when 90nm was state of the art. Most of the the bugs accumulated over the years were still there. They won't fix it as long as a big customer doesn't complain about it.

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

#94

Post by bgnn »

traverseda wrote: post #35
ACCount36 wrote: post #24

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.

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

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.

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

#95

Post by ants_everywhere »

sumtechguy wrote: post #69
ants_everywhere wrote: post #32

Earlier quoted context omitted.

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.

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 verti…

that's a bit depressing :(

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

#96

Post by ants_everywhere »

bgnn wrote: post #93
ants_everywhere wrote: post #32

Earlier quoted context omitted.

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.

I don't know what's it like to work with their chips, but I worked at one of them designing chips. There is often a block designed by someone 10 years ago but left the company, it has bugs, but nobody dares to touch it and fix it because "we knyiw ots bugs" and nobody really knows what's happening under the hood. So someone writes a wrapper for the next gen, to add new features. This person soon leaves the company..…

oh wow. do they at least keep a list of known bugs centrally? or do they just hope nobody notices?

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

#97

Post by lmz »

Tuna-Fish wrote: post #45
rkangel wrote: post #38

Earlier quoted context omitted.

If they distribute the one with optimisations, then they need to make the source available.

... but only to the ones they distribute it to. They can then choose to redistribute it if they want to.

... a.k.a. the RHEL model (with contract termination on sharing source).

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

#98

Post by Taniwha »

stephen_g wrote: post #44
Taniwha wrote: post #7

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

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…

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

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

#99

Post by GeneralSyb »

junon wrote: post #25
ACCount36 wrote: post #24

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.

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 tooli…

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?

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

#100

Post by MrBuddyCasino »

thyristan wrote: post #46
rbanffy wrote: post #20

Earlier quoted context omitted.

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.

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, a…

Digital audio distribution over Ethernet for a stadium PA is definitely hard realtime. Glitches are very noticeable, unlike video.
Post reply on HN