Wishful Coding

Imagine you’re writing a collaborative application where multiple users are editing a document at the same time. How do you resolve conflicting edits?

The YOLO solution is last-write-wins, resulting in data loss. The git/CouchDB solution is explicit conflict resolution, by asking the user or using domain-specific logic. The cool kids solution is to use a conflict-free replicated data type (CRDT), promising to never create conflicts in the first place!

A simple to understand CRDT is the add-only set. If two people add different things to a set, you simply add all the things. As long as you never remove things, you can always resolve concurrent edits.

Computer science has given use a whole set of these CRDTs, and people have built nice libraries out of them that promise that as long as you use these data structures you can have a collaborative app that never has conflicts or data loss. Perfect!

Except, the fact that they are conflict free does not mean that the resolution is what the user expected.

Imagine a collaborative drawing program. Lets keep it simple and say the drawing is an add-only set of lines. Perfect, anyone can add lines and there will never be a conflict!

So now Alice and Bob decide to draw a landscape together. Alice starts drawing happy little trees, but Bob suffers an internet glitch and goes offline for a minute. While offline he draws some big snowy mountains. When Bob comes back online, the add-only set neatly merges all their lines without conflict, resulting in a hot mess.

This is not an imaginary scenario. I was showing Mosaic to a friend, but their ad blocker blocked synchronization. He drew a nice circuit, unaware of what was already there, and when he disabled his ad blocker, this was the result. Not a single conflict, but not a functional circuit either. (it’s a band pass filter and a differential pair, in case you’re wondering)

Mosaic is not in fact using a true CRDT, rather it is using CouchDB in a way that avoids conflicts. Each component is its own document, so there aren’t conflicts unless two people try to drag the same component at the same time. There is no way to resolve that situation and let both people get what they want. CouchDB has a pretty good section on designing an application to work with replication by the way.

In short, no matter if you use a CRDT or something else, there are situations that cannot be automatically resolved in a way that is generic and does what the user expects. You cannot wish this problem away. To the user last-write-wins data loss and seamlessly-smushed-together data loss are indistinguishable. So how do you handle it?

I think CRDTs are a useful tool, but ultimately suffer from the same “wishing the problem away” attitude as last-write-wins. CouchDB has the right mentality of designing for conflict avoidance, and requiring domain-specific conflict resolution, but it is not a full solution either. As you saw with Mosaic, you can get too good at avoiding conflicts, leading to a result that is unexpected to the end user. You need to think of domain-specific solutions.

In the case of Mosaic the plan is that device-level changes are an explicit conflict that requires user review. If you change the transistor width, and I change the length, that is not something that should be resolved automatically, even though it technically could be. We have both changed the very important W/L ratio, and combining these edits would likely have the wrong result.

At the schematic level, it’s hard to tell if some changes are intentional. I don’t think you can or should capture overlapping components at the database level, and the best thing to do is offer Electrical Rule Checks(ERC) for likely mistakes, and good edit history to recover from them.

The release of the open source Skywater 130nm PDK seems to have started a flurry of activity around open source EDA tools, with several companies trying to form a business around an open source suite of chip design tools of some form. Of course this raises the question of what business model you’re going for.

As far as the licensing aspect is concerned, there are things to be said for the easier commercial adoption of permissive licensed tools and for copyleft encouraging the contribution of modifications, and enabling dual-license models.

A well known example of the latter is Qt, which is released under the GPL, so you can use it freely for open source projects, but if you want to develop a proprietary application that you don’t want to release under the GPL, you’ll have to get a commercial license.

Would such a model work for EDA tools? Unlike Qt your users are not writing software, they are making a chip, so GPL doesn’t really cover that. I’m very much not a lawyer, but my reading of the CERN Open Hardware License is that the strongly reciprocal one would do exactly that. Let me explain why.

The CERN OHL version 2, An Introduction and Explanation is a great place to get an understanding what problem it is trying to solve, and spoiler, it’s not EDA tools. It basically tries to solve issues with using GPL for hardware: hardware is not free as in beer, and not all IP blocks and components are open source.

A centerpiece of the license is that of an “available component” which can be either an open source thing, or something anyone can obtain with sufficient documentation to reproduce your thing. The goal is basically that if I write some HDL, the copyleft aspect applies to a PCB made with my HDL on it, but you don’t need to provide the source code for a resistor, anyone can just buy a resistor and download its datasheet. It’s an available component.

But when you squint a bit, the HDL->PCB copyleft mechanism is kinda similar to an EDA software->chip copyleft mechanism. But lawyers don’t “squint a bit” so we’ll have to get into the weeds to see if the exact wording makes sense for EDA software.

The excerpts below come from the full CERN Open Hardware Licence Version 2 - Strongly Reciprocal

