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

[Altera_Forum]

Hi, 

 I have the dsp development kit, cyclone iii edition (http://www.altera.com/products/devkits/altera/kit-cyc3-dsp.html).   How can I use the Ethernet?   In my altera > 80 > ip Directory I have triple_speed_ethernet. Will that work with this board?   Or will I need additional IP-Cores? Will they also be shipped with my dev. kit?   And are there IP-Cores for USB-Communication?   Kind regards, Stefan__

[Altera_Forum]

Well, so far I can create the NiosII3C120DesignExample. 

 But if the board is OK I wonder why my Triple Speed Ethernet Core in Quartus does not work... Do you have a simple fpga design with TSE that works or do you have only NIOS software?

[Altera_Forum]

I had a simple design on the Nios forum, but not as good as thi one from the wiki. It would work only in gigabit mode. 

But if on your design the PHY doesn't even autonegotiate a speed, the problem must be a simple one, related to signals directly connected to the PHY. Maybe the reset signal, a clock, or one of the MDIO signals. You can try and find the differences between your design and the wiki example in those areas.

[Altera_Forum]

Finally at least the physical connection works with the FPGA. :)  

 I think I owe you to say where the error was:  I connected resetN to an (unassigned) input with default value = VCC. This was obviously wrong. I deleted the input pin and replaced it with primitives > other > vcc and then it worked.

[Altera_Forum]

I was about to suggest to put a proper reset signal generator for the PHY. The Nios example uses one (in global_reset_generator.v) that could serve that purpose. 

The marvel chip is known for having reset issues on the Stratix board (it won't init properly if it didn't have a reset pulse at power up) but as far as I know the Cyclone III board doesn't have the problem. Still it is a good idea to reset properly the PHY at power up, it can't hurt ;)

[Altera_Forum]

--- Quote Start ---  Still it is a good idea to reset properly the PHY at power up, it can't hurt ;)  --- Quote End ---    Yes, I noticed too that it sometimes doesn't work if no reset is done at startup.  To send packets I think that I must prepare three things: 

• clock setup 
• time constraints 
• register settings 

  For clock setup I have:  ff_tx_clk = ff_rx_clk = 25 MHz clk = 125 MHz tx_clk = 125 MHz enet_gtx_clk = 125 MHz + 90°  For Time constraints I use the skript tse_constraints.tcl and Classic Timing Analyzer. (But I still get Critical Warnings).  Register settings I do like following: I want to set TX_ENA (bit 0) and RX_ENA (bit 1) in Command_Config Register which is at Address Offset 0x008, so I do: data <= "00000000000000000000000000000011"; -- (32 Bit) addr <= "00001000"; -- 0x008 write <= '0'; -- this makes a falling edge of write  I think that's not 100% right so maybe you can tell me where I misunderstood something...?  From where do you get information except of the TSE User Guide?

[Altera_Forum]

I suggest reading the avalon specification (http://www.altera.com/literature/manual/mnl_avalon_spec.pdf). 

The write signal is normally '0'. To perform a write, supply the correct vectors to writedata and address, change write to '1', wait until waitrequest is '0', and change write to '0' again (except if you want to write again)

[Altera_Forum]

--- Quote Start ---  ...wait until waitrequest is '0'...  --- Quote End ---   Somehow waitrequest is always 1. I have put read and write to GND but still waitrequest is 1. Maybe it is inverted, but then it would be named waitrequest_n. The register clock (clk) is 25 MHz which I think is OK.

[Altera_Forum]

Did you reset the TSE core before using it?

[Altera_Forum]

--- Quote Start ---  Did you reset the TSE core before using it?  --- Quote End ---    Yes, I resetted TSE as well as the PHY.

[Altera_Forum]

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

[Altera_Forum]

--- 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?

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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?

[Altera_Forum]

--- 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.

[Altera_Forum]

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.

[Altera_Forum]

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?

[Altera_Forum]

No I haven't seen this problem before. If you manually calculate the CRC32 on the received packet, is it ok?

[Altera_Forum]

--- 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...?

[Altera_Forum]

Sorry, I don't see anything wrong. Are you sure the PC is sending valid packets? The contrary would be very unlikely, but I don't see anything else...

[Altera_Forum]

is marvell 88e1111 hardware programmable or software?