Indiana manipulated report on Amazon worker's death, investigation says - <AUTHOR> https://www.indystar.com/story/news/investigations/2019/11/25/amazon-indiana-governor-eric-holcomb-warehouse-accident-hq-2/4282653002/ <comment><USER2> A really clear case of corruption both at Amazon and within the state labor departments. The fines are so small I'm not sure why Amazon didn't just reject corruption like this and do things right. Really just speaks to a company culture completely lacking any morals.

<comment><USER3> Why would small fines mean they should behave correctly? Small fines make it easy to justify as "cost of doing business". It's the large onerous fines which incentivize them to do it the less-profitable and more-moral way, because the fines cost more than doing it right.

Hate to be cliche, but reminds me of the opening scene in Fight Club where Edward Norton's character describes how insurance adjusters(?) determine if a recall is cheaper than the lawsuits from dead/injured people, they do it, otherwise... they don't.

Why would Amazon behave less profitably? Simply because we perceive it to be more moral?

<comment><USER4> > _Why would Amazon behave less profitably? Simply because we perceive it to > be more moral?_

Yes. Why is this so controversial? Why are we okay with profits being more important than ethics?

<comment><USER5> Corporations reliably do not care about morality more than they do about their bottom line. If you want to push them into behaving ethically, you need tools that work. Finger-wagging doesn't work. Hurting the bottom line might.

<comment><USER6> When I hear this argument the way my head translates it is "we need to create a market for morality" which sounds quite absurd...

<comment><USER5> I tend to look at it from the perspective of "what can we do" more than "what is right". While moral values certainly set the direction we should head in, having strong values achieves no good in the world without practical action.

</comment></comment></comment></comment></comment></comment><comment><USER7> A long, compelling piece by The Atlantic covered this and other Amazon horror stories this month.

