Assign multiple values to a signal during 1 process - for-loop

If you assign a value to a signal in a process, does it only become the correct value of the signal at the end of the process?
So there would be no point in assigning a value to a signal more than once per process, because the last assignment would be the only one that would be implemented, correct?
I'm a bit desperate because I'm trying to implement the booth algorithm in VHDL with signals and I can't get it baked. It wasn't a problem with variables, but signals make it all more difficult.
I tried a for loop, but that doesn't work because I have to update the values within the loop.
My next idea is a counter in the testbench.
Would be very thanksful for an idea!
my current Code look like this:
architecture behave of booth is
signal buffer_result1, buffer_result2, buffer_result3: std_logic_vector(7 downto 0) := "0000"&b;
signal s: std_logic:= '0';
signal count1, count2: integer:=0;
begin
assignment: process(counter) is
begin
if counter = "000" then
buffer_result1 <= "0000"&b;
end if;
end process;
add_sub: process(counter) is
begin
if counter <= "011" then
if(buffer_result1(0) = '1' and s = '0') then
buffer_result2 <= buffer_result1(7 downto 4)-a;
else if (buffer_result1(0) = '0' and s = '1') then
buffer_result2 <= buffer_result1(7 downto 4)+a;
end if;
end if;
end process;
shift:process(counter) is
begin
if counter <= "011"
buffer_result3(7) <= buffer_result2(7);
buffer_result3(6 downto 0) <= buffer_result2(7 downto 1);
s<= buffer_result3(0);
else
result<=buffer_result3;
end if;
end behave;

Short answer: that's correct. A signal's value will not update until the end of your process.
Long answer: A signal will only update when its assignment takes effect. Some signal assignments will use after and specify a time, making the transaction time explicit. Without an explicit time given, signals will update after the default "time-delta," an "instant" of simulation time that passes as soon as all concurrently executing statements at the given sim time have completed (e.g. a process). So your signals will hold their initial values until the process completes, at which point sim time moves forward one "delta," and the values update.
That does not mean that multiple signal assignment statements to the same signal don't accomplish anything in a process. VHDL will take note of all assignments, but of a series of assignments given with the same transaction time, only the last assignment will take effect. This can be used for a few tricky things, although I've encountered differences of opinion on how often they should be tried. For instance:
-- Assume I have a 'clk' coming in
signal pulse : std_ulogic;
signal counter : unsigned(2 downto 0);
pulse_on_wrap : process(clk) is
begin
clock : if rising_edge(clk):
pulse <= '0'; -- Default assignment to "pulse" is 0
counter <= counter + 1; -- Counter will increment each clock cycle
if counter = 2**3-1 then
pulse <= '1'; -- Pulse high when the counter drops to 0 (after this cycle)
end if;
end if clock;
end process pulse_on_wrap;
Here, the typical behavior is to assign the value '0' to pulse on each clock cycle. But if counter hits its max value, there will be a following assignment to pulse, which will set it to '1' once simulation time advances. Because it comes after the '0' assignment and also has a "delta" transaction delay, it will override the earlier assignment. So this process will cause the signal pulse, fittingly, to go high for one cycle each time the counter wraps to zero and then drop the next - it's a pulse, after all! :^)
I provide that example only to illustrate the potential benefit of multiple assignments within a process, as you mention that in your question. I do not advise trying anything fancy with assignments until you're clear on the difference between variable assignment and signal assignment - and how that needs to be reflected in your code!
Try to think of things in terms of simulation time and hardware when it comes to signals. Everything is static until time moves forward, then you can handle the new values. It's a learning curve, but it'll happen! ;^)

Related

VHDL finite state machine counter with start

