How to constrain tse on cyclone III board

Usually the tse sopc sdc file is enough. Then you only need to constrain your input clock and PLLs outputs, which drive your mac rx/tx clock ports.

I'm not an Ethernet guru but I think the extra FF in the preamble is not a problem, since the mac should discard symbols until it receives a complete the preamble sequence (and this eventually arrives correctly, isn't it?); when the preamble has been received the mac will receive the actual data payload.

I just had a look at the Altera example for the Cyclone III dev board, and amazingly they don't put any timing constrains on the RGMII interface... Not good for a "design example" ;)

You can use those .sdc files from the uCLinux reference design from the Nios wiki.

There are two PHY registers that you can change in the Marvell PHY to specify that the receive and transmit data should be center-aligned with the clock rather than edge-aligned. I don't remember the registers addresses, but you should find them by doing a search on the forum. I don't remember what the Altera TSE driver is doing when initializing the Marvell PHY.

--- Quote Start ---

I just had a look at the Altera example for the Cyclone III dev board, and amazingly they don't put any timing constrains on the RGMII interface... Not good for a "design example" ;)

You can use those .sdc files from the uCLinux reference design from the Nios wiki.

There are two PHY registers that you can change in the Marvell PHY to specify that the receive and transmit data should be center-aligned with the clock rather than edge-aligned. I don't remember the registers addresses, but you should find them by doing a search on the forum. I don't remember what the Altera TSE driver is doing when initializing the Marvell PHY.

--- Quote End ---

So according to you, is the extra "ff" in preamble a problem for MAC to correctly receive the packet?

--- Quote Start ---

Usually the tse sopc sdc file is enough. Then you only need to constrain your input clock and PLLs outputs, which drive your mac rx/tx clock ports.

I'm not an Ethernet guru but I think the extra FF in the preamble is not a problem, since the mac should discard symbols until it receives a complete the preamble sequence (and this eventually arrives correctly, isn't it?); when the preamble has been received the mac will receive the actual data payload.

--- Quote End ---

Unfortunately, even if the complete preamble sequence eventually arrives correctly (verified by signalTap), the extra "ff" ahead of correct preamble sequence does bring me trouble. After I read statistics counter with address 0x074 (aAlignmentErrors counter) from MAC, I found MAC treat this frame as frame with alignment error and discard it.

I am not sure whether adding rx_clk delay to the PHY by programming bit7 of mdio register 20 (Marvell 88E1111) will remove the extra "ff" since according to my understanding, adding rx_clk delay by 2ns (setting bit7 to 1), the rx_clk can still sample one "f" instead of two "ff" (since "ff" will last one entire clock cycle, which is 8ns, delay rx_clk by 2ns will sample at least one "f"). Can anybody tell me how to remove the additional "ff"?

FYI, I am using RGMII interface and the rx_clk is 125MHz, generated from PHY.

I don't understand either... it is as if the valid signal is asserted one cycle too soon. I agree that it doesn't look like a timing problem. The data valid signal should only be raised by the PHY during the preamble and before the SFD. Not before the preamble.

Can you try the reference design and add the same signaltap probe, and see if you get any different results?

After carefully examine the data from RGMII using signalTap, I found that the data before preamble is "ffff" instead of "ff" (considering DDR). This is 16bits extra data, and I am wondering is it related with IP Payload Alignment to align packet header to 32-bit boundaries?

If the answer is yes, how should I remove this extra data? I tried to select "Align packet headers to 32-bit boundaries" option when I was generating tse MAC in SOPC builder and also tried set bit 25 of "rx_cmd_stat" register to 0 and 1, but no matter what, MAC still indicates this is a frame received with alignment error and then discard it.

I am using Windows XP "ping" command to generate the packet, so does this command generate the extra "ffff" or the Marvell PHY generate "ffff"?

No the payload alignment option will add 16 bits before the packet in the Avalon streams, but not on the (R)(G)MII side.

There isn't any reason why the ping command would add the extra ff. A packet starts with the preamble, and nothing else.