I synthesized my design with Xilinx ISE 13.1. Target device is Virtex 5. Then I encountered this warning:
WARNING:Xst:819 - "F:/FRONT-END/h264/inter/src/eei/eei_mvd.vhd"
line 539: One or more signals are missing in the process sensitivity list.
To enable synthesis of FPGA/CPLD hardware, XST will assume that all necessary signals are present in the sensitivity list.
Please note that the result of the synthesis may differ from the initial design specification. The missing signals are:
<mvd_l0<3><3>>, <mvd_l0<3><2>>, <mvd_l0<3><1>>, <mvd_l0<3><0>>, <mvd_l0<2><3>>, <mvd_l0<2><2>>,
<mvd_l0<2><1>>, <mvd_l0<2><0>>, <mvd_l0<1><3>>, <mvd_l0<1><2>>, <mvd_l0<1><1>>, <mvd_l0<1><0>>,
<mvd_l0<0><3>>, <mvd_l0<0><2>>, <mvd_l0<0><1>>, <mvd_l0<0><0>>, <mvd_l1<3><3>>, <mvd_l1<3><2>>,
<mvd_l1<3><1>>, <mvd_l1<3><0>>, <mvd_l1<2><3>>, <mvd_l1<2><2>>, <mvd_l1<2><1>>, <mvd_l1<2><0>>,
<mvd_l1<1><3>>, <mvd_l1<1><2>>, <mvd_l1<1><1>>, <mvd_l1<1><0>>, <mvd_l1<0><3>>, <mvd_l1<0><2>>,
<mvd_l1<0><1>>, <mvd_l1<0><0>>, <mvd<0>>, <mvd<1>>
Here is my source code:
proc_update_next: process(mvd_l0, mvd_l1, mvd, subMBPart_Idx, MBPart_Idx, eei_info )
begin
--// Init
next_mvd_l0 <= mvd_l0;
next_mvd_l1 <= mvd_l1;
--// Change
if eei_info.mb_type = BLK_8x8 then
for i in 3 downto 0 loop
for j in 3 downto 0 loop
if i = to_integer(unsigned(MBPart_Idx)) and j = to_integer(unsigned(subMBPart_Idx)) then
next_mvd_l0(i)(j) <= mvd(0);
next_mvd_l1(i)(j) <= mvd(1);
end if;
end loop;
end loop;
else
for i in 3 downto 0 loop
if i = to_integer(unsigned(MBPart_Idx)) then
next_mvd_l0(i)(0) <= mvd(0);
next_mvd_l1(i)(0) <= mvd(1);
end if;
end loop;
end if;
end process;
Update: I change a little bit in my code and still this warning.
The mvd_l0 and mvd_l1 is two-dimension array and it appeared on sensitivity list. I know my source code is too abstract and ISE may can not understand.
I tried with Virtex 7 (not avaiable in laboratory) then there are no error. So, my question is how to fix this warning ? I can't ignore this warning because it can lead to latch.
Use the VHDL-2008 construct process(all) to tell the tools you want the sensitivity list to include all signals which are read.
Alternatively, make it a clocked process, only sensitive to the clock, and then you don't have to worry either.
You should only set signals like next_mvd_l0 and next_mvd_l1 once for a set of conditions. The "init" section is still an issue. It may be better to use local variables if you are avoiding reseting the process.
Best option: add a reset to the sensitivity list and if its enabled, set next_mvd_* to your init values
--// Init
if (reset = '1') then
next_mvd_l0 <= mvd_l0;
next_mvd_l1 <= mvd_l1;
end if;
Second option: use a local variable
proc_update_next: process(mvd_l0, mvd_l1, mvd, subMBPart_Idx, MBPart_Idx, eei_info )
variable mvd_10_local : 2dArrayType;
variable mvd_11_local : 2dArrayType;
begin
--// Init
mvd_10_local := mvd_l0;
mvd_11_local := mvd_l1;
--// Change
if eei_info.mb_type = BLK_8x8 then
for i in 3 downto 0 loop
for j in 3 downto 0 loop
if i = to_integer(unsigned(MBPart_Idx)) and j = to_integer(unsigned(subMBPart_Idx)) then
mvd_10_local(i)(j) := mvd(0);
mvd_11_local(i)(j) := mvd(1);
end if;
end loop;
end loop;
else
for i in 3 downto 0 loop
if i = to_integer(unsigned(MBPart_Idx)) then
mvd_10_local(i)(j) := mvd(0);
mvd_11_local(i)(j) := mvd(1);
end if;
end loop;
end if;
next_mvd_l0 <= mvd_10_local;
next_mvd_l1 <= mvd_l1_local;
end process;
You use the VHDL record construct (eei_info.mb_type). You can add every record element to the sens-list to make xst happy. I just ignore this warning.
Related
I have a for loop in process, which works fine with std_logic arrays, but not with record arrays. I use Xilinx ISE along with ISIM and the code is vhdl-93. The target will be a Spartan 3.
Here is the record definition:
TYPE spi_rx_t IS RECORD
CS : std_logic;
MOSI : std_logic;
CLK : std_logic;
END RECORD;
constant SYNC_LATCHES : integer := 2;
Here is the array definition and declaration:
type spi_rx_array_t is array (0 to SYNC_LATCHES) of spi_rx_t;
signal spi_in_array : spi_rx_array_t;
Below is the process:
spi_in_array(0).MOSI <= SPI_MOSI;
spi_in_array(0).CLK <= SPI_CLK;
spi_in_array(0).CS <= SPI_CS;
sync_p: process (clk_100)
begin
if rising_edge(clk_100) then
-- for I in 1 to SYNC_LATCHES loop
-- spi_in_array(I) <= spi_in_array(I - 1);
-- end loop;
spi_in_array(1) <= spi_in_array(0);
spi_in_array(2) <= spi_in_array(1);
end if;
end process;
The 2 lines below the commented code works exactly as expected (allowing me to synchronize external signals to clk_100), but I'd rather implement them as a for loop (such the commented one).
However, these commented lines does not produce the same result in my ISIM test bench (spi_in_array stays in unknown state when using the for loop). Why?
Please kindly help me with this.
As commented by Morten Zilmer, this is due to the VHDL concept "longest static prefix". This SO answer is similar to my issue.
In my case, the simplest way to resolve the issue was to move the assignment of the first element of the array into the same process as the for loop. I also had to decrease SYNC_LATCHES constant from 2 to 1, because spi_in_array(0) is now latched with clk_100.
sync_p: process (clk_100)
begin
if rising_edge(clk_100) then
spi_in_array(0).MOSI <= SPI_MOSI;
spi_in_array(0).CLK <= SPI_CLK;
spi_in_array(0).CS <= SPI_CS;
for I in 1 to SYNC_LATCHES-1 loop
spi_in_array(I) <= spi_in_array(I - 1);
end loop;
end if;
end process;
Hi I'm trying to implement a mealy machine using VHDL, but I'll need to debounce the button press. My problem is I'm not sure where should I implement the debouncing. My current work is like this:
process(clk)
begin
if(clk' event and clk = '1') then
if rst = '1' then
curr_state <= state0;
else
curr_state <= next_state;
end if;
end if;
end process;
process(curr_state, op1,op0,rst) --here op1,op0 and rst are all physical buttons and I need to debounce op1 and op0
begin
if rst = '1' then
...some implementation
else
...implement the debounce logic first
...process some input
case curr_state is
when state0=>...implementation
...similar stuff
end case;
end process;
I'm not sure whether I'm doing in the right way or not. In the second process, should I put the rst processing like this, or should I put it inside when state0 block? Also, as the processing of debounce requires counting, do I put it outside the case block like this? Thank you!
I would use a completely separate block of code to debounce any button signals, allowing your state machine process to focus on just the state machine, without having to worry about anything else.
You could use a process like this to debounce the input. You could of course exchange variables for signals in this example (with associated assignment operator replacements).
process (clk)
constant DEBOUNCE_CLK_PERIODS : integer := 256; -- Or whatever provides enough debouncing
variable next_button_state : std_logic := '0'; -- Or whatever your 'unpressed' state is
variable debounce_count : integer range 0 to DEBOUNCE_CLK_PERIODS-1 := 0;
begin
if (rising_edge(clk)) then
if (bouncy_button_in /= next_button_state) then
next_button_state := bouncy_button_in;
debounce_count := 0;
else
if (debounce_count /= DEBOUNCE_CLK_PERIODS-1) then
debounce_count := debounce_count + 1;
else
debounced_button_out <= next_button_state;
end if;
end if;
end if;
end process;
Another option would be to sample the bouncy_button_in at a slow rate:
process (clk)
constant DEBOUNCE_CLK_DIVIDER : integer := 256;
variable debounce_count : integer range 0 to DEBOUNCE_CLK_DIVIDER-1 := 0;
begin
if (rising_edge(clk)) then
if (debounce_count /= DEBOUNCE_CLK_DIVIDER-1) then
debounce_count := debounce_count + 1;
else
debounce_count := 0;
debounced_button_out <= bouncy_button_in;
end if;
end if;
end process;
The advantage of the first method is that it will reject glitches in the input. In either case, you would use the debounced_button_out (or whatever you want to call it, perhaps rst) in your state machine, whose code then contains only the core state machine functionality.
If you wanted even more debouncing, you could use another counter to create an enable signal for the processes above, to effectively divide down the clock rate. This could be better than setting the division constant to a very high number, because you may not be able to meet timing if the counter gets beyond a certain size.
You could even create a debounce entity in a separate file, which could be instantiated for each button. It could have a generic for the constant in the above process.
There's also hardware debouncing, but I suppose that's outside the scope of this question.
In the second process, should I put the rst processing like this, or
should I put it inside when state0 block?
Only put it in the State0 block
Also, as the processing of
debounce requires counting, do I put it outside the case block like
this?
Counting needs to be done in a clocked process. Since you are doing a two process statemachine, you cannot do it in the case block. I typically put these sort of resources in a separate clocked process anyway.
For states, you need: IS_0, TO_1, IS_1, TO_0.
The TO_1 and TO_0 are your transition states. I transition from TO_1 to IS_1 when I see a 1 for 16 ms. I transition from TO_0 to IS_0 when I see a 0 for 16 ms. Run your counter when you are in the TO_1 or TO_0 state. Clear your counter when you are in the IS_1 or IS_0 state.
This should get you stated.
I'm getting an error during CheckSyntax for the following code I've tried. The error says:
"Line 48. parse error, unexpected VARIABLE Line 53. Undefined symbol 'InOutDetector'.
Line 57. InOutDetector: Undefined symbol (last report in this block)".
Can you let me know how should I fix this?
Here is an image of my code, as I could not paste it.
https://www.dropbox.com/s/ay8pjq4ojoep6ry/RoomLightController.png?dl=0
entity Room_Light_Controller is
port (
clk, sA, sB: IN STD_LOGIC;
sL: OUT STD_LOGIC
);
end Room_Light_Controller;
architecture Behavioral of Room_Light_Controller is
-- assuming sensors are variables sA and sB, and lights switch is sL
SIGNAL People : INTEGER:=0;
SIGNAL AllowNextCount : BIT:='0';
--unsigned int People=0; -- counter for people inside the room
--char AllowNextCount=0; -- boolean indicating if allowing next count or not
--short int InOutDetector; -- 1 = entering; -1 = exiting
begin
variable InOutDetectorDetector: integer;
process (clk)
begin
if ((sA = '0') and (sB = '1')) then
-- entering
InOutDetector := 1;
end if;
if ((sA = '1') and (sb = '0')) then
-- exiting
InOutDetector := -1;
end if;
if ((sA ='1') and (sB = '1') and (AllowNextCount = '1')) then
-- only when both sensors are touched validate the people counter
People := People+InOutDetector;
-- count once then block counting until the same person has finished entering/exiting
AllowNextCount <= '0';
end if;
if ((sA = '0') and (sB = '0')) then
-- it gets 0;0 only when someone has finished entering/exiting
-- pr at turn on; so now allow to counting again
AllowNextCount <= '1';
end if;
if (People > 0) then
sL <= '1'; -- Turn/keep lights on as long as People greater than 0
else
sL <= '0'; -- otherwise, turn them off
end if;
end process;
end Behavioral;
In addition to the error Amir notes that there is a name mismatch and the variable is declared in the wrong place, there is an additional error with the assignment to People:
library ieee;
use ieee.std_logic_1164.all;
entity Room_Light_Controller is
port (
clk, sA, sB: in std_logic;
sL: out std_logic
);
end entity Room_Light_Controller;
architecture Behavioral of Room_Light_Controller is
-- assuming sensors are variables sA and sB, and lights switch is sL
signal people: integer := 0;
signal allownextcount: bit := '0';
--unsigned int People=0; -- counter for people inside the room
--char AllowNextCount=0; -- boolean indicating if allowing next count or not
--short int InOutDetector; -- 1 = entering; -1 = exiting
begin
-- variable InOutDetectorDetector: integer;
process (clk)
variable InOutDetector: integer; -- as per Amir
begin
if sA = '0' and sB = '1' then
-- entering
InOutDetector := 1;
end if;
if sA = '1' and sb = '0' then
-- exiting
InOutDetector := -1;
end if;
if sA ='1' and sB = '1' and AllowNextCount = '1' then
-- only when both sensors are touched validate the people counter
People <= People + InOutDetector; -- was :=, signal assignment
-- count once then block counting until the same person has finished entering/exiting
AllowNextCount <= '0';
end if;
if sA = '0' and sB = '0' then
-- it gets 0;0 only when someone has finished entering/exiting
-- pr at turn on; so now allow to counting again
AllowNextCount <= '1';
end if;
if People > 0 then
sL <= '1'; -- Turn/keep lights on as long as People greater than 0
else
sL <= '0'; -- otherwise, turn them off
end if;
end process;
end architecture Behavioral;
People is a signal and requires the signal assignment symbol (<=) not the variable assignment symbol (:=).
After the two changes the VHDL design specification analyzes and elaborates.
Notice a context clause has been added to make your code a Minimal, Verifiable and Complete example.
Also note in the Help Center web page on Minimal, Complete, and Verifiable example the section Minimal and readable,
..Use consistent naming and indentation, and include comments if needed to explain portions of the code.
If this code were intended to be synthesize you might likely need to constrain the integers.
For execution efficiency all the independent if statements could be consolidated using elsif. That's hardly an issue in a small design, but the binary patterns described for sA and sB are mutually exclusive (while not exhaustive for type std_logic).
You neglected to provide the complete error messages, which appear to be output from XST. Historically the recommended design flow includes simulation, which if for no other purpose provides better syntax error messages from VHDL analysis.
XST historically assumes you are handing it a design description that is syntax error free, and is other wise quite sparse in providing adequate error messages.
The error message prefix (e.g. ERROR:HDLParsers:1209) can tell you how to find the problem via Xilinx's support site and/or documentation.
Declare the variable inside the process and rename it to (InOutDetector). You used (InOutDetector) inside the process.
Then if you want to run the process on clk rising edge, complete your process such as the following code :
process(clk)
variable InOutDetector : integer;
begin
if clk = '1' and clk'event then
-- your code
end if;
end process;
However if you don't want to use the clk rising edge, just complete the sensitivity list with parameters that you read or check it inside the process (sA,sB,AllowNextCount,People) and remove clk from the process sensitivity list.
Also be careful about incomplete if statements. Latches may be generated from incomplete case or if statements.
I'm working on a FIR filter, specifically the delay line. x_delayed is initialized to all zeros.
type slv32_array is array(natural range <>) of std_logic_vector(31 downto 0);
...
signal x_delayed : slv32_array(0 to NTAPS-1) := (others => (others => '0'));
This does not work:
x_delayed(0) <= x; -- Continuous assignment
DELAYS : process(samp_clk)
begin
if rising_edge(samp_clk) then
for i in 1 to NTAPS-1 loop
x_delayed(i) <= x_delayed(i-1);
end loop;
end if; -- rising_edge(samp_clk)
end process;
But this does:
DELAYS : process(samp_clk)
begin
if rising_edge(samp_clk) then
x_delayed(0) <= x; -- Registering input
for i in 1 to NTAPS-1 loop
x_delayed(i) <= x_delayed(i-1);
end loop;
end if; -- rising_edge(samp_clk)
end process;
The problem with this "solution" is that the first element in x_delayed is delayed by one sample, which it should not be. (The rest of the code expects x_delayed(0) to be the current sample).
I'm using Xilinx ISE 13.2, simulating with ISim, but this was also confirmed simulating with ModelSim.
What gives?
Edit:
The problem was essentially that, even though x_delayed(0) didn't appear to be driven inside the process, it was.
After implementing Brian Drummond's idea it works perfectly:
x_delayed(0) <= x;
-- Synchronous delay cycles.
DELAYS : process(samp_clk)
begin
-- Disable the clocked driver, allowing the continuous driver above to function correctly.
-- https://stackoverflow.com/questions/18247955/#comment26779546_18248941
x_delayed(0) <= (others => 'Z');
if rising_edge(samp_clk) then
for i in 1 to NTAPS-1 loop
x_delayed(i) <= x_delayed(i-1);
end loop;
end if; -- rising_edge(samp_clk)
end process;
Edit 2:
I took OllieB's suggestion for getting rid of the for loop. I had to change it, since my x_delayed is indexed from (0 to NTAPS-1), but we end up with this nice looking little process:
x_delayed(0) <= x;
DELAYS : process(samp_clk)
begin
x_delayed(0) <= (others => 'Z');
if rising_edge(samp_clk) then
x_delayed(1 to x_delayed'high) <= x_delayed(0 to x_delayed'high-1);
end if; -- rising_edge(samp_clk)
end process;
Edit 3:
Following OllieB's next suggestion, it turns out the x_delayed(0) <= (others => 'Z') was unnecessary, following his previous change. The following works just fine:
x_delayed(0) <= x;
DELAYS : process(samp_clk)
begin
if rising_edge(samp_clk) then
x_delayed(1 to x_delayed'high) <= x_delayed(0 to x_delayed'high-1);
end if;
end process;
In the first case, the x_delayed(0) actually has two drivers, out outside the
process, being x_delayed(0) <= x, and an implicit one inside the DELAY
process.
The driver inside the process is a consequence of a VHDL standard concept
called "longest static prefix", described in VHDL-2002 standard (IEEE Std
1076-2002) section "6.1 Names", and the loop construction with a loop variable
i, whereby the longest static prefix for x_delayed(i) is x_delayed.
The VHDL standard then further describes drives for processes in section
"12.6.1 Drivers", which says "... There is a single driver for a given scalar
signal S in a process statement, provided that there is at least one signal
assignment statement in that process statement and that the longest static
prefix of the target signal of that signal assignment statement denotes S ...".
So as a (probably surprising) consequence the x_delayed(0) has a driver in
the DELAY process, which drives all std_logic elements to 'U' since unassigned,
whereby the std_logic resolution function causes the resulting value to be 'U',
no matter what value is driven by the external x_delayed(0) <= x.
But in the case of your code, there seems to be more to it, since there actually are some "0" values in the simulation output for x_delayed(0), for what I can see from the figures. However, it is hard to dig further into this when I do not have the entire code.
One way to see that the loop is the reason, is to manually roll out the loop by
replacing the for ... loop with:
x_delayed(1) <= x_delayed(1-1);
x_delayed(2) <= x_delayed(2-1);
...
x_delayed(NTAPS) <= x_delayed(NTAPS-1);
This is of course not a usable solution for configurable modules with NTAPS as
a generic, but it may be interesting to see that the operation then is as
intuitively expected.
EDIT: Multiple solutions are listed in "edit" sections after the question above, based on comments. A solution with variable, which allows for complex expressions if required, is shown below. If complex expression is not required, then as per OllieB's suggestion it is possible to reduce the assign to x_delayed(1 to x_delayed_dir'high) <= x_delayed(0 to x_delayed_dir'high-1):
x_delayed(0) <= x;
DELAYS : process(samp_clk)
variable x_delayed_v : slv32_array(1 to NTAPS-1);
begin
if rising_edge(samp_clk) then
for i in 1 to NTAPS-1 loop
x_delayed_v(i) := x_delayed(i-1); -- More complex operations are also possible
end loop;
x_delayed(1 to x_delayed_dir'high) <= x_delayed_v;
end if; -- rising_edge(samp_clk)
end process;
During elaboration, drivers are created for all elements in x_delayed, regardless of the range of loop iterator. Hence, x_delayed(0) has two drivers associated with it. Std_Logic and Std_Logic_Vector are resoved types(i.e., when multiple drivers are associated with the signal with these types, the resolved function will determine the value of the signal by looking up a table in std package. Please refer to VHDL Coding Styles and Methodologies for more details.
the reason you have a problem is that the logic thinks you have two things assigning into the same signal simultaneously - both the continues assignment and the register assignment loop.
keep with the register implementation.
edit
if you have modelsim, you can use the 'trace x' option and see where it comes from.
might be that the other simulator also have this feature, but for modelsim i'm certain it works
In you not working example
x_delayed(0) <= x;
is aquvalent to
process(x)
begin
x_delayed(0) <= x;
end process;
So the process will assign x_delayed(0) only when x changes. Because this is a signal asignment the x_delayed(0) will not change immediatly, it will change after a delta cycle. Therefore, when process DELAYS is called assignment for x_delayed(0) is not happened yet!
Use a variable for x_delayed in your process, if you could.
x_delayed(0) := x;
I am beginner in VHDL programming and I am trying to synthesize the following vhdl code (software denouncing for a push button) using ISE project navigator 13.1
entity PBdebouncer is
Port ( PB : in STD_LOGIC;
CLK : in STD_LOGIC;
reset : in STD_LOGIC;
PBdebounced : out STD_LOGIC);
end PBdebouncer;
architecture Behavioral of PBdebouncer is
begin
p1: process(CLK , PB , reset)
variable enable,count : integer range 0 to 100000 := 0;
begin
if(reset = '1') then
count := 0;
enable :=0;
elsif(CLK' event and CLK = '1' ) then
if (enable = 1) then
count := count + 1;
end if;
if(count = 99999 ) then
if(PB = '0') then
PBdebounced <= '0';
else
PBdebounced <= '0';
end if;
count := 0;
enable := 0;
end if;
count := count;
else
enable := 1;
end if;
end process;
end Behavioral;
but unfortunately I am bumped with the following error:
ERROR:Xst:827 - ".../digital lab II 110/PBdebouncer/PBdebouncer.vhd" line 43: Signal enable cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release.
So could you please explain this error for me ?
Try it without the space between Clk' and event...
A few other questions :
why does "enable" have a range of 0 to 100000 when you only use two of those values? why not just use a boolean or std_logic?
is "pbdebounced" ever supposed to be set to anything other than '0'?
why the parentheses around the boolean expressions?
why is PB in the sensitivity list?
did it work as expected in simulation?
these will probably do for now...
EDIT : the bad formatting hid the problem:
begin
if reset = '1' then
count := 0;
enable :=0;
elsif rising_edge(clk) then
if enable = 1 then
count := count + 1;
end if;
if count = 99999 then
-- do stuff
end if;
count:= count;
-- else
-- enable := 1;
-- THE TWO LINES ABOVE are the problem
-- They are outside both the CLK and RESET clauses.
end if;
end process;
Just a small advice: Avoid variables as beginner.
They seem to work like in a software program, but they map sometimes to nasty things in hardware.
The cause of the problem seems to have been identified by Brians answer - but I'll just add a tip for these cases:
In Xilinx ISE you can view a number of language templates (select Edit -> Language templates), which can help you when implementing various styles of flip-flops (synchronous / asynchronous resets, rising / falling edge triggered and so on) and other constructs.
These can be really helpful - especially when getting error-messages like this, which are typically due to syntactically correct VHDL code that describes hardware that can't be synthesized in the selected device.