Prev: Comunicate FPGA to Ethernet
Next: (Xilinx) OPB watchdog timer fails to release RESET
From: joerg on 22 Mar 2007 05:30
On Mar 22, 9:21 am, Rem...(a)gmail.com wrote:

> > I'ts running on my Spartan-3E starter kit and I'm currently porting it
> > over to the
> > Altera Cyclone-II Starter kit.
>
> > I don't have it integrated into the Eclipse IDE Lattice is shipping --
> > but at least I've
> > got theCPUrunning in my own wishbone based SOC.

> I am just Altium User and I love the tool for sch capture, layout,
> SPICE and signal Integrity Analysis.
> haven't jumped on it with FPGA develpments. So far I've been using
> Xilinx ISE.

Never used Altium -- can't comment on that.

My workflow is far from nice. Although there are wishbone system
builders (Counting the Lattice IDE as one of them), my workflow for
Xilinx ISE and Altera Quantus still heavily depend on cut'n paste.

> > I'ts running on my Spartan-3E starter kit and I'm currently porting it
> > over to the
> > Altera Cyclone-II Starter kit.
>
> you really got my attention on Mico32, since my target hardware is
> Xilinx. How is performance running on Xilinx Spartan3, what clock
> frequency can you push it to.

On my XC3S500E-4 I get between 90 and 95 MHz -- with default XST/PAR
options. So I'd expect 100MHz to be the limit.

Takes < 1500 LUTs.


I'll publish my ISE project as soon as I fixed some problems with the
DDR
controller. But that won't be before ~10 days.

Porting the actual CPU is trivial -- only some small changes to make
XST
happy.


> And thanks for clarifying this. I always thought that Lattice Mico32
> is like Microbalze, with code tailored for specific architecture. Well
> I guess then it was one unselfish move from Lattice point of view :)

LM32 ist straight-forward verilog RTL code.

> Just have read that uClinux is in the process of being ported to
> Mico32. This open source project could really take off.

Hope so.

Having a mutually compatible set of OSS hard- and softwarecomponents
whould be really great -- and could bring a boost to reconfigurable
hardware.

Sad, that there's no OSS toolchain for synthesis and par :( Or at
least
a common build system where different verndor tools could plug in.
Changing your FPGA vendor is still too much pain.



j.


From: David Brown on 22 Mar 2007 06:11
Austin Lesea wrote:
> InmateRemo,
>
> Thoughts to share:
>
> I would suggest that Xilinx is the only provider with a continuous
> history of providing a code compatible (MicroBlaze) soft processor.
>
> Where others had their first version (which did not work very well) and
> then abandoned it (leaving all their customers with useless code).
> Xilinx recognizes that to be a serious player in the embedded processor
> space there must be backward compatible code (forever). Intel's rule is
> very simple, you can research and play with any architecture you wish,
> but there is one, and only one instruction set (x86).
>

I can't really comment on the MicroBlaze, having never used it, but I've
used large numbers of processors in embedded systems over the years.
And if there is one thing I know about object code compatibility, it is
that it is vastly overrated.

There are only a few situations where object code compatibility is
important. One is when you are replacing an obsolete part with a new
part, and are trying to avoid development costs. That requires absolute
100% compatibility in hardware and software. You don't get that in the
fpga world (your new part will have different footprints, power
supplies, etc., and will need a re-build of the fpga design). Second is
when you have old assembly code that must be re-used - that's mostly an
issue for 8-bit microcontrollers. Third is for when you are using
third-party binary-only software modules. That's mostly an issue for
windows pc's. Finally, the only issue that is at all relevant in this
case, you sometimes have short code sections that are hand-written in
assembly for very low level tasks, or for specialised optimisations.
Adapting these to a new processor ISA is seldom a major part of a port.

Source code compatibility is, of course, vital. But that's a matter of
sticking to your favourite C standard and structuring your core-specific
functionality (such as interrupts) properly. Transitioning between a
Nios and a Nios II, for example, is little more than a re-compile on the
software side.

Clearly you don't break the ISA unnecessarily. But if it is a major
problem for your customers when the MicroBlaze II is object-code
incompatible with the MicroBlaze, then your tools are not good enough.
When there is enough benefit to be gained from a change in ISA, you make
that change.