i pretty new of vhdl and i'm trying to learn how to do a FSM with vhdl.
At moment i need a code that after a fixed count value, it give me back a pulse, in order to start a second FSM block. (I have a recurring signal every 100 kHz, i need to count it and release this signal after a fixed number of counts).
Actually it work as free run, every time that it see this signal, it start to count, but realy i want to add a "start" signal, so it must start to count this signal after it see this start signal.
at moment my working code is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;
entity counter is
Port (
signal_in : in STD_LOGIC := '0'; --segnale di start
clk : in STD_LOGIC; --clock di ingresso
reset : in STD_LOGIC; --ff reset
signal_out: out STD_LOGIC; --gate in uscita
count_val: in std_logic_vector (7 downto 0);
start : in STD_LOGIC := '0'
);
end counter;
architecture behavioral of counter is
type state_type is (idle, count_up);
signal state : state_type;
begin
process (reset, clk, signal_in, start)
variable index : integer :=0;
variable countlen: integer;
variable count_v: std_logic;
variable countlen2 : std_logic;
begin
countlen := to_integer(unsigned(count_val))-1;
if reset = '1' then
count_v := '0';
index := 0;
state <= idle;
else
--if start = '1' and
--if rising_edge(clk) then
if rising_edge(signal_in) then
case state is
when idle =>
count_v :='0';
index := 0;
if (signal_in = '1') then
state <= count_up;
else
state <= idle;
end if;
when count_up =>
if(index < countlen) then
state <=count_up;
index := index + 1;
elsif
index = countlen then
count_v := '1';
state <=idle;
end if;
when others => null;
end case;
end if;
end if;
signal_out <= count_v;
end process;
end Behavioral;
Any attempt to work with cose with "start = 1" will stop the count.
Please some one have some suggestion?
Kind REgards
Fulvio
Welcome om StackOverflow. Your specification is not 100% clear. What difference do you make between signal_in and start? According to your code and to your explanations, they both seem to act as a starter.
Moreover, there are several strange things with your code:
your process seems to be a synchronous one, with asynchronous reset. Its sensitivity list should contain only the clock and the reset. And its body should be:
process(clk, reset)
<variable declarations>
begin
<NOTHING HERE>
if reset = '1' then
<reset code>
elsif rising_edge(clk) then
<regular code>
end if;
<NOTHING HERE>
end process;
you are using signal_in as a clock and as a logic signal. This is extremely strange. Moreover, your if (signal_in = '1') then is always true (in the synthesis semantics) and thus useless.
You are initializing variables at declaration (index). This is not supported by some synthesizers and hardware targets. Moreover, even when supported, it works only at power up. If:
you intend to synthesize your code,
you want it to be portable across synthesizers and hardware targets,
you want to re-initialize signal and variables not only at power up but also when a reset input is asserted,
prefer a real explicit reset, instead, and guarantee that it is always asserted after power up (or at the beginning of a simulation) for proper first initialization.
you declare variable index with a full integer range, that is, 32 bits minimum, while 8 bits would suffice. This is a potential waste of hardware resources.
It is difficult to propose a solution without a clear and complete specification but assuming you want to count only after start has been asserted and only when signal_in is asserted, the following may be a starting point:
process (clk, reset)
variable index: natural range 0 to 255;
begin
if reset = '1' then
state <= idle;
signal_out <= '0';
index := 0;
elsif rising_edge(clk) then
case state is
when idle =>
signal_out <= '0';
index := 0;
if start = '1' then
state <= count_up;
end if;
when others =>
if signal_in = '1' then
if index = to_integer(unsigned(count_val)) - 1 then
state <= idle;
signal_out <= '1';
else
index := index + 1;
end if;
end if;
end case;
end if;
end process;
Note that this is really synchronous of your clock clk. I suspect that you made a very common mistake: as you wanted to increment your counter when signal_in is asserted you decided more or less to use signal_in as a clock. This is not a real synchronous and safe design. In a real safe synchronous design you do not use logic signals as clocks. You have well identified clocks and you use only these as clocks. In your case there is one single clock: clk. If you want to do something synchronously when a logic signal is asserted, wait for the rising edge of your clock and then test the logic signal and take appropriate actions.
thanks for your support.
Yes the point is that i need to "decimate" (or count) a signal.
This signal had a width of 50-100ns and it repeat itself with a frequency of 100 kHz.
so in my mind, this signal will go in to "signal in". My FPGA is an Actel proasic3 with a clock of 40 MHz.
In my setup this signal will be always on, but i don't want that my FSM will start to count as it see the first "signal in" but only when i send a "start" signal for the number of count that i indicate. (Realy they ask to me the possibility to decimate this signal up to 65000 count, so for sure i need to use a 16bit vector instead of 8bit).
The async reset is here "just in case" i need to reset the whole fsm in the middle of some data record.
Hope to be more clear now what this code should do.
For Old fart, yes indeed all my signal coming outside the fpga will be first synchronized with a simple 2 ff synchronizer with the FPGA clock

