softcore CPU tools

On Mar 22, 9:21 am, Rem...@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.

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

On Mar 22, 9:30 am, j...@zilium.de wrote:
> On Mar 22, 9:21 am, Rem...@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