mctom's FPGA playground for ODROID M1S

[mctom]

This idea has been with me for a long time, as FPGA dev boards (well, at least iCE40 series) often have nothing more than a few GPIO exposed. This isn't ideal for experimenting with things requiring extreme data throughput, differential IO, or extra memory.
This board solves most of my problems and I will be able to develop Verilog code with actual hardware and real life signals.
It was meant to be as universal as possible, but even though FPGA has 109 GPIO pins that sounded almost like infinite, I had to cut many features in the end.
RS-232 port, LVDS header, LED matrix and FPGA-driven power converters all had to go to make room for other things that cannot be recreated using FPGA devboards I already own. Heck, I had to pick a 8-bit SDRAM chip instead of 16-bit data bus.

This idea would still be nowhere without new excellent M1S and add-on design aides. The feature list below will speak for itself, many of them would not be possible without those extra 14 pins.

Here is a feature list:
- iCE40HX4K in TQFP144 package, about 4K LUTs, 2x PLL, 109 GPIO. The largest that isn't BGA -> possible on $7 PCBs
- 4-layer PCB with strict design rules -> cheap
- All components on top side -> can be hand-soldered
- FPGA configuration stored in EEPROM on board and programmed from SBC directly via SPI (flashrom)
- External 100MHz oscillator
- FT2232 chip supporting 8-bit wide, bidirectional FIFO with SBC, via USB, at High Speed (480Mbps)
- 256Mb SDRAM (Zentel A3V56S30GTP-60), 8-bit wide, clocked at 166MHz (if all goes well)
- "HDMI" connector
- VGA output (RGB565)
- Stereo jack output (shares resources with VGA)
- DC jack or screw terminal as alternative power input for M1S, with on-board 5V 3A Buck converter (tolerates input up to 23V
- Some M1S pins connected to FPGA (SDMMC1, UART0, SPDIF)
- General purpose IO: 2 buttons, 7 LEDs, 2 pins

Github repository: https://github.com/tomek-szczesny/m1s-fpga-playground

Some of the ideas what could be done with this board include:
- Developing I2C, SPI, UART libraries for FPGA
- Using FT2232 in any of its built-in modes of operation
- SDRAM support, that's a topic for PhD alone
- SPDIF decoder -> multibit DAC for analog audio
- Displaying static images through HDMI / VGA
- SPI display emulation on a real monitor
- /dev/fb via USB and displaying stuff through HDMI / VGA (or both!)
- Exploring the undocumented SDMMC interface on M1S GPIO header
- Hardware h264 encoder, maybe?

It should be said, I have no idea if any of this will actually work. The board is intended for testing ideas (= development) and isn't fit for any particular real life purpose as it is. However purpose-made boards may follow after working prototypes are achieved.
The FPGA has limited performance. Due to their nature there is no exact number given, because performance depends on internal layout of Verilog code. Some 100+MHz worked for me in the past. Internal PLL can run up to 275MHz.
I don't expect to reach Full HD resolution with that HDMI port, but interlaced Vu7C at 30fps may be possible. I'm guessing just because <100MHz. But hey, even working 640x480 would be a tremendous success that can be scaled up if needed.

[mad_ady]

You say "hand soldered", but those SMD components say otherwise!

Anyway, best of luck in this ambitious project!

[mctom]

I'll probably hand solder it because I can't afford having 5 pieces built, and that's the usual minimum quantity.
I'll use a solder paste stencil and bake the whole PCB, as usual.
I deliberately use larger components anyway, all passives are 0603.

[mctom]

Updated picture and feature list.

I gave up some M1S - FPGA connections because they won't be useful. I added LEDs instead which should be more helpful in development.
Still all connections are here to play with SDMMC1 interface, use UART0 for debug, and SPDIF as audio source for experiments with multibit DAC.
M1S PWM channel can be used as a clock input for FPGA, but onboard 100 MHz oscillator will be faster anyway. FPGA has PLL that can synthesize higher frequencies.

This board is stuffed!

[rooted]

Very nice, should be quite the playground for learning assuming it works

[mctom]

I updated a picture and included schematics for those interested in reviewing them, lol.
The layout is done, now I'll calculate some passive component values and order PCBs.

Very nice, should be quite the playground for learning assuming it works

This is FPGA playground, not nursery.

I spent some time studying SDRAM and understanding its controls, and it should work IMO. Even DDR might have worked, as it turns out both share the same communication interface. But the pinout won't be compatible so I'm sticking to SDRAM for now.
Some guys have already shown HDMI is possible with this FPGA class but ended at producing a few test patterns, nothing more exciting than that.
VGA and audio outputs are pretty straightforward and I already created delta-sigma blocks in the past that I may reuse.

[mad_ady]

Obligatory xkcd: https://xkcd.com/730/

[mctom]

I'm sure I've put much more work into my practical joke.

I decided to order it with "basic" parts mounted, instead of ordering a stencil. I'll have some 500+ components soldered on and I'll mount the rest at home with solder paste applied by hand.
After all, assembly of complex PCBs takes a lot of time due to a wide variety of components in use. Finding each type in a box, finding it on a schematic and then on PCB, it all by far takes the most time.

[mctom]

I uploaded the project on github, thus removed the schematc pdf from here.

The PCBs are already manufactured with most of the passive components soldered on, and have been dispatched my way. Mouser order is also being processed, and I already received a syringe of solder paste. Good luck to me applying it by hand.

[mctom]

I searched online what the correct term for FPGA code is, because it's neither firmware, and definitely not software.
According to ESA, FPGA code is a part of hardware, and had to obey hardware quality standards.
I have found some discussion online about this topic and I grew fond of the term "gateware".
Thus I have uploaded a "blinky" example, in a gateware directory on github.

I discovered a super annoying bug on a PCB, which comes directly from Lattice's poor documentation.
It said that PLLs can be fed frequency through any global FPGA pin (8 in total), but that's only partially true. In fact there are two dedicated external pins that will be claimed by PLLs, even if their source signals come from anywhere else.
One of these pins happens to be a SDRAM data line, so that won't do.
VERY luckily, all I have to do is to swap two neighboring pins on PCB, which I did in kicad, but will be harder to do on the real thing. Fingers crossed, in the worst case I'll have 7-bit wide SDRAM

[mctom]

PCBs are on their way and should get there well before Christmas, so I've allocated time to build the thing before New Year's Eve.

Meanwhile I've been busy preparing some Verilog code.

Apart from VGA driver which was suspiciously easy, I turned my attention to SDRAM driver, which will be required to display anything more interesting than white box on a black background.
I have read the datasheet of SDRAM and found out these chips are spiritually rich. So many convoluted rituals to get them going..

Long story short, I made a CPU, in Verilog
https://github.com/tomek-szczesny/ice40 ... equencer.v
It supports 8 commands that took me way longer to design that I'd like to admit. Commands are selected to facilitate loops and jumps, as its purpose is performing SDRAM rituals.

I scrapped CPU registers in favor of a single stack memory, which can be filled with looping and jumping parameters directly in the code.
This core supports externally forced jumps around the ROM, so program ROM may contain few sequences launched accordingly by external logic.
Most opcodes have space for user data that is returned by the block, which is a whole point of a sequencer.

The module is quite flexible. For example, opcode length (thus user data space) is parameterized.

Attached screenshots of a sample machine code (yes at least I defined instruction mnemonics..) and simulated result.
It's a stepper motor driver
By forcing a jump into a correct entry point, a few procedures can be initialized:
#2: 1 spin left
#12: 1 spin right
#19: 5 spins left,
#25: 5 spins right and 1 left.

This program takes 31*12 = 372 bits, so will use a single 4096b ROM block from the FPGA. There are 20 such blocks available on 'HX4K.

EDIT: Would be nice to have a compiler for it now, or at least assembler, but I'll pass.

EDIT: I had an idea before going to bed, that it would be awesome to queue sequencer tasks..
So, now it's a matter of dumping a list of procedure entry points into FIFO, and sequencer will execute them in given order with no delays in between them.
HOW AWESOME IS THAT.