Xilinx IP core drivers for RTEMS- diff attached

[Robert S. Grimes]

Argh!  My memory fails me again!  Going back and looking at the
plb_temac XPS IP, I noticed it does support a FIFO mode without DMA. 
What was blurring my memory is that you must decide when you generate
the FPGA configuration if you want to use FIFO mode or SGDMA mode; once
that decision has been made, you must stick with it.  My memory,
however, erroneously informed me that plb_temac only supports SGDMA. 
Turns out there is a middle ground between the previous two options I
outlined, which is the FIFO mode (with or without interrupts), which
uses much more reasonable FPGA resources; again on the ml403's V4FX12,
it uses about 14% of slice FF, 24% of slices, and 17% of the 4-input LUT.

Given these number, I would like to suggest going with the
plb_temac/hard_temac combo, in interrupt-driven FIFO mode.  There are
basically three reasons why I now endorse this candidate:

   1. Fully supported by XPS, meaning you can XPS to manage your
      project; if you have the latest service pack for EDK, you can even
      use the Base System Builder (BSB) to get you started.
   2. The corollary to 1 is that you don't have to use ISE and deal with
      all the details that entails, which would be rather daunting to
      software-only folks.
   3. It offers a reasonable level of performance without incurring the
      complexity of scatter-gather DMA.

Just my updated $0.02, adjusted for memory lapse-induced inflation.
-Bob


Robert S. Grimes wrote:
> Sounds fine to me.
>
> At this point in time, I am ready to help with the xilinx_hardemac
> driver; I personally have no real interest in the soft flavor.  I would
> be happy to lead, follow, or get out of the way  :-P , whatever works
> best.  I am still rather new to RTEMS, but that's going to change in the
> next few months...  What I'm really driving at is that I'd like to
> contribute to what you guys are doing, in whatever way is best.
>
> That said, we should come to consensus on the hardware configuration for
> the xilinx_hardemac driver development.  As I mentioned in an earlier
> email, there are essentially two different approaches we can take with
> the hard temac.
>
>    1. http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf - minimalist
>       approach (V4 emac)
>    2. http://www.xilinx.com/bvdocs/appnotes/xapp941.pdf - full-featured
>       approach (plb_temac and hard_temac)
>
> I have successfully used the "full-featured" approach from within the
> Xilinx XPS, but it is a bit of a resource hog; on the ml403's V4FX12, it
> uses about 33% of slice FF, 60% of slices, and 45% of the 4-input LUT. 
> This is not really a problem for my application (they're giving me
> FX60s!), it does seems excessive, especially for people wanting to use
> the lower cost ml403 boards. I could be talked into going with the
> minimalist approach, but that presents some non-trivial rework on my end
> to hook the emac up within XPS.
>
> What have you been using, Greg?  How do you feel about this, Keith?  Am
> I correct in trying to build a consensus here?
>
> FYI, I am working on a system with three custom Virtex-4 FX-based
> processors interconnected via Ethernet, with actual hardware coming
> on-line in January; in the meantime, I have several Xilinx ml403 boards
> available for use.
>
> Thanks, and take care,
> -Bob
>
> gregory.menke at gsfc.nasa.gov wrote:
>   
>> Keith Robertson writes:
>>  > 
>>  > new libcpu dir: ppc405 (so we can easy follow differences to the 403)
>>  > new libbsp dir: virtex_shared
>>  > new emac name : xilinx_softemac (possibly/probably in libchip)
>>  > new hardemac  : xilinx_hardemac (when it's written.  probably in bsp.  I 
>>  > don't know of any xilinx plans to include the hardemac in anything other 
>>  > than the virtex).
>>  > 
>>
>> This would work for me.
>>
>> Greg
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>
>>
>>   
>>     
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
>
>