Achronix Semiconductor in Talks for Merger

It's still QuickLogic. I don't know prices though, Mouser lists them as "non-stock, ask for quote".

Reply to
Anssi Saari
Loading thread data ...

d

's

I was confusing them with Actel which has been swallowed up by bigger fish two or three times now. Both were antifuse based FPGA companies. The dif ference is Actel aka ?Microchip actually makes and sells devices. From looking at their web page it appears Quicklogic sells IP and you have to fab your own chips or something. I can't really tell their products fro m their new ideas. But Mouser is not stocking any Quicklogic devices. It' s all call for quote.

They do list the EOS S3 with the CM4F, but other than the eval board which may or may not yet be shipping, I don't see where this chip is sold.

For my needs this chip falls a bit short with 2.4 kLUT "effective". A desi gn I need to port to a new device is currently on a 3 kLUT chip using close to 90%. While in theory some of that design could be moved to the MCU, th e preference would be to initially port the VHDL without modification. If it were 4 or 5 kLUT I would take a more serious look at it. Being partly v aporware at the moment to boot, makes it much less interesting.

--
Rick C. 

+-+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit

Those hard cores are probably lower power too - if you don't use them they get turned off. FPGA logic is not known for being super low power.

By all means implement the MCU pin mux using FPGA routing if you want. That's an argument for the hard MCU to live inside the sea of FPGA, but I'd argue it shouldn't be far from the shore. The default configuration might have the MCU wired to some sensible pins, rather than everything floating unless connected.

It depends where your focus is - my interest is in smaller, PSoC scale, parts (QFN48 sort of thing). You save die area and board complexity with integral flash - yes your parts are slower, but sometimes you don't care about that. For those you might want a flash FPGA, to avoid having to copy configuration as part of a (slow) boot process.

It's actually commonly used these days. A lot of that is for accelerator cards in servers: you program the periphery of the FPGA with the I/Os (PCIe, DDR4, ethernet, etc) and then you can swap in different blocks in the middle for different applications. AWS F1 does this.

Another application relevant to this thread is that the newer Intel parts (Arria 10, Stratix 10) which have an ARM core in the middle use partial reconfiguration as part of the boot process. To bring up the ARM, you need to provide it with some RAM. So first of all you configure enough of the I/Os to allow the ARM to get at its DDR4 channels. Then you can boot Linux. Later on you can program up the rest of the FPGA with whatever logic you want to run on it. Linux provides an API where you can funnel bitfiles at the FPGA logic, with associated device tree parts to teach Linux about what hardware it should expect inside.

The PSoCs are interesting in that they have some kind of firmware inside. Different part numbers have different firmware that enable or disable different features. Of course somebody hacked the firmware to enable the features...

formatting link

Theo

Reply to
Theo

g old

PWMs.

y

That's a common misconception. Just like MCUs, FPGAs come in different pow er consumption lines. The smaller devices have fairly low quiescent power levels and moderate to low dynamic levels. But people have in their minds images of the massive FFT machines with heat sinks on the heat sinks. The Lattice part I used on a board has two options, one with a 1.2V core and th e same chip that uses an on board regulator so runs from a common voltage b etween 1.8V and 3.3V. I build it both ways and never see a difference in p ower consumption. The external regulator is only rated for 50 mA. Neither device ever gets warm to the touch.

Lattice also makes the iCE40 devices with a static current of 100 uA max. When it was SiBlue they were specing it below 40 uA, but I guess Lattice de cided there was no market demand and bumped it up. I wanted to build a WWV B clock using one but never completed the loop on some of the external comp onents. It would be capable of running on a AA cell for over a year like m ost clocks even at 100 uA quiescent.

e

I was thinking that meant using routing for the pins outside of the FPGA, b ut running the peripheral I/Os to the FPGA would provide great flexibility including using them internally in the FPGA.

'd

If it connects to the FPGA routing and the FPGA has lots of I/Os that would be fine. Not sure what "close to the sea" would even mean in that context . Routing in FPGAs is usually under a small handful of ns which is invisib le to most peripherals unless you are talking about 100 Mbps Ethernet. My thinking is typically for less intense designs.

One potential problem is management of the tristate aspects of an I/O. Is that under FPGA control or MCU control? That might be hard to manage well, at least in the standard way of having control registers in the MCU while controlled by discrete signals in the FPGA.

.

e

e.)

o

y

Nearly every part of my designs don't push FPGA speeds. I did have a desig n with one signal that had 15 ns from the clock in to get data out to the o ther chip on the other clock edge, similar to SPI but having to decode the command to select the data. I was worried about making that timing constra int.

A design I'm working on now is using a built in DSP section to do math cloc ked at 30 MHz while they run at 100's of MHz. No speed issues there. Even with that the math section will sit idle for 90% of the time.

Ie,

dle

I guess I should look at the Xilinx tools once in a while. I don't have a use for it now, so no biggie. At the time I was using an FPGA as the inter face for various interchangeable modules, too small to put an FPGA on each one. So a new download was required for each combination of peripherals on four different sites. Lots of FPGA loads to manage.

d

x.

at

I would have expect the memory interface on the chip to be hardwired.

oc4/

Those darn hackers!

--
Rick C. 

++- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit

Yes. I think I mentioned low power somewhere (but not clock gating). And the MCU manufacturers already have the modules - the hard macros for die (and these are /tiny/ - therefore virtually free - compared to an FPGA implementation), the documentation, the header files, the driver code.

I'd definitely want /some/ MCU pins to be direct - at the very least, you want everything involved in booting and debugging (including at least one debug UART) and QSPI for reading in your FPGA image.

Perhaps it would be better to think of internal FPGA input/output connections as just another option in the multiplexer choices for the MCU peripherals and pins. For a given pin, it might have a multiplexer letting you select GPIO, UART, or SPI - just add FPGA to that list. Similarly, a UART might be able to take its input from pin 10 or pin 25

- just add an FPGA signal to the list.

Perhaps. But there are no fundamental reasons why you couldn't do as I suggested and put the flash on a separate die, mounted internally in the same package. Even in a QFN48 there is a big difference between the package size and the die size of the chip - there's room for adding another small die. And vertical stacking inside the package is also possible.

Multi-die packaging, whether it is side-by-side or vertical stacking, used to be /very/ expensive. But it is becoming a lot more common in a range of devices. I don't think it will be long before we see not just flash dies but also ram dies of some kind inside high-end MCU (and FPGA) packages. The big issue with multi-die is power, but that's not going to be a problem in the sort of things we are envisioning here.

Look at the NXP RT1024 to see the concept:

Although the description says "4 MB on-chip flash", it is /not/ on the chip - the die. But it is in the same package. Logically, and in the MCU setup, the flash is an externally connected peripheral.

(If anyone has used National Semiconductor COP8 microcontrollers, this was also how they implemented their OTP devices.)

The devices I have been thinking about would be a bit smaller - not big Linux systems. But I guess technology often starts at the high-end, high profit devices and rolls down to the mass market.

I'll read that link when I get the chance, thanks.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.