FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

tse ip core communicate with pc

Altera_Forum
Honored Contributor II
1,197 Views

hi, I instantiate the tse ip core with configuration of 10,100/1000Mb mac and RGMII interface in my project to communicate with pc,then initialize the register space of mac with the recommended initialization sequences in ug(except for the initialization of external phy using MDIO).The design works correctly with the simulation of modelsim. When i program my design on Cyclone IV GX EP4CGX150DF FPGA Development Board,the led of RX on the boad blinking and the led of 1000 and DUP are lightening.But i use the signaltap to capture the signals of mac interface,it can be seen that there are no signals on the interface of rx_clk,rx_control and rgmii_in,and the config statemachine can't work correctly as simulation, it keep state of read software reset and can't clear reset bit automatically as the ug said.I am confused how should i do next. I don't know whether it is caused by incorrect constraints on mac ip and rgmii interface or other reason?thankyou! I will attach my sdc content and signaltapii picture below!# ************************************************************ # Create Clock # ************************************************************ create_clock -name {inclk} -period 8.000 [get_ports {inclk}] create_clock -name {rx_clk} -period 8.000 [get_ports {rx_clk}] # ************************************************************ # Create Generated Clock # ************************************************************ derive_pll_clocks set eth_tx_in_clk pll_inst|altpll_component|auto_generated|pll1|clk[0] set eth_tx_out_clk pll_inst|altpll_component|auto_generated|pll1|clk[1]# ************************************************************# Set Input Delay#************************************************************ set_input_delay -clock rx_clk -min 1.5 [get_ports {rgmii_in 

[*] rx_control}] -add_delay set_input_delay -clock rx_clk -max 2.5 [get_ports {rgmii_in 

[*] rx_control}] -add_delay set_input_delay -clock rx_clk -clock_fall -min 1.5 [get_ports {rgmii_in 

[*] rx_control}] -add_delay set_input_delay -clock rx_clk -clock_fall -max 2.5 [get_ports {rgmii_in 

[*] rx_control}] -add_delay#************************************************************# Set Output Delay#************************************************************ set_output_delay -clock $eth_tx_out_clk -max 1 [get_ports {rgmii_out 

[*] tx_control}] set_output_delay -clock $eth_tx_out_clk -min -1 [get_ports {rgmii_out 

[*] tx_control}] -add_delay set_output_delay -clock $eth_tx_out_clk -clock_fall -max 1 [get_ports {rgmii_out 

[*] tx_control}] -add_delay set_output_delay -clock $eth_tx_out_clk -clock_fall -min -1 [get_ports {rgmii_out 

[*] tx_control}] -add_delay#************************************************************# Set Clock Groups#************************************************************ set_clock_groups -exclusive -group [get_clocks {inclk eth_tx_in_clk eth_tx_out_clk}] set_clock_groups -exclusive -group [get_clocks {rx_clk}]# ************************************************************# Set False Path#************************************************************ set_false_path -from [get_ports {mdio}] set_false_path -to [get_ports {mdc mdio}] set_false_path -setup -rise_from $eth_tx_in_clk -fall_to $eth_tx_out_clk set_false_path -setup -fall_from $eth_tx_in_clk -rise_to $eth_tx_out_clk set_false_path -hold -rise_from $eth_tx_in_clk -fall_to $eth_tx_out_clk set_false_path -hold -fall_from $eth_tx_in_clk -rise_to $eth_tx_out_clk# ************************************************************# Set Multicycle Path#************************************************************ set_multicycle_path -from $eth_tx_in_clk -to $eth_tx_out_clk -setup -start 2# ************************************************************# Set Maximum Delay#************************************************************ set_max_delay -from $eth_tx_out_clk -to [get_ports {tx_clk}] 20# ************************************************************# Set Minimum Delay#************************************************************ set_min_delay -from $eth_tx_out_clk -to [get_ports {tx_clk}] 0
0 Kudos
12 Replies
Altera_Forum
Honored Contributor II
438 Views

Usually when the TSE doesn't clear its reset flag, it means that some clocks are missing on the interface with the PHY. Check that the TSE is receiving correct rx and tx clocks on its RGMII interface.

0 Kudos
Altera_Forum
Honored Contributor II
438 Views

thanks for your reply! In fact, I haven't check rx_clk on RGMII interface with signaltapII! Is that means the PHY hasn't config correctly or anything else? 

https://www.alteraforum.com/forum/attachment.php?attachmentid=7122
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

No wait, I'm sorry, I wrote something wrong. 

The clocks that you need to check are the ones on the Avalon Stream interfaces, so on the other side of the TSE. It is those clocks that need to be active for the TSE to reset properly.
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

 

--- Quote Start ---  

No wait, I'm sorry, I wrote something wrong. 

The clocks that you need to check are the ones on the Avalon Stream interfaces, so on the other side of the TSE. It is those clocks that need to be active for the TSE to reset properly. 

--- Quote End ---  

 

