In my now doing project, a altera Tse mac without sopc/os is used, I wanna to use only the Tse with udp/ip stack in a very fast image grab application.Basic hardware is Cyclone III + 88E1111(GMII),and 88e1111 works fine with my very simple sending test code but when I turn to Tse, huge problem. I've read the ug for Tse many times and know that before Tse transfer datas, I must config the Mac control registers who's interface is avalon-MM.Problem is when I do the configuration, the waitrequest signal of avalon-MM interface is always read as '1', which means it's busy and I cann't write to the control registers. I have tried a lot to solve this but none works, days gone and gone, helplessssss, so turn to help here, Any one with any suggestion is deeply appreciated. additional information: tse is config to work in 10/100/1000 multiport ethernet mac mode but only use one port. one pll is used to generate two clks , one is 125M used for tx_clk/rx_clk, another is 100M used for avalon-MM interface reset of tse is force to high for about 1 ms then goes to low. mac_tx_clk_n/mac_rx_clk_n output 125m clk ena_10_n/eth_mode_n outputs works as wanted as set_10_n/set_1000_n seted.
First be sure you wait long enough, the TSE's initialization phase can take several thousand cycles IIRC. If waitrequest stays up for more than that, then it means you have a problem.Is the TSE getting clocks on the PHY side too? It has some clock domain crossing logic inside, and the reset cycle will only complete if the TSE gets all its clocks.
I seem to have the same problem. I'm using Quartus 13.0sp1, TSE 13.0 10/100M Small MAC on a Cyclone IV E connected to a Micrel KSZ8021RNL with a small custom wrapper to convert RMII to MII. The PHY works fine, I can configure it using a custom MIIM design and I see data coming in through the RMII and MII interface when connected to an Ethernet network.However, the waitrequest signal of the MM interface stays high as described by the OP. My clocks are 100Mhz on clk, ff_rx_clk, ff_tx_clk, and a locally generated (just divide by 4 in logic, derived from the 100Mhz clk) 25Mhz for rx_clk and tx_clk. Those clocks are all active according to signaltab. I have not yet connected any logic to the FIFO interfaces except the clocks, but I DID set the "noprune" attribute on all the ff_rx_* signals to keep them visible in signaltab (and it seems to work, the signals do not turn red in SignalTab). I will do the same on the ff_tx_* signals just to make sure and test again, but since I would be very surprised if that was the problem, I wanted to get a post out first. Any insight on how to get the MM interface responsive would be greatly appreciated :) EDIT: I checked again with basically all signals marked as "noprune". Additionally, I implemented an additional reset after the clocks have been stable for some time. Both actions did not change the behavior in any way.
3x for replay, I have tried to use a external pin as the reset signal ,first tie up, then after I watch 100M, 125M clocks ok, pull the pin low, so I am sure reset time isn't the problem.Tse don't get clocks on the phy side, only GMII interface needed signals connect between Tse and Phy, tx&rx clks all from Tse side. As I know, Tse worked under mulit-port mac mode need tx_clk/rx_clk for data trans and clk for alavonMM, are there any other signals need?tell me if you know.
I've seen somewhere on the web said that waitrequest signal is high by default, and will be goes low after mac config regiters read and write, that confused me a lot. Had someone here used Tse monitored waitrequest signal? say something about this,plz.
Find the problem, seems waitrequest is by default '1', don't confused by that, you can write to/read from the mac control register and then wait for waitrequest '0' (1 clk pulse )to indicate that write/read done, then do the next write/read.The ug says waitrequest means "Register interface busy", I don't think it is exactly, easy to let me think of "busy". maybe directly "Register wait for request" is better.
This behaviour is allowed in the avalon specification (http://www.altera.com/literature/manual/mnl_avalon_spec_1_3.pdf): (page 3-3)--- Quote Start --- An Avalon-MM slave may assert waitrequest during idle cycles. An Avalon-MM master may initiate a transaction when waitrequest is asserted. The design of Avalon-MM slaves must take these possibilities into account. --- Quote End --- I don't remember how it is written in the TSE's manual, but usually the Avalon specification is a bit better.