Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12606 Discussions

Avalon Master/Slave Interface Problem

Altera_Forum
Honored Contributor II
1,002 Views

I have created an Avalon Master Writer and an Avalon Slave Writer in Verilog. I believe I am properly adhering to the timing diagrams described in the Avalon Bus Specification for both modules. Both modules use a 16-bit wide data interface. 

 

I am able to debug the interface signals using a logic analyzer with my hardware. I can see the Master address and data signals as well as the Slave address, data, chipselect, and write signals. Up to this point, I have observed the Master's address and data to be functioning properly. I have also observed the Slave's chipselect, write, and address signals to be functioning properly. However, the data signals on the Slave side are not changing or matching the Master's data signals. All the data signals are being pulled low. I changed my debug signals to make sure that there are no errors with my logic analyzer or how I am bringing the data signals out the scope; no problems there. 

 

it seems as if the Master Data signals are not even connected to the Slave Data signals. 

 

Anybody else have any issues relating to Avalon Slaves not being able to receive data from a Master? 

 

thanks, 

Joe
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
265 Views

The issue was that my Avalon Master module was set to "Big Endian" when I configured my system in SOPC builder. The Slave module, by default, is configured to be "Little Endian". Therefore, the data that I was passing from Master to Slave was flip-flopped, this was the source of my problem. 

 

After reading the Avalon spec, it was my understanding that even if one module was Big Endian and another was Little Endian, that Avalon would take care of the Endianness and make sure that data was transferred accordingly. This assumption, however, was incorrect.  

 

Please beware of this.
0 Kudos
Reply