On the Altera Cyclone 10 site they have a link to the "buy online" parts and prices, includes also the Evalboard (EK-10CL025U256).
The link text says: "Available today" but the available quantity for all parts is 0 (zero, nothing).

Here is a comparsion to the already available ECP5 parts from Lattice:

Here is a comparsion to the already available ECP5 parts from Lattice:

Interesting. I see the Cyclone TQFP144 pin package goes only up to the 10CL025.
The ECP5 parts have BGA only, but there is a 10mm BGA in the smallest 12K version, and Cyclone has 10CL010 & 10CL016, in 8mm BGA

The free version of the Toolchain only supports the devices without serdes, but the promo boards have the ones with serdes mounted. So my understanding is you can not use the whole FPGA without a license.

I'm pretty sure it's always the same die, they can enable and disable some functions of the chip and can change the ID.
I also think the 12k LUT version is the same chip as the 25k LUT, the toolchain just limits the resources according the ID.

Maybe you can do the same with the Prop2: Versions with half the Smartpins, or only 8 cogs max, all with the same chip and some fuses. But I'm pretty sure you will not

Chip ...
Maybe you can do the same with the Prop2: Versions with half the Smartpins, or only 8 cogs max, all with the same chip and some fuses. But I'm pretty sure you will not

Because the package and testing do not change, there is less scope for Parallax to make a psuedo-family (single die).
That said, the idea is common, and it could be worth allowing for.
Where it can make sense is if yields are an issue, or there is some psychological price barrier that needs a 'loss leader' to get peoples attention.
I've not seen prices indicated yet on P2 that would 'frighten the horses'.

It makes a lot more sense in a FPGA module / crowd funding thrust, to chose some useful subset of P2 based on price point.
If such a module encompasses both P1 and P2 choices, and the right price point, it can have life after full P2 commercial release.

Interesting that Intel/Altera is using an improved 60nm process for the Cyclone 10.

IMHO, Altera's pricing model has always been weird. Usually just unrealistic single unit pricing, and for volume you had to put forward you whole plan to get pricing directly from Altera. And if you were lucky, they would respond.

Perhaps Intel is going to change the pricing model which should open up a lot more markets. Currently (previously) it's just too difficult to design a lower volume design using Altera FPGA's. Xilinx was simpler to deal with, but that was more than 10 years ago so thing may have changed there too.

Interesting that Intel/Altera is using an improved 60nm process for the Cyclone 10.

IMHO, Altera's pricing model has always been weird. Usually just unrealistic single unit pricing, and for volume you had to put forward you whole plan to get pricing directly from Altera. And if you were lucky, they would respond.

Perhaps Intel is going to change the pricing model which should open up a lot more markets. Currently (previously) it's just too difficult to design a lower volume design using Altera FPGA's. Xilinx was simpler to deal with, but that was more than 10 years ago so thing may have changed there too.

Andy I can do a breakout but don't have time to get to grips with another FPGA brand, do you have anything up and running with Lattice?

Lachlan, I have already made a board, and will soon try to assemble it. Lattice is my favorite FPGA manufactor, because I like their little cheap FPGAs. They have single supply devices with flash on chip since many years (XP2, MachXO2).

I have done a lot with Lattice devices, but not tried a P1V so far. There are many other FPGA CPUs which are more resource friendly. On little FPGAs that matters.

The usual Lattice devices are too small for a full P1V, this has changed now with the ECP5.
Lattices architecture is quite similar to old Xilinx devices, so I think a Xilinx version of P1V should compile (with some adaptions for PLL and maybe memory).

I'll add a table of the smaller Lattice parts, as I see the choices are expanding - with the 128K bytes RAM, these can now be considered 'smart memory'

Seems to me that by the time one decides to go for an FPGA solution there is no point in putting a P1 in there.

I mean why use Propeller cores and software for all that bit banging peripheral functionality when the same peripherals could just be created in Verilog?

So for example a RISC V core fits into Lattice devices with plenty of room left over for peripheral logic.

When would it make sense to put a P1V into the FPGA solution?

When would it make sense to put a RISC V in a FPGA, when you can always buy an mainstream 32b MCU cheaper and/or faster ?
Flash Speeds often impose wait-states, but I see ~200MHz is appearing at the mid 32b MCU space.

