i am beginner in VHDL and i need do login terminal. For example i have fixed password 7010. I need implement only funcionality of automat. I want to have defined one signal, that will hold count of keys presses and will be incremented each time.
But i dont know how to initialize signal and incerement it, because when i initialize signal in one process, i cant increment its value in other process. If i dont intialize that signal, then my code not work and i dont know why. For example doSomething will not be runned if i dont that signal to "0000". But i need incerement its value in doSomething... Sry for my bad english.
if(mySignal = "0000")
doSomething
What you are trying to do sounds like a class assignment.
Break the problem down.
Draw a block diagram of what you want
In synthisisable VHDL you are correct in saying, unless the signal can be high Z, multiple drivers are not allowed. But there is nothing to stop you taking a copy of the signal and using that in another process.
Make use of unsigned types for counters or any signal that has magnitude, it makes life much easier
doSomething:process(clk,mySignal
begin
if rising_Edge(clk) then
if mySignal = "0000" then
count<=count+1;
end if;
end if;
end process;
Related
I am doing a project in VHDL and I am stuck at this point. Any help is appreciated.
The problem is described as follows:
I have a 2D array with N (in number) std_logic_vector signals. The number N is defined in generics, so we do not know the specific length of the array (we use N instead).
This array is used as sensitivity list of a process in order to trigger it. Like so: process(arrayOfSignals)
My question is: Is there any way to know which specific signal of the array triggered the process? (Like for example the signal: arrayOfSignals(2))
I have seen this post: Which signal in the sensitivity list triggers the process but it is not the case here. It would be the case if all the signals of their sensitivity list where inside an array, and this array was triggering the process.
To become clear, below is the VHDL code of what I am trying to do.
process(arrayOfSignals)
begin
for i in 0 to N-1 loop
if arrayOfSignals(i)'transaction'event then --I want to determine which signal of arrayOfSignals (position in the array) triggerd the process.
case arrayOfSignals(i) is
when "01" =>
AD(i)(30 downto 23) <= AD(i)(7 downto 0);
exit;
when others => null; exit;
end case;
exit;
end if;
end loop;
end process;
I don't know how to do exactly what you are asking. But let me suggest a way to do what I think you are trying to do.
Typically if you want to detect a change in a signal, you would have a clocked process and make a registered copy of the signal. You can then compare the state of your input signal with your registered copy (for each element) and if they are not equal, the input has changed and you can trigger your logic.
I am trying to clean up my VHDL code. I have a signal that is NOT a clk.
Can I write an event change monitor like the following and how do I get it to compile so it can be synthesized? (see code) I have tried several permutations but I cannot get it to compile. Will signal'event compile if signal is not a CLK and if so, how is it done? I see on the web and other literature that it can be done but all examples I see show CLK'event.
signal cntr: unsigned(15 downto 0) := (others => '0');
...
process(CLK):
begin
IF rising_edge(CLK) THEN
if (cntr'event) then
do something;
end if;
or...
if(cntr(0)'event) then
do something;
end if;
END IF;
end process;
I get the following and others
: can't synthesize condition that contains an isolated 'EVENT predefined attribute
rising_edge(CLK) is already an event, making your design synchronous, which is good. As said in comments, only clock signals should use that.
Looking at another even at that time doesn't make sense in synchronous designs, as the 2 signals won't change exactly at the same time, creating a race condition. Or actually a clock within a clock, and the synthesis error...
It may work in simulation, but don't rely on that fact.
The normal way to program in HDL languages is to save the previous value of the signal, on the same clock (for example cntr_d <= cntr) and to compare with that previous value. That allows to find if the signal went up (previously at 0, currently at 1), went down, changed (is different)...
And that method is perfectly fine for synthesis!
I am trying to make a new design. I design it with two processes which are synchronous and asynchronous. I generally give reset in the asynchronous process which is shown first code snippet. However, someone just told me that is a mistake. In her knowledge, I should give the reset statement in the synchronous process. I also checked the schematic for the first one and saw it is connected correctly to flip-flop's resets.
sync_proc : process(clk_i)
begin
if(rising_edge(clk_i)) then
do smt..
end if;
end process sync_proc;
async_proc : process(some signals)
begin
if(reset_i = '1') then
reset smt..
else
do smt..
end if;
end process sync_proc;
Above is my code and below is what she suggested.
sync_proc : process(clk_i)
begin
if(reset_i = '1') then
reset smt..
else(rising_edge(clk_i)) then
do smt..
end if;
end process sync_proc;
I am wondering that, is there any differences between these states? If so, what are they?
Think of a VHDL process as a little bit of software that models a little bit of hardware. With your approach, you have two little bits of hardware driving the same signal, ie a short circuit. With her (correct) approach, you have one little bit of hardware (a flip-flop) driving one signal.
I am new to VHDL and am trying to understand how reset operates - specifically within the Xilinx Spartan6. I've looked over this site and others, a white paper or two, but my questions do not seem to be addressed (so I fear the issue is so basic that all is assumed!)
Anyway, I inherited some example code and have made significant changes to it and succeeded in getting some decent functionality but the use of reset mystifies me.
The code looks like this:
architecture Behavioral of BigProject is
...
signal reset : std_logic := 0;
...
begin
...
reset <= '0';
...
process(clk_1MHz, reset) is
begin
if reset = '1' then
foo_flag <= '0';
fsm_a <= FSM_FIRST_STATE;
elsif rising_edge(clk_1MHz) then
case fsm_a is
when FSM_FIRST_STATE =>
<do stuff>
when FSM_SECOND_STATE =>
<do other stuff>
when others =>
null;
end case;
end if;
end process;
What does my use of reset actually accomplish?
Thanks.
With respect to the Xilinx tools, initial values on signals are honored for power-on state. For example:
signal a : std_logic := '0';
signal b : std_logic := '1';
Signal a will have a power-on reset value of '0', and signal b will have a power-on reset value of '1'.
Now, this is generally NOT the case for ASIC's, and is not the case for Microsemi parts.
Also, it is highly recommended that you limit the resets to only those bits that actually need to be reset. For example, if you have a data path that does math operations on some data in a pipeline, do you need to reset the data itself? Resets have a cost in terms of logic (depending on the logic library, it may require a multiplexer), routing (the reset has to get everywhere it is necessary), and can be complex when releasing reset.
So, limit your resets as much as possible. If an external reset is not necessary, don't use one. And if it is required, limit it's use to essential bits.
Your reset actually accomplishes nothing ;) In your code the reset is tied to '0' and thus your clocked process is always in reset state.
Usually the reset signal is an input port. So someone outside of your module asserts the reset for clock cycle or more and then releases it. After that all your registers are (or should be) in knowns states and your design is ready to do what ever it does.
edit: sorry, the reset is active high, so the tie-0 in for your reset actually makes sure that the clocked process is not reset. Ever. So every time your design starts from unknown state. That would be the red x's you see in the simulation waveform.
signal reset : std_logic := ***'0'***;
In your code the reset is tied to '0' and thus your clocked process is always in reset state.
#Jarno: That's not correct. For a synthesized module for Altera this doesn't matter ... even if there would be a 1 for the reset.
If you synthesize the code you will see that the synthesizer ignores that value. Maybe you even get a warning that the init value is ignored.
[http://quartushelp.altera.com/14.0/mergedProjects/msgs/msgs/wvrfx2_vhdl_warning_initial_value_for_signal_is_ignored.htm][1]
PS: Sorry, I am not allowed to write comments, yet.
A lot of the FSMs I see in VHDL work by setting a variable "next_state" in the FSM logic and then assign this seperately to the state variable outside of the process.
If there anything wrong with simply writing "state <= state_five;" to set the next state instead?
I'm presuming there is a reason that so many people use a separate next state variable instead of directly assigning to the state as I see it all the time, but as far as I can tell there is no difference except that it makes the code longer and more complicated looking.
Have I missed something? Or is it just a question of style? And if so why is that style better, it seems unnecessary to me.
"Is there anything wrong with simply writing state <= state_five;?"
Nothing whatsoever - PROVIDED the state assignment is done in a clocked process.
This leads to the neat simple reliable "single process state machine" style, instead of the unreliable (because it's easy to get the sensitivity lists wrong) two-process style that is taught in WAY too many textbooks and online tutorials.
Search for "single process state machine" and you should be able to find good example material and further discussion.
Historical note : there may have been some synthesis tools in the previous century that had problems with the single-process style; but that's no reason to avoid it now.
The reason why some people always write two-process state machines (that is, one synchronous process and one concurrent process) is probably mostly because they learned to do it that way in school, like others have said.
However, in some cases this coding style can actually be better than having a single synchronous process. In short it allows you to mix synchronous and concurrent assignments in the same context. Consider the following two pieces of code, both accomplishing the same thing:
Two-process state machine:
process (clk)
begin
if rising_edge(clk) then
state <= state_next;
end if;
end process;
process (all)
begin
state_next <= state;
case state is
when s_idle =>
if req_i = '1' then
fifo_read <= '1'; -- Concurrent assignment
state_next <= s_check_data; -- "Synchronous" assignment
end if;
when s_check_data =>
if fifo_out = x"1234" then
(...)
end if;
(...)
end case;
end process;
One-process state machine:
process (clk)
begin
if rising_edge(clk) then
case state is
when s_idle =>
if req_i = '1' then
fifo_read <= '1';
state <= s_wait_for_data;
end if;
when s_wait_for_data =>
state <= s_check_data;
when s_check_data =>
-- Data word from FIFO now available.
if fifo_out = x"1234" then
(...)
end if;
(...)
end case;
end if;
end process;
Notice the extra state in the second example. Because there is no way to make concurrent assignments in synchronous processes in VHDL (I wish there was!), a register will be added to the fifo_read signal, delaying it by one cycle. While this example is simple enough, always sticking to one-process state machines can sometimes cause the code to become quite confusing and hard to follow for this reason. It can also cause your state machine to spend more resources in hardware and even make the code longer. Neither style is always the right choice, but I usually prefer the one-process variant.
Or even use a variable:
state := state_five
Using a variable to store the state means that it remains completely local to the process and doesn't pollute the namespace of the whole architecture.
It also means that if you are in the habit of using printf (sorry report) to track the progress of state machines when debugging (which is sometimes preferable to a waveform viewer), you can report the intended next state at the end of the state machine process, which can be handy.
Added:
As noted in the comments, the variable assignment occurs "instantly" (to be clear - this doesn't cause the case statement to immediately switch to the next state though!)
This effect can be used to advantage (occasionally) if you need an output a cycle early - by assigning to said signal based on the next state at the end of the process. If I end up needing to do that I tend to have an explicit next_state variable which I use for everything except the case statement and the state := next_state; (which is right at the end of the clocked process). It demonstrates to the code reviewers that you intended to do it this way!