Support for Avalon-MM burst transfers by slaweksiluk · Pull Request #364 · VUnit/vunit

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

+  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

+                      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

    write_bus(net, bus_handle, to_address(bus_handle, address), data, byte_enable);
  end;

+  procedure write_bus(signal net : inout network_t;


I think the function should be called burst_write_bus to disambiguate it from the normal write_bus.

kraigher · 2018-11-08T19:22:30Z

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


Maybe just data is enough for this name if the procedure is called burst_write_bus

kraigher · 2018-11-08T19:22:49Z

    read_bus(net, bus_handle, to_address(bus_handle, address), reference);
  end;

+  procedure read_bus(signal net : inout network_t;


burst_read_bus

kraigher · 2018-11-08T19:23:42Z

    read_bus(net, bus_handle, to_address(bus_handle, address), data);
  end;

+  procedure read_bus(signal net : inout network_t;


burst_read_bus

kraigher · 2018-11-08T19:23:59Z

+    await_read_bus_reply(net, bus_handle, burstdata, reference);
+  end procedure;
+
+  procedure read_bus(signal net : inout network_t;


burst_read_bus

kraigher · 2018-11-08T19:24:30Z

+    send(net, bus_handle.p_actor, request_msg);
+  end procedure;
+
+  procedure read_bus(signal net : inout network_t;


burst_read_bus

kraigher · 2018-11-08T19:24:59Z

+  -- deallocation of burstdata queue. Procedure cunsumes burst_length data words
+  -- from burstdata queue. If burstdata queue has less data words, all data
+  -- words are consumed and pop from empty queue error is raised.
+  procedure write_bus(signal net : inout network_t;


burst_write_bus, also maybe burst_data can just be named data.

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

@slaweksiluk I just pushed a commit to master which moves the verification components to a separate build. Hopefully it will make it more robust.

kraigher · 2018-11-15T08:59:20Z

I think this is ready to merge except for the names I commented on, what do you think about the names @slaweksiluk. Is it not more clear to have different names for burst read and normal read or do you have a different opinion?

slaweksiluk · 2018-11-15T12:59:58Z

I had doubts about it and decided to use the same names as in non-burst transfers. It is impossible to confuse burst and non burst transfers as they have different interfaces. On the other side having the same names has no clear advantages. Its up to you, I can implement burst_read/write_bus naming if needed.

kraigher · 2018-11-15T13:01:31Z

I prefer having different names to make the behavioral difference more obvious when reading the code.

slaweksiluk · 2018-11-30T15:08:52Z

@kraigher I've updated names

kraigher requested changes Aug 2, 2018

View reviewed changes

kraigher requested changes Aug 4, 2018

View reviewed changes

slaweksiluk force-pushed the master branch from cc4e822 to 49fd65c Compare September 19, 2018 10:21

slaweksiluk force-pushed the master branch from 49fd65c to 2c4a4e4 Compare October 4, 2018 10:13

slaweksiluk force-pushed the master branch from 2c4a4e4 to 5252571 Compare October 24, 2018 11:08

slaweksiluk force-pushed the master branch from 5252571 to a71f34c Compare November 8, 2018 07:31

kraigher reviewed Nov 8, 2018

View reviewed changes

slaweksiluk force-pushed the master branch from a71f34c to 66c11c8 Compare November 8, 2018 21:46

slaweksiluk added 5 commits November 29, 2018 16:33

Support for Avalon-MM burst transfers

355631f

Rename burstsize -> burst_length

09185ef

Add comments regarding queue ownership for burst bus transfers

fbcb2bf

Support for wait until idle command in Avalon Master

9c0658f

Change burst subprograms names

166bf13

slaweksiluk force-pushed the master branch from 66c11c8 to 166bf13 Compare November 29, 2018 15:57

kraigher merged commit 7e90f4f into VUnit:master Nov 30, 2018

Conversation

slaweksiluk commented Aug 1, 2018

Master

Slave

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slaweksiluk commented Sep 19, 2018

Uh oh!

slaweksiluk commented Oct 9, 2018

Uh oh!

kraigher commented Oct 9, 2018

Uh oh!

slaweksiluk commented Oct 24, 2018

Uh oh!

kraigher commented Oct 24, 2018

Uh oh!

Aaron-Hartwig commented Nov 6, 2018

Uh oh!

kraigher commented Nov 8, 2018

Uh oh!

slaweksiluk commented Nov 8, 2018

Uh oh!

kraigher commented Nov 8, 2018

Uh oh!

kraigher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kraigher commented Nov 8, 2018

Uh oh!

kraigher commented Nov 15, 2018

Uh oh!

slaweksiluk commented Nov 15, 2018

Uh oh!

kraigher commented Nov 15, 2018

Uh oh!

slaweksiluk commented Nov 30, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects