Lramseyer

I think the article understates how big of a deal this is. It mentions a lot about the implications from the perspective of packaging, but this opens up a whole new world for IO!

Right now, most semiconductor companies who make an SoC for whatever purpose, will often license designs for common things like a DDR controller or a PCIe interface. But in literally every architecture meeting I've ever sat in ever, the senior manager bigwig always asks: "has this design been tested in silicon yet?" And for a very good reason! No one wants to make a chip only to find out that there's a show stopping errata on the new bleeding edge Ethernet controller design. So the architecture team inevitably settles on the current generation IO protocol, which turns into previous generation when the chip is product ready.

But if your IO controller controller is instead on a separate chiplet, that risk of show stopping errata becomes less impactful (at increased the cost of packaging.) The vendor can respin, or you can choose a different vendor all together. It also allows for greater flexibility in vendor selection and SKU offerings, as well as yield improvements. But I think those upsides are a bit more obvious.

Unfortunately, it could make the business of selling IPs like memory and IO controllers that much more cutthroat, since the cost of changing vendors dramatically decreases. But then again maybe not, since a respin would barely (directly) cost the customer any money.

Who says you have to fabricate a RISC-V processor on leading edge TSMC nodes? What about FPGAs? What about older nodes? The whole point of my argument is that when you make the proprietary "industry" knowledge more generally available, more people can contribute to the ecosystem as it removes barriers to entry.

> In the first case anyone with the right skills can do it. In the second you need access to lots of specialist tools / proprietary industry knowledge.

In the first case, it used to require specialist tools like the Autodesk suite, and people had to have access to that software to develop the right skills and acquire the industry knowledge.

I don't think RISC-V "winning" is the right way of measuring success. Whether or not it becomes the dominant ISA for everything is irrelevant. It serves an important role in our market and it doesn't need the guys at Qualcomm and Intel to use it to make it successful. Either way Intel is investing big money into RISC-V: https://www.zdnet.com/article/intel-invests-in-open-source-r...

Also, careful what you say about high schoolers: https://riscv.org/blog/2020/11/13-year-old-nicholas-sharkey-...

