Avalon bus with 2 Avalon_MM_ Slaves fails to work (works fine with 1...)

[Altera_Forum]

Hi All, 

  I have designed an Avalon bus with 1 Master and 1 Slave, it works greate. I can do write and read just fine. OK, so I added another  Master and another Slave, the first Slave at base address 0x000000C0 and the second Slave at base address 0x00000100.  Now, the first Slave responds with chipselect for both addresses while the second Slave does not at all - no chip-select, no write or read signals ! (on the user side I use exactly the same "user_if_module").  I tried different address ranges, no help. QSYS compiles fine, no errors or warnings. Modelsim elaborates fine.  It looks to me like a QSYS address decoding bug.  Any Ideas?  Thanks, S.

[Altera_Forum]

I would avoid using chipselect for starters. This is from the spec, pay extra attention to the last sentence: 

 "When present, a slave port ignores all Avalon-MM signals unless chipselect is asserted. chipselect must be used in combination with read or write. The chipselect signal is not necessary; Altera does not recommend using it."  Have you simulated your system to see what is happening at the fabric level? That's typically where I start when debugging issues that resemble this.

[Altera_Forum]

Yes, of course I simulated the dual Slaves with two sets of user signals including the chipselect signal. In all cases only the lower addresses Slave responded with with a chipselect. The purpose of a chipselect is to qualify the Write and Read signals. The statement you are quoting is contradictory in nature, isn't it? 

If you have 2 instances of the Slave mapped to diferent address ranges I would expect all associated control signals and in particular the chipselect to respond ONLY to accesses made in these addresses.  There is deffinitly a bug here ! Or else, you have to use only 1 Slave and qualify all its signals with external address decodes if you want to use several Slaves.  Thanks, Shvitzer

[Altera_Forum]

The reason why chip select is not recommended is because the fabric already generates qualified read and write signals. It generates a chip select by performing a logical OR of those signals to generate the chip select line. So if you use that to qualify the read and write signals at the slave side it's redundant. Most users omit the chip select of the slave port and use read and write directly and that's Altera's recommendation in the specification. Qsys is not generating a shared bus interconnect, it's a partial crossbar implemented as a NoC. So transactions flow through the fabric and can only arrive at one end point (slave), the only way multiple slaves can be issued transactions at the same time is if there are multiple masters issuing the transactions in the system. That quote from the spec is stating if you include a chip select port then you *must* include read/write ports as well. The second part is saying chipselect is optional and not recommended because the fabric doesn't issue non-qualified transactions to slaves anyway. 

 I didn't follow the bug, but someone was showing me an issue around a year ago with the chip select polarity in a system. I told them remove the chip select since it makes no sense to use with an Avalon slave in Qsys and the problem went away. I have also seen people try to include a chip select port on their Avalon master interfaces, I have no clue what will happen in those cases but if you are doing that I highly recommend removing it.