advice please: virtex pro 2

advice please: virtex pro 2

[James Don]

Hi everyone,

I am just curious what kind of ETA to get a custom board based on virtex
2 pro "running" is.

Specifically:

1.) Is it just as "easy" as an MPC860 or MPC8260 based platform ?

2.) Is there any big caveats I should now about for debugging bring up?

3.) Does anybody know about vxworks 'support' for this as well?

4.) Is debugging support with BDI, vision ICE, etc there yet for this
board? Is it just good old JTAG or something different?

5.) Is this chip even mature yet?

Sorry kind of a wierd question I know ... but your opinions are much
appreciated.

Jim

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: advice please: virtex pro 2

[Scott Anderson]

James Don wrote:
> 4.) Is debugging support with BDI, vision ICE, etc there yet for this
> board? Is it just good old JTAG or something different?

I've used a BDI2000 with a single core Virtex-II Pro and "it just works".

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: advice please: virtex pro 2

[Peter Ryser]

James,

> 1.) Is it just as "easy" as an MPC860 or MPC8260 based platform ?

Once you have a board with a bitstream for the FPGA (for example ML300 as it
ships) the development environment on Virtex-II Pro doesn't look different for
a SW person than on any other microprocessor based board.

Building the board itself is the same amount of work as for other chips.

Building the bitstream for the FPGA definitely is an additional step. However,
the EDK web page has some example designs that get you started in a short
amount of time.

> 2.) Is there any big caveats I should now about for debugging bring up?

If you keep the design close to the ML300 design (schematics available) you
will be able to use the Linux kernel for ML300 and by just configuring the
kernel bring the board up in a short amount of time.

> 3.) Does anybody know about vxworks 'support' for this as well?

Not the appropriate list - I know - but VxWorks support exists as well.

> 4.) Is debugging support with BDI, vision ICE, etc there yet for this
> board? Is it just good old JTAG or something different?

Yes, it is standard JTAG. So far, any external debuggers I've used that claim
support for 405GP have worked out of the box on Virtex-II Pro (BDI2000,
RiscWatch, VisionProbe, VisionICE, Lauterbach, ...).

> 5.) Is this chip even mature yet?

It's in production. We have Virtex-II Pro based systems here at Xilinx that run
(uptime) Linux under load (web server, streaming MP3, etc.) for more than sixty
days.

- Peter

------
PS: some links for things mentioned in the text
- ML300: http://www.xilinx.com/ml300
- EDK: http://www.xilinx.com/edk
- Linux on Virtex-II Pro:
http://www.mvista.com/partners/semiconductor/xilinx.html


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: advice please: virtex pro 2

[Kerl, John]

James:

We have brought up a custom Virtex-II Pro board and
now have ELDK running on it.  I can answer some
of your questions, but not all, as I am the software
guy.

1.) Is it just as "easy" as an MPC860 or MPC8260 based platform?

Since there is a 405 core in there, it really is a PowerPC.  Once
you get the PowerPC running, it's very familiar.

One big caveat is that the PPC is surrounded by the programmable
logic -- in particular, *all* I/Os.  Your UART, Ethernet MAC,
interrupt controller, memory controller etc. are *all* programmable
logic.  This turns out to be a good thing because you have the
flexibility to, say, change MACs without needing to use a soldering
iron.

The peripherals are (in my opinion) stable.  You can drop a peripheral
into your design and feel confident that it will work.

There is a learning curve -- since you really are building the chip
and the software, not just the software.  Xilinx has what they call
an Embedded Development Kit (EDK) which is a very nice GUI for building
your hardware design.  It runs on Windows and Solaris, but unfortunately
not, to my knowledge, on Linux.  You do need to learn the syntax of
their hardware-specification and software-specification files.  You
need to get used to running the place-and-route tool each time you
change your hardware design, and you need to accept that you will
now need to think about whether all your logic is meeting timing, etc.

The EDK GUI (XPS, Xilinx Platform Studio) is great for building a
hardware design.  Personally, I don't like it as much for building
software.  They assume that you have one and only one C program; maybe
true for small software systems but not generally true.  Second, they
use Xygwin (like Cygwin) as a Unix-on-Windows portability layer.  It's
OK, as a dumbed-down bash prompt, but it is slow, and also lacks a Perl,
a native gcc, etc.  Third, the automatically-generated makefiles created
by XPS lack any dependencies for header files, and also rebuild all
.c's whenever any is touched.  Again, OK for small projects, but not
OK when you have a hundred source files.

