Lattice vs Altera (Mico32 / NIOS)....or?

> If you say what the specific bugs are, maybe I can offer some help or
> advice.

One of the main problems are the poor performance of the debug interface in 
the Mico32. A download speed of 20-30 kbit/sec is just to slow when 
developing large applications. Is there any way to speed up this interface?

> MicroBlaze and NIOS II have been around for longer and no doubt have a
> larger user base, but they are not without their own problems. Don't
> forget that much of the toolchain is pretty much the same s/w.

Offcourse! But you mention a big reasson to try out Altera....the large user 
base. Lattice have < 100 topics in their forum compared to >8k in Alteras. 
The large user may help you to find/fight some of the problems.

Regards

--
MMJ

MMJ wrote:

> Offcourse! But you mention a big reasson to try out Altera....the large user 
> base. Lattice have < 100 topics in their forum compared to >8k in Alteras. 
> The large user may help you to find/fight some of the problems.

Maybe there are less topics because there are less problems :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

> Here you need care:
> Your SoftCPU needs external Code memory, so that adds to the BOM
> (unless you just happen to be using large external memory anyway, with
> unused space, that can fit the CODE, and also happen to have spare bus 
> cycles to access it.
> It also might need a larger Config memory, another BOM adder, and
> you might also need a larger FPGA.
> You also have higher EMC issues, and could even need more PCB layers....
> If that external memory is ONLY for code, that is a LOT of pins
> you have added to the design....

External flash for code is needed yes - but is also used on most silicon 
MCU/MPUs. Config memeory for the FPGA will be selected to support a fully 
configured FPGA. Regarding EMC and PCB we acutally keep allot of signals 
within the FPGA by embedding the CPU, which eases routing and maybe 
decreasses layers.

> Single chip MCUs are quite small, and the flash is all done.

Correct....if the job can be done at the right price by an internal flash 
MCU.

> Generally, if you can fit your code into a merchant uC, it
> makes more sense to use one, along side your (now smaller?) FPGA

No the size of the CPU in the FPGA is very few percent relative to the 
custom hardware that needs to be implemented.

> How high do you need ?

Above 10Mbit on a buffered DMA interface. Internally in the FPGA I guess 
this can be done by DMA from FPGA RAM to DDR ram of the CPU. Complette 
control of interrupt loading etc.

--
MMJ

MMJ pisze:
>> Here you need care:
>> Your SoftCPU needs external Code memory, so that adds to the BOM
>> (unless you just happen to be using large external memory anyway, with
>> unused space, that can fit the CODE, and also happen to have spare bus 
>> cycles to access it.
>> It also might need a larger Config memory, another BOM adder, and
>> you might also need a larger FPGA.
>> You also have higher EMC issues, and could even need more PCB layers....
>> If that external memory is ONLY for code, that is a LOT of pins
>> you have added to the design....
> 
> External flash for code is needed yes - but is also used on most silicon 
> MCU/MPUs. Config memeory for the FPGA will be selected to support a fully 
> configured FPGA. Regarding EMC and PCB we acutally keep allot of signals 
> within the FPGA by embedding the CPU, which eases routing and maybe 
> decreasses layers.
> 

If you have enough space inside configuration flash you can use it for 
both - for FPGA image and for softprocessor code.

I'm doing this way.

Adam

Adam G�rski pisze:
> MMJ pisze:
>>> Here you need care:
>>> Your SoftCPU needs external Code memory, so that adds to the BOM
>>> (unless you just happen to be using large external memory anyway, with
>>> unused space, that can fit the CODE, and also happen to have spare 
>>> bus cycles to access it.
>>> It also might need a larger Config memory, another BOM adder, and
>>> you might also need a larger FPGA.
>>> You also have higher EMC issues, and could even need more PCB layers....
>>> If that external memory is ONLY for code, that is a LOT of pins
>>> you have added to the design....
>>
>> External flash for code is needed yes - but is also used on most 
>> silicon MCU/MPUs. Config memeory for the FPGA will be selected to 
>> support a fully configured FPGA. Regarding EMC and PCB we acutally 
>> keep allot of signals within the FPGA by embedding the CPU, which 
>> eases routing and maybe decreasses layers.
>>
> 
> If you have enough space inside configuration flash you can use it for 
> both - for FPGA image and for softprocessor code.
> 
> I'm doing this way.
> 
> Adam

If you have external SDR SDRAM or DDR SDRAM of course or big enough 
internal ram

Adam

On 13 Oct, 13:21, "MMJ" <S...@aldrig.com> wrote:
> > If you say what the specific bugs are, maybe I can offer some help or
> > advice.
>
> One of the main problems are the poor performance of the debug interface in
> the Mico32. A download speed of 20-30 kbit/sec is just to slow when
> developing large applications. Is there any way to speed up this interface?

Are you developing on Lattice's ECP2 board or your own custom board?

Cheers,
Jon