UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
7,951 Views
Registered: ‎01-22-2015

VHDL signal-vs-variable for timing analysis

Jump to solution

For helping VHDL code pass timing analysis, do you generally recommend using signals or variables?

 

Verilog users:  please provide the equivalent question (and answer).

 

The internet has many discussions about VHDL "signals vs variables", but most focus on implications for synthesis or simulation and not for timing analysis.

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
13,794 Views
Registered: ‎01-23-2009

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Do you find that you must teach HDL coding differently to programmers and digital hardware engineers? 

 

Yes, this is definitely true. Software is inherently sequential - you describe an algorithm... "Do this, then do this, then do this".

 

Conversely, hardware is inherently parallel; you need to be able to visualize the parallel operations that are essential for efficient FPGA design.

 

So, yes, the thought processes are quite different. The syntax of Verilog looks a lot like the syntax of C, but what you are trying to accomplish and therefore how you should code it are inherently different. And, yes, it is hard to make this transition - particularly for a highly skilled software designer that has been almost instinctively writing code to maximize execution efficiency.

 

but, I’ve been staring at schematics of my synthesized HDL code for most of a day and am getting nothing (in the way of improving timing analysis for the code).

 

So here is the key point (similar to what I was trying to say above). "Coding style" (and that is a bit of a nebulous term) may have very little to do with improving timing. The timing is determined by the architecture - where the flip-flops are, what transfers are done between them, how many pipeline stages are used to implement a portion of the design, how many operations or iterations will be done in parallel... By my definition, these are not "coding style" things, but architecture things. You need to visualize the architecture and then use RTL to represent the desired architecture.

 

If your architecture inherently cannot meet timing - i.e. you are trying to accomplish too much "transfer" logic in a single clock cycle, then the "coding style" you use to describe this architecture will have no (or little) effect. The only thing that will matter is changing the architecture (adding a pipeline stage, doing more operations in parallel, moving some work to the clock cycle before, or the clock cycle after).

 

(And, no, hardware designers are not extinct - Endangered, perhaps, but not extinct...)

 

Avrum

Tags (1)
9 Replies
Historian
Historian
7,936 Views
Registered: ‎01-23-2009

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

The question really doesn't make any sense...

 

Signals and variables are language constructs that you use in order to describe the functionality of hardware that you want the synthesis tool to implement (and that you want a simulator to simulate). Once the description of the hardware (RTL code) is synthesized, the concept of a signal or variable no longer exists - you have an interconnection of logic cells that were inferred by the synthesis tool to match the behavior of what you described in RTL. The timing of this resulting netlist is what it is - whether a signal or variable was used in the original RTL will not affect the timing.

 

I am not a VHDL expert, but one of the main differences between signal and variables is how they are assigned - variables are assigned procedurally, whereas signals infer a one "delta-cycle" delay on the assignment. This delta-cycle delay is what allows for the description of concurrency in your RTL (allowing for order independence of different processes that are sensitive to the same event [i.e. clock]). So, in general, one always uses signals in RTL.

 

Avrum

0 Kudos
7,927 Views
Registered: ‎01-22-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Avrum - thanks for your reply.

 

Perhaps a better way to ask my question is:

Which VHDL coding style, "using mostly signals" or "using mostly variables", generally makes it easier to meet timing requirements?

 

In my VHDL reading, the selection between these coding styles seems to be one of personal preference.  -but, I feel this is not a proper answer.

 

The VHDL-variable concept of "being updated immediately" is a sharp contrast to the VHDL-signal concept of being updated "after a delta cycle delay".  Coming from a C-programming background, I am more comfortable working with variables, but always kinda felt they were the wrong way to do things in VHDL/FPGA work.  That is, variables "being updated immediately" does not seem to fit with the RTL concept of clocking data from register to register  - nor does it seem to fit with the timing analysis concepts of setup and hold. 

 

Getting back to the coding style concept, I have seen pipelining done in VHDL only with signals.  If variables cannot be used to pipeline in VHDL (please check me on this), then this is a proper reason to adopt the "using mostly signals" style.

 

Does my rephrased question clarify or prompt any more comments?

0 Kudos
Scholar u4223374
Scholar
7,910 Views
Registered: ‎04-26-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Variables make it very easy to write very complex combinational code; you can end up with long combinational paths (which will fail timing) without really realising it. Signals make that harder, so you're less likely to hit timing problems.

 

However, avoiding variables because poor coding with them can result in timing problems is like avoiding C (and sticking with x86 assembly code) because poor coding in C can occupy more memory than the computer has available - while just using a large amount of RAM is difficult in assembly. You're much better-off just using the easiest technique (which will be a mix of combinational and sequential code, using variables) and paying attention to the limitations.

