> > 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
Reply by ●October 13, 20082008-10-13
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
Reply by ●October 13, 20082008-10-13
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
Reply by MMJ●October 13, 20082008-10-13
> 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
Reply by Frank Buss●October 13, 20082008-10-13
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.
> 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
Reply by Jim Granville●October 13, 20082008-10-13
MMJ wrote:
>>Why does this need to be on the FPGA ?
>>SoftCPUs still need external memory, so are a 2-3 chip solution.
>
>
> Correct, but the FPGA is a "must have" in this project, so an embedded
> softcore will give us allot of advantages:
>
> *No extra BOM cost for MCU and needed extra components.
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....
> *No additional use of "real estate" for the MCU subsystem.
Single chip MCUs are quite small, and the flash is all done.
Generally, if you can fit your code into a merchant uC, it
makes more sense to use one, along side your (now smaller?) FPGA
> *High data bandwidt between our custom hardware and CPU.
How high do you need ?
> *"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses).
Nothing stops you adding 4 i2c in the FPGA
>
> These pros has made us going for the softcore soloution.
-jg
Reply by MMJ●October 13, 20082008-10-13
> Why does this need to be on the FPGA ?
> SoftCPUs still need external memory, so are a 2-3 chip solution.
Correct, but the FPGA is a "must have" in this project, so an embedded
softcore will give us allot of advantages:
*No extra BOM cost for MCU and needed extra components.
*No additional use of "real estate" for the MCU subsystem.
*High data bandwidt between our custom hardware and CPU.
*"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses).
These pros has made us going for the softcore soloution.
--
MMJ
Reply by Jon Beniston●October 10, 20082008-10-10
Hi MMJ,
> * Some stuff will
> never work if you don't reverse engineer HW or get correct support.
What specifically isn't working? Did you contact Lattice about it?
> * Poorly integrated and bugy tools.
What problems and bugs do you have? Are they with the IDE, the GNU
tools or are you talking about the FPGA tools?
> * Tools crashes
Ditto.
> * Any ways (known fixes to issues, third party stuff etc.) to get
> faster to market with the Lattice solution?
If you say what the specific bugs are, maybe I can offer some help or
advice.
> * Is the stuff (NIOS II and tools) from Altera (or any other vendor)
> any better regarding the complaints above?
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.
> * The Mico32 is open source but is the origin of the code made by
> Lattice themselves or?
It's a mixture. The IDE & toolchain are obviously based on other open
source projects (Eclipse / GCC / binutils / GDB), but the Mico32
architecture was designed & implemented by Lattice.
Cheers,
Jon
Reply by Jim Granville●October 10, 20082008-10-10
FreeWheel wrote:
> Hi everybody,
>
> First off all...sorry for cross posting this to both arch.fpga and
> arch.embedded, but I think it fits in both places.
>
> I'm currently in the selection fase of an FPGA vendor. we need a >2M
> gate chip with DSP capabilities, SERDES and offcourse the mandatory
> low cost. Likewise we need a high performance embedded CPU softcore
> for system management.
Why does this need to be on the FPGA ?
SoftCPUs still need external memory, so are a 2-3 chip solution.
Why not use a 32 bit microcontroller, with on chip FLASH ?
(it may allow smaller FPGA, or smaller Loader/RAM resource)
Some examples:
* Infineon have 32bit uC models with Error Correcting FLASH
* NXP claims : "At 125 MHz, the NXP LPC2900 series
are the fastest ARM968 microcontrollers
available on the market,"
* Atmel's claim 200MHz peak core for their AT91SAM9XE128 with a
ARM926EJ-S core
( 15ns memory bandwidth @ 32 bits)
* NXP have 100MHz cM3-R2 devices
and you get SSI/SPI/ADC/DAC/Timers/RTC/WDOG/Low power, and
in some cases USB/CAN/Ethernet
> My conclusions on the
> Lattice tool chain and the Mico32 system based on the evaluation is as
> follows:
In the timeline of such things, the Lattice solution is relatively new,
so it is expected to have more wrinkles than a more mature system.
Have you asked Lattice for a reference design closest to what you
are trying to do ?
-jg