Lattice Announces EOL for XP and EC/P Product Lines

[rickman]

On 8/22/2013 12:09 PM, jonesandy@comcast.net wrote:

Rick,

You might add MicroSemi Igloo2 to your list as well. A SmartFusion2 without the ARM, but still has the other hard-silicon interfaces.

Yes, I've taken a look at the MicroSemi parts, but they suffer the same
problems as the others. The favorable 100 pin QFP is not used in the
Igloo2 line and the Igloo line is rather long in the tooth. It also is
hard to get now, I see very little inventory at Digikey and a lead time
query says "Unable to get lead time".

If the prices on the SmartFusion lines weren't so high I'd consider
them, but they are pretty high for this design and they only come in
rather large packages.

--

Rick

 

[rickman]

On 8/23/2013 6:34 PM, jg wrote:

On Saturday, August 24, 2013 9:31:35 AM UTC+12, rickman wrote:
The favorable 100 pin QFP is not used in the
Igloo2 line and the Igloo line is rather long in the tooth.

I've noticed a significant trend from Asia, in Microcontrollers to offer
a choice of package-pitch, in particular, 64pin 0.8mm == same plastic as qfp100.

This allows higher yield PCB design rules.

It would be great if the FPGA/CPLD vendors grasped this.

I used to rail against the FPGA vendor's decisions in packaging. I find
it very inconvenient at a minimum. But these days I have learned to do
the Zen thing and reabsorb my dissatisfaction so as to turn it to an
advantage. I'm not sure what that means exactly, but I've given up
trying to think of FPGAs as an MCU substitute.

I suppose the markets are different enough that FPGAs just can't be
produced economically in as wide a range of packaging. I think that is
what Austin Leesa used to say, that it just costs too much to provide
the parts in a lot of packages. Their real market is at the high end.
Like the big CPU makers, it is all about raising the ASP, Average
Selling Price. Which means they don't spend a lot of time wooing the
small part users like us.

I don't really need the 0.8 mm pitch. My current design uses the 0.5 mm
pitch part with 6/6 design rules and no one other than Sunstone has any
trouble making the board. Is there any real advantage to using a 0.8 mm
pitch QFP? I would be very interested in using QFNs. They seem to be
the same package as the QFNs but without the leads. Of course that
presents it's own problem. BGAs and QFNs don't like it when the board
flexes and my board is long and skinny. It tends to get pried off of
the mother board and flexed in the process. That can cause lead-less
parts to separate from the board.

As long as we are wishing for stuff, I'd really love to see a smallish
MCU mated to a smallish FPGA. I think Atmel made one called the FPSLIC
with an AVR and FPGA inside. It never took off and I was never brave
enough to design one in expecting it to be dropped at any time. I just
looked and it appears the FPSLIC is finally EOL. lol

--

Rick

 

[Uwe Bonnes]

jg <j.m.granville@gmail.com> wrote:

On Saturday, August 24, 2013 9:31:35 AM UTC+12, rickman wrote:
The favorable 100 pin QFP is not used in the
Igloo2 line and the Igloo line is rather long in the tooth.

I've noticed a significant trend from Asia, in Microcontrollers to offer
a choice of package-pitch, in particular, 64pin 0.8mm == same plastic
as qfp100.

This allows higher yield PCB design rules.

But that gets the decouplig caps farer away from the chip and so worsens
simultanious switching.

But it is also great for prototyping and degugging...

> It would be great if the FPGA/CPLD vendors grasped this.

--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Tom Gardner]

On 24/08/13 02:06, rickman wrote:
> As long as we are wishing for stuff, I'd really love to see a smallish MCU mated to a smallish FPGA.

Isn't the presumption that you will use one of their soft-core processors?

 

[rickman]

On 8/24/2013 6:25 AM, Tom Gardner wrote:

On 24/08/13 02:06, rickman wrote:
As long as we are wishing for stuff, I'd really love to see a smallish
MCU mated to a smallish FPGA.

Isn't the presumption that you will use one of their soft-core processors?

There is more to an MCU than the processor core. Memory is a
significant issue. Trying to use the block memory for the processor
creates a lot of routing congestion and ties up those resources for
other uses. Adding something like the AVR or MSP430 to an FPGA would be
a lot more efficient than building it out of the "fabric". But yes,
that is an approach for sure.

I think the real issue for me is that they just don't put very much FPGA
into small packages usable without very fine board geometries. I did my
original design with a 3 kLUT part which was the largest I could get in
a 100 pin QFP. Over 5 years later, it is *still* the largest part I can
get in that package, hence my problem... lol Man, I would kill (or
kiloLUT) to get a 6 kLUT part in a QFN package with just ONE row of
pins. They always seem to use QFN packages with two or more rows of
pins which require 3/3 mil space/trace design rules.

One of my potential solutions is to use a similar, but smaller part from
the XO2 line (assuming I stay with Lattice after this) and roll my own
processor to handle the slow logic. It will be a lot more work than
just porting the HDL to a new chip though. I think rolling my own will
likely produce a smaller and more efficient design. The 32 bit designs
wouldn't even fit on the chip. I'm not sure how large the 8 bit designs
are in LUTs. I'm thinking a 16 or 18 bit CPU would be a good data size.
Or if the LUTs are really tight, a 4 or 5 bit processor might save on
real estate. Maybe 8 or 9 bits is a good compromise depending on the
LUT count.

--

Rick

 

[rickman]

On 8/24/2013 6:02 AM, Uwe Bonnes wrote:

jg<j.m.granville@gmail.com> wrote:
On Saturday, August 24, 2013 9:31:35 AM UTC+12, rickman wrote:
The favorable 100 pin QFP is not used in the
Igloo2 line and the Igloo line is rather long in the tooth.

I've noticed a significant trend from Asia, in Microcontrollers to offer
a choice of package-pitch, in particular, 64pin 0.8mm == same plastic
as qfp100.

This allows higher yield PCB design rules.

But that gets the decouplig caps farer away from the chip and so worsens
simultanious switching.

Two comments. He is describing two packages with the same body size and
so the caps would be the same distance from the chip. But also, when
you use power and group planes with effective coupling, the distance of
the cap from the chip is nearly moot. The power planes act as a
transmission line providing the current until the wave reaches the
capacitor. Transmission lines are your friend.

--

Rick

 

[Gabor]

On 8/24/2013 12:37 PM, rickman wrote:

On 8/24/2013 6:25 AM, Tom Gardner wrote:
On 24/08/13 02:06, rickman wrote:
As long as we are wishing for stuff, I'd really love to see a smallish
MCU mated to a smallish FPGA.

Isn't the presumption that you will use one of their soft-core
processors?

There is more to an MCU than the processor core. Memory is a
significant issue. Trying to use the block memory for the processor
creates a lot of routing congestion and ties up those resources for
other uses. Adding something like the AVR or MSP430 to an FPGA would be
a lot more efficient than building it out of the "fabric". But yes,
that is an approach for sure.

I think the real issue for me is that they just don't put very much FPGA
into small packages usable without very fine board geometries. I did my
original design with a 3 kLUT part which was the largest I could get in
a 100 pin QFP. Over 5 years later, it is *still* the largest part I can
get in that package, hence my problem... lol Man, I would kill (or
kiloLUT) to get a 6 kLUT part in a QFN package with just ONE row of
pins. They always seem to use QFN packages with two or more rows of
pins which require 3/3 mil space/trace design rules.

One of my potential solutions is to use a similar, but smaller part from
the XO2 line (assuming I stay with Lattice after this) and roll my own
processor to handle the slow logic. It will be a lot more work than
just porting the HDL to a new chip though. I think rolling my own will
likely produce a smaller and more efficient design. The 32 bit designs
wouldn't even fit on the chip. I'm not sure how large the 8 bit designs
are in LUTs. I'm thinking a 16 or 18 bit CPU would be a good data size.
Or if the LUTs are really tight, a 4 or 5 bit processor might save on
real estate. Maybe 8 or 9 bits is a good compromise depending on the
LUT count.

I would think the Lattice mico8 would be pretty small, and it should be
easy enough to try that out. Rolling your own would be more fun,
though...

--
Gabor

 

[rickman]

On 8/24/2013 1:14 PM, Gabor wrote:

