Wired-OR does not get synthesized - vhdl

I want to have two combinational processes driving one signal in wired-or style. Each process can drive 'Z' or '1' value to the signal and there is a global pull-down to 'L'.
Vivado 2017.1 synthesis 'optimizes' my code to drive a constant 0 to the output port. Why does this happen? How do I work around this issue?
Code:
library ieee;
use ieee.std_logic_1164.all;
entity test is
port(
input_0 : in std_logic;
input_1 : in std_logic;
output : out std_logic
);
end entity test;
architecture rtl of test is
signal s_output : std_logic;
begin
output <= to_X01(to_bit(s_output));
process(input_0)
begin
s_output <= 'Z';
if input_0='1' then
s_output <= '1';
end if;
end process;
process(input_1)
begin
s_output <= 'Z';
if input_1='1' then
s_output <= '1';
end if;
end process;
s_output <= 'L';
end architecture rtl;
Synthesis result:
WARNING: [Synth 8-3917] design test has port output driven by constant 0

Related

VHDL - Adding/Removing Pipeline Register with Generics

Let's assume I have two processes PROC_A and PROC_B, and they share a signal between them. Let me write a dummy example:
library ieee;
use ieee.std_logic_1164.all;
entity example is
port (
clk : in std_logic;
rst_n : in std_logic;
a : in std_logic;
b : in std_logic;
c : in std_logic;
z_out : out std_logic);
end entity example;
architecture rtl of example is
signal a_and_b : std_logic;
signal ab_xor_c : std_logic;
begin -- architecture rtl
z_out <= ab_xor_c;
PROC_A : process (clk, rst_n) is
begin -- process PROC_A
if rst_n = '0' then -- asynchronous reset (active low)
a_and_b <= '0';
elsif rising_edge(clk) then -- rising clock edge
a_and_b <= a and b;
end if;
end process PROC_A;
PROC_B : process (clk, rst_n) is
begin -- process PROC_B
if rst_n = '0' then -- asynchronous reset (active low)
ab_xor_c <= '0';
elsif rising_edge(clk) then -- rising clock edge
ab_xor_c <= a_and_b xor c;
end if;
end process PROC_B;
end architecture rtl;
Now, I want to have a pipeline register between a_and_b and ab_xor_c signals, and I want to hardcode it but also enable/disable it with ease. I really want something like a ifdef in C/C++. I could think of a generic to do that but I am also open to any other method (maybe with pragmas?). I am writing an example below, I know that it is so wrong in terms of VHDL but just see it as an idea:
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic (
PIPELINE_EN : std_logic := '1');
port (
clk : in std_logic;
rst_n : in std_logic;
a : in std_logic;
b : in std_logic;
c : in std_logic;
z_out : out std_logic);
end entity example;
architecture rtl of example is
signal a_and_b : std_logic;
signal ab_xor_c : std_logic;
if PIPELINE_EN = '1' then
signal pipeline_reg : std_logic;
end if;
begin -- architecture rtl
z_out <= ab_xor_c;
PROC_A : process (clk, rst_n) is
begin -- process PROC_A
if rst_n = '0' then -- asynchronous reset (active low)
a_and_b <= '0';
elsif rising_edge(clk) then -- rising clock edge
a_and_b <= a and b;
end if;
end process PROC_A;
PROC_B : process (clk, rst_n) is
begin -- process PROC_B
if rst_n = '0' then -- asynchronous reset (active low)
ab_xor_c <= '0';
if PIPELINE_EN = '1' then
pipeline_reg <= '0'
end if;
elsif rising_edge(clk) then -- rising clock edge
if PIPELINE_EN = '1' then
pipeline_reg <= a_and_b;
ab_xor_c <= pipeline_reg xor c;
else
ab_xor_c <= a_and_b xor c;
end if;
end if;
end process PROC_B;
end architecture rtl;
Your example has been modified to removed the register from process A and show a generic controlling the presence of the register. Additional pipeline registers could be added generically as well.
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic ( PIPELINED: BOOLEAN := TRUE);
port (
clk: in std_logic;
rst_n: in std_logic;
a: in std_logic;
b: in std_logic;
c: in std_logic;
z_out: out std_logic
);
end entity example;
architecture genericly_pipelined of example is
signal a_and_b: std_logic;
signal ab_xor_c: std_logic;
begin
NO_PIPELINE:
if not PIPELINED generate
PROC_A:
process (a, b) is
begin
a_and_b <= a and b; -- could be a concurrent statement instead
end process;
end generate;
GEN_PIPELINED:
if PIPELINED generate
PIPELINED_PROC_A:
process (clk, rst_n) is
begin
if rst_n = '0' then
a_and_b <= '0';
elsif rising_edge(clk) then
a_and_b <= a and b;
end if;
end process;
end generate;
PROC_B:
process (clk, rst_n) is
begin
if rst_n = '0' then
ab_xor_c <= '0';
elsif rising_edge(clk) then
ab_xor_c <= a_and_b xor c;
end if;
end process;
end architecture genericly_pipelined;
The granularity using a generate statement is to a concurrent statement. For purposes of changing signal names you can declare intermediary signals in the block statement elaborated by the generate statement's block declarative region. Generate statements can be nested (it's a concurrent statement) which can be used to add more pipeline registers.
A generate statement body can have a block declarative part prior to any concurrent statements in the block statement body. Concurrent statements are delineated by the reserved words begin and end followed by a semicolon when any declarations are present in the block declarative part. E.g. IEEE Std 10786-2008:
11.8 Generate statements
if_generate_statement ::=
    generate_label :
        if [ alternative_label : ] condition generate
            generate_statement_body
        { elsif [ alternative_label : ] condition generate
            generate_statement_body }
        [ else [ alternative_label : ] generate
            generate_statement_body ]
    end generate [ generate_label ] ;
