TSE-SGDMA something wrong

[Altera_Forum]

Hi all, 

I'm working on a custom board with nios2 + tse (10/100/1000) + DDR sdram... I'm trying to use a driver for triple speed eth under u-boot...the driver has been already tested on an altera demo board and is working fine.... On my custom board...the nightmare....I'm able to transmit correctly a packet (ARP request) to PC but when I get the response (ARP Reply) I find that the first byte of the packet (in the destination mac field) is always dropped... Really strange...at first I tought to some problem between sgdma_rx and ddr...something like a problem that avoid the first byte to be transferred in memory... Then I did this...I've enabled the rx_shift16 and I found that the packet is actually shifted by 2 bytes but the first byte of dmac field is always missing... In other words: arp request to PC: ff ff ff ff ff ff 01 02 3e 0a etc.. arp reply by PC: 01 02 3e 0a etc.. received : 02 3e 0a etc... rx_shift16 enabled: received : 00 00 02 3e 0a  TSE seems always dropping one byte.... I don't know how solve it... Any help will be appreciated..  Carlo

[Altera_Forum]

This is a test

[Altera_Forum]

what do you mean??? :confused:

[Altera_Forum]

What PHY are you using and what is the interface with the PHY? Did you constrain the I/O to the PHY and does the design meet timing requirements?

[Altera_Forum]

Hi Daixiwen..thanx for you reply....now I'm enabling loopback on mac to check problems with phy.... 

 Phy is a more than standard DP83848C (that I've already on the demo and is working well)..interface is MII..I don't think that more than a reset and autoneg enable is needed...(anyway I see link going up correctly...)  I have some doubt on the clock constraint...I don't remember but someone told me that the sdc automatically generated for tse doesn't constraint the 25 mhz input clock....am I wrong??  The only problem I can think about is a timing violation...  Any idea???  Carlo

[Altera_Forum]

yes, the sdc generated with the TSE core only constrain the TSE's internal paths, you need to constrain the interface to the PHY yourself. 

It could be a good idea to add a signaltap probe on your MII interface to see what is going on. It could help you find the origin of the problem.

[Altera_Forum]

Maybe we found the question....I've noticed that in the demo (that uses the same PHY but different interface RMII) the clock that should be coming from the PHY is instead generated internally from the PLL....this seems strange but should be reasonable considering that niosII and Phy are feeded by the same external oscillator... 

 Carlo

[Altera_Forum]

Ok...the problem is PHY clock....with the over mentioned change now I usually see the complete packet without any problem....anyway sometimes the error comes back again...not in the head (first byte) but in the tail (last byte) especially with big packets.... 

 Now I understand that problem is there...it only need to correctly center phy clock....  Daixiwen and the others....which is the best way to regenerate this clock???  Thanx Carlo

[Altera_Forum]

You must be absolutely sure that the MAC and PHY use the same clocks. In MII mode the PHY is giving both the transmit and receive clocks to the MAC. 

In RMII mode an external 50MHz clock source provides the reference clock to both the MAC and the PHY. Some PHY have options to synchronize the data pins with the centre of the clock signal instead of the rising edge. This can help too but as long as you constrain your interfaces properly it shouldn't be a problem.

[Altera_Forum]

Yes..you are right...it is a constraint problem....our PHY doesn't allow settings on clock phase...I had already checked that....:( 

 Anyway we are on the problem...at least..  Thanx Carlo

[Altera_Forum]

Dear all, 

can someone, please, summarize the steps that must be followed in timing constraining a design that include a tse?  I guess that tse_timing_constraint.sdc must be added in the timing analyzer sdc file list, but what must be done then? Is there something more that must be constrained? is there somenthing that must be edited in the tse-*.sdc file? Thanks A lot.

[Altera_Forum]

I don't think that you need to edit anything in the generated sdc file. However the interface to the PHY chip isn't constrained by that file, and you need to do it yourself.

[Altera_Forum]

Hi, 

 I created a SDC file for the PHY DP83848C some time ago. Maybe this file helps you out a little bit. Like I understood it is necessary to create the TX and RX Clock in the SDC. After that you have to define which Pins are synchronus to these Clocks.

[Altera_Forum]

Hi all, 

thread is becoming interesting....now it works... I upload the constraints changes we added to make it work...obviously changes are due to fully constraint MII interface...  Carlo :)

[Altera_Forum]

--- Quote Start ---  I don't think that you need to edit anything in the generated sdc file. However the interface to the PHY chip isn't constrained by that file, and you need to do it yourself.  --- Quote End ---    Thanks. I tried to do it but my design still doesn't work. I'm going to be very depressed for this. What made me concerned about timing is a message I got in the "ignored constraints" in TimeQuest. There is a list of "clock creations" commands that comes from tse_constraints.sdc. I'm not an expert in this kind of architecture so my only way to debug by now was trying to run a simple_socket_server application. From NioS side everything seems to work, but I can't reach the erver anyway. DO you have a suggestion to me to break  the chain and investigate this problem? I'm using TSE in RGMII mode. Thank a lot.

[Altera_Forum]

The first thing to do in my opinion is to put some signaltap probes on the RGMII interface and see what is going on over there.