Avalon OpenCores Ethernet MAC and QII version 10 and higher

[Altera_Forum]

Hi, 

 I'm migrating my design to QII 10.1sp1 (after an unsuccessful try with v11.0) and can observe a warning with SOPC builder about the parameter SYS_CLOCK_RATE:CLOCK_DOMAIN that must be of type Integer but is of type String. Shall I simply modify the "_hw.tcl" to correct it?  Thanks in advance, Fred

[Altera_Forum]

I've done just a small number of Avalon-ST cores, but in my opinion - yes, You can edit it in tcl.  

On the other hand, I am not sure if You'll find it in tcl. It is probably set in VHD file :)

[Altera_Forum]

Well, I have changed the line  

add_parameter SYS_CLOCK_RATE STRING "0" for add_parameter SYS_CLOCK_RATE INTEGER 0 and the warning has disappeared.  However, the IP seems NOT working anymore once the design regenerated (tcpdump can't see anymore the ping packets issued from or to the system).  Has anyone succeeded to make OpenCore Eth working with QII v10sp1?  -- Fred

[Altera_Forum]

I have used OpenCores MAC with V8 and V9sp2. I checked now that project, but I didn't have the SYS_CLOCK_RATE parameter. 

Anyway, what is in _hw.tcl is for user configuration of parameters that are anyhow defined in HDL. I'd suggest you browse source files to find out the correct format and value required. You possibly can set it up to a fixed configuration.  Can you investigate further where is the failure? Are you using Nios with an OS? Can you check if mac/phy initialization is performed correctly and if incoming packets reach the mac?

[Altera_Forum]

The VISIBLE property of this parameter is set to false. That must explain why you think you don't have such parameter. Have a look to the file (its name is 'eth_ocm_hw.tcl') and you will see what I mean. 

However, it seems to be used only to do a 'set_module_assignment' of something called 'embeddedsw.CMacro.SYS_CLOCK_RATE. Because I'm using a Linux/MMU kernel, I don't think this is used and, thus, it doesn't explain this issue. I can add some printk() in the driver to see what's happening, but I can see the RX/TX packets counters growing while the errors counters remain null. That is very strange...

[Altera_Forum]

Attach signaltap on rx/tx lines and also check management interface. Are You sure the PHY is initialized?

[Altera_Forum]

Yes it is correctly initialized. I'm using the same kernel, that is flashed. 

What I power the board on, Linux boots and everything works fine. Once the FPGA is reprogrammed with the QII v10 design, the kernel reboots and, there, the eth0 is working anymore.

[Altera_Forum]

--- Quote Start ---  The VISIBLE property of this parameter is set to false. That must explain why you think you don't have such parameter. Have a look to the file (its name is 'eth_ocm_hw.tcl') and you will see what I mean.   --- Quote End ---   What I meant is that I used a older version of the ip (I guess 8.03), which had no SYS_CLOCK_RATE parameter.     --- Quote Start ---   I can add some printk() in the driver to see what's happening, but I can see the RX/TX packets counters growing while the errors counters remain null. That is very strange...  --- Quote End ---   If you can see rx/tx packet counters growing, I believe the problem is not with the mac itself but with the software drivers or more probably with the tcp/ip stack. You should try to send and receive raw ethernet frames to confirm the problem is not with the mac. But I don't know Linux, so I can't give you advice about how to do this.

[Altera_Forum]

Hi, 

 I'm also having problems running the Avalon OpenCores Ethernet MAC; one thing I stumbled over is in the "SOPC Builder to QSys Migration Guidelines AN 632", in the chapter "Avalon-MM wait-request Signal". It seems that the notion of the wait-request signal on the Avalon bus has changed. Is this possibly a problem for the current version of the OpenCores Mac?  I've never seen rdreq signal on the rx_dma fifo going up, and it seems to me, that in eth_avalon_rxdma.v it's assumed that the waitrequest is going down ...  Any ideas?

[Altera_Forum]

So, I've been messing around with the design of the opencore mac for Qsys and at least I'm able to recieve frames now, alltough tx is not yet working; here is me little patch to eth_avalon_rxdma.v. First there is the new conception of av_waitrequest; I just removed the condition from the av_write set. Also I've seen the RX_EOP coming up and going down before the FIFO captured it, so I changed the lines at the end ... 

I'm new to HDL/FPGA design ... does this make sense to you? Is it just working by luck?  diff -u ../eth_ocm//eth_avalon_rxdma.v eth_ocm//eth_avalon_rxdma.v --- ../eth_ocm//eth_avalon_rxdma.v 2010-02-05 12:07:22.000000000 +0100 +++ eth_ocm//eth_avalon_rxdma.v 2011-11-22 00:24:58.498985534 +0100 @@ -217,7 +217,7 @@    always @(posedge clk or posedge reset)  if(reset) av_write <= 1'b0; - else if(~av_waitrequest) + else  av_write <= pre_av_write;    always @(posedge clk) @@ -577,16 +577,17 @@      //We'll alow these to overrun -always @* begin dff_stat[MBYTE_BITS] = rx_state[RX_EOP ]; - if(rx_state[RX_EOP]) dff_stat[MBYTE_BITS+1] = rx_abort_r; - else dff_stat[MBYTE_BITS+1] = 1'b0; +always @* begin  + if(rx_state[RX_EOP]) dff_stat[MBYTE_BITS+1] <= rx_abort_r; + else dff_stat[MBYTE_BITS+1] <= 1'b0;  end   -always @(posedge rxclk) +always @(posedge rxclk) begin + dff_stat[MBYTE_BITS] <= rx_state[RX_EOP ];  if(rx_dv) begin dff_din_reg[rx_bcnt] <= rx_data;  dff_stat[0+:MBYTE_BITS] <= rx_bcnt;  end - +end

[Altera_Forum]

IMHO You lose 50% of throughput removing that waitrequest check...

[Altera_Forum]

Hi all 

Just to rev up the thread.  We are facing the same problem here. We have a design that uses ocm-eth and works using Q9.1sp2. It takes three hours to compile in 9.1 but only 25 mins in 10.1 or 11.1so we want to migrate to Q10 or Q11 :-) It is a uClinux no-MMU system and ocm-eth seems to be working but there are no incoming or outgoing packets. Tx and Rx counters grow, there are no errors but no packets over the wire Any news? Thanks In Advance

