Achronix Semiconductor in Talks for Merger

gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:
> 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 available 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 package.

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

On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:
> gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:=20
> > What I've found interesting is there are very limited options for MCU/F=
PGA=20
> > combinations. The available choices are rather large and expensive. Lik=
e=20
> > there are <$5 FPGAs and very cheap MCUs, you'd think there would be <$5=
=20
> > MCU/FPGA combos. Actually, Gowin has a line of small FPGAs with an ARM=
=20
> > CM3. I need to look into these a bit harder. I don't know if you can=20
> > trust the pricing on the Edge web site, but they show a 9 kLUT part wit=
h=20
> > the ARM for under $4. That's pretty interesting. The version without=20
> > extra RAM is available in an 88 pin package. The version with the RAM i=
s=20
> > not available in anything larger than 48 pins at the moment without goi=
ng=20
> > to a BGA type package.
> I'd be quite interested in something that's an MCU first, but with an FPG=
A=20
> component. Most of the offerings seem to be primarily an FPGA but with a=
=20
> hard core instead of a NIOS/Microblaze/etc. That brings with it the=20
> downsides of having to manage an FPGA toolchain with the downsides of hav=
ing=20
> to implement lots of things in a custom way.=20
>=20
> I've used the Cypress PSoC line for things - they have a tiny amount of=
=20
> programmable logic, but it's very limited. Something with a few kLUTs wou=
ld=20
> be nice, being mainly an MCU with all the regular MCU stuff (SPI, I2C,=20
> timers, ethernet, USB, CAN...) but with a peripheral that's some=20
> programmable logic hooked up to the internal bus and wired into the exist=
ing=20
> pin mux. You implement your function in FPGA logic and it sits alongside=
=20
> all the other hard peripherals. You simply flash that logic into the part=
=20
> at the same time as you flash the software image.=20

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.  ???=20

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. =20

--=20

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On 12/01/2021 07:14, gnuarm.del...@gmail.com wrote:
> On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:
>> gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
>>> 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
>>> available 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 package.
>> 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.
> 
> I pretty much agree with you.

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
SPI, an I&sup2;C, a UART, a PWM timer.  But competing devices with boring old
fixed peripherals already have an SPI /and/ I&sup2;C /and/ UARTs /and/ PWMs.
 You don't want programmable logic for these things that are commonly
found as fixed peripherals - you want the logic for odd things.

> I'm not clear on what would be best in
> terms of the interconnections for the FPGA section.  It would
> certainly be useful for the FPGA to be on the MCU bus, but how many
> address bits, 8, 16 or 32 bit data connection?  

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.

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

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'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 requires 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 that timing number since the output delays add up.
> Run the input and output through the I/O mux and it might not work
> anymore.  But who knows?  Maybe these newer, smaller design rule
> parts are that much faster they would work fine.  ???
> 

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.

> I'm also not sure I want the FPGA to be flash if it has an MCU on
> chip.  Maybe let the MCU boot the FPGA from the program store so
> variants can be booted depending on what is connected, etc.  

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.

> 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 ready for prime time and only
> really ever saw it in a small number of high volume designs with lots
> of customer hand holding by the Xilinx experts.  

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

> That's actually how
> Cypress got started with their PSOC devices.  They didn't have the
> fancy software working very well, so they had weekly design seminars
> 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 helped someone port a Forth to one of the PSOC ARM
> devices that actually was not 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 how 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.
> 

Theo <theom+news@chiark.greenend.org.uk> writes:

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

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.

Theo <theom+news@chiark.greenend.org.uk> wrote:
...
> 
> 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.
> 
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
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