Fortunately, you don't need to build your software in XPS.  The
cross GCC (powerpc-eabi-gcc) is available from the Xygwin shell.
You can create your own makefiles & make your software build
sophisticated.

Also, once the hardware design is created -- meaning that a bit
file has been generated for the FPGA, and header files have been
generated telling you the addresses all the peripherals are at,
etc. -- you have a hardware platform.  You can then build software
for that platform elsewhere -- e.g. I use XPS to build the
bit file & headers, but then I use any of (1) Xygwin & makefiles
(2) Green Hills on Window$ (3) ELDK's ppc_4xx-gcc on my Linux box
to generate code for that hardware platform.  There are no special
Virtex-II Pro compiler flags -- you can use any compiler that
creates 405-compatible object code.

So, in a shorter answer to your question, once your hardware
design has stabilized and you have your bit file in the FPGA's PROM,
it really does look like a fully hardwired PowerPC chip.

2.) Is there any big caveats I should now about for debugging bring up?

My experience is that, if anything, it was *easier* to bring up the
Virtex-II Pro.  Xilinx has a debugger called XMD (Xilinx Microprocessor
Debugger) which, by itself, is a minimally featured command-line
tool.  You can print registers, etc.  On top of that, separately,
is a GUI laid on top of powerpc-eabi-gdb.  If you want a point-and-click
debugger, you can use that.  (Note:  their graphical gdb seems
not to proceed with executables not created by Xilinx tools.
But the lower-level XMD doesn't care, since it's not operating
at the symbolic level.)

But for me the primary interest is using XMD -- this is a program
on the PC which communicates with the PPC debug port.  You can use
XMD to download and run ELF files over the JTAG cable (pretty
snappy with parallel-III, faster with parallel-IV).  You can use
it to dump memory as well.

3.) Does anybody know about vxworks 'support' for this as well?

I haven't used VxWorks at all, but a customer of ours has.  And
I do know that XPS includes explicit support for building a VxWorks
BSP, within the GUI.  (Contrast to Linux, for which I build the
hardware system in XPS, then do the software elsewhere.)

What I do not know is how the licensing works.  VxWorks, of course,
is not free.

4.) Is debugging support with BDI, vision ICE, etc there yet for this
board? Is it just good old JTAG or something different?

I rarely if ever use a visionICE, and have never used a BDI, on this
or any other platform.  So I can't speak to that.  However as described
above you do have XMD over the JTAG port.

5.) Is this chip even mature yet?

To my knowledge, yes.  IBM does have some 405 errata but they are
well-documented.  If there are maturity issues, I'm not aware of
them.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: advice please: virtex pro 2

[James Don]

sorry ;-)

does "it just works" mean plug and play with a reference design ... or do
you mean it was so difficult to get running you know something else is wrong
... or does that mean you just got it working today?

I looking to estimate project so any info is good ?

Jim

-----Original Message-----
From: Scott Anderson
To: James Don
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Sent: 5/8/03 11:36 AM
Subject: Re: advice please: virtex pro 2

James Don wrote:
> 4.) Is debugging support with BDI, vision ICE, etc there yet for this
> board? Is it just good old JTAG or something different?

I've used a BDI2000 with a single core Virtex-II Pro and "it just
works".

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: advice please: virtex pro 2

[Scott Anderson]

James Don wrote:
> sorry ;-)
>
> does "it just works" mean plug and play with a reference design ... or do
> you mean it was so difficult to get running you know something else is wrong
> ... or does that mean you just got it working today?

Ah, sorry I was too terse.  It means I used it on the ML300 for
debugging the kernel and drivers.  I also used it to load the
kernel into memory so I didn't have to muck with the CompactFlash.
I mainly used its gdbserver interface, but also did use the telnet
interface at times.  The BDI2000 config file I used was very terse.
The System ACE took care of initializing the hardware so by the
time the BDI got control, most things were pretty much taken care of.
Here's the INIT section from my file:
  [INIT]
  ; init core register
  WSPR    954     0x00000000      ;DCWR: Disable data cache write-thru
  WSPR    1018    0x00000000      ;DCCR: Disable data cache
  WSPR    1019    0x00000000      ;ICCR: Disable instruction cache
  WSPR    982     0x00000000      ;EVPR: Exception Vector Table @0x00000000
  ; Setup MMU info
  WM32    0x000000F0  0x00000000  ;invalidate page table base

Hope that was better,
    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/