La conversion de Type en VHDL: réel en entier - Est le mode d'arrondi spécifié?

Pendant le débogage de la manipulation de l'utilisateur défini des types physiques dans Vivado (lire plus), j'ai trouvé un comportement différent pour les conversions de type de réel en entier.

Voici mon code d'exemple:

library IEEE;
use     IEEE.STD_LOGIC_1164.ALL;
--use     IEEE.MATH_REAL.all;

entity Top_PhysicalTest_Simple is
  port (
    Clock : in STD_LOGIC;
    Input : in STD_LOGIC;
    Output : out STD_LOGIC
  );
end;

architecture top of Top_PhysicalTest_Simple is
  constant int_1     : INTEGER  := natural(0.5);
  constant int_2     : INTEGER  := integer(-0.5);
--  constant int_2     : INTEGER  := natural(-0.5);
begin
  assert FALSE report "16 - int_1 (natural(0.5)):  " & INTEGER'image(int_1) severity note;
  assert FALSE report "17 - int_2 (natural(-0.5)): " & INTEGER'image(int_2) severity note;

  Output <= Input when rising_edge(Clock);
end;

Le mannequin flip flop est utilisé pour prévenir certains outils de se plaindre au sujet d'une conception vide.

XST 14.7:

Elaborating entity <Top_PhysicalTest_Simple> (architecture <top>) from library <work>.
Note: "16 - int_1 (natural(0.5)):  1"
Note: "17 - int_2 (natural(-0.5)): 0"

XST semble utiliser le mode round up et il se charge de la conversion de type inclusif contrôle de portée.
Donc, je dois utiliser integer(-0.5) au lieu de natural(-0.5).

Vivado 2014.4:

[Synth 8-63] RTL assertion: "16 - int_1 (natural(0.5)):  1" ["D:/Temp/PhysicalTest_Vivado2014.4/vhdl/Top_PhysicalTest_Simple.vhdl":80]
[Synth 8-63] RTL assertion: "17 - int_2 (natural(-0.5)): -1" ["D:/Temp/PhysicalTest_Vivado2014.4/vhdl/Top_PhysicalTest_Simple.vhdl":81]

Synthé semble utiliser le mode ronde à l'infini et gère le type de conversion, sans contrôle de portée. Alors peut-être natural(..) est juste un alias pour integer(..).

La ligne de commentaire: constant int_2 : INTEGER := natural(-0.5); ne renvoie pas d'erreur.

GHDL 0.29:

GHDL 0.29 n'a pas de contrôle de portée dans natural(..).
Je sais que c'est daté, mais depuis 0.31 me déteste, je ne peux pas dire si c'est déjà corrigé.

GHDL 0.31:

Je vais présenter les résultats par la suite. GHDL refuse à analyser mon code parce que:

Top_PhysicalTest_Simple.vhdl:29:14: fichier std_logic_1164.v93 a changé et doivent être analysés de nouveau

Mes questions:

• Ne VHDL définir un mode d'arrondi? Et si oui, lequel?
• Comment dois-je gérer arrondissement si aucun mode n'est-elle définie?

OriginalL'auteur Paebbels | 2015-01-07