generate_statement_body ::=
        [ block_declarative_part
    begin ]
        { concurrent_statement }
    [ end [ alternative_label ] ; ]
The generate statements in the above VHDL code have no declarations. Braces { } enclosing the item concurrent_statement indicate you can use the 'long form' with the begin and end reserved words with zero or more concurrent statements. You'd declare any intermediary signals used to communicate between statements found in different generate statements in the same design hierarchy. (The block statement elaborated by a generate statement is a separate declarative region.)
The BNF found in the standard's numbered sections is normative.
Note you didn't assign z_out.
Here's an example compatible with the OP's code:
library ieee;
use ieee.std_logic_1164.all;
entity example1 is
generic ( PIPELINES: natural := 1);
port (
clk: in std_logic;
rst_n: in std_logic;
a: in std_logic;
b: in std_logic;
c: in std_logic;
z_out: out std_logic
);
end entity example1;
architecture generic_pipeline_stages of example1 is
signal a_and_b: std_logic;
signal ab_xor_c: std_logic;
begin
NO_PIPELINE:
if PIPELINES = 0 generate
PROC_A:
process (a, b) is
begin
a_and_b <= a and b; -- could be a concurrent statement instead
end process;
end generate;
GEN_PIPELINED:
if PIPELINES > 0 generate
type pipeline is array (0 to PIPELINES - 1) of std_logic;
signal pipeline_reg: pipeline;
begin
PIPELINED_PROC_A:
process (clk, rst_n) is
begin
if rst_n = '0' then
pipeline_reg <= (others => '0');
elsif rising_edge(clk) then
for i in pipeline'range loop
if i = 0 then
pipeline_reg(i) <= a and b;
else
pipeline_reg(i) <= pipeline_reg(i - 1);
end if;
end loop;
end if;
end process;
a_and_b <= pipeline_reg(PIPELINES - 1); -- a separate process
end generate;
PROC_B:
process (clk, rst_n) is
begin
if rst_n = '0' then
ab_xor_c <= '0';
elsif rising_edge(clk) then
ab_xor_c <= a_and_b xor c;
end if;
end process;
end architecture generic_pipeline_stages;
which produces:
And shows the two clock delays using natural generic PIPELINES.
With PIPELINES = 1:
The signals a_and_b and a_xor_b show up one clock earlier. It's compatible with the first VHDL example in this answer with PIPELINED = TRUE.
Note the block declarative part contains a composite signal declaration for the pipeline stages. A generate statement is it's own declarative region which means pipeline_reg wouldn't be visible outside the elaborated block. To access intermediary pipeline stages you'd either move the pipeline_reg declaration to the top level (example1, here) or assign signals declared in the top level assigned in the generate statement.
Principles in the design you wrote are fine, except for the if PIPELINE_EN = '1' then part in the declaration of pipeline_reg, which should be skipped, since the synthesis will then just remove the unused pipeline_reg. Also I would suggest that PIPELINE_EN is declared as type boolean instead, since that is a more obvious choice, and the = '1' can then be skipped in the conditions.
If for some reason you want to avoid declaration of the pipeline signal 'pipeline_reg' in the actual design, then you can declare a variable in the process, with code like below. It is required to assign the variable after use in the code, to get a flip-flop, since it otherwise just becomes combinatorial logic. However, such creation of flip-flops through use of variables is advised against, since it is hard to read and get right, thus error prone, and should be avoided in general. Though here it comes:
PROC_B : process (clk, rst_n) is
variable pipeline_reg_v : std_logic; -- Results in pipeline register if PIPELINE_EN, otherwise removed by synthesis
begin -- process PROC_B
if rst_n = '0' then -- asynchronous reset (active low)
ab_xor_c <= '0';
if PIPELINE_EN then
pipeline_reg_v := '0';
end if;
elsif rising_edge(clk) then -- rising clock edge
if PIPELINE_EN then
ab_xor_c <= pipeline_reg_v xor c;
pipeline_reg_v := a_and_b;
else
ab_xor_c <= a_and_b xor c;
end if;
end if;
end process PROC_B;
An alternative is to use the VHDL block construction, together with generate, whereby you can have signal declarations that are local to the block, as shown below. Though note that the block construction is rarely used in VHDL, thus there is a higher risk of encountering bugs in tools.
PIPELINE_EN_TRUE_GENERATE : if PIPELINE_EN generate
PIPELINE_EN_TRUE_BLOCK : block
signal pipeline_reg : std_logic;
begin
PROC_B : process (clk, rst_n) is
begin -- process PROC_B
if rst_n = '0' then -- asynchronous reset (active low)
ab_xor_c <= '0';
pipeline_reg <= '0';
elsif rising_edge(clk) then -- rising clock edge
pipeline_reg <= a_and_b;
ab_xor_c <= pipeline_reg xor c;
end if;
end process PROC_B;
end block PIPELINE_EN_TRUE_BLOCK;
end generate PIPELINE_EN_TRUE_GENERATE;
PIPELINE_EN_FALSE_GENERATE : if not PIPELINE_EN generate
PROC_B : process (clk, rst_n) is
begin -- process PROC_B
if rst_n = '0' then -- asynchronous reset (active low)
ab_xor_c <= '0';
elsif rising_edge(clk) then -- rising clock edge
ab_xor_c <= a_and_b xor c;
end if;
end process PROC_B;
end generate PIPELINE_EN_FALSE_GENERATE;
With a generic parameter for the pipeline depth:
library ieee;
use ieee.std_logic_1164.all;
entity example is
generic(
depth: natural := 0
);
port(
clk: in std_logic;
rst_n: in std_logic;
a: in std_logic;
b: in std_logic;
c: in std_logic;
z_out: out std_logic
);
end entity example;
architecture rtl of example is
signal a_and_b: std_logic;
signal ab_xor_c: std_logic_vector(0 to depth);
begin
z_out <= ab_xor_c(depth);
process(clk, rst_n) is
begin
if rst_n = '0' then
a_and_b <= '0';
ab_xor_c <= (others => '0');
elsif rising_edge(clk) then
a_and_b <= a and b;
ab_xor_c <= ab_xor_c srl 1;
ab_xor_c(0) <= a_and_b xor c;
end if;
end process;
end architecture rtl;
And then, with depth=2:
use std.env.all;
library ieee;
use ieee.std_logic_1164.all;
entity example_sim is
end entity example_sim;
architecture sim of example_sim is
signal clk: std_logic;
signal rst_n: std_logic;
signal a: std_logic;
signal b: std_logic;
signal c: std_logic;
signal z_out: std_logic;
begin
u0: entity work.example(rtl)
generic map(
depth => 2
)
port map(
clk => clk,
rst_n => rst_n,
a => a,
b => b,
c => c,
z_out => z_out
);
process
begin
clk <= '0';
wait for 1 ns;
clk <= '1';
wait for 1 ns;
end process;
process
begin
rst_n <= '0';
a <= '1';
b <= '1';
c <= '1';
wait until rising_edge(clk);
rst_n <= '1';
for i in 1 to 15 loop
wait until rising_edge(clk);
c <= not c;
end loop;
finish;
end process;
end architecture sim;
Demo:
$ ghdl -a --std=08 example_sim.vhd
$ ghdl -r --std=08 example_sim --vcd=example_sim.vcd
simulation finished #21ns
$ open example_sim.vcd
Of course, if your data type (T) is more complex than a single std_logic you will need some extra work.
Define a vector type of your data type (T_vector).
Define a "zero" constant value for your base type (T_zero), this will be the value that enters on the left when shifting to the right.
Overload the srl operator for the T_vector vector type.
Example with a T type (not tested):
type T_vector is array(natural range <>) of T;
constant T_zero: T := <some zero value for your type>;
...
function "srl"(l: T_vector; r: natural) return T_vector is
constant size: positive := l'length;
constant tmp: T_vector(0 to size - 1) := l;
variable res: T_vector(0 to size - 1);
begin
if r = 0 then
res := tmp;
elsif r = 1 then
res := T_zero & tmp(0 to size - 2);
else
res := (l srl 1) srl (r - 1);
end if;
return res;
end function "srl";

