RE: Xilinx hard TEMAC

RE: Xilinx hard TEMAC

[Rick Moleres]

David,


<snip>
>=20
>     The choice and configuration of the TEMAC was driven by FPGA
> realestate.
>=20
>     My perception was that the "Hard" Temac was based on silicon
already
> in the FX (much like the PowerPC) while the "Soft" TEMAC is primarily
> implimented within the FPGA (much like the MicroBlaze).
>=20
>     Is that distinction between "soft" and "hard" correct ?
>=20

That is the correct distinction between "soft" and "hard".  Just know
that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.

>      If not is the only significant distinction between the PLB_TEMAC
> supported by the EDK and the LL_TEMAC the bus interface ?

Yes, this is one of the distinctions between LL TEMAC and PLB TEMAC. :-)

>      I should not think the difference between different bus
interfaces
> should be radically different in terms of FPGA cells. While
implimenting
> the MAC in the FPGA would likely be expensive in realestate.
>       I can try to argue for the PLB_TEMAC - as something that will
have
> Xilinx/MV support and may get incorporated in the standard Kernel - If
> the cost in cells is not substantial.
>=20

I believe LL_TEMAC is smaller than PLB_TEMAC, and so this could be a
tough sell for you if FPGA space is at a premium.  When put in a system
with other stuff (e.g., memory controller, etc...) the size gets closer,
but I think GSRD is still smaller.  Sorry, I don't have the numbers.
There were improvements to PLB TEMAC in EDK 8.1.2 to address some size
issues, and even more planned down the road to hopefully converge the
two.

>=20
>=20
> > The Linux driver posted for the TEMAC (by MontaVista) is for the
> > PLB_TEMAC.  Updates to this driver may also be released with the EDK
> > (e.g., EDK 8.1.2 updated the driver to include checksum offload).
There
> > is a Linux driver for the LL_TEMAC that comes with GSRD, but my
group's
> > efforts go toward the PLB_TEMAC as that is the EDK IP we want to
promote
> > and whose drivers we'd like to see in kernel.org.
> >
>     How can I get a copy of the GSRD LL_TEMAC ? Is it a 2.4 or 2.6
driver
> ?
>=20

You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
design, and inside of that design somewhere you'll find a Linux 2.4
driver for the LL TEMAC.

> > By the way, there is no relation to the IBM EMAC.
> >
>     These things are worth knowing.
>=20
>     The T still means Tri. is there some specific EMAC that was used
as
> a reference for the design or is the TEMAC entirely a Xilinx creation
?
>=20

It's a Xilinx creation as far as I know.

> > Hope that helps,
> > -Rick
> >

Re: Xilinx hard TEMAC

[David H. Lynch Jr.]

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

Rick Moleres wrote:
> That is the correct distinction between "soft" and "hard".  Just know
> that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
> the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
>   
    First, thanks, your remarks have been enormously helpful.

    I have successfully put together a Driver for the TEMAC currently
used in the Pico E-12.
   
    I am still having some difficulty corresponding this TEMAC
implimentation to any of Xilinx's documentation.
    It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web
Server application.
    It seems to be extremely minimal. Basically a DCR interface for most
things that closely matches the GSRD documents.
    and TX and RX FIFO's that I can't seem to find documented anywhere,
but I have working based on the Treck WebServer code.

    I am have two remaining problems and then I am done.
   
       The first is I am currently doing polled I/O. The transmits
happen as they are requested and the receives are picked up ona a timer
interrupt.
    But I am dropping about 50% or more of the receives. I will work
that out myself eventually.

       The second is that this driver will serve as the basis for a
driver in other Pico supported OS's. Some of which have no means of
doing Polled Receives.
       And I can not get interrupts working. Since my hardware does nto
match anything perfectly - except that Treck Webserver application and
that does not do interrupts.
    I am reading all the Xilinx TEMAC Documents and the GSRD documents
reference an IRENABLE register and an IRSTATUS register, I cobbled
something together
    assuming that they were access much as the other DCR registers in
that block and I assumed the bits in IRSTATUS and IRENABLE matched the
definitions of those
    in larger TEMAC implimentations. It appeared after I enabled TX and
RX complete interrupts that when I have received data available the
IRSTATUS register has the
    Bit set for an Rx interrupt. All fine - except that no interrupt
actually occurs.
    I can force interrupts from the PHY using the same IRQ so the IRQ is
connected correctly and programmed correctly. Other TEMAC
implimentations seem to have a GIE - Global Interrupt enable
    Bit, but I do not have a clue where to look here. What I could get
