Welcome to FPGA Design for Embedded Systems. In this video, you will learn how the important concept of Delta delays are used to model concurrency in hardware processes, how the VHDL simulators model variables versus signals, and how Verilog simulators model blocking versus non-blocking statements. An HDL simulator is just a software program. It models the actions of hardware, but also includes other elements. It's a complete and powerful development environment. It uses clever programming techniques to create the appearance of concurrency to correctly model how real hardware behaves. Some HDL code will simulate, but not synthesize. Some HDL code will synthesize, but not simulate. Your HDL code describing hardware should both simulate and be synthesizable. A Delta delay is a very important concept to understand in simulation. The Delta delay is the default assignment propagation delay in the case that no delay is explicitly defined. The Delta is an infinitesimal time unit so that all signal assignments can result in signals assuming their values at some future time. For example, if you had this statement, "Output gets not the input," the output assumes the input in one Delta cycle. Delta delay supports and in fact, makes possible a model of concurrent HDL process execution. As a consequence, the order in which processes are executed by the simulator does not affect the simulation output. In this example circuit, how are changes through multiple levels propagated in the simulator? As the AND input goes from 1-0, if the NAND gate is evaluated first, then C remains at zero as we might expect. But at the end gate is evaluated first. The C will briefly be a one before then changing to a zero. Is there a way to resolve this behavior consistent with how the devices work? Delta delays can help solve this problem by resolving the apparent simultaneous logic global changes, as we would expect. At time 0, the input changes. This force is evaluation of the inverter, creates a transaction on signal A. This then requires a Delta delay, which changes the value of a requiring evaluation of B and C. At Delta 3, B and C change, requiring another evaluation of C because B is an input to C or to the gate that creates C. This occurs then in Delta 4. There's no pending changes after Delta 4, so the process suspends until the next scheduled time when A event may happen. These four Delta delays all happened at time 0. Before it can progress to time 1, all of these things happened and it basically resolved all the logic so that it ended up in a known state before it went on to the next time. Delta delays also help model the difference between signals and variables in VHDL. In this example, the variable changes immediately, but the signal does not until after one Delta delay. Verilog also has the concept of Delta delays, in fact, they are inherent inside of the simulator. In Verilog, delays are modeled using the delay control operator #n, where n is some number, which has the simulator effect of suspending simulation for n time units. So for this code, the first assignment statement is going to be delayed by 10 time units because of the #10 in front of the assignment statement. Then if you go into the always block, we're creating a clock here setting it to 0, and then waiting for 50 time units setting it to 1, and then waiting for another 50 time units. This is eventually going to fall out the bottom and it comes back, and so on. I've added a couple of other statements here, which you normally wouldn't do if you were trying to generate a duty cycle clock of 50 percent. But anyway, the next example has a #10 in front of an assignment inside of an always block, which is a blocking delay, and so this assignment is not going to happen until after 10 time units have passed. The next statement has an inner assignment delay, and in this case, the calculation of x plus y is going to occur, then it's going to wait for 10 time units before that gets assigned to a. Let's look at this a little more closely. Unlike a blocking delay, in a non-blocking assignment, the right hand side is evaluated before the delay. These type of statements that we have here that have time delays in them are good for simulation code, but they're not synthesizable as delays. If we look at the code here, with blocking assignments, we've got a equals #5b plus c, so in this case, b plus c is going to get evaluated, and then a change is going to be scheduled in a for five time units later. Then the next assignment statement uses a, but a is not available yet, and so that assignment statement will be delayed until five time units elapsed, so that statement is basically blocked by a. If you have a non-blocking assignment though, like we see in the next set of code, where a gets #5 plus c 5b plus c, b plus c will be evaluated, the change will be scheduled. But then the next statement that's seen is not going to be blocked by the previous one, and so it's going to execute immediately, which means the d is going to get the old value of a. So we have to be really careful about mixing blocking and non-blocking assignments inside of an always block. It's generally something that you don't want to do. You usually either use one or the other. That avoids the problem, which is really hard to debug at times. The way the simulator works creates the situation and we need to be aware of it when we're writing code for simulation. Other helpful hints can come from looking at a couple of really great articles by Cliff Cummings, which are highly recommended. So if you have a chance to take a look at those, it'll tell you a lot more about non-blocking assignments with delays and so on. In summary, in this video, you have learned how the important concept of Delta delays are used to model concurrency in hardware processes, how VHDL simulators model variables versus signals, and how verilog simulators model blocking versus non-blocking statements.
