It will be useful later on if we have the option to not merge all the functions in a class together - maybe merging partly or not at all. The unmerged functions would be stated-out seperately and would interact using the protocol - so the structural steps would now operate between functions within an object as well as between objects.
This gets rid of the idea that the sequential/structural divide has to be at the object/module level. Now it will be able to be at a lower level, perhaps down to the individual function level. This may permit optimisation to do a better job and also let us extract more parallelism.
We still want to preserve the object<->module duality, so introducing new classes around individual functions or groups of functions and then using the existing scheme is out. Instead, we expect to use Verilog's ability to supply multiple "always" blocks (hardware processes) in a single module.
We also have an issue with class member data of fundamental types. Again, we do not want to surround them with new objects. Each group of merged functions (call them servers) could access the underlying registers as though there were no other servers or access to them could be implemented through TLM channels/protocols (basically making each memeber variable a server). The latter scheme seems rather heavyweight but might do better with concurrency.
The term server now represents each node as far as the structural steps are concerned - it may be a single function, or it may be all the functions in an object or somewhere in between. Making multiple classes into a single server has problems because that would mean multiple modules, and modules need well defined wire-based ports, which kind-of forces a structural solution.
I suggest the term "server" should be used where appropriate even if we retain a 1:1 object to server relationship.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Merging the functions together in an object only loses concurrancy. But the overall philosophy places concurrancy at the inter-object level only. The philosophy also describes a clear change in appraoch between inter-object and intra-object stuff. This is a good simplifying assumption and we should stick to it.
There is certainly no need to use multiple "always" blocks in a module just because we can. Verilog is somewhat redundant in this area and there's nothing wrong with not mapping onto everything Verilog can express. Indeed, verilog coding standards often set rules that limit usage to allow a more consistent style. So a "one always block per module" rule is actually quite natural.
There's nothing else in the earlier argument that is particularly compelling.
Introducing servers complicated the design significantly in the data phase and would tend to introduce confusion everywhere. Furthermore, the user would have to specify the servers using hinting, which is a significnt extension to C++ and we don't really want to do that. In the case of multiple servers for parallelism, the allowed interactions would need specifying via "server interfaces" and we'd be substantially duplicating the existing class interface support in C++. It will be no harder for a programmer to simply split a class in two, particularly if he/she is willing to give the new "partial" classes public data members.
All mention of servers is to be removed. The semantics of servers will now apply to classes/objects so that we hard-code a one-server-per-class rule. The word "server" will be expunged from the designs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It will be useful later on if we have the option to not merge all the functions in a class together - maybe merging partly or not at all. The unmerged functions would be stated-out seperately and would interact using the protocol - so the structural steps would now operate between functions within an object as well as between objects.
This gets rid of the idea that the sequential/structural divide has to be at the object/module level. Now it will be able to be at a lower level, perhaps down to the individual function level. This may permit optimisation to do a better job and also let us extract more parallelism.
We still want to preserve the object<->module duality, so introducing new classes around individual functions or groups of functions and then using the existing scheme is out. Instead, we expect to use Verilog's ability to supply multiple "always" blocks (hardware processes) in a single module.
We also have an issue with class member data of fundamental types. Again, we do not want to surround them with new objects. Each group of merged functions (call them servers) could access the underlying registers as though there were no other servers or access to them could be implemented through TLM channels/protocols (basically making each memeber variable a server). The latter scheme seems rather heavyweight but might do better with concurrency.
The term server now represents each node as far as the structural steps are concerned - it may be a single function, or it may be all the functions in an object or somewhere in between. Making multiple classes into a single server has problems because that would mean multiple modules, and modules need well defined wire-based ports, which kind-of forces a structural solution.
I suggest the term "server" should be used where appropriate even if we retain a 1:1 object to server relationship.
This issue now moved to "task requests" tracker
Changed my mind about this.
Merging the functions together in an object only loses concurrancy. But the overall philosophy places concurrancy at the inter-object level only. The philosophy also describes a clear change in appraoch between inter-object and intra-object stuff. This is a good simplifying assumption and we should stick to it.
There is certainly no need to use multiple "always" blocks in a module just because we can. Verilog is somewhat redundant in this area and there's nothing wrong with not mapping onto everything Verilog can express. Indeed, verilog coding standards often set rules that limit usage to allow a more consistent style. So a "one always block per module" rule is actually quite natural.
There's nothing else in the earlier argument that is particularly compelling.
Introducing servers complicated the design significantly in the data phase and would tend to introduce confusion everywhere. Furthermore, the user would have to specify the servers using hinting, which is a significnt extension to C++ and we don't really want to do that. In the case of multiple servers for parallelism, the allowed interactions would need specifying via "server interfaces" and we'd be substantially duplicating the existing class interface support in C++. It will be no harder for a programmer to simply split a class in two, particularly if he/she is willing to give the new "partial" classes public data members.
All mention of servers is to be removed. The semantics of servers will now apply to classes/objects so that we hard-code a one-server-per-class rule. The word "server" will be expunged from the designs.