The x86 is an example of *exactly* why you must be able to change the
ISA. Modern x86 cpu's are fantastic implementations of a terrible
design, with vast amounts of time and effort spent to make such a rotten
ISA work well in practice, demonstrating that you can, in fact, polish a
turd.



> In a similar fashion, we have PicoBlaze (still the KCMP core from long
> ago), MicroBlaze (32 bit Harvard architecture soft core optimized for
> our architecture -- unchanged as far as instructions from day 1), and
> the IBM Power PC family (405, 4??, ???: the roadmap being IBM's "power"
> architecture roadmap, just delayed).
>
> With as many customers as we have, with all of their designs, and as
> many seats of software (more than 250,000 installed), and our long
> history (invented the FPGA in 1984), besides our business position (took
> PowerPC(tm IBM) architecture from ~33% in embedded systems when we
> introduced Virtex II Pro, to more than 50% of embedded systems today);
> you would be well served to stick with Xilinx.
>
> Austin
From: RemisN on 22 Mar 2007 08:53
On Mar 22, 9:30 am, j...(a)zilium.de wrote:
> On Mar 22, 9:21 am, Rem...(a)gmail.com wrote:
>
> > > I'ts running on my Spartan-3E starter kit and I'm currently porting it
> > > over to the
> > > Altera Cyclone-II Starter kit.
>
> > > I don't have it integrated into the Eclipse IDE Lattice is shipping --
> > > but at least I've
> > > got theCPUrunning in my own wishbone based SOC.
> > I am just Altium User and I love the tool for sch capture, layout,
> > SPICE and signal Integrity Analysis.
> > haven't jumped on it with FPGA develpments. So far I've been using
> > Xilinx ISE.
>
> Never used Altium -- can't comment on that.
>
> My workflow is far from nice. Although there are wishbone system
> builders (Counting the Lattice IDE as one of them), my workflow for
> Xilinx ISE and Altera Quantus still heavily depend on cut'n paste.
>
> > > I'ts running on my Spartan-3E starter kit and I'm currently porting it
> > > over to the
> > > Altera Cyclone-II Starter kit.
>
> > you really got my attention on Mico32, since my target hardware is
> > Xilinx. How is performance running on Xilinx Spartan3, what clock
> > frequency can you push it to.
>
> On my XC3S500E-4 I get between 90 and 95 MHz -- with default XST/PAR
> options. So I'd expect 100MHz to be the limit.
>
> Takes < 1500 LUTs.
>
> I'll publish my ISE project as soon as I fixed some problems with the
> DDR
> controller. But that won't be before ~10 days.
>
> Porting the actual CPU is trivial -- only some small changes to make
> XST
> happy.
>
> > And thanks for clarifying this. I always thought that Lattice Mico32
> > is like Microbalze, with code tailored for specific architecture. Well
> > I guess then it was one unselfish move from Lattice point of view :)
>
> LM32 ist straight-forward verilog RTL code.
>
> > Just have read that uClinux is in the process of being ported to
> > Mico32. This open source project could really take off.
>
> Hope so.
>
> Having a mutually compatible set of OSS hard- and softwarecomponents
> whould be really great -- and could bring a boost to reconfigurable
> hardware.
>
> Sad, that there's no OSS toolchain for synthesis and par :( Or at
> least
> a common build system where different verndor tools could plug in.
> Changing your FPGA vendor is still too much pain.
>
> j.


> I'll publish my ISE project as soon as I fixed some problems with the
> DDR
> controller. But that won't be before ~10 days.

I would be interested once you done.

BTW, which DDR controller are you using?
I've just done some reading on Mico32 on Lattice website, they mention
a range of Wishbone compliant peripherals, including DDR contr, UART,
DMA, SPI, etc. Are all of these cores available from Lattice under
open source as well? If so, I wonder if they've reused any cores from
opencores.org

Using Mico32 on other than Lattice architecture would need to tackle
solution for JTAG debugging. has anyone approached this yet?

If Mico System Builder (MSB) can be used independantly from Lattice
ispLEVER, then this package could be used to generate Wishbone
Interconnect.

RN

First  |  Prev  | 
Pages: 1 2 3
Prev: Comunicate FPGA to Ethernet
Next: (Xilinx) OPB watchdog timer fails to release RESET