0 Kudos
7,878 Views
Registered: ‎01-22-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Thanks u4224474 - yours was the type of answer I wanted.

 

After a few days of testing, I can confirm that the choice (by itself) of using a VHDL-signal or VHDL-variable has little effect on timing analysis.  As you say, choose what makes you comfortable since you are then more likely to write good code instead of bad code - which has a big effect on timing analysis.

 

-back to the RTL/Synthesis viewpoint:

Are you saying that VHDL-variables synthesize to (unclocked) combinational logic placed in the timing paths traveled by VHDL-signals?

 

Why do you say,  "...fail timing) without really realising it"?

0 Kudos
Highlighted
Historian
Historian
7,867 Views
Registered: ‎01-23-2009

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

As is often the case, I start with the statement "think hardware"...

 

Synchronous digital logic consists of two things - networks of combinatorial gates (implementing boolean logic) and flip-flops. Using conventional synthesis (not HLS), both Verilog and VHDL are used to write Register Transfer Language (RTL) code.

 

In RTL code, you are explicitly defining the registers (or flip-flops); these are "things" in Verilog/VHDL that are given a value in a clocked process that is used outside the clocked process. The only "rule" in Verilog VHDL is

  - you must use signals in VHDL for your registers

  - you must use non-blocking assignments in Verilog for your registers

 

All the rest of your code is the "transfers" between these registers. These are combinatorial networks that implement the transfers from one state to the next. These will be implemented as networks of combinatorial gates. The depth and complexity of this network of combinatorial gates determines how hard or easy it is to meet timing during synthesis, place and route (using Static Timing Analysis as the mechanism to measure timing).

 

How you code this network of combinatorial gates is completely irrelevant to static timing analysis. Both Verilog and VHDL give you several different syntaxes to represent these networks of combinatorial gates:

  - Verilog

      - expressions on the right hand side (RHS) of the non-blocking assignment (NBA) of a reg in a clocked process

      - expressions using blocking assignments to a reg in a clocked process that are only used inside the same process (hence only end up affecting the reg that uses the NBA to model the register)

      - expressions using blocking or non blocking assignments (blocking is preferred) in a non-clocked process "always @(*)"

      - continuous assignments to nets

      - (and probably a few others like functions and sub-modules, and ....)

  - VHDL

      - expressions on the (RHS) of the assignment to a signal in a clocked process

      - expressions using variables in a clocked process that are only used in that process

      - expressions using variables or signals (variables are preferred) in a non-clocked process

      - assignments to signals that are not in any processes

      - (and probably a few others like functions and sub-modules, and ....)

 

The way you choose to represent these networks of gates is irrelevant - only the final structure of the network matters.

 

As long as you always "think hardware" all of these are the same.

 

The only thing that might be true is that if you do not "think hardware" it can be easier to create very deep and complex combinatorial networks using complex procedures using variables in non-clocked processes. But I would argue that it isn't the fact that you are using variables that is the problem, but that you did not "think hardware".

 

Avrum

Tags (2)
Scholar u4223374
Scholar
7,827 Views
Registered: ‎04-26-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

markg@prosensing.com

 

I'm honestly not 100% sure about variables and combinational logic in VHDL. In Verilog it's a (very strong) convention that the variable-equivalent (ie blocking assignment) is used for combinational logic, and signal-equivalent (ie non-blocking assignment) is used for sequential (clocked) logic. In VHDL I don't know whether it's actually a formal rule or a convention. Either way, better to behave like it is a rule - I know that ISE would normally tolerate beginners using blocking assignment (variables) all over the place, but that's a very good way to confuse both yourself and the tools.

 

