Achronix Semiconductor in Talks for Merger

An IPO of sorts really. They would merge with ACE Convergence Acquisition Corp NASDAQ: ACEV and this company would be seeking investors.
Achronix has been profitable, so this should be a good deal. I'm looking to buy in.
--
Rick C. 

- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
Loading thread data ...
Corp NASDAQ: ACEV and this company would be seeking investors.
to buy in.
These IPOs done through SPACs are trying to take advantage of market exuber ance which will surely pass at some point. It might be easy to get burned when everything turns. I'm suspicious of new fads in the dark financial ar ts.
I don't know much about Achronix, except that I believe they no longer use any of the asynchronous architecture on which they were originally based. Maybe they should change their name to Chronix? But that sounds like Dr. D re album or a persistent disease. I'm not sure how they survive in a marke t ruled by the duopoly, but they must be doing something OK, since they're still around.
Reply to
Kevin Neilson
on Corp NASDAQ: ACEV and this company would be seeking investors.
g to buy in.
erance which will surely pass at some point. It might be easy to get burned when everything turns. I'm suspicious of new fads in the dark financial ar ts.
Sounds like the POs from Tesla.
e any of the asynchronous architecture on which they were originally based. Maybe they should change their name to Chronix? But that sounds like Dr. D re album or a persistent disease. I'm not sure how they survive in a market ruled by the duopoly, but they must be doing something OK, since they're s till around.
They seem to be doing a lot more than just OK.
--
Rick C. 

+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
They moved to a different market, their main product is an embedded FPGA IP core (and associated expensive to develop backend tools). Given the cost of making an ASIC/SoC and time to market pressures it makes sense to add some reconfigurable bits so you can fix some "oopses" and add features after tape-out.
Hans
formatting link

but they must be doing something OK, since they're still around.
Reply to
HT-Lab
ion Corp NASDAQ: ACEV and this company would be seeking investors.
ng to buy in.
uberance which will surely pass at some point. It might be easy to get burn ed when everything turns. I'm suspicious of new fads in the dark financial arts.
use any of the asynchronous architecture on which they were originally base d. Maybe they should change their name to Chronix? But that sounds like Dr. Dre album or a persistent disease. I'm not sure how they survive in a mark et ruled by the duopoly,
I don't think it is the "oopsies" problem they are addressing. If you have an "oopsie" it is unlikely to be fixable with a separate piece of logic. Allowing an ASIC user to add a bit of logic to the device or even a custom coprocessor can be very useful. I seem to recall someone offering such a c hip once, but I don't recall any details. It never made it to a general ma rket that I know of. I suspect it was mostly sold to OEMs with high volume s. Often FPGAs are used as prototyping devices and that may have been how this was used.
--
Rick C. 

-- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
No that is exactly what it is used for. By adding bypass logic to an "eFPGA" there is a good change you can fix bugs after tape-out. And yes designers do know which blocks are most likely to have issues.
This is obviously not new, microprocessor manufacturers have been doing this for decades. I am always amazed at the issues AMD and Intel can fix after tape-out, I am sure the patched microcode is not just some simple ROM code that changes the instruction sequencer.
Hans
formatting link

Allowing an ASIC user to add a bit of logic to the device or even a custom coprocessor can be very useful. I seem to recall someone offering such a chip once, but I don't recall any details. It never made it to a general market that I know of. I suspect it was mostly sold to OEMs with high volumes. Often FPGAs are used as prototyping devices and that may have been how this was used.
Reply to
HT-Lab
ition Corp NASDAQ: ACEV and this company would be seeking investors.
king to buy in.
exuberance which will surely pass at some point. It might be easy to get bu rned when everything turns. I'm suspicious of new fads in the dark financia l arts.
r use any of the asynchronous architecture on which they were originally ba sed. Maybe they should change their name to Chronix? But that sounds like D r. Dre album or a persistent disease. I'm not sure how they survive in a ma rket ruled by the duopoly,
GA
ave an "oopsie" it is unlikely to be fixable with a separate piece of logic .
Do you have any info from Achronix regarding this? While the technique is not uncommon in various devices, I don't think they are very large pieces o f logic. If they aren't large, is it really important to have the fastest technology in them (which is the Achronix advantage)?
There was a device made by a European chip company that had embedded FPGA. I never saw anything about it being to "fix" the chip.
If the chip is being used for prototyping, that is entirely different and n ot an ASIC at all. Why design a chip to debug the chip you are going to de sign? What they do talk about at the Achronix web site is lots and lots of "networking" and some very high speed interfaces. Rather than fixings opp sies, I expect they are supporting leaving portions of the your ASIC to be implemented in gate software rather than hard wiring. That would seem to m ake a lot more sense.
--
Rick C. 

