The cheapest FPGA+MCU integration in one chip I ve ever seen in China

[client]

AGM FPGA is a new brand founded in China. which, it integrates an FPGA and an MCU into just one package,and the stange part is, the MCU is compatibe with STM32F4 and the FPGA is compatibe with some Altera/intel models and can be developed by Quartus.

you may check this link on Chinese demestic website TaoBao:
https://shop33530563.taobao.com/?spm=pc_detail.29232929/evo401271b517998.shop_block.dshopinfo.14d97dd6S6ITrG

the official website is:
http://www.agmsemi.com/index.html

[ataradov]

This is cool, but won't be of much use. Documentation is virtually non-existent. And Taobao requires registration to even see the listing, so getting that device outside of China would be next to impossible.

So, it will remain a cool curiosity.

Plus the need to use Quartus for non-Altera parts is questionable.

[tycz]

I was looking at the Chinese FPGA market a couple of months ago and did see this company. The hardware looks interesting but the software is no good. Their Supra software allows three FPGA synthesis options - Quartus, Synplicity, or Yosys. Using Quartus this way violates the license agreement. Synplicity is too expensive to consider (something like $20k). The version of Yosys in their software package couldn't synthesise the two projects I tried. Documentation is awful. The docs are at  www.tcx-micro.com  delivered blog style. The info you need to start is spread out over many articles, not organised in a coherent way.

The parts are actually very easy to buy, compared to those of other companies, and very cheap too. But without real supporting software, who would buy them outside of China?

[brucehoult]

How cheap?

How do they compare to the GOWIN FPGA SoC chips with RISC-V cores?

[tycz]

How cheap?

How do they compare to the GOWIN FPGA SoC chips with RISC-V cores?

The price is $1-2 depending on package, MCU configuration. These are low end parts - 2000 logic elements, not really comparable the Gowin Arora series. More like Cypress PSOC.

[vstrakh]

AGM FPGA is a new brand founded in China

Well, it's not quite new. I have a DS213 oscilloscope which uses their AG1KLP fpga's for FIFOs, and the datasheet rev1.5 for the chip is dated year 2015.

[c64]

How cheap?

How do they compare to the GOWIN FPGA SoC chips with RISC-V cores?

Some single quantity prices from official taobao shop. These parts are direct replacement and pin compatible with EP4CE10 and EP4CE15 (LQFP144 and 1mm FBGA256). Datasheet says it has MCU inside but I could not even find which one.
AG16KL144 ￥26
AG10KL144 ￥20
AG10KF256 ￥22
AG16KF256 ￥26

They also have LQFP176 if you need more pins, but they are more expensive and have SDRAM inside

[c64]

I was looking at the Chinese FPGA market a couple of months ago and did see this company. The hardware looks interesting but the software is no good. Their Supra software allows three FPGA synthesis options - Quartus, Synplicity, or Yosys. Using Quartus this way violates the license agreement. Synplicity is too expensive to consider (something like $20k). The version of Yosys in their software package couldn't synthesise the two projects I tried. Documentation is awful. The docs are at  www.tcx-micro.com  delivered blog style. The info you need to start is spread out over many articles, not organised in a coherent way.

I was looking at them few months ago as well. How did you manage to get Supra? I was trying to download it to see how it works but could not - they upload it to Baidu and it required Chinese mobile to download

[mark03]

This is too bad.  I've often thought a part just like this would be quite useful.  Basically an MCU first---probably higher end, Cortex M4/M7 or similar RISC-V.  Then, enough fabric to implement one or two custom peripherals or accelerators, with full connection to the MCU's peripheral bus.  Maybe something like the smallest Spartan 7.  And of course in the same package selection as the MCU, because the external connectivity needs would not be different from the MCU alone.

[ataradov]

All MCU plus simple FPGA designs would run into the same issue - FPGA software is universally crap. You have state of the art open compilers and then you have to use locked up tools with barely working UI from the 90s.