The whole point of FPGA is it allows you to move outside the square, and gives choice.

You can choose if you do peripherals in Verilog, and so remove a COG, or get better performance.

You can even choose to put in RISC V and some COGs !

P1V provides a means where you can literally be in 2,3,4+ places at once, in software, and with 1 SysCLK granularity.

That's simply not possible in RISC V : drop in a Load-Store MPU, and you get the same MPU issues

I've tried this. Was never able to program the finished product. It's not detected by propman either. I just tried with the latest icestorm. No go! Although, I do see an attempted I2C read. Maybe I should test with a pre-programmed EEPROM.

These parts are quite small. To fit a HX8K I reduced to 2 cogs, 8kB hub ram, and 4kB rom.

Seems to me that by the time one decides to go for an FPGA solution there is no point in putting a P1 in there.

I mean why use Propeller cores and software for all that bit banging peripheral functionality when the same peripherals could just be created in Verilog?

So for example a RISC V core fits into Lattice devices with plenty of room left over for peripheral logic.

When would it make sense to put a P1V into the FPGA solution?

While RISC-V + Verilog gives you the most possibilities and the smallest LUT size, it is just no RAD Tool, like the Propeller:
- Defining all those pins and modes until you can start to code is like doing your Tax declaration.
- If you change something in the Verilog, you have to wait minutes (hours ?) for synthesis until you can try the code.
- Only few engineers can do FPGA developement, while many can do Propeller programming.
- Toolchains for FPGAs take Gigabytes while an IDE for a P1V can be made with some MegaBytes and can work everywhere.
- and so on..

With P1V you can have both worlds, Implement the fast peripherals that a Propeller not can do in Verilog (HDMI, external Memories, USB, Ethernet), and use then the cogs for the rest.

I think we need to differenciate between the original Lattice parts and the ICE40 series, which was SiliconBlue and later bought by Lattice. They are very different.

The ICE40 have no onchip Flash, are much slower (exept the HX) and the Toolchain is very limited. BlockRam is 8 bit wide (no parity bit) and Multipliers 16x16, not the standard 18x18. But there is an opensource toolchain for them.
The new UltraPlus devices look interesting with the big Ram, but the QFN48 is not really available if you want to buy < 2000 pieces. And they are not yet supported by the opensource toolchain.

The small Lattice FPGAs that I like are the genuine ones like MachXO2/3 and XP2 series. They are much more powerful. Alot of packages with onchip Flash. Lattice still adds new devices to the quite old MachXO2 serie, QFN32, QFN48 variants for example.

I'm not sure if the Lattices synthesis engine supports the SystemVerilog extensions, that Chip's original P1V verilog code needs. The Xilinx one does not, That's why I would try a Xilinx adapted version of te P1V first.

I use the same DTR reset code as Magnus. That doesn't seem to be the problem. I think I have bidirectional IO working. That wasn't supported when I first started with icestorm. The core seems at least partially functional, so I'm going to pre-load some PASM into RAM/ROM.

The ideal way to program a P1V might be pre-loading the RAM. The icebram tool should allow the RAM contents to be replaced without recompiling the Verilog. Most FPGA boards have configuration flash, so the EEPROM is redundant. And this should free up some ROM to be used as more RAM. Very important on the HX8K with only 16kB total RAM.

The ideal way to program a P1V might be pre-loading the RAM. The icebram tool should allow the RAM contents to be replaced without recompiling the Verilog. Most FPGA boards have configuration flash, so the EEPROM is redundant. And this should free up some ROM to be used as more RAM. Very important on the HX8K with only 16kB total RAM.

That makes sense, and on those FPGAs that have RAM init feature, you could include a complete memory image and so init/clear RAM variable, which saves more valuable code space...
I guess the most compact form could have N hex files, one for each supported COG, and one to init HUB memory.

I have a couple of these MachXO2-1200/7000 breakout boards, they are great. With one of them I program my own board too (it has a LCMXO2-7000ZE), I just use the JTAG pins. But the iCE parts do not have JTAG... I bought a couple of iCE5LP parts for tests (ICE5LP1K-SG48ITR50)... now I am a bit lost on how do you program them... (I would buy a suitable breakout board but they are not that great anymore in bang-for-buck).