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
Gast
#2311569
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";
Gast
#2311578
abc schrieb: > vector <= std_logic_vector(to_unsigned(5,8); Und noch schöner ist:
1 | |
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
Gast
#2311719
>> allerdings sind die Constaten vom typ std_Ulogic_vector
1 | |
zwar ziemlich wild, sollte aber funktionieren.
abc schrieb: > zwar ziemlich wild, sollte aber funktionieren. Hier würde ich dann mal auf die resize Funktion verweisen...
1 | |
Gast
#2312084
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Gast
#2312096
Michael K^3 schrieb: > use IEEE.STD_logic_arith.all; Raus damit! vorher:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
nachher:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Duke
okay thx^^ generell zu typen konversionen wo was drinnen is ist ein bisschen kompliziert... lg
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...
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
@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.
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:
1 | |
2 | |
3 | |
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...
Gast
#2313783
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...'
Gast
#2313795
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...
@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.
Gast
#2314809
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.