vector mit 0 initalisieren

[Michael K. (manhunt)]

Hallo

Frage ist es möglich in einem Prozess einem signal vector der zb die 
länge 8 hat mit "000000" + CONSTANTE zu belgen, wobei der Syntesizer 
sich um die anzahl der führenden NULLEN eben für diese Konstante 
kümmert?

lg Michael

[abc (Gast)]

vector <= std_logic_vector(to_unsigned(integer_wert, integer_länge);

z.b.

vector <= std_logic_vector(to_unsigned(5,8);

ist das gleiche wie

vector <= "00000101";

[dito (Gast)]

abc schrieb:
> vector <= std_logic_vector(to_unsigned(5,8);

Und noch schöner ist:

vector <= std_logic_vector(to_unsigned(5, vector'length));

[Michael K. (manhunt)]

Danke für die hilfe, diesen Tip kann ich zwar auch brauchen allerdings 
sind die Constaten vom typ std_Ulogic_vector somit fällt das für mich 
flach...

lg Michael

[abc (Gast)]

>> allerdings sind die Constaten vom typ std_Ulogic_vector

vector <= std_logic_vector(to_unsigned(to_integer(unsigned(Konstante)), vector'length));

zwar ziemlich wild, sollte aber funktionieren.

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

abc schrieb:
> zwar ziemlich wild, sollte aber funktionieren.
Hier würde ich dann mal auf die resize Funktion verweisen...

vector <= std_logic_vector(resize(unsigned(konstante),8));

[Michael K^3 (Gast)]

Hallo,

leider bekomme ich eine Fehlermeldung die ich nicht einordnen kann.

ERROR:HDLParsers:808 - "C:/Projekte/VHDL/trash/test/test.vhd" Line 36. 
resize can not have such operands in this context.

Unten der Quellcode:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_logic_arith.all;
use IEEE.numeric_std.all;
use work.test2.all;

entity test is

port(
  out_vector: out std_ulogic_vector(16 downto 0));
end test;

architecture Behavioral of test is

begin

out_vector <= std_ulogic_vector(resize(unsigned(testt), out_vector'length));

end Behavioral;

library IEEE;
use IEEE.STD_LOGIC_1164.all;

package test2 is

constant testt : std_ulogic_vector(2 downto 0) := "001";

end test2;

package body test2 is

end test2;

[Duke Scarring (Gast)]

Michael K^3 schrieb:
> use IEEE.STD_logic_arith.all;
Raus damit!

vorher:

Model Technology ModelSim PE vcom 10.0b Compiler 2011.05 May  5 2011
-- Loading package STANDARD
-- Loading package TEXTIO
-- Loading package std_logic_1164
-- Loading package std_logic_arith
-- Loading package NUMERIC_STD
-- Loading package test2
-- Compiling entity test
-- Compiling architecture Behavioral of test
** Error: res.vhd(17): (vcom-1078) Identifier "unsigned" is not directly visible.
   Potentially visible declarations are:
        ieee.NUMERIC_STD.UNSIGNED (subtype declaration)
        ieee.std_logic_arith.UNSIGNED (type declaration)
** Error: res.vhd(17): Illegal type conversion to ieee.std_logic_1164.STD_ULOGIC_VECTOR (operand type is not known).
** Error: res.vhd(19): VHDL Compiler exiting

nachher:

Model Technology ModelSim PE vcom 10.0b Compiler 2011.05 May  5 2011
-- Loading package STANDARD
-- Loading package TEXTIO
-- Loading package std_logic_1164
-- Loading package NUMERIC_STD
-- Loading package test2
-- Compiling entity test
-- Compiling architecture Behavioral of test

Duke

[Michael K. (manhunt)]

okay thx^^

generell zu typen konversionen wo was drinnen is ist ein bisschen 
kompliziert...

lg

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

Und dann der:
> std_ulogic_vector
Nimm stattdessen die weltweit üblichen std_logic...

Der ulogic hatte vor geraumer Zeit mal den Vorteil, dass die Simulation 
schneller durchlief. Mit aktuellen Compilern ist dieser Vorteil weg, und 
alle anderen verwenden weltweit std_logic. Damit lassen sich dann 
nämlich auch Tristate Busse beschreiben...

[Michael K. (manhunt)]

Hallo,

ja das ist mir bekannt, allerdings habe ich leider einen coding style 
der vorschreibt für alle entitys/architectures die nicht toplevel sind 
std_ulogic zu verwenden.


lg Michael

[Dietmar S. (df8de)]

@manhunt
Die gleichen Regeln kenne ich auch. std_logic ist nur fuer Chip IOs 
erlaubt, die auch einen tri-state driver haben. Jedes andere Signal ist 
std_ulogic,
@lkmiller
In meinem Environment geht es da nicht um Simulationsperformance, 
sondern darum, dass das  versehentlichte Zuweisen zweier Gleichungen auf 
das gleiche Signal, bei std_logic hat der Compiler eine resolution 
function (worst case ein 'X' innerhalb des Chips) hat, bei std_ulogic 
aber eine Fehlermeldung provoziert wird. Das hilft viele Probleme schon 
sehr frueh zu erkennen. Das letzte Mal, das mir chipinterne tri-atate 
Signale begegnet sind, ist ca. 20 Jahre her, aber da hatte es schon mehr 
Nachteile als Vorteile ('x' als Ergebnis der resolution function, double 
selection an Multiplexer Stufen [war nicht vhdl, sondern eine 
syntaktisch aehnliche Sprache]).
Seit dieser Zeit gilt fuer mich:
Chipintern : std_Ulogic fuer interne Signale um doppelte Zuweisungen vom 
Compiler erkennen zu lassen und std_ulogic nur da, wo ich weiss, das 
tri-state (HZ) im Spiel ist, also an chip IOs.

PS: Spaetestens die Synthese wird (sollte) meckern, wenn zwei 
Zuweisungen auf ein Signale erfogen, aber das wird in der Regel 
wesentlich spaeter erkannt.

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

Dietmar Schmunkamp schrieb:
> PS: Spaetestens die Synthese wird (sollte) meckern, wenn zwei
> Zuweisungen auf ein Signale erfogen, aber das wird in der Regel
> wesentlich spaeter erkannt.
Die Synthese wird bei std_logic sowas einfach in einen Multiplexer 
auflösen:

   output <= inputA when sel='1' else 'Z';
   :
   output <= inputB when sel='0' else 'Z';

Und in Fällen, in denen ein Buskonflikt oder ein undefinierter Pegel 
rauskommt, erscheint eine Fehlermeldung.

> Das letzte Mal, das mir chipinterne tri-atate Signale begegnet sind,
> ist ca. 20 Jahre her,
Die letzte Architektur bei Xilinx war der Spartan (ohne II oder 3 oder 
E/A/AN).
> aber da hatte es schon mehr Nachteile als Vorteile
Begrenzte Ressourcen, lange Turn-Around Zeiten, Bustreiber-Konflikte...

[berndl (Gast)]

Lothar Miller schrieb:
> Dietmar Schmunkamp schrieb:
>> PS: Spaetestens die Synthese wird (sollte) meckern, wenn zwei
>> Zuweisungen auf ein Signale erfogen, aber das wird in der Regel
>> wesentlich spaeter erkannt.
> Die Synthese wird bei std_logic sowas einfach in einen Multiplexer
> auflösen:   output <= inputA when sel='1' else 'Z';
>    :
>    output <= inputB when sel='0' else 'Z';
> Und in Fällen, in denen ein Buskonflikt oder ein undefinierter Pegel
> rauskommt, erscheint eine Fehlermeldung.
>
>> Das letzte Mal, das mir chipinterne tri-atate Signale begegnet sind,
>> ist ca. 20 Jahre her,
> Die letzte Architektur bei Xilinx war der Spartan (ohne II oder 3 oder
> E/A/AN).
>> aber da hatte es schon mehr Nachteile als Vorteile
> Begrenzte Ressourcen, lange Turn-Around Zeiten, Bustreiber-Konflikte...

Da ich den Dietmar kenne, weiss ich auch worueber er redet: Es geht hier 
nicht um FPGAs sondern um ASICs/Custom Logic Chips! Und da wird seeeeehr 
lange nur simuliert, bevor ueberhaupt mal eine Synthese angeworfen wird. 
Und dann bist du echt froh, wenn du rechtzeitig (also bei der 
Simulation) einen potentiellen Konflikt gemeldet bekommst. Bis die Jungs 
vom Physical Design ueberhaupt anfangen dauert, und wenn du dann wegen 
sowas deine komplette Logic ueberdenken/-arbeiten musst dann geht da was 
ganz gewaltig schief...

Also nicht nur an FPGA denken, sondern auch an 'was Groesseres...'

[berndl (Gast)]

berndl schrieb:
> Und da wird seeeeehr
> lange nur simuliert, bevor ueberhaupt mal eine Synthese angeworfen wird.

Erklaerung dazu: Die Jungs und Maedels von PD (physical design) koennen 
gar nicht frueher anfangen, da z.B. Macros wie RAMs, CAMs, irgendwelche 
Logic-Macros parallel zum Design entwickelt werden. D.h. da gibt es halt 
lange Zeit nix fertiges was man synthetisieren kann. Beim FPGA ist das 
easy, der Chip ist ja schon fertig, also kann man auch beim entwickeln 
auf alle Resourcen zugreifen. Aber wenn's ASIC oder sowas ist, dann 
sieht die Welt gleich ganz anders aus...

[Dietmar S. (df8de)]

@berndl

Danke fuer deine Erlaeuterungen:

In der Tat handelt es sich um (komplexe) ASICs, d.h. mit einem Versuch 
sind >100.000$ 'verbrannt'. 'Einfaches' Nachprogrammieren geht da nicht, 
und auf neue Hardware wartest du auch eine gewisse Zeit (mindestens 
einen Monat fuer Aenderungen im Metall, wenn es ins Silizium auch 
laenger...). Daraus folgt fuer mich: Wenn dir der Compiler beim Finden 
eines Fehlers hilfreich sein kann, nutze dieses. Und std_ulogic hat 
haertere Bedingungen als std_logic in der resolution function.
@manhunt

Ich halte den Coding style aufgrund meines (speziellen?) Backgrounds 
fuer sinnvoll, er koennte deiner Firma Geld sparen (nicht nur wegen den 
einmaligen Kosten, sondern auch wegen Time-to-Market).

@lkmiller
Es waren unerkannte Bus-Konflikte, und ein re-spin des Designs mit den 
oben genannten Folgen.

Da es kein FPGA design war, war mein post evtl. deplaziert, aber 
trotzdem bin ich der Meinung, wenn ein Fehler frueh erkannt wird, sind 
die Folgekosten am Geringsten.

PS: Selbst das Debugging der Buskonflikte hat den Fortschritt der 
gesamten Inbetriebnahme empfindlich gestoert.

[SuperWilly (Gast)]

Es gibt in Modelsim eine "Synthesis check"-Option, die bereits beim 
Kompilieren anzeigt, ob ein Signal einen Cross-Treiber hat.

>>Warning: Nonresolved signal 'test_sig' may have multiple sources.

Wenn diese Simulator-Option zur Verfügung steht (vcom -synthesis_check), 
dann benötigt man auch beim ASIC-Design kein "std_Ulogic" mehr.

VG, SuperWilly