Lattice Radiant - No FIFO

[Ice-Tea]

Is there crud in my eyes or is there no FIFO option in the IP catalog? I mean... why?? This doesn't seem normal to me.. I'm well aware I can roll my own but I shouldn't have to.. This should be a total no-brainer.

Again, am I missing something?

[SiliconWizard]

There isn't indeed.
All in all, Radiant's IP catalog is quite spartan. (No pun intended )
There's also a very limited set of memory primitives.

[Ice-Tea]

Do they plan to add it? Pretty sure it has been in any IDE I've used in the last 20 years or so.. This is just nuts.

[SiliconWizard]

No clue.
The iCE40UP series are pretty capable little FPGAs, but Lattice's support looks quite lacking compared to their MachXO2/3 series...

As you said, you can implement FIFOs yourself, but having ready-made and validated FIFOs is certainly a plus. Especially if you need a FIFO to cross clock domains, they are not completely trivial to implement 100% problem-free.

[asmi]

The iCE40UP series are pretty capable little FPGAs, but Lattice's support looks quite lacking compared to their MachXO2/3 series...

They are toy FPGAs.

As you said, you can implement FIFOs yourself, but having ready-made and validated FIFOs is certainly a plus. Especially if you need a FIFO to cross clock domains, they are not completely trivial to implement 100% problem-free.

Since these are toy FPGAs, there is no hardware support for FIFO - hence no primitive as additional logic resources would be required to implement FIFO. You can take a look at "Sensor Interface and Preprocessing" reference design (FPGA-RD-02048) - there is "afifo_8" module which should be a good starting point if you don't know how, or don't want to implement your own FIFO implementation. I didn't use it myself as I don't have these FPGAs but the code seems fairly straightforward.

[OwO]

I always just use my own FIFO implementation and inferred ram so that I need no effort to port between FPGA vendors. I don't use vendor provided IP other than for hard blocks like PLLs.

[Ice-Tea]

Not sure why you'd call them toy FPGA's. They fill a nice gap between some MAX10 devices. Those seem to be either so small you'd have your PCB vendor running for the hills or so big it stops making sense for a "small" FPGA.

I wanted to use the hard IP for I2C. Was faster to just make my own. I wanted to do a quick test with the embedded LED drivers. There's a 50-page manual for that. And after reading that I still don't have a clue on how to turn on a LED. I don't really get it. There are some niffy features that seem too hard to use without stupid effort and other stuff that is probably well supported in the newfangled open source is MIA in this IDE.

I just don't get it 

[OwO]

I wanted to use the hard IP for I2C. Was faster to just make my own. I wanted to do a quick test with the embedded LED drivers. There's a 50-page manual for that. And after reading that I still don't have a clue on how to turn on a LED. I don't really get it. There are some niffy features that seem too hard to use without stupid effort and other stuff that is probably well supported in the newfangled open source is MIA in this IDE.

I just don't get it 

No one uses I2C controller IP in an FPGA (unless we are talking about exposing a I2C interface to a softcore). If there is actually a hardware I2C block then that's absurd design on the part of Lattice most likely meant to tick a checkbox.

I don't use Lattice FPGAs because (1) not good bang for the buck; XC6SLX9 is under $4 and way more powerful; (2) strange design decisions like using a weird SPI based protocol for programming rather than JTAG. I avoid any FPGA or MCU that does not use industry standard JTAG or SWD for programming.

[Ice-Tea]

No one uses I2C controller IP in an FPGA (unless we are talking about exposing a I2C interface to a softcore).

Nothing dignifies labor so much as the saving of it.

So it made sense to me if it could be easily implemented. Guess not.

[iMo]

I messed a lot with porting a 16bit forth mcu into ice40up5k. I was also thinking to incorporate the hardened spi and i2c. Have not found enough energy to do..
The interface looks simple, but you need an 8bit soft controller. Still waiting on some simple examples.
The most useful so far are the smallest ice40LP384 in my case, you may put a lot of logic inside when playing with something special.
A disadvantage of those ice chips is you need an external flash or an mcu for storing the bitstream. Lattice acquired an ice40 vendor years back and follows a minimal effort strategy with it, it seems.

[Berni]

Yeah the only good thing about Lattice is that the chips are cheaper for the small parts. Nice fit for places where you need a little FPGA to only do a few simple things that are hard to do for a MCU. The IDE is not the best but its good enough to do the job (At least for MachXO)

