Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

TSE-SGDMA something wrong

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

15 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.