I'm having trouble to bring up the TSE MAC to Ethernet interface on the Stratix II GX PCIe board. I was able to instantiate a triple speed Ethernet MAC and build logic around it. The loopback at the GMII interface seems work fine. However, I'm not able to send any packet out via the on board Marvell 88E1111 Ethernet transceiver. I suspect I need to program the registers in it via the MDIO. Is there a register map or data sheet of the 88E1111? Or is there anything else I'm missing? Thanks.

Hey guy, I have successfully make it works before(same dev board, same on-board PHY). A few tricks: 1. You need to do a RESET on the onboard Marvel PHY when you power up the board (only for this particular onboard PHY, I have no such problem with other Marvel88E111 daughter card or SFP). It is described in the Marvel document as about 10ns second reset (if not mistaken). You can either tie the PHY reset pin to the on board reset button or just use some hard logic to do it. Very odd, powerdown/powerup the board doesn't cleanly reset the PHY. (2. to 4. only apply if you are not using the sample application/example design/default TSE driver) 2. You need to make sure that your MAC, ethermode/speed bit in the command config register represent the mode the PHY is currently working at 3. Remember to turn off the INTERNAL_LOOPBACK register bits:) 4. Make sure that you know you are using/not using the 16-bits byte shifting/alignment feature (synthesis/register option in TX/RX_CMD_STAT), I don't think you need a Marvel Datasheet, all the general settings of any PHY is described in the TSE documentation, unless you need some extended/proprietary settings like turn on the automatic clock adjustment for RGMII interface.

Thanks. I somehow got it to work after playing with it for a while. I added some "redundant" initialization sequence in the logic including a reset of the PHY after power up. I suspect that's what made it work as you pointed out. --- Quote Start --- Hey guy, I have successfully make it works before(same dev board, same on-board PHY). A few tricks: 1. You need to do a RESET on the onboard Marvel PHY when you power up the board (only for this particular onboard PHY, I have no such problem with other Marvel88E111 daughter card or SFP). It is described in the Marvel document as about 10ns second reset (if not mistaken). You can either tie the PHY reset pin to the on board reset button or just use some hard logic to do it. Very odd, powerdown/powerup the board doesn't cleanly reset the PHY. (2. to 4. only apply if you are not using the sample application/example design/default TSE driver) 2. You need to make sure that your MAC, ethermode/speed bit in the command config register represent the mode the PHY is currently working at 3. Remember to turn off the INTERNAL_LOOPBACK register bits:) 4. Make sure that you know you are using/not using the 16-bits byte shifting/alignment feature (synthesis/register option in TX/RX_CMD_STAT), I don't think you need a Marvel Datasheet, all the general settings of any PHY is described in the TSE documentation, unless you need some extended/proprietary settings like turn on the automatic clock adjustment for RGMII interface. --- Quote End ---

