-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Block Design support for simulation #962
base: master
Are you sure you want to change the base?
Conversation
@LarsAsplund, this is related to issue #172 , which was closed as out-of-scope of VUnit. I think it's closely enough related to the standard IP core generation already present, especially considering the change is small. But in case you disagree we could add this support in tsfpga instead. |
This is great, thanks! Perhaps I'm missing something, but I found in Vivado 2019.1 if a Block Design isn't instantiated as part of the current simulation "top" module then This can be resolved by setting each Block Design as the top module for simulation in turn, replacing the last part of
|
I'm curious why would we actually want to compile it if it's not instantiated then? Or am I misunderstanding you? I have checked my simulation and for me the BD is instantiated in a nested way: |
Sorry, I explained poorly - it is if it's instantiated in a different (non-currently Perhaps it's specific to my project - it's been going for many years with multiple parts of the system (frontend, backend) that I'm attempting to get all into a single simulation framework (hence VUnit😄) We have a variety of testbenches and are currently migrating from the Vivado simulator to using VUnit with Modelsim/Questasim - this means that the current simulation I'm aiming to remove the dependency on requiring the full integration testbench to be set as the So for example, if I have the following structure, and want to run all the testbenches with VUnit:
Vivado won't pick up the simulation files for |
I'm still confused. If you have tb_unit_small compiled and tested then you dont instantiate the BD thus you dont have it nor want it. And thats ok. You dont want to compile stuff you dont use right? But when you set e.g. |
When I set the simulation I want to run as top manually, yes, everything works fine - it's when I want to use VUnit to run all testbenches in one go that I need to ensure all files needed for any of the simulations are in the VUnit compile order. (IE for running regression tests, which currently I run manually but eventually will be happening in CI when I get a gitlab runner set up) |
Ok I understand now. So your proposed solution adds setting the BD as top file temporary, and then returns to original top after its done? What if the fileset is not named |
Yes, exactly 👍 I haven't used multiple Vivado simulation sets before, but I've had a quick play around. We can use
to get whatever the current simulation set is. So replacing
This would handle the simulation fileset not being called But then perhaps covering those cases isn't necessary as the workaround of "make sure all BDs are in your simulation set" doesn't feel onerous or unreasonable to me (I assume if a project is using VUnit for simulation having multiple different simulation sets in Vivado becomes less useful anyway). |
Add support for out of scope BD build. Per @jh16g15
Hi @LarsAsplund any update on merging this fix? |
Updated the fork with newest @LarsAsplund to try to rerun the actions for merge. |
Closes #963
Added block design parsing and generation based on https://gitlab.com/tsfpga/tsfpga/-/issues/74.
tcl
file throughwrite_bd_tcl
for open block designstcl
should be located together with otherip_cores