The year is 2012. Blender is an open source 3D modeling and CG software. There are hundreds of crummy plugins and hacks (and a handful of good ones,) whereas Maya is battle tested, developed by professional Autodesk engineers. It comes with good documentation and support. Blender documentation and tutorials were essentially youtube videos with cheesy electronic music in the background. (I'm probably getting some details wrong, but you get the point.)

You're not wrong in your assessment. However you're looking at it as it is right now, as opposed to where it's headed for in the future and what it could ultimately become. While CG and computer hardware are very different fields, the effects of communal knowledge sharing are very similar and very powerful. When bored high schoolers and broke college kids (and curious adults) can tinker with the tech, they enter the industry with that much more experience and/or have another avenue for career transition. And that is far more valuable than the mild (and sometimes nonexistent) conveniences of ARM over RISC-V.

Maybe this is a bit of a ridiculous idea, but what about natively supporting tabs in a window manager? While it would probably be impractical to force all applications to support tabs, it would be nice to be able to rearrange elements/windows of work/productivity apps as such.

What is it good for, or what is it used for? I think Tcl's biggest downfall is the fact that it suffers from Excel syndrome in that It works well for a small set of problems and OK for a bigger set of tangential problems.

Tcl is Tool Command Language, and it's pretty good at routing commands to all of your JTAG, GPIB, Serial port, and whatnot devices. It has a REPL that is easy to use, and sits in the same runtime as all of your code. You can kind of think of it as a shell terminal for your devices. It's also apparently pretty compact all things considered. But it's typing is about as strong as wet toilet paper, which is cool when you have commands to send, receive, and parse out. But since it's also a programming language, you get into situations where someone writes all of the code to communicate with all of the devices in a nice little mini-library for everyone else to use. Since Tcl is a programming language, everyone is expected to develop all of the test and debug code in TCL.

For some projects, we'll prototype a feature in Tcl, but the firmware implementation will be way simpler and more concise. That's mostly because doing anything with an array, or any type of math function requires a mess of syntax. The quintessential example would be incrementing a value in an array. In C, it would look like:

myArray[i]++;

But in Tcl, it goes a little something like this:

lset myArray $i [expr [lindex $myArray $i] + 1]

Now imagine doing things with descriptive variable names and it gets pretty messy.

The way your previous comment was worded implied a level of attempt to justify the presentation style as opposed to being worded like: "their argument is [It's B2B...]." And while it's admittedly such a minor nitpick on an internet comment made by somebody I probably don't know, I bring it up because I also work in hardware, and your argument (or quote thereof) echoes of of managers throughout the industry that justify half baked EDA tools, arcane software, disjointed workflows, and visual design akin to drawing with crayons. These things make me want to pull my hair out. We're trying to make chips on bleeding edge lithography processes, yet we're banging rocks together like cavemen when it comes to software, and for no good reason either!

And to be clear, I am not trying to justify the response you got, I am simply trying to point out the level of frustration that some engineers in the industry (like myself, and a lot of people on HN) have with our workflows. Especially when we see all of these exciting new tools on HN!

That's because you have to pay an extra licensing fee for clear and concise visual design. Besides, that would add complexity - imagine if there was something that needed to be changed after the article was published! /s

> It's not really that either because PCIe 2.0 was "5GT/s" despite being only 4 gigabits per second.

Sort of, depends on where you're measuring. PCIe 2.0 runs at 5GT/s, which is the speed that the Phy layer runs at, but it uses an 8b/10b encoding, so the Data Link layer sees that 4GB/s. For Gen 3.0 and 4.0 (and I think 5.0) the Phy layer uses a 128b/130b encoding, which has much less overhead. So technically it's about 63Gb/s but we round up. But that's kind of a useless measurement because there's additional overhead from Acks/Nacks on the Data Link Layer and TLP headers on the transaction layer (which depends on the size of your TLPs, and whether or not you're using infinite credits.)

edit: I'm not sure which encoding the Phy layer on PCIe Gen 6.0 uses, since it's PAM4. The (approximately) 63 GB/s on the data link layer assumes 128b/130b encoding

> What makes you say that? The chart says x16.

Maybe that metric includes both directions. Either way, it's misleading, as you only get 128 MB/s (before protocol overhead) on PCIe 6.0 x16. (64Gb * 16 lanes) / 8 bits per byte = 128 MB/s

The term gigatransfers per second is essentially Gb/s, so 2 bits x 32 billion per second is 64 billion per second. This is done using PAM4, which stands for Pulse Amplitude Modulation, and 4 is the number of valid voltage levels. Normally we use what's called NRZ or Non Return to Zero, where there are only two voltage levels: 0 and 1.

The did pull something cheeky though - the 256 GB/s is for a PCIe x32 connection. It exists in the spec, but I've literally never seen it in the wild.

Not a stupid question at all!

Any communication protocol has functional layers to them, and at the very bottom is what's called the Phy layer (or physical layer.) While pretty much every layer can be implemented in digital logic, the physical layer has a lot of analog circuitry. (It's programmable analog circuitry, so it's technically mixed signal.) Most wired communication protocols that you are familiar with (including SAS/SATA, USB, HDMI/DP, PCIe/NVMe, and Ethernet) all use what's known as a "SerDes Phy" which is short for Serializer Deserializer. It takes parallel data in, and serializes it to transmit data, and does the reverse when receiving data. In the example of PCIe Gen 4, it takes 32 bits of data in at 500 Mb/s (per bit) and serializes it to 16 Gb/s.

Because the SerDes Phy is such a common part of all communication protocols, it's often reused in other designs. For example - a GPU may use the same SerDes Phy design for its PCIe lanes as it does for its HDMI ports (at least on the transmit side.) They are however programmed differently.

Because these designs see so much reuse in so many different chips, there are companies that specialize in designing SerDes Phys, and their development is usually ahead of protocol development. Though in today's day and age, it's super complicated, and consists of way more than shift registers and a PLL. But there are SerDes designs that exist in products that are capable of 112Gb/s (not sure if 224Gb/s exists outside of test chips yet.)

You can buy modern FPGAs that have PCIe Gen 5, but with a SerDes Phy capable of going way faster. And if you want, you could bypass that hard block and talk straight to the SerDes, and program your own PCIe 6.0 controller.

But to answer your question on how they prototype it and test it, they run computer simulations that are exceedingly complicated and slow, and once a test chip comes back from the fab, eye diagrams are usually collected using what's known as a repeating signal scope. Since it's insanely difficult to sample a 112Gb/s signal at any reasonable resolution, it's sampled statistically (in time) over billions of samples, and plotted by knowing the frequency of the target signal. An eye diagram is what comes out of a traditional NRZ (non return to zero) where each cycle represents either a 1 or a 0. In an eye diagram, you see all permutations of bit transitions overlayed on each other, since you're sampling billions of cycles statistically. This is important because you can see other anomalies of your signal like jitter and rise/fall times.

There's a lot more to it, and this comment is already getting to be a wall of text but definitely feel free to ask more questions!

> Why stop at 5.25in drives? Let's go back to washing machine sized units or even bigger. Let's stack platters so dense and heavy that we can use the spindle as a flywheel UPS system too.

Current HDD tracks are around 50-60nm wide, and their limitation is not magnetic grain density (those are around 10-12nm for non-HAMR/MAMR substrates and even smaller for HAMR/MAMR substrates.) The limitation is the long (relatively speaking) actuator arm trying to precisely stay on a very narrow data track. There's actuator flexure, disk flutter, and aerodynamic noise, all of which increase with increasing platter radius. This increases your minimum track width, and minimum disk thickness/minimum disk spacing and end up defeating the purpose of bigger disks in the first place.

Also it's important to keep in mind that in order to manufacture a drive, the entire drive is written to and read back multiple times, which takes an increasingly long time, creating a huge push for some steps to be combined.

That all being said, I'm not entirely sure where the sweet spot in terms of data density per unit volume. It might be slightly more efficient with 5.25 drives. But I can assure you that the record sized or washing machine sized HDDs of olden days are not practical anymore ...though they would be dope if they did exist!

You're not wrong, but it's important to keep in mind that for more complicated FPGAs, they have hard IP blocks in them often supplied by other companies. Also consider that when these IPs have errata in them, they can sometimes be worked around with FPGA soft logic. Oh, and parts of the software are supplied by companies like Synopsys.

As far as I am concerned though, Synopsys is essentially Autodesk, and Blender is taking over!

I would agree with you in the case of a mass market design where you're competing with a major CPU player. And while that gets the most attention in the tech media, it's actually a somewhat small portion of the market. it's important to keep in mind that a large portion of the semiconductor (VLSI, digital design) market is chips that perform auxiliary tasks. Things like networking equipment controllers, Storage device controllers, and connectivity device controllers like Bluetooth, USB, and whatnot. Those designs all have CPUs in them, but performance is not as critical as something like a Ryzen CPU or an i7. Unit volumes can be lower for these chips as well, and there is definitely a lot of value to be gained by a lowered development costs, which this aims to do.

While I'm not claiming that this is a perfect implementation, the VLSI design world is definitely ripe for newer, higher level, and more open source design languages and tools. There will always be performance critical designs that lower level languages will be useful for, similarly how there will always be performance critical code that will be written in C/C++ and assembly.

And yes, I'm aware of most of the alternative HDLs, and open source EDA tools out there, and I have varying opinions about them. I understand the limitations of building hardware and why we do things the way we do. But I think it's incredibly naive to think that we can't apply more mindsets from software engineering to hardware engineering. We just happen to be in a market where good hardware engineers can get paid more as a software engineer. I call this out because I get the push back from so many people in my industry, and they sound like (what I would imagine) Autodesk developers sound like when Blender gets brought up in a conversation.

I'm familiar with Daisy, however that's for recycling iPhones. Not repairing laptops. It's totally different.

Your claims about independent repair shops may apply to franchises like ubreaxifix, with bottom of the barrel pay to their technicians, but there are also many high quality independent repair shops like iPad Rehab and Rossmann Repair (both who have youtube channels outlining their repairs.) Who are very good at what they do. Also, some of their technicians are readers of HN.

> these very advanced tools are primarily used for building wealth > If you aren't making enough to replace your equipment when necessary, the problem isn't the design of the laptop. It's your failing to earn

By that logic, the target market for Apple laptops are for business use only (Apple's marketing says otherwise.) It's a set of product lines that are marketed towards college students, business elites, and casual users alike. Not all of those groups of people use their laptop for immediate wealth generation, or can afford expensive apple repairs. Which of these demographics do you think is a bigger market? By your logic, Framework has a very compelling product aimed at a large target market.

> ...to save $50 is totally insane. It's a waste of your valuable finite time and energy

Try adding a zero to the savings. Seriously, Apple repairs are expensive. and even more so if you're purchasing a new laptop like you claim to. Besides, if you actually believe all that you're saying about valuable time and energy, what takes more time and energy? Purchasing a new macbook, restoring your cloud backups, and all your applications, as well as checking that everything was properly restored, or spending a few minutes replacing a defective part in a modular, user serviceable laptop? If your argument is time savings here, its significantly faster to upgrade/replace parts than it is for me to upgrade/replace devices.

This future of automated repair and recycling that you speak of is not the current reality, and as somebody who works in hardware, I would be very interested in learning more about this emerging technology of automated repair that you speak up. Though I would challenge that claim with this question: if automated repair is in the near future, why does Apple charge on average three times more than what an independent repair shop charges for fixing logic board issues on a Macbook while still not recovering your data?

While I don't disagree with the idea that we're in an era of disposable electronics, that still currently comes at a high monetary cost that a significant portion of the population would prefer to not have to spend. As a result, it creates a strong market demand for human repair technicians. Though I would argue that the market force that's more likely to put human repair technicians out of jobs are products that are easily repairable (like the framework laptop.) Not some automated repair technology that will arrive to the market around the same time as flying cars.

The claim that "if a device is repairable, it will be big and clunky" is simply corporate propaganda. While the Macbook has some great design aspects to it, it's not without it's flaws. The NAND is soldered onto the board, such that if you have an issue with the motherboard (including a broken charge port) you will need to get it replaced by Apple for a hefty sum of money (think $800-$1200, which most people can't afford unexpectedly.) On top of that, you will lose all of your data. Then there's the butterfly keyboards, which were a reliability nightmare for Apple. If the keyboard were modular and replacable it probably wouldn't have erupted into a massive class action lawsuit. In my opinion, the flat top keycaps that were introduced in the 2009 Pros never felt right to me, and the touchbar was more of a party trick than anything.

I am not claiming that the framework laptop is perfect, but it sure is a compelling product on it's own, and for a lot of the same reasons a Macbook Pro is.

Indeed there is, and you would be correct in that assumption! Take a look at CXL. It's currently optimized for NVMe, Ethernet, or co-processors (GPUs.) It uses the PCIe Gen 5.0 physical layer (but then again most SerDes IPs are general purpose and go into all different types of controllers.) It's essentially an alternate protocol that is negotiated in PCIe link up.

What's nice is that it still keeps everything good about PCIe - like the electrical and mechanical spec, but does away with the old legacy things that nobody likes about PCIe. However, I'm not super familiar with CXL, so maybe it just looks nice from far away.

> UBI only works when it's 1) Universal (even to rich people) and 2) When it's funded by dismantling some/all of the existing welfare state.

This is key. To go even further (at the risk of being a little political) The best way I heard UBI described (by economically conservative individuals in support of it) was that it was simply a readjustment of tax brackets so that lower incomes end up paying a negative tax [receiving money]. While not perfectly mathematically correct, it's an analogy. And it's important to keep that analogy in mind, because if UBI were to hypothetically be implemented in the US, it would simply be withheld accordingly by the employer as income taxes in higher paying jobs where such taxes would cancel out UBI money.

I have found that my friends who are unfamiliar with UBI tend to respond better to the idea of "_negative taxes_ for lower income earners" than "Universal [welfare]/Basic Income"

To be clear, I'm not trying to advocate for or against UBI, I'm simply trying to explain the idea from a different perspective.

> the latency when typing drove me fucking NUTS!

I had the exact same experience.

Back at my old company, all of our development was done on a secure Sungrid server farm that could only be accessed from the VDI environment. The way my coworker initially showed me how to do it, the terminal was sent to an X session on the VDI, and yet everyone at the company was OK with this. I explained how typing is something that you do tens to hundreds of thousands of times per day, and that a few frames of latency every single key press really fatigues you mentally. The sungrid farm didn't support SSH (for load balancing purposes,) so I eventually had to deepdive into the spec for how to access via terminal, and wrote a script.

But that's not the worst part as I was interviewing around at other companies, I asked them how their computing is done, and you wouldn't believe how many companies have their development environment set up this exact way! These are all major semiconductor companies in Silicon Valley too, not some "IT as an afterthought" industry!

It's refreshing to see that VDIs are about as popular with developers on HN as Google Stadia is with hardcore gamers.

I'm surprised that nobody's mentioned it here, but this crypto boom has sent demand for mining hardware through the roof, which has contributed in no small part to the chip shortage. Miners are buying up ASICs, GPUs and FPGAs at a premium.

In the short term, crashing the crypto market can ease demand for semiconductors, but in the long term, getting cryptos to move to Proof of Steak will hopefully ease it up for good (But don't quote me on that!)

It's no secret that one of their biggest supply chain constraints is chips right now (aside from batteries.) So it's not all that ridiculous to imagine them pulling this kind of publicity stunt off so that they can actually produce and sell more cars. And if they can profit off of it at the end of the day, even better!

While my experience is mainly in digital hardware, my tinfoil hat theory as to why the hardware startup scene is so lackluster is because the EDA tools are expensive hot garbage. Not only are the dev tools cost prohibitive, but so are the necessary analog components like PLLs and PHYs (which are more or less required in pretty much every modern VLSI design.)

The same companies that make the EDA tools also make IP blocks that semiconductor companies purchase, so it's in their best interest to prevent an open source hardware scene from thriving. I get that making masks for a chip is expensive for a startup. But if the design, verification, and layout steps were cheaper and more streamlined, I would bet money that the fab costs would work their way down in clever and creative ways.

One issue with the hyperloop that nobody seems to talk about is safety. How do you handle ruptures in the tube? How do you evacuate? and What do you do if your pod loses pressure? This isn't like a 737 where you can give people oxygen while you drop to 10,000 feet when you lose pressure. That only works because at 35,000 ft the pressure is still high enough that you can breathe a higher concentration of oxygen for a short period of time, and not get hypoxia or decompression sickness.

Sure, you can add safety re-pressurization valves and escape hatches, but all of those seals are points of failure that need to be inspected and maintained across the entire length of the tube.

I'm glad somebody pointed this out! Meta materials and diffractive structures are not known for being low dispersion. This article mentions nothing about bandwidth. However, I think the writer assumes that the indented reader knows this already.

Also in the video you can see spatial ringing, which is highly indicative of coherent light (single wavelength, like in a laser.)

This is still a cool discovery and could definitely have a lot of important applications, but it's important to clarify what this is, and what it isn't.

The challenge of doing that, is that there are apparently a lot of proprietary IP blocks (both analog and digital) that are in the FPGA (like the Viterbi decoder as the parent comment suggests) that would need to be redesigned before you could tape it out into your own chip.

I am not sure what other IP blocks are being used in these FPGAs, but a viterbi decoder can be pretty area and power heavy (relatively speaking.) I'm not sure if you would be able to get enough performance [speed] with modern WiFi protocols by implementing it in normal FPGA fabric hence why those blocks are woven into the FPGA.

All that said, this is still a very good thing, because it marks a step forward towards a more open source hardware ecosystem.

> I think a lot of people at HN just hate IBM for no real reason

I disagree. From a marketing perspective, they are a company that is known to over promise and under deliver. Their marketing is vague pie in the sky without much to show for in the market. Watch this IBM ad and tell me what is it that this company actually does:

https://www.youtube.com/watch?v=gsEwmumEsKU

They are a company that fails to innovate, and fails to be relevant, yet they put a ridiculous amount of effort to try to convince people otherwise.

From a business strategy perspective, IBM has spun off or sold off most of their great product lines and business units. Some of which were failing under IBM leadership, and became profitable once divested. Every company they acquire, they seem to dissolve after a few years.

From an internal culture perspective, they are known for laying off their talented experienced employees who have been with the company for over 20 years in favor of younger, cheaper employees. In some departments, they have resorted to simply not promoting people and let people to leave on their own accord.

That being said, most of my experience in working with IBM has been while they were under CEO Ginni Rometty who led from 2012 to 2020. This was one of the biggest bull runs in history, yet the stock went from about $205 per share down to about $120 per share. They have a new CEO now, so things might change.

I would argue that the fact that Apple and Google are working together to develop a contact tracing protocol goes to show the general level of dissatisfaction with the way contact tracing is done in other parts of the world and the privacy implications.

It's important to keep in mind that not all surveillance technologies and methodologies are created equal. The reason that the Apple/Google contact tracing technology has received so much praise is because it's more or less decentralized and all of the data is cryptographically anonymized. Any data that could be associated an individual changes periodically, so it's borderline impossible to track someone with it. There is no central database aside from the list of ID's that are marked sick. There is no location data associated either. In fact, it's blocked by the OS.

You might be surprised. Pretty much all of the pre silicon work at the semi companies I have worked at (besides maybe emulation) is done “remotely” from a server farm to begin with. Even with post silicon work, with careful lab set up, you can do a surprising amount of work remotely, or with minimal lab time.

But you’re right, the light at San Tomas and Walsh is a pain.

If I am reading the data correctly, considering total number of cases, and current rates of growth, the Bay Area is doing really well compared to the rest of the USA in terms of preventing the spread. [1] There will inevitably be areas that will recover sooner than others, and I could see the Bay Area being one of those places. How is the Bay Area going to handle that? Are these places going to station cops on county lines and screen people wanting to come into a "recovered" region?

[1] https://www.latimes.com/projects/california-coronavirus-case...

Not only that, but the sheer complacency of people within the industry when it comes to better tools blows my mind!

Our VDI development environment runs an OS from 2 decades ago. It's ugly and the latency is mildly infuriating. And yet, my co-workers are totally OK with it all.

I was always torn about the implications of Vaporflys. I can respect the fact that they skew the competition, but how is this any different than cycling? Pay a ton of money to reduce drag coefficient, moment of angular inertia, and weight to maximize energy return. The article even points out similarities in midsole thickness, ZoomX foam, and the Carbon fiber plate with other previous shoes that were completely legal with the IAAF. I love my Vaporflys and I run noticeably faster in them, but I think the most underrated thing about them is that they're way softer on the joints, and greatly improve running stability. They have the potential to make running safer and more accessible. Personally, I'd rather see more people maintaining and improving their fitness than some legacy goal post.

The dealer purchased the car from Tesla at an auction according to Jalopnik, and as another commenter pointed out, the feature is documented on the Monroney sticker. It doesn't matter whether or not the first owner paid for the features or not. The car was re-purchased from Tesla (even though it was the dealer buying at an auction.) Tesla advertised that feature to the customer [the dealership], and it's value took the feature in to account.

Whether the original owner paid for the feature or not is irrelevant. The dealership paid for the feature, and it's on the Monroney sticker. Tesla can either honor the claims of the Monroney sticker, or face the consequences.