Vivado: Mismatch between behavioral simulation and post-synthesis functional simulation

I have a strange problem in Vivado. The goal is to initialize spi for an adc with the Xilinx Artix-100T FPGA in VHDL. But, there is a mismatch between the behavioral simulation and post-synthesis functional simulation in Vivado 2021.1.
In the behavioral simulation, the signal reset_n is 0 for one clock cycle and then rises to 1 (as it should). But, in the post-synthesis functional simulation, it is always 0. Is there any explanation for this? I also tried synthesis attributes like KEEP, DONT_TOUCH, but with no luck.
I reduced the whole logic to a few lines of code to show the part where this happens.
The Main file:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity Main is
port(
clock : IN STD_LOGIC; --system clock;
res : out std_logic := '0';
reset_done : out std_logic := '0');
signal init_done :boolean := false;
-- signal res : std_logic := '0';
end Main;
architecture Behavioral of Main is
begin
test: process is
begin
if (reset_done = '0') then
res <= '0';
wait until rising_edge(clock);
res <= '1';
reset_done <= '1';
else
wait until rising_edge(clock);
end if;
end process test;
end Behavioral;
The test bench file:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity Main_tb is
end Main_tb;
architecture Behavioral of Main_tb is
component Main is
port(
clock : IN STD_LOGIC;
res : out std_logic := '0';
reset_done : out std_logic := '0');
end component;
--signals
signal clock : std_logic := '1';
signal res :std_logic := '0';
signal reset_done : std_logic := '0';
begin
simulation: Main
port map (clock, res, reset_done);
--100 MHz clock
clk_stimulus: process
begin
wait for 5 ns;
clock <= not clock;
end process clk_stimulus;
end Behavioral;
Behavioral simulation:
Post-synthesis functional simulation:
New working code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity Main is
port(
clock : IN STD_LOGIC; --system clock;
res : out std_logic := '0'; --init signal
reset_done : out std_logic := '0'); --init signal
end Main;
architecture Behavioral of Main is
begin
test: process(clock) is
begin
if (rising_edge(clock)) then -- preferred syntax
res <= '1';
reset_done <= '1';
end if;
end process test;
end Behavioral;
A mismatch means that the synthesizer could not infer the correct logic form your VHDL description: the synthesis doesn't understand the entirety of VHDL. You have to program it in a specific way, as described in the HDL coding guidelines.
That's the whole reason we do post-synthesis simulation: to verify that the synthesizer understood our code.
Due to signal initialization, power-on-reset is rarely needed in good designs.
Anyhow, if you strip your code down to the core, it says:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity Main is
port(
clock : in std_logic;
res : out std_logic;
reset_done : out std_logic);
end Main;
architecture Behavioral of Main is
signal i_res : std_logic := '0'; -- initialize
signal i_reset_done : std_logic := '0';
begin
test: process(clk) is
begin
if (rising_edge(clk)) then -- preferred syntax
i_res <= i_reset_done;
i_reset_done <= '1'; -- set once.
end if;
end process test;
res <= i_res;
reset_done <= i_reset_done;
end Behavioral;
I don't get why reset_done has to be asserted one clock before res, but anyhow.
You could also infer a shift-register to realize a multi-clock cycle reset.