Having somewhat simple, but fully documented fabric with simple tools would be great, but I don't see this happening any time soon. It does not even need to support any standard HDLs. For simple designs, a reasonable proprietary description language would be fine.

[SiliconWizard]

For "performance" applications, you have full hybrid FPGA with CPU hard cores.
For the lower end, you have MCUs with flexible IO blocks, such as FlexIO for NXP or the PIO of the RP2040. Some (few) MCUs do have reprogrammable logic blocks with a simplified language.

There's no real intermediate (apart from these AGM chips) yet. I'm not sure the market would be that large.

Otherwise you also have the XMOS chips.

And single-chip solutions are great, but you can always add a small FPGA to your MCU (for a couple bucks) and have a lot more freedom and better tools. Sure communication between the two won't be as efficient as they won't share a common bus, but if you're looking for a modest MCU with a modest FPGA built-in, I'm not sure communication speed between the two is really going to be an issue. Otherwise, go for a "proper" hybrid. Just a thought.

[langwadt]

For "performance" applications, you have full hybrid FPGA with CPU hard cores.
For the lower end, you have MCUs with flexible IO blocks, such as FlexIO for NXP or the PIO of the RP2040. Some (few) MCUs do have reprogrammable logic blocks with a simplified language.

There's no real intermediate (apart from these AGM chips) yet. I'm not sure the market would be that large.

Gowins GW1NSR-LV4C ?

[iMo]

An MCU of choice plus the cheapo ice40LP384 (384 LUTs) looks to me as the simplest to use combo for smaller stuff.
LP384 was the first fpga with Yosys support, afaik. It is not a fast fpga, however. The bitstream may come from the MCU so no need for the bitstream flash (384 could be used as OTP as well). Years back I even created a DIL28 "stamp" for it.

[mark03]

It's true, splitting MCU + FPGA into two chips is no big deal, and gives more flexibility to choose each one.

On the other hand, I see no technical reason why combinations of the two aren't available, only reasons due to social/human shortcomings, such as those ataradov mentioned above.  I mean, vendors are eager to stuff everything else we don't need into their MCUs, why not fabric?  So I reiterate: it's unfortunate.  Needing programmable logic in your design doesn't mean you want to run Linux on an applications processor... so this is really another manifestation of the missing low end in FPGA offerings ("low" meaning low cost, low power, and low pin count).

My hypothetical part could come from either team MCU or team FPGA.  Team FPGA, except for Lattice and perhaps the Chinese, has abandoned the low end, so not interested.  Team MCU doesn't have the tools (or a high enough opinion of their users---and they might be right).  Perhaps RISC-V will make it feasible for a player on team FPGA to do this with lower investment.

[ataradov]

I discussed that with people close to design/manufacturing (from the MCU side). And one thing that comes up often is additional verification effort. The way verification and manufacturing testing are setup for the MCUs would not translate to FPGA fabric. This raises the bar enough that it makes no financial sense. A few hobbyist wanting a device like this will not cover the additional effort. And I guess customers and marketing people don't push for such a device.

Although finding the right balance may open a lot of opportunities. Pi's PIO certainly did. And having more flexibility would open more. But this will definitely won't come from Western companies, they are way too risk averse. So, hopefully Asian vendors could come up with a well documented and obtainable device like this.

And then there is additional load on the customer support side of things. You will have to train an army of FAEs and sales people on how to use and sell those devices. A random unknown Chinese company can get away with a half translated datasheet with a lot of information missing. Microchip or ST won't be able to do the same.

[SiliconWizard]

For "performance" applications, you have full hybrid FPGA with CPU hard cores.
For the lower end, you have MCUs with flexible IO blocks, such as FlexIO for NXP or the PIO of the RP2040. Some (few) MCUs do have reprogrammable logic blocks with a simplified language.

There's no real intermediate (apart from these AGM chips) yet. I'm not sure the market would be that large.

Gowins GW1NSR-LV4C ?

Haven't looked at this series yet, but looks like one.

[SiliconWizard]

