FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6659 Discussions

Avalon Interconnect Dynamic Bus Sizing and Bursts

sadad
Novice
5 757 Visites

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!

 

 

 

0 Compliments
26 Réponses
JohnT_Intel
Employé
4 165 Visites

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

0 Compliments
BInos
Débutant
4 165 Visites
0 Compliments
JohnT_Intel
Employé
4 165 Visites

Hi,

 

Could you share with me your simulation or SignalTap result?

0 Compliments
sadad
Novice
4 165 Visites

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:

avalon_32to8bit_bursts.png

 

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

 

 

 

 

 

0 Compliments
KennyTan_Altera
Modérateur
4 165 Visites
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".
0 Compliments
BInos
Débutant
4 165 Visites

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!

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

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.

0 Compliments
BInos
Débutant
4 166 Visites

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.

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

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;

0 Compliments
BInos
Débutant
4 166 Visites

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.

 

 

 

 

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

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.

0 Compliments
BInos
Débutant
4 166 Visites

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!

 

 

Unbenannt.JPG

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

This is your simulation

0 Compliments
BInos
Débutant
4 166 Visites

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.

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites
It will take me some time to rewrite the testbench. Not sure if you can wait for this?
0 Compliments
BInos
Débutant
4 166 Visites

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

 

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

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.

0 Compliments
BInos
Débutant
4 166 Visites

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

 

 

0 Compliments
KennyTan_Altera
Modérateur
4 166 Visites

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.

0 Compliments
KennyTan_Altera
Modérateur
4 089 Visites

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.

0 Compliments
Répondre