VHDL: issues with adding and subtracting -

what issues run code? thinking there issue if result addition bigger 15 bits can represent (32767), or if negative number in subtraction.

library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.std_logic_arith.all; use ieee.numeric_std.all;  entity test     port(   input:  in std_logic_vector(14 downto 0);             sel : out boolean;             output: out std_logic_vector(14 downto 0)); end test;   architecture test of test  constant first : integer := 1050; constant second : integer := 33611;  begin   output <= input - first;  output <= input + second;  sel <= input < first;  end test; 

the primary issue have design intent not communicated impossible distinguish correct incorrect results - in sense, whatever must right!

i differ david's opinion in 1 respect : says "std_logic_vector unsigned representation" suggest std_logic_vector neither signed nor unsigned; bag of bits. if happens follow unsigned rules, that's accident of set of libraries have included.

instead, delete non-standard libraries:

use ieee.std_logic_unsigned.all; use ieee.std_logic_arith.all; 

and use exclusively standard libraries:

library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; 

then - if input , output ports meant represent unsigned numbers, best thing so...

port(   input  : in unsigned(14 downto 0);         sel    : out boolean;         output : out unsigned(14 downto 0)); 

(if not allowed change port types, can use unsigned signals internally, , type convert between them , ports.)

now regards expressions, may overflow (and in case of "second" will!).

in simulation, these overflows ought reported arithmetic errors. (note : @ least 1 simulator runs overflow checks off default setting! dumb...)

as designer, decide correct semantics overflows are:

• they represent bugs. simulate overflow checks enabled, detect , fix bugs.
• they permitted, , e.g. negative numbers represent large positive numbers. express in code, e.g. output <= (input - first) mod 2**output'length; reading code understands overflow allowed, , wraps.
• overflow should saturate positive or negative limit. signal writing output <= saturate(input - first); i'll leave writing saturate function exercise...