Simulation on Vivado

[lorenrus]

Hi guys

i'm doing some tests with vhdl and vivado. I made a simple mux.
Within the architecture I used a "process".

From the theory I know that the assignments placed within the process are sequential to each other.

Having said that, I don't get the timing diagram of the simulation, attached. What I expected is that the output on DOUT would be at least slightly out of phase with respect to the "Sel" signal and the "Data_In".

Then I thought that it is normal that it is so because it is an ideal case and not a real one since the simulation was not done physically on an FPGA.

Is what I said correct or am I doing something wrong?

Thank you

[JohnnyMalaria]

The assignments are not sequential in timing way. You should think of your example as a truth table or lookup table. Furthermore, the assignments indicate what the values will be on the next clock cycle, not instantly. All of the "code" in the process block occurs in zero time in the simulation. There is a kind of sequential element in as far as if the same signal is assigned twice in process block, it is the last assignment that occurs.

[lorenrus]

Hello and thanks for the reply.

So the sequencing of the assignments doesn't just depend on how the VHDL code is implemented, right?
Can you give me an example that I can create with Vivado in which instead I can appreciate the sequentiality of the assignments placed within the process?

I attach the schematic and the code of the testbench.

Many thanks

[Bassman59]

Hi guys

i'm doing some tests with vhdl and vivado. I made a simple mux.
Within the architecture I used a "process".

From the theory I know that the assignments placed within the process are sequential to each other.

Having said that, I don't get the timing diagram of the simulation, attached. What I expected is that the output on DOUT would be at least slightly out of phase with respect to the "Sel" signal and the "Data_In".

Then I thought that it is normal that it is so because it is an ideal case and not a real one since the simulation was not done physically on an FPGA.

