Closed LarsAsplund closed 9 years ago
kraigher
commented
9 years ago | As a | I want | so that |
|---|---|---|
| testbench developer | The mechanism to be fast. | So that I can use it without paying a large runtime cost. |
| testbench developer | The mechanism to be easy to debug | So that I can debug my complicated testbench using much message passing. |
| testbench developer | One sender can broadcast information to many receivers | So that more receivers can be added without affecting the sender. |
LarsAsplund
commented
9 years ago Have we already covered the basic user stories? Maybe, from a software point of view we are already covering many of the common communication patterns:
Are there more such patterns that have VHDL relevance?
Anyway, here is another user story
| As a | I want | so that |
|---|---|---|
| testbench developer | the ability to set timeouts when waiting for information | I can have both event-driven and polling processes and everything in between. |
LarsAsplund
commented
9 years ago Maybe it's time to start setting some of the vocabulary. Based on the user stories above I suggest the following
Client, server, publisher, and subscribers are examples of actors/senders/receivers. Commands, transactions, requests, responses, replies etc are all examples of messages.
LarsAsplund
commented
9 years ago | As a | I want | so that |
|---|---|---|
| testbench developer | all actors to have a unique identifier | I can address other actors directly without having any other knowledge. |
| testbench developer | actors to be able to respond to incoming messages without a priori knowledge of the sender | I can implement patterns like client/server. |
LarsAsplund
commented
9 years ago Looking at some random code from opencores it seems like the most common communication pattern is the "trigger" pattern, i.e. trigger <= true; together with wait until trigger;. This is often used because it's all that's needed and sometimes used because better mechanisms are missing. A more advanced communication mechanism may be overkill for the simple trigger but it maybe interesting for triggers spanning over multiple files/components such that more routing is required. Anyway, I add that user story for the sake of completeness.
| As a | I want | so that |
|---|---|---|
| testbench developer | some actors to publish triggers | other actors can synchronize their actions with the publishers. |
barri
commented
9 years ago I see that you have touched upon most of the general needs. The collected mechanisms/patterns should probably cover the common cases. I don't have anything specific to add at the moment on the topic of mechanisms/patterns. One of the strengths of the "trigger" pattern is the low amount of code needed to use it, so a similarly simple mechanism in VUnit should require less or the same amount of code to use. Which leads me to the following user stories. They are somewhat similar but I feel that they both should be mentioned.
| As a | I want | so that |
|---|---|---|
| testbench developer | minimal boilerplate | I can focus on the functionality of the test. |
| testbench developer | good defaults | I don't have to tinker with details unless needed. |
Keep up the good work!
tomasnilefrost
commented
9 years ago | As a | I want | so that |
|---|---|---|
| testbench developer | encoding/decoding methods for common data types (such as enums) | reinventing encoding of common types in every testbench is avoided |
LarsAsplund
commented
9 years ago Now that we have user stories from four people and a number of involved "objects" (sender, messenger, ...) I think we can take the next step. I'm suggesting that we start refining the user stories by talking about the activities that these objects are involved in. An activity can be expressed like this:
result_of_activity = the_activity(inputs_to_the_activity)
For example
send_status = send(receiver, message)
The functional format of the activity is not intended to suggest that all activities are implemented as functions. They can for example be implemented with signal assignments or even declarations made at compile time. The implementation as still TBD.
Activities will focus on functional aspects, the non-functional aspects like performance will have to be address when we decide how the activities are implemented. Let's also start with the main successful scenarios. The error cases are more easily added when we have those in place.
I will suggest a few activities later today but let me start with an example.
The messenger will have to be aware of the involved actors and each actor will need an identifier to be uniquely addressed in communication. So each actor can perform this activity with the messenger:
actor_identifier = create_actor()
However, if other actors are to communicate with this one based on a priori knowledge of its existance the user must be in control of the identifier
create_actor(actor_identifier)
This would work but since the most convenient identifier from a user perspective is a name (at least I think so) which most often isn't a convenient format for a messenger I suggest
actor_identifier = create_actor(actor_name)
With two representations of the same thing we would need ways convert between the two
actor_identifier = get_identifier(actor_name)
actor_name = get_name(actor_identifier)
kraigher
commented
9 years ago It would be good to be able to create an unique actor without supplying a name for cases when the name is irrelevant such as a master that only sends messages.
kraigher
commented
9 years ago Some thoughts on the API as pseudo-vhdl:
-- send message to receiver, non-blocking and does not wait for receiver to get message
message_status := send(self, receiver, message);
-- block until receiver has consumed message (optional)
wait_until_received(message_status);
-- block until incoming message queue is non-empty
wait_for_messages(self);
-- Handle message queue
while has_messages(self) loop
message := pop_message(self);
-- message.sender is the identifier of the sender, can be used to send a reply
-- message.data is the sent data
end loop;@kraigher Agree with your first post. I can embedded that variant in one of the upcoming activity sequences. Also agree with the second post, I had a message = receive(self, timeout) activity in mind but that doesn't imply that there must be a subprogram of the same format in the final implementation. In fact, we will probably end up having partly overlapping functionality of different granularity.
The wait_until_received call may actually deserve its own user story. Asynchronous message passing, "partly synchronous" message passing as in your example, and fully synchronous message passing where you block until a reply is received should be supported.
LarsAsplund
commented
9 years ago Here comes a number of scenarios expressed with activities. I've excluded the messenger for clarity since it's more or less involved in every activity. The activity names are a bit verbose but we can work on that in the implementation phase.
| Client | Server |
|---|---|
client_identifier = create_actor(client_name) |
server_identifier = create_actor(server_name) |
server_identifier = get_identifier(server_name) |
|
send(client_identifier, server_identifier, request_message_payload) |
|
request_message = receive(timeout) |
|
send(server_identifier, get_sender(request_message), reply_to(get_payload(request_message)) |
|
reply_message = receive(timeout) |
The receive activity will block until a message arrives or it times out. Since I'm focusing on the main successful scenarios I'm assuming that timeout is sufficiently high and isn't triggered.
reply_to is a server specific activity that creates the reply message payload and it has nothing to do with the communication mechanism
The sendand receive activities on the client side can be combined into a single activity to provide native support for synchronous message passing. Something like
reply_message = sync_send(client_identifier, server_identifier, request_message_payload, timeout)
| Sender | Receiver |
|---|---|
sender_identifier = create_actor() |
receiver_identifier = create_actor(receiver_name) |
receiver_identifier := get_identifier(receiver_name) |
|
send(sender_identifier, receiver_identifier, message_payload) |
|
message = receive(timeout) |
The difference in this example is that the create_actor() activity doesn't take an input name. This is a valid approach when no messages or only replies are sent to the sender.
| Publisher | Subscriber |
|---|---|
publisher_identifier = create_actor(publisher_name) |
subscriber_identifier = create_actor() |
publisher_identifier := get_identifier(publisher_name) |
|
subscribe(subscriber_identifier, publisher_identifier) |
|
publish(publisher_identifier, message_payload) |
|
message = receive(timeout) |
Does these activities cover the more functional aspects of our user stories? I think we'll have to take the non-functional parts when activities become real implementations. If these activities are good we can start defining our test cases (just the names) in a VUnit testbench. It should also be possible to define test cases for most of the error cases. Go/no go?
LarsAsplund
commented
9 years ago Added a communication-develop branch with empty files and an initial testbench with two defined test cases (create/destroy actor).
kraigher
commented
9 years ago @LarsAsplund One though I have is that we do not have a mechanism for synchronizing client creation. When sending to a client the client must first be created. If all processes do this in the first delta cycle some will run before others.
kraigher
commented
9 years ago @LarsAsplund I just pushed a message_passing branch with an initial implementation of the basic concept.
LarsAsplund
commented
9 years ago @kraigher Yes we'll have to think about the use cases for actor creation. I guess that the most common use case is that everyone starts with create and then do get_identifier of others at time 0. We should handle this case without special measures from the user. This means that get_identifier will have to wait for new actors to be added. If it still can't find the other actor after resolution time there is an error. Would a timeout with that default be the solution?
I'll have a look at your branch when I get back home.
kraigher
commented
9 years ago @LarsAsplund One idea I got on the actor creation synchronization was to create an actor as soon as it is mentioned by anyone even before someone did 'create_actor'. Such an handle could be marked as non-owning and would not be allowed to perform the same actions as a owning handle such as sending messages as it. One potential error case that would go undetected is when an incorrect handle is created and messages sent there never go anywhere.
LarsAsplund
commented
9 years ago @kraigher I had a look at your code and it's almost identical in principles to the prototype that was the basis for my presentation in Norway. The only difference, naming excluded, is that I bundled the subprograms you have for message reception into one receive procedure but I have no strong opinion there. Once we have the test cases i place we will know how much we have to split that functionality. I have also looked at the publish/subscribe pattern and encoding/decoding from custom data types to string but all those things are pretty straight-forward once the foundation is set. Let's start with the test cases for actor create/destroy and then lift in functionality from the prototypes.
Your idea for actor creation is interesting. I have to think about the various error cases that we can have but the suggested idea would result in a more tightly coupled design which may cause some problems. Maybe some prototyping would make the pros and cons a bit more clear.
kraigher
commented
9 years ago @LarsAsplund What makes you think it will be more tightly coupled?
LarsAsplund
commented
9 years ago I think we should go for the deferred creation of actors since that makes the life of the user easier as long as he/she doesn't make mistakes. We can do a number of things to help the user avoid mistakes:
LarsAsplund
commented
9 years ago I've started to add test cases and implementation for creating, destroying, and finding actors. Deferred creation is included. Have a look at the communication-develop branch.
I will now start with test cases for the client/server communication test pattern based on the activities in one of the previous posts
LarsAsplund
commented
9 years ago Added functionality for handling client/server/command/transaction/trigger communication patterns. Next is the publisher/subscriber pattern.
LarsAsplund
commented
9 years ago Added functionality for the publisher/subscriber communication pattern. Next step is a more complete example to more easily evaluate performance and ease of debugging which were two other requirements
LarsAsplund
commented
9 years ago @kraigher @barri @tomasnilefrost I've added an example for the communication mechanism. It's a card shuffler that takes a stream of input cards encoded into a std_logic_vector. Once 52 cards have been received a shuffled output stream is generated. At least that's the idea. So far I've only implemented a testbench.
The test runner publishes 52 transactions, one for each card. A driver subscribes to this stream and converts the transactions into the input std_logic_vector. On the shuffler output there is a monitor that translate the shuffled std_logic_stream to card transactions again. A scoreboard subscribes to this stream as well as the input stream from the test runner. Once the test runner has published its 52 transactions (@ time = 0) it sends a request to the scoreboard to send status after it has received 52 cards from the monitor . The test runner then waits for the reply, verifies the status, and then the test is ended.
This testbench uses all the communication patterns we've discussed so far and should be useful for evaluating the com mechanism. In this first iteration I focused on getting the code "dense" and that requires support functions for encoding/decoding. Exactly how these should realized is still TBD but the point is that the codec functions in codecs.vhd could be generated from the message type declarations in msg_types.vhd
Would something like this fulfill the user stories for minimum boilerplate and good defaults? I guess that procedure calls without the status output would be useful since I'm often not using it.
I'll await your comments before proceeding. Synchronization, codecs, and performance still need to be addressed.
tomasnilefrost
commented
9 years ago @LarsAsplund seems like you are making great progress! I'm sorry that I haven't had the time to contribute with feedback, my weeks have been quite hectic. I'll try to look into the current work further next week and try to come up with some comments.
LarsAsplund
commented
9 years ago Support for synchronous communication has now been added. Instead of doing like this in the example testbench
send(net, self, scoreboard, get_status(52), status);
wait_for_scoreboard_reply: loop
receive(net, self, message);
if msg_type(message.payload.all) = "get_status_reply" then
check_false(decode(message.payload.all).checksum_match, "Identical deck after shuffling");
exit wait_for_scoreboard_reply;
end if;
end loop;you can do like this to wait for the reply to the request (get_status(52)) with a specified message id (receipt.id). Other messages in the client inbox are left untouched for later processing.
send(net, self, find("scoreboard"), get_status(52), receipt);
receive_reply(net, self, receipt.id, reply);
check_false(decode(reply.payload.all).checksum_match, "Identical deck after shuffling");@kraigher could you elaborate on the use cases for
-- block until receiver has consumed message (optional) wait_until_received(message_status);
There also similar functionality like checking if an actor is online (blocking on a receive procedure call)
kraigher
commented
9 years ago @LarsAsplund I is useful in the scenario when the receiver consumes messages at a slow rate and the sender wants to adapt to this rate instead of creating a huge inbox.
LarsAsplund
commented
9 years ago | As a | I want | so that |
|---|---|---|
| testbench developer | to limit the actor inbox size | memory usage and maximum message latency can be controlled |
LarsAsplund
commented
9 years ago @kraigher I made a new user story out of this. If we let the receiver create an actor with a bounded inbox we get a bit of slack when there is a temporary overload. The tradeoff would be the maximum latency we can handle. This would also handle multiple senders. The send command can simply block with an optional timeout when the receiving inbox is full. What is the desired behaviour for a publish when some subscribers are full? Will think about that when I start with the test cases.
LarsAsplund
commented
9 years ago Pushed support for limited inbox size. Reply and send will wait for a user defined time when the receiver inbox is full, default is wait "forever". Publish will never wait but rather skip sending to subscribers with full inboxes. The reason is that the publisher/subscriber pattern implies that subscribers aren't aware of each other and the publisher doesn't know who the subscribers are. If we block when a subscriber inbox is full then the pace of message exchange is set by the slowest subscriber and we have created dependencies between actors that have no knowledge of each others existence.
LarsAsplund
commented
9 years ago Pushed encode and decode functions for 25 or so types that are native to VHDL or part of standardized IEEE packages. Didn't put any effort in making the encoding compact, I've used "plain text" style, e.g. a boolean becomes the string "true" or "false". This can be optimized later on. Instead I've put the effort on how codecs for custom types can be made out of these primitive codecs and/or custom primitives. For example, if I have these types
type rank_t is (ace, one, two, three, four, five, six, seven, eight, nine, ten, jack, queen, king);
type suit_t is (spades, hearts, diamonds, clubs);
type card_t is record
rank : rank_t;
suit : suit_t;
end record card_t;
type card_msg_type_t is (load, received);
type card_msg_t is record
msg_type : card_msg_type_t;
card : card_t;
end record card_msg_t;I can write encoders like this
function encode (
constant data : rank_t)
return string is
begin
return rank_t'image(data);
end function encode;
function encode (
constant data : suit_t)
return string is
begin
return suit_t'image(data);
end function encode;
function encode (
constant data : card_t)
return string is
begin
return create_group(encode(data.rank), encode(data.suit));
end function encode;
function encode (
constant data : card_msg_type_t)
return string is
begin
return card_msg_type_t'image(data);
end function encode;
function encode (
constant data : card_msg_t)
return string is
begin
return create_group(encode(data.msg_type), encode(data.card));
end function encode;
Maybe not the best example since I'm not using any of the provided basic type encoders but the point is that these encoders (and the decoders) should be possible to generate given the datatypes. That will be the next step to spare the user from the details of making communication happen and boilerplate coding
kraigher
commented
9 years ago @LarsAsplund would it not be better to encode things as a sequence of bytes such that an integer is four characters and a boolean is one character. This way every type has a fixed size and there is no need for grouping. A record is simply serialized/deserialized as a sequence of its members. Additionally it is probably faster and requires less storage. Enums would be encoded/decoded as integers using enum_type_t'pos and 'val attributes.
LarsAsplund
commented
9 years ago @kraigher Yes, something like that would improve it just in the ways you mention but I started like this to make it easier to debug while developing since messages are humanly readable. Once the codec stuff is completed I think all functional user stories are covered (or at least addressed) and it's time to address the non-functional ones. That will hopefully take us to the right tradeoff between performance and ease of debugging. Maybe codecs can have a fast and a debug mode? Or maybe we address debugging in other ways and just make it fast. We'll see.
LarsAsplund
commented
9 years ago I've now pushed a first iteration of the codec generation support. More type parsing support, more tests, some restructuring etc are needed but the functionality is sufficient for the card shuffling example under examples/com so now you can have a first glimpse of what I think the end product will look like. I currently support parsing of basic enums and records. For example, parsing
type suit_t is (spades, hearts, diamonds, clubs);will result in the following codecs
function encode (
constant data : suit_t)
return string;
alias encode_suit_t is encode[suit_t return string];
function decode (
constant code : string)
return suit_t;
alias decode_suit_t is decode[string return suit_t];The aliases are sometimes useful for handling compiler ambiguities.
If you have a record type with the the first element named msg_type and that element is of an enumerated type, e.g.
type card_msg_type_t is (load, received);
type card_msg_t is record
msg_type : card_msg_type_t;
card : card_t;
end record card_msg_t;you will also get the following encoders
function load (
constant card : card_t)
return string;
function received (
constant card : card_t)
return string;so instead of sending a command to load the card shuffler with a new card like this
send(net, card_shuffler_driver, encode((load, (ace, spades))), send_receipt);you can do
send(net, card_shuffler_driver, load((ace, spades)), send_receipt);which is a bit more readable.
To activate codec generation you have to add one line to your run script. The first two lines in the example below is what you normally do to create and add a number of files to a library. The third line is the new one which means that codecs shall be generated from the msg_types_pkg package that was added along the files in line two. The resulting codecs will be placed in a package named msg_codecs_pkg which is compiled into the same library.
tb_shuffler_lib = ui.add_library('tb_shuffler_lib')
tb_shuffler_lib.add_source_files(join(dirname(__file__), 'test', '*.vhd'))
tb_shuffler_lib.generate_codecs('msg_types_pkg', 'msg_codecs_pkg')Next on my agenda will be to add support for more types, primarily custom array types. I'm also considering the possibility to add default values to record types so if you have a msg_type record with many elements that results in an encode function with many parameters you would have default values for all those parameters. Such default values could be defined by a constant with some naming convention, e.g. foo_t_default for a type named foo_t.
Any other ideas?
LarsAsplund
commented
9 years ago I've now added codec generation for custom array types as well. There are other types to recognize and generate codecs for as well but I feel I should pause here and focus a bit on the non-functional user stories. The one addressing performance may very well require a change in the verbose, plain text, easy to debug encoding style I'm using right now so it's better to do some profiling before adding support for more types. Since we've done work on all functional user stories I also feel it's time to summarize the solutions so far:
| As a | I want | so that | Solution |
|---|---|---|---|
| testbench developer | a fundamental communication mechanism | I can realize more advanced communication-related patterns (transactions, client/server, ...) with minimal effort. | The message passing paradigm we're using is based on the actor model which is a fundamental mathematical model of concurrent computation so it can't get much more fundamental than this. |
| testbench developer | communication to be performed without passage of physical time (only delta cycles) | synchronization with the unit under test is simplified. | Communication takes no physical time unless the receiver is busy doing something else. The sender is not blocked by a busy receiver unless the receiver has a bounded inbox which is full. The default is an unbounded inbox. |
| testbench developer | the task of designing communication to be focused on what to communicate and with whom | I don't have to spend time on the information transport (routing, resource allocation, queues, ...). | All you need are the names of the actors involved and to create a message of a datatype of your selection |
| testbench developer | One sender can broadcast information to many receivers | So that more receivers can be added without affecting the sender. | Dedicated support for publisher/subscriber pattern |
| testbench developer | the ability to set timeouts when waiting for information | I can have both event-driven and polling processes and everything in between. | Optional timeout on receive type of procedures. Default is wait "forever". |
| testbench developer | all actors to have a unique identifier | I can address other actors directly without having any other knowledge. | Create and find functions. |
| testbench developer | actors to be able to respond to incoming messages without a priori knowledge of the sender | I can implement patterns like client/server. | Reply procedure. |
| testbench developer | some actors to publish triggers | other actors can synchronize their actions with the publishers. | A publish or a send from the triggering actor together with a receive with no timeout at the triggered actors will achieve his. |
| testbench developer | encoding/decoding methods for common data types (such as enums) | reinventing encoding of common types in every testbench is avoided | Codecs for all (?) built-in and IEEE standardized types. Codec generation for custom enum, record, and array types. Support for more custom types can be added. Not all legal enum/record/array types supported. Codec development for non-supported types are aided with some primitives. |
| testbench developer | to limit the actor inbox size | memory usage and maximum message latency can be controlled | Optional to limit inbox size when an actor is created. Default is "no limit" (RAM on the host computer will place a limit) |
I think the codec support is the area for improvement although the most common use cases are covered. The other stories seem to be pretty much covered.
LarsAsplund
commented
9 years ago I've now done a first iteration with performance enhancements
So the execution time was almost halved with these modification. Now there is no obvious single point that will give a lot extra so the next step will be to create more dense encodings and improve in many places. I will probably keep the current "plain text" solution and have it available in a debug mode
kraigher
commented
9 years ago @LarsAsplund Have you thought about rebasing on master? The communication branch is quite far behind.
kraigher
commented
9 years ago @LarsAsplund I have rebased the branch and pushed to communication-develop-rebased to save you some work. There are tons of pep8 and pylint warnings though.
kraigher
commented
9 years ago @LarsAsplund I pushed a commit fixing the pep8 violations on the rebased branch.
kraigher
commented
9 years ago @LarsAsplund There are still pylint warnings though. You should have a look at them yourself. Some are minor and easy to fix and others indicate that some functions are way to large and should be split up into multiple smaller functions.
LarsAsplund
commented
9 years ago @kraigher Thanks Olof. I'm thinking the second iteration of performance enhancements will be sufficient to cover all user stories. After that I will do a cleaning/refactoring pass and then take everything to the master branch
kraigher
commented
9 years ago @LarsAsplund Great. Could you create a "pull request" for it when you think it is ready for the master branch to give me and others a to chance review it and write some comments. It is hard to comment when there is multiple commits and it is not ready.
LarsAsplund
commented
9 years ago I finally made a more optimized codec solution which removes another 20% from the execution time in my test (tb_card_shuffler under examples/com). The test is now three times faster compared to the version I had before the performance enhancements. The new codecs are based on the following principles
This somewhat general approach to encoding has a good overall performance effect on my test which doesn't use all data types. To get even better performance one should study each datatype individually but that's a lot of work so I will leave that to more long-term continuous improvment. What's more important right now is to set the principle for how the trade-off between the performance and ease of debugging user stories should be handle. The principle I use right now is:
From a performance point of view it's also interesting to compare com with other communication schemes and also to investigate under which circumstances this way of communication becomes an intolerably large part of a testbench. I will do some work in this area but I have at least one observation. The card shuffler test includes roughly 750000 messages and takes about 6 seconds. The card shuffler itself has yet to be implemented, it only passes input to output and takes "no time" to simulate which means that the vast majority of the 6 seconds comes from message passing. With these numbers we have about 125000 messages per second.
@kraigher Do you feel that this meets your performance/debugging user stories so we at least can make a baseline on master with this approach (after I made an iteration with rebasing/refactoring)?
| As a | I want | so that |
|---|---|---|
| testbench developer | The mechanism to be fast. | So that I can use it without paying a large runtime cost. |
| testbench developer | The mechanism to be easy to debug | So that I can debug my complicated testbench using much message passing. |
The final two non-functional user stories are
| As a | I want | so that |
|---|---|---|
| testbench developer | minimal boilerplate | I can focus on the functionality of the test. |
| testbench developer | good defaults | I don't have to tinker with details unless needed. |
I think both of these are met with actor model abstraction. The minimal setup is to create the actors involved, define the message format, and then send the message to the target actor. Agree @barri ?
kraigher
commented
9 years ago @LarsAsplund Nice performance improvements. If you rebase on master, squash it into one commit and make a pull request it will be easier for me and others to review it as a whole and give comments. One direct comment I have is that it does not feel very lean to have two implementations of the codecs which have to be maintained. Does the plain text variant really bring that much benefit? I would cut the fat and remove that one. I would think the fast variant would be just as easy to debug especially if trace print messages are added. Also I do not like that a very generally named --debug flag has been added to the command line interface for something very specific and optional. Maybe it should be named --com-plain-text-codecs instead if we should keep them.
kraigher
commented
9 years ago @LarsAsplund I have rebased your branch on develop again and pushed to communication-develop-rebased. Please try to use this for any further work to avoid problems.
LarsAsplund
commented
9 years ago @kraigher
LarsAsplund
commented
9 years ago @kraigher, @barri, @tomasnilefrost I've now completed an iteration of refactoring, PEP8 and pylint cleanup. I've also improved encoding of std_ulogic_vector-based types by encoding two bits in every character. I've also made it possible to have different msg_type enumeration types in different records while still being able to read the message type at the receiver with a single command.
Now is the time for you to comment on what's there. I will try to address any concerns you may have, add a user guide and a YouTube clip and then merge it to master to make the first release.
kraigher
commented
9 years ago @LarsAsplund It would look nicer and be easier to review if it was squashed into a single commit or a logical sequence of commits.
kraigher
commented
9 years ago @LarsAsplund I does not go clean through PEP8 and pylint.
When I presented VUnit at FPGA Forum i Norway last week I showed a slide (2:40 into this presentation) with a VUnit testbench example. The example showed a testbench with mixed levels of complexity. The unit under test was partly controlled by pin-wiggling and partly controlled with more high-level transactions. The point was to show that VUnit does not care about the complexity of your testbench, it can be simple or advanced. However, after the presentation there was a number of question around the underlaying message passing mechanism I used for the transactions. Is it part of VUnit? Is it for free? There were also discussions around how streams of transactions should be organized in a testbench. Should all stream be controlled from a central process (I did that using the test runner as the central process) or should there be (many) smaller parallel processes controlling one stream/interface each. Regardless of the answer there was an interest for a reusable communication mechanism that could support transactions but also other communication design patterns. This would not be a part of the "VUnit core" but more of a good to have utility for testbench development. Unit testing is at the core of the VUnit project but our project mission is open to best practises in general so I think such a mechanism has a place. One way forward would be to simply push the code I currently have but I know that there are more similar ideas within the community so I would like to make an experiment and take one step back and let the community design and implement this functionality. I'm thinking an approach similar to this
I realize that it's sometimes easier to exemplify how things can be done in order to describe what you want but let's try to at least put the initial emphasis on WHAT. Sounds like a plan?
I think we should start the discussion in this issue to get some attention but at some point, maybe after the user stories, we should move the design to a wiki page.
I will start with a few user stories and let you fill in and then we will see what happens.
I'm not sure about your experiences with user stories and I guess there are tons of rights and wrongs (probably overlapping). However, I'm used to the following format
As a, I want so that .
Some people consider the reason to be optional but my experience is that it's vital. It's not uncommon that everyone agree that the reason is obvious but in their minds they have different reasons.
Ok, let me start with three user stories.