VHDL - converting from level sampling to edge triggered - an intuitive explanation?

I have the following code (a primitive "RS-232 signalling" transmitter)...
LIBRARY ieee;
USE ieee.std_logic_1164.all;
entity SerialTX is
port(
baud_clk : in std_logic;
data : in std_logic_vector(7 downto 0);
send : in std_logic;
serial_out : out std_logic := '0';
busy : out std_logic := '0'
);
end entity;
----------------------------------------
architecture behavioural of SerialTX is
constant IDLE_BITS : std_logic_vector(10 downto 0) := "00000000001";
signal shifter : std_logic_vector(10 downto 0) := IDLE_BITS;
signal shift : std_logic := '0';
signal internal_busy : std_logic := '0';
begin
-------- ALWAYS HAPPENING --------
serial_out <= shifter(0);
busy <= internal_busy;
internal_busy <= '1' when (shifter /= IDLE_BITS) else '0';
----------------------------------
shifting_handler:
process(baud_clk) is
begin
if rising_edge(baud_clk) then
if (send = '1') and (shifter = IDLE_BITS) then
shifter <= "11" & data & '0';
elsif (shifter /= IDLE_BITS) then
shifter <= '0' & shifter(10 downto 1); -- shifter >>= 1;
end if;
end if;
end process;
end architecture behavioural;
... it works well (in simulation) but has a limitation. The send signal (that causes a transmission to begin) has to be a '1' level for longer than at least one full cycle of the baud_clk in order for the transmitter to see it reliably.
I have been trying to find a way to convert this code so that it responds to the rising edge of the send signal instead of testing its level at the rising edge of baud_clk. I want to be able to respond to a send pulse less than 100ns in duration even when the baud_clk is running at a much slower rate (115200 hz for instance).
I've tried (naively) altering the process thus...
shifting_handler:
process(baud_clk) is
begin
if rising_edge(baud_clk) then
if (shifter /= IDLE_BITS) then
shifter <= '0' & shifter(10 downto 1); -- shifter >>= 1;
end if;
elsif rising_edge(send) and (shifter = IDLE_BITS) then
shifter <= "11" & data & '0';
end if;
end process;
Here I was hoping to change the logic to test for a rising edge on send when there isn't a rising edge on baud_clk.
I know that this is not a valid approach to the problem (the synthesizer moans of course) but I was hoping that someone could explain in simple terms why this cannot be done. What would happen if it was possible to use two edge detectors in a process? There is a concept here I cannot grasp and I always seem to end up writing the code in the same way and producing this problem. I'm fighting hard against years of ingrained software programming habits, which doesn't help much!
It sounds like send is asynchronous with respect to baud_clk. You therefore need to perform some form of clock domain crossing (CDC) in order to correctly implement your design, otherwise you will have a design that cannot pass timing and has the potential to not function correctly. CDC is a standard term that you should be able to find more information about in other questions, and elsewhere.
As you have found, you cannot have a design realised in real hardware if it has a process sensitive to edges on two different signals. There's no one 'right' way to do what you want, but here is one example that uses a simple 'toggle' CDC. This is very simple, but note that the design could miss sending a byte if one send request arrives before a previous byte has been transmitted. There will also be some delay introduced between assertion of the send signal, and the transmission starting. It's not clear if these issues matter in your system.
Create another process sensitive to send:
-- The initial state doesn't matter, but we want the design to work in simulation
signal send_toggle : std_logic := '0';
process(send)
begin
if (rising_edge(send)) then
send_toggle <= not send_toggle;
end if;
end process;
Now another process to synchronize this to the baud_clk domain. Use two cascaded registers to produce a design that is largely immune to any metastability (this is another standard term that you can look up) that can result from sampling a signal generated from a different clock domain:
signal send_toggle_r1 : std_logic;
signal send_toggle_r2 : std_logic;
process(baud_clk)
begin
if (rising_edge(baud_clk)) then
send_toggle_r1 <= send_toggle;
send_toggle_r2 <= send_toggle_r1;
end if;
end process;
The above is a very standard circuit block that you can use in many single-bit CDC scenarios.
Your transmit process can then register the send_toggle_r2 signal in order to look for a transition, in order to determine whether it should start sending. This signal is in the correct clock domain:
signal send_toggle_r3 : std_logic;
process(baud_clk) is
begin
if rising_edge(baud_clk) then
send_toggle_r3 <= send_toggle_r2;
if ((send_toggle_r3 /= send_toggle_r2) and (shifter = IDLE_BITS)) then
shifter <= "11" & data & '0';
elsif (shifter /= IDLE_BITS) then
shifter <= '0' & shifter(10 downto 1); -- shifter >>= 1;
end if;
end if;
end process;
Lastly, you will need to implement timing constraints to tell your tool chain not to worry about timing of the send_toggle_r1 register.
You might spot that if you are targeting hardware where the initial states of registers are random, you might get an erroneous byte transmission after the first few baud_clk cycles. To prevent this, you might choose to hold your baud_clk process in reset for some clock cycles after start up, but as I don't know if this is relevant for you, I won't detail this part.
This whole answer addresses your question directly, but my personal approach would be to use whatever higher-rate clock is generating your send signal to drive the entire design. The serial transmission would then in fact use the higher rate clock, with shifting enabled by a CDC > edge detector chain driven from the baud_clk. The bit timing would not be absolutely perfect, but this should not matter for a standard 'UART' scenario.