Welcome to the world of HDL simulation. The terms I use here can be found in any VHDL textbook, if you are not familiar. (I like Peter Ashenden's book.)

Let's start with what you designed. You have a combinatorial multiplexor, described with a process. The signals in the parentheses of the process are called "the sensitivity list." Normally, a process is suspended -- that means it is asleep -- until there is an event on any signal on the sensitivity list. At that instant, the process wakes up, and all of the signals on all of the right-hand-sides of all assignments are frozen.

Then the right-hand-sides of the assignments are evaluated, from the top down, and once that is complete for each assignment, the signals on the left hand sides of the assignment (<=)  are "scheduled for assignment." That is, the process will hold off on finally driving the signals on the left hand side until all of the logic on all of the right-hand-sides in the process are evaluated.

This evaluation takes place in "delta" time, which is infinitesimally short (think Dirac delta) and it's a simulation construct only, it's not "real" time. Thus in your simulation waveform display, it looks like the output changes instantaneously with changes in the input. But there really is a delay between the input and output. And it is important to remember this.

Remember that in this behavioral model, you don't care about actual gate delays. You know that some delay exists, but it doesn't matter. That's because later, in the final FPGA the tools will take your behavioral code and fit it into a chip with actual non-delta delays, and the timing tools will tell you what those delays are. And the delays can be different depending on FPGA family chosen,  routing and other such things.

So for a logic simulation you shouldn't worry about actual delays.

I suggest spending quality time with a good VHDL text.

[JohnnyMalaria]

Hello and thanks for the reply.

So the sequencing of the assignments doesn't just depend on how the VHDL code is implemented, right?
Can you give me an example that I can create with Vivado in which instead I can appreciate the sequentiality of the assignments placed within the process?

I attach the schematic and the code of the testbench.

Many thanks

Bassman59's explanation is, I'm sure, more coherent than mine I'll add that, in the second testbench, you have add some wait statements. So, now there will be an element of sequential ordering of events. But everything between each wait statement occurs in "delta" time. By adding the wait statements, you have simulated clock cycles. All the assignments made between two wait statements only become effective after the second wait statement.

Note, that such a process (lots of wait statements) cannot be synthesized into "real" logic on an FPGA. The "waiting" is achieved by having the process occur only when an appropriate signal change occurs (e.g, rising edge of a clock).

I strongly recommend https://vhdlwhiz.com/basic-vhdl-tutorials/

Disclaimer: I've very much a noob at this and have been climbing what seems like an insane mountain to learn. Every time I think "okay, got it", I move on to the next step and end up thoroughly confused and frustrated at how hard it is to find answers. But, I've persevered and gone from "what does <= even mean" to having a fully functional FPGA-based device.

[emece67]

.

[emece67]

.

[NorthGuy]

A combinatorial process is a map which translates all possible combinations of inputs to outputs. In your example, you have 11 inputs (which can produce 2^11 = 2048 different combinations). You have a single output. The combinatorial process determines what is the value of the output for each of the 2048 combinations.

The code you write describes the mapping. That's all.

The simulation goes statement by statement and "executes" them sequentially to simulate the mapping. At the end of the "execution"  it knows the value of the output.

The synthesis generates a combinatorial hardware block. There are 11 wires going in and one wire going out. The output of this hardware block will change according to the input signals based on the mapping table you have described. Thus all the code is "executed" simultaneously (although "executed" is not the right word - the sequence of your statements no longer exists - the hardware is only concerned with the result). In ideal world this happens immediately. In real world there's a propagation delay.

[NorthGuy]

You can actually buy the mux that you described as a ready-made IC:

https://www.ti.com/product/SN74HC151

There are many way to desribe it in VHDL, as there are many way to describe something in English. But the method you use to describe it doesn't affect the result.

[rstofer]

"Free Range VHDL" is a pretty good "free" book.  Google for it.

It important to partition your thinking between what simulates and what synthesizes.  At best, simulation is a hallucination.  There is no "sensitivity list" in synthesis.  There is no such thing as a process waking up when a signal in the sensitivity list changes.  Real logic doesn't have a list.

In fact, the sensitivity list is pretty much obsolete.  In VHDL 2008 it can be replaced with:
  process (all) begin

With VHDL-2008, you can use the process(all) statement that looks for all the inputs to
the process and then creates the logic.
  process(all) begin
    enable <= en1 and en2;
  end process;

Page 211 here:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_3/ug901-vivado-synthesis.pdf

One thing that is interesting with these simple circuits is to look at the RTL schematic.  Here you will see what the tool has actually created.  This should be part of the 'required reading'.  See how different versions of the HDL for a MUX result in different logic (or not).

[emece67]

.

[SiliconWizard]

"Free Range VHDL" is a pretty good "free" book.  Google for it.

It important to partition your thinking between what simulates and what synthesizes.  At best, simulation is a hallucination.  There is no "sensitivity list" in synthesis.  There is no such thing as a process waking up when a signal in the sensitivity list changes.  Real logic doesn't have a list.

In fact, the sensitivity list is pretty much obsolete.  In VHDL 2008 it can be replaced with:
  process (all) begin

We can also refer to this discussion which happened to elaborate on this quite a bit in the end:
https://www.eevblog.com/forum/fpga/combinatorial-inside-or-outside-of-a-process/

So in the end, I wouldn't say sensitivity lists are "obsolete" per se. VHDL is a pretty general hardware description language, and whereas incomplete sensitivity lists don't seem to make much sense for synthesis - and as you said, they are just ignored in this context - while (as was discussed in the above thread) it would be extra clunky, inefficient and complex to implement, nothing would really prevent synthesis to respect them to the letter. Synthesis tools just don't bother because pretty much everyone can agree this would add a lot of complexity for very little added value. But for simulation, incomplete sensitivity lists can have their uses.

[Bassman59]

It important to partition your thinking between what simulates and what synthesizes.  At best, simulation is a hallucination.  There is no "sensitivity list" in synthesis.  There is no such thing as a process waking up when a signal in the sensitivity list changes.  Real logic doesn't have a list.

In fact, the sensitivity list is pretty much obsolete.  In VHDL 2008 it can be replaced with:
  process (all) begin

At risk of diverging to another side discussion:

1. The sensitivity list is not obsolete. It is required for synchronous processes because the only signal that should trigger the process is the clock (and asynchronous reset, if used). This means that all of the inputs to the process which are combined to make the flip-flop's D input can wiggle in the wind as much as they want and that will not affect the Q output.

2. The statement "sensitivity list is not used in synthesis" is strictly true but to ensure synthesis and simulation results match, you can't ignore the sensitivity list. So please stop making that claim. Especially if you're inferring registers. You absolutely want to tell the process which signals it should use to "Wake up."

[Sal Ammoniac]

Furthermore, the assignments indicate what the values will be on the next clock cycle, not instantly. All of the "code" in the process block occurs in zero time in the simulation.

What clock are you referring to? This is combinatorial logic and there's no clock involved.