Achronix Semiconductor in Talks for Merger

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On Wednesday, January 6, 2021 at 11:35:39 AM UTC-7, snipped-for-privacy@gmail.com
 wrote:
Quoted text here. Click to load it
 Corp NASDAQ: ACEV and this company would be seeking investors.  
Quoted text here. Click to load it
to buy in.  
Quoted text here. Click to load it

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.

Re: Achronix Semiconductor in Talks for Merger
On Thursday, January 7, 2021 at 5:24:34 PM UTC-5, Kevin Neilson wrote:
Quoted text here. Click to load it
om wrote:  
Quoted text here. Click to load it
on Corp NASDAQ: ACEV and this company would be seeking investors.  
Quoted text here. Click to load it
g to buy in.  
Quoted text here. Click to load it
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.  


Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 07/01/2021 22:24, Kevin Neilson wrote:
Quoted text here. Click to load it

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
www.ht-lab.com


but they must be doing something OK, since they're still around.
Quoted text here. Click to load it


Re: Achronix Semiconductor in Talks for Merger
On Friday, January 8, 2021 at 7:37:33 AM UTC-5, HT-Lab wrote:
Quoted text here. Click to load it
.com wrote:  
Quoted text here. Click to load it
ion Corp NASDAQ: ACEV and this company would be seeking investors.  
Quoted text here. Click to load it
ng to buy in.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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,
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 08/01/2021 18:46, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

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
www.ht-lab.com


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.
Quoted text here. Click to load it


Re: Achronix Semiconductor in Talks for Merger
On Saturday, January 9, 2021 at 4:31:18 AM UTC-5, HT-Lab wrote:
Quoted text here. Click to load it
il.com wrote:  
Quoted text here. Click to load it
ition Corp NASDAQ: ACEV and this company would be seeking investors.  
Quoted text here. Click to load it
king to buy in.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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,  
Quoted text here. Click to load it
GA  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ave an "oopsie" it is unlikely to be fixable with a separate piece of logic
.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
Quoted text here. Click to load it

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

Re: Achronix Semiconductor in Talks for Merger

Quoted text here. Click to load it

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.

Re: Achronix Semiconductor in Talks for Merger
On Sunday, January 10, 2021 at 1:47:08 PM UTC-5, Anssi Saari wrote:
Quoted text here. Click to load it
GA  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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 <$5 FPGAs and very cheap MCUs, you'd think there would be <$5 MCU
/FPGA combos.  Actually, Gowin has a line of small FPGAs with an ARM CM3.  
I need to look into these a bit harder.  I don't know if you can trust the  
pricing on the Edge web site, but they show a 9 kLUT part with the ARM for  
under $4.  That's pretty interesting.  The version without extra RAM is ava
ilable in an 88 pin package.  The version with the RAM is not available in  
anything larger than 48 pins at the moment without going to a BGA type pack
age.  

--  

Rick C.

+- Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
Quoted text here. Click to load it

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

Re: Achronix Semiconductor in Talks for Merger
On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:
Quoted text here. Click to load it
PGA  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
h  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
ng  
Quoted text here. Click to load it
A  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ing  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ld  
Quoted text here. Click to load it
ing  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 12/01/2021 07:14, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.)

Quoted text here. Click to load it


Re: Achronix Semiconductor in Talks for Merger
On Tuesday, January 12, 2021 at 2:31:48 AM UTC-5, David Brown wrote:
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it

old  

Ms.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
)  

Just get a Zynq already!  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

--  

Rick C.

--- Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 12/01/2021 18:20, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it


"SLIC" rings a bell.  It was definitely an AVR - which is, of course, an
Atmel proprietary 8-bit MCU.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

I thought you were concerned about the timing of hard peripherals here.
 But if not, that's okay.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).


Re: Achronix Semiconductor in Talks for Merger
On Tuesday, January 12, 2021 at 12:51:03 PM UTC-5, David Brown wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Quoted text here. Click to load it

  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 12/01/2021 20:03, snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it

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.


Re: Achronix Semiconductor in Talks for Merger
Quoted text here. Click to load it


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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...
https://hackaday.com/2017/03/04/reading-the-unreadable-srom-inside-the-psoc4/

Theo

Re: Achronix Semiconductor in Talks for Merger
On Wednesday, January 13, 2021 at 7:05:49 PM UTC-5, Theo wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

g old  

PWMs.  
Quoted text here. Click to load it
y  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  

Quoted text here. Click to load it
'd  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e.)  
Quoted text here. Click to load it
o  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
y  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
Ie,  
Quoted text here. Click to load it
dle  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
d  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
x.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
at  
Quoted text here. Click to load it

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

Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
oc4/  

Those darn hackers!  

--  

Rick C.

++- Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Achronix Semiconductor in Talks for Merger
On 14/01/2021 01:05, Theo wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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:

<https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1024-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1024

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.)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Site Timeline