Forum Discussion
15 Replies
- Altera_Forum
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
Attach signaltap on rx/tx lines and also check management interface. Are You sure the PHY is initialized?
- Altera_Forum
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
IMHO You lose 50% of throughput removing that waitrequest check...