Test Driven Design?

Nice!

tible with source control systems. When you don't have projects, you don't have piles of junk files of unknown purpose that changes every time you ope n a project or run a simulation. In non-project mode you have only hdl sour ces and tcl scripts. Therefore all information is stored in source control system but when you commit changes you commit only changes you have done, n ot random changes of unknown project files.

ering that you don't change ip's very often, it's not a problem at all.

be I should write an article about it. Where it would be appropriate to pub lish it?

I would like to know more about this. When I used ISE I only used scripts (shell scripts) and when I transitioned to Vivado I promised I would use TC L scripts but I've never done that and I'm still just using the GUI. I nee d to use the GUI to look at schematics of critical paths or to look at plac ement, but I'd like to use scripts to do all the PAR and timing and everyth ing else.

patible with source control systems. When you don't have projects, you don' t have piles of junk files of unknown purpose that changes every time you o pen a project or run a simulation. In non-project mode you have only hdl so urces and tcl scripts. Therefore all information is stored in source contro l system but when you commit changes you commit only changes you have done, not random changes of unknown project files.

idering that you don't change ip's very often, it's not a problem at all.

aybe I should write an article about it. Where it would be appropriate to p ublish it?

s (shell scripts) and when I transitioned to Vivado I promised I would use TCL scripts but I've never done that and I'm still just using the GUI. I n eed to use the GUI to look at schematics of critical paths or to look at pl acement, but I'd like to use scripts to do all the PAR and timing and every thing else.

I am writing an article about that. I'll post it here.

I examine timing reports in logs of Vivado, but if I have bad timings somew here, I often use GUI as well. It's just easier to understand what part of code creates bad timing if you investigate it visually. I just open vivado, do open_checkpoint post_place.cpt Then I examine schematics of the paths and and their placement. Non-project mode doesn't prevent using GUI when you need it. They work fine together.

It's a draft of an article.

It would be great if you left you comments right in the document or here, so that I could improve it.

Thanks.

It's finally published on edn.com !

If we are talking about the typical software developer interpretation of TD D we're dealing with code/test cycles that can be as short as one minute. T his is only possible with a fully automated approach to testing and that's why we have unit testing frameworks designed with this requirement in mind. I only know of two such frameworks for HDL, VUnit and SVUnit, so the popul arity of these tools may serve as an indication of how widely TDD is used. I can't speak for SVUnit but from what I understand it's mostly used by ASI C verification engineers. However, I'm "the guy" who setup the test environ ment for VHDL-2017 and also one of the authors of VUnit so maybe I can shed some light in that area.

VUnit is today used by both FPGA and ASIC teams, for VHDL and Verilog, from US to Japan, when developing everything from high-volume products like aut omotive vision to niche military system, by simulator vendors to verify the ir tools, and for education. If you're like me you prefer facts over claims from a promoter so I would recommend that you google for VUnit rather than TDD. You should be able to find job ads where people look for VUnit skills , that the latest version of Sigasi Studio added VUnit support, independent training providers , university education, VHDL text books, etc. You can a lso compare VUnit with other popular open source projects. Search for VHDL on Github and you'll find most of them. Look at the number of stars, where the supporters work, the number of forks, the number of opened issues, the number of closed. Look at the project homepages and the activities on their forums.

However, just because people use VUnit doesn't mean that they are doing TDD . What I see is mainly two types of users. Some users have their own SW exp eriences with TDD/unit testing or have seen SW people doing it. They know w hat the want and end up doing just that. The other type of users doesn't ha ve that experience or finds the concept somewhat absurd. They are more look ing at the convenience of having everything fully automated but stick with their longer code/test cycle and they tend to do less refactoring. It doesn 't mean that they don't get there eventually but it usually takes longer ti me. Unit testing and TDD is an acquired taste for anyone and requires pract ice. The good thing is that you can takes small steps and still get rewarde d.

After reading this thread I also feel that I need to "defend" the simplicit y of VUnit :-) If you look at the VUnit setup I made for the IEEE standard libraries I can understand if it looks complicated but that is not your ave rage project and not the place to get started. At better starting point is

There you will fi nd a clip showing how to install VUnit in a minute, how you can create a co mpile script for non-trivial project in a minute, and how you can have your project fully automated by adding 5 lines of code to every testbench. htt p://vunit.github.io/user_guide.html is another good source of information. So what makes the IEEE libraries different? Well...

- The simulator already knows about these libraries and gets confused when you try to compile them yourself.

- The code is not fully self-contained VHDL but relies on the simulator "ma gically" implementing some functionality

- Some subprograms are expected to assert warning/error/failure on certain inputs and that is not something that you can verify automatically within V HDL since the simulator stops. That can be handled with Python scripting or you can use VUnit's assertion library which supports mocking of asserts.

- I setup a continuous integration server to run all tests whenever people want to summit code to he Git repository. You don't have to do that in orde r to run VUnit or any other unit testing framework.

- IEEE already had 30 or so testbenches but these testbenches also contain many test cases. VUnit allow you to isolate these test cases such that you can run and have their status reported individually. Rather than having 30 passing testbenches we now have 1700 passing test cases. You don't have to do this though, 5 lines of code is sufficient.