Hi everyone,
Time for another update!
We are marking a big milestone. We just shipped the last Glasgow boards that were part of the crowdfunding campaign! This means that everyone who ordered a Glasgow during the crowdfunding campaign should either have gotten their Glasgow already or will receive it very soon.
We have also shipped all the aluminium cases that are needed to wrap up the campaign (as well as pre-orders) to Mouser.
This does not mean we are fully done yet! There are still another 1000 Glasgows that we need to manufacture and ship to Mouser for people who placed pre-orders after the core campaign was concluded.
We will continue chipping away at the backlog.
Safety Issue
Since the last update we have addressed a safety issue in Glasgow. The solution to the issue is a firmware change, so you will need to update the firmware to receive it.
tldr;
Your Glasgow will drive all I/O to a strong high level when re-loading the bitstream with VIO enabled.
To mitigate the issue: Make sure to update your Glasgow software installation as described in these instructions and run glasgow flash command with your Glasgow connected to your computer.
Following are more details about the issue and the solution.
What is the issue
When a new bitstream is loaded while VIO is enabled, all the I/O pins will strongly drive high. Strongly means that these are not pull-ups (aka. driven through resistors) but rather that the pins are just connected to the VIO supply through the level shifter high-side FET and 33 ohm IO resistors (about 50 ohm of resistance total). Depending on the application this can have varying consequences.
The issue is caused by the fact that the FPGA by default has weak pull-ups on the IO pins. So when the FPGA is reset in the process of loading a new bitstream, it will briefly output high on all of its pins. The way we have designed the level shifter circuits results in them switching to output high.
Background on decision-making
(You can skip this section unless you want to understand this issue in as much detail as we ourselves do.)
Unfortunately, at the time when we designed Glasgow revC, the best level shifters we found available (SN74LVC1T45) are asymmetric: they have an A-side and a B-side with a constraint on supply voltages that can be provided to each, and for a design like Glasgow, only the B-side could cover all of the voltages we wanted to make available on the I/O ports. The DIR input being high corresponds to the B=A configuration of the level shifter (B-side is driven).
We have discovered this issue during internal review in 2019, and have decided to address it with a firmware component (disabling VIO supply while FPGA is reset) combined with a hardware component (adding a discharge resistor to ensure that the VIO supply falls to a safe level in a short period of time after being disabled). While the hardware fix was applied in 2019, the firmware fix was left unaddressed, as the issue was inadvertently closed after the hardware fix was applied.
We have considered adding pull-down resistors to override the FPGA built-in pull-up resistors during the 2019 review, but decided against it as it would have substantially increased the complexity of assembly and parts count. We have considered other solutions in 2024 (switching to symmetric 74AXP1T45 level shifters that have become available; turning off FPGA bank power supply) but concluded these were not practical due to the costs that would be incurred to 1BitSquared which has a significant part stock.
When is it happening
The issue occurs when changing the gateware on the fly and after the device has already been loaded with gateware. It affects those who develop new applets the most, but since Glasgow applets embed parameters (such as clock frequency) into applets, changing these parameters will trigger a rebuild and reload of the gateware. Similarly, switching from one applet to another will trigger this issue.
If you have been pressing "E-STOP / RESET" button before making any changes to the running applet you have not been affected by this issue. This is a good safety practice regardless of any such issues.
What is the firmware fix
The firmware fix disables VIO before loading a new bitstream and adds 250 ms of delay afterwards to let the VIO supply dissipate before the new bitstream is loaded. Based on our testing, this delay has enough safety margin to cover most cases, with the exception of targets which have large amounts (over 40 µF) of bulk capacitance and no static load (i.e. a resistor from the supply to ground, or integrated circuits that act the same way) that would discharge this capacitance.
Note that if you supply voltage to the Glasgow I/O bank via the VIO pin, this fix will not protect you from the issue. It has always been forbidden to supply voltage to the Glasgow I/O bank via the VIO pin (it is only allowed for Glasgow to power other devices, not vice versa); while it is unlikely to damage the device it may cause undesired operation, such as preventing this mitigation from being applied.
How do I apply the fix
The patch is already merged into the main branch of the Glasgow software. So make sure to update your Glasgow software installation. Then you should run glasgow flash command with your Glasgow connected to update the firmware on your device. As you are doing that, you should see a warning message about "API level 3"; if you see this message it means that the device did not have the fix applied and that it is being applied now.
All Glasgows with the lot number (1T field on the serial number sticker) 8 and greater will already come with the updated firmware on the device.
How do I verify that the fix is applied
Look up the "Product" property of the device while it is plugged in using the appropriate OS interface. If it states Glasgow Interface Explorer (git f050f518) both before and after pressing the "E-STOP / RESET" button, the fix has been applied correctly.
On Linux this can be done with a terminal command:
$ lsusb -d 20b7:9db1 -v | grep iProduct
iProduct 2 Glasgow Interface Explorer (git f050f518)
On Windows this can be done using the Device Manager, or with a PowerShell command:
PS> Get-WmiObject CIM_LogicalDevice | where { $_.DeviceID -like "USB\VID_20B7&PID_9DB1*" } | select Name
Name
----
Glasgow Interface Explorer (git f050f518)
On macOS this can be done with a terminal command:
% ioreg -p IOUSB | grep "Glasgow Interface Explorer"
+-o Glasgow Interface Explorer (git f050f518)@02400000 <class IOUSBHostDevice, id 0x100034d75, registered, matched, active, busy 0 (28 ms), retain 20>
Future
We may eventually address the issue in a new hardware revision to avoid relying on the firmware for safety measures, as we have done several times previously. The new hardware design will take quite a while to implement, test and deploy though. We know that everyone has already been waiting patiently to receive their Glasgows. We also made a major financial investment in PCBs and parts, so we will not be making changes to the hardware design in the near term future.
Fortunately, the firmware fix mitigates the problem in a satisfactory manner. If you have any additional questions, feel free to contact us through the regular project communication channels or through the campaign contact form.
What is next
We still have a few months of work in front of us to wrap up fulfilling the post-campaign pre-orders. Manufacturing the remaining 1000 boards and shipping in batches of roughly 200 units at a time. Make sure that your shipping address is up to date in your Crowd Supply account.
Closing words
As always, thank you everyone for your patience. We hope that those of you that already received their Glasgows have fun with it and it serves you well.
When you receive your Glasgow, make sure to take a picture and send a message to us in the community channels or use the hash-tag #GlasgowInterfaceExplorer on Mastodon! It is very nice to see the results of our work in the wild!
If you would like to support the software and documentation effort please consider supporting Catherine through Patreon she has implemented regular Glasgow maintenance hours every week to keep things moving forward. Thanks to Catherine’s hard work 32 pull requests were merged and closed since the last update.
See you in the next update!
Cheers,
Piotr Esden-Tempski and the Glasgow team