This seems like a much more advanced version of EOMA68, a compute card project re-using old PCMCIA connectors.
I feel like USB-C gives much more flexibility: it has a well-defined configuration enumeration protocol that's already supported everywhere. There's a lot more options for extensibility and future-proofing with USB-C.
With the onboard storage this is one step closer to my dream: the ability to plug a phone's compute module into a desktop to give me access to a more powerful GPU, extra storage, etc.
My big question: will this card format be an open standard, or will Intel be locking it down?
I like the idea of extensible and replaceable computers: I would be much less concerned about my fridge being an IOT device if the IOT component was an easily upgraded and replaced Intel atom or Qualcomm Snapdragon compute card.
In terms of process migration I still think Google has missed a trick by not marrying Android and light-weight containers. If I could flick my wrist to send a phone process to my Chromebook, Android tablet, Andromeda device or smart TV life would be pretty interesting. Maybe one gesture for screen mirroring and another to move rather than mirror or copy the process.
This would also open up new channels for malware sure but also cool things like trusted processes / data for authentication. You have an invitation to my party, you say? Dock it with my Google Home device which signed your invitation to prove it, then...
We designed an architecture for replaceability during the summer for our UAV project. Our current architecture has been based on the Zynq-7000 which is a two ARM-core + FPGA SoC. Here we had custom logic for doing things such as controlling signals to the servos in the FPGA and then software drivers communicating with the FPGA through memory maps. This resulted in a tight coupling between the drivers on the compute platform and the IO hardware.
Our next hardware generation will have a dedicated FPGA handling the communication with the GPS, IMU, servos. The compute platform will communicate with the FPGA over Ethernet. This means that all hardware drivers can be written against a network based interface, resulting in a loose coupling between the compute and IO. This means that both the IO hardware and compute hardware can be replaced individually without breaking the setup, and without having to rewrite any drivers. It also results in high transparency for debugging IO, with the possibility of easily recording and playing back a scenario. You can also test the full flight software on a developer's desktop machine during development without the embedded compute platform.
As embedded compute platforms get better all the time, while the IO stays more stable, this will make it easy to replace the compute every 2-3 years.
This is essentially what React Native has done for UI <~> Logic communication, allowing the latter (think iOS/Androind/Apple tv os/macOS etc.) to be replaced by any compute platform - even Compute Card in theory I think.
You're applying the same mental model to hardware which can be seen in the similarity of tools that can be enabled on top of such abstraction. Way to go!
The flexibility that emerges from decoupling our software and hardware solutions is a [recent] trend that will only gain on traction as more people become aware of it's implications to how we create solutions to technological problems.
How can we evangelize this better? From my experience it's complicated to communicate this idea well.
not sure if true, may be recency bias or the fact that I'm still young and inexperienced in many ways and lack historical background knowledge in tech
Out of curiosity, why are you going to communicate to the FPGA over Ethernet vs PCIe or SPI or USB? It seems like you'd have to do a lot of high level processing on the FPGA to get it behave nicely on an Ethernet network.
With UDP and custom FPGA IP for handling the packets the processing works fine. Network behavior is made easier as the IO board will mostly be used in a dedicated point-to-point Ethernet connection.
Our opinion is that Ethernet is easier to analyze using tools such as Wireshark, in addition to being easier to run in a cable between different PCAs. It also allows the IO board to be easily networked for communicating with development tools to reprogram the FPGA memory, debug issues, do testing from a developer machine etc without concern for driver issues on various host operating systems.
Another of their summer projects this year was the "CoastalShark" autonomous jetski where they constructed a sophisticated autonomous surface vessel. For their demonstration they used it to pull a guy on water skis:
I had the same idea about the phone years ago. I don't know why we can't just take our iPhone or (more likely) Android, plug it into a docking station and use that at work as a desktop, pick it up and use it as a smartphone, or dock it to something at home.
I have a lumia 950 with continuum, and it does this even without the dock. You wirelessly project to any w10 device, and it's like plugging in a different compute engine. You get a desktop, the start menu is your phone's home screen, all apps adapt to the bigger screen, and you can multitask. You use the keyboard and mouse of the PC.
It has two major downsides right now. There's no win32 support, so there's not much to run on the desktop, which MS is going to address by bringing x86 emulation to arm. Secondly, the hardware isn't quite powerful enough, which limits the max. resolution and the ability to multitask, which the new qualcomm 835 based phones with 4+ gb of ram should address.
It is impressive, but I haven't found a use for it. After all, when you have a laptop, why use it to run apps from your phone?
As mobile chips continue to improve, emulating x86 becomes a viable way of tapping into the huge Windows ecosystem of applications when not running on battery power.
I think this is Microsoft's last shot of becoming relevant in the mobile space.
Bring your own screen, keyboard, and power supply. Continuum is a weird beast, I'm not exactly sure who would get something out of it even if app support was good.
If the phone hardware was more powerful, and the win32 app support was there, it could replace your PC. You'd have a USB-C dock, with keyboard, screen and mouse, into which you plug your phone. Your phone is your PC, and when you leave you take it with you along with all your files and all your software.
You could combine it with something like a nexdock to also turn it into a laptop. Would be cheaper than getting a phone, and a desktop pc and a laptop, and it would avoid all those nasty issues with keeping devices in sync.
The qualcomm 820 already performed at core m levels, and the 835 is 25% faster, so it should be fine if paired with enough ram and storage.
I recall Nokia demoing something like that with their later Symbian phones. Video out to a TV, bluetooth keyboard and mouse, and you got the phone UI up on the TV and could operate it much like you operated a desktop. And you could still see and interact with the UI on the phone screen.
Android was out at that point, but could barely do video out by blanking the phone screen. Forget about operating it via other means. And i don't think iPhone was doing much better.
One reason why i feel the focus on those platforms reset mobile device progress by a decade.
Speaking to retailers recently, demand is for office apps usable on touch. i.e. if it can possibly done without a keyboard, people will do that. From listening to users, they will moan and complain about touch "productivity" apps... but will choose it.
Personally, I switched entirely to a phone a year ago... though with a bluetooth keyboard.
Unless I missed it, I don't see any info on how it boots. Does it have UEFI? Is it a standard PC?
Where Intel can win is if a standard x86 Linux distribution could boot off of this with little modification. Right now in the ARM world, unless your device supports device tree configuration, kernels are highly customized per device.
I'm starting to wonder if next-generation blade systems might not just have a bunch of USB-C connectors to act as a backplane. They provide power, data connectivity, external storage links and anything more. Small, self-contained modules like this could contain the CPU and whatever other components are best to have locally, like a small local SSD and memory.
Sure, but why would you add that overhead (both in latency and electronics needed) to transport e.g. 16 PCIe lanes over 4 USB connections just to then direct it to PCIe devices anyways, especially if those devices partially need more than 4 lanes?
USB-C is a really cool solution, but a solution for the needs of laptops/other personal devices, not servers.
* Dead simple design.
* Easily hot-swappable without expensive proprietary connectors.
* Low cost solution that provides adequate bandwidth.
This isn't something that will perform better than a proper server with actual PCIe lanes, but it will perform better than a blade from two generations ago that didn't have that kind of backplane bandwidth and it will cost less to manufacture.
EOMA68 gets me thinking about those Compaq Ipaqs that could be fitted with a sleeve (i think Compaq referred to them as jackets) with a PCMCIA slot. One use of all this was to turn the Ipaq PDA into a mobile phone.
I feel like USB-C gives much more flexibility: it has a well-defined configuration enumeration protocol that's already supported everywhere. There's a lot more options for extensibility and future-proofing with USB-C.
With the onboard storage this is one step closer to my dream: the ability to plug a phone's compute module into a desktop to give me access to a more powerful GPU, extra storage, etc.
My big question: will this card format be an open standard, or will Intel be locking it down?