Extend support for FlooDMA traffic generation#182
Conversation
* Floogen is used to populate the traffic model with information concerning the FlooNoC instance.
* The class content match the traffic cfg information, similarly to what floogen also does.
The generator currently loads and compiles floonoc and traffic models.
* Add start, done, and ready control signals to control the execution of floo dma. * Loop execution of floo dma based on control interface. * Access queues with array indexing to preserve dma jobs between different execution runs.
* Handle execution corner case where floo dma is activated without jobs to execute.
* hw: Add floogen makefile recipe. * hw: Add `nw_mesh` to bender compilation. * util: Add makefile arguments for traffic generation. * util: Change default `traffic_type` to `dma_mesh` as `random` type is not supported.
I have removed the ready signal as it was redundant and was creating problems if initialized to 1'b1 at reset-time, which would however make sense from a logical pov. Thus, end_of_sim_o is directly used in place of ready.
* Update interfaces of floo_dma_test_node and axi_bw_monitor. * Add procedural start-wait controls. * Tested in rtl simulation.
Clean the tb procedural block.
* Add support in Makefile. * Add two examples of `traffic_cfg` files for xy-based mesh testbenches (narrow, narrow-wide).
The floonoc protocol type is used to populate the traffic model and distinguish between narrow, wide, or other floonoc channel types. If this is not specified in the floogen configuration, then the job generator will assert warnings.
There was a problem hiding this comment.
Thanks for the PR @gbellocchi! I finally got some time to review it🤓 I was thinking whether it makes sense to directly integrate the gen_jobs.py script into floogen. Because some of the things are actually duplicate now.
Also, it would be nice to add some examples that can be used as reference.
There are also some trivial linting issues that need to be fixed.
|
|
||
| protocols: | ||
| - name: "axi_in" | ||
| type: "narrow" |
There was a problem hiding this comment.
is this necessary for the axi network type?
| always_ff @(posedge clk_i or negedge rst_ni) begin : proc_start | ||
| if(!rst_ni) begin | ||
| start <= 1'b0; | ||
| end else begin | ||
| start <= start_of_sim_i; | ||
| end | ||
| end | ||
|
|
||
| always_ff @(posedge clk_i or negedge rst_ni) begin : proc_ready | ||
| if(!rst_ni) begin | ||
| end_of_sim_o <= 1'b0; | ||
| end else if(done == 1'b1) begin // job completion, floo dma is ready to accept new jobs | ||
| end_of_sim_o <= 1'b1; | ||
| end else if(start == 1'b1) begin // start, with jobs to run | ||
| end_of_sim_o <= 1'b0; | ||
| end | ||
| end | ||
|
|
There was a problem hiding this comment.
could use FF macros from common_cells/registers.svh if you want
| try: | ||
| from floogen.config_parser import parse_config | ||
| from floogen.model.network import Network | ||
| FLOOGEN_AVAILABLE = True | ||
| except ImportError: | ||
| FLOOGEN_AVAILABLE = False |
There was a problem hiding this comment.
In theory, you could also integrate this directly into floogen as a new target. And then call it something like this:
floogen traffic -c config.yml --traffic traffic.ymlWhat do you think? Then we could get rid of this separate script
| job_file.close() | ||
|
|
||
|
|
||
| def gen_chimney2chimney_traffic( |
There was a problem hiding this comment.
I think gen_[nw]_chimney2chimney_traffic can ge removed entirely. This is legacy stuff that is not used anymore.
| if args.tb == "chimney2chimney": | ||
| gen_chimney2chimney_traffic(**kwargs) | ||
| elif args.tb == "nw_chimney2chimney": | ||
| gen_nw_chimney2chimney_traffic(**kwargs) |
There was a problem hiding this comment.
Can be removed, see above
| clean: clean-vsim clean-spyglass clean-jobs clean-sources clean-vcs | ||
| build: compile-vsim | ||
| run: run-vsim | ||
| run: run-vsim No newline at end of file |
| always_ff @(posedge clk_i or negedge rst_ni) begin : proc_ready | ||
| if(!rst_ni) begin | ||
| end_of_sim_o <= 1'b0; | ||
| end else if(done == 1'b1) begin // job completion, floo dma is ready to accept new jobs |
There was a problem hiding this comment.
| end else if(done == 1'b1) begin // job completion, floo dma is ready to accept new jobs | |
| end else if(done) begin // job completion, floo dma is ready to accept new jobs |
| end_of_sim_o <= 1'b0; | ||
| end else if(done == 1'b1) begin // job completion, floo dma is ready to accept new jobs | ||
| end_of_sim_o <= 1'b1; | ||
| end else if(start == 1'b1) begin // start, with jobs to run |
There was a problem hiding this comment.
| end else if(start == 1'b1) begin // start, with jobs to run | |
| end else if(start) begin // start, with jobs to run |
SUMMARY OF CONTRIBUTIONS
Add FlooDMA traffic generation from YAML configuration files
I have extended the FlooDMA job generator (
gen_jobs.py) to support FlooDMA job generation from traffic configuration files (YAML).This feature simplifies the generation of custom traffic patterns, reusing FlooGen to retrieve the target FlooNoC topology information.
Below are the main contributions:
floogen/examples/) using FlooGen and produce a NoC model;hw/test/traffic_cfg/);Then, I have verified the new feature using the supported testbenches, making use of FlooDMA:
traffic_cfg) have been added underhw/test/traffic_cfg;tb_floo_axi_mesh.svandtb_floo_nw_mesh.sv;axi_bw_monitorto compare traffic generated directly in Python against traffic generated usingtraffic_cfg.Extend the FlooDMA control plane
I have modified the control plane of
floo_dma_test_nodeto launch DMA jobs after triggering astartsignal.This feature enables running FlooDMA multiple times during one simulation run, which might prove useful during design space exploration.
Below are the main contributions:
start_of_sim_isignal to thefloo_dma_test_nodeinterface;floo_dma_test_node;tb_floo_axi_mesh.svandtb_floo_nw_mesh.sv;