I’ve taken the existing Novena iCE40 add on board and made some minor improvements to the layout. In particular I’ve connect up the few stray signals where I didn’t have space to route previously, and replaced all the 0402 components on the rear surface.
One of the very few complaints I have with the Novena laptop relates to the positioning of the FPGA header on the board. The header is next to an edge of the case, which is important for devices that need external I/O headers, but unfortunately it’s nowhere near the Novena’s Peek array, and therefore hard to combine with internal add-ons. (It’s also a bit close to the CPU heatsink and wireless cards, so you can’t easily use large boards on the FPGA header).
To work around that somewhat, and to try and address some wish-list features I’d have liked on the general-purpose breakout board on the Novena, I’ve been toying with the idea of a bus breakout of sorts, designed to sit in the Peek array, and provide a few buffered I/O slots. Ideally, we want an iCE40 FPGA in there too, to make it easier to build custom FPGA code directly on the Novena – to build for the Xilinx part needs the proprietary Xilinx tools running on a remote machine.
I’d set myself a few basic requirements before starting designing a board for this;
Add-on devices can appear memory-mapped into the Novena’s address space – this is one of the unique abilities of the Novena FPGA slot vs. devices plugged in over USB or I2C.
Add-on devices should be able to be 3V, 5V, or any other reasonable voltage without needing to incorporate level-shifting buffers into the device (so you can, for example, use simple 74-series buffers as GPIO for either voltage, selectably)
At least two, and preferably more, add-on devices should fit into the Peek array, and be able to be mounted securely.
0.1″ pitch headers, only, so that add-ons can be made up on Veroboard or perfboard.
I2C, parallel data, and SPI should all be supported (at any voltage).
When I mentioned some of the details of what I was planning on IRC, Sean Cross (xobs) noted that he’d been considering building something similar with an iCE40 as a catch-all factory test device. I realised that nothing about Pi connectivity fundamentally clashes with the Novena requirements, so I’ve been experimenting with board layouts to try and accommodate both. For the raspberry pi, the main way to talk to the device will be over the SPI port, with both chip selects on the Pi connected up and usable. The same SPI interface allows both reprogramming the FPGA and communicating with it after setup (using two different CS pins). For the Novena, the same approach can be taken, using the SPI port brought out to the front panel board. It’s also possible to use some of the GPBB pins as another SPI port. In both cases the Xilinx FPGA can mediate and present whatever’s attached to the iCE40 as a memory-mapped device. Several extra pins are connected to allow QSPI, UART, and I2C interfaces between the host computer and the iCE40. Of course, since the Pi connector’s pins all go into the iCE40 FPGA, there’s no real requirement that the protocol spoken is SPI at all!
My current work-in-progress is based on a board that fits in a 90mm x 60mm region of the peek array, as shown below, and provides three slots on 30mm spacing. To allow add-on boards as much room adjacent to each other as possible, and a secure mounting directly to the peek array, the boards have notched corners, and a single screw in each corner (which may be shared with the adjacent board) secures them.
My current proposed pin-out for each slot includes a reference voltage pin sandwiched between a 5V pin and a 3.3V pin; this allows a simple jumper to be used to select a suitable voltage, or an external regulator can be used to feed some other reference into the reference pin. Each slot has I2C, SPI, a simple 8-bit bus, and an interrupt pin to allow it to signal for attention.
The 8 bit data pins are connected to a bidirectional (switched) level shifter, which can therefore be used for QSPI as well as for a normal 8 bit bus. The other pins are wired to single-direction level shifters as appropriate for the signal role.
As a first “will this even fit” test, I’ve dropped all the key components onto a PCB layout and run the DipTrace autorouter against it; this succeeds even on a 2 layer board, so this design looks achievable. I’d love to hear any feedback on the idea; you can reach me as MadHacker on #kosagi at irc.oftc.net, at the obvious email address, or you can leave a comment below.
Today, I got the revision 2 boards back from DirtyPCBs, and they work well. The new pads for the FX10 connectors line up much better, and the FPGA started up first time without any trouble. The extra connectors make it a bit easier to debug, or to use the board without a Novena attached. The larger-diameter mounting holes also make it much easier to attach. At this point, I’m happy to declare these boards a success; now I just need to get some Verilog written for the bus-bridge between the Xilinx and iCE40 FPGAs.
To help anyone else writing code to run on these boards, I’ve written a spreadsheet that’ll allow you to map the iCE40 FPGA pins to the Novena standard name for them, and to the GPBB role, on both sides. It will also produce the set_io statements for IceStorm’s .pcf constraints files, which simplifies getting something up and running quickly.
I’m not intending to manufacture any of these for general supply, but if anyone else is interested in these boards, you can get the bare PCBs from DirtyPCBs (file’s already uploaded and ready to go at this link – I’ve set up a zero cut for myself, so you’re only paying DirtyPCBs prices, no extra fees for me). The rest of the parts are listed in the BOM and are all available from both RS and Farnell – I’m sure the usual other suppliers will be able to provide something suitable as well. As the board is under the Apache 2.0 license, there’s no problem if anyone else wants to manufacture for others – feel free.
As I make progress on the bus bridge code, I’ll post it here, but in the meantime, have some blinkenlights. 🙂
I’ve now redrawn this board to correct the problems found with the previous version, and the new board’s schematics and layouts are now available at this link. As well as correcting the problems I had before, I’ve also managed to add in a few extra features. I’ve found two pins from each FPGA that weren’t sensibly routable, and connected one to an LED and one to a 0.1″ header for each FPGA. This helps a bit with debug, as you can more easily see what’s going on. I’ve also added the FPGA reset pin to the SPI header, which means that it’s now possible to bring up the FPGA without a Novena attached. Previously, you couldn’t do this because you couldn’t bring the FPGA out of reset without a bodge wire, but the extra pin makes it straightforward. Finally, I’ve added a 1.2V header, so you can access the FPGA core voltage if you want.
I’ve uploaded the schematics as a PDF as well as the original DipTrace and Gerber files in case anyone wants to take a look without having to download Diptrace.
The new board is, as before, under the Apache 2.0 license. I’ll be getting a few of these made up at Dirty PCBs, and will post again here when I’ve got one assembled and tested.
I’ve now got the iCE40 add-on board for the novena up and running. There are a couple of defects on the board design that need corrected before you can get one of these boards to run. These are:
Missing power to the VCC_SPI pin (pin 72, top pin on the right-hand side of the chip, nearest the 1.2V regulator) – this just needs jumpered to any available 3.3V point. Since it’s the very corner pin, there’s no difficulty connecting this by hand.
Bad footprint for the pass-through connector – the FX10A_80P_8 connector footprint I’ve used is too narrow, and it makes it very difficult to solder by hand. Reflow should be OK as long as the solder resist layer isn’t excessively thick on your boards – the pads are in the right place, just too short.
I’ll do a revision of the board layout when I get some time, but for now, this is pretty functional.
I’ve written a basic loader for the iCE40 , which uses a slightly modified GPBB Xilinx bitstream for now. I hope to write a proper bus bridge for the Xilinx to interface between the two ICs, but for now it’s enough to get blinkenlights working. The sources (and a copy of the compiled Xilinx bitstream) are available here.
I’ve also included a basic blinkenlights demo for the GPBB when piggy-backed on the iCE40.
I’ve received the boards for the iCE40 add-on back from DirtyPCBs, and they look good. As far as I can tell, everything seems to be functional, although I’ve got some coding to do before I can tell for certain – in particular, I need to put together a bootloader of some sort to feed the SPI port on the iCE40 with the bitstream.
In the meantime, I’ve put together one of these boards and got it powered up in a spare novena to test, and I’ve quickly thrown together enough Verilog code for the Xilinx to be able to bit-bang SPI to talk to the iCE40.
For anyone following along, the only mistake I’ve noticed on these boards has been the wrong footprint for the upper pass-through connector; the one I’ve used is close enough to fit, but there’s some definite overhang on the pins over the pads, and it’d be wise to redo that part if you’re considering making one of these boards. I’d also recommend using the taller version of the lower connector, as I found the board sits slightly high at one side as a result of resting on the SATA connector. It’s flat enough to still make good contact, however, so if you only have the shorter connectors, you should be OK.
Here’s the board sitting in place in the novena (with a patch wire onto the reset pin during bringup):
I’ve been working on an add-on board for the Novena open-source laptop, which provides an iCE40HX4K FPGA on a mezzanine board designed to fit in between the Novena and any add-on boards.
The reason this is useful is that Clifford Wolf’sicestorm project provides a fully open-source FPGA toolchain for the iCE40 that can run locally on the Novena, thereby removing the need for an x86 desktop machine when playing with FPGA projects. The Xilinx FPGA will act as a bus bridge between the iCE40 and the Novena, and (hopefully) provide access to RAM too, using a fixed, shared, FPGA design.
The board is intended to sit in the same location as the normal GPBB board would in a Novena laptop, and to provide a rotated FPGA header for the GPBB or other add-on boards to connect to, positioned such that it will sit above the SSD. This isn’t ideal, but the Novena layout is very tight for space around the FPGA connector, so it’s the best way I could fit in space for a whole second board.
At this point, I’ve drawn up a PCB design for the board, and I’ve ordered the first batch from dirtypcbs.com to try out. If anyone’s curious to look at the schematics or board, they’re available here in DipTrace format. Everything’s under the Apache 2.0 license, to match the Novena itself.
I recently found, in an old box of random electronics, a pocket dictionary of the 12-in-one spellchecker variety. The board had two large chip-on-board ICs on it, both covered with the usual black epoxy of doom. The actual traces routing between the two were relatively sparse, and I was somewhat curious what the architecture of the device actually was, so I decided I’d like to de-encapsulate the chips to see what was making it tick.
I’ve heard many times in the past that the best way to do this is by careful application of fuming nitric acid. Unfortunately, that’s somewhat controlled in the UK as it’s considered a precursor for making explosives; as a result, I didn’t have any to hand. However, I thought it might be interesting to try a different approach – a laser cutter.
I have a generic 40W chinese laser cutter, of the kind you can pick up cheaply on eBay. This particular laser has been upgraded very slightly with some better stepper control electronics and an air assist nozzle for the head; however, it’s still using all the original optics and laser. The air assist is the only relevant improvement for this job.
I set the PCB with the COB blob up under the laser, and fed in a simple half-inch square bitmap to the laser control software to be engraved. This made the laser perform a raster pattern across the surface of the COB device, neatly etching away the epoxy. If you’re trying this yourself, I used three passes, with the laser at full power and set to 300mm/sec and air assist on.
A single pass yielded a noticable depth of cut into the epoxy blob, with a fairly good surface; it was a little dusty (the various unpleasant byproducts of burning epoxy tend to recondense on nearby surfaces), but the laser was clearly cutting the epoxy fine. The question was whether it would trash the silicon underneath.
After the third pass, the die surface started to become visible, and so I stopped and cleaned off the surface with a brush. Unfortunately, I was a little heavy-handed with the brush, and some of the gold bond wires were broken as I did – they were actually intact before. However, I managed to get a pretty good view of the chip surface, and a look at the layout. Apologies for the poor photograph quality – I was using a biological microscope not intended for top illumination, and it has bad flare problems with the reflections from the IC surface.
From this, I think it’s pretty clear that this chip is just a ROM of some sort, and any clever behaviour is implemented on the other chip on the board, Unfortunately I managed to shatter that chip while trying a different process for removing it from the epoxy blob of doom, so I have no photographs of that to show.
I hope this helps if anyone else needs urgently to deencapsulate a chip and work out what’s inside it; it’s faster (less than 5 minutes on the laser) and simpler than the nitric acid approach, and while it doesn’t yield a perfect result, it’s good enough for basic identification. Most importantly, the laser doesn’t seem to cut any of the metal on the chip, nor the bond wires, nor the silicon itself, despite chewing rapidly through the black epoxy.