Hi, I've got a pci express demo board and i want to use GbEthernet communication. For now, I was able to instantiate TSE MAC and make logic for initialization. with a big sate machine just like in the provided altera test bench. That seem's to work. But when i send frame on tx fifo interface, nothing come back on the rx fifo interface. And loopback is activate... I think some initializations are missing. I put below my init sequence. could you help me and say me if I wrong or not ? Init TSE MAC Sequence: - Read Version (@0x00) and check 0x00000800 - Write Scratch (@0x01) to 0xAAAAAAAA, readback and check - Write Config (@0x02) to 0x040083EB TX_ENA & RX_ENA = 1 ETH_SPEED = 1 PAD_EN = 1 CRC_FWD & PAUSE_FWD = 1 PAUSE_IGNORE = 1 TX_ADDR_INS = 1 LOOP_ENA = 1 RX_ERR_DISC = 1 - Write mac_0 & mac_1 (@0x03 & 0x04) to 0x22334450 & 0x0000EE11 (choose MAC: EE1122334450) - Write ipg length (@0x17) to 0x0C - Write frame length (@0x05) to 1518 (0x5EE) - Write pause quanta (@0x06) to 0x0F - Write rx_section_empty (@0x07) to 0x00 - Write rx_section_full, tx_section_empty, tx_section_empty (@0x08, 0x09, 0x0A) to 0x10 - Write rx_almost_empty, rx_almost_full, tx_almost_empty (@0x0B, 0x0C, 0x0D) to 0x08 - Write tx_almost_full (@0x0E) to 0x0A - Finally, Write mdio_addr0 (@0x0F) to 0x12. (Sorry for all this details but I wan't you have all the informations to help me!) Did I forget something during init process ? Could you help me ? Thanks you very much! Fabrice.

--- Quote Start --- Hey guy, I have successfully make it works before(same dev board, same on-board PHY). A few tricks: 1. You need to do a RESET on the onboard Marvel PHY when you power up the board (only for this particular onboard PHY, I have no such problem with other Marvel88E111 daughter card or SFP). It is described in the Marvel document as about 10ns second reset (if not mistaken). You can either tie the PHY reset pin to the on board reset button or just use some hard logic to do it. Very odd, powerdown/powerup the board doesn't cleanly reset the PHY. (2. to 4. only apply if you are not using the sample application/example design/default TSE driver) 2. You need to make sure that your MAC, ethermode/speed bit in the command config register represent the mode the PHY is currently working at 3. Remember to turn off the INTERNAL_LOOPBACK register bits:) 4. Make sure that you know you are using/not using the 16-bits byte shifting/alignment feature (synthesis/register option in TX/RX_CMD_STAT), I don't think you need a Marvel Datasheet, all the general settings of any PHY is described in the TSE documentation, unless you need some extended/proprietary settings like turn on the automatic clock adjustment for RGMII interface. --- Quote End --- Hi, I am using Stratix II gx board and TSE MAC core. Can u please give some more details (logic )on reset logic required to use MARVELL PHY. Thanks

Marvel Data sheet ? Where did you find that, I have been googling around all over and all I find is the 2 page Product brief. Any help greatly appreciated! -Art

TSE MAC and Marvell 88E1111 | Altera Community

42 Replies

Altera_Forum

Honored Contributor

16 years ago

--- Quote Start ---

As for the empty data packet, it can come from the CPU data cache. Try to flush the data cache before sending the packet, or use the alt_remap_uncached() function to modify your pointer to the memory buffer that you fill in.

--- Quote End ---

I tried to use uncashed but the result is the same.

8 Frame 69 (126 bytes on wire, 126 bytes captured) Arrival Time: Nov 24, 2009 13:50:20.538005000 
 
 
 
Frame Number: 69 Frame Length: 126 bytes capture Length: 126 bytes 
 
 0 
Ethernet II, src: 00:07:ab:f0:Od:ba (00:07:ab:f0:Od:ba), 
Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) S 
Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) 
Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    0    = IG bit: individual address (unicast)
    0    = LG bit: Globally unique address (factory default)
&#1032; &#1042; 
mds Header(unknown(0)/unknown(0)) &#1042; 
mds Header
...0 0000 0000 0000 = Packet Len: 0
     0000 0000 00.. = Dst index: 0x0000
    00 0000 0000 = src index: 0x0000
     0000 0000 0000 = VSAN: 0
&#1042; mds Trailer
eof: unknown (0) CRC: 0x00000000

Where can I have a look of configuring of SGDMA and how to бфлу a descriptor for daata memory to transmit?

Altera_Forum
Honored Contributor
16 years ago
Is the packet size correct?
To build a descriptor, you can use the functions defined in altera_avalon_sgdma.h.
The alt_avalon_sgdma_construct_mem_to_stream_desc() can build the descriptor for you. It is well described in the SGDMA datasheet.

If it isn't a cache problem, it could be because the SGDMA isn't reading the memory at the correct address. But at least it seems to try to read 126 bytes.
Altera_Forum
Honored Contributor
16 years ago
The size of packet is correct. I also use the standard functions from SGDMA.
Unfortunatelly I don't have any workable example with correct configured registers of TSE and SGDMA, maybe there is special bit I should set to make it work =(

I try to make it using the user guide of TSE and SGDMA with it examples.
here is the example of my code for Marvell 88e1111, if anybody would have a need of half worked example or anybody would look through the text of program and will find any mistakes or bugs it would be greatfull.
hello_world.zip5 KB

Altera_Forum

Honored Contributor

16 years ago

I can see a few problems in tse_mac_raw_sendM.

First you don't bypass the cache when writing the packet contents.

Second, in the "recopy to buf2" loop, you are reading the contents back using IORD_8DIRECT, whereas you filled it the [] operator. The second method uses the cache, but the first one bypasses it, so you may read back completely different data.

Third, you don't use the ActualData pointer in the SGDMA descriptor.

I would first create two uncached pointers:

