Lattice Announces EOL for XP and EC/P Product Lines

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

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

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

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?

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

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

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

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

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

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