USB to SPI: FPGA bridge

[NivagSwerdna]

I'm interested in creating a simple FPGA breakout board with an ice40 (or similar) and a connection to USB for programming.   i.e. a USB to SPI bridge.

The evaluation board I've been playing with is the now obsolete https://www.latticesemi.com/iceblink40-hx1k which I bought a couple of years ago.

Looking at the schematic it has an at90usb2-16mu acting at the USB i/f and this seems to implement "digilent adept 2".

My research suggests the Digilent Adept 2 provides a virtual interface to some registers which you implement on the FPGA side for virtual LEDs, buttons etc.

My question is... in this case does the at90usb2-16mu contain proprietary and non-free firmware from Digilent or is that available somewhere? 

In 2021, is digilent adept 2 a good or bad standard for this interface? 

Ultimately I would like to be able to program the device (SPI) and to exchange registers... any Open Source alternatives?

[NiHaoMike]

Not sure about ICE40 but XVCD on a Raspberry Pi can communicate with Xilinx tools, excellent for remote debugging. My guess is that an equivalent for ICE40 would be even easier to develop since the ICE40 toolchain is open source, I'm just not sure if there's a ready to go app available.

[NivagSwerdna]

I came across https://github.com/davidcarne/iceBurn which appears to be a utility to interact with the uP on the iceBlink that itself implements Adept2. 

I guess I need to reformulate my question now my understanding has increased a little.

What I need is a reference design that I could use to provide the USB to SPI bridge (to at least program the onboard SPI and/or NVRAM in the device) which would speak the same protocol as IceStorm and ideally Diamond...

There seem to be several approaches:

• Use the FPGA itself to implement the USB interface (Tiny FPGA)
• Use a FTDI device as the bridge (ice40-hx8k)
• Use a uP with a proprietary interface (iceBlink)

I think I am too constrained for space on my device to use the TinyFPGA approach although it has cost advantages, the FTDI devices are expensive so the third option would seem the cheapest whilst retaining the FPGA for the application itself.

Are there any open reference designs for USB to SPI for ice40 devices that are supported by IceStorm/Diamond?

[mon2]

Gowin announced 'low cost' ASSP USB bridges last week that will support USB to SPI; USB to JTAG; USB to UART; USB to I2C but no confirmation on pricing or lead times yet. They may be of interest to you - available in a QFN32 package.

The Lattice toolchains prefer the FTDI devices which are quite stable. A while ago, did write up some demo code using the XMOS CPU to bit bang out JTAG and did manage to read out the ID and a few other functions but this was with custom code. That is, there will be more value to allow for other tools to make use of this USB to SPI bridge for the ICE40.

[SiliconWizard]

Digilent Adept supports their HS2/3 adapters which are FTDI-based IIRC.

The Upduino boards also contain an FTDI chip for programming (FT232H). Not the cheapest you can find of course, not awfully expensive either (about $3 in quantities), but it just works.
https://tinyvision.ai/products/upduino-v3-0
(Beware: programming is done through SPI with those iCE40 devices, not standard JTAG. The FT232H supports both.)

[NivagSwerdna]

The Upduino boards also contain an FTDI chip for programming (FT232H).

That's interesting.  I already have FT232H in some of my designs so that's very familiar.  I think I might opt for something more programmable though as it supports my application... so I'm strongly considering a small 20-pin ATSAMD11 device that can do a bit of the work that doesn't fit so well into the FPGA... higher complexity but might work better.  I'm not 100% clear on how I would fool the Diamond Programmer into thinking my board is actually similar to an ice40 dev board and allow me to seamlessly program it but I think it might be do-able.

[SiliconWizard]

I'm not 100% clear on how I would fool the Diamond Programmer into thinking my board is actually similar to an ice40 dev board and allow me to seamlessly program it but I think it might be do-able.

It supports FTDI devices only AFAIK. I'm almost (but not 100%) sure they use FTDI libraries for that - which means they access FTDI parts through FTDI provided DLLs. I guess you could "spoof" those DLLs and reimplement the required functions accessing your own device. Looks like a lot of work.

Note that you're talking about Diamond here, but the tools that support the given Lattice parts depend on what you end up choosing. iCE40 parts are NOT supported by Diamond AFAIK? I think you need icecube2 for some, and Radiant for the newer iCE40 parts... That's 3 different tools, and each comes with its own programmer tool AFAIR.

Implementing FTDI compatibility at the drivers level, though, well. I doubt it...

I would look at open-source programmers for those Lattice parts. There are probably a few. Much easier to adapt to your own needs...