Write followed by Read in VHDL process

The following code is for a very simple program in VHDL.
entity ent is
port(
clk: in std_logic;
out_value: out std_logic;
);
end entity ent;
architecture ent_arch of ent is
signal counter: std_logic_vector(3 downto 0);
begin
process(clk)
begin
if rising_edge(clk) then
counter <= counter + 1;
if counter = 10 then
counter <= (others => '0') ;
end if;
end if;
end process;
end ent_arch;
Imagine counter = 9 and we enter in the if statement (if rising_edge(clk)). The first statement counter <= counter + 1 will assign 10 to counter. My question is "Is the if statetement (if counter = 10) evaluted as true in this entrance or in the next entrance of the process?". In other words "For this comparison in this entrance of the process, is counter = 10 due to the previous statement?"
Thanks a lot for any answer!
Signal assignments are always delayed. You didn't specified a delay explicitly using the after keyword, thus the assignment is delayed for one delta cycle (same as after 0 fs). That means, that the value of the expression on the right side of this statement:
counter <= counter + 1;
will be assigned to counter at the beginning of the next simulation cycle.
But, all remaining statements in your process, are executed in the current simulation cycle. Thus, this read of the counter value,
if counter = 10 then
will still use the old value, so that, the counter will be reseted when it is already 10 at the rising clock edge. The counter counts from 0 to 10 inclusive.
The delay of at least one delta cycle, easily allows to swap the content of registers:
-- within declarative part of architecture
signal reg_a, reg_b : std_logic;
-- within architecture body
process(clock)
begin
if rising_edge(clock) then
reg_a <= reg_b;
reg_b <= reg_a; -- assign old value of reg_a !
end if;
end process;

