New ContributorHello!
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!
Regular ContributorHi,
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
New ContributorMy tests showed only partly this result:
Further discussion: https://forums.intel.com/s/question/0D50P00004OQKyLSAX/avalon-interconnect-dynamic-bus-sizing-and-bursts
Regular ContributorHi,
Could you share with me your simulation or SignalTap result?
New ContributorYes, 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.
Super ContributorNew Contributorhm, 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!
Super ContributorOnce 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.
New ContributorThats 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.
Super ContributorIf 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;
New ContributorLook 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.
Super ContributorI 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.
New Contributorwait 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!
Super ContributorThis is your simulation
New ContributorThats 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.
Super ContributorNew Contributorare 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
Super ContributorI 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.
New Contributorare 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
Super ContributorUnfortunately 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.
