I am having difficulty getting the SW_RESET bit 13 of the tse_mac Command Configuration Register to work properly. It does not go from a 1 to a 0 like it should.

[JMira21]

I am using an Arria II GX with an 88E1111 PHY setup in RGMII mode. When I try to do this manually by writing to this register it doesn't work. I tried using the tse_mac_SwReset() API function which appeared to work until I realized after the timeout it restores the original contents of the command config register. When I disable this restore instruction, bit13 SW_RESET is stuck high after calling tse_mac_SwReset() API function.

What is very weird is if I use the Eclipse Debugger and tell it to do address renderings my software works and bit 13 gets cleared. If I don't do the address rendering in the Eclipse debugger, the software doesn't work and bit 13 is read back as a 1 even after some delay of the software reset. I should also note that all data cache has been disabled and we are using IOWR and IORD to access the MAC address apace.

Any help would be appreciated.

Thanks Joe

[Deshi_Intel]

Hi,

Below scenario may affect sw_reset operation as per TSE user guide doc.

• Ensure all existing data transmission and reception is completed before you perform sw_reset
• After sw_reset is asserted high, wait for the software reset sequence to complete before changing any MAC setting (for instance : operating speed and mode (full/half duplex))
• No interruption on the TSE clocking like cable plug/unplug

You can checkout TSE user guide (page 53, figure 18) to learn about some of operation that may interrupt SW_RESET that you need to watchout

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_ethernet.pdf

Anyway, you can always rely on TSE IP hardware reset if software reset is not reliable. Hardware reset is the superset of software reset that will reset everything in TSE IP.

Thanks.

Regards,

dlim

[Deshi_Intel]

Hi Joe,

Thanks for additional feedback but can you use back forum community for future issue update ?

The only explanation that I can think off is stepping through Eclipse debugger gives more time for certain function task execution to complete before proceed to next task.

Based on my earlier feedback, sw_reset got stuck is typically caused by some other operation is interrupting the reset sequence as explained in TSE user guide doc.

• Does any data traffic start to run after you release TSE hardware reset ?
• Can you review you design code on the operation before write and after read sw_reset read via command_config register ?

I presume your design flow is as below.

1. release TSE hardware reset
2. What operation happened here ? can add more delay or pls stop certain operation ?
3. Write to trigger sw_reset
4. What operation happened here ? can add more delay or pls stop certain operation ?
5. Read back sw_reset status

Also, does it work better if you don't use the API and perform access control to command_config register directly ?

Thanks.

Regards,

dlim

[Deshi_Intel]

Hi Joe,

I had not hear back from you for sometime.

Hopefully you managed to get your project going.

For now, I am setting this case to closure.

Thanks.

Regards,

dlim