TSE_MAC and memory

[Altera_Forum]

Hi Guys, 

 I've been building on examples and built a functioning ethernet. I can use the Nios for TCP TX/RX and i have interfaced some HDL for direct UDP TX.   I'm currently developing on a DE2-115 and i'm merging this and the D5M camera example. I'll be building my own board soon. Problem is both use the SDRAM in their isolation and i need to merge.   de2-115 has  - sdram 2x64mb(16bit wide) used together as 32bit wide. - sram - 2mb   1. how can i determine how much memory the tse_mac needs? 2. does the niche stack use the sram?   regarding point 1: the example i took just used the full 128mb and the BSP says it uses it all, but i imagine that more means it allocates it all.   [update]  point 2: I've tried to remove the SRAM in the past but my ethernet initialisation gets stuck after    INFO : TSE MAC 0 found at address 0x0c042000 INFO : PHY Marvell 88E1111 found at PHY address 0x10 of MAC Group INFO : PHY - Automatically mapped to tse_mac_device INFO : PHY - Restart Auto-Negotiation, checking PHY link... INFO : PHY - Auto-Negotiation PASSED   According to the BSP linker, nothing seems to link it.  I've left the pin assignments, but i've removed it from the Qsys and commented it out of the module instantiation.   I've checked what i can timer wise. I also remember the first time i tried to do this, i did a signal tap on the sram and didn't pick up any enabling of it, or changes in data. But i may have missed something there.    Thanks in Advance for any comments and help.

[Altera_Forum]

I doubt it's a hardware problem if other examples work fine.

[Altera_Forum]

Well just looked and that LAN SMSC chip is only 10/100. 

 I can't find a honourable supplier with Marvell 88E1111. Anybody know where i could get one. Only place i've seen is Avenet and they don't respond to query requests

[Altera_Forum]

There are National chips already supported by TSE, but I would offer to use Micrel. Those PHYs are way much cheaper than National and Marvell, however You'll need to write a small driver for TSE to initialize it correctly.

[Altera_Forum]

Hi,  

 I've got the same problems and get stuck at the same as you. But I found something. I use too SSS exemple and I've seen that, if I made any change in Qsys the software don't work and get stuck at   [tse_mac_init] INFO : TSE MAC 0 found at address 0x0c042000 INFO : PHY Marvell 88E1111 found at PHY address 0x10 of MAC Group[0] INFO : PHY[0.0] - Automatically mapped to tse_mac_device[0] INFO : PHY[0.0] - Restart Auto-Negotiation, checking PHY link... INFO : PHY[0.0] - Auto-Negotiation PASSED  In debug mode make a break and where you are exactly stuck. Maybe it's like me.  But I succed to use the design without external memory. Don't make any change at the @ in qsys and do not delete anything or component in qsys.  It is my own experiment maybe you don't have the same things.

[Altera_Forum]

Thanks Calagan. I'll have a hopefully tonight. I'll update you within the next 24hrs.

[Altera_Forum]

Ok Calagan. 

 A good idea and it worked. But note that i've been able to make plenty of changes to the SOPC, i just can't remove the SRAM. Disconnecting the SRAM from the SPOC in HDL and hooking random pins for the SOPC inputs worked.   I ran some debugs and when i was actually steeping through using F6 and F7, it got passed the auto negotiate. But when io hiot continue it got stuck. If i didn't set a break point it would get stuck after the auto negotiate. When i pushed pause after getting stuck (in either case), it shows its stuck int eh while loop below:   altera_avalon_sgdma.c Lines 212 to 214  /* Wait for the descriptor (chain) to complete */ while ( (IORD_ALTERA_AVALON_SGDMA_STATUS(dev->base) & ALTERA_AVALON_SGDMA_STATUS_BUSY_MSK) );    I can't see why the removal of the SRAM affects the sgdmas?   Same for you?

[Altera_Forum]

Hi AsValdr,  

 Exactly the same as me, the sgdma wait for receive the descriptor chain.  Are you using SOPC or QSYS ?   I don't know why there is a problem with the descriptor. Maybe a problem with the connnection with the on-chip memory of the descriptor ?   Can you tell me if you it works if you re-add the sram controller like the original project ?   I don't If there is some people from Altera in this forum ?   Maybe some other developpers can test the same thing and tell us if it work or not ?   Thanks.  ps: I debug the sgdma and see that the descriptor chain is not receiv.

[Altera_Forum]

I found something interresting, the sgdma's (rx and tx) are connected to the uas port of the ssram and ext_flash. 

 I've started this test with the original project. I disconnect rx and tx sgdma from ext_flash. Recompile and test ----> don't work and stuk like usual (wait descriptor chain).  I go back to Qsys and make ctrl+z to have my connection restored. Recompile and test ----> don't work too, same problem.  Interresting. I investigate.