On Tuesday, January 12, 2021 at 2:31:48 AM UTC-5, David Brown wrote:
> On 12/01/2021 07:14, gnuarm.del...@gmail.com wrote:=20
> > On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:=20
> >> gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:=20
> >>> What I've found interesting is there are very limited options for=20
> >>> MCU/FPGA combinations. The available choices are rather large and=20
> >>> expensive. Like there are <$5 FPGAs and very cheap MCUs, you'd=20
> >>> think there would be <$5 MCU/FPGA combos. Actually, Gowin has a=20
> >>> line of small FPGAs with an ARM CM3. I need to look into these a=20
> >>> bit harder. I don't know if you can trust the pricing on the Edge=20
> >>> web site, but they show a 9 kLUT part with the ARM for under $4.=20
> >>> That's pretty interesting. The version without extra RAM is=20
> >>> available in an 88 pin package. The version with the RAM is not=20
> >>> available in anything larger than 48 pins at the moment without=20
> >>> going to a BGA type package.=20
> >> I'd be quite interested in something that's an MCU first, but with=20
> >> an FPGA component. Most of the offerings seem to be primarily an=20
> >> FPGA but with a hard core instead of a NIOS/Microblaze/etc. That=20
> >> brings with it the downsides of having to manage an FPGA toolchain=20
> >> with the downsides of having to implement lots of things in a=20
> >> custom way.=20
> >>=20
> >> I've used the Cypress PSoC line for things - they have a tiny=20
> >> amount of programmable logic, but it's very limited. Something with=20
> >> a few kLUTs would be nice, being mainly an MCU with all the regular=20
> >> MCU stuff (SPI, I2C, timers, ethernet, USB, CAN...) but with a=20
> >> peripheral that's some programmable logic hooked up to the internal=20
> >> bus and wired into the existing pin mux. You implement your=20
> >> function in FPGA logic and it sits alongside all the other hard=20
> >> peripherals. You simply flash that logic into the part at the same=20
> >> time as you flash the software image.=20
> >=20
> > I pretty much agree with you.
> Atmel had an AVR with an FPGA many years ago - I don't know how=20
> successful it was. At the time, I thought it was an interesting idea=20
> but never had a project that needed it.=20

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. =20

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.=20


> A lot of the available devices are, as Theo says, too limited. PSoC's=20
> have some programmable logic - but its far too limit. It's one thing to=
=20
> say that the logic makes the device flexible - it can be used for an=20
> SPI, an I=C2=B2C, a UART, a PWM timer. But competing devices with boring =
old=20
> fixed peripherals already have an SPI /and/ I=C2=B2C /and/ UARTs /and/ PW=
Ms.=20
> You don't want programmable logic for these things that are commonly=20
> found as fixed peripherals - you want the logic for odd things.
> > I'm not clear on what would be best in=20
> > terms of the interconnections for the FPGA section. It would=20
> > certainly be useful for the FPGA to be on the MCU bus, but how many=20
> > address bits, 8, 16 or 32 bit data connection?
> I'd want 32-bit to dual-port ram blocks and some uncommitted registers=20
> (uncommitted from the FPGA side, but fixed addresses on the cpu side).=20
> No one would make such a device with a cpu less than 32-bit, and the=20
> 64-bit world has fast buses dedicated to FPGA accelerators and the like.=
=20
> It would seem crazy to limit the connection to anything less than full=20
> speed on the cpu side.=20
>=20
> I'd also want the FPGA to be able to work as a bus master on the cpu=20
> data bus side. This is essential to be able to make accelerators and=20
> DMA components in the FPGA.

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.=20


> > How many FPGA I/Os=20
> > will require pins? I don't agree with mixing the FPGA I/O pins with=20
> > the MCU peripherals since the FPGA I/Os naturally mux within=20
> > themselves.
> Here I disagree. Mixing FPGA and MCU pins is exactly what I would want.=
=20
> You'd be free from the usual MCU limitation of having lots of hardware=20
> peripherals but not the right pin mux choices to let you have exactly=20
> the combination you want. And you'd be free to take advantage of=20
> combinations, without having to route signals back on the outside of the=
=20
> device (say you want to use an internal UART but with the data used to=20
> modulate a carrier signal). You want this kind of routing to be done=20
> internally, not via the pin drivers.

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. =20

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. =20

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.=20


> > I'm not sure of the performance penalty of running the=20
> > FPGA I/Os through the I/O mux. I know the current design I have=20
> > which may get redone with a Gowin part needs some decent I/O speed to=
=20
> > work. One timing parameter on an interface was not well thought out=20
> > and requires an output to be driven and received by the other device=20
> > in a half of a 33 MHz clock cycle or 15 ns. I was worried about=20
> > being able to meet that timing number since the output delays add up.=
=20
> > Run the input and output through the I/O mux and it might not work=20
> > anymore. But who knows? Maybe these newer, smaller design rule=20
> > parts are that much faster they would work fine. ???=20
> >
> I think the delays from the fixed peripherals would be smaller and more=
=20
> predictable than the FPGA fabric. But some pins would remain dedicated=20
> - you'd want things like QSPI and other fast memory buses, Ethernet, or=
=20
> FPGA SERDES pins to be dedicated to appropriate hardware peripherals or=
=20
> FPGA fabric.

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.=20


