Bug in tri_state_bridge implementation?

[Altera_Forum]

Hello everybody, 

 It seems to me than I stumble on a bug in tri_state_bridge in Quartus v9.0:  A simple master is connected to 16-bit SRAM through the tri_state_bridge. Only write bursts are done by this master, burstcount is always = 3. Although linewrapBursts and burstOnBurstBoundariesOnly are disabled (false), the first 32 word (0xFFFF FFFF) is overwritten by the third word (0x53) because the SRAM address "a" is not linearly incremented between write of second and third 32-bit word (sample 13 in timing diagramm). The timing diagram recorded with Signal Tap is attached - the 4 bottom signals are SRAM connections.  Any ideas how to solve this problem?  Best regards,  fpga-dev

[Altera_Forum]

I don't think the 3-state brigde supports burst-mode. 

In burst mode the master set the address and the burstcount just once and the slave is supposed to increase the internal address every access.  -- Ton

[Altera_Forum]

Hello Ton, 

 The tri_state_bridge definitely supports burst accesses.  I've solved my problem by increasing width (N) of burstcount signal vector from 2 to 3 bits. The supported burst length is 2^(N-1) max. as defined in Avalon bus documentation.  regards,  fpga-dev

[Altera_Forum]

It's good to hear you solved your problem. 

And now I know that the 3-state bridge supports burst-mode. That's the nice thing about this forum. You can learn from it every day.  Good luck, Ton

[Altera_Forum]

Bursts are part of the generic Avalon memory-mapped spec but are not officially part of the Avalon MM tri-state slave specification. 

 I can't see a reason why it wouldn't work but remember that it's technically not in the spec.