craigjb

I think the embedded wafer level or "panel" level packaging technologies are the mid-ground. These technologies don't use expensive silicon, and instead surround the die with cheaper epoxy. Then the interconnects are built on top of that, and can connect multiple die together. Yield and interconnect pitch are the big issues here though, and that's why I think you're right, that we will see SoCs or mobile systems first, not whole motherboards.

With that said, some of these technologies can have a layer of surface mount pads on top. So you have a substrate of epoxy with all your chips and interconnects embedded in it, and then surface mount parts on top. For example, passives, connectors, etc. It would look almost like a motherboard, but with all the chips inside. Of course, for cost and yield reasons, this will be for mobile devices only at first.

It's been fun to see Dr. Subu present this concept and prototypes at several conferences, and the level of integration possible is absolutely insane. I think the industry is definitely moving toward chiplets, such as the latest AMD release.

I definitely think we will see more chiplets and more standardization on interfaces between chiplets. The focus will be on how to minimize energy per bit transferred (a big topic in Subu's talks) and how to minimize the die area used for inter-chiplet communication. In monolithic silicon, you don't have to think about die area, since your parallel wires between sections might just need a register or two along the way. With chiplets, you typically can't run wires at that density yet, so you still have some serialization/deserialization hardware. But, since it's not crossing multiple high inductance solder balls and PCB traces, you can get away with less. Hopefully also you can get away without area-intensive resynchronization, PLLS, etc.

I think it will definitely be awhile before this kind of integration is used outside of niche cases though. The costs are just insane. You have to pre-test all manufactured chiplets before integration, and that test engineering is nothing to sneeze at. If you don't then you have all kinds of commercials issues about who is liable for the $500k prototype one bad chip broke.

On the bright side, I see the chiplet approach benefitting other integration technologies. For example, wafer level and panel level embedded packaging technologies can be used for 1-2um interconnects now. You won't get a wafer sized system out of it with any kind of yield, but it's probably the direction mobile chips and wearables will go.

Anyway, disorganized info-dump over.

I’ve started using SpinalHDL, https://github.com/SpinalHDL/SpinalHDL. It’s a Scala DSL that spits out Verilog or VHDL for traditional synthesis tools. But, unlike Chisel or MyHDL, in my opinion it’s a great experience. And, now it has seamless integration with Verilator for simulation, and the open-source Verilator project is very capable—they claim it beats commercial simulators: https://www.veripool.org/wiki/verilator. Since Scala is quite a bit faster than Python, the simulations run much faster than something like Cocotb too!

I have my hobby project in SpinalHDL up at https://craigjb.com

Edit: also, GTKWave is pretty good! It’s a simple and straightforward waveform viewer that works on all platforms.

This is awesome!

I’ve been using Python to generate OpenSCAD scripts, and then a half-finished Python binding for OpenSCAD. This framework uses the natural parametric CAD modeling primitives, like the workplane. I never got used to the OpenSCAD way.

I’m switching my stack over to this today.

That is called an anechoic chamber [1]. Basically, the walls absorb all the outward radiation from the device so the test instruments do not have to sort out reflected waves. It mimics the device being outside with infinite space in all directions.

[1] https://en.wikipedia.org/wiki/Anechoic_chamber

It's actually incredibly rare in consumer products. Especially since an 8-bit micro controller can cost much much less in bulk today.

Edit: and 8-bit micros come much cheaper than Digikey when you buy consumer product volumes directly.

If you physically have the phone, de-soldering and moving the flash memory to a custom board for modification is an option.

Additionally, the instruction set is not virtualized because of compatibility. Compatibility is a nice side effect though, so software from even five years ago works just as expected (not all software can be recompiled, and could you imagine commercially supporting that many variants--this way Intel shoulders that burden). And, backward compatibility is a tiny fraction of the control unit silicon area. It has zero performance cost. Zero. Intel is scraping for more (not less) things to add to silicon to improve performance (video encode/decode, GPU, memory controller, PCI).

The virtualized instruction set enables the performance gains by executing portions of instructions in parallel, re-ordering to avoid pipeline stalls, better branch prediction, execution shortcuts depending on operanda, etc. without compiler support. RISC architectures like ARM do this as well. On a modern Cortex part with multiple execution units, the processor is not a textbook pipelined RISC processor like this community seems to yearn for. So if you look at machine code for some reason, yes the instruction set is simple, but it's still a facade over complexity.

I don't understand the constant cry that processors are complex. To gain performance against the frequency limit, complexity increased. This happens with software all the time.

Also, for those that want direct control over all the elements of the processor, go buy an Itanium... oh wait... no one did.

What kind of artist work can you practically distribute between multiple people and merge? Most things like this are broken into pieces and each piece is tracked separately and assembled later.

I think this is a big mistake programmers make when trying to create VCS for other industries. A lot other fields with binary files don't care about merge as much. Like electronic design automation: track every part's history and even every module on a board or die layout. But, practically it's difficult to have two people productivly work on the same small piece simultaneously.

[edit] I also think a bunch of the reasons programmers require merge are because code is organized into files. Organization into files is arbitrary and often doesn't correlate particularly well with logical structure.

It's interesting how the article you linked mentions cheap capital has enabled consolidation. I was always under the impression that cheap capital would spawn a plethora of startups and new differentiation. I guess this system has two stable states...

Also, now more than ever, startups can enter the fabless market since TSMC and other foundries are open to even small customers. I think we may just be seeing a slowdown on new entries because the engineering cost, not just tool or IP cost, is monstrous for new chips (i.e. innovative features, not just coupling IP cores). Now I want to go research what portions of IC designs require the most time now. My hunches: formal requirements definition and analog design.

Yah, I understand it's not always an option.

If the data size is limiting though, you can embed a Redis key or Hadoop FS reference into the message, rather than breaking your message system with massive data.

Then, you can have the storage system listen for completion messages, and cleanup appropriately. Or, like we did, just shove out old data LRU style. This way some history is always available for debugging.

If LIDAR could sweep materials with varying frequency and measure the reflection vs. absorption across a band, you could get pretty decent material identification.

It certainly wasn't the only digression either. I think you sign up for this when you pick up a Stephenson book. It's part of his intellectual style.

It always makes me smile when I hear the term "8-bit" used to describe art. The strict hardware and software limitations of early computers spawned a complete visual aesthetic!

It seems like the most immediate way to meet low-cost but high volume is through in vitro meat culture [1]. It will likely take awhile to clear the health and GMO-fear hurdles, but it's coming. Especially places where raising livestock in traditional ways drastically harms the environment (mass pig dumps in rivers, or limited land resources in island nations).

Decentralizing growth of meat and other food, as mentioned in the article, is probably a good thing too, just like decentralizing internet services or electrical generation. However, I don't completely buy the 'decentralize everything' argument that has become popular lately. While it brings us closer to the libertarian dream, some advantages are lost as well. Also, I'm not convinced the innovations that enable decentralized agricultural or electrical generation don't have the same positive impact on the centralized version of the system. Except, in the centralized system you benefit from economies of scale. We'll probably end up with some kind hybrid system.

[1] http://new-harvest.org/wp-content/uploads/2013/03/post_2012_...

In a real-time system at work, we originally used Redis as a locking mechanism to avoid resource contention. However, it turned out the better long-term solution was to better use our reliable message broker and make tasks finer grain.

So, rather than lock large resources, we would break the processing into tiny tasks, each completely contained in a message object. Each message specified a new message to launch on completion. This way the messaging protocol is preventing resource contention rather than a lock.

[edit] The context involved some licenses software to which we only owned several instances. The original approach would attempt to grab a lock and run the batch. The final approach just created a queue for jobs and one consumer for each available license. Now, none of our compute is spent waiting on locks either.

Neither tool has a good way to do matched-impedance traces. Both rely on scripting or a plugin to do this, and the feedback is not real-time nor can you make design rules on matched nets.

Also, neither tool integrates smoothly with simulation software yet. One of my pet ideas for a while has been to integrate EEScheme, the KiCad schematic capture tool, with ngspice, an open-source spice engine. The integration would include things like probing voltages and currents in the schematic to make graphs appear. Or, associating spice models with library components.

However, this would also require some way to create "simulation-only" versions of schematics. Typically, you only want to simulate a sub-section of the schematic at once. No other schematic tool, even the big ones (Cadence, Mentor), does this very well yet.

Wouldn't some of what this article describes happen simply because of specialization?

As the knowledge in a field broadens, no one person, less so a person outside the field, can read and keep up with the publications. Therefore a single field can have 40 journals. And, some topics really are complex enough that they cannot be explained in an "easy-to-read" format because they require an enormous amount of context.

Not an ignorant question at all! This is actually a subtle problem in switching regulator design: high duty-cycle operation and efficiency. Basically, if you input a voltage very close to the output voltage, the switch part of a switching regulator must be always or near always closed. And, any inefficiencies such as voltage drops in the power path are visible in the output.

Being Apple, I'm sure it has 100% duty cycle operation. However, it's likely not optimized for hat (uncommon case).

[edit] as the other comment points out, my comments forgot about the PFC circuit. But on switchers without this, near output voltage input is possible.

I would guess even less than 24. Today you can write your structural Verilog implementation, run an automatic mapping to a PDK standard cell library, and simulate to verify. The hardest part might be floor planning for something like that today. The placement and routing can all be automagical, and you won't have any timing closure issues at these speeds. I'd guess a single student could do it if sufficiently motivated. And, with CMP or MOSIS you could have it manufactured on a 350nm CMOS process by AMS for $2200 (20-25 pcs).

We have a choice in what system we use for managing natural resources and preventing large-scale environmental problems. Just because capitalism has been efficient so far for economic growth does not mean the current implementation is perfect for everything else.

Also, there's nothing natural about free markets and capitalism. We (humans) made it up! We're free to change the rules in order to make life and the world better.

It's too bad ultrasonic transducers this size (~16mm) are too large to make a linear phased array with high angle range and low grating lobes [1]. This means that a different object or particle might be manipulated simultaneously with the target object.

I've been looking into using a genetic search or just brute force random search to create a randomized transducer pattern that minimizes grating lobes though. You can purchase these transducers in bulk for super low prices though! So anyway to build a capable phased array with them would be awesome.

[1] http://www.microwaves101.com/encyclopedias/grating-lobes

Sample size of 76....

How is this not a troll article....

An example use case: shuffle terabytes of plant genomic data to a TACC supercomputer, crunch data, and shuffle gigabytes of results back.

There is a whole group of tools for transfers when your data is big: http://moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Gallium-Arsenisde has a high switching speed because of the higher carrier mobility, but the higher frequency applications it is used in dissipate high power.

This article's transistors will not likely have a high switching speed, just high enough for switching power converters (100kHZ-few MHZ). The important feature of GaN according to the article is that you generate 1/10 the waste heat from current just flowing through the switch.

Power transistors don't perfectly 'turn on' like an ideal switch. They have a resistance to the switched path on the order of milliohms called Rds (resistance source to drain). And, heat dissipated from that is ~ I^2 x Rds.

This AT&T Bell Labs documentary about the anti-ballistic missile defense program is eye-opening. The program roots are in the Nike anti-bomber defense program. The complexity of radar and digital signal processing technology in the 1960-70s is incredible (they even had stylus touch-screen interfaces).

https://www.youtube.com/watch?v=ARx2-wRn9-Y

I agree so far as some progressive activists are fighting against being offended rather than fighting for rights. No person has a right not to be offended, and not every creative piece should be required to target all demographics.

Yes, laws exist about harassment and should be enforced since that can effectively violate rights. But, I have no right to require the content from artists, TV producers, movie producers, and game companies meets my word view. I can simply not buy the game or movie, but other people have the right to do so if they wish. And, I cannot harass the producers about the content that doesn't meet my world view to an extent that violates their rights--i.e. several internet catastrophes that resulted in lost jobs and people scared to leave their home due to death threats.

It doesn't appear like the researchers have access to the car's firmware, so how can they guarantee their code will not have other unpredictable effects? Automotive parts and firmware are put through endless testing before being allowed onto public roads. Why should I have to be at an unnecessarily increased risk of an accident when this could've been done on a track.