VHDL synthesis of registers - separate process for each register vs. one merged process - vhdl

Let's say I have two registers named reg_operand1 and reg_operand2. For both of them I have an appropriate write-enable signal. Somewhere I read I should have separate process for each register assignment, something like this:
process(CLK, RESET)
begin
if (RESET = '1') then
reg_operand1 <= (others => '0');
elsif (CLK'event and CLK = '1') then
if reg_operand1_we='1' then
reg_operand1 <= DI;
end if;
end if;
end process;
process(CLK, RESET)
begin
if (RESET = '1') then
reg_operand2 <= (others => '0');
elsif (CLK'event and CLK = '1') then
if reg_operand2_we='1' then
reg_operand2 <= DI;
end if;
end if;
end process;
But what happen if I merge the processes into this? Will the synthesized circuit be different? Also, what if I put "elsif" between the if-statements in merged process? Will the synthesizer insert a multiplexor into the circuit? Thanks!
process(CLK, RESET)
begin
if (RESET = '1') then
reg_operand1 <= (others => '0');
reg_operand2 <= (others => '0');
elsif (CLK'event and CLK = '1') then
if reg_operand1_we='1' then
reg_operand1 <= DI;
end if;
if reg_operand2_we='1' then
reg_operand2 <= DI;
end if;
end if;
end process;

The second one will produce exactly the same hardware as the first, and as already been said, contains less boilerplate.
If I understand your question about elsif correctly, you're proposing:
process(CLK, RESET)
begin
if (RESET = '1') then
reg_operand1 <= (others => '0');
reg_operand2 <= (others => '0');
elsif (CLK'event and CLK = '1') then
if reg_operand1_we='1' then
reg_operand1 <= DI;
elsif reg_operand2_we='1' then
reg_operand2 <= DI;
end if;
end if;
end process;
This generates different hardware, and also gives different behaviour.
In the example without the elsif, reg_operand2 is assigned DI when reg_operand2_we is high, irrespective of the state of reg_operand1_we.
When elsif is used, the assignment to of reg_operand2 only occurs when reg_operand2_we is high and reg_operand1_we is low
In general, if the two assignments do not depend on each other, use a seperate if construct.

The second one is shorter and simpler, and will generate the same hardware. (from a brief inspection : i.e. assuming there are no accidental typos in one or the other)
An elsif in the second version, combining the two register writes, will just prioritise the registers; i.e. if you attempt to write to both registers by asserting both we signals in the same cycle, only reg_operand1 will actually be written. It will have no other effect on the design.
So...
Unless you have specific corporate style guides that prohibit it, use the second style as a general rule.
There may be a FEW cases where you want to COMPLETELY separate some functionality to make it clear that it IS separate; in that case it's better not to be dogmatic about this style; but USUALLY fewer lines of code means less to go wrong, especially where (as here) it's easier to read and understand.
"I read somewhere" ... it would be worth knowing where you read this. There are a LOT of excruciatingly bad books, teaching materials and example projects out there, waiting to ruin potential VHDL programmers, and it's worth publicising which ones to avoid...

Related

VHDL - Inferred Latch With Reset - FSM

I have an issue with this process where if I include a reset statement, I get an inferred latch. However, if I do not include the reset statement, I do not get an inferred latch on duty_cycle_triangle.
SIGNAL duty_cycle_triangle : INTEGER := 0;
SIGNAL count_up : STD_LOGIC;
SIGNAL tick_zero : STD_LOGIC;
triangle_count: PROCESS(clk, reset signal, tick_zero)
BEGIN
IF (reset = '1') THEN
duty_cycle_triangle <= 0;
ELSIF (RISING_EDGE(clk)) THEN
IF (tick_zero = '1') THEN
IF (count_up = '1') THEN
duty_cycle_triangle <= duty_cycle_triangle + 2;
ELSE
duty_cycle_triangle <= duty_cycle_triangle - 2;
END IF;
END IF;
END IF;
END PROCESS;
I am trying to design an FSM that will output a triangle wave using a PWM and an FSM shown below:
FSM_comb: PROCESS(currentState, duty_cycle_triangle)
BEGIN
CASE currentState IS
WHEN triangle_up =>
PWM_enable <= '1';
count_up <= '1';
IF (duty_cycle_triangle > 99) THEN
nextState <= triangle_down;
ELSE
nextState <= triangle_up;
END IF;
WHEN triangle_down =>
PWM_enable <= '1';
count_up <= '0';
IF (duty_cycle_triangle < 1) THEN
nextState <= triangle_up;
ELSE
nextState <= triangle_down;
END IF;
END CASE;
END PROCESS;
FSM_seq: PROCESS(clk, reset)
BEGIN
IF (reset = '1') THEN
currentState <= triangle_up;
ELSIF (RISING_EDGE(clk)) THEN
currentState <= nextState;
END IF;
END PROCESS FSM_seq;
Basically, after every "tick" I want the duty cycle of the triangle wave to increase by 2. After the duty cycle reaches 100, I want the duty cycle to decrease by 2 until the duty cycle reaches 0. Once the duty cycle reaches 0, I want the duty cycle to start increasing from 0 again until it reaches 100 and it starts over.
Does anyone see any problems with my code or can anyone point me in the right direction to correcting any issues?
If you want to create a sequential process, only include a reset and a clock in your sensitivity list. I suspect that it's inferring the latch because you're including too many signals in this process:
triangle_count: PROCESS(clk, reset signal, tick_zero)
It should just be
triangle_count: PROCESS(reset, clk)
The tools don't see that as a sequential process and make it combinational and that's how you get your latch.
Without trying it out i'm wondering if when the reset statement is removed, the tool is recognising the process as a synchronous process and inferring registers. In this case you don't need to explicitly define duty_cycle_triangle for each outcome of the process as the value is stored in a register.
With the reset statement included it may be treating the process as combinatorial and therefore inferring latches to store the state of duty_cycle_triangle when it's not explicitly defined.
Either way I agree with Russell's suggestion of changing the process sensitivity list which should get rid of the latch.

During synthesis, should I care about the "found latch" warnings if I actually want the latches?

say I have the following state machine:
....
if state_a then
output_a <= '0';
next_state <= state_b;
elsif state_b then
output_a < '0';
if cond then
output_b <= '1';
next_state <= state_a;
else
next_state <= state_b;
end if;
end if;
......
I don't want output_b to change except when being assigned again in state_b. However, when I try to synthesise this code, most synthesis tools will say something along this line:
warning: found 1-bit latch for signal "output_b". latches aren't
recommended for FPGA design because it might result in timing
problems.
Should I worry about this at all? If so, why and what are the alternatives?
Following Xilinx:
If latch inference is intended, you can safely ignore this message. However, some inefficient coding styles can lead to accidental latch inference. You should analyse your code to see if this result is intended.
Some techniques to avoid latch inference:
Make sure any "if / else if" statements have a concluding "else" clause,
Assign to all the same outputs in each case,
Include all possible cases in the case statement (but be aware that WHEN OTHERS clause always works, but can create extraneous logic).
if you have incomplete if/elsif or case statement in a clocked process, it's absolutely harmless.
if rising_edge(clk)
if a then
out <= b;
end if;
end if;
It means that you have flip-flop with some sort of feedback, or, like in this case, you have flip-flop with clock enable pin used, which is even better.
If you have incomplete if/elsif or case statement in not clocked process - it's a latch and it's in most cases:
something you don't really want;
something that point out on a poor design and can be avoided with redesign.
If you complete your little example, someone can help you redesign it. Now it is not enough information.
The problem you have stems from the FSM coding style you're (presumably) using. As other pointed it is not possible to guess what you want the code to do, since you did not provide enough code to figure that out, so I present one possible interpretation, assuming you really wanted to change output_a somehow and that one time (after reset) latching of output_b should happen at the same time FSM state transitions.
Using 2 processes per FSM style, we have code that is not giving latch warnings:
----
signal CLK, RESET, cond : std_logic;
type state_t is (a,b);
signal state, state_next : state_t;
signal ouput_a, output_b, output_b_next : std_logic;
----
FSM_clock: process(all)
begin
if rising_edge(CLK) then
if RESET then
state <= a;
output_b <= '0';
else
state <= state_next;
output_b <= output_b_next;
end if;
end if;
end process;
FSM_next: process(all)
begin
state_next <= state;
output_b_next <= output_b;
output_a <= '0';
case state is
when a =>
state_next <= b;
when b =>
output_a <= '1';
if cond then
output_b_next <= '1';
state_next <= a;
else
state_next <= b;
end if;
end case;
end process;

Place and route timing strategy

This sounds very naive, but i would like your expert comments on the below pseudo-code. Which of the 2 methods below can achieve minimal place & route timing when implemented in hardware.
Method:1
control_proc: process(clk)
begin
if(clk'event and clk=='1') then
if sig_delay == 1 then
sig_ctrl <= '1';
else
sig_ctrl <= '0';
end if;
end if;
end process
delay_proc: process(clk)
begin
if(clk'event and clk=='1') then
if <some-condition> then
sig_delay <= '1';
else
sig_delay <= '0';
end if;
end if;
end process
Method:2
control_single_proc: process(clk)
begin
if(clk'event and clk=='1') then
if <some-condition> then
sig_delay <= '1';
else
sig_delay <= '0';
end if;
if sig_delay == 1 then
sig_ctrl <= '1';
else
sig_ctrl <= '0';
end if;
end if;
end process
Note:
sig_ctrl is used as a CE (chip enable) for another component in the hierarchy, which is kind of bit serialiser.
Your two methods are equivalent. Any good synthesis tool will be able to perform the same optimisations on both cases.
The sorts of things that might prevent a synthesis tool from optimising logically equivalent hardware are entity hierarchy / design partition boundaries, however most tools flatten the netlist before optimisation anyway.
Method 2 may perform marginally better in simulation since there are fewer processes to schedule.

Communication between processes in VHDL

I have problems on communicating between the processes. I used to use flag and clearFlag to tackle this, but it's kind of annoying and not looking good. What is the best practice to handle this? Here is a sample code on how I did it before:
Proc_A : process (clk, reset, clrFlag)
begin
if clrFlag = '1' then
flag <='0';
elsif reset = '0' then
A <= (others => '0');
elsif rising_edge (clk) then
A <= in;
flag <= '1';
end if;
end process;
Proc_B : process (clk, reset)
begin
if reset = '0' then
B <= (others => '0');
elsif rising_edge (clk) then
if flag = '1' then
B <= data;
clrFlag <= '1';
else
clrFlag <= '0';
end if;
end if;
end process;
This way works but I don't think it is nice method. I have to write a flag and clrFlag couple to do this task. All I want to do is when something happened (e.g. A <= in;), it triggers another proc, Proc_B for example, to run once or a number of times. What is the best practice to this problem? Thanks!
For simulation, you can make a process wait on a signal:
Proc_B : process
begin
wait until flag'event;
B <= data;
end process;
and just write the flag with its inverse every time you need something to happen.
In synthesisable logic, you either have to exchange flag signals, as you do, or use some other higher-level communication (like a FIFO, messagebox, or similar).
However, if all your proc_b logic takes place in a single cycle - so you can guarantee not to miss a flag, and to be able to keep up even if flag is asserted all the time (as it looks like you do) - you can do this (and combine the two processes):
Proc : process (clk, reset, clrFlag)
begin
flag <='0';
if reset = '0' then
A <= (others => '0');
B <= (others => '0');
elsif rising_edge (clk) then
if some_trigger_event = '1' then
A <= in;
flag <= '1';
end if;
-- recall that due to VHDL's scheduling rules, this "if" will take place
-- one clock cycle after the flag is written to, just as if it were in a
-- separate process
if flag = '1' then
B <= data;
end if;
end if;
end process;
Side note - your code is not ideal for synthesis... you really only want the reset part outside the clocked part:
Proc_A : process (clk, reset)
begin
if reset = '0' then
A <= (others => '0');
elsif rising_edge (clk) then
if clrFlag = '1' then
flag <='0';
else
A <= in;
flag <= '1';
end if;
end process;

VHDL - setting sampling rate for a sensor

Fellow SO users,
I'm trying to sample my resistive humidity sensor at a frequency of 5Hz (5 samples a second). I'm using an ADC to read the output. Now, I've been told that you can run the ADC at any frequency but you need to use a 5hz clock to initiate the conversion and read values from the ADC.
The way I'm doing this is by having a process that initiates the conversion by running at 5hz and having a flag, say "start_convert" to '1' on the rising edge of the clock.
PROCESS (CLK_5HZ)
BEGIN
IF (CLK_5HZ'EVENT AND CLK_5HZ = '1') THEN
START_CONVERT <= '1';
END IF;
END PROCESS;
And then I have a state machine for the ADC;
PROCESS (CURR_STATE, INTR)
BEGIN
CASE CURR_STATE IS
WHEN STARTUP =>
WR <= '0';
READ_DATA <= '0';
IF (START_CONVERT = '1') THEN
NEXT_STATE <= CONVERT;
ELSE
NEXT_STATE <= STARTUP;
END IF;
WHEN CONVERT =>
IF (INTR = '0' AND STREAM = '1') THEN
NEXT_STATE <= WAIT500;
ELSIF (INTR = '0' AND STREAM = '0') THEN
NEXT_STATE <= READ1;
ELSE
NEXT_STATE <= CONVERT;
END IF;
WR <= '1';
READ_DATA <= '0';
WHEN WAIT10 =>
IF (COUNTER_WAIT = 10) THEN
NEXT_STATE <= READ1;
ELSE
NEXT_STATE <= WAIT10;
END IF;
COUNTER_WAIT <= COUNTER_WAIT + 1;
WHEN READ1 =>
NEXT_STATE <= CONVERT;
WR <= '1';
READ_DATA <= '1';
WHEN OTHERS =>
NEXT_STATE <= STARTUP;
END CASE;
END PROCESS;
And then I'm using another process at 5hz to detect whenever READ_DATA is 1 so that I read the values from the ADC.
PROCESS (CLK_5HZ, RST)
BEGIN
IF (RST = '1') THEN
Y <= (OTHERS => '0');
ELSIF (CLK_5HZ'EVENT AND CLK_5HZ = '1') THEN
IF (READ_DATA = '1') THEN
Y <= DATA_IN (0) & DATA_IN (1) &
DATA_IN (2) & DATA_IN (3) &
DATA_IN (4) & DATA_IN (5) &
DATA_IN (6) & DATA_IN (7);
END IF;
END IF;
END PROCESS;
Could anyone please advice me whether this is the right approach or not?
EDIT: I'm interfacing the ADC (ADC0804) using a Spartan-3 board.
It's a bit hard to give specific advice, when not knowing the specifics of the device you are trying to interface to.
However, a couple of general comments regarding your code:
Your asynchronous process (the PROCESS (CURR_STATE, INTR)) will generate quite a few latches when synthesizing it, since you are not setting all your signals in all cases. WR and READ_DATA are for instance not being set in your WAIT10 state. This will most probably lead to severe timing issues, so correcting this is something you'd absolutely want to do.
The WAIT10 state in the same process will give you a combinatorial loop, as it runs whenever COUNTER_WAIT is updated. As that state also updates COUNTER_WAIT, it will in theory just keep running, but in practice most synthesizers will just give you an error (I think). You'll need to move the incrementing to a synchronous/clocked process instead, which will also give you control over how long each cycle takes.
Your 5 Hz processes seem to run on a separate clock (CLK_5HZ). I presume that the rest of your system is running at a faster clock? This essentially gives you two (or more) clock domains, that will need special interface logic for interfacing them with each other. A much, much better solution is to run everything on the same (fast) clock, and control slower processes using clock enables. Everything is thus inherently synchronized, and shouldn't give you any nasty timing surprises.

Resources