Winand Diagram

[Graziana Getz]

Iencountered a problem about progress flow diagram of GitLab CI/CD Pipeline. I have a cross-platform C++ project is trying to integrate into GitLab CI/CD, but the progress flow diagram confuse me, it is crisscross each other! is there any suggestion to make it clear ?

hey there, this is really late but I kinda had this problem too, I simply changed to order of the jobs in each stage on my cicd and it fixed it.

so if I have a test and build stage. test-linux and build inux should be higher than test win and build win in the ci file so that the lines are straight and not up and down, hope this helps

Last academic year (2015-2016), Winand Seldeslachts joined Sigasi to work on his masters thesis. For his thesis he investigated a new way to test VHDL code by extending Wavedrom.Wavedrom is a simple, textual language that is used to describe and visualized timing diagrams.Winand investigated how Wavedrom files could be used to generate input for VHDL testbenches.

The VHDL verifier 9000 is a program that runs on both windows and unix based operating systems. It is a tool designed to help VHDL designers in verifying and documenting their design. Let me demonstrate its function using a simple example.

If we compare the signal representations in the two pictures above, we can see that both representations look exactly the same, apart from formatting of course. In other words, I have had to use the same information twice: once to document my design, and once to build a self-checking testbench. It makes sense to want to have some kind of tool that could build both documentation and test from one source.

This was the starting point for the project. The result was the VHDL Verifier 9000. It is a simple tool that can help build both the test and the documentation from one source file. On top of that, it automatically runs the test, analyses the result and offers an easy way find discrepancies in simulation output and expected output.

The tool works in an intutive way: Clicking a button in the top row will open the corresponding folder. Clicking the bottom button will start the tool. The designer enters all source files in the input folder and his design in the design folder. He then runs the tool. When the tool has finished, the result file will be in the output folder.

A source file is the only thing the designer has to create, apart from the design itself. Source files are an extension of standard WaveDrom files. WaveDrom files hold the waveJSON formatted descriptions for signals. The WaveDrom engine converts this description to a visual representation. An example WaveDrom file is shown below.

When the tool is run, it combines information from the design file and the source file to generate a testbench. This testbench is then run using the VUnit framework, which logs important information. The output of this process is then used to build a comparison file that will compare the behavior of the design to the expected behavior. This file is called the result file.

Perhaps one day. For now it is only a proof of concept that has it limitations. It is useful for relatively simple designs and smaller (unit) tests. For example, for designs the size of an SPI master interface the system will still function, but the result file will become crowded and less readable when there are a lot of errors.

3a8082e126