> > I'm also not sure I want the FPGA to be flash if it has an MCU on=20
> > chip. Maybe let the MCU boot the FPGA from the program store so=20
> > variants can be booted depending on what is connected, etc.
> Certainly I'd want the MCU to be able to control loading the FPGA image.=
=20
>=20
> Modern high-end MCUs are now often without flash. You don't want flash=20
> on the same die as the MCU - the optimal production processes for flash=
=20
> and high-speed logic are too different, and you end up limiting both the=
=20
> MCU and the flash.=20

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.=20

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.=20


> Look at the NXP RT10xx series - you have a 600 MHz=20
> Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined=
=20
> with an external QSPI flash chip, is cheaper than a typical 120 MHz M4=20
> microcontroller with a fraction of the flash, and the QSPI flash runs=20
> faster than on-die MCU flash. (There are some RT10xx devices which=20
> include flash - it is a separate die, in the same package, which is nice.=
)=20

Just get a Zynq already!=20


> So external QSPI flash (or external die, internal package) is the way to=
=20
> go IMHO.
> > Many=20
> > years ago Xilinx was working on partial reconfiguration in a way that=
=20
> > would allow sections of the chip to be independently designed and=20
> > configured. I think they never got it ready for prime time and only=20
> > really ever saw it in a small number of high volume designs with lots=
=20
> > of customer hand holding by the Xilinx experts.
> I remember hearing about that kind of thing (Altera had something of=20
> that sort too, I think?). Wasn't it only available on their paid-for=20
> subscription versions of their tools? Keeping a technology out of the=20
> hands of amateurs, learners, experimenters and small users is a=20
> sure-fire way to make sure no one uses it.=20
>=20
> (Even though I haven't used programmable logic much for a long time, I=20
> still try to keep up with what's happening in the FPGA world.)
> > That's actually how=20
> > Cypress got started with their PSOC devices. They didn't have the=20
> > fancy software working very well, so they had weekly design seminars=20
> > which were really just conference calls for you to pick the brains of=
=20
> > the experts. Great way to get started with the parts, but still not=20
> > great in place of workable tools. I believe they have much better=20
> > tools now. I helped someone port a Forth to one of the PSOC ARM=20
> > devices that actually was not programmable in a real sense, it has=20
> > very flexible serial controllers so the same hardware could do SPI,=20
> > UART or I2C if I recall. I figured out how to install a UART so the=20
> > Forth could boot up and give a command prompt. Funny actually. The=20
> > one small family of non-programmable PSOC devices.=20

--=20

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On Tuesday, January 12, 2021 at 3:16:13 AM UTC-5, Anssi Saari wrote:
> Theo <theom...@chiark.greenend.org.uk> writes:=20
>=20
> > Something with a few kLUTs would be nice, being mainly an MCU with all=
=20
> > the regular MCU stuff (SPI, I2C, timers, ethernet, USB, CAN...) but=20
> > with a peripheral that's some programmable logic hooked up to the=20
> > internal bus and wired into the existing pin mux.
> I haven't taken a close look but QuickLogic has come out with this kind=
=20
> of chip, Cortex M4-F and embedded FPGA on the same chip. Looks like it's=
=20
> smaller than a few kLUTs and doesn't have that much in the way of MCU=20
> peripherals though.

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.=20

--=20

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

On 12/01/2021 18:20, gnuarm.del...@gmail.com wrote:
> On Tuesday, January 12, 2021 at 2:31:48 AM UTC-5, David Brown wrote:
>> On 12/01/2021 07:14, gnuarm.del...@gmail.com wrote:
>>> On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:
>>>> gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:

>> 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.
> 
> They called it a SLIC or something similar.  It used a proprietary 8
> bit MCU 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.

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

> 
> 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 part as well and in the end had a limited life span.  In
> other words, aside from 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.
> 

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.

> 
>> 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 SPI, an I&sup2;C, a UART, a PWM timer. But competing
>> devices with boring old fixed peripherals already have an SPI /and/
>> I&sup2;C /and/ UARTs /and/ PWMs. You don't want programmable logic for
>> these things that are commonly found as fixed peripherals - you
>> want the logic for odd things.
>>> I'm not clear on what would be best in terms of the
>>> interconnections for the FPGA section. It would certainly be
>>> useful for the FPGA to be on the MCU bus, but how many address
>>> bits, 8, 16 or 32 bit data connection?
>> 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.
> 
> You've asked for two things that you would not need together.  You
> can either DMA data into main memory or your can host memory that the
> CPU can access, but there is little need to do both.
> 

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.

> 
>>> 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.
>> 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.
> 
> You are asking for things you just don't need.  FPGAs are capable of
> hosting 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 available for the FPGA?  Asking for everything gives you
> nothing in the end because the chip won't be made.
> 

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.

> When discussing this with the Xilinx folks who used to haunt the FPGA
> forums the reason for not selling such chips was the FPGA makers are
> not MCU makers and their business model did not support as large
> proliferation of variants as the MCU makers.  So it would be
> necessary to limit the number of hard peripherals and combinations of
> FPGA size.  That is what Xilinx and Altera have done.  They focus on
> a market with a handful of offerings, all aimed 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 all but a minimal set of peripherals and other
> compromises to simply the permutations.
> 

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'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
>>> requires 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 that timing number since the output delays
>>> add up. Run the input and output through the I/O mux and it might
>>> not work anymore. But who knows? Maybe these newer, smaller
>>> design rule parts are that much faster they would work fine. ???
>>> 
>>> 
>> 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.
> 
> Nobody cares about the speed of the hard peripherals since they run
> fast enough.  I'm talking about the FPGA peripherals.  Not everything
> is a standard SPI or UART.  If you just need standard peripherals you
> can probably find a good part with the combo you need.
> 

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

> 
>>> I'm also not sure I want the FPGA to be flash if it has an MCU on
>>>  chip. Maybe let the MCU boot the FPGA from the program store so
>>>  variants can be booted depending on what is connected, etc.
>> 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.
> 
> Those are exactly the devices you can already get on an FPGA.  Check
> out the Xilinx Zynq and the Altera equivalent.  They are much too
> large for me with 400 pin packages and big price tags.
> 

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.

> Microsemi has a line of MCUs that are more like what I am talking
> about, but the prices are far too high.  Gowin is jusssst right at
> ~$4.  They talk about versions with SDRAM die in the package, but not
> on the disti's list yet.
> 
> 
>> 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.)
> 
> Just get a Zynq already!

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

