1

I have a project with multiple structural entities that each have sub-entities like the picture below.

enter image description here

Now I am trying to plan for the testing phase. I have checked UVVM, OSVVM, and VUnit and I found that VUnit is the easiest and fastest way to start.

I have read the documentation and played a little bit with the provided examples and I started to write some tests for some sub-entities like A1, A2, ..., etc.

My question is how to use VUnit for testing at a system level and how should I structure my testbench?

  • Shall I write tests for all sub-entities and then for the structural entities, and then for the whole system?
  • Shall I write tests for the structural entities as transactions?
  • Shall I write tests for all sub-entities each in a separate architecture file and run them in sequence in the test suite in top-level testbench?
  • Any other suggestions?
Ahmad Zaklouta
  • 165
  • 2
  • 12
  • 1
    VHDL doesn't have modules or submodules. Blocks are either internal (block statements) or external (entity and architecture pairs that elaborate as nested block statements and can be instantiated). Empty block diagrams aren't particularly informative. Ask a single specific question. –  Jun 15 '20 at 10:24
  • 2
    This question is quite broad, and it is more about testing in general than specifically VHDL. Please read some good book about testing, decide for a strategy that fits your needs best, and then follow that. – the busybee Jun 15 '20 at 11:19
  • @user1155120 I meant by blocks a structural entity that includes several sub-entities and by submodules different entities. – Ahmad Zaklouta Jun 15 '20 at 11:22
  • @thebusybee do you have any suggestions? – Ahmad Zaklouta Jun 18 '20 at 10:36
  • Recommendations are out of scope of SO, but you might like to start by using your favorite web search engine and ask it about "ISTQB". – the busybee Jun 18 '20 at 10:39

1 Answers1

4

This is the type of question that risks being closed as opinion-based so I will just give a few general remarks that can guide you in your decisions.

  1. VUnit doesn't care about the size of the thing you're testing. It can be a small function or a very large system. The basic test strategy is not a tool question but something you're free to decide.
  2. Regardless of test philosophy I think most, if not all, developers agree that it's better/cheaper to find bugs early rather than late. This means that you should test often and start on small things. How often and small depends on the test overhead and bug frequency which depends on the tools being used, experience of designer, complexity of the problem etc. There's no universally true number here.
  3. A transaction is a coding abstraction and as such it can improve readability and maintainability of the code. However, using too much abstractions for a simple problem adds no value. If the thing you're testing has a single simple bus interface it makes sense to create simple read and write procedures that you call after one another. If you have several interfaces and want to perform concurrent transactions on those interfaces you need somehing more. The VUnit solution for this is to take your simple transaction procedures and add message passing on top of that. https://www.linkedin.com/pulse/vunit-bfms-simple-emailing-lars-asplund/ explains how it's done
  4. I'm not sure if I understand your last question but if you're thinking about only testing the small things from the top-level you would need to develop the top before testing can start. That would go against number 2.

Disclaimer: I'm one of the VUnit authors but I think I managed to avoid personal opinions here.

lasplund
  • 1,350
  • 1
  • 8
  • 17
  • I found this very useful: https://stackoverflow.com/questions/42980036/how-to-combine-multiple-vunit-run-py-files-into-a-single-vunit-run – Ahmad Zaklouta Jun 18 '20 at 10:37