On 8/24/2013 12:37 PM, rickman wrote:

One of my potential solutions is to use a similar, but smaller part from
the XO2 line (assuming I stay with Lattice after this) and roll my own
processor to handle the slow logic. It will be a lot more work than
just porting the HDL to a new chip though. I think rolling my own will
likely produce a smaller and more efficient design. The 32 bit designs
wouldn't even fit on the chip. I'm not sure how large the 8 bit designs
are in LUTs. I'm thinking a 16 or 18 bit CPU would be a good data size.
Or if the LUTs are really tight, a 4 or 5 bit processor might save on
real estate. Maybe 8 or 9 bits is a good compromise depending on the
LUT count.

I would think the Lattice mico8 would be pretty small, and it should be
easy enough to try that out. Rolling your own would be more fun,
though...

I've already done the roll your own thing. Stack processors can be
pretty small and they are what I prefer to use, but a register machine
is ok too. I don't know how big the Micro8 is in terms of LUTs. My
last design was 16 bits and about 600 LUTs and that included some
flotsam that isn't required in a final design. By contrast the
microBlaze I know is multiple kLUTs, but that is a 32 bit design. The
Xilinx picoBlaze 8 bit design is rather small (I don't recall the
number) but it instantiates LUTs and FFs and so is not portable. There
may be a home grown version of the picoBlaze.

--

Rick

 

[Allan Herriman]

On Sat, 24 Aug 2013 18:51:57 -0400, rickman wrote:

[snip]

The
Xilinx picoBlaze 8 bit design is rather small (I don't recall the
number) but it instantiates LUTs and FFs and so is not portable. There
may be a home grown version of the picoBlaze.

There's "Pacoblaze" - a behavioural Verilog reimplementation of Picoblaze
that should be fairly portable.

The last time I checked (in 2006?) by simulating Pacoblaze vs Picoblaze
back-to-back, it wasn't cycle-accurate for interrupts. However, I do
notice that a 2007 bug fix is described as "Bug corrections on stack and
interrupt" so perhaps it now is an exact clone.

http://bleyer.org/pacoblaze/

You'll be restricted to assembly language of course. If your source is
in C (or some other mid-level language) then you should look to a
different micro core.

Regards,
Allan

 

[rickman]

On 8/24/2013 8:27 PM, Allan Herriman wrote:

On Sat, 24 Aug 2013 18:51:57 -0400, rickman wrote:

[snip]
The
Xilinx picoBlaze 8 bit design is rather small (I don't recall the
number) but it instantiates LUTs and FFs and so is not portable. There
may be a home grown version of the picoBlaze.

There's "Pacoblaze" - a behavioural Verilog reimplementation of Picoblaze
that should be fairly portable.

The last time I checked (in 2006?) by simulating Pacoblaze vs Picoblaze
back-to-back, it wasn't cycle-accurate for interrupts. However, I do
notice that a 2007 bug fix is described as "Bug corrections on stack and
interrupt" so perhaps it now is an exact clone.

http://bleyer.org/pacoblaze/

You'll be restricted to assembly language of course. If your source is
in C (or some other mid-level language) then you should look to a
different micro core.

My source is in VHDL. I would be porting sections of VHDL that don't
need to run fast to software. So either the Pacoblaze or the Micro8
would do. I don't think you can use the Altera CPUs on anyone else's
chips. But still, I would most likely use a stack processor, especially
if I could find one that is programmable in Forth. Actually, I'm fine
with the assembly language as long as it's a stack machine. Very simple
instructions and very simple to implement.

--

Rick

 

On Sunday, August 25, 2013 1:51:57 AM UTC+3, rickman wrote:

On 8/24/2013 1:14 PM, Gabor wrote:

On 8/24/2013 12:37 PM, rickman wrote:


One of my potential solutions is to use a similar, but smaller part from
the XO2 line (assuming I stay with Lattice after this) and roll my own
processor to handle the slow logic. It will be a lot more work than
just porting the HDL to a new chip though. I think rolling my own will
likely produce a smaller and more efficient design. The 32 bit designs
wouldn't even fit on the chip. I'm not sure how large the 8 bit designs
are in LUTs. I'm thinking a 16 or 18 bit CPU would be a good data size.
Or if the LUTs are really tight, a 4 or 5 bit processor might save on
real estate. Maybe 8 or 9 bits is a good compromise depending on the
LUT count.