On Tuesday, January 12, 2021 at 12:51:03 PM UTC-5, David Brown wrote:
> On 12/01/2021 18:20, gnuarm.del...@gmail.com wrote:=20
> > On Tuesday, January 12, 2021 at 2:31:48 AM UTC-5, David Brown wrote:=20
> >> On 12/01/2021 07:14, gnuarm.del...@gmail.com wrote:=20
> >>> On Monday, January 11, 2021 at 1:07:59 PM UTC-5, Theo wrote:=20
> >>>> gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:=20
>=20
> >> Atmel had an AVR with an FPGA many years ago - I don't know how=20
> >> successful it was. At the time, I thought it was an interesting=20
> >> idea but never had a project that needed it.=20
> >=20
> > They called it a SLIC or something similar. It used a proprietary 8=20
> > bit MCU that may or may not have been an AVR. At the time it was not=20
> > anything I'd seen elsewhere, but that was quite some years back.
> "SLIC" rings a bell. It was definitely an AVR - which is, of course, an=
=20
> Atmel proprietary 8-bit MCU.
> >=20
> > The FPGA was a very poor man's Xilinx part (a beggar's as it were)=20
> > because most of the technology was still under patent. It was a very=20
> > expensive part as well and in the end had a limited life span. In=20
> > other words, aside from being nearly the only FPGA/MCU combo part you=
=20
> > could buy, it was a crappy device. I expect the software matched,=20
> > but I don't know that I ever tried it.=20
> >
> I don't know what the FPGA tools were like for the device. At the time,=
=20
> software tools for the AVR were a bit limited or very expensive (IAR),=20
> but they're good now - for an 8-bit device.
> >=20
> >> A lot of the available devices are, as Theo says, too limited.=20
> >> PSoC's have some programmable logic - but its far too limit. It's=20
> >> one thing to say that the logic makes the device flexible - it can=20
> >> be used for an SPI, an I=C2=B2C, a UART, a PWM timer. But competing=20
> >> devices with boring old fixed peripherals already have an SPI /and/=20
> >> I=C2=B2C /and/ UARTs /and/ PWMs. You don't want programmable logic for=
=20
> >> these things that are commonly found as fixed peripherals - you=20
> >> want the logic for odd things.=20
> >>> I'm not clear on what would be best in terms of the=20
> >>> interconnections for the FPGA section. It would certainly be=20
> >>> useful for the FPGA to be on the MCU bus, but how many address=20
> >>> bits, 8, 16 or 32 bit data connection?=20
> >> I'd want 32-bit to dual-port ram blocks and some uncommitted=20
> >> registers (uncommitted from the FPGA side, but fixed addresses on=20
> >> the cpu side). No one would make such a device with a cpu less than=20
> >> 32-bit, and the 64-bit world has fast buses dedicated to FPGA=20
> >> accelerators and the like. It would seem crazy to limit the=20
> >> connection to anything less than full speed on the cpu side.=20
> >>=20
> >> I'd also want the FPGA to be able to work as a bus master on the=20
> >> cpu data bus side. This is essential to be able to make=20
> >> accelerators and DMA components in the FPGA.=20
> >=20
> > You've asked for two things that you would not need together. You=20
> > can either DMA data into main memory or your can host memory that the=
=20
> > CPU can access, but there is little need to do both.=20
> >
> I'd want to do both - perhaps not both at the same time in the same=20
> peripheral, but both at times. If I were making a peripheral in the=20
> FPGA - say, a CAN controller - I'd want it to have a dual-port RAM that=
=20
> can be accessed directly from the cpu. If I were making an accelerator,=
=20
> such as a CRC accelerator, I'd want that FPGA component to be able to=20
> access main chip memory.
> >=20
> >>> How many FPGA I/Os will require pins? I don't agree with mixing=20
> >>> the FPGA I/O pins with the MCU peripherals since the FPGA I/Os=20
> >>> naturally mux within themselves.=20
> >> Here I disagree. Mixing FPGA and MCU pins is exactly what I would=20
> >> want. You'd be free from the usual MCU limitation of having lots of=20
> >> hardware peripherals but not the right pin mux choices to let you=20
> >> have exactly the combination you want. And you'd be free to take=20
> >> advantage of combinations, without having to route signals back on=20
> >> the outside of the device (say you want to use an internal UART but=20
> >> with the data used to modulate a carrier signal). You want this=20
> >> kind of routing to be done internally, not via the pin drivers.=20
> >=20
> > You are asking for things you just don't need. FPGAs are capable of=20
> > hosting all the UARTs you want within the FPGA. SPI is a snap. Even=20
> > I2C is not hard. Why futz with hard peripherals when it only reduces=20
> > the die area available for the FPGA? Asking for everything gives you=20
> > nothing in the end because the chip won't be made.=20
> >
> Look at existing FPGA devices with hard cpus. You'll notice that the=20
> have a number of hard peripherals, including timers and UARTs. Sure,=20
> you can make these in an FPGA - but you can get more functionality at a=
=20
> much lower die cost and power when they are made as hard blocks. It=20
> would be crazy /not/ to put them along with the microcontroller part -=20
> they are devices that just about every MCU user wants, and are a=20
> completely negligible cost in the silicon.=20
>=20
> Remember, while a UART is entirely doable in an FPGA, it is /not/ free.=
=20
> It costs FPGA resources. It costs FPGA developer time and effort (even=20
> if it is a ready-made unit). It costs software developer time to=20
> support the special FPGA version rather than one they have used before=20
> with that MCU.=20
>=20
> There would be a balance, of course - you wouldn't put everything that=20
> MCU's might have as hard peripherals.
> > When discussing this with the Xilinx folks who used to haunt the FPGA=
=20
> > forums the reason for not selling such chips was the FPGA makers are=20
> > not MCU makers and their business model did not support as large=20
> > proliferation of variants as the MCU makers. So it would be=20
> > necessary to limit the number of hard peripherals and combinations of=
=20
> > FPGA size. That is what Xilinx and Altera have done. They focus on=20
> > a market with a handful of offerings, all aimed at the high end with=20
> > complex interfaces (supposedly for high performance) and complex=20
> > tools.=20
> >=20
> > As you said, you want an MCU with a bit of FPGA hanging on the=20
> > internal bus as an uber-peripheral. That's great, but it's going to=20
> > require dropping all but a minimal set of peripherals and other=20
> > compromises to simply the permutations.=20
> >
> I don't see that at all - especially if it is implemented as a=20
> peripheral. When an MCU manufacturer wants to add an Ethernet=20
> controller to an existing MCU, they don't start by removing a UART even=
=20
> if they think someone who uses Ethernet will need fewer UARTs.
> >=20
> >>> I'm not sure of the performance penalty of running the FPGA I/Os=20
> >>> through the I/O mux. I know the current design I have which may=20
> >>> get redone with a Gowin part needs some decent I/O speed to work.=20
> >>> One timing parameter on an interface was not well thought out and=20
> >>> requires an output to be driven and received by the other device=20
> >>> in a half of a 33 MHz clock cycle or 15 ns. I was worried about=20
> >>> being able to meet that timing number since the output delays=20
> >>> add up. Run the input and output through the I/O mux and it might=20
> >>> not work anymore. But who knows? Maybe these newer, smaller=20
> >>> design rule parts are that much faster they would work fine. ???=20
> >>>=20
> >>>=20
> >> I think the delays from the fixed peripherals would be smaller and=20
> >> more predictable than the FPGA fabric. But some pins would remain=20
> >> dedicated - you'd want things like QSPI and other fast memory=20
> >> buses, Ethernet, or FPGA SERDES pins to be dedicated to appropriate=20
> >> hardware peripherals or FPGA fabric.=20
> >=20
> > Nobody cares about the speed of the hard peripherals since they run=20
> > fast enough. I'm talking about the FPGA peripherals. Not everything=20
> > is a standard SPI or UART. If you just need standard peripherals you=20
> > can probably find a good part with the combo you need.=20
> >
> I thought you were concerned about the timing of hard peripherals here.=
=20
> But if not, that's okay.
> >=20
> >>> I'm also not sure I want the FPGA to be flash if it has an MCU on=20
> >>> chip. Maybe let the MCU boot the FPGA from the program store so=20
> >>> variants can be booted depending on what is connected, etc.=20
> >> Certainly I'd want the MCU to be able to control loading the FPGA=20
> >> image.=20
> >>=20
> >> Modern high-end MCUs are now often without flash. You don't want=20
> >> flash on the same die as the MCU - the optimal production processes=20
> >> for flash and high-speed logic are too different, and you end up=20
> >> limiting both the MCU and the flash.=20
> >=20
> > Those are exactly the devices you can already get on an FPGA. Check=20
> > out the Xilinx Zynq and the Altera equivalent. They are much too=20
> > large for me with 400 pin packages and big price tags.=20
> >
> By "modern high-end MCU", I mean something like the NXP RT1020 (or 1024=
=20
> with a flash in the same package). It's about $2.50, with 100 pin LQFP=20
> package.
> > Microsemi has a line of MCUs that are more like what I am talking=20
> > about, but the prices are far too high. Gowin is jusssst right at=20
> > ~$4. They talk about versions with SDRAM die in the package, but not=20
> > on the disti's list yet.=20
> >=20
> >=20
> >> Look at the NXP RT10xx series - you have a 600 MHz Cortex-M7 cpu,=20
> >> with plenty of ram, but no flash. One of these, combined with an=20
> >> external QSPI flash chip, is cheaper than a typical 120 MHz M4=20
> >> microcontroller with a fraction of the flash, and the QSPI flash=20
> >> runs faster than on-die MCU flash. (There are some RT10xx devices=20
> >> which include flash - it is a separate die, in the same package,=20
> >> which is nice.)=20
> >=20
> > Just get a Zynq already!
> The cheapest Zynq is 20 times the price of an RT1020. And it has a=20
> Cortex-A core, not a Cortex-M. It's a different world (though you can=20
> solve many tasks with devices from different worlds).

I typed a reply and when I sent it it crapped out.  I'm not typing all that=
 again. =20

--=20

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote:

> I typed a reply and when I sent it it crapped out.  I'm not typing all that again.  
> 

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.