Ethernet with DSP Dev. Kit Cyclone III (no NIOS)

I really can't see any other reason than problems on the clock or reset...

Did you see that reset is active high this time? You need to put it to 1 to reset the core, and then to 0 to use it.

Are you waiting long enough? I just had a look at the test bench, and it waits 1000 ns after the reset before doing anything. If you attempt write just after the reset, the TSE core could take a long time to respond, while it is accomplishing the reset.

Oh no wait, I just remember another problem I ran into. The address register map in the datasheet is misleading when you use the TSE core outside of a NIOS processor. It is giving the addresses as seen by a CPU in an 8-bit space, but the hardware address bus selects a register in the 32-bit space. This means that when you address the component yourself, you need to divide the address by four. i.e. supply "00000010" on the address bus to access the config register.

You were in fact trying to write to the rx_section_full register, which could block the component if no valid clock is present on the ff_rx_clk signal.

This problem kept me stuck for a long time ;)

Hope this helps

--- Quote Start ---

This means that when you address the component yourself, you need to divide the address by four. i.e. supply "00000010" on the address bus to access the config register.

--- Quote End ---

OK, thank you. I didn't know this.

So until now the following things work:

• Physical ethernet connection (LEDs are on)

• Programming of the TSE Register (command_config)

• Time constraints (I included the default tse_constraints.sdc, but I did nothing with timequest)

• tx_clk,rx_clk: 125 MHz without phase shift

Now I am trying to send packets but I cannot see them in wireshark (http://www.wireshark.org/). Maybe the problem is that I do not know which is the right preamble to use in the ethernet frame. I couldn't find it in the TSE Guide. With SignalTap I have seen that rgmii_out and tr_control (enet_tx_en) is always low (0). I already checked that it is not because of the OpenCore Plus Hardware Evaluation of the TSE.

When I try to send packets, the TX LED is flashing, but I can't see the packets in wireshark. My packet is more than 42 Byte long, so it is not too short. I still wonder why waitrequest is always high (1). Maybe it is low active...

Should the write enable Signal be asserted when the packet starts or when the preamble starts?

You don't send the preamble or SFD to the TSE, it will add it automatically. You just send the Ethernet frame, starting with its header. Depending on the configuration, you may also have to add the 16-bits padding in front of the header if you enabled the option "Align packet headers to 32-bit boundaries".

You can have a look at the offload example on the Nios Wiki, they format some frames for the TSE.

waitrequest shouldn't be high when you are writitg or reading. If it still is, then you have a problem.

if the packet doesn't show in Wireshark it could be because it is badly formatted. Bad packets can be discarded by the Ethernet driver on the PC. Some drivers have options to disable this output.

--- Quote Start ---

waitrequest shouldn't be high when you are writitg or reading. If it still is, then you have a problem.

--- Quote End ---

I think the reason why I do not see the packets in wireshark is the problem with the waitrequest signal. When I program the device, the OpenCore Plus Status message displays:

Time remaining: unlimited

This takes me aback, I thought I could use it only for one hour without license. What did it display in your design?

I have put ff_rx_rdy, read, write, set and reset to GND. Then I opened Timequest (which I use for timing analysis) and generated a SDC file from QSF for my project. In my project I included myproject_top.sdc and tse_constraints.sdc. For Tcl Script File I use tse_constraints.tcl, which I did not modify. The clock signals are defintely not stuck and reset is only asserted once on startup.

On the pin assignment I have altera_reserved_tck, altera_reserved_tdi, altera_reserved_tdo and altera_reserved_tms which I can't assign to the pins according to the datasheet.

Normally I can see every packet in wireshark, no matter how badly formatted it is. Once I used a windows-program to send a packet consisting of some random bytes and wireshark captured it. So I think wireshark is not the problem.

In the avalon specification it says:

An Avalon-MM slave may assert waitrequest during idle cycles.

Maybe the TSE is in a idle cycle for any reason.

I have the same OpenCore plus window, but it is very important that you don't close the alert window with that message and the "cancel" button. If you do that, it will disable the TSE until you configure the FPGA.

If you are reading or writing, then you aren't in an idle cycle.

Could you show a Signaltap acquisition of the signals on the avalon interfaces when you attempt to write to the TSE, and when you send a packet?

Does your design meet timing requirements? No critical warnings from Timequest?

--- Quote Start ---

Does your design meet timing requirements? No critical warnings from Timequest?

--- Quote End ---

There were critical warnings. But then I removed them somehow with TimeQuest.

I can see two problems:

Register access: you release the write signal too soon. Try to keep it to 1 and see if waitrequest is released after a while. You should only release write when waitrequest is at 0.

Packet send: the sop is never seen by the TSE because you release it before the rising edge of the clock. More generally the data is changing faster than the clock so I think that you are not generating the packet with the same clock than ff_tx_clk.

Hi Daixiwen,

Now it works: I can transmit frames from the FPGA-Board to the PC and see them in wireshark. :)

But in the other direction I have problems with CRC32. Every frame that I receive on the FPGA-Board has a CRC32 Error. Do you know this problem?

--- Quote Start ---

If you manually calculate the CRC32 on the received packet, is it ok?

--- Quote End ---

I think yes. The TripleSpeedEthernet receives every frame with a CRC32-Error. So I think there is a general problem in the configuration.

In command_config I have set the following bits:

• TX_ENA

• RX_ENA

• ETH_SPEED

• PROMIS_EN

That was all what I did for configuration. Maybe it is not enough...?