2.1 This Licence governs the use, copying, modification, Conveying of Covered Source and Products, and the Making of Products. By exercising any right granted under this Licence, You irrevocably accept these terms and conditions.

The interesting bit here is the Making of Products. We’ll get back to the definitions in a minute, but it’s important to note that the license does not just cover modifying the source, but also using it to Make Products. Such as using EDA tools to make a chip, if these fit the definition.

Section 3 is typical copyleft stuff about modifying the Covered Source, but section 4 reads

You may Make Products, and/or Convey them, provided that You either provide each recipient with a copy of the Complete Source or ensure that each recipient is notified of the Source Location of the Complete Source. That Complete Source is Covered Source, and You must accordingly satisfy Your obligations set out in subsection 3.3. If specified in a Notice, the Product must visibly and securely display the Source Location on it or its packaging or documentation in the manner specified in that Notice.

So you can Make Products if you give the recipient the Complete Source, and the Complete Source is Covered Source. Let’s have a look at their definition.

1.3 ‘Source’ means information such as design materials or digital code which can be applied to Make or test a Product or to prepare a Product for use, Conveyance or sale, regardless of its medium or how it is expressed. It may include Notices.

So Source can be code, HDL, Spice, GDS, or any other design material.

1.4 ‘Covered Source’ means Source that is explicitly made available under this Licence.

This includes the source of our EDA tools, and the Complete Source.

1.5 ‘Product’ means any device, component, work or physical object, whether in finished or intermediate form, arising from the use, application or processing of Covered Source.

Clearly a chip is a device, that arises from the use of Covered Source, the EDA tools. But a GDS, bitstream, or netlist are also a work (in intermediate form) that arise from application of the Covered Source.

1.6 ‘Make’ means to create or configure something, whether by manufacture, assembly, compiling, loading or applying Covered Source or another Product or otherwise.

You do a thing to another thing. Specifically by applying Covered Source (EDA tools) to load or compile some source.

1.8 ‘Complete Source’ means the set of all Source necessary to Make a Product, in the preferred form for making modifications, including necessary installation and interfacing information both for the Product, and for any included Available Components. If the format is proprietary, it must also be made available in a format (if the proprietary tool can create it) which is viewable with a tool available to potential licensees and licensed under a licence approved by the Free Software Foundation or the Open Source Initiative. Complete Source need not include the Source of any Available Component, provided that You include in the Complete Source sufficient information to enable a recipient to Make or source and use the Available Component to Make the Product.

So all the stuff needed to make the chip basically, EDA tools as well as design files. Either as Source or Available Components.

With those definitions in mind, let’s look at section 4 again. Paraphrasing, you can Make a Product if you provide the recipient with the Complete Source. Expanding that, it says you can apply the Covered Source (EDA tools) to make a device (chip) or intermediate work (netlist, GDS), provided you give the recipient all the source files or available components specs necessary to do so.

Long story short, my amateur reading of all this is that if you release your EDA tools under CERN-OHL-S and your users make a chip with it, they have to make the design files available, unless they obtain a commercial license from you.

In alternative circles people tend to be worried about the harmful effects of electromagnetic radiation (EMR/EMF, or just “radiation”), which scientists tend to dismiss because is’s it’s not ionizing radiation. That is, it’s not powerful enough to smash your atoms to bits.

Now, I’m not here to argue about the harmfulness of radiation, but it rubs me the wrong way to dismiss the idea outright because you’re not standing next to radioactive waste. All I want to do is propose a pathway for how EMF could potentially influence humans.

It is really quite simple. Any current creates a field and any field creates a current, and you can measure the electromagnetic fields of your brain and muscles, therefore your brain and muscles are also stimulated by external fields.

Let’s unpack that a little bit.

Things like Electrocardiography and Electroencephalography measure the electric signals emitted by your heart and brain respectively. You can build a DIY EEG device with some wires and an instrumentation amplifier. Electrical muscle stimulation on the other hand, applies electricity to your muscles to activate them.

It’s often said everyone designs antennas, but only some design them intentionally. Everything that can carry a current is an antenna weather you want it or not. It is fundamental to electricity that every current creates a field, and every field creates a current.

So the very fact that we can measure the fields created by your brain and muscles, means that a field can create a current in your brains and muscles.

It’s just a matter of magnitudes. Muscle stimulation requires dozens of volts, while EEG seems to be on the order of microvolts. Some radio transmitters transmit kilowatts, but due to the inverse square law receivers sometimes only receive microvolts.

Humans are not nicely tuned antennas designed to receive gigahertz frequencies, so I’m not saying EMF from your phone or wifi will cause microvolt signals in your brains, and I’m also not saying anything about what the effect would be if they did.

All I want to say is that due to how electric fields and currents interact, there is a two way link between currents in your body and fields outside it, so EMF has the potential to raise the noise floor on the signals inside your body.

I’m curious what you think about this argument.