I would think the Lattice mico8 would be pretty small, and it should be
easy enough to try that out. Rolling your own would be more fun,
though...



I've already done the roll your own thing. Stack processors can be
pretty small and they are what I prefer to use, but a register machine
is ok too. I don't know how big the Micro8 is in terms of LUTs. My
last design was 16 bits and about 600 LUTs and that included some
flotsam that isn't required in a final design. By contrast the
microBlaze I know is multiple kLUTs, but that is a 32 bit design. The
Xilinx picoBlaze 8 bit design is rather small (I don't recall the
number) but it instantiates LUTs and FFs and so is not portable. There
may be a home grown version of the picoBlaze.
--

Rick

I just measured Altera Nios2e on Stratix3 - 379 ALMs + 2 M9K blocks (out of 18K memory bits only 2K bits used). It's hard to translate exactly into old-fashioned LUTs, but I'd say - around 700.
Per clock Nios2e is pretty slow, but it clocks rather high and it is a 32-bit CPU - very easy to program in C.

Reimplementing Nios2 in minimal number of LUTs, e.g. trading memory for fabric, could be an interesting exercise, well suitable for coding competition. But, probably, illegal

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip)

I used to rail against the FPGA vendor's decisions in packaging. I find
it very inconvenient at a minimum. But these days I have learned to do
the Zen thing and reabsorb my dissatisfaction so as to turn it to an
advantage. I'm not sure what that means exactly, but I've given up
trying to think of FPGAs as an MCU substitute.

I suppose the markets are different enough that FPGAs just can't be
produced economically in as wide a range of packaging. I think that is
what Austin Leesa used to say, that it just costs too much to provide
the parts in a lot of packages. Their real market is at the high end.
Like the big CPU makers, it is all about raising the ASP, Average
Selling Price. Which means they don't spend a lot of time wooing the
small part users like us.

In many cases they would put one in a package with fewer pins
than pads, a waste of good I/O drivers, but maybe useful for
some people.

I don't know much much it costs just to support an additional
package, though.

Also, a big problem with FPGAs, and ICs in general, is a low enough
lead inductance. Many packages that would otherwise be useful have
too much inductance.

-- glen

 

On Saturday, August 24, 2013 11:46:59 AM UTC-5, rickman wrote:

Two comments. He is describing two packages with the same body
size and so the caps would be the same distance from the chip.
But also, when you use power and group planes with effective
coupling, the distance of the cap from the chip is nearly moot.
The power planes act as a transmission line providing the
current until the wave reaches the capacitor. Transmission
lines are your friend. -- Rick

Two more comments...

The problem with leaded packages is, especially compared to flip-chip packages, is the electrical distance (and characteristic impedance) from the lead/board joint to the die pad, particularly for power/ground connections. The substrate for a CSP looks like a mini-circuit board with its own power/ground planes.

Sure you can put the cap on the board close to the power/ground lead, but you cannot get it electrically as close to the die pad as you can with a flip-chip package.

Transmission lines for power connections are not your friend, unless they are of very low characteristic impedance at the high frequencies of interest (e.g. transition times on your fast outputs, etc.) Until the wave traverses the length of the transmission line, you are effectively supplying current through a resistor with the same value as the transmission line impedance..

What power planes do is provide "very low impedance transmission lines" for the power/ground connections, and the ability to connect an appropriately packaged capacitor to the end of that line with very low inductance.

If your design is slow (output edge rates, not clock rates) or has few simultaneously switching outputs, it won't matter which package you use.

Andy

 

[jg]

On Saturday, August 24, 2013 1:06:37 PM UTC+12, rickman wrote:

I suppose the markets are different enough that FPGAs just can't be
produced economically in as wide a range of packaging. I think that is
what Austin Leesa used to say, that it just costs too much to provide
the parts in a lot of packages. Their real market is at the high end.
Like the big CPU makers, it is all about raising the ASP, Average
Selling Price.