out of the Xilinx Webset GSRD seems to be a Linux driver that uses the
DMA unit and that generates its own interrupts.
    I don't think I have the DMA in my bit image.

    Anyway any clues as to where I can find some useful docs on
Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer
application ?











> Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my
>   
> group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to
>   
> promote and whose drivers we'd like to see in kernel.org.
>
> You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
> design, and inside of that design somewhere you'll find a Linux 2.4
> driver for the LL TEMAC.
>   
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein


[-- Attachment #2: Type: text/html, Size: 5207 bytes --]

RE: Xilinx hard TEMAC

[Rick Moleres]

[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]

David,

 

Could you send a system.mhs file from the EDK project you're using so I
can get a bearing on what exactly you have in the hardware?  I didn't
think the LL TEMAC could be used without the DMA engine (CDMAC), which
is where the interrupts come from in the Linux/VxWorks drivers I've seen
for this core.

 

-Rick

 

________________________________

From: David H. Lynch Jr. [mailto:dhlii@dlasys.net] 
Sent: Saturday, July 29, 2006 7:09 PM
To: Rick Moleres
Cc: linuxppc-embedded
Subject: Re: Xilinx hard TEMAC

 

Rick Moleres wrote: 

 
That is the correct distinction between "soft" and "hard".  Just know
that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
  

    First, thanks, your remarks have been enormously helpful.

    I have successfully put together a Driver for the TEMAC currently
used in the Pico E-12.
    
    I am still having some difficulty corresponding this TEMAC
implimentation to any of Xilinx's documentation.
    It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web
Server application.
    It seems to be extremely minimal. Basically a DCR interface for most
things that closely matches the GSRD documents.
    and TX and RX FIFO's that I can't seem to find documented anywhere,
but I have working based on the Treck WebServer code.

    I am have two remaining problems and then I am done.
    
       The first is I am currently doing polled I/O. The transmits
happen as they are requested and the receives are picked up ona a timer
interrupt.
    But I am dropping about 50% or more of the receives. I will work
that out myself eventually.

       The second is that this driver will serve as the basis for a
driver in other Pico supported OS's. Some of which have no means of
doing Polled Receives.
       And I can not get interrupts working. Since my hardware does nto
match anything perfectly - except that Treck Webserver application and
that does not do interrupts.
    I am reading all the Xilinx TEMAC Documents and the GSRD documents
reference an IRENABLE register and an IRSTATUS register, I cobbled
something together 
    assuming that they were access much as the other DCR registers in
that block and I assumed the bits in IRSTATUS and IRENABLE matched the
definitions of those 
    in larger TEMAC implimentations. It appeared after I enabled TX and
RX complete interrupts that when I have received data available the
IRSTATUS register has the 
    Bit set for an Rx interrupt. All fine - except that no interrupt
actually occurs.
    I can force interrupts from the PHY using the same IRQ so the IRQ is
connected correctly and programmed correctly. Other TEMAC
implimentations seem to have a GIE - Global Interrupt enable
    Bit, but I do not have a clue where to look here. What I could get
out of the Xilinx Webset GSRD seems to be a Linux driver that uses the
DMA unit and that generates its own interrupts.
    I don't think I have the DMA in my bit image.

    Anyway any clues as to where I can find some useful docs on
Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer
application ?














Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my
  
group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to
  
promote and whose drivers we'd like to see in kernel.org.
 
You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
design, and inside of that design somewhere you'll find a Linux 2.4
driver for the LL TEMAC.
  
 
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
  






-- 
Dave Lynch                                                 DLA Systems
Software Development:                                   Embedded Linux
717.627.3770            dhlii@dlasys.net          http://www.dlasys.net
fax: 1.253.369.9244                                Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
 
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein

[-- Attachment #2: Type: text/html, Size: 14014 bytes --]

Re: Xilinx hard TEMAC

[David H. Lynch Jr.]

Rick Moleres wrote:
> David,
>
> I'll see if I can clarify a bit.  In Virtex-4, there is a silicon-based
> Hard TEMAC.  But in order to get to it (and have things like buffering
> and DMA) you need a soft wrapper - which comes in two flavors.  One is
> the LL_TEMAC, which is released as part of the GSRD reference design.
> The other is PLB_TEMAC, which is released in the EDK.  The fundamental
> difference between the two (I'm simplifying) is that the LL_TEMAC and
> GSRD system keep data off the PLB bus, using LocalLink point-to-point
> connections between the LL_TEMAC and the memory and DMA controllers.
> The PLB_TEMAC's data path is over the PLB.  The LL_TEMAC also supports
> both channels of the Hard TEMAC, whereas the PLB_TEMAC does not (yet).
> Both are comparable in performance.  The PLB_TEMAC, as part of the EDK,
> has the official Xilinx support that other EDK IP has, whereas LL_TEMAC
> and GSRD are just a reference design.
>   
    Thanks, you have clarified things somewhat. I was vaguely aware of
the differences between the locallink and PLB.

    Though I still have some confusion.

    In my environment FPGA space is precious. The FPGA firmware for
Linux uses the UartLite, and does not include a PIC.
    The objective is to leave as much of the FPGA available for
application use as possible. Some current uses of the remaining FPGA
space have included
    decryption engines and FFT's. I am not part of the firmware process
- I am just responsible for Linux and any requests I make that require
more FPGA realestate
    tend to get stomped on.

    The choice and configuration of the TEMAC was driven by FPGA realestate.

    My perception was that the "Hard" Temac was based on silicon already
in the FX (much like the PowerPC) while the "Soft" TEMAC is primarily
implimented within the FPGA (much like the MicroBlaze).

    Is that distinction between "soft" and "hard" correct ?

     If not is the only significant distinction between the PLB_TEMAC
supported by the EDK and the LL_TEMAC the bus interface ?
     I should not think the difference between different bus interfaces
should be radically different in terms of FPGA cells. While implimenting
the MAC in the FPGA would likely be expensive in realestate.
      I can try to argue for the PLB_TEMAC - as something that will have
Xilinx/MV support and may get incorporated in the standard Kernel - If
the cost in cells is not substantial.
   
   

> The Linux driver posted for the TEMAC (by MontaVista) is for the
> PLB_TEMAC.  Updates to this driver may also be released with the EDK
> (e.g., EDK 8.1.2 updated the driver to include checksum offload).  There
> is a Linux driver for the LL_TEMAC that comes with GSRD, but my group's
> efforts go toward the PLB_TEMAC as that is the EDK IP we want to promote
> and whose drivers we'd like to see in kernel.org.
>   
    How can I get a copy of the GSRD LL_TEMAC ? Is it a 2.4 or 2.6 driver ?

> By the way, there is no relation to the IBM EMAC.
>   
    These things are worth knowing.

    The T still means Tri. is there some specific EMAC that was used as
a reference for the design or is the TEMAC entirely a Xilinx creation ?

> Hope that helps,
> -Rick
>
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

RE: Xilinx hard TEMAC

[Rick Moleres]

David,

I'll see if I can clarify a bit.  In Virtex-4, there is a silicon-based
Hard TEMAC.  But in order to get to it (and have things like buffering
and DMA) you need a soft wrapper - which comes in two flavors.  One is
the LL_TEMAC, which is released as part of the GSRD reference design.
The other is PLB_TEMAC, which is released in the EDK.  The fundamental
difference between the two (I'm simplifying) is that the LL_TEMAC and
GSRD system keep data off the PLB bus, using LocalLink point-to-point
connections between the LL_TEMAC and the memory and DMA controllers.
The PLB_TEMAC's data path is over the PLB.  The LL_TEMAC also supports
both channels of the Hard TEMAC, whereas the PLB_TEMAC does not (yet).
Both are comparable in performance.  The PLB_TEMAC, as part of the EDK,
has the official Xilinx support that other EDK IP has, whereas LL_TEMAC
and GSRD are just a reference design.

The Linux driver posted for the TEMAC (by MontaVista) is for the
PLB_TEMAC.  Updates to this driver may also be released with the EDK
(e.g., EDK 8.1.2 updated the driver to include checksum offload).  There
is a Linux driver for the LL_TEMAC that comes with GSRD, but my group's
efforts go toward the PLB_TEMAC as that is the EDK IP we want to promote
and whose drivers we'd like to see in kernel.org.

By the way, there is no relation to the IBM EMAC.

Hope that helps,
-Rick

-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of David H. Lynch Jr.
Sent: Thursday, July 13, 2006 5:50 PM
To: linuxppc-embedded
Subject: Xilinx hard TEMAC


I am trying to get the Xilinx TEMAC working. I am getting an education
in Xilinx, TEMAC's, PHY's, ... in the process.

The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
It is my understanding that this is the TEMAC builtin to the FX parts,
not one that is created in the FPGA.

Is anyone else working to support that configuration ? I think that is
basically the same as the GRSD TEMAC.
Is it sane to try to adapt the soft TEMAC patch from the list ?

I have a driver that works under uCos as a starting point. It initially
appeared to use basically the same xilinx_edk code that the linux temac
driver patch that has been the subject of a number of messages uses. But
on deeper inspection that dependence appears to be very shallow - mostly
using the edk macros to read the PHY and registers in the MAC.

Am I correct that the TEMAC patch floating arround is not for that TEMAC
?

I am also trying to digest the paternity of the TEMAC. Is the basic
programming of the hard TEMAC and the IP TEMAC the same ? i.e. does the
fact that the both have TEMAC in their name actually express some
commonality ? TEMAC means Tri-Mode EMAC - does that mean there is some
commonality with the IBM EMAC ?

I have a driver in the works that is based on the working uCos code I
mentioned, as well as I think the pcnet32 driver as a very basic
template.
I seem to got the PHY portions working, but then addapted to the
separate PHY driver model with the MAC driver providing routines to
access the PHY registers. I may have that working. I think I have DCR
access to the MAC registers working. I am just starting on getting the
TX and RX code working.

I actually started trying to get the posted TEMAC patch working but that
quickly went off the rails - I presumed because the hard and soft
TEMAC's are just too different, or because the xilinx_edk really does
not support the hard TEMAC.

The xilinx_edk based driver seems incredibly complex. I think the OS
independent xilinx_edk incurrs a high cost in obscurity - but I am not
looking to gore someone elses ox, just solve my problem.

If the edk based driver is going to make it into the kernel, and
somebody who understands better than I beleives that it is reasonable to
adapt that to support the hard TEMAC too, I am willing to pursue that
approach.

Regardless. I need to get a driver working, and I am not looking to
duplicate effort.




--=20
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.

"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx hard TEMAC

[Ming Liu]

Hi David,

>The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
>It is my understanding that this is the TEMAC builtin to the FX parts,
>not one that is created in the FPGA.

That's right. The hard Temac is a built-in hard core in virtex 4 FPGA. 

>Is anyone else working to support that configuration ? I think that is
>basically the same as the GRSD TEMAC.
>Is it sane to try to adapt the soft TEMAC patch from the list ?

I am working on that. But I am not so experienced and still working. :)

>I actually started trying to get the posted TEMAC patch working but that
>quickly went off the rails - I presumed because the hard and soft
>TEMAC's are just too different, or because the xilinx_edk really does
>not support the hard TEMAC.

I don't think so. I think the hard and soft cores are similar. I have 
included the enet drive in Linux 2.4 and it works well. Now I am including 
the Temac in 2.6 and have not see the result. 

>Regardless. I need to get a driver working, and I am not looking to
>duplicate effort.

I am doing that. So we can share our experience. 

Regards
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  

Xilinx hard TEMAC

[David H. Lynch Jr.]

I am trying to get the Xilinx TEMAC working. I am getting an education
in Xilinx, TEMAC's, PHY's, ... in the process.

The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
It is my understanding that this is the TEMAC builtin to the FX parts,
not one that is created in the FPGA.

Is anyone else working to support that configuration ? I think that is
basically the same as the GRSD TEMAC.
Is it sane to try to adapt the soft TEMAC patch from the list ?

I have a driver that works under uCos as a starting point. It initially
appeared to use basically the same xilinx_edk code that the linux temac
driver patch that has been the subject of a number of messages uses. But
on deeper inspection that dependence appears to be very shallow - mostly
using the edk macros to read the PHY and registers in the MAC.

Am I correct that the TEMAC patch floating arround is not for that TEMAC ?

I am also trying to digest the paternity of the TEMAC. Is the basic
programming of the hard TEMAC and the IP TEMAC the same ? i.e. does the
fact that the both have TEMAC in their name actually express some
commonality ? TEMAC means Tri-Mode EMAC - does that mean there is some
commonality with the IBM EMAC ?

I have a driver in the works that is based on the working uCos code I
mentioned, as well as I think the pcnet32 driver as a very basic template.
I seem to got the PHY portions working, but then addapted to the
separate PHY driver model with the MAC driver providing routines to
access the PHY registers. I may have that working. I think I have DCR
access to the MAC registers working. I am just starting on getting the
TX and RX code working.

I actually started trying to get the posted TEMAC patch working but that
quickly went off the rails - I presumed because the hard and soft
TEMAC's are just too different, or because the xilinx_edk really does
not support the hard TEMAC.

The xilinx_edk based driver seems incredibly complex. I think the OS
independent xilinx_edk incurrs a high cost in obscurity - but I am not
looking to gore someone elses ox, just solve my problem.

If the edk based driver is going to make it into the kernel, and
somebody who understands better than I beleives that it is reasonable to
adapt that to support the hard TEMAC too, I am willing to pursue that
approach.

Regardless. I need to get a driver working, and I am not looking to
duplicate effort.




-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein