Support for Avalon-MM burst transfers #364

slaweksiluk · 2018-08-01T13:55:52Z

Master

For support for burst transfers current bus_master had to be extended and some way of passing multiple data words had to be chosen. I decided to use VUnit queues as it seems the most natural for me. Please comment if somebody see the better options. Currently data words from queue are pushed to bus burst msg, however it is also possible to push queue reference instead of single data chunks.

In bursts transactions byteenable signals is always high - probably need to extend it.

Slave

Avalon Slave was rewritten - write and read handling is separated. New implementation does not prevent simultaneous write and read .The another event which should be forbidden is mixed write/read bursts. In general bus monitor should be added to capture and report such a invalid transactions.

kraigher · 2018-08-02T17:09:13Z

vunit/vhdl/verification_components/src/bus_master_pkg.vhd

+  procedure write_bus(signal net : inout network_t;
+                      constant bus_handle : bus_master_t;
+                      constant address : std_logic_vector;
+                      constant burstsize : positive;


At least in AXI terminology it would be called burst length and not burst size.

In Avalon it is burstcount. The another option is simple "burst". However, for me, "burstlength" sounds good.

I think we should either keep Avalon naming or use our current naming conventions all the way with underscore separators. burstlength would be something in between.

Queues are very explicit about data order but not explicit about what data types that it accepts. I'm on my mobile and haven't looked at the code carefully but I think an integer queue is assumed. A user may find it more natural to represent the data as a vector. Or create the burst out of order. Maybe we should list some pros cons when comparing with integer_array_t.

So lets stay at 'burst_length'?

Currently std_logic_vector queue is assumed. Is it possible to restrict queue to accept only single type? What do you mean by out of order burst?

Using some array type is another option. I think the little disadvantage is the user would have to allocate array type with some fixed size. Does std logic vector array type exist in vunit?

Yet another option is to give up using special types for input burst data and split it in command and payload phases:
write_burst(address, burst_length);
write_burst(data0);
write_burst(data1);
...
However this kind of interface is a little bit harder to implement internally. Also need to check if user doest not violate burst transfer rules, for example by reading bus before writing last data word to the bus.

I think the queue is fine for now. There is nothing stopping other data-types from being supported in the future if the message format consists of the data by value.

Ok so it seems no more activity here. I will change to burst_length.

Ok burst_length is a good name

kraigher · 2018-08-04T17:29:13Z

vunit/vhdl/verification_components/src/bus_master_pkg.vhd

+                      constant bus_handle : bus_master_t;
+                      constant address : std_logic_vector;
+                      constant burstsize : positive;
+                      constant burstdata : queue_t);


This comment is valid for all functions added. The ownership of the queues should be documented in the API. For example is ownership of the queue transferred into the function?, does the queue need to be deallocated afterwards?, is the queue consumed by the function?
This is important for the user to know.

Yes, it need to be documented. I assumed that queue is allocated in tb main which is responsible for its deallocation. In that case single queue could be shared by multiple reads/writes in different verification components instantiations.

Is it enough to document queue API in vhdl package code or also in general vunit doc?

It is enough to document it in a comment above the function in the package header.

Note: For many VUnit packages we have separated the package header from the package body to include the package header in verbatim on the webpage as a simple form of API documentation lacking any better autodoc for VHDL like there is for Python.

slaweksiluk · 2018-09-19T13:35:01Z

Failed Travis build seems not related to this pull request

slaweksiluk · 2018-10-09T15:47:09Z

@kraigher do you have idea what happened to travis now?

kraigher · 2018-10-09T15:50:41Z

@slaweksiluk Looks like an environment error. I restarted the build manually.

slaweksiluk · 2018-10-24T11:41:59Z

@kraigher I have not idea how to fix it

vunit/test/acceptance/test_external_run_scripts.py::TestExternalRunScripts::test_verification_components_vhdl_2008 

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated

kraigher · 2018-10-24T15:02:43Z

It is an environment problem and not your fault. We are working on it.

Aaron-Hartwig · 2018-11-06T18:25:46Z

Is this PR still being worked on? @kraigher @slaweksiluk

kraigher · 2018-11-08T04:04:45Z

The PR needs to be rebased and the CI checks must pass. Then it is probably ready to merge after a review.

slaweksiluk · 2018-11-08T10:05:46Z

Still time-out on travis

kraigher · 2018-11-08T11:03:36Z

Are the new test you added long running tests? Travis has a timeout for builds. Maybe we need to start splitting the running of all run.py files into several builds.

kraigher

I am almost ready to merge this I just have a few comments regarding the naming.

kraigher · 2018-11-08T19:21:28Z