VHDL found '0' definition of operator “=”

I am getting this error in my VHDL code :
found '0' definitions of operator "=", cannot determine exact
overloaded matching definition for "="
Here is my code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
entity test2 is
Port (clk : in std_logic ;
sclk : out std_logic);
end test2;
architecture Behavioral of test2 is
signal cnt : std_logic_vector(2 downto 0):=(others=>'0');
begin
process(clk)
begin
if rising_edge(clk) then
if cnt(2) = "111" then
sclk <= clk ;
else
cnt <= cnt+1;
end if;
end if;
end process;
end Behavioral;
Where exactly is the problem?
the "cnt" is 3bit signal like (bit2,bi1,bit0). When you write cnt(2) it will mean cnt(bit2), however you compared it with "111".

I’m new to coding in VHDL and don’t understand why my code will not show an output when simulating on a VWF file

My code will not simulate an output when running the VWF file.
I have tried changing the code several different time and don't really understand what I'm doing wrong.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity Counter_JM is
Port (
up_down : in std_logic;
LED : out std_logic;
Q : Buffer integer Range 0 to 7);
end Counter_JM;
architecture archi of Counter_JM is
Begin
-- up/down counter
process (up_down)
begin
if (Q=7) then
Q<=0;
end if;
if (up_down = '1') then
Q <= Q + 1;
else
Q<=0;
end if;
if (Q=0 or Q=1) then
LED <= '0';
else
LED <= '1';
end if;
end process;
end archi;
The LED output should show high for 4 cycles and low for 2 on the VWF file
I don't know why you use up_down. But as Oldfart said, you don't have a clock. I have simplified and modified your code (it works for me (in modelsim):
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity Counter_JM is
Port (
clk: in std_logic;
up_down : in std_logic;
LED : out std_logic
);
end Counter_JM;
architecture archi of Counter_JM is
Begin
process (clk)
variable Q: integer range 0 to 7;
begin
if rising_edge(clk) then
-- up/down counter
Q := Q + 1;
if Q=1 or Q=2 then
LED <= '0';
else
LED <= '1';
end if;
if Q = 7 then
Q := 0;
end if;
end if;
end process;
end archi;
and also created/generated a simple testbench here :
`-- Testbench automatically generated online
-- at http://vhdl.lapinoo.net
-- Generation date : 7.6.2019 11:22:53 GMT
library ieee;
use ieee.std_logic_1164.all;
entity tb_Counter_JM is
end tb_Counter_JM;
architecture tb of tb_Counter_JM is
component Counter_JM
port (clk : in std_logic;
up_down : in std_logic;
LED : out std_logic);
end component;
signal clk : std_logic;
signal up_down : std_logic;
signal LED : std_logic;
constant TbPeriod : time := 1000 ns; -- EDIT Put right period here
signal TbClock : std_logic := '0';
signal TbSimEnded : std_logic := '0';
begin
dut : Counter_JM
port map (clk => clk,
up_down => up_down,
LED => LED);
-- Clock generation
TbClock <= not TbClock after TbPeriod/2 when TbSimEnded /= '1' else '0';
-- EDIT: Check that clk is really your main clock signal
clk <= TbClock;
stimuli : process
begin
-- EDIT Adapt initialization as needed
up_down <= '0';
-- EDIT Add stimuli here
wait for 100 * TbPeriod;
-- Stop the clock and hence terminate the simulation
TbSimEnded <= '1';
wait;
end process;
end tb;
-- Configuration block below is required by some simulators. Usually no need to edit.
configuration cfg_tb_Counter_JM of tb_Counter_JM is
for tb
end for;
end cfg_tb_Counter_JM;`

digital circuit scheme to vhdl ring counter multiplexer

I have this circuit that I want to implement in vhdl. There is a clock input and which clock event changes the 1 pin output sequentially. 0001 -> 0010 -> 0100 -> 1000 ...
I wondering what is the correct approach to do that. I could do that with multiple ifs and elsifs and an integer counter signal. Sorry for the noob question, is there a name for this kind of circuit?
It appears from your description this intended to be a ring counter. Your gates seem superfluous:
library ieee;
use ieee.std_logic_1164.all;
entity ring_counter is
port (
clk: in std_logic;
q: out std_logic_vector (0 to 3)
);
end entity;
architecture your_representation of ring_counter is
signal qint: std_logic_vector (0 to 3) := "0000";
signal all_zero: std_logic;
begin
YOURS:
process(clk)
begin
if rising_edge(clk) then
qint(0) <= qint(3);
qint(1) <= all_zero or qint(0);
qint (2 to 3) <= qint(1 to 2);
end if;
end process;
all_zero <= '1' when qint = "0000" else
'0';
q <= (qint(0) or all_zero) & qint(1 to 3);
end architecture;
With a test bench:
library ieee;
use ieee.std_logic_1164.all;
entity ring_counter_tb is
end entity;
architecture foo of ring_counter_tb is
signal clk: std_logic := '0';
signal q: std_logic_vector(0 to 3);
begin
DUT:
entity work.ring_counter(your_representation)
port map (
clk => clk,
q => q
);
CLOCK:
process
begin
wait for 10 ns;
clk <= not clk;
if Now > 200 ns then
wait;
end if;
end process;
end architecture;
Gives:
(clickable)
While a classic ring counter:
architecture classic of ring_counter is
signal qint: std_logic_vector (0 to 3) := "1000";
begin
RING_CTR:
process(clk)
begin
if rising_edge(clk) then
qint <= qint(3) & qint(0 to 2);
end if;
end process;
q <= qint;
end architecture;
(and modified test bench):
entity work.ring_counter(classic)
gives:
(clickable)
And the starting phase is all in the initial condition.

Resources