-+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
Is an FPGA a good fit for that?
It's not unusual to add 'chicken bits' that allow particular parts to be disabled or bypassed. But ISTM there's a bit of a disconnect between that and a full-scale FPGA. Unless you implement your entire block in FPGA logic, it's always going to be faster to implement your risky logic in several hard-logic ways and use routing controlled by chicken bits to select. You pay an area cost for that, but retain ASIC performance - I'd imagine even the best FPGA logic is going to be much slower.
I could see some FPGA use cases where you want to do, say, hardware video decode (for power reasons perhaps) but need to periodically update to the latest codec. Similarly when doing packet processing and you need something to handle the customer's special flavour of packets at line rate.
But going embedded FPGA means you pay a performance cost over hard ASIC cells, and you'll pay that performance cost even if everything works first time. I can't quite see going FPGA making sense for speculative bug fixes alone.
Theo
Reply to
Theo
I'd like to know too. Or actually I'd like to know the size of the eFPGA market, the customers and who has what market share and what it's actually used for but all that seems secret. But there are new(ish) companies exclusively in that market, at least Flex Logix (although they've come out with some kind of ML FPGA chip now) and some old ones have joined up too. Even FPGA old timer QuickLogic came out of what I think of near death to play in that business.
Reply to
Anssi Saari
GA
What I've found interesting is there are very limited options for MCU/FPGA combinations. The available choices are rather large and expensive. Like there are
Reply to
gnuarm.deletethisbit
I'd be quite interested in something that's an MCU first, but with an FPGA component. Most of the offerings seem to be primarily an FPGA but with a hard core instead of a NIOS/Microblaze/etc. That brings with it the downsides of having to manage an FPGA toolchain with the downsides of having to implement lots of things in a custom way.
I've used the Cypress PSoC line for things - they have a tiny amount of programmable logic, but it's very limited. Something with a few kLUTs would be nice, being mainly an MCU with all the regular MCU stuff (SPI, I2C, timers, ethernet, USB, CAN...) but with a peripheral that's some programmable logic hooked up to the internal bus and wired into the existing pin mux. You implement your function in FPGA logic and it sits alongside all the other hard peripherals. You simply flash that logic into the part at the same time as you flash the software image.
Theo
Reply to
Theo
PGA
e
h
s
ng
A
ing
ld
ing
I pretty much agree with you. I'm not clear on what would be best in terms of the interconnections for the FPGA section. It would certainly be usefu l for the FPGA to be on the MCU bus, but how many address bits, 8, 16 or 32 bit data connection? How many FPGA I/Os will require pins? I don't agree with mixing the FPGA I/O pins with the MCU peripherals since the FPGA I/Os naturally mux within themselves. I'm not sure of the performance penalty of running the FPGA I/Os through the I/O mux. I know the current design I have which may get redone with a Gowin part needs some decent I/O speed to work. One timing parameter on an interface was not well thought out and re quires an output to be driven and received by the other device in a half of a 33 MHz clock cycle or 15 ns. I was worried about being able to meet tha t timing number since the output delays add up. Run the input and output t hrough the I/O mux and it might not work anymore. But who knows? Maybe th ese newer, smaller design rule parts are that much faster they would work f ine. ???
I'm also not sure I want the FPGA to be flash if it has an MCU on chip. Ma ybe let the MCU boot the FPGA from the program store so variants can be boo ted depending on what is connected, etc. Many years ago Xilinx was working on partial reconfiguration in a way that would allow sections of the chip to be independently designed and configured. I think they never got it rea dy for prime time and only really ever saw it in a small number of high vol ume designs with lots of customer hand holding by the Xilinx experts. That 's actually how Cypress got started with their PSOC devices. They didn't h ave the fancy software working very well, so they had weekly design seminar s which were really just conference calls for you to pick the brains of the experts. Great way to get started with the parts, but still not great in place of workable tools. I believe they have much better tools now. I hel ped someone port a Forth to one of the PSOC ARM devices that actually was n ot programmable in a real sense, it has very flexible serial controllers so the same hardware could do SPI, UART or I2C if I recall. I figured out ho w to install a UART so the Forth could boot up and give a command prompt. Funny actually. The one small family of non-programmable PSOC devices.
--
Rick C. 

++ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
Atmel had an AVR with an FPGA many years ago - I don't know how successful it was. At the time, I thought it was an interesting idea but never had a project that needed it.
A lot of the available devices are, as Theo says, too limited. PSoC's have some programmable logic - but its far too limit. It's one thing to say that the logic makes the device flexible - it can be used for an
You don't want programmable logic for these things that are commonly found as fixed peripherals - you want the logic for odd things.
I'd want 32-bit to dual-port ram blocks and some uncommitted registers (uncommitted from the FPGA side, but fixed addresses on the cpu side). No one would make such a device with a cpu less than 32-bit, and the 64-bit world has fast buses dedicated to FPGA accelerators and the like. It would seem crazy to limit the connection to anything less than full speed on the cpu side.
I'd also want the FPGA to be able to work as a bus master on the cpu data bus side. This is essential to be able to make accelerators and DMA components in the FPGA.
Here I disagree. Mixing FPGA and MCU pins is exactly what I would want. You'd be free from the usual MCU limitation of having lots of hardware peripherals but not the right pin mux choices to let you have exactly the combination you want. And you'd be free to take advantage of combinations, without having to route signals back on the outside of the device (say you want to use an internal UART but with the data used to modulate a carrier signal). You want this kind of routing to be done internally, not via the pin drivers.
I think the delays from the fixed peripherals would be smaller and more predictable than the FPGA fabric. But some pins would remain dedicated - you'd want things like QSPI and other fast memory buses, Ethernet, or FPGA SERDES pins to be dedicated to appropriate hardware peripherals or FPGA fabric.
Certainly I'd want the MCU to be able to control loading the FPGA image.
Modern high-end MCUs are now often without flash. You don't want flash on the same die as the MCU - the optimal production processes for flash and high-speed logic are too different, and you end up limiting both the MCU and the flash. Look at the NXP RT10xx series - you have a 600 MHz Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined with an external QSPI flash chip, is cheaper than a typical 120 MHz M4 microcontroller with a fraction of the flash, and the QSPI flash runs faster than on-die MCU flash. (There are some RT10xx devices which include flash - it is a separate die, in the same package, which is nice.)
So external QSPI flash (or external die, internal package) is the way to go IMHO.
I remember hearing about that kind of thing (Altera had something of that sort too, I think?). Wasn't it only available on their paid-for subscription versions of their tools? Keeping a technology out of the hands of amateurs, learners, experimenters and small users is a sure-fire way to make sure no one uses it.
(Even though I haven't used programmable logic much for a long time, I still try to keep up with what's happening in the FPGA world.)
Reply to
David Brown
I haven't taken a close look but QuickLogic has come out with this kind of chip, Cortex M4-F and embedded FPGA on the same chip. Looks like it's smaller than a few kLUTs and doesn't have that much in the way of MCU peripherals though.
Reply to
Anssi Saari
...
Some NXP LPC parts have programmable logic for their IO, to implement at least custom serial/parallel logic.
--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes
They called it a SLIC or something similar. It used a proprietary 8 bit MC U that may or may not have been an AVR. At the time it was not anything I' d seen elsewhere, but that was quite some years back.
The FPGA was a very poor man's Xilinx part (a beggar's as it were) because most of the technology was still under patent. It was a very expensive par t as well and in the end had a limited life span. In other words, aside fr om being nearly the only FPGA/MCU combo part you could buy, it was a crappy device. I expect the software matched, but I don't know that I ever tried it.
old
Ms.
You've asked for two things that you would not need together. You can eith er DMA data into main memory or your can host memory that the CPU can acces s, but there is little need to do both.
You are asking for things you just don't need. FPGAs are capable of hostin g all the UARTs you want within the FPGA. SPI is a snap. Even I2C is not hard. Why futz with hard peripherals when it only reduces the die area ava ilable for the FPGA? Asking for everything gives you nothing in the end be cause the chip won't be made.
When discussing this with the Xilinx folks who used to haunt the FPGA forum s the reason for not selling such chips was the FPGA makers are not MCU mak ers and their business model did not support as large proliferation of vari ants as the MCU makers. So it would be necessary to limit the number of ha rd peripherals and combinations of FPGA size. That is what Xilinx and Alte ra have done. They focus on a market with a handful of offerings, all aime d at the high end with complex interfaces (supposedly for high performance) and complex tools.
As you said, you want an MCU with a bit of FPGA hanging on the internal bus as an uber-peripheral. That's great, but it's going to require dropping a ll but a minimal set of peripherals and other compromises to simply the per mutations.
Nobody cares about the speed of the hard peripherals since they run fast en ough. I'm talking about the FPGA peripherals. Not everything is a standar d SPI or UART. If you just need standard peripherals you can probably find a good part with the combo you need.
Those are exactly the devices you can already get on an FPGA. Check out th e Xilinx Zynq and the Altera equivalent. They are much too large for me wi th 400 pin packages and big price tags.
Microsemi has a line of MCUs that are more like what I am talking about, bu t the prices are far too high. Gowin is jusssst right at ~$4. They talk a bout versions with SDRAM die in the package, but not on the disti's list ye t.
)
Just get a Zynq already!
--
Rick C. 

--- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
QuickLogic??? Was that the name some 20 years ago??? If you mean Microsem i... opps, that was several years ago, I guess I can't keep up either. If you mean Microchip, their parts are very expensive for some reason. Just n ot an option when you are trying to produce something affordable.
--
Rick C. 

--+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
"SLIC" rings a bell. It was definitely an AVR - which is, of course, an Atmel proprietary 8-bit MCU.
I don't know what the FPGA tools were like for the device. At the time, software tools for the AVR were a bit limited or very expensive (IAR), but they're good now - for an 8-bit device.
I'd want to do both - perhaps not both at the same time in the same peripheral, but both at times. If I were making a peripheral in the FPGA - say, a CAN controller - I'd want it to have a dual-port RAM that can be accessed directly from the cpu. If I were making an accelerator, such as a CRC accelerator, I'd want that FPGA component to be able to access main chip memory.
Look at existing FPGA devices with hard cpus. You'll notice that the have a number of hard peripherals, including timers and UARTs. Sure, you can make these in an FPGA - but you can get more functionality at a much lower die cost and power when they are made as hard blocks. It would be crazy /not/ to put them along with the microcontroller part - they are devices that just about every MCU user wants, and are a completely negligible cost in the silicon.
Remember, while a UART is entirely doable in an FPGA, it is /not/ free. It costs FPGA resources. It costs FPGA developer time and effort (even if it is a ready-made unit). It costs software developer time to support the special FPGA version rather than one they have used before with that MCU.
There would be a balance, of course - you wouldn't put everything that MCU's might have as hard peripherals.
I don't see that at all - especially if it is implemented as a peripheral. When an MCU manufacturer wants to add an Ethernet controller to an existing MCU, they don't start by removing a UART even if they think someone who uses Ethernet will need fewer UARTs.
I thought you were concerned about the timing of hard peripherals here. But if not, that's okay.
By "modern high-end MCU", I mean something like the NXP RT1020 (or 1024 with a flash in the same package). It's about $2.50, with 100 pin LQFP package.
The cheapest Zynq is 20 times the price of an RT1020. And it has a Cortex-A core, not a Cortex-M. It's a different world (though you can solve many tasks with devices from different worlds).
Reply to
David Brown
I typed a reply and when I sent it it crapped out. I'm not typing all that again.
--
Rick C. 

-+- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
gnuarm.deletethisbit
OK, I suppose.
Would this be a good time to point out that if you switch to a proper newsreader like Thunderbird, not only is it much more reliable than using a web browser, but you don't lose you drafts when your connection to the server has a hiccup? In fact, as drafts are saved automatically every so often (or when you choose), you don't necessarily lose them even if the whole machine dies.
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.