And then there is additional load on the customer support side of things. You will have to train an army of FAEs and sales people on how to use and sell those devices. A random unknown Chinese company can get away with a half translated datasheet with a lot of information missing. Microchip or ST won't be able to do the same.

Yep. That's a big point. Also markets are a bit different.
Documentation and support for chinese chips is often terrible.

In terms of verification, in chinese chips, it's much, much more common to see SoCs made of a number of separate dies even on cheap devices, while it's far less common for cheap ICs in western devices. Different approach for a number of reasons. So they'll essentially connect dies that are sometimes from completely different manufacturers (not necessarily all from a single one) which have been verified and tested separately. The whole SoC still needs to be verified of course, but that's less of a burden than putting everything on the same die.

[tycz]

I was looking at the Chinese FPGA market a couple of months ago and did see this company. The hardware looks interesting but the software is no good. Their Supra software allows three FPGA synthesis options - Quartus, Synplicity, or Yosys. Using Quartus this way violates the license agreement. Synplicity is too expensive to consider (something like $20k). The version of Yosys in their software package couldn't synthesise the two projects I tried. Documentation is awful. The docs are at  www.tcx-micro.com  delivered blog style. The info you need to start is spread out over many articles, not organised in a coherent way.

I was looking at them few months ago as well. How did you manage to get Supra? I was trying to download it to see how it works but could not - they upload it to Baidu and it required Chinese mobile to download

Here is the correct place to download the latest version (as well as an archive of all the old versions) of Supra. This is important, because there other links to download it scattered about tcx-micro.com and they point to an old version.
http://www.tcx-micro.com/doc_25499541.html

As for how to download from Baidu, at first I used the service of https://baidudownloader.com paid my $1 and got the file. When I realised I had an old version, I found some kind of free automated baidu download service to download it from the other location. I don't remember what it was called now (these things come and go). 

[ZaneKaminski]

I did actually port a design to one of AGM/Alta-Gate AG256 parts, just for fun. AG256 is pin-compatible with Altera MAX II EPM240 and I already had a MAX II-based design that was easy to adapt.

I had to use the sketchy Supra and Quartus arrangement to compile it but it did work. My original design used the MAX II's user flash memory, so I had to port that to the AG256's SPI NOR flash-type UFM interface. Easy enough and actually the code came in handy when we ported this design to another FPGA family that doesn't have internal user flash. Everything worked fine on the AG256 in my brief testing. The design ran at 62.5 MHz, by the way, which is pretty fast for the lowest speed grade MAX II. I was slightly surprised that the AGM met timing so easily. Of course I did not like, evaluate multiple units at the extremes of operating temperatures and margins of the rest of the system. That's basically the issue with these small manufacturers. Any cost savings from the AGM chip would just be totally blown away by the risk of a problem and the recertification effort we'd have to put in.

[asmi]

I think the reason we don't see many low-to-midrange MCU + FPGA combo devices is that as long as you don't require huge bandwidth of MCU <-> FPGA link, it's fairly trivial to just place any "normal" MCU with any "normal" FPGA - at this performance bracket MCUs typically don't require elaborate PDS setup, nor connection MCU <-> FPGA is any sort of problem (because it typically doesn't require high bandwidth, you can make do with any commodity bus like I2C, SPI, etc.), while having a wide choice of possible MCUs allow to optimize a design according to design priorities (performance, size, cost, toolchain/libraries quality, TTM, etc.). Compared to higher-end setups with full MPU and FPGA, here connection bandwidth might very well become a limiting factor, especially since for some unknown reason SoC manufacturers typically provide very limited choice as far as this connection is concerned - like a single line of PCIE 2 at only 5 Gbps in each direction, and these higher-end MPUs typically require quite complex PDS setup, which goes in addition to what FPGA itself requires.

Just to give an idea, according to Zynq TRM CPU <-> FPGA interconnect is facilitated by over 3000 connections. Obviously it's not feasible to implement that kind of interconnect with discrete devices.