With regards to not realising that you're going to fail timing: with signals in a sequential/clocked logic block, the input path to a register is essentially limited by how much code you can fit on a line. You can't make it depend on intermediate results that were generated in the same clock cycle, because assignment to a signal is effectively delayed by one clock cycle (so it has to depend on results that were generated in the previous cycle).The only intermediate results you can use are those that you get on the same line; for example (using Verilog because I'm more familiar with this)

 

x <= (a + b) * (c + d) + (e + f);

In this case there are intermediate results in the form of (a + b), (c + d), and (e + f) which are generated in this clock cycle, but not many of them.

 

You cannot do this:

x0 <= (a + b);
x1 <= (c + d);
x2 <= (e + f);
x <= x0 * x1 * x2;

In this case "x" would take the product of the old values of x0, x1, and x2; and those registers would get new values. It's still possible to generate immense paths (eg. by using the "/" operator, which Vivado will correctly implement as a combinational divider) but in general it's obvious when you're doing that.

 

With variables, you can just act like you're working in C. You can have a page of nice, neat code with 200 variables defined and used, and forget that actually all those operations are going to happen simultaneously - because the tool will figure out how to build hardware that acts as though the operations happened sequentially. However, when you go to build that, what you find is that the tools have had to connect 200 variables over several hundred lines of complex operations to get down to a single result at the end - which is obviously going to have a pretty substantial delay.

 

An example might be a combinational divider done in ISE (which does not correctly implement the "/" operator). You cannot, realistically, implement a combinational divider using just signals - because to do it in a single cycle with signals you have to do the whole lot in a single line of code, because intermediate variables can't be defined.

 

You can easily implement a combinational divider using variables in a combinational block. Lots of intermediate variables, simulation works fine, and the algorithm works fine in C. However, in hardware you find that there are 30+ levels of multiplexers and subtractors, with a huge delay. Having intermediate variables available makes this sort of poor coding very easy.

7,821 Views
Registered: ‎01-22-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Avrum:

Your “think hardware” discussion is the first that has really made sense to me. Many thanks!

 

I have no doubt that “think hardware” is the proper approach to HDL (H=hardware) programming – and is an approach that makes perfect sense to a digital hardware engineer (aren’t they extinct?).   –but, I’ve been staring at schematics of my synthesized HDL code for most of a day and am getting nothing (in the way of improving timing analysis for the code).

 

In the C-programming world (my background), we strive for “efficient code” – something that is definitely more art than science and that probably makes little sense to a digital hardware engineer. Coming at my HDL timing analysis problem from this “think (efficient) software” point of view has been more successful than my attempts to “think hardware”. That is, improved timing analysis results from writing efficient code (akin to what u4223374 said) –and, of course, from using the FPGA’s parallel processing capability.

 

Do you find that you must teach HDL coding differently to programmers and digital hardware engineers?  

 

Can you recommend reading for me on the "think hardware" approach?

 

---

u4223374:

I am guilty of overusing variables and getting huge delays that cause my code to fail timing. –but I have learned from my mistakes and from clear and patient people like you and Avrum who take the time to talk with me. Thanks for your awesome contributions to this post.

 

--

People of the “think software” persuasion:

I know you’re out there.   Back me up here!   Give me some HDL “think software” rules to live by.

0 Kudos
Historian
Historian
13,795 Views
Registered: ‎01-23-2009

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

Do you find that you must teach HDL coding differently to programmers and digital hardware engineers? 

 

Yes, this is definitely true. Software is inherently sequential - you describe an algorithm... "Do this, then do this, then do this".

 

Conversely, hardware is inherently parallel; you need to be able to visualize the parallel operations that are essential for efficient FPGA design.

 

So, yes, the thought processes are quite different. The syntax of Verilog looks a lot like the syntax of C, but what you are trying to accomplish and therefore how you should code it are inherently different. And, yes, it is hard to make this transition - particularly for a highly skilled software designer that has been almost instinctively writing code to maximize execution efficiency.

 

but, I’ve been staring at schematics of my synthesized HDL code for most of a day and am getting nothing (in the way of improving timing analysis for the code).

 

So here is the key point (similar to what I was trying to say above). "Coding style" (and that is a bit of a nebulous term) may have very little to do with improving timing. The timing is determined by the architecture - where the flip-flops are, what transfers are done between them, how many pipeline stages are used to implement a portion of the design, how many operations or iterations will be done in parallel... By my definition, these are not "coding style" things, but architecture things. You need to visualize the architecture and then use RTL to represent the desired architecture.

 

If your architecture inherently cannot meet timing - i.e. you are trying to accomplish too much "transfer" logic in a single clock cycle, then the "coding style" you use to describe this architecture will have no (or little) effect. The only thing that will matter is changing the architecture (adding a pipeline stage, doing more operations in parallel, moving some work to the clock cycle before, or the clock cycle after).

 

(And, no, hardware designers are not extinct - Endangered, perhaps, but not extinct...)

 

Avrum

Tags (1)
7,771 Views
Registered: ‎01-22-2015

Re: VHDL signal-vs-variable for timing analysis

Jump to solution

If your architecture inherently cannot meet timing ....... The only thing that will matter is changing

the architecture (adding a pipeline stage, doing more operations in parallel, moving some work

to the clock cycle before, or the clock cycle after).

 

HDL programming advice I can live by (and now understand). 

 

Many thanks Avrum and u4223374 !

 

0 Kudos