String als Konstante definieren

[Uwe B. (derexponent)]

Hallo,

-hier eine Frage zu einer String Definition :

dieser Codeabschnitt :

architecture Verhalten of Test1 is

  signal c_str : STRING(1 to 16):="abcdefghijklmnop";
  signal v_chr : character;
  signal chr_pos : integer range c_str'range := c_str'left;
  signal data : std_logic_vector(7 downto 0);  
  
begin
  v_chr <= c_str(chr_pos);
  data <= std_logic_vector(to_unsigned(character'pos(v_chr),8));
end Verhalten;

liefert als Ergebnis in "data" die Zahl 61Hex = 'a'
das ist das erste Zeichen im String...so wie es sein soll

ABER !

wenn ich jetzt nur eine Zeile ändere und
aus dem "signal c_str" ein "constant c_str" mache,
kommt als Ergebnis die Zahl 62Hex = 'b' raus !!
Das ist das zweite Zeichen im String !!

architecture Verhalten of Test1 is

  constant c_str : STRING(1 to 16):="abcdefghijklmnop";
  signal v_chr : character;
  signal chr_pos : integer range c_str'range := c_str'left;
  signal data : std_logic_vector(7 downto 0);  
  
begin
  v_chr <= c_str(chr_pos);
  data <= std_logic_vector(to_unsigned(character'pos(v_chr),8));
end Verhalten;

1. Wie kommt es zu diesem "Fehler"
2. Muss ich einen String (den ich nicht mehr verändern will)
   nicht als "constant" definieren ?

und was ich jetzt noch gesehen habe :
der "Fehler" tritt nicht auf, wenn der String
kleiner als 16 Zeichen lang ist !?!

Danke und Gruss Uwe

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> STRING(1 to 16)
Was kommt raus, wenn du das so änderst:
STRING(0 to 15)

Uwe B. schrieb:
> der "Fehler" tritt nicht auf, wenn der String
> kleiner als 16 Zeichen lang ist !?!
WO tritt der Fehler denn überhaupt auf?
Im Simulator? Welcher?
Oder auf der Hardware?

[Uwe B. (derexponent)]

Hi Lothar,

-der "Fehler" (wenn ich den mal so nennen darf...
er kann ja auch bei mir liegen)

habe ich auf der Zielhardware (Xilinx, Spartan-3, ISE 13.1)

-ich lasse mir das erste Zeichen eines Strings
auf den 8Bit LEDs ausgeben und sehe das es
einen Unterschied macht, ob ich den String
als "signal" oder als "constant" definiert habe

P.S. als Ausgangsbasis habe ich dein Beispiel
von hier benutzt :

Link zu Artikel "Beitrag "ISim: String-Darstellung im Waveplot";

...im Simulator hab ich es noch nicht getestet

Nachtrag :

bei "STRING(0 to 15)" meckert die ISE von Xilinx
das "0" nicht im Index-Range von "1" bis "2147484347"
eines "array STRING" liegt...das geht also nicht

Gruss Uwe

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uwe B. schrieb:
> -ich lasse mir das erste Zeichen eines Strings
> auf den 8Bit LEDs ausgeben und sehe das es
> einen Unterschied macht, ob ich den String
> als "signal" oder als "constant" definiert habe
Lass dir mal die RTL-Schaltpläne anzeigen. Unterscheiden die sich?

[H..M. (Gast)]

Deine beiden Beispiele in einen TestBench umgewandelt
ergeben bei mir immer 'a'. (verwende 13.2).
Am "constant"/"signal" liegt's also (auch offensichtlich)
nicht.

[Uwe B. (derexponent)]

Danke ihr beiden für die Hilfe,

-ich hab gestern mal noch in einem "Qick&Dirty" Test
das Signal "chr_pos" gegen eine feste Zahl getauscht :

v_chr <= c_str(1);

so geht es komischerweise auch immer (egal op signal/constant)

@Lothar,

-werd heut abend auch ne Testbench schreiben
und danach versuchen noch die RTL-Schaltpläne zu vergleichen

Nachtrag...
...und P.S. er 'verschiebt' nicht nur die Position (1)
sondern alle Positionen um eine stelle nach rechts :

also wenn ich die 3te Stelle auslesen will :

signal chr_pos : integer range c_str'range := 3;
v_chr <= c_str(chr_pos);

kommt einmal der Buchstabe 'c' (signal)
und einmal der Buchstabe 'd' (constant) raus

Gruss Uwe

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uwe B. schrieb:
> -werd heut abend auch ne Testbench schreiben
Da fällt mir der Beitrag "Re: ISim: String-Darstellung im Waveplot" 
wieder ein...

Und: die Version 13 bringts auch noch nicht...
Das geht (unabhängig ob signal oder constant):

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity StringToSLV is
    Port ( clk  : in  STD_LOGIC;
           dout : out  STD_LOGIC_VECTOR (7 downto 0));
end StringToSLV;

architecture Behavioral of StringToSLV is
constant txt : string(1 to 4) := "azby";
-- signal txt : string(1 to 4) := "abcd";
signal ch  : character := 'o';
signal cnt : integer range txt'range := txt'left;

begin
   process begin
      wait until rising_edge(clk);
      if cnt < txt'right then  cnt <= cnt+1;
      else                     cnt <= txt'left;
      end if;
   end process;

   ch   <= txt(cnt);
  
   process (ch) begin
      dout <= std_logic_vector(to_unsigned(character'pos(ch),8));
   end process;
end Behavioral;

Aber das geht nicht:

   : -- alles gleich wie oben
   :
   ch   <= txt(cnt);
 
   dout <= std_logic_vector(to_unsigned(character'pos(ch),8));

end Behavioral;

Und das obwohl die Concurrent-Beschreibung

   dout <= std_logic_vector(to_unsigned(character'pos(ch),8));

eigentlich 1:1 in den Prozess überführbar sein müsste!

   process (ch) begin
      dout <= std_logic_vector(to_unsigned(character'pos(ch),8));
   end process;

Und wie schon gesagt: der ModelSim kanns, der ISIM nicht!

[Uwe B. (derexponent)]

Hi Lothar,

-mal eine generelle Frage...das Synthesetool erkennt ja anscheinend
(wie ich aus den Screenshots von deinem anderen Beitrag erkennen kann)
welche Signal-Bits sich ändern und welche fest verdrahtet (GND,VCC)
werden können

...warum (bzw. welcher Zweck) hat dann bei der VHDL-Beschreibung
der Unterschied signal/constant

...würde es nicht ausreichen einfach "ALLES" als "signal" zu definieren 
?

Gruss Uwe

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uwe B. schrieb:
> ...würde es nicht ausreichen einfach "ALLES" als "signal" zu definieren
Es läuft mehr oder weniger aufs Gleiche raus... ;-)
Wenn die Synthese sieht, dass ein Signal nur gelesen wird, dann ist es 
automatisch konstant. Sowas wie volatile in C gibt es nicht...

[Klaus (Gast)]

Lothar Miller schrieb:
> Uwe B. schrieb:
>> ...würde es nicht ausreichen einfach "ALLES" als "signal" zu definieren
> Es läuft mehr oder weniger aufs Gleiche raus... ;-)
> Wenn die Synthese sieht, dass ein Signal nur gelesen wird, dann ist es
> automatisch konstant. Sowas wie volatile in C gibt es nicht...

Das hat wohl eher dokumentarische Funktion. Wenn ich mir fremden VHDL 
Code anschaue und ein constant sehe, dann weiß ich, dass dieses signal 
nie beschrieben wird, und dieser Wert eine besondere Bedeutung hat.

[Uwe B. (derexponent)]

Hi nochmal,

-hab jetzt noch etwas rumprobiert ... hier das Ergebnis :

1. mit einer Testbench und ModelSim sieht man keinen
Unterschied zwischen "signal/constant" und es kommt
immer der richtige Wert raus

2. auf der Zielhardware macht es einen Unterschied
(bei signal = ok, bei constant = fehler)

3. ich hab dann mal den VHDL-Code abgeändert, das ganze
in einen Prozess gepackt und mir das RTL-Schema
anzeigen lassen

entity Test_Prj8_VHDL is
  port(
    CLK_50MHZ_IN : in std_logic;
    LED_OUT : out std_logic_vector(7 downto 0)
  );
end Test_Prj8_VHDL;

architecture Verhalten of Test_Prj8_VHDL is


  

  constant c_str : STRING(1 to 16):="abcdefghijklmnop";
  signal v_chr : character;
  signal chr_pos : integer range 0 to 17:=1;
  
  
begin

  P1 : process(CLK_50MHZ_IN) begin
    if rising_edge(CLK_50MHZ_IN) then
      v_chr <= c_str(chr_pos);
      LED_OUT <= std_logic_vector(to_unsigned(character'pos(v_chr),8));
    end if;
  end process P1;
  
    

end Verhalten;

...die Bilder seht ihr ja

-warum ISE bei der Synthese diesen "Fehler" macht
verstehe ich nicht...aber ich nehme es jetzt halt so hin,
und definiere Strings ab jetzt immer als "signal" und gut ist

...man muss vielleicht nicht alles verstehen :-)

Danke trotzdem für die Hilfe

@Klaus,
"Wenn ich ein constant sehe, dann weiß ich, dass dieses signal
nie beschrieben wird"

genau aus dem Grund habe ich bei meinem String
ein "constant" davorgesetzt...es soll ein Text
für ein LCD-Display werden der sich nicht ändert

Gruss Uwe

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uwe B. schrieb:
> -warum ISE bei der Synthese diesen "Fehler" macht
> verstehe ich nicht...
Das sieht wirklich urig aus...  :-o
Welche Meldungen bekommst du bei der Synthese bei den beiden Fällen 
bzgl. RAM/ROM?

Was passiert, wenn du den "neuen" Parser verwendest:
http://www.lothar-miller.de/s9y/archives/79-use_new_parser-YES.html
Evtl. versteht der besser, was du willst...

[Uwe B. (derexponent)]

Hi nochmal,

-hier der Text von der Synthese bei "signal c_str : STRING(1 to 16)"

=========================================================================
*                           HDL Synthesis                               *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <Test_Prj8_VHDL>.
    Related source file is "F:/Data_Temp_Ordner/Xilinx/Projekte/Test_Prj8/Test_Prj8/Test_Prj8_VHDL.vhd".
WARNING:Xst:1780 - Signal <chr_pos<4>> is never used or assigned. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:653 - Signal <chr_pos<3:0>> is used but never assigned. This sourceless signal will be automatically connected to value 0001.
WARNING:Xst:1781 - Signal <c_str> is used but never assigned. Tied to default value.
    Found 16x8-bit ROM for signal <$varindex0000> created at line 52.
    Found 8-bit register for signal <LED_OUT>.
    Found 8-bit register for signal <v_chr>.
    Summary:
  inferred   1 ROM(s).
  inferred  16 D-type flip-flop(s).
Unit <Test_Prj8_VHDL> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# ROMs                                                 : 1
 16x8-bit ROM                                          : 1
# Registers                                            : 2
 8-bit register                                        : 2

=========================================================================

=========================================================================
*                       Advanced HDL Synthesis                          *
=========================================================================


Synthesizing (advanced) Unit <Test_Prj8_VHDL>.
INFO:Xst:3034 - In order to maximize performance and save block RAM resources, the small ROM <Mrom__varindex0000> will be implemented on LUT. If you want to force its implementation on block, use option/constraint rom_style.
Unit <Test_Prj8_VHDL> synthesized (advanced).

=========================================================================
Advanced HDL Synthesis Report

Macro Statistics
# ROMs                                                 : 1
 16x8-bit ROM                                          : 1
# Registers                                            : 16
 Flip-Flops                                            : 16

=========================================================================

und hier bei "constant c_str : STRING(1 to 16)"

=========================================================================
*                           HDL Synthesis                               *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <Test_Prj8_VHDL>.
    Related source file is "F:/Data_Temp_Ordner/Xilinx/Projekte/Test_Prj8/Test_Prj8/Test_Prj8_VHDL.vhd".
WARNING:Xst:1780 - Signal <chr_pos<4>> is never used or assigned. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:653 - Signal <chr_pos<3:0>> is used but never assigned. This sourceless signal will be automatically connected to value 0001.
    Found 16x8-bit ROM for signal <v_chr$rom0000> created at line 52.
    Found 8-bit register for signal <LED_OUT>.
    Found 8-bit register for signal <v_chr>.
    Summary:
  inferred   1 ROM(s).
  inferred  16 D-type flip-flop(s).
Unit <Test_Prj8_VHDL> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# ROMs                                                 : 1
 16x8-bit ROM                                          : 1
# Registers                                            : 2
 8-bit register                                        : 2

=========================================================================

=========================================================================
*                       Advanced HDL Synthesis                          *
=========================================================================


Synthesizing (advanced) Unit <Test_Prj8_VHDL>.
INFO:Xst:3034 - In order to maximize performance and save block RAM resources, the small ROM <Mrom_v_chr_rom0000> will be implemented on LUT. If you want to force its implementation on block, use option/constraint rom_style.
Unit <Test_Prj8_VHDL> synthesized (advanced).

=========================================================================
Advanced HDL Synthesis Report

Macro Statistics
# ROMs                                                 : 1
 16x8-bit ROM                                          : 1
# Registers                                            : 16
 Flip-Flops                                            : 16

=========================================================================

nach der Umstellung auf den "neuen" Parser
legt er alle Signale fest auf Lo-Potential
(egal ob signal oder constant) !!

WARNING:HDLCompiler:871 - "F:\Data_Temp_Ordner\Xilinx\Projekte\Test_Prj8\Test_Prj8\Test_Prj8_VHDL.vhd" Line 45: Using initial value 1 for chr_pos since it is never assigned
WARNING:HDLCompiler:1127 - "F:\Data_Temp_Ordner\Xilinx\Projekte\Test_Prj8\Test_Prj8\Test_Prj8_VHDL.vhd" Line 50: Assignment to v_chr ignored, since the identifier is never used
WARNING:HDLCompiler:634 - "F:\Data_Temp_Ordner\Xilinx\Projekte\Test_Prj8\Test_Prj8\Test_Prj8_VHDL.vhd" Line 44: Net <v_chr[7]> does not have a driver.
WARNING:Xst:2935 - Signal 'v_chr', unconnected in block 'Test_Prj8_VHDL', is tied to its initial value (00000000).
    WARNING:Xst:2404 -  FFs/Latches <LED_OUT<7:0>> (without init value) have a constant value of 0 in block <Test_Prj8_VHDL>.
WARNING:Xst:3152 - You have chosen to run a version of XST which is not the default solution
   for the specified device family. You are free to use it in order to take
   advantage of its enhanced HDL parsing/elaboration capabilities. However,
   please be aware that you may be impacted by  language support differences.
   This version may also result in circuit performance and device utilization
   differences for your particular design. You can always revert back to the
   default XST solution by setting the "use_new_parser" option to value "no" 
   on the XST command line or in the XST process properties panel.

...ich lass es damit gut sein und mach einfach mit dem
"Walkaround" weiter


Gruss Uwe