VHDL-PWM Weird Behavior and Physical Upper/Lower limitations

I am trying to generate picosecond PWM signal using the Spartan 3e board in VHDL (Xilinx ISE+ISim).
library ieee;
use ieee.std_logic_1164.all;
entity pwm is
port(clk : in std_logic;
pwm_out : buffer std_logic);
end entity;
architecture rtl of pwm is
begin
process (clk)
variable count : integer range 0 to 50000;
variable duty_cycle : integer range 0 to 50000;
variable flag : integer range 0 to 1;
begin
if (rising_edge(clk)) then
count := count+1;
if (count = duty_cycle) then
pwm_out <= '1';
end if;
if (count = 50000) then
pwm_out <= '0';
count := 0;
if(flag = 0) then
duty_cycle := duty_cycle+50;
else
duty_cycle := duty_cycle-50;
end if;
if(duty_cycle = 50000) then
flag := 1;
elsif(duty_cycle = 0) then
flag := 0;
end if;
end if;
end if;
end process;
end rtl;
I am using the embedded 50Mhz for the global clock (C9) but the simulation showed a weird behavior; from 0ps to 1000000ps clk (clock) and pwm_out (output) seems to be HIGH always and there is nothing after 1000000ps both for clk and pwm_out in time domain under ISim.
I am trying to do is to investigate and solve this behavior and then increase the frequency of output (pwm_out). Also I would like to learn about how fast (rise/fall times and in the frequency) can I generate the pulse (physical limitations).
I would appreciate some guidance from experienced users.
The pwm_out output has not initial value, so it has to be assigned in the process before it gets a well defined value. But the process variables (holding process state) all have an initial value of zero, and since count is incremented first thing in the process loop, count will not equal duty_cycle (being 0) at the beginning. So pwm_out is not assigned until it equals 50000, which (with a 50 MHz clock) happens at 50000 / 50 MHz = 1 ms.
However, if you synthesize this and run it in the FPGA, you may experience some unexpected behavior, depending on your clock source and control. For example, if the pwm module is running from a clock that is not stable right when the FPGA is loaded, for example an internal PLL clock, then the initial clock behavior may not adhere to the timing constraints applied to the design, and any value may end up in for example the duty_cycle variable (register). But, the design is based on the assumption that the duty_cycle register has a value of (50 * n), and otherwise it won't increment and decrement as anticipated due to the equal compare (=) with 0 and 50000. So if the duty_cycle get the value 1, due to initial timing violations as a result of an initial "invalid" clock, the flag variable (state) won't operate as expected, and so on. One way to amend this is to add a reset input and apply this to the variable state until the clock is stable, or use inequality operators for comparison.

Detecting the rising edge of an std_logic signal in VHDL

I have a flip flop which uses as clk input a signal which comes from the processing of to other signals. That means, that I'm not using the clock of the system neither an input. Thus, when I do:
architecture sampler_a of sampler_e is
signal S0_s : std_logic := '0';
begin
-- In my block this is not only a not. I put this to simplify things.
S0_s <= not(S0_i);
S0_o <= S0_s;
process(S0_i)
begin
--Also with rising edge does not work
if (S0_s'event and S0_s= '1') then
BitReady_o <= '1';
end if;
end process;
end sampler_a;
BitReady does not change in the simulation (in modelsim). Is the use of std_logic incorrect here?
Note that I don't want to generate a pulse that is a clock period's wide, because my circuit works in an asynchronous way.
The process is only sensitive to S0_i, but only tests for events on S0_s (which are never in the same delta cycle as S0_i events). Thus the process can never do anything.
Change its sensitivity list to S0_s and if ought to work.
However, as currently written, once BitReady_o becomes '1', there is no way to ever return it to '0'.

Resources