Xilinx IP core drivers for RTEMS- diff attached

Robert S. Grimes rsg at alum.mit.edu
Wed Dec 6 21:01:46 CST 2006


> Robert S. Grimes wrote:
> > I have used the plb_temac component, and have assumed I'll
> continue to do
> > so.  However, I'm not really tied to it.  In fact, I'm not sure I fully
> > understand something here.  I had originally been using pretty much the
> > out-of-box demo for the FX12-based ML403 board, but noticed
> that the soft
> > core emac used up a large amount of FPGA resources (IIRC 35-40% ?).  I
> > thought using the TEMAC would cut this way down, but the
> > plb_temac/hard_temac combination seems to take up almost as much, again
> > IIRC.  (Sorry, I'm at home right now, and my computer at work just died
> > anyway, so the real numbers are not available as I write this.)
>
> Keith Robertson wrote:
> Are you sure you're using the hard core emac?  AFAIK, the temac
> component can be instantiated in several ways.  It can be used as an
> stand alone soft core emac (suitable for the Spartan, or other chips
> without a hard core emac) or you can instantiate just the logic to
> connect from the ppc405 to the hard core emac (probably what most
> virtex4fx users would want).
Yes, I'm sure.  To be frank, I've found much of this to be very confusing,
at least to EDK beginners.  There are actually quite a few choices out
there.  I've finally been able to narrow it down a bit.  Assuming we want
the "hard core emac", there seems to be two basic approaches.  These seem to
be presented well in the following two app notes:

  http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf - minimalist approach

  http://www.xilinx.com/bvdocs/appnotes/xapp941.pdf - full-featured approach

The first approach uses the PowerPC, hard emac, a couple of FIFOs, and a bit
of logic.  It is very small!  I don't recall exactly why I didn't go this
way last spring when I first looked at this, but I think it was because it
was ISE-centric, and because it doesn't have Xilinx driver code.  The latter
approach I ended up using, primarily because I was able to generate it in
the EDK, and using the EDK drivers, I was able to get MicroMonitor up and
communicating via Ethernet.  Anyway, this approach uses two EDK components:
plb_temac and hard_temac.  The plb_temac provides a lot of neat features,
all parameterizable; it also implements scatter-gather DMA.

In summary, I went with the plb_temac/hard_temac approach, using the EDK to
develop the top-level FPGA configuration (i.e. EDK-centric); at the time, I
did not realize the resource hit the plb_temac represented.  I chose that
approach because my application is primarily an embedded processor one, with
a bit of custom logic that makes sense as peripherals; hence, it fit that
Xilinx PowerPC usage model.  The other approach is to create a VHDL entity
(or Verilog module) containing the PowerPC, and incorporating that into a
top-level ISE design; this is the Xilinx-recommended approach when the
PowerPC is more deeply embedded into a larger FPGA design.

Of course, there is no reason why we couldn't use the minimalist approach in
a EDK-centric approach; I didn't at the time because I only needed to
demonstrate functionality at that time, and the latter approach was much
easier to get up and running, especially with the drivers.  I also assumed
the scatter-gather DMA promises greater (potential) performance.  Because we
ended up with an FX60, the resources required by the plb_temac are not
really significant for me, but they probably are in the general case.
However, my extreme, worse case loading of 100 Mbit Ethernet is still only
3.5%, and I'm not sure I'll even use that much, so that isn't really a
driver for me.  Also, and here is where you all are more knowledgeable than
me, I'm not sure how important the Xilinx drivers are when it comes to an
RTEMS BSP.

So, what I'm saying is, I guess, I don't really care which way we go, though
I think I would still prefer an EDK-centric approach.

Does all this make any sense?  Or am I just way too confused?

-Bob



More information about the rtems-users mailing list