[Altera_Forum]

Check Nios linux mailing list.

[Altera_Forum]

Hi frd66 and keibee, 

Could you eventually operate OpenCores mac with Qsys? I'm now trying to migrate a design from 9.0sp2 (sopc builder) to 11.0sp1 with Qsys and I found this old thread.  The problem is similar to yours: all compiles fine, but I can't send/receive packets. Actually my MAC transmit only the very first packet, but after this the dma seems to get stuck. I checked the descriptor control reg and I found it never becomes ready again until I reconfigure the fpga. The control port works correctly: I can access mac registers and also the phy interface is ok. The problem seems to come from the rx/tx dma modules. I applied the code patch Keibee posted, but I still can't receive anything.  Like you, I can never see rd/wr request signals switching on dma ports.

[Altera_Forum]

Hi Cris72, 

Sorry, I stopped to use this core because there is no more support on it, and I suspect there is still a bug in it that makes the reception hang after a while (with the driver 'ethoc' under Linux/MMU). I'm thus using the TSE in its full variation since QII v10.x, with better performances and less headache !

[Altera_Forum]

Thank you for answering, Fred. 

Since I don't use Linux but I directly interface the core with my own driver, I hope I can overcome the problem... if I only could discover where it is! Moreover, in my case it works perfectly with QII V9.0, so I think it's definitely a minor issue, something changed from SOPC to Qsys. So far I could only discover this, by signaltapping the tx_dma module: - 1st packet trasmission:  bd_read is pulsed, then pulse on valid_rdata, then pulse on stat_ready   ethernet frame correctly transmitted out - 2st packet trasmission:  bd_read is pulsed, then pulse on valid_rdata, then rising edge on stat_ready;  at this point stat_ready is stuck to a high level until I reset everything  ethernet frame is not transmitted   I'll appreciate any comment or help