«нарушение ограничения диапазона» ошибка при попытке смоделировать схему в VHDL

Question

Я новичок в VHDL и я пытаюсь моделировать блок следующим образом:

1. Он имеет четыре std_logic_vector входа имени a, b , c и d. Входы a и b обозначены номерами и входами c и d являются неподписанные номера.
2. Он имеет четыре выхода с именем u, v, w и x. Выходы u и v - это номера и выходы с подписью w и x - это номера без знака.

3. Выходы определяются следующим образом:

   = а + Ь

   V = а/2

   ш = с * D

   х = с * 2

4. Внутренние сигналы являются целыми числами.

Я могу скомпилировать как модуль, так и стенд. У меня есть проблема в том, что, когда я пытаюсь моделировать схемы выводится следующее сообщение об ошибке:

ncsim: *E,TRRANGEC: range constraint violation. 
      File: ./operator2.vhd, line = 38, pos = 36 
     Scope: :inst_operator:$PROCESS_007 
      Time: 0 FS + 0 

Как следствие, симулятор не запускается. Я не понимаю, как эта линия может быть неправильно:

x <= std_logic_vector(to_unsigned(sx, 17)); 

Я попытался, изменив эту строку с другими те, которые делают то же самое, и я получаю ошибку в одной и той же линии. Если я удалю эту строку, ошибка сообщается в строке 37. Не могли бы вы дать мне подсказку, чтобы узнать мою ошибку? Ниже приведен код для модуля:

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

entity operator2 is 
    port(
     a: in std_logic_vector(15 downto 0); 
     b: in std_logic_vector(15 downto 0); 
     c: in std_logic_vector(15 downto 0); 
     d: in std_logic_vector(15 downto 0); 
     u: out std_logic_vector(16 downto 0); 
     v: out std_logic_vector(14 downto 0); 
     w: out std_logic_vector(31 downto 0); 
     x: out std_logic_vector(16 downto 0) 
    ); 

end entity operator2; 

architecture a2 of operator2 is 

    signal su: integer; 
    signal sv: integer; 
    signal sw: integer; 
    signal sx: integer; 

begin 

    --signals affectation 
    su <= to_integer(signed(a)) + to_integer(signed(b)); 
    sv <= to_integer(signed(a))/2; 
    sw <= to_integer(unsigned(c)) * to_integer(unsigned(d)); 
    sx <= to_integer(unsigned(c)) * 2; 

    --outputs affectation 
    u <= std_logic_vector(to_signed(su, 17)); 
    v <= std_logic_vector(to_signed(sv, 15)); 
    w <= std_logic_vector(to_unsigned(sw, 32)); 
    x <= std_logic_vector(to_unsigned(sx, 17)); --This is the line reporting the error during the simulation** 

end architecture a2; 

Answer 1

Когда вы работаете с целыми значениями, вы должны инициализировать их значения. В ваших сигналах (su, sv, sw и sx) вы должны сделать это, потому что они являются целыми значениями (от -2^31 до 2^31). Пожалуйста, попробуйте:

signal su: integer :=0; 
signal sv: integer :=0; 
signal sw: integer :=0; 
signal sx: integer :=0; 

если вы не инициализировать их, они будут принимать наибольшее значение (2^31), так что может вызвать проблемы при моделировании.

Answer 2

Строка 37 является ошибка: максимальный диапазон для естественного в VHDL составляет 31 бит (потому что естественным является неотрицательным подмножеством диапазона целых чисел), так to_unsigned с 32 (неформально, Дэвид, вероятно, скоро будет со ссылками LRM). Почему ваш симулятор сообщает об этом неправильно, я не могу ответить. GHDL сообщает об ошибке: ошибка проверки привязки на operator2.vhd: 37 ", как ожидалось.

Обратите внимание, что реальная проблема заключается эта линия:

sw <= to_integer(unsigned(c)) * to_integer(unsigned(d)); 

который пытается запихнуть произведение двух 16-битных unsigneds в целое число с 31-битным положительным диапазоном, который ... не всегда работаю.

Я предлагаю сделать «sw» 32-разрядное без знака, а не целое число, которое будет обрабатывать полный диапазон правильно.

Я бы хотел сделать то же самое для других внутренних сигналов для ясности.Там нет необходимости делать это на основе диапазона численной, но если вы держать их как «целое» было бы лучше, чтобы уточнить свои декларации, чтобы сделать дизайнерский замысел разъясняя:

signal sx: integer;     -- obscures the design 
signal sx: natural range 0 to 131071; -- documents the intent 

и если вы хотите сделав это, вы, вероятно, видели бы проблему быстрее.

И как было отмечено в комментариях, используя natural, а не integer дает действительное значение по умолчанию (natural'left = 0), а не тот, который не может быть преобразован в unsigned (integer'left = -2 ** 31)

Альтернативно , предоставлять гарантии на свои входы (C и D) - ЕСЛИ вы можете ограничить хотя бы один из них до 15 бит - это тоже будет работать.

Я хотел бы продолжить и объявить все порты правильного типа, signed или unsigned, в зависимости от ситуации, и устранить большинство ненужных преобразований типов, которые ничего не делают для удобства чтения. Это также полностью устранит внутренние сигналы, для значительно менее подробного дизайна.