Avalon Interconnect Dynamic Bus Sizing and Bursts

[sadad]

Hello!

My Avalon-MM master has 32bit data width and is bursting capable.

Now i connect an Avalon-MM slave with 8bit data width which is also bursting capable.

Will a 32bit read or write access to the slave cause the automatically generated Avalon adapter to translate the 1x32bit access to a single burst of 4 x 8bit?

Or will there be 4 non bursting transfers of 8bit?

Thanks in Advance!

[JohnT_Intel]

Hi,

Yes, the Avalon adapter will performed a single burst of 4 x 8bit since the slave is able to support. A non 4 non bursting transfer 8bit will only happen when the slave is not able to support it

[BInos]

My tests showed only partly this result:

Further discussion: https://forums.intel.com/s/question/0D50P00004OQKyLSAX/avalon-interconnect-dynamic-bus-sizing-and-bursts

[JohnT_Intel]

Hi,

Could you share with me your simulation or SignalTap result?

[sadad]

Yes, it is based on the avalon verification demo testbenches: "avlmm_1x1_vhdl"

Open the qsys design hit "generate HDL" => make sure "Generate Simulation Model" is set to "VHDL".

=>

cd avlmm_1x1_vhdl

vsim -do run_simulation.tcl

=>

the simulation will output bfm errors like:

"WARNING: tb.dut.slave_0.mm_slave_vhdl_wrapper.<protected>: Pipelined read commands 2 > AV_MAX_PENDING_READS 1"

caused by the missing testbench implementation to control the slave bfm responses to master read requests. 

This can be ignored for the proof of concept. The bustcount for read requests should be 4 even before the error happens.

See attached image:

Write Request seems ok, but Read Request shows only burstcount of 1.

[Kenny_Tan]

Is there any steps that I am missing? I am getting error: # ** Error: (vcom-11) Could not find master_0.altera_avalon_mm_master_bfm_vhdl_pkg. # ** Error (suppressible): test_program_pkg.vhd(8): (vcom-1195) Cannot find expanded name "master_0.altera_avalon_mm_master_bfm_vhdl_pkg". # ** Error: test_program_pkg.vhd(8): Unknown expanded name. # ** Error: (vcom-11) Could not find slave_0.altera_avalon_mm_slave_bfm_vhdl_pkg. # ** Error (suppressible): test_program_pkg.vhd(11): (vcom-1195) Cannot find expanded name "slave_0.altera_avalon_mm_slave_bfm_vhdl_pkg".

[BInos]

hm, must be something on your side, retested my steps without errors.

Did you make sure that:

"Open the qsys design hit "generate HDL" => make sure "Generate Simulation Model" is set to "VHDL"."

NONE would be wrong!

[Kenny_Tan]

Once set to VHDL, I can see the simulation already. Did you make changes to the parameter to the slave? As I remember correctly, this design example uses number of symbols 4 and burst count with 1 on the slave side.

[BInos]

Thats the point of my tb:

Test access from 32bit (symbolcount 4) mm master to bursting capable 8bit (symbolcount 1) mm slave.

And see if the Avalon Bus Adapter will issue 4x8bit read/write bursts.

[Kenny_Tan]

If you make changes to to symbols from 4 to 1, you will need to understand how does the testbench written and rewrite the testbench.

Currently, the design example testbench is cater for symbols 4 in test_pgm_pkg.

  constant SYMBOL_W          : integer := 8;

  constant NUM_SYMBOLS        : integer := 4;

[BInos]

Look at the testbench, it is not the same code...

It has nothing to do with the original tb, except DUT instantiation.

Changing tb constants like SYMBOL_W   or NUM_SYMBOLS will not work because the testbench assumes the same symbolcount for master and slave.

My testbench only issues single reads and writes! No fancy random latency bursts non bursts random waitstates, transaction queues, ...

It is used to check if the creation of 4x 8bit bursts works and not more ....

And as result i saw correct burst writes but non bursting reads.

[Kenny_Tan]

I make a comparison of the original waveform from the design example vs the modified version of your testbench.

Few things that i can observe is that, you read signal does not goes down, there should be a wait request goes down and the readdatavalid go up inorder to see the value.

Attached the screenshot.

[BInos]

wait request, readdatavalid has nothing to do with my issue at this point.

my issue starts at the beginning of an read transfer.

I marked the start of the write/read transactions:

The rising edge of the read/write signal begins the burst. At this point the burstcount must already be correct!

So the burstcount signal is wrong (should be 4) even before any of the wait request, readdatavalid signal come into play!

[Kenny_Tan]

This is your simulation

[BInos]

Thats not the output of my testbench. Using Quartus 17.1 or 18.1.

Your result shows a burstcount of 1 during write transaction. Mine shows correct burstcount of 4 when writing.

Did you change some settings? I redownloaded my archive again from this thread and revalidated and confirmed my results.

[Kenny_Tan]

It will take me some time to rewrite the testbench. Not sure if you can wait for this?

[BInos]

are you the creator of this testbench?

yes it would be fine.

But my main goal is not an fully automated testbench which tests latencies / cornercases.

My main goal is to get burst read transfers working when adapting from 32bit to 8bit avalon.

Or do i have to try it out without bfms in real hardware

[Kenny_Tan]

I look into the testbench again, why does your burst count in the slave showing 1 to 4 but your input of your master only shows 1? Did you manually write to the avs signal?

I imagine if your slave is a ram, your burst count cannot be control in the slave side avs. It should be only be control in the master avm but in your case, it is limited to 1 bit.

[BInos]

are you the creator of this testbench?

because i have a 32bit datawidth avs master bfm and a 8bit datawidth slave bfm

=> the avalon interconnect will insert an width adapter.

this adapter should convert one 32bit transaction to one 8 bit burst transaction with bustcount 4.

=> the master avs does not need to be bursting capable.

=> the slave avs must be bursting capable (as in my qsys design)

PS: this forum software sucks

[Kenny_Tan]

Unfortunately I am not the creator of this testbench. And it will be hard for the modification as it will take efforts on this.

I have another design that demonstrate different width work but it is different than your design. This design uses on chip ram as the slave. It successfully accept the burst when the width data is narrower at the slave side, the read is correct as well.

You can take a look on this,

What you need to do is to follow the steps below:

cd to directory ... /altera_avalon_bfm_master/hdl/avalon_bfm_master/scripts/qsys_system/simulation/mentor/

1) source msim_setup.tcl

2) com

3) vlog -sv qsys_system_tb.sv -L altera_common_sv_packages

4) elab +nowarnTFMPC

5) do qsys_system_tb.do

6) run -a

Look into the test_number 4 in the modelsim simulation, you will find it it is working.

Attached the screenshot as well as the zip files.

[Kenny_Tan]

I forgot to mention I did not pull in the ram module in the simulation, you will have to add it to the *.do file before run -a. Here is the screenshot, the current test is the readata is 16bits while the write data at the master is 32bits.