I was meaning more at the lower end, - eg where lattice can offer parts in QFN32, then take a large jump to Qfp100 0.5mm.
QFN32 have only 21 io, so you easily exceed that, but there is a very large gap between the QFN32 and TQFP100.
They claim to be chasing the lower cost markets with these parts, but seem rather blinkered in doing so.
Altera well priced parts in gull wing,(MAX V) but only in a 0.4mm pitch.

As long as we are wishing for stuff, I'd really love to see a smallish
MCU mated to a smallish FPGA.

If you push that 'smallish', the Cypress PSoC series have uC+logic.

The newest PSoc4 seems to have solved some of the sticker shock, but I think they crippled the Logic to achieve that.
Seems there is no free lunch.

Cypress do however, grasp the package issue, and offer QFN40(0.5mm), as well as SSOP28(0.65mm) and TQFP44(0.8mm).

 

[jg]

On Saturday, August 24, 2013 10:02:23 PM UTC+12, Uwe Bonnes wrote:

jg wrote:
This allows higher yield PCB design rules.

But that gets the decouplig caps farer away from the chip and so worsens
simultanious switching.

As rick has already pointed out, the package is the same size, so the die-cap pathway via the leadframe is no different.

In fact, because the leads are wider, the inductance is actually less on the coarser pitch package. (not by much, but it is lower)

Also, someone wanting a lower pin count logic package is less likely to be pushing 'simultanious switching'

-jg

 

[jg]

On Sunday, August 25, 2013 12:35:56 PM UTC+12, rickman wrote:

Actually, I'm fine
with the assembly language as long as it's a stack machine. Very simple
instructions and very simple to implement.

This tolerance of a subset opens an interesting design approach, whereby you make opcodes granular, and somehow list the ones used, to allow the tools to remove the unused ones.

I think I saw a NXP design some time ago, along these lines of removing unused opcode logic.

That means you can start with a more powerful core (hopefully more proven)
and then limit your SW to an opcode-subset.

-jg

 

[rickman]

On 8/25/2013 12:44 PM, already5chosen@yahoo.com wrote:

I just measured Altera Nios2e on Stratix3 - 379 ALMs + 2 M9K blocks (out of 18K memory bits only 2K bits used). It's hard to translate exactly into old-fashioned LUTs, but I'd say - around 700.
Per clock Nios2e is pretty slow, but it clocks rather high and it is a 32-bit CPU - very easy to program in C.

I can't say I fully understand the ALM, but I think it functions as a
lot more than just a pair of 4 input LUTs. It will do that without any
issue. But it will do a lot more and I expect this is used to great
advantage in a CPU. I'd say the ALM is equivalent to between 3 and 4
LUT4s depending on the design. I guess it is hard to compare between
different device types.


> Reimplementing Nios2 in minimal number of LUTs, e.g. trading memory for fabric, could be an interesting exercise, well suitable for coding competition. But, probably, illegal

Yes, there are always lots of tradeoffs to be considered.

--

Rick

 

[rickman]

On 8/25/2013 9:35 PM, glen herrmannsfeldt wrote:

rickman<gnuarm@gmail.com> wrote:

(snip)
I used to rail against the FPGA vendor's decisions in packaging. I find
it very inconvenient at a minimum. But these days I have learned to do
the Zen thing and reabsorb my dissatisfaction so as to turn it to an
advantage. I'm not sure what that means exactly, but I've given up
trying to think of FPGAs as an MCU substitute.

I suppose the markets are different enough that FPGAs just can't be
produced economically in as wide a range of packaging. I think that is
what Austin Leesa used to say, that it just costs too much to provide
the parts in a lot of packages. Their real market is at the high end.
Like the big CPU makers, it is all about raising the ASP, Average
Selling Price. Which means they don't spend a lot of time wooing the
small part users like us.

In many cases they would put one in a package with fewer pins
than pads, a waste of good I/O drivers, but maybe useful for
some people.

They often put parts in packages with a lot fewer pins than pads. Check
out nearly any data sheet and you'll see what I mean. The Cyclone V
book shows parts with I/O pin counts varying between 240 and 480
depending on the package.

I don't know much much it costs just to support an additional
package, though.

