Comments (4)
I think this would be a valuable feature (also to speed up the CI) and I would offer myself to implement this. The easiest would be to rewrite the run_vsim.sh
script in Python. How do you feel about this? @micprog @thommythomaso
from axi.
We should rather invest time in a proper Makefile to run stuff parallel. Instarted this effort in the VCD sim branch (to be merged)
from axi.
Two comments to understand what's the plan for extending your Makefile, since you mention it's partial:
- IMO it doesn't make sense to use Makefiles when all but the
*.log
targets are PHONY. And the only dependency of the*.log
targets is basically theBender.yml
file not the actual HDL source files themselves, so most of the time you will end up force-running these rules as if they were PHONY. In this case, IMO sticking to the Makefile language (compared to another scripting language e.g. Python) is just more restrictive than the benefits it brings (since we are not using the useful features of Make most of the time). - You are still using the
run_vcs.sh
file with the loops parameterizing and simulating the MUT.
Regarding 1
I can extend your Makefile to add the source files of a specific TB and MUT as dependencies of the respective target. If I'm not mistaken, this should be easy and safe using Bender. This would really justify having the Makefile, as you simply do make all
and he automatically figures out all and only what should be done.
Regarding 2
I wonder whether moving the loops into the Makefile could also make sense, each loop iteration would basically get its own simulation target. When you modify an HDL source file, all loop iterations for that MUT would anyways run so there is no benefit from this point of view. From the parallelization point of view it would make sense. However the same could be achieved just modifying the run_*.sh
scripts.
I thought about it and bringing this logic into the Makefile would probably be complex and criptic, with no reasonable advantage over the approach we are currently using. Here an example https://saveman71.com/2020/makefile-recursive-rules. In our case the cartesian product would be between the MUTs and their respective loop variables/bounds, with the additional complexity of not being a dense product.
So for this point I still propose to rewrite the run_*.sh
scripts in Python and easily parallelize them there. Of course let me know if you think differently. I'm glad to have your feedback.
from axi.
Two comments to understand what's the plan for extending your Makefile, since you mention it's partial:
1. IMO it doesn't make sense to use Makefiles when all but the `*.log` targets are PHONY. And the only dependency of the `*.log` targets is basically the `Bender.yml` file not the actual HDL source files themselves, so most of the time you will end up force-running these rules as if they were PHONY. In this case, IMO sticking to the Makefile language (compared to another scripting language e.g. Python) is just more restrictive than the benefits it brings (since we are not using the useful features of Make most of the time). 2. You are still using the `run_vcs.sh` file with the loops parameterizing and simulating the MUT.
Regarding 1
I can extend your Makefile to add the source files of a specific TB and MUT as dependencies of the respective target. If I'm not mistaken, this should be easy and safe using Bender. This would really justify having the Makefile, as you simply do
make all
and he automatically figures out all and only what should be done.Regarding 2
I wonder whether moving the loops into the Makefile could also make sense, each loop iteration would basically get its own simulation target. When you modify an HDL source file, all loop iterations for that MUT would anyways run so there is no benefit from this point of view. From the parallelization point of view it would make sense. However the same could be achieved just modifying the
run_*.sh
scripts.I thought about it and bringing this logic into the Makefile would probably be complex and criptic, with no reasonable advantage over the approach we are currently using. Here an example https://saveman71.com/2020/makefile-recursive-rules. In our case the cartesian product would be between the MUTs and their respective loop variables/bounds, with the additional complexity of not being a dense product.
So for this point I still propose to rewrite the
run_*.sh
scripts in Python and easily parallelize them there. Of course let me know if you think differently. I'm glad to have your feedback.
As I said it is incomplete.
To 1) Only running changed files if you call make all is not a requirement. The idea is to easily run all in parallel on your machine if you want to ensure all still pass or run them one by one.
To 2) Ofc. Move all to a nicely constructed makefile. I don't like the boilerplate code that you need to write in order to let something run in a magical version of python, that is maybe not installed on your target system. Make is specifically constructed to let such tasks run parallel. So lets use it.
from axi.
Related Issues (20)
- `axi_to_mem`: Comb path from `b_ready` to `w_ready` HOT 2
- axi_to_mem: Starvation issue: AW channel blocks AR channel forever
- axi_dw_downsizer: AXI Slave BRESP changes in value during BVALID’s wait for BREADY
- axi_pkg::LenWidth not compatible with vivado IP packager
- axi_cdc fpga implementation very inefficient HOT 2
- tb_axi_lite_xbar is not included in scripts/run_vsim.sh
- Vivado Synthesis Error - [Synth 8-6038] cannot resolve hierarchical name HOT 1
- ``axi_to_mem``: Error response signals in B and R response channels
- axi_dw_downsizer writing data beats with wstrb == 0
- Logging not supported for Queue item error : AXI HOT 2
- axi_iw_convertor connection
- AXI_BUS and AXI_BUS_DV package missing? HOT 2
- Pipelines between demux and mux would still cause deadlock in an axi_xbar? HOT 2
- Can't find cdc_fifo_gray_dst HOT 2
- Compile errors with CDC module
- "MaxTrans" defined incorrectly in the module documentation
- Error when IdMapNumEntries =0 with VCS
- Why is `xbar_latency_e` an `enum`? HOT 1
- Expose `AxiLookBits` as a parameter in `axi_burst_splitter` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from axi.