[julian1]

The ice40 is tied to ftdi - in the sense that the programming pins needed to hold the ice40 in reset, and to represent ice40 bitstream configuration success are mapped to specific ftdio gpio pins. Programmers - at least iceprog used with icestorm will expect to see and control signals on those specific ftdi gpio pins. 

A board with a dual ft232H is handy - because you can program the ice40 flash to hold the bistream, and implement a spi slave (or uart) in verilog, and talk to it, over the same USB cable/connection. That's what the offical icestick dev board does.

There's actually no requirement to use ftdi/flash though. The fpga could pull the bitstream from a mcu spi port if desired (and the mcu implement usb). But that's a less generalizable approach for a dev board.

[NivagSwerdna]

The ice40 is tied to ftdi - in the sense that the programming pins needed to hold the ice40 in reset, and to represent ice40 bitstream configuration success are mapped to specific ftdio gpio pins.

Ah.  Now that's an interesting observation.  I did notice that ADBUS6 and ADBUS7 were connected to CDONE and CRESET.
I'm starting to get the picture now... (and I was referring to the component called Diamond Programmer that works hand in hand with ICECUBE2).  I did buy a knock off Lattice Programmer that I haven't used yet... that might be the solution using SPI during the development and then I can use my proprietary interface subsequently.
PS
I wasn't proposing any DLL jiggery pokery... just wanted to present a similar h/w interface.

[SiliconWizard]

The ice40 is tied to ftdi - in the sense that the programming pins needed to hold the ice40 in reset, and to represent ice40 bitstream configuration success are mapped to specific ftdio gpio pins.

Ah.  Now that's an interesting observation.  I did notice that ADBUS6 and ADBUS7 were connected to CDONE and CRESET.
I'm starting to get the picture now... (and I was referring to the component called Diamond Programmer that works hand in hand with ICECUBE2).  I did buy a knock off Lattice Programmer that I haven't used yet... that might be the solution using SPI during the development and then I can use my proprietary interface subsequently.
PS
I wasn't proposing any DLL jiggery pokery... just wanted to present a similar h/w interface.

Yeah but your mention of "Lattice programmer" and even more so "Diamond programmer" was confusing then, that's why I mentioned that. It sounded as though you wanted to use Lattice software tools to program your boards with your own hardware interface, and I couldn't see how to do this except by doing nasty emulation through DLLs.

Now if the programming can be handled with your own software tool, then of course you can implement the interface the way you like. It's just SPI and a couple GPIOs that are required.

[NivagSwerdna]

Sorry I have been using 'Programmer' as an overloaded term...

I mean...

https://www.latticesemi.com/programmer which is the Lattice standalone programmer software which is aware of the interfaces to several dev boards and is compatible with Diamond and IceCube2.

And also..

HW-USBN-2B https://www.digikey.co.uk/short/8rdpt7j9

[SiliconWizard]

Sorry I have been using 'Programmer' as an overloaded term...

I mean...

https://www.latticesemi.com/programmer which is the Lattice standalone programmer software which is aware of the interfaces to several dev boards and is compatible with Diamond and IceCube2.

And also..

HW-USBN-2B https://www.digikey.co.uk/short/8rdpt7j9

OK, not sure you could program all devices through just one software tool. So that's just one. But the rest of what I said still holds true. This only supports FTDI chips AFAIK (and, AFAIR, possibly the very old parallel port adapters, which are completely obsolete). So if you want to use this software tool with anything else than an FTDI chip, you'd have to do what I said earlier. Too messy to be considered an option IMO.

Edit: I just saw something else: while the HW-USBN-2B adapters are FTDI-based (and this option can be used with any compatible FTDI really, FT232H/FT2232H), standalone programmer also seems to support HW-USBN-2A (which I personally have never seen), which is shown as an "EzUSB" port, so apparently that would be an earlier adapter based on EzUSB devices (Cypress FX1/FX2). That might be easier to emulate with any other kind of MCU that has an USB controller, although you'd need to know their protocol. Good luck, as it's likely completely proprietary.

As I suggested though, there are open-source sofftware programming tools for iCE40 devices, so that's an alternative to the non-modifiable Lattice tools.
The following for instance: https://github.com/imodularsynth/WinICEProg
It only supports FTDI adapters, but modifying it for supporting another kind of hardware shouldn't be that hard.

Of course all I mentioned was in case you absolutely didn't want to embed FTDI chips on your boards. If you don't mind, then you can absolutely use Lattice tools directly.