Austin Leesa from Xilinx claimed it was prohibitive, at least for the
low end devices.

Also, a big problem with FPGAs, and ICs in general, is a low enough
lead inductance. Many packages that would otherwise be useful have
too much inductance.

That depends entirely on your design. All the devices I have used have
at least two or more levels of I/O pin drive current which will help
prevent issues from lead inductance. Even so, there are plenty of small
packages with no leads greatly reducing the inductance.

--

Rick

 

[rickman]

On 8/26/2013 6:58 PM, jonesandy@comcast.net wrote:

On Saturday, August 24, 2013 11:46:59 AM UTC-5, rickman wrote:
Two comments. He is describing two packages with the same body
size and so the caps would be the same distance from the chip.
But also, when you use power and group planes with effective
coupling, the distance of the cap from the chip is nearly moot.
The power planes act as a transmission line providing the
current until the wave reaches the capacitor. Transmission
lines are your friend. -- Rick

Two more comments...

The problem with leaded packages is, especially compared to flip-chip packages, is the electrical distance (and characteristic impedance) from the lead/board joint to the die pad, particularly for power/ground connections. The substrate for a CSP looks like a mini-circuit board with its own power/ground planes.

Sure you can put the cap on the board close to the power/ground lead, but you cannot get it electrically as close to the die pad as you can with a flip-chip package.

Transmission lines for power connections are not your friend, unless they are of very low characteristic impedance at the high frequencies of interest (e.g. transition times on your fast outputs, etc.) Until the wave traverses the length of the transmission line, you are effectively supplying current through a resistor with the same value as the transmission line impedance.

What power planes do is provide "very low impedance transmission lines" for the power/ground connections, and the ability to connect an appropriately packaged capacitor to the end of that line with very low inductance.

If your design is slow (output edge rates, not clock rates) or has few simultaneously switching outputs, it won't matter which package you use.

My experience has been that for 95% of the designs done in FPGAs,
especially at the low end, this is just not an issue. FPGAs typically
have selectable drive strength which limits the issues of ground bounce
in less than electrically desirable packages. If you have fast edges
and lots of them, then use one of the more suitable packages. But if
you don't, then use the package that otherwise suits the design.

--

Rick

 

On Wednesday, August 28, 2013 11:51:36 AM UTC+3, rickman wrote:

On 8/25/2013 12:44 PM, already5chosen@yahoo.com wrote:



I just measured Altera Nios2e on Stratix3 - 379 ALMs + 2 M9K blocks (out of 18K memory bits only 2K bits used). It's hard to translate exactly into old-fashioned LUTs, but I'd say - around 700.

Per clock Nios2e is pretty slow, but it clocks rather high and it is a 32-bit CPU - very easy to program in C.



I can't say I fully understand the ALM, but I think it functions as a
lot more than just a pair of 4 input LUTs. It will do that without any
issue. But it will do a lot more and I expect this is used to great
advantage in a CPU. I'd say the ALM is equivalent to between 3 and 4
LUT4s depending on the design. I guess it is hard to compare between
different device types.

No, ALM is close to two 4-input LUTs. May be, a bit more when implementing complex tightly-coupled logic with high internal complexity to fanout ratio. May be, a bit less, when implementing simple things with lots of registers and high fanout.

For sake of the argument, I compiled Nios2e for Cyclone4, which has more old-fashioned architecture - 676 LCs + 2 M9Ks.
I also dug out my real-world design from many years ago that embeds Nios2e into Cyclone2. It is even smaller at 565 LCs + 2 M4Ks.

Reimplementing Nios2 in minimal number of LUTs, e.g. trading memory for fabric, could be an interesting exercise, well suitable for coding competition. But, probably, illegal

Yes, there are always lots of tradeoffs to be considered.

My point is - if you don't need performance and can use embedded memories then you can design useful 32-bit RISC CPU which would be non-trivially smaller than 600 LCs.
Nios2e core that I took as example is small, but hardly minimalistic. It implements full Nios2 architecture including several parts that you probably don't need. In particular:
- everything related to interrupts and exceptions
- support for big program address space
- ability to run execute programs from any memories others than on-chip SRAM