[https://www.theatlantic.com/technology/archive/2019/11/amazo...](https://www.theatlantic.com/technology/archive/2019/11/amazon- warehouse-reports-show-worker-injuries/602530/)

<comment><USER8> Additional story: [https://amazonandmykid.com](https://amazonandmykid.com)

( my own )

Suffice it to say Amazon does not care about employees, neither at the warehouses nor at their corporate headquarters.

When I was there a guy jumped off a building because they wouldn't let him switch off a toxic team. They also similarly tried to prevent me from switching teams when I was there.

A week ago I was at one of the Amazon retail stores and an employee there agreed that Amazon cares nothing for their employees. Obviously one should take this with a grain of salt as this is just a random statement from a random retail employee, but this is generally what I hear from Amazon workers both current and ex.

The general word on the street in Seattle is "Amazon sucks" to the extent I've heard Amazon employees referred to as Amholes.

<comment><USER9> > The general word on the street in Seattle is "Amazon sucks"

Just about every dev that it's in the region knows this. It's why their recruiters constantly spam talent in the region. Insane turnover, and you have a very short shelf life due to burnout. It's also why their compensation is mostly in stock. They know you won't last to collect your RSUs.

<comment><USER10> >It's also why their compensation is mostly in stock. They know you won't last to collect your RSUs.

Not only that, the stock doesn't follow a typical vesting period like "4 years, with a one year cliff" but instead is HEAVILY weighted to later years, so that at the end of year one you barely get any of it percentage-wise.

<comment><USER11> This is extremely misleading. A typical package looks something like:

      year 1: $150k cash + $100k bonus + $10k stock
      year 2: $150k cash + $80k bonus + $30k stock
      year 3+4: $150k cash + $110k stock

The bonuses vest linear, daily, so there's no clawback if you leave during the first two years.

Realistically, it means that you only get into stock comp if you've stayed for a few years and have decided that it's where you want to stay. Otherwise, you just get a nice big pile of cash each month.

<comment><USER12> it's misleading for new hires, amazon has to pay them well. but internal growth at amazon is horrible and additional comp is heavily delayed

</comment></comment></comment></comment></comment></comment><comment><USER13> The Indiana Governor disputes the allegation: [https://www.indystar.com/story/news/investigations/2019/11/2...](https://www.indystar.com/story/news/investigations/2019/11/25/indiana- gov-eric-holcomb-disputes-interference-allegations-amazon-death- investigation/4302895002/).

I find it interesting the whistle blower claims the governor attended a meeting where pressure was applied to back off the investigation. The Governor claims he never attended a meeting. Wouldn't this be an easy item to fact check by getting records of meeting attendees?

<comment><USER14> Should be almost irrelevant if the mentioned recording with the director is still around.

Just play that on the evening news every day until Amazon pays full death benefits and punitive fines to the Terry family.

Oh yeah, and arraign the director on criminal conspiracy charges. And the governor too.

<comment><USER15> They played an excerpt on the "Reveal" podcast the other day, so it's probably still around...

<comment><USER14> I heard this morning one of the Reveal team staff interviewing on NPR.

Hope this stays in the news.

</comment></comment></comment></comment><comment><USER16> I'd like to believe that this was a culture failure isolated to a single fulfillment center, but that seems like a convenient way to absolve Amazon of guilt.

At the end of the day, it's Amazon's responsibility to enforce a safety culture in each and every fulfillment center, and failing to do so is inexcusable.

</comment><comment><USER17> This is sad. I used to work in a warehouse and we were mandated to have training in proper forklift use. There is no excuse for Amazon not conducting proper training.

The Indiana officials who tried to cover this up should have their ass put in a sling.

<comment><USER18> How about Federal level OSHA refusing to get involved. That is seriously messed up. He even had the audio of the IOSHA coverup and that was not enough for OSHA?

Forklift training is one thing. Forklift maintenance is not something you could easily teach. It is learned by years of on the job experience.

Something that Amazon was not willing to pay for with Forklift Maintenance Mechanics.

Disgusting show from all parties involved. There should be a FBI investigation and the Governors phone location data used. I bet the whistle-blower is right.

</comment></comment><comment><USER19> It's embarrassing to watch proud cities (my hometown) humiliate themselves like game show contestants for this HQ.

</comment><comment><USER20> <quote> Amazon's corporate offices in Seattle gave a $1,000 campaign contribution to Indiana's governor. It was years before Holcomb would next face reelection, and Amazon hasn't donated to him before or since. </quote>

US state governors are this cheap? :)

<comment><USER21> Lobbyist are clever. It often isn't the money directly given that matters, but the threat of giving money to the opponent.

</comment></comment><comment><USER22> I highly doubt Amazon cares about $28000

<comment><USER23> That's what I thought.

Maybe it is about the state showing what it could do for Amazon in the future, should they build their HQ there? Or maybe it is more about saving the image of the company then the actual fine?

<comment><USER24> It's mentioned in the Reveal (investigative radio news source) coverage that Indiana had an active bid for HQ2 at the time the coverup happened.

<comment><USER15> That whole "new HQ" operation was a brilliant hoax. I hope the people who pulled that off see at least _some_ of their options vest before they get laid off.

</comment></comment></comment></comment><comment><USER25> This article feels a little fishy to me. The title says an "investigation says" "Indiana manipulated a report," but there's no evidence to suggest this besides one person's claims and it doesn't seem there was any official investigation into whether the report was manipulated. Also, all the figures appear to be an order of magnitude off... All this fuss over only $28,000? And a single $1,000 donation? That's a drop in the pond. I wouldn't be surprised if there was indeed a lot of corruption in bidding for Amazon's HQ, but something doesn't add up here for me.

<comment><USER15> The original article [0], which for some reason "indystar" doesn't care to link, has links to source material.

[0] [https://www.revealnews.org/article/behind-the- smiles/](https://www.revealnews.org/article/behind-the-smiles/)</comment></comment>


Lenovo ThinkPad TrackPoint Keyboard II is now available - <AUTHOR> https://www.notebookcheck.net/Lenovo-ThinkPad-TrackPoint-Keyboard-II-is-now-available.463107.0.html <comment><USER2> looks very useful, but not adding a wired usb support throught the integrated USB port seems a bit short sighted.</comment>


RIP Sparrow: Components open sourced for personal use only - <AUTHOR> http://thenextweb.com/insider/2012/07/27/rip-sparrow-the-beloved-mail-client-is-open-sourced-for-personal-use-only/

<comment><AUTHOR> Here are the contents of the two zip files that Sparrow provides at <http://sprw.me/lgpl.php>:

* mac.zip - <https://gist.github.com/3196054>

* iphone.zip - <https://gist.github.com/3196057>

In other words - not much at all. :(</comment>


How to Get More Visitors to Your App? - <AUTHOR> http://theappentrepreneur.com/how-to-get-more-visitors-to-your-app/ <comment><USER2> Though marketing via social networks and mobvertising certainly enable you to make money to some degree, the most important step towards successfully marketing your iPhone app would be to feature it in the iTunes App Store and also try and gather the maximum possible amount of positive user reviews for the same.</comment>


How to Create Meaningful Impact in Your Pursuits - <AUTHOR> http://www.timjlawrence.com/blog/2014/10/14/how-to-create-meaningful-impact

<comment><USER2> Nice find!</comment>


Open Hacker House: regular Wednesday meetup in San Francisco - <AUTHOR>

Working for yourself is great but working by yourself can suck. So we're going to try an experiment, put a stake in the ground and see what happens.
Every Wednesday, all Wednesday, we will host a meetup/hackathon in the back room of Mission Creek Cafe on 21st and Valencia in Mission, SF. Feel free to drop by any time, meet and work where everyone knows your username. No signup, just show up. We'll be there.
More details: http://www.archivd.com/open-hacker-house <comment><USER2> see you there</comment>


Ask HN: Does anyone use a physical two-factor authentication device? - <AUTHOR> I am trying to increase the security of my accounts and have enabled MFA on as many of the accounts that I can, using Google Authenticator. I am thinking about getting a key like Yubico instead of having to use Google Auth, is it more secure? Better? Do any of you guys use this? <comment><USER2> A u2f key protects you better from phishing, but unfortunately the number of sites that support it is very limited. Luckily it includes google and facebook, so you can harden these two, and use social login where u2f isn't supported.

As for the security key, you should check the support for your devices, ios is generally more problematic (keep in mind that even if you have an android phone, but you have an ipad, you prob need support for ios too). I wrote a blog post about this a while ago: [https://medium.com/@0x0ece/googles- advanced-protection-progr...](https://medium.com/@0x0ece/googles-advanced- protection-program-with-iphone-and-ipad-5f30802885e7)

</comment><comment><USER3> The physical U2F key protects you against phishing, which is important, but that's pretty much it.

</comment><comment><USER4> I use a yubikey for the few places that support u2f (google, github).

I still use Authenticator for a bunch of places that don't support u2f.

It likely wouldn't be worth it if I didn't also carry the yubikey for ssh public key.

<comment><AUTHOR> I didn't know you could use it as a ssh public key. Thanks.

</comment></comment><comment><USER5> I use a Yubikey mostly for convenience (grabbing your phone to login everywhere gets annoying), but sadly, not a lot of sites actually support U2F.

</comment><comment><USER6> I use a Yubikey NEO myself which is nice but not a heap of services support it.

Probably my favourite feature, which gets very little attention, is that you can store your MFA tokens on your key. Scanning a Yubikey NEO with the Yubikey app open will show your keys. Lost your phone? It's fine because you can just install the app on your new phone and there they are without being tied to a centralised service.

You can also store your GPG key on it but you're forced to only use 2048 bits over the highest setting of 4096. All it means is you need to have your key in to eg; sign commits which is a bit less convenient than reading from disc.

Oh yeah, I use the Windows subsystem for Linux and it doesn't support reading the Yubikey so it renders GPG signing useless for now. There was an update recently that increased USB support but I don't think it applies for USB hardware keys. I haven't tried though.

It's also worth nothing that Google doesn't follow the U2F spec which means that authenticating with their stuff only works inside Chrome. You can just fall back to SMS or MFA.

One thing I notice with Github is that if I don't have my Yubikey nearby, the only other default is MFA but with my tokens on my Yubikey... yeah, you can't just drop back to SMS so you gotta have it on you (for the first time/new browser) haha

tl;dr They're cool for "important" accounts ie Github, Google, GPG key storage is just ok and storing MFA tokens on it is pretty rad</comment>


Google offers free fabbing for 130nm open-source chips - <AUTHOR> https://fossi-foundation.org/2020/06/30/skywater-pdk <comment><USER3> I've spent some time in the chip industry. It is awful, backwards, and super far behind. I didn't appreciate the full power of open source until I saw an industry that operates without it.

Want a linter for your project? That's going to be $50k. Also, it's an absolutely terrible linter by software standards. In software, linters combine the best ideas from thousands of engineers across dozens of companies building on each other's ideas over multiple decades. In hardware, linters combine the best ideas of a single team, because everything is closed and proprietary and your own special 'secret sauce'.

In software, I can import things for free like nginx and mysql and we have insanely complex compilers like llvm that are completely free. In hardware, the equivalent libraries are both 1-2 orders of magnitude less sophisticated (a disadvantage of everyone absolutely refusing to share knowledge with each other and let other people build on your own ideas for free), and also are going to cost you 6+ figures for anything remotely involved.

Hardware is in the stone age of sophistication, and it entirely boils down to the fact that people don't work together to make bigger, more sophisticated projects. Genuinely would not surprise me if a strong open source community could push the capabilities of a 130nm stack beyond what many 7nm projects are capable of, simply because of the knowledge gap that would start to develop between the open and closed world.

<comment><USER4> I've been thinking about this a lot lately. In economics, the value of competition is well understood and widely lauded, but the power of cooperation seems to be valued much less - cooperation simply doesn't seem as fashionable. But the FOSS world gives me hope - it shows me a world where cooperation is encouraged, and works really, really well. Where the best available solution isn't just the one that was made by a single team in a successful company that managed to beat everyone else (and which may or may not have just gotten into a dominant position via e.g. bigger marketing spend). It's a true meritocracy, and the best ideas and tools don't just succeed and beat out everything else, they are also copied, so their innovation makes their competitors better too - and unlike the business world, this is seen as a plus. The best solutions end up combining the innovation and brilliance of a much larger group of people than any one team in the cutthroat world of traditional business. Just think about how much effort is wasted around the world every day by hundreds of thousands of companies reinventing the wheel because the thousands of other existing solutions to that exact problem were also created behind closed doors. Think about how much of this pointless duplication FOSS has already saved us from! I really hope the value of cooperation and the example set by FOSS can spread to more parts of society.

<comment><USER5> but let's not forget the non-material nature of software allows this, hardware will always be a physical (material) artifact.

however the line does blur when talking about blueprints and designs.

in any case, I think that free software movements are a sociological anomaly, I wonder if there is any academic research into this from an antropological or an historical economics viewpoint.

also, it seems to me that in some sense the entire market works in cooperation, just not very efficiently (it optimizes for other things than efficiency and is heavily distorted by subsidies and tariffs)

<comment><USER4> I'm curious to hear what you mean when you say the entire market works in cooperation? I mean, strategic partnerships happen, and companies work as suppliers for other companies. But that's not the market - the market is where someone wanting to buy something goes and evaluates competing products and picks the one they want to buy. It's pretty comparable to natural selection, where the fittest animals survive and the fittest companies get bigger marketshare while the least fit companies go bankrupt, and the least fit species go extinct. So I guess you could say that the market functions as an ecosystem - maybe the word you were looking for was 'symbiosis' rather than cooperation? Cheetah's aren't cooperating with lions, they are competing - <USER2> relative to the rest of the ecosystem, they exist in a form of symbiosis.

<comment><USER6> 'Survival of the fittest' when applied to groups implies cooperation as an essential skill between individuals. It's not all competition. The fittest group is not the one made of the most individually fit members, they also need to function well together.

<comment><USER7> _" selfish individuals beat altruistic individuals. Altruistic groups beat selfish groups. Everything else is commentary."_

-David Sloan & E. O. Wilson

</comment></comment></comment></comment></comment></comment><comment><USER8> This is amazing.

I think the main reason why open source has taken off is because access to a computer is available to many people, and as cost is negligible, it only required free time and enough dedication + skill to be successful. For hardware though, each compile/edit/run cycle costs money, software often has 5-digit per seat licenses, and thus the number of people with enough resources to pursue this as a hobby is quite small.

Reduce the entry cost to affordable levels, and you have increased the number of people dramatically. Which is btw also why I believe that "you can buy 32 core threadripper cpus today" isn't a good argument to ignore large compilation overhead in a code base. If possible, enable people to contribute from potatoes. Relatedly, if possible, don't require gigabit internet connections either, so downloading megabytes of precompiled artifacts that change daily isn't great either.

<comment><USER9> Not only is the software expensive it's often crap. By which I don't mean, oh no it doesn't look nice - crap as in productivity-harming.

For example, Altium Designer is probably the most modern (not most powerful although close) PCB suite and yet despite costing thousands a seat it is a slow, clunky, _single-threaded (in 2020)_ program (somehow uses 20% of a 7700k at 4.6GHz with an empty design). Discord also thinks that Altium Designer is some kind of Anime MMO

<comment><USER10> From what I can tell a lot of parametric design software is also single threaded. I felt like this is was an opportunity where usage of multiple cores could make Freecad stand out a little bit. Except Freecad uses opencascade as their kernel and they require you to sign a CLA just to download the git repository. Considering that barrier to just cloning the code I just decided to not contribute anything. They do offer zip file downloads of the source code but at that point I lost interest.

<comment><USER11> I suspect geometric kernels and 2D/3D renderers don't fall into the "easy to parallelize" category. Of course there are functions that use multiple threads, but it's not obvious how you could build the core system to do so. However the code in CAD software is often pretty old, it wasn't that long ago that many of these still used intermediate mode OpenGL and I wouldn't be surprised if some still do.

In the same vein something like ECAD tools don't use GPU-accelerated 2D rendering but instead use GDI and friends (which used to be HW-accelerated, but isn't since WDDM/Vista).

A lot of "easy" opportunities to improve UX and productivity.

<comment><USER12> It seems like it depends a lot on your representation of the circuit network. If you consider each trace and PCB element as a node in a graph which maps the connections of the traces and PCB elements then you could parallelize provided you can describe the boundary conditions at each node. There's a degree to which they're interdependent, but there are also nodes at which the boundary condition is effectively constant and I think those would make good cut points for parallelization.

</comment></comment></comment></comment></comment><comment><USER13> Strategically, could this be part of a response to Apple silicon?

Or put another way, Apple and Google are both responding to Intel/the market's failure to innovate enough in idiosyncratic manner:

\- Apple treats lower layers as core, and brings everything in-house;

\- Google treats lower layers as a threat and tries to open-source and commodify them to undermine competitors.

I don't mean this free fabbing can compete chip-for-chip with Apple silicon of course, just that this could be a building block in a strategy similar to Android vs iOS: create a broad ecosystem of good-enough, cheap, open-source alternatives to a high-value competitor, in order to ensure that competitor does not gain a stranglehold on something that matters to Google's money- making products.

<comment><USER14> These are not related at all. Only common element is making silicon.

Apple spends $100+ millions to design high performance microarchitecture to high-end process for their own products.

Google gives tiny amount of help to hobbyists so that they can make chips for legacy nodes. Nice thing to do, nothing to do with Apple SoC.

\---

Software people in HN constantly confuse two completely different things

(1) Optimized high performance microarchitecture for the latest prosesses and large volumes. This can cost $100s of millions and the work is repeated every few years for a new process. Every design is closely optimized for the latest fab technology.

(2) Generic ASIC design for process that is few generations old. Software costs few $k or $10ks and you can uses the same design long time.

<comment><USER15> > Nice thing to do

I don't believe Google does anything because it's a "nice thing to do". There's some angle here. The angle could just be spurring general innovation in this area, which they'll benefit from indirectly down the line, but in one way or another this plays to their interests.

<comment><USER16> Google has never created a product that does not collect data in a unique manner apart from its other products.

<comment><USER17> They must be some kind of genius. I don't see how are they going to be able to extract personal information out of here.

<comment><USER16> They're not doing this out of the kindness of their heart. Just because we don't know the data being collected here (yet) does not invalidate my statement. Name a google product and you can easily identify the unique data being collected.

</comment></comment></comment></comment></comment></comment><comment><USER18> TFA doesn't really summarize what's available very well, so let me take a shot from a technical perspective:

\- 130 nm process built with Skywater foundry \- Skywater Platform Development Kit (PDK) is currently digital-only \- 40 projects will be selected for fabrication \- 10 mm^2 area available per-project \- Will use a standard harness with a RISC-V core and RAM \- Each project will get back ~100 ICs \- All projects must be open source via Git - Verilog and gate-level layout

I'm curious to see how aggresive designs get with analog components, given that they can be laid out in the GDS, but the PDK doesn't support it yet.

<comment><USER19> I'm thinking 10mm^2 so kinda 3.3mm x 3.3mm. In 130nm

(Remember 130nm gave us the late models Pentium 3s, the second model P4s and some Athlons, though all of these had a bigger die size)

I'm thinking you could have some low power or very specific ICs, where these would shine as opposed to a generic FPGA solution

<comment><USER20> > 10mm^2 so kinda 3.3mm x 3.3mm

3.16mm x 3.16mm?

<comment><USER19> Square root by head is hard ;)

</comment></comment></comment></comment><comment><USER21> From a hobbyist and preservation perspective, it would be cool if this could be used to produce some form of the Apollo 68080 core to revive the 68k architecture a little bit, and build out the Debian m68k port [0][1]. The last "big" 68k chips were produced in 1995 (that would be a 350nm process?) so this could be hugely improved on 130nm. The 68080 core is currently implemented in FPGAs only and is already the fastest 68k hardware out there. With a real chip, people could continue upgrading their Amigas and Ataris.

[0]: [http://www.apollo-core.com/](http://www.apollo-core.com/) I can't easily find how "open source" it is though, but it's free to download.

[1]: [https://news.ycombinator.com/item?id=23668057](https://news.ycombinator.com/item?id=23668057)

<comment><USER22> What happened to freescale/NXP "Coldfire"?

<comment><USER23> ColdFire is still around but is also not fully binary compatible with 68k. There have been attempts at making Amiga accelerator cards using Coldfires, but I don't think I've ever seen one that was fully finished.

<comment><USER24> It's not fully binary compatible but pretty damn close. People working on the Firebee were able to make it run pretty smooth, there's some things you can do to trap the old instructions and rewrite. It's never going to work for games and the like, but games and the like from that era have all sorts of other video hardware specific dependencies that are even more difficult to satisfy.

It really is "spiritually" a 68k series processor, just with some cleaning up. I like it.

</comment></comment></comment></comment><comment><USER25> I believe that a lot of people here might be interested in "Minimal Fab", developed by a consortium of Japanese entities.

These are kiosk-sized machines that a company can use to set up a fab with a few million dollars. Any individual can then design a chip and have it fabricated very (as in "I want to make a chip for fun") affordably.

I was not able to find a ton of information on this, but the 190nm process was supposedly ready last year and there were plans to go below this. The wafers are 12mm in diameter (so basically, one wafer -> one chip) and the clean room is just a small chamber inside the photolithography machine. There are also no masks involved, just direct "drawing".

</comment><comment><USER26> My advice to anyone who's looking for a pathway into open source silicon is to look into E-Beam lithography. Effectively E-Beam lithography involves using a scanning electron microscope to expose a resist on silicon. This process is normally considered to slow for industrial production but it's simplicity and size make it ideal for prototyping and photo mask production.

The simplistic explanation for why this works is that electron beams can be easily focused using magnetic lenses into a beam that reaches the nano meter level.

These beams can then be deflected and controlled electronically which is what makes it possible to effectively make a cpu from a cad file.

Furthermore, It's very easy to see how the complexity of photolithography goes up exponentially as we scale down.

Therefore I believe it makes sense to abandon the concept of photolithography entirely if we want open souce silicon. I believe that this approach offers something similar to the sort of economics that enable 3D printers to become localized centers of automated manufacturing.

I should also mention that commercial E-beam machines are pretty expensive (something like 1-Mil) but that I dont think it would be that difficult to engineer one for a mere fraction of that price.

<comment><USER27> I suggest you take a look at how easy maskless photolithography is: [https://sam/zeloof.xyz](https://sam/zeloof.xyz)

Theoretically it should be feasible to fab 350 nm without double-patterning by optimizing a simple immersion DLP/DMD i-line stepper.

I think ArF immersion with double-patterning should be able to do maskless 90 nm.

<comment><USER28> fixing the url [http://sam.zeloof.xyz/](http://sam.zeloof.xyz/)

</comment></comment></comment><comment><USER29> How much has the power efficiency improved between 130nm and 7nm? Is it plausible to get better performance/watt for a custom chip on 130nm vs a software application running on a 7m chip? I get that hardware has other benefits but just wondering for accelerators where the cost/benefit starts to make sense.

<comment><USER22> > Is it plausible to get better performance/watt for a custom chip on 130nm vs > a software application running on a 7m chip?

This very, very much depends on what the algorithm is (integer or FP? how data dependent?), but I would say no for almost all interesting cases.

The only exception would be if you're doing a "mixed signal" chip where some of the processing is inherently analogue and you can save power compared to having to do it with a group of separate chips.

Another exception might be _low leakage_ construction, because that gets worse as the process gets smaller. This is only valuable if your chip is off almost all of the time and you want to squeeze down exactly how many nanoamps "off" actually consumes.

<comment><USER30> An open source WiFi chip would be super cool. I wonder how easy it would be to take the FPGA code from openwifi[0] and combine it with a radio on the same chip?

[0] [https://github.com/open-sdr/openwifi](https://github.com/open- sdr/openwifi)

<comment><USER22> The problem is that analogue IC design is a field that even digital IC design people regard as black magic. It's clearly _possible_ for that to happen but the set of people who have the skills to do it is very narrow and most of them are probably prevented from doing it in their spare time by their employment agreements.

I wonder how many "test chips" Google will let a non-expert team do to get it right? And whether they provide any "bringup" support?

<comment><USER31> They're only allowing parts that stay within the bounds of the PDK (which only allows digital designs) for now.

</comment></comment></comment></comment></comment><comment><USER32> I should note there's open source ASIC toolchain - OpenROAD[1][2]. I wonder if these can be integrated. You also can use SymbiFlow to run your prototype in FPGA[3][4].

[1] [https://theopenroadproject.org/](https://theopenroadproject.org/)

[2] [https://github.com/The-OpenROAD-Project/OpenROAD](https://github.com/The- OpenROAD-Project/OpenROAD)

[3] [https://symbiflow.github.io/](https://symbiflow.github.io/)

[4] [https://github.com/SymbiFlow](https://github.com/SymbiFlow)

<comment><USER33> Spot on. Both are discussed by Tim in the video as part of the solution stack.

</comment></comment><comment><USER34> Because apparently no one remembers the other "free" fab service.

[https://www.themosisservice.com/university- support](https://www.themosisservice.com/university-support)

Previously MOSIS would run select a few student/research designs to go along with the commercial MPW runs, frequently on pretty modern fabs. I'm not really sure how much they still run.

(oh here is the MOSIS/TSMC runs for this year [https://www.mosis.com/db/pubf/fsched?ORG=TSMC](https://www.mosis.com/db/pubf/fsched?ORG=TSMC))

<comment><USER35> But this one is open to hobbyists. If you're doing a graduate degree in ASIC design and your group doesn't have the funds to do simple fab runs, you're probably in a somewhat questionable program to begin with.

</comment></comment><comment><USER36> > All open source chip designs qualify, no further strings attached!

Surely they have some threshold requirements that the thing actually works? How is this going to work? I mean, if there's no investment required from me, what's the incentive for me to verify my design properly? What's the point in them fabbing a load of fatally bugged open-source designs?

<comment><USER37> All open source designs qualify, doesn't mean they get selected :/ If you look at the slides, they say that each run will be 40 designs, and they'll do one run this year and multiple next. Criteria for how they'll choose if there are more than 40 applicants TBD.

</comment></comment><comment><USER38> With the PDK being open, does anyone know if any kind of NDAs are still required to get a chip fabbed? While free-of-charge fabbing is quite nice, I think being NDA-free is even more important so all work including the tweaks necessary for fabbing can be published, e.g. on GitHub.

BTW, it will be nice to try this together with the OpenROAD tools [1]. They have support for Google's PDK on their to-do list (planned for q3, but I doubt it will be ready that fast).

[1] [https://github.com/The-OpenROAD-Project](https://github.com/The-OpenROAD- Project) [https://theopenroadproject.org/](https://theopenroadproject.org/)

<comment><USER39> yup, NDAs destroys economic productivity.

<comment><USER39> From talking to VC. NDA are useless. It really comes down to whether you trust the people or not. It is like patent just a gesture. Everything is in the implementation.

</comment></comment></comment><comment><USER40> That sounds pretty huge. I've never seen on Hackaday or similar people getting small runs of chip fabbed. What are the broader implications of this? Will other fabs start to lower the barrier to production as well?

<comment><USER41> You generally don't do small runs of chips, unless cost is no object. The NRE costs of getting the masks made, even on older processes like these are still comfortably in the $X00,000 range, blowing past $1 million pretty quickly if you need a process that isn't ancient. That's without design software licenses, which can be hundreds of thousands more.

So the minimum order quantity usually needs to be at least in the tens to hundreds of thousands of chips if you don't want each chip to be a sizeable chunk of that initial cost.

It would be really nice to get to the point where small batch chips were viable though. One aspect is cost -- if they could get the NRE cost down to, say, $20k - $50k, and the software licensing cost down to zero, that would open up a lot of options.

The other aspect is the "dark art" nature of the process kit and communicating with the fab. If everybody assumes that chip design is expensive, they're going to be reluctant to even talk to the fab to see what options are available. If they see a bunch of people building interesting things with this shuttle program, then all of a sudden the fab is going to see more business interest as people try to figure out if there's a way to make their project work.

<comment><USER42> There are cheap-ish multi-project wafers (MPW).

These organizations typically also gives access to software design tools. But that's still a sizeable investment. Last project I've worked on used a (more expensive than usual I think) GloFo 22nm technology. Price was around €9k/mm², 9mm² was the minimum area. Still much more accessible to academia than individuals or open source projects, but not out of the realm of a crowdfunding campaign.

There are multiple chips that ought to be open source, broadly available, and cheap: AV1 decoders, small FPGAs, Wi-Fi or SDR chips, TMPs, and other crucial pieces for security, DIY/open HW projects, and basic computer building blocks. Most interesting to me are chips that would allow novel applications that commercial ventures would never look at, like open, hackable p2p WiFi meshes, or emulators-on-a-chip, or other application-specific coprocessors (protein folding, etc).

[1] ttps://mycmp.fr/technologies/process-catalog/

[2] [https://europractice-ic.com/](https://europractice-ic.com/)

<comment><USER27> A while back I came up with the idea of an ultra-miniature quadro copter with asynchronous outrunner motors who's stators would most likely be sintered (with or without a ferromagnetic matrix) to handle the power density, and a simple tube-shaped rotor (though a squirrel cage style might be better).

I'm thinking 5-20 mm rotor diameter (3M-750k rpm transonic limit), or maybe even smaller.

The interesting part would be an analogue ASIC that decodes an external control signal modulated onto the microwave (via rectenna) or optical (solar cell/photodiode) "wireless power" beam.

Demodulation would first do naive rectenna-based AM demodulation, followed by a bandpass and FM demodulation, revealing 12 carriers corresponding to the 4 3-phase motors, which are just FM-demodulated to yield the H-bridge control signals.

These would primarily be one xx MHz PLL and 12 lower-frequency ones spaced 50-200 kHz (the FM subcarrier's bandwith (assuming narrow-band FM) is twice the maximum motor field frequency), starting as low as feasible while still being able to use AC-coupling liberally.

Also either some amplifiers for (potentially-overdriven) "linear" H-bridge operation or (NE555-like?) PWM chopper drivers to exploit the winding inductance for less-wasteful H-bridge operation.

Far too much to realize in discrete circuitry, but nothing really fancy beyond a parametric PLL design. And not really realistic for a μC, either, because of brown-out resilience and overall latency.

At least the polyphase induction motors are very easy to drive, compared to the typical 3-phase permanent magnet outrunner motors used in most multicopters.

Depending on how predictable the effects of some tuning parameters are, maskless litho could allow for chips to be tuned to measured electro- mechanical properties of these sintered motors, reaching optimal drive waveforms. And for digital circuits, hard-wired ROM (security/shelf life/radiation-hardness) for individual chips or even doping-controlled ROM for anti-readout private/secret key storage.

I expect a maskless double-patterning ArF+immersion process allowing NDA-free- usage to be "the" thing that would enable true state-of-the-art experimentation and true ASICs (where the prototype needs an ASIC to be more than a paperweight after some photoshoots and staged interactions).

Feel free to contact me/let me know if you'd like further discussion(s).

</comment></comment></comment></comment><comment><USER43> This reminds me of how cubesats kind of got off the ground because some launch commpanies allowed extra spare capacity to be sold or donated to student projects.

<comment><USER44> I couldn't tell which was the cart and which the horse, but the SpaceX telecommunications satellite launch I saw had a rideshare arrangement going on. I suspect what happened is that someone only needed half a payload, and SpaceX filled the rest with their own stuff. But the PR person made it sound like the opposite was happening.

I'm not sure what happens when they reach full capacity on their sat network. Space for research projects, or launching surplus consumables?

</comment></comment><comment><USER45> Well done Google. But there is still problem with EDA tool license... Is there any replacement for Cadence Virtuoso tool for chip design?

<comment><USER46> The efabless people that the talk mentions a bunch of times are using a fully open-source design flow but I think it's a bit hacky (as in, a bunch of command line tools from various open source projects, some of which may be unmaintained judging by the commit logs). They seem to have successfully fabricated a RISC-V based SoC with it though, which is crazy cool.

As somebody with a decent amount of FPGA experience, having a go at setting this software up and seeing if I can get anything to synthesise and through place and route is something I've been intending to have a play with, but I haven't had the spare time.

It uses yosis for synthesis and a few other tools for the rest of the process, and is called Qflow - [http://opencircuitdesign.com/qflow/index.html](http://opencircuitdesign.com/qflow/index.html)

<comment><USER42> IIRC there are a couple ways to produce the intended design. At the end of the day, fabs often take layouts in the GDSII format, which is documented and open. The Klayout open source visualizer is industry-standard in my experience.

Now, how do you generate these layouts? It depends on what you are doing. If more on the experimental side of things, writing scripts to generate structures is fine, as long as these conform to the fab-provided design rules. Technically, that's still what everyone is doing at the industrial level, except the scripts -- often written in tcl -- are provided by the fab.

Now if you have some FPGA experience, you are probably interested in logic synthesis tools. There are a few ones, I've seen some academic with their own place-and-route stage, for instance. [https://open-src- soc.org/program.html#T-CHAPUT](https://open-src-soc.org/program.html#T-CHAPUT) does that, I think.

The slides linked above outline one of the possible ways to do this: leverage chisel ( [https://www.chisel-lang.org/](https://www.chisel-lang.org/)) and the FIRRTL intermediate representation for RTL description. A few tools can ingest the output and try to come up with a layout. Hammer ([https://github.com/ucb- bar/hammer](https://github.com/ucb-bar/hammer)) is such a tool, but I don't think that PDK is available with it just yet. To be honest, I don't think commercial tools are _that_ advanced, and it would be fairly doable to catch up.

There is some interesting work in this field, but since fabbing is expensive, it tends to be more within the academic community than the free software one. I'd look for papers, not on Github, though that's slowly changing.

The chip design world is a slow beast to turn around: everything in the fabrication process is optimized to maximize yield, hence very little leeway is allowed: "If it ain't broken, don't fix it" is the motto, for good reason: if changing humidity levels 0.2% can make a fab lose millions; they won't try to use new and experimental software.

I'm watching this space, notably with Verilog alternatives such as Migen. The open source community starts to embrace FPGA, wich is already great. I wish more manufacturers opened up their bitstream, so maybe we need an open FPGA? Though this free fabbing offer would be a great fit for Wi-Fi chips, I think. I wonder if People at openwifi ([https://github.com/open- sdr/openwifi](https://github.com/open-sdr/openwifi)) are interested?

I hope that gives a few interesting pointers to whoever reads this :)

<comment><USER47> Hammer is just a driver for tools that cost >100k to license. And that doesn't include access to memory compilers, which you would also need.

<comment><USER48> There is an open PR adding support for the OpenROAD tools [^1]. So, there should be a flow that uses open source VLSI tools eventually.

The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out.

[^1]: [https://github.com/ucb-bar/hammer/pull/584](https://github.com/ucb- bar/hammer/pull/584)

[^2]: [https://www.eda.ncsu.edu/wiki/FreePDK](https://www.eda.ncsu.edu/wiki/FreePDK)

</comment></comment></comment></comment></comment><comment><USER49> Can anyone venture a guess as to why Google might be doing this? What's the incentive structure here?

<comment><USER50> The market of skilled hardware designers is running low: training costs are high, complexity has skyrocketted. By doing this they can increase attention to a field that is otherwise dominated by big corporates (already somewhat the case). The only way to have a sane and healthy chip market is to make 1) the entry barrier low and 2) stimulate innovation. This does both of that.

<comment><USER51> Another point is that silicon-related tech is currently leaving US and begins booming in China.

</comment></comment></comment><comment><USER52> Any Chisel developers here ?

How fast is the iterative development and library ecosystem compared to native traditional RTL design tools ?

<comment><USER48> I'm one of the Chisel devs.

My biased view is that iterative development with Chisel, to the point of functional verification, is going to be faster than in a traditional RTL language primarily because you have a robust unit testing framework for Scala (Scalatest) and a library for testing Chisel hardware, ChiselTest [^1]. Basically, adopting test driven development is zero-cost---most Chisel users are writing tests as they're designing hardware.

Note that there are existing options that help bridge this gap for Verilog/VHDL like VUnit [^2] and cocotb [^3].

For libraries, there's multiple levels. The Chisel standard library is providing basic hardware modules, e.g., queues, counters, arbiters, delay pipes, and pseudo-random number generators, as well as common interfaces, e.g., valid and ready/valid. Then there's an IP contributions repo (motivated by something like the old tensorflow contrib package) where people can add third-party larger IP [^4]. Then there's the level of standalone large IP built using Chisel that you can use like the Rocket Chip RISC-V SoC generator [^5], an OpenPOWER microprocessor [^6], or a systolic array machine learning accelerator [^7].

There are comparable efforts for building standard libraries in SystemVerilog, notably BaseJump STL [^8], though SystemVerilog's limited parameterization and lack of parametric polymorphism limit what's possible. You can also find lots of larger IP ready to use in traditional languages, e.g., a RISC-V core [^9]. Just because the user base of traditional languages is larger, you'll likely find more IP in those languages.

[^1]: [https://github.com/ucb-bar/chisel-testers2](https://github.com/ucb- bar/chisel-testers2)

[^2]: [https://vunit.github.io/](https://vunit.github.io/)

[^3]: [https://docs.cocotb.org/en/latest/](https://docs.cocotb.org/en/latest/)

[^4]: [https://github.com/freechipsproject/ip- contributions](https://github.com/freechipsproject/ip-contributions)

[^5]: [https://github.com/chipsalliance/rocket- chip](https://github.com/chipsalliance/rocket-chip)

[^6]: [https://github.com/antonblanchard/chiselwatt](https://github.com/antonblanchard/chiselwatt)

[^7]: [https://github.com/ucb-bar/gemmini](https://github.com/ucb-bar/gemmini)

[^8]: [https://github.com/bespoke-silicon- group/basejump_stl](https://github.com/bespoke-silicon-group/basejump_stl)

[^9]: [https://github.com/openhwgroup/cva6](https://github.com/openhwgroup/cva6)

<comment><USER52> Gracias.

</comment></comment></comment><comment><USER51> Can someone please tell me how photo-masks are produced? I don't understand how can tiny features be printed at almost the same scale as a final structure? With a laser beam?

Say, as an input you have a layer description (schematics) - how can you transfer it to a tiny scale so precisely to produce a mask?

<comment><USER53> They aren't built at the same scale, they're much larger than the final structure and lenses are used to scale the image down to the desired size.

Here's a video form Intel on how they are made: [https://youtu.be/u3ws0UebnSE](https://youtu.be/u3ws0UebnSE)

Apparently they use "electron beams", not sure what those are, they sound similar to lasers but with electrons, from this video: [https://youtu.be/PWV9pvdRBNY](https://youtu.be/PWV9pvdRBNY)

<comment><USER54> Wouldn't that just be something like CRT? [https://en.wikipedia.org/wiki/Cathode- ray_tube](https://en.wikipedia.org/wiki/Cathode-ray_tube)

<comment><USER10> It's probably closer to how an electron microscope works.

</comment></comment></comment></comment><comment><USER55> My understanding of ASIC production, is that new circuit designs are capital intensive, they require masks to be produced and machines to be configured for the given pattern.

Are older processes more automated?

Can the 130nm production line, produce many different designs without any manual intervention?

<comment><USER56> Mask sets will still be required for each chip (to my knowledge), but they are significantly cheaper on older processes like 130nm.

The process design kit (or PDK) mentioned in the article takes care of "configuring the machiines". The PDK provides describes how to construct low- level primitives (the instruction set, if you will) for the specific fab. Designers then layer on their logic circuits using those primitives.

</comment></comment><comment><USER57> This is cool! But I fear the workflow to get a chip out the door requires a lot of niche specialized knowledge. Making a logic design work on an FPGA is much easier, because the chip overhead (stuff like I/O pins) is all handled for you. If I had to design my own I/O pins at the silicon level, I wouldn't know where to start. And having access to open-source tools that give me the ABILITY to build a chip doesn't help with the _knowledge_ I'm missing.

I think, however, that this may help Google integrate into academia. I can imagine a lot of MSEE and PhD students are looking at this hungrily.

<comment><USER58> The project comes with a standard harness around your 10mm^2 design, with provided I/O and a working RISC-V supervisor CPU.

</comment></comment><comment><USER59> Interesting, 130nm was achieved by Pentium III as a reference: [https://en.m.wikipedia.org/wiki/130_nm_process](https://en.m.wikipedia.org/wiki/130_nm_process)

</comment><comment><USER60> That is great. It will encourage new hobbyist opensourse Eco-system around hardware community just like many FOSS communities.

Even engineers/students from countries with less resources will now be able to design make prototypes in viable way.

</comment><comment><USER24> I have a friend who has a Verilog clone of the C64 VIC-II chip, which he has interfaced into a real C64 and it's running pretty much everything, demos, etc. even supports weird things like the lightpen.

I wonder if his project would fit the bill here... real VIC-II chips are dying all over the place and getting hard to find... manufactured ASICs to replace them could be a popular item....

</comment><comment><USER61> So, this doesn't appear to have been announced by google. It does seem to be real but the OP may be jumping the gun a bit.

The authoritative source seems to be the slides of this guy at google: [https://docs.google.com/presentation/d/e/2PACX-1vRtwZPc8ykkk...](https://docs.google.com/presentation/d/e/2PACX-1vRtwZPc8ykkkgtUkHkoJZrP9jKOo3FYdKqbg- So0ic6_kx7ha1vHnxrWmuxWkTc9GfC8xl0TfEpMLwK/pub?start=false&loop=false&delayms=3000#slide=id.g8a02ce4cad_0_207)

From the slides this is "current plans, subject to change". This is an 'open source shuttle process'. Shuttle processes are a relatively cheap way of making _small numbers_ of chips (it is actually more costly per chip, but the fixed cost is smaller). There will be some kind of approval process, and I would imagine that there is a capacity limit for both the number of chips and number of projects.

(I didn't have time to watch the talk, so the above is just from the slides)

<comment><USER62> Maybe watch the talk first before commenting? All these questions are answered in the talk.

<comment><USER61> Well since you evidently did have time to watch the talk, perhaps you also have time to enlighten us about these questions. If not, maybe don't criticise those of us who used at least some of our time to dig out some information for the thread.

<comment><USER63> You could have just watched the talk instead of reprimanding him.

</comment></comment></comment></comment><comment><USER64> How "bad" is that compared to standard/common 14nm, etc...

<comment><USER21> 130nm was used to make the Athlon XP, Athlon 64, Pentium M, Pentium 4 and PowerPC G5 in the 2001-2003 timeframe [0]. So at the peak of 130nm's performance spectrum, it was able to produce stuff that can still run 2020 software quite okay. The Athlon 64 is probably the best 130nm silicon produced in its heyday and it's in the ballpark of a Raspberry Pi 4 (which has a 28nm SoC) in single core benchmarks.

I don't think this program is meant or likely to produce high frequency 100mm2+ chips (and it's worth remembering those chips had a lot of engineering effort put in them outside of manufacturing process) but it should permit chips of somewhat decent performance. It's a very generous thing!

[0]: [https://en.wikipedia.org/wiki/130_nm_process](https://en.wikipedia.org/wiki/130_nm_process)

<comment><USER65> As I recall from that generation, also the first models of AMD opterons, commonly built into dual socket motherboards. For the time they were very speed competitive with the Intel option.

<comment><USER66> I think at that time, Opterons was THE server processor.

<comment><USER65> I recall the dual socket (everything was single core at the time) Xeon being particularly unimpressive.

In fact it was somewhat of a step backwards from the better thermals/power efficiency of a dual socket, 1.13 to 1.4 GHz / 512KB cache Tualatin pentium 3.

</comment></comment></comment></comment></comment><comment><USER67> Simple question: aren't you basically not allowed to make chips because of patents? Not literally forbidden, but aren't there so many patents that you can't really work without violating one, even if you have never heard of it or the technique before? It just sounds so hazardous

</comment><comment><USER68> Is enough of the PDK open now to allow for actual hacking on devices? I have a rather simple analog chip I'd love to make for my own personal uses (I'd love a really long modern bucket brigade device to build gritty analog delay lines for synth hacking)...

</comment><comment><USER69> Sounds interesting but what you build as an open source chip?

I mean 130nm is 20 year old technology and you can buy general purpose CPUs today which are night and day faster than anything made with 130nm. Allowing you to emulate anything specialized using sofware.

<comment><USER70> Gate level emulation is really, really slow. If you've got a nice abstraction like the x86 ISA you can simulate a chip at that level far faster but if you're interested in the net level design rather than the abstraction emulation will be way, way slower. At least in throughput, it takes a long time to fab a chip and so you really ought to do emulation first in any event.

And for gate/line level effects things get slower still. Back when I was doing my master's thesis I was running simulations over the weekend on sequences of 100s of instructions in SPICE.

</comment></comment><comment><USER71> Can I in theory build one optimised for running one program? Will it be of any benefit?

<comment><USER72> yes, but it depends on the program, that's what the whole ASIC industry for bitcoin mining is.

<comment><USER71> I was thinking about AutoDock Vina ( Molecular Docking Software ), I have literally 0 knowledege about hardware :(

Then again, this is going to be a really fun experience

<comment><USER73> Yes, you can build dedicated ASICs. No, it's not worth it for docking software.

<comment><USER74> According to Wikipedia there has been some success building FPGAs for Autodock, so maybe it could be. [https://en.m.wikipedia.org/wiki/AutoDock](https://en.m.wikipedia.org/wiki/AutoDock)

<comment><USER73> yes but since drug discovery isn't bottlenecked by virtual docking throughput, it doesn't matter.

We've seen similar approaches applied to BLAST, and in the end, everybody ends up giving up the ASIC or the FPGA because it's not cost effective long-term.

</comment></comment></comment></comment></comment></comment><comment><USER75> I wonder if you can make micro machines at this level? The MEMS thing.

I always wondered why you needed gearing mechanisms in a micro machine. Has there ever been a practical application for gears in MEMS?

<comment><USER46> Not with this PDK or process, no. MEMS processes are quite specialised, and I beleive this project only supports digital standard cells currently, with IO and analogue/RF stuff coming out eventually (it's on the roadmap in the slides).

<comment><USER76> > I wonder if you can make micro machines at this level? The MEMS thing.

At this size range, though state-of-the-art MEMS (mechanical vibrating frequency filters for RF receivers in phones, accelerometers) can have sub-100nm dimensions, basic accelerometers, pressure sensors, and inkjet heads are absolutely doable.

> Not with this PDK or process, no. MEMS processes are quite specialised.

But yeah, this is the problem. Although ICs and MEMS devices are made with similar tools, MEMS usually needs processing steps that don't play nicely with the steps in an IC process (e.g., etching away huge amounts of silicon to leave gaps and topography, or using processing temperatures and materials that mess up ICs). This SkyWater process cannot do MEMS.

A more general problem is that different MEMS devices often need different incompatible process steps, so a standardized process is infeasible (though [http://memscap.com/products/mumps/polymumps](http://memscap.com/products/mumps/polymumps) tries).

However, there is a tiny chance that, if we get enough detail on the process steps and leeway in the design rules, a custom layout could implement a rudimentary accelerometer or something that works after post-processing (say, a dangerous HF bath), but only with intimate knowledge of said process steps (e.g., internal material stress levels) and a lot of luck.

</comment></comment></comment><comment><USER77> Could someone explain, is there any advantage of producing a 130nm custom SoC compared to using a lower node FPGA for the same design?

<comment><USER78> Current consumption. FPGAs are quite energy intensive compared to ASICs.

Also for analog stuff you can't use FPGAs. And if you need an ASIC anyways for that why not include the digital part as well?

<comment><USER70> The crossover point where ASICs become less expensive than FPGAs is also lower than you might think even including mask costs, provided it's on an older process node.

</comment></comment></comment><comment><USER79> So, until now, there's been this niche for FPGAs, where people would buy them in decent numbers to use _with static programming, in production devices_ , simply because they needed some custom DSP or some-such, but the capital costs of an ASIC fab-run would be a killer for their project.

Has this announcement thrown that use-case for FPGAs out the window?

<comment><USER80> The economics of FPGAs and ASICs over the past few decades are covered really well in [1]. It's almost always about production volume. The FPGA's ability to be reprogrammed is often a convenient side-effect.

In short, no, this doesn't impact the trade-offs and wouldn't even if Google provided this service as a commercial print-on-demand offering. You can get an ASIC fab'd on older nodes for surprisingly cheap, if you have the know-how and access to tools [2].

When power is a first-class design problem (it frequently is), even an "old" 28nm FPGA like Xilinx's 7 series will run rings around an 130nm ASIC. The extra silicon you're powering in the FPGA is more than offset by the economical access it gives you to modern nodes with lower voltages.

[1]: [https://ieeexplore.ieee.org/document/7086413](https://ieeexplore.ieee.org/document/7086413) [2]: [https://spectrum.ieee.org/tech- talk/computing/hardware/lowbu...](https://spectrum.ieee.org/tech- talk/computing/hardware/lowbudget-chip-design-how-hard-is-it)

</comment></comment><comment><USER81> Could anyone offer an explanation of what this means, for all of us who have no experience with hardware at all?

</comment><comment><USER82> Could this be suitable for a camera sensor? I don't know anything about hardware, but I am intrigued by the idea of exploring new camera sensor ideas.

Edit: Nevermind, another comment says 10 mm^2 per project. That's probably too small for the type of camera sensor I have in mind.

</comment><comment><USER83> That's really awesome. If that gives us widely available open source hardware, our computing freedom will always be safeguarded. We'll always be able to run any software we want even if the hardware is not as good as proprietary designs.

</comment><comment><USER84> If you wanted to do something with a hardware root-of-trust, would the GDSII leak needed secrets (i.e. any private keys could be extracted by looking at what you're required to open up), or is that done in some special post-fab way?

<comment> yjftsjthsd-h Could you burn in the private key using fuses?

<comment><USER58> Take a look at the Google Titan chip slides for an idea of how to implement this: [https://www.hotchips.org/hc30/1conf/1.14_Google_Titan_Google...](https://www.hotchips.org/hc30/1conf/1.14_Google_Titan_GoogleFinalTitanHotChips2018.pdf) Video: [https://youtu.be/ve_64dbM4YI?t=3089](https://youtu.be/ve_64dbM4YI?t=3089)

Specifially, slides 35-40. You burn a feature fuse to unlock manufacturing test features. The device is personalized with a serial number + told to generate private key + record stored in database. Then, the key is locked in by burning a second feature fuse that disables any future writing to those segments.

</comment></comment></comment><comment> ur-whale This is fantastic, for many reasons, but the two that come immediately to mind are:

        - amazingly good for security.
        - finally the public at large will get to understand *in details* how an ASIC is designed.

<comment><USER85> Meta: please don't use preformatted text for lists. It makes reading much harder, especially on narrower displays. Just put a blank line between each item, treat each as a paragraph.

<comment> ur-whale Thank you for listing your personal preferences, but I also happen to have mine.

</comment></comment></comment><comment><USER86> Anyone have a sense of how easy it is to audit/verify devices made with this process? I would love to see some properly trustworthy chips for end-to-end encryption come out of this.

</comment><comment><USER87> Hmm, sounds like Google is hunting for chip design talents. :) We will fab your design and if it looks good, come work for us. :P

</comment><comment><USER88> The difference is one is pure public good but hardware is not that pure. And hence you have other concerns and other means.

</comment><comment><USER89> Quote: " All open source chip designs qualify, no further strings attached!"

There is no such thing as free lunch! I really wonder what is Google's game plan with this. 20 years ago they started to made maps + email + office +... free for everybody, but the game plan was they gathered everything about everybody, so now we know. Sorry Google, I don't trust you one bit anymore.

</comment><comment><USER90> Fantastic Google! Dream come true

</comment><comment><USER91> It would be nice to get all of the HDL used by the HPSDR project fabbed this way.

</comment><comment><USER92> Would this make it possible to reproduce some historic-but-rare chips like the 4004?

<comment><USER93> This is a 0.13µm CMOS process while the 4004 was made using a 10µm PMOS technology. So the electrical characteristics would not be the same. If you don't care about that then the answer is "yes".

An attempt to do something like this would have a Z80, a 6502 and a 68000 in a single chip (none of them are rare, however):

[https://www.crowdsupply.com/chips4makers/retro- uc](https://www.crowdsupply.com/chips4makers/retro-uc)

<comment><USER94> Well, the 6502 was famously NMOS which isn't CMOS either. Though wikipedia tells me there is a '65C02' which is a CMOS version of the 6502.

</comment></comment></comment><comment><USER95> Are there any Risc-V designs that would plug in to this?

<comment><USER62> Yes, there are lots of open-source RISC-V cores. Tim Edwards of efabless has another talk about creating a RISC-V based ASIC SOC: [https://www.youtube.com/watch?v=EsEcLZc0RO8](https://www.youtube.com/watch?v=EsEcLZc0RO8) based on PicoRV: [https://github.com/cliffordwolf/picorv32](https://github.com/cliffordwolf/picorv32). PicoRV is part of the efabless IP offerings. The chips will have a PicoRV harness on them.

<comment><USER95> Thanks!

</comment></comment></comment><comment><USER96> What are the chances that google will add their own hidden or proprietary circuitry to any open-source chips? They'll add all sorts of "Security" and "Tracking" features..

<comment><USER22> If you hand them GDSII then fiddling with it is very time-consuming and difficult, but can be spotted by looking at the resulting chip under a microscope.

(Not entirely simple at 130nm as this is shorter than the wavelength of visible light!)

<comment><USER10> You don't need to look at the smallest features of a transistor to notice that the chip has 30% more transistors than your original design.

<comment><USER70> Also, adding something like that would be an incredible amount of work. Basically you would have to totally re-do the layout even if you're just adding a macro somewhere and totally re-design it if you're not going to end up causing a drastic decrease in max clock rate. That's for an management engine or tracking style thing. A backdoor that makes #5F0A40A3 equal to every other number for password bypass wouldn't be that invasive and might only slow things down by a little bit so I guess that's a possibility if a certain design becomes really popular?</comment></comment></comment></comment>


Take a Tour of the Millenium Falcon with WebGL - <AUTHOR> https://spaces.archilogic.com/3d/archilogic/4yzpzool?modelResourceId=5d2038e3-dfe3-411d-b489-f1f85f61ab30&mode=view <comment><USER2> That was incredibly cool. I would really like to see this running on an engine with a bit more power, and some very basic FPS-like features. I mean very basic. Imagine that same walkthrough tour, but with collision, interaction with doors and ladders, annnnnd maybe some blinky lights on the computers. That said, as it is it's amazing!</comment>


Cross Domain Authentication Bypass in Office 365 - <AUTHOR> http://www.economyofmechanism.com/office365-authbypass.html <comment><USER2> Out of all the service providers I've worked with, microsoft's been the worst. Few years ago I was amazed that I could literally brute force an o365 admin account via powershell and it would never lock the account and of course there was no way to enable 2fa for the account...

</comment><comment><USER3> This is impressively bad. Literally Office365 let you simply claim to be anyone you wanted to via SAML. They didn't bother checking the user was actually in the same domain as the SAML Identity Provider. I can't get over how insanely incompetent that is...

<comment><AUTHOR> I guess the only saving grace is that they fixed it in 7 hours, but again it shouldn't have been an issues in the first place :/</comment></comment>


At Amazon, Employees Treat the Bathroom as an Extension of the Office - <AUTHOR> http://motherboard.vice.com/read/at-amazon-employees-treat-the-bathroom-as-an-extension-of-the-office <comment> rm_-rf_slash My roommate works at a call center. There is a rule there that you can't go to the bathroom within 15 minutes of clocking in. He complains of the arbitrary control of people's bladders yet in the same breath will complain of people who go straight in at 9:15. To me that's where work culture gets despicable: make people look down at people who don't approve of rules they themselves don't like, and you've outsourced shame from managers to the employees themselves.

<comment><USER2> >outsourced shame from managers to the employees themselves

this is one of the major selling points of management.

McD has a policy that the managers have to tell the employees what to do. Store managers don't. Which creates an inevitable 'but Doug didn't...' and then a 'I know but, ...' dialog

having non-shitty store managers would solve this.

</comment></comment><comment><USER3> I'm sympathetic to the difficulty of Amazon's culture, but this person seems to place more concerns on bathroom culture than most. Yes, I prefer to be silent in the bathroom, but sometimes people talk and then I will respond. I've talked work in the bathroom before, including to a supervisor. Not everyone has the same expectations and in a large group it's inevitable that some folks are going to want to use coincidental meetings in the bathroom to have impromptu conversations about work or other topics. The idea of "hunting for the perfect bathroom" strikes me as a bit of an overreaction to such a situation.

</comment><comment><USER4> "I regularly saw people bring their laptops into the bathroom, where they would sit on the toilet and write code"

I would need some corroboration in order to believe this bit. The rest of the behavior listed I've sadly seen in other companies, though I've fortunately never been somewhere it was a cultural constant, as opposed to the lack of tact of some individuals and double-digit tendency to hire folks who lacked tact.

<comment><USER5> Many years ago when I started in corporate code-dronery I was at our US headquarters for the first time when nature called.

At first I was merely amused at the diminutive vertical dimensions of US toilet-stall doors ( they have a much larger gap at the bottom than Euroloos ).

But then I was stunned to pass one stall where there was a pile of Z-fold green-bar printer paper sitting on the floor, with the occupant slowly raising the pages in sequence and presumably reading the code...

We didn't have many laptops back then :)

</comment></comment><comment><USER6> I interned within AWS for a few month and never saw anyone carrying their laptops into bathrooms. Although I do remember regularly doing a linearly search of adjacent floor's bathrooms in order to find a seat.

</comment><comment><USER7> I worked support for a major shipping company and was told I could not use the restroom without answering the phone while I was in there. I refused and nothing really ever happened.

</comment><comment><USER8> It's called multi-tasking:

[http://dilbert.com/strip/2012-10-26](http://dilbert.com/strip/2012-10-26)

</comment><comment><USER9> Seems a little uptight - who hasn't enjoyed a bit of toilet typing now and then?

</comment><comment><USER10> The horror! The hygiene!</comment>


Data Engineering Cookbook - <AUTHOR> https://github.com/andkret/Cookbook <comment><USER2> Excessive self-promotion aside, I think high level documents like this are more important than people give them credit for.

Computer science is: 1) Daunting to beginners 2) Changing constantly

It is absolutely a field where people suffer from "I don't know what I don't know". 100-ft overviews of best practices and new buzz-words are refreshing, in my opinion.

The criticisms I have of this document are all preference. I do not want to watch the podcasts or youtube videos, especially if I just want a high level overview of something. A ctrl-f of 'andreaskayy' returns 12 results. This guy's self promotions is everywhere, which is fine for some people, but it makes me think I'm getting 1 man's opinion on everything, and not an unbiased explanation of different technologies/methods.

<comment><USER3> >Daunting to beginners

I agree it is. But just I took a quick look at the book, while I understand the book is not done yet, looking at the table of contents, I doubt this would help. Like, do you have to cover kerberos, IP Subnetting, OSI IP model, Agile, git, REST API, docker, and many more in a _single book_ about "data engineering"? If anything, it would confuse beginners even more. Its like the author tried to cram as many buzzwords as possible into a single book.

<comment><USER2> I agree this author seems more interested in self-promotion than anything else.

However, I don't think the purpose of this book is to cover these subjects in their entirety. Most of the time, with books like these, I would just like to see definitions, use cases, why it's used, maybe even what it replaced in the space it exists in. Materials like this aren't meant to make you an expert, they are just meant to show you what's out there, why it's out there, and (maybe) what was out there before. They give you context with which to google things.

Either way, everyone expects something different from educational materials. I personally would not use this book, but I get the idea he was going for.

</comment></comment></comment><comment><USER4> Looks like a great outline for an important topic! A few thoughts:

1\. Given the title, I was expecting a more traditional Cookbook style book. I.e., "How do I..." followed by one or more recipes to answer the question.

2\. The blueprint on page 39 is a good start: it includes the 4 main processes for data engineering. However, Display is only one use case. Training models, for example, is another. It also ignores real-time vs. batch processing. This comes up later in the book, but could be diagrammed more clearly. There are a lot of recipes for the overall architecture, and for each subprocess.

<comment><USER5> This is a good example of respectful criticism. I wish others would follow your example.

</comment></comment><comment><USER6> How about calling it "Book of mostly empty chapters on various topics about software engineering with slight emphasis on data engineering"?

<comment><USER7> How about constructive criticism...

<comment> squeaky-clean Have you looked through the PDF? Many sections are entirely blank except a section header. Many are just links to a blog post or podcast.

Data Warehouse vs Data Lake chapter is a single podcast link. The Hadoop chapter is 5 pages, mostly used by large diagrams and the docker chapter is less than 4 pages with half of the sections empty except a heading. The REST API chapter is less than 2 pages with a blank section headed OAuth Security.

Data Visualization is entirely blank. The database chapter is mostly empty except for text about HDFS, and just links on MongoDB, ElasticSearch and InfluxDB. Apache Kafka gets its own mostly blank chapter.

Most of the beginning chapters seem unrelated to data engineering. 3) Learn to Code. 4) Getting Started with Git. 5) Agile Development. 6) Learn how a computer works (section 1 is subtitled "CPU,RAM,GPU,HDD" but the chapter is empty). 7) Computer Networking - Data Transmission.

<comment><USER5> Where is your finished data engineering book? I would like to read it.

How do you think a book gets written? Obviously you don't think that someone sits down, puts finger to keyboard, and then a book bursts into fruition. This is a work-in-progress kindly made freely available. Is it really fair to criticize the author for not having finished it yet?

<comment> squeaky-clean > Where is your finished data engineering book? I would like to read it.

So I need to have written a book to be able to download a PDF and see 85/100 pages are blank? I work as a data engineer and can tell you 50% of these chapter topics are not directly related to data engineering.

There are no chapters in this book even close to 10% finished. If you want a book recommendation I'm seconding the suggestion in this thread of Designing Data-Intensive Applications. I have a copy 3 feet from me at the moment.

> This is a work-in-progress kindly made freely available. Is it really fair > to criticize the author for not having finished it yet?

Please look through the PDF. This isn't just not done. This is not ready to share with anyone publicly. There is no useful information in this. There are probably under 20 paragraphs of original text.

> Is it really fair to criticize the author for not having finished it yet?

No, but I'm criticizing the fact that it's posted[0]. Not that they're working on something.

I don't see the author here in this thread so my warning is to other readers. Just move on unless you're a book publisher looking for an author to pick up.

The only real criticism anyone could offer about this would be about the chapter structure, because that's all that exists. I would recommend they drop all the chapters that are a CS101 equivalent. There's no need to explain git or the OSI model or grep.

[0] edit, I want to clarify I mean just posted and dumped. If the author were here for questions or feedback I would feel differently. But with just this link as-is, there is no point in sharing.

<comment><USER8> > So I need to have written a book to be able to download a PDF and see 85/100 > pages are blank? I work as a data engineer and can tell you 50% of these > chapter topics are not directly related to data engineering.

Also data engineering focused, agreed completely.

</comment></comment></comment></comment></comment></comment><comment><USER9> This is good.

Although when I think of a cookbook, I'm mostly interested in some re-usable snippets of codes that can be used again and again. A good example would be Chris Albon's site [https://chrisalbon.com](https://chrisalbon.com)

For eg: \- a recipe for splitting comma separated values in a column into multiple rows or \- a data cleaning recipe that removes all unwanted spaces/trailing newlines/punctuations

I've searched but never come across a compilation of such re-usable code snippets anywhere. Would be glad if anyone has any resources like this.

</comment><comment><USER10> This looks like blogspam or collecting a bunch of blogspam articles and turning it into a book.

</comment><comment><USER11> As a data engineer, the level of self promotion this guy is going through is insane. Good for him, if this catches on though, I hope I dont have to make myself into a data engineering celebrity/ thought leader in order to get jobs in the future.

</comment><comment><USER12> Anyone using non-JVM stuff in general? Nothing against the giant ecosystem around Hadoop/spark etc.

I am currently using one Python process with Prefect for DAGs ([https://docs.prefect.io/guide/](https://docs.prefect.io/guide/)), custom API queries and Elasticsearch indexing code in a batch processing style and it seems to be going fine to ingest a 2TB dataset with the ability to generate rich errors, retry/resume etc.

Besides maybe job listings, why would a real "plumber" who came from python and js NEED to dive into the whole Apache ecosystem?

</comment><comment><USER13> Is there an equivalent job title for Data Engineer without the word "engineer"? As a data engineer without an engineering degree I don't like having that word in my job title.

<comment><USER14> ETL developer? Business Intelligence Consultant?

<comment><USER15> "ETL developer" was (and still is) the industry term for more than 10 years before this new wave of buzzword spam came along (i.e. when "data science" was "data mining"). Most of these roles focused on using low-code tools like SSIS to build business-focused data transformation workflows faster than with any code intensive approach (e.g. Hadoop ecosystem and derivatives).

Business intelligence consultant/developer was a blanket term used either for 1) people that can model and translate business requirements into data platforms/components; 2) poorly targeted recruiting; 3) more rarely, to describe people that work both in 'frontend' (reporting and dashboarding using tools like PowerBI, who are "data analysts" in newspeak) and 'backend' (ETL developer).

"Data Engineer" today is, sadly, too often synonym with "solving solved problems using an unnecessarily complex approach and toolkit"; and then there are the cases where the volume or complexity of the data actually justifies the cost of using "big data" platforms. Not to sound harsh; the article discussed here illustrates my point using "simple" unix tools: [https://news.ycombinator.com/item?id=14401399](https://news.ycombinator.com/item?id=14401399)

</comment></comment></comment><comment><USER16> While respecting the author's good intentions to share knowledge, I think that calling this set of (shallow) notes a "book" is an insult to all decent comprehensive books and their authors.

</comment><comment><USER17> What is the benefit of making something like this into a PDF instead of a website?

I don't think I ever see a PDF link online and think, "yes, this is the ideal format for ingesting this information."

</comment><comment><USER18> Good summary of he current technologies on the market right now, Maybe adding a few ETL tools will be great, they're still important :)

I liked case of studies compilation thumps up.

</comment><comment><USER19> Why is it useful to separate "data" from software engineering in general? What are some examples of programs that do not operate on data?

<comment> squeaky-clean The difference is where the difficulty of your problem lies. I work with serving and reporting ads, so most of our actual logic is simple. Glorified ETL work and fancy caching layer really.

The problem comes about that we can have peaks of 20k reads and 20k writes per second with strict guarantees on response time and data consistency. All at the same time needing to be kept consistent across multiple datacenters in several regions.

Your typical application won't hold up in that environment or can become extremely difficult to maintain. And I've met people at conferences who would say my use case still isn't "big data" and is pennies compared to their data streams. It really does become a class of algorithms and solutions on its own, just dealing with your real-world ability to manage that much data.

<comment><USER19> This doesn't ring true with how I've seen the terms used.

Highly scalable distributed systems are the bread and butter of backend engineering in modern tech companies. Even specialists working on storage layer tech in particular are not called "data engineers," just backend engineers, although with more systems/infrastructure focus than others.

People with the title "data engineer" at my company pretty much do ETL pipelines on Hadoop. I've done some ETL pipelines on Hadoop; seems like a tool that should be in the portfolio of any SWE. But when you give a data engineer a problem, they are _sure_ to suggest an ETL pipeline in Hadoop; I have even seen them build RPC interfaces out of INSERT statements. Whereas a SWE is looking at a broader suite of options, and probably defaulting to backend services / OLTP databases. Hence my confusion. Maybe our use of the term is anachronistic? Or maybe they just know a bunch of HiveQL or pipeline design patterns that are too complex to fit into the heads of people who can also write services?

<comment> squeaky-clean I would say these terms are not exclusive of each other. Like Parallelogram, square, rectangle. All 3 of your descriptions would be different types of Backend Engineers to me, with focuses on systems or data (or both) or something else. Sometimes the storage team is focused on generically keeping storage working while another team actually works on the "big data" applications, but often these teams design and plan very hand-in-hand.

> But when you give a data engineer a problem, they are sure to suggest an ETL > pipeline in Hadoop

Maybe someone who sees Hadoop as their only hammer but IMO a "good" data engineer would go

"How much data? 300MB? And you need to run this how often? Once? You're sure just once? Like really sure? Okay here is a bash script."

</comment></comment></comment></comment><comment><USER20> I see these kinds of books as good points for reference. These days I like video formats that reference the theory and show real world examples.

</comment><comment><USER21> Tempted to say how harmful things and advice is in here.

</comment><comment><USER22> For anyone eager to read something now, Designing Data-Intensive Applications [1] is an excellent and completed book that covers nearly all of the same material with significant depth.

[1] [https://www.amazon.com/Designing-Data-Intensive- Applications...](https://www.amazon.com/Designing-Data-Intensive-Applications- Reliable-Maintainable/dp/1449373321)

<comment><USER23> Why is this book considered to be so good? I started it because it's been recommended on HN so much and I gave it up rather quickly because it was really dry and not all that focused on practical applications. Should I give it another go?

<comment><USER3> I highly recommend it. It does a very good job at explaining the "magic" behind all the data storage techniques, giving you a very good fundamentals and intuition of why each of them are good for certain kind of problems.

After reading the book, googling for something like "mongodb v.s. cassandra" would start to feel as silly as googling for something like "javascript v.s. css" as you start to understand the fundamental differences between them.

No more need to hope the vague Medium post you found while trying to decide which DB to use would match your use case closely enough.

<comment><USER24> I've read the book too and didn't feel like it covered much that isn't covered by an undergraduate CS curriculum of databases and distributed systems. Perhaps the book appeals to developers without a formal education in computer science?

<comment><USER25> Some senior engineers have been in the game long enough that they could have a reputable cs degree without classes in DB or distributed systems. Now it seems less likely, but after teaching Java, C++, C, the other topics were electives.

<comment><USER26> This. Data engineering has ramped up significantly and if you want senior people you'll quickly run out of people who've been exclusively doing "big data" for 5+ years.

So your options are either senior software engineers who have done some data work (that's how I got to be a Data Engineer) or people who've been doing analytical data work (either in the traditional warehousing space or via science/insurance/finance type spaces) that are semi-technical but have no formal engineering background.

The former are people who went to college in the late 90s/early 2000s (like myself) when things were different. The latter need to hyperfocus on coming up to speed in engineering.

I reviewed this guide a couple months ago for my employer to consider as the basis of an internal bootcamp, and I'd note that it's perfect for the audiences I mentioned. Also, even for people with more up to date academic experience, note that the transactional database schemas that software normally deals with often look wildly different than analytical structures.

</comment></comment></comment></comment></comment></comment><comment><USER27> What a weird title for a book about data science.

I'm not a fan of the marketing gravy people dump on everything. The future will devolve to unhelpful titles like - "How to do Data F __king science "

<comment><USER28> Data engineering is not data science. Data engineers deliver the data for data scientists, data scientists use the data in models.</comment></comment>