In this video, we will have a look at VHDL simulation

of our circuit for lane detection with a Sobel filter.

Here you see the design specification.

We want to process images which are in 720p format,

which means they have 1280 by 720 pixel.

They are in 8 bit RGB, plus they have sync signals,

horizontal sync, vertical sync and data-enable.

For VHDL simulation, we need a testbench.

A testbench is another VHDL design

that is providing the input signals to our design, the stimuli,

plus it is processing, it is receiving

the output signal of our design, which is the response.

It is a surrounding for the circuit we want to design.

It represents the board where you would normally have

the input from the camera.

And you would have the output to a monitor or to a post-processing circuit.

In our design, we use an advanced form of a testbench,

which is a self-checking testbench,

which means that the results of our verification

are not only received and stored,

but we want to also check if the circuit is performing correctly.

This means we have a file with the input signal,

we have another file where we have the expected response.

These are signals we already know. These are signals we already have.

This is the output of our C simulation.

It is the test image we have

plus it's the output of the C simulation from the C program.

In this diagram, I will show you the design flow for VHDL simulation.

We start with the input image, which is a road scene.

We process it with a C program to have the reference file.

This processing is done with a fixed-point C program

so that we have a bit-true representation.

It should be exactly the same result that the circuit design will give.

These images are in bitmap format and VHDL cannot easily read this format.

So therefore we have to convert it to a text file.

I've used a format that is quite simple.

You have represented the bitmap file as a text file

where each line corresponds to one pixel.

You start with one line of a comment and then

you have the first pixel with RGB, the second pixel with RGB, and so on.

It's a big file, but we need all this information for simulation.

You also have the VHDL files, which is the testbench, plus the design files

for the circuit you want to implement.

You give all these information to the VHDL simulator.

We here used the ModelSim which is available in a version that's free to use

together with the Intel/Altera design environment.

From the VHDL simulation, you get console messages.

This could be something like "Simulation OK".

You can also get simulation results in a file.

Here, we output a text file, which represents the output image.

If everything is okay, this is exactly like the reference image.

If there are errors, it's possible

to convert this text file to a bitmap image again,

to have a look and maybe, by inspecting the visual result of your simulation,

find out what is wrong and do some debugging of your circuit.

This design flow might look a little bit complicated

because you have the different programs,

but this is exactly what you would find in industry.

We already have a bit-true C-simulation of our circuit,

but there are two small differences between the simulation

and the digital circuit that we have to consider.

The first difference is that we have to consider the image boundary.

Because we have a 3x3 matrix on which we process,

there will be one pixel on each border that is not valid.

The output images is two pixel smaller in X and Y direction.

The second difference is

that the position of input and output pixel are not exactly the same.

Let's have a look at the diagram to see why this is the case.

We do processing when we receive the last pixel of the 3x3 matrix,

which is this current input pixel.

However, the result of the 3x3 matrix

corresponds then to the center pixel,

which means that there is a shift of one pixel down and one pixel right

between the current position and the corresponding output pixel.

As a consequence, the bit-true simulation

has to consider this shift plus the invalid lines.

In the resulting image,

two lines on the top and two lines on the left are invalid.

This is considered by a slightly modified C program,

which is called lane_testbench.

From the test image street_0 in bitmap format,

we generate stimuli and expected response

by executing the C program lane_testbench for the design.

I use the Cygwin environment on Windows 10,

but you can adapt the C program to any other C compiler.

For the simulation, we then use the following VHDL files.

You have the testbench and you have the design files

for the design and the verification.

A more detailed explanation of these design files you find in a separate video.

To demonstrate the self-checking testbench,

I will include an error in the expected response.

We take the pixel at position 1000, 10 and change the value there.

To find this pixel in the testbench, we need to calculate the line of this pixel.

10 lines means 10 times 1280 pixel

and pixel 1000, as we start counting from 0, we have to take another 1001 positions,

plus we have one comment line.

So, this is the line number we have to look for.

We modify the correct response to a different value

so that the testbench will give an error.

Here, we have the ModelSim simulator.

We have the source files and compile them,

we start the simulation.

It's in the work directory.

sim_lane and the sim architecture.

This invokes the simulator window.

We can select input and output signals to be monitored in the wave window.

We start the simulation.

At the beginning, you will get some warning messages because

the memories contain uninitialized values.

Now, you see here the note that there has been a simulation mismatch

at position X 1000, Y 10.

This is exactly the error we wanted to see.

The self-checking testbench is working.

It has found the mismatch between expected result,

and the simulation result of our design-under-verification.

Now, the simulation is completed.

We get the message that there has been one mismatch in the simulation.

Now, we would do debugging.

In our case, we know that we have introduced

an error in the expected response.

We correct that and restart the simulation.

It takes, depending on your computer, about a minute.

Now, the simulation is completed.

We get a message, "Everything is okay."

The simulated result matches the result.

We can have a look at the wave signals to see what has been done here.

This is the view of the complete simulation.

If we zoom in, we see the individual lines with the sync-signals and data_enable.

This is the beginning of a line.

Here, if we zoom in a little bit more,

we can see individual pixels.

On the top, you see the input pixel.

First pixel is RGB 7F, 9D, 5F.

Here, you see the output pixel.

It's 1B for R, G, B.

The next step in our design flow is the synthesis of the FPGA.

You find more about this and about accessing the remote-lab

in the next video.