Oh and the hardware I2C and SPI block is a joke pretty much. Its actually a memory mapped I2C controller like you would find in a MCU so you have to talk to it via a wishbone bus. This only really is convenient if you have a softcore MCU inside and on such a small FPGA you usually wont. The complexity of HDL code needed to configure and run these hardcore I2C/SPI controllers trough a memory bus is so high that its easier to build your own I2C controller from scratch in logic instead.

There is one useful thing about these hardcore I2C/SPI ports is that they can be instead configured to work in bootloader mode. This lets you use a external MCU to talk to the FPGA like a slave and do most things JTAG can do. Allowing you to stop/reboot the chip, load a new image to RAM, read ID data, program and read internal flash etc. Tho the documentation on how to do this is awful.

[Ice-Tea]

Good to know my lack of understanding of the I2C itf is not my brain turning to mudd all of sudden

[TimCambridge]

Yeah the only good thing about Lattice is that the chips are cheaper for the small parts. Nice fit for places where you need a little FPGA to only do a few simple things that are hard to do for a MCU. The IDE is not the best but its good enough to do the job (At least for MachXO)

Also non-volatile. And the XO2/XO3 have a particularly flexible PLL - digital control, fractional synthesis, multiple outputs.

[Bassman59]

Oh and the hardware I2C and SPI block is a joke pretty much. Its actually a memory mapped I2C controller like you would find in a MCU so you have to talk to it via a wishbone bus. This only really is convenient if you have a softcore MCU inside and on such a small FPGA you usually wont. The complexity of HDL code needed to configure and run these hardcore I2C/SPI controllers trough a memory bus is so high that its easier to build your own I2C controller from scratch in logic instead.

I recently used a MachXO2 in a design, and I thought I'd use the built-in SPI and I2C blocks. Oh, the Wishbone interface, thanks for making the interface a lot more complicated than necessary. I thought about putting a Mico8 in the design to deal with those two blocks and it could also do some math. That was a rabbit hole I spent a couple of days down until I decided to punt on all of it and just did everything in VHDL with standard state machines, no micro at all. The design ended up having three SPI ports and it was easier to just make them all separate with their own control machines.

[Berni]

Well to be fair the wishbone bus is great if you want to hook it up to a softcore CPU, its basically like talking to synchronous SRAM memory. Just have to ignore all the fancy advanced features of the bus (that are probably rarely used anyway).

I think this hardcore I2C controller was just Lattice being clever and repurposing existing circuitry in the FPGA to make a new feature out of it. This I2C/SPI controller is there to boot the FPGA from external memory as is standard practice. There is probably a tiny hardcore CPU next to it that configures all of the FPGA fabric on start up and this is talking to the I2C controller over the usual memory bus as most MCUs do. So someone got the bright idea of simply putting a MUX between the CPU and its peripherals to switch the bus to those peripherals over into the FPGA fabric. Cost them just a bandfull of extra transistors to do.

Might be a neat trick in efficient dual use of transistors in the chip, but in a small FPGA like this its completely useless.

If you think about it why would you even need a hardcore SPI controller? With just a handful of logic cells you can implement a SPI bus running over 100MHz without any optimization effort. If you optimize it to use some dedicated stuff in the IO cells that could go past 300MHz no problem. And if we want to go even faster then we got serdes.

[iMo]

L. Radiant supports the iCE40UP chips only. The hardened 2xSPI and 2xI2C are not related to the programming interface, afaik. The programming interface is an SPI as well and I've been using the wiring (bitbanging) for writing/reading data into/from the 4MB bitstream flash (from the fpga's fabric userland).

The 5k LUTs (UP5k) allow for a simple soft controller messing with the hardened modules (you may need a few hundreds LUTs for it).

The UP5k for example has got only 15kB BRAM, the 1kB is most probably reserved for the hardened interfaces (as I assume it has got 16kB on chip in reality).

Out of my UP5k forth mcu I can access the internal 128kB SPRAM pretty easily, thus accessing the 8bit bus of the hardened interfaces cannot be a big problem. The interrupts are also implemented.
The hardened interfaces are prepared for using an FIFO, afaik.

PS: I've opened my Radiant and tried with generating I2C and SPI. There is a GUI IP generator, you set all possible parameters, and you get ie. verilog files. The appnote says it generates a soft ip "loader" which loads the selected SPI/I2C configuration bits into the hardened registers and then releases the bus for user fabric. On the first glance it looks like the mechanism is coded in there.

[SiliconWizard]

Just a quick note: the latest Radiant release (1.1) includes FIFOs in the IP catalog.

[Ice-Tea]

Lovely. If only I hadn't finished coding yet

Ah, well, next project.