char *uncached_pkt = alt_remap_uncached ((volatile void*) pkt, 256);
char *uncached_buf2 = alt_remap_uncached ((volatile void*) buf2, 1560);

Then use the uncached versions to access the data:

   uncached_pkt=0xCC;
   uncached_pkt=0xCC;
   for(k=2;k<254;k++){
    uncached_pkt=0xA5;
   }
   uncached_pkt=0xEE;
   uncached_pkt=0xEE;

      for(i=0;i<length;i++) {
         uncached_buf2 = uncached_pkt;
      }
      ActualData = (unsigned int*)buf2;

(by the way, I'm not sure buf2 will be properly 32-bit aligned this way...)

Then to remove bit 31 before building the descriptor, you need to call remap_cached, not remap_uncached:

    ActualData = (unsigned int*)alt_remap_cached ((volatile void*) ActualData, 256);

And finally build the descriptor with ActualData:

        alt_avalon_sgdma_construct_mem_to_stream_desc(
           (alt_sgdma_descriptor *) desc, // descriptor I want to work with
           (alt_sgdma_descriptor *) desc,// pointer to "next"
           (alt_u32 *)ActualData,               // starting read address
           (length),                                  //#  bytes
           1,                                        // don't read from constant address
           1,                                        // generate sop
           1,                                        // generate endofpacket signal
           0);                                       // atlantic channel (don't know/don't care: set to 0)

I hope this helps

Altera_Forum
Honored Contributor
16 years ago
unfortunatelly after the alt_avalon_sgdma_check_descriptor_status(desc) desc_stat = 119
Owned_by_HW = 1
and i get not free of errors descritor # define EINPROGRESS 119 /* Connection already in progress */

Altera_Forum

Honored Contributor

16 years ago

Try to use a separate descriptor for the "next" argument in alt_avalon_sgdma_construct_mem_to_stream_desc.

Maybe something like

        alt_avalon_sgdma_construct_mem_to_stream_desc(
           (alt_sgdma_descriptor *) desc, // descriptor I want to work with
           ((alt_sgdma_descriptor *) desc)+1,// pointer to "next"
           (alt_u32 *)ActualData,               // starting read address
           (length),                                  //#  bytes
           1,                                        // don't read from constant address
           1,                                        // generate sop
           1,                                        // generate endofpacket signal
           0);                                       // atlantic channel (don't know/don't care: set to 0)

I'm not sure about what happens if you make the descriptor point to itself as "next".

If that's not it, I don't have any other idea... I never had this problem with the SGDMA.

Altera_Forum
Honored Contributor
16 years ago
You are supposed to get that status until the transfer has been done. Try to call alt_avalon_sgdma_do_async_transfer() or alt_avalon_sgdma_do_sync_transfer() and check the status again.
Altera_Forum
Honored Contributor
16 years ago
didn't notice there is a TSE topic here.

http://www.alteraforum.com/forum/showthread.php?t=19915
Altera_Forum
Honored Contributor
16 years ago
Could anyone help me with my weird 88e1111 tx problem?
http://www.alteraforum.com/forum/showthread.php?t=20140
Altera_Forum
Honored Contributor
16 years ago
Good day.

I have a problem with NicheStack and a PHY.
I am using the 3sl150 Stratix III based devkit. As I am a beginner, I am using NIOS II standard design that comes with the board. As I tried to launch the Simple Socket Server (SSS) application, it could not allocate the PHY (the board's PHY is Marvell 88E1111 that is supported by the driver by default, as it is written in the documentation) and came up with the error:

[tse_mac_init]
INFO : TSE MAC 0 found at address 0x00001400
ERROR : MAC Group[0] - No PHY connected!
ERROR : PHY[0.0] - No PHY connected! Speed = 100, Duplex = Full
OK, x=401, CMD_CONFIG=0x00000000

The design uses Triple Speed Ethernet in RGMII mode for networking.

There are no other MAC interfaces (like lan91c111) in the design.

What can be wrong?

Forum Discussion

TSE MAC and Marvell 88E1111

42 Replies

Recent Discussions

DK-DEV-AGI027RBES missing device selection

SyncE clock as the reference for DDR, HBM, and FPGA control interfaces in the Agilex M-Series design

DK-DEV-AGI027RES Install Package

Cyclone V GT Dev Kit - new units fail to boot from FPP

Why 390.625MHz clock to F-Tile Reference fequency