Configuring TSE & Nichestack

[Altera_Forum]

I have Quartus&SBT 11.1, and a board with PHY 83848. 

I cannot bring up the eth interface with simple socket example. SOPC configuration is good (i hope), but i can't initialize the software:  Your Ethernet MAC address is 00:07:ed:ff:d7:52 prepped 1 interface, initializing... [tse_mac_init]  Error opening TX SGDMA init error -22 on net[0] mctest init called IP address of : 0.0.0.0 DHCP timed out, going back to default IP address(es)  With a (long) debug session, i saw that tse_mac_device[maxnets] global variable is not properly setted. How can i add a phy profile?

[Altera_Forum]

Ok, i'll try without external descriptor_memory, thanks!

[Altera_Forum]

Doesn't work. 

Maybe i need to set something on clock_crossing_bridge? Currently i havent bursts allowed and FIFO master to slave and viceversa are to default values

[Altera_Forum]

Nothing, doesn't work even if i left the clock_crossing_bridge and clock all design with ddr clock. 

It stucks at that DMA loop  But it's correct that dev->descriptor_base is 0? Shoudn't be the address of the main memory? It's always 0 (both with externam descriptor memory or internal)

[Altera_Forum]

No, the macro TSE_SYSTEM_EXT_MEM_NO_SHARED_FIFO should set it up with the address of your descriptor memory block.

[Altera_Forum]

I did it. I checked it many tines. Even eithout external memories and only one memory and clock doesnt work 

It stucks at dma loop. It seems a resource conflict. Perphas some priority (irq) has to be set in sopc?

[Altera_Forum]

No I don't think so. The IRQ number is automatically picked up at the driver instantiation and you would get a compile time error if it wasn't set properly. 

You need to trace the TSE driver instantiation and try to understand why it isn't setting dev->descriptor_base properly.

[Altera_Forum]

Ok, thanks. 

Ah, the board that i'm working on it's not a develpoment board, but a custom board

[Altera_Forum]

Ok, it seems that dev->descriptor_base is referred to a global variable set it up at alt_sys_init.c by calling a macro that it's defined in altera_avalon_sgdma.h: 

 #define ALTERA_AVALON_SGDMA_INSTANCE(name, dev) static alt_sgdma_dev dev = { ALT_LLIST_ENTRY, name##_NAME, ((void *)(name##_BASE)), ((alt_u32 *) 0x0), \ ((alt_u32) 0x0), ((alt_u32) 0x0), ((alt_sgdma_descriptor *) 0x0), ((alt_sgdma_descriptor *) 0x0), ((void *) 0x0), ((void *) 0x0), ((alt_u16) 0x0) };   Plase note that i'm using external descriptor memory. Bold line is descriptor_base and it's not touched in code after this initialization. However, if i put the descritor base inside bold line, it stucks again in dma loop, but dev->descritor_base is now correct. Question: descriptor_base should be the same value for sgdma tx and rx?

[Altera_Forum]

I haven't used the TSE driver in a long while, but I believe the proper way to initialize the descriptor memory base is via the TSE_SYSTEM_INT_MEM_NO_SHARED_FIFO and TSE_SYSTEM_EXT_MEM_NO_SHARED_FIFO macros. 

AFAIK you don't need to set up different descriptor bases for tx and rx, those are automatically taken care of by the driver that will use different addresses for each DMA. Did you try Signaltap to see what the DMAs are doing?

[Altera_Forum]

This just make no sense. 

In my main vhdl file i'm exporting sysclk.c3 as PHY clock (25 MHz since i'm using MII). If i set the sysclk PLL as normal pll, i get the warning "Critical Warning (176598): PLL "nios:nios_inst|sysclk:the_sysclk|sysclk_altpll_l4h2:sd1|pll7" input clock inclk[0] is not fully compensated because it is fed by a remote clock pin "Pin_F2"" but ethernet works as expected (all timings meeted) If i set the PLL in "no compensation" mode, all timing are meeted but the ethernet stucks at DMA loop

[Altera_Forum]

So You supply MII clock to PLL? Which one: TX or RX? Anyway it's a stupid idea... Use DDR controller clock output for the whole system.

[Altera_Forum]

No. 

My PHY want an external oscillator (25 MHz), i'm suppling it via fpga. I've exported a PLL output clock@25 MHz. Anyway, i've checked with another clock source to the PHY, it still work if my sysclk PLL is set to normal mode, but it stucks when i set it to no compensation. It seems a bug inside Altera's tools. Ah, my external crystal oscillator feed two pll (sysclk and ddr's pll) with the same input pin, it's okay?

[Altera_Forum]

Why not to use only ddr controller clock outputs? It already takes a PLL, so use that for the whole system. 133MHz is possible, but probably too much. Why not to use half rate clock output for all the components? Then You would need no clock crossing bridge, since the whole system would be synchronous.

[Altera_Forum]

Have you already solved this problem? I've just encountered with the same problem with you and I tried all method mentioned in this thread but doesn't work.  

I hope you can help me in some degree...

[Altera_Forum]

--- Quote Start ---  Have you already solved this problem? I've just encountered with the same problem with you and I tried all method mentioned in this thread but doesn't work.  I hope you can help me in some degree...  --- Quote End ---    Yep, the problem is a bug inside the SOPC buildeir. When i started a fresh new project everything goes ok, but when inside SOPC i modified the clk frequency of DDR the SOPC builder failed to generate appropiate files and then likely some internal timing violation occurs. The problem is 100% replicable with Nios 11.1sp2 with DDR block and TSE. If you have a similar issue, start a new project and rebuild manually from scratch the SOPC configuration. P.S. SOPC builder even when it failed to generate appropiate files still show "generated successfully" at the end, however in the middle of the log i saw a "failed"

[Altera_Forum]

Thank a lot. But there are somewhere different between your system and mine. There is no DDR RAM on my board, so i use a on-chip memory(500K) instead. Thus, my developing environment is Nios 11.0 with no service pack.

[Altera_Forum]

I have a similar looking system, anything specifically in the system that you'd recommend changing?

[Altera_Forum]

--- Quote Start ---  I have a similar looking system, anything specifically in the system that you'd recommend changing?  --- Quote End ---    If you have a DDR controller and TSE, simply don't change the DDR clock frequency after the first time. If you have to modify the frequency, start a fresh new SOPC project.

[Altera_Forum]

--- Quote Start ---  If you have a DDR controller and TSE, simply don't change the DDR clock frequency after the first time. If you have to modify the frequency, start a fresh new SOPC project.  --- Quote End ---     Thanks, I was actually curious about Socrates message about the SOPC system being a mess... not sure if the way the addresses are assigned is not good practice, or if it's something else. My Qsys system looks similar, so just looking for ways to possibly improve it.