Creating A Custom ASIC With The First Open Source PDK

June 25, 2020 by Maya Posch 23 Comments

A process design kit (PDK) is a by now fairly standard part of any transformation of a new chip design into silicon. A PDK describes how a design maps to a foundry’s tools, which itself are described by a DRM, or design rule manual. The FOSSi foundation now reports on a new, open PDK project launched by Google and SkyWater Technology. Although the OpenPDK project has been around for a while, it is a closed and highly proprietary system, aimed at manufacturers and foundries.

The SkyWater Open Source PDK on Github is listed as a collaboration between Google and SkyWater Technology Foundry to provide a fully open source PDK and related sources. This so that one can create manufacturable designs at the SkyWater foundry, that target the 130 nm node. Open tools here should mean a far lower cost of entry than is usually the case.

Although a quite old process node at this point (~19 years), it should nevertheless still be quite useful for a range of applications, especially those that merge digital and analog circuitry. SkyWater lists their SKY130 node technology stack as:

Support for internal 1.8V with 5.0V I/Os (operable at 2.5V)
1 level of local interconnect
5 levels of metal
Inductor-capable
High sheet rho poly resistor
Optional MiM capacitors
Includes SONOS shrunken cell
Supports 10V regulated supply
HV extended-drain NMOS and PMOS

It should be noted that use of this open source PDK is deemed experimental at this point in time, and should not be used for any commercial or otherwise sensitive applications.

Header image: Peellden/ CC BY-SA 3.0

AudioMoth: The Proverbial Moth On The Wall

June 25, 2020 by Maya Posch 12 Comments

Monitoring environmental sounds is perhaps not a common task, but much like with wildlife cameras, we could learn a lot from an always-on device listening in on Mother Nature. The AudioMoth is one of such devices. Although it has been around for a few years, it is notable for being an open platform, with the full Eagle-based hardware design files, BOM and firmware available, as well as NodeJS- and Electron-based utility software.

The AudioMoth is powered by a Silicon Labs EFM32-based MCU (EFM32WG980F256) with a Cortex-M4 core, 256 kB of Flash and 32 kB of SRAM. Using the onboard MEMS microphone it records both audible and ultrasonic frequencies that are written in uncompressed WAV format to the SD card. This makes it capable of capturing the sounds from bats in an area in addition to the calls of birds and other wildlife.

The AudioMoth has also a micro-sized, low-cost version called the μMoth, which shares the same features as the AudioMoth. This project is still in progress, with updates expected later this year.

Although the AudioMoth device can apparently be bought from sites like LabMaker for $74 at this point, it should be noted that the MCU used on the device is listed as ‘NRND’ (not recommended for new designs) by SiLabs, which may complicate building one in a number of years from now. Or at least you’ll have to substitute in a different microcontroller.

Regardless, it does seem like an interesting starting point for wildlife monitoring, whether one simply wants to build a device like this, or to use it as inspiration for one’s own design.

New Silq Programming Language Aims To Make Quantum Programming Easier

June 22, 2020 by Maya Posch 18 Comments

Fresh from ETH Zurich comes the new Silq programming language. They also have submitted a paper to the PLDI 2020 conference on why they feel that it is the best quantum programming language so far. Although it may be not common knowledge, the lack of usable general purpose quantum computers has not kept multiple teams from developing programming languages for such computer systems.

Microsoft’s Q# is a strong contender in this space, along with the older QCL language. The claims by the Silq team on exactly why their language is better appear to come down to it being ‘more high level’, and by supporting automatic (and safe) uncomputation. While the ‘high level’ aspect is suspect since Q# is most decidedly a high-level programming language, their uncomputation claim does at least have some merit.

Uncomputation is a concept in quantum programming, where one occasionally has to remove a few intermediate objects from the current state because they may cause quantum interference that would affect the resulting output. Normally, one would save the intermediate result to a register for this, then reset the state and continue. Which parts of the state to keep and what to uncompute is however not easily determined, as a quick glance at related answers over at the Quantum Computing StackExchange and Theoretical Computer Science might reveal.

The main question thus appears the validity of this claim about Silq being able to automatically determine what ‘garbage’ can be safely uncomputed, and what should be part of the quantum interference. We have all seen with languages like Java and C# how even with traditional computing something as simple as garbage collecting can go horribly wrong. Maybe we shouldn’t count our quantum chickens yet until this particular waveform has fully collapsed.

(Thanks to Qes)

Metasurface Design Methods Can Make LED Light Act More Like Lasers

June 18, 2020 by Maya Posch 33 Comments

Light-emitting diodes (LEDs) are not exactly new technology, but their use over time has evolved from rather dim replacements of incandescent signal lights in control panels to today’s home lighting. Although LEDs have the reputation of being power-efficient, there is still a lot of efficiency to be gained.