sorry!Do you means the check of clocks of ff_tx_clk,ff_rx_clk and clk?These clocks are working correctly,but i don't know how can i make the rx_clk,rx_control and rgmii_in interfaces work correctly?
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

Yes it is those clocks that you need to check. As for the rx signals on the RGMII side, you should see activity on those when the PHY receives a packet. 

Are you using the Altera drivers? Could you show the exact output you get on the console?
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

 

--- Quote Start ---  

Yes it is those clocks that you need to check. As for the rx signals on the RGMII side, you should see activity on those when the PHY receives a packet. 

Are you using the Altera drivers? Could you show the exact output you get on the console? 

--- Quote End ---  

 

sorry,what do you mean the Altera drivers? I have checked the clocks of clk(50mhz),ff_tx_clk(125mhz) and ff_rx_clk(125mhz) which are woring normally! But the mac still can't reset properly.I will show you the signaltapII results in attachments for you.
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

How are you controlling the TSE? Are you using a CPU with some software? And if yes what OS and drivers? 

How can you tell that the TSE isn't resetting properly?
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

 

--- Quote Start ---  

How are you controlling the TSE? Are you using a CPU with some software? And if yes what OS and drivers? 

How can you tell that the TSE isn't resetting properly? 

--- Quote End ---  

 

I just instantiate the mac ip core,and config some register space,then, program the project on my board which use a cable connecting to pc without any software or cpu to control the mac.I write a reset bit 1 to the command register, then read the reset bit,if reset done, it should be bit 0.so i can conclude the TSE reset properly.I don't know how to use the sdc file generated by megawizard to constraint my project properly,so when i read the compilation report in quartusii,the fmax of ff_tx_clk and ff_rx_clk just equal to 111.38mhz witch are 125mhz when input.Could you tell me how to solve this problem?Thank you!
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

I see. If possible I would suggest to use a standard design first, with a Nios CPU and a software template such as the simple socket server. The big advantage is that the driver will ensure the TSE is initialized and configured properly. Once this works, you know the TSE is functioning properly and you can mode you your own hardware design. 

Solving your problem directly is difficult because it is hard to figure out if it is coming from your logic that controls the TSE, or something else. If you are using a development kit there is probably an example design with everything already there, including the timing constraints. Start by running this design, and once it works, remove the Nios CPU, the DMAs, and everything you don't require, and put your own logic instead. 

 

Now to answer your question, IIRC the TSE takes quite some time to reset itself. You should read back the reset bit continously, until you can get a reset done status. In my opinion a bad timing in the project will cause other kind of problems, but not a reset failure. 

The .sdc file generated with the TSE will only constrain some internal timing requirements inside the TSE. Timequest currently doesn't know anything about the frequencies you want to achieve on ff_tx_clk and ff_rx_clk. To define those you need to constrain yourself all the signals on the RGMII interface. Again if you have a development kit with example designs, you should be able to get the correct constraints from there.
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

 

--- Quote Start ---  

I see. If possible I would suggest to use a standard design first, with a Nios CPU and a software template such as the simple socket server. The big advantage is that the driver will ensure the TSE is initialized and configured properly. Once this works, you know the TSE is functioning properly and you can mode you your own hardware design. 

Solving your problem directly is difficult because it is hard to figure out if it is coming from your logic that controls the TSE, or something else. If you are using a development kit there is probably an example design with everything already there, including the timing constraints. Start by running this design, and once it works, remove the Nios CPU, the DMAs, and everything you don't require, and put your own logic instead. 

 

Now to answer your question, IIRC the TSE takes quite some time to reset itself. You should read back the reset bit continously, until you can get a reset done status. In my opinion a bad timing in the project will cause other kind of problems, but not a reset failure. 

The .sdc file generated with the TSE will only constrain some internal timing requirements inside the TSE. Timequest currently doesn't know anything about the frequencies you want to achieve on ff_tx_clk and ff_rx_clk. To define those you need to constrain yourself all the signals on the RGMII interface. Again if you have a development kit with example designs, you should be able to get the correct constraints from there. 

--- Quote End ---  

 

Thanks.Could you show me how to constrain RGMII interface properly?Because i haven't a ethernet demo on my development kit,so i don't know how to constrait the RGMII interface.
0 Kudos
Altera_Forum
Honored Contributor II
438 Views

I don't have any ready .sdc script for that, but in that message (http://www.alteraforum.com/forum/showthread.php?t=26077&p=103956#post103956), I suggested to have a look at the uclinux design example, which was done for the Cyclone III dev board.

0 Kudos
Altera_Forum
Honored Contributor II
438 Views

 

--- Quote Start ---  

I don't have any ready .sdc script for that, but in that message (http://www.alteraforum.com/forum/showthread.php?t=26077&p=103956#post103956), I suggested to have a look at the uclinux design example, which was done for the Cyclone III dev board. 

--- Quote End ---  

 

OK,thank you very much!
0 Kudos
Reply