UC Santa Barbara researchers [Jonathan Schuller] and his team found that a large number of the photons that are generated never make it out of the LED. This means that the power that was used to generate these photons was essentially wasted. Ideally one would be able to have every single photon successfully make it out of the LED to contribute to the task of illuminating things.

In their paper titled ‘Unidirectional luminescence from InGaN/GaN quantum-well metasurfaces‘ (pre-publication Arxiv version) they describe the problem of photon emission in LEDs. Photons are normally radiated in all directions, causing a ‘spray’ of photons that can be guided somewhat by the LED’s packaging and other parameters. The challenge was thus to start at the beginning, having the LED emit as many photons in one direction as possible.

Their solution was the use of a metasurface-based design, consisting out of gallium nitride (GaN) nanorods on a sapphire substrate. These were embedded with indium gallium nitride (InGaN) quantum wells which emit the actual photons. According to one of the researchers, the idea is based on subwavelength antenna arrays already used with coherent light sources like lasers.

With experiments showing the simulated improvements, it seems that this research may lead to even brighter, more efficient LEDs before long if these findings translate to mass production.

(Thanks, Qes)

OmniBallot, Another Flawed Attempt At Online Voting

June 14, 2020 by Maya Posch 49 Comments

Although online voting in elections has been a contentious topic for decades already, it is during the current pandemic that it has seen significant more attention. Along with mail-based voting, it can be a crucial tool in keeping the world’s democratic nations running smoothly. This is where the OmniBallot software, produced by Democracy Live, comes into play, and its unfortunate unsuitability for this goal.

Despite already being used by multiple US jurisdictions for online voting, a study by MIT’s [Michael Specter] and University of Michigan researchers points out the flaws in this web-based platform. Their recommendations are to either avoid using OmniBallot completely, or to only use it for printing out a blank ballot that one then marks by hands and sends in by mail.

One of the issues with the software is that it by default creates the marked ballot PDF on the Democracy Live servers, instead of just on the user’s device. Another is that as a web-based platform it is hosted on Amazon Web Services (AWS), with JavaScript sources pulled from both CloudFlare and Google servers. Considering that the concern with electronic voting machines was that of unauthorized access at a polling station, it shouldn’t require a lengthy explanation to see this lack of end-to-end security with OmniBallot offers many potential attack surfaces.

When Ars Technica contacted Democracy Live for commentary on these findings, Democracy Live CEO [Bryan Finney] responded that “The report did not find any technical vulnerabilities in OmniBallot”. Since the researchers did not examine the OmniBallot code itself that is technically true, but misses the larger point of the lack of guarantee of every single voter’s device being secured, as well as every AWS, CloudFlare and Google instance involved in the voting process.

As a result, the recommended use of OmniBallot is to use it for the aforementioned printing out of blank ballots, to save half of the trip time of the usual mail-in voting.

Quantum Computing And The End Of Encryption

June 11, 2020 by Maya Posch 58 Comments

Quantum computers stand a good chance of changing the face computing, and that goes double for encryption. For encryption methods that rely on the fact that brute-forcing the key takes too long with classical computers, quantum computing seems like its logical nemesis.

For instance, the mathematical problem that lies at the heart of RSA and other public-key encryption schemes is factoring a product of two prime numbers. Searching for the right pair using classical methods takes approximately forever, but Shor’s algorithm can be used on a suitable quantum computer to do the required factorization of integers in almost no time.

When quantum computers become capable enough, the threat to a lot of our encrypted communication is a real one. If one can no longer rely on simply making the brute-forcing of a decryption computationally heavy, all of today’s public-key encryption algorithms are essentially useless. This is the doomsday scenario, but how close are we to this actually happening, and what can be done?

Continue reading “Quantum Computing And The End Of Encryption” →

Xilinx Makes MIPI CSI And DSI Controller IP Blocks Free To Use With Vivado

June 9, 2020 by Maya Posch 21 Comments

If you want to use a display or camera with an FPGA, you will often end up with a MIPI-based solution. As of the Xilinx Vivado 2020.1 release, the MIPI DSI (display serial interface) and CSI (camera serial interface) IP blocks are now bundled with the IDE to be used freely with Xilinx FPGAs.

The Xilinx MIPI CSI2 receiver block implements the CSI-2 v1.1 specification, which although a bit older is essentially the same CSI implementation as on the Raspberry Pi boards. This means that it would allow one to use this IP block on an FPGA with many common CSI camera modules out there. The IP block offers a standard AXI4 interface for connecting up to the rest of a design.

Similarly, the Xilinx MIPI DSI transmitter block implements DSI v1.3 specification. This offers a maximum data rate of 1.5 Gbps, with an AXI4-lite interface to communicate with the rest of the design. Both IP blocks are subject to the Core license agreement, which doesn’t appear to preclude it from being used in a specific fashion, whether commercial or personal.

This is not the only way to use MIPI devices with an FPGA, of course. Take for example [Daveshah]’s CSRIx project on Github.

Header image: Kwapix / CC BY-SA 4.0