Xilinxs synthese Bitbreiten ausrechnen lassen

Sowas packt man in Konstanten. Dann läuft das VOR der Synthese durch und 
macht keinen Ärger.

FPGA-Pongo schrieb im Beitrag #4146470:
> Sowas packt man in Konstanten. Dann läuft das VOR der Synthese durch und
> macht keinen Ärger.

Sowas: 4*16-1-1
sind Konstanten und die Tools die ich kenne kommen damit wunderbar klar

Nein, eine Konstante ist in C und VHDL eine Ausdruck wie "CONST_MUELLER" 
und wird unten im Code eingesetzt. Was Du da bezeichnest sind 
ausdrueckliche Werte.

die Antwort von Pongo liefert bei Eingabe in Google:

1

   vhdl+CONST_MUELLER

auch nur diesen Beitrag im Forum. Danke fuer die Bestaetigung

Ich stimme ebenso zu, dass dort nicht das Problem liegen sollte.

Naja, der Fehler ist .... es funktioniert nicht. Es kommt nur Schrott 
raus, wenn ich mir das in ChipScope anschaue. Die Synthese läuft durch, 
d.h. der Code ist vom Syntax richtig von der Funktion nicht. Fehler muss 
ich wohl am Montag noch mal debuggen. Mit meiner Testbench scheint es 
aber zu funktionieren. D.h. Wirklichkeit weicht von der TB ab :-) Ich 
bin nur stutzig geworden, denn lässt man Klammern weg, scheint es nicht 
immer zu klappen.

Ich glaube es war sowas

stdlogic_vector(5 downto 2-1) wurde nicht richtig interpretiert
stdlogic_vector(5 downto (2-1)) aber schon

Konstanten an der Stelle sind Schwachsinn. Ich mache das immer, da ich 
dann weiß wo die Zahlenwerte her kommen.

Dank und Gruß

Lothar Miller schrieb:
> Was geht und
> was nicht, das steht für Xilinx im entsprechenden Handbuch. Für den XST
> ist das der "XST Users Guide"

Kann sein ... wenig hilfreich ist es trozdem :-)

Lothar Miller schrieb:
> Wird wohl wie üblich ein asynchrones Signal in einer FSM sein.
> Oder noch offensichtlicher ein asynchroner kombinatorischer Reset...
>
> Das kann man aber erst nach Begutachten der VHDL Beschreibung und der
> Synthesemeldungen sicher sagen.

Sollte eigentlich nicht Thema werden, aber ich habe den Code mal 
angehängt.... ist ja nicht geheim :-) Eigentlich wollte ich nur diese 
Fehlerursache ausschließen. Das war von gestern mein erster Erguss, 
sicher nicht perfekt und irgendwas ist falsch. Anregungen nehme ich sehr 
gerne an.

Sensor ist ein:
http://www.infineon.com/dgdl/TLE5012_TDS_V_0.46.pdf?folderId=db3a304313d846880113dd9752130268&fileId=db3a30431ed1d7b2011f46f9ec2156c5

Grm ist die eigentliche Datei die auf dem FPGA landet.

Viele Grüße

Spartanischer schrieb:
> Sensor ist ein:
> 
http://www.infineon.com/dgdl/TLE5012_TDS_V_0.46.pdf?folderId=db3a304313d846880113dd9752130268&fileId=db3a30431ed1d7b2011f46f9ec2156c5

ich hab' mit dem Ding vor 2-1/2 Jahren rumgemacht, der ist schon ein 
bissle zickig auf der SSC. Musst du den evtl. erstmal mit diversen 
'write' Kommandos initialisieren? Das war bei uns der Fall, das Ding 
hatte die SSC beim PON nicht aktiviert. Du musst das fuer genau deinen 
Sensor gueltige Datenblatt seeeeehr genau lesen...

Was bei mir unterschiedlich zu deinem Ansatz war, ich hatte immer nur 
den Winkel gelesen (1 Register) und den Rest 'kuenstlich' im FPGA 
(Xilinx S3E-1200) nachgebildet. Aber unsere SW am anderen Ende des FPGA 
hat auch Burst-Schreibzugriffe gemacht die ich 1:1 durchgeschoben habe. 
Und das hat auch funktioniert (wie gesagt, nach korrekter 
Initialisierung des Sensors).

All das macht es ganz schoen aufwaendig, ein Simulationsmodell fuer den 
Sensor zu schreiben. Bist du sicher, dass du den Teil in der Simulation 
korrekt abbildest? Dazu hilfreich ist ein Oszi mit SPI-Dekodierfunktion 
(bei uns war die SSC als SPI mit LVDS-Treibern implementiert, ich musste 
also auch noch die LVDS-Treiber am Sensor steuern/umschalten).

Lange Rede, kurzer Sinn: Ohne Oszi haette ich das Ding auch nur sehr 
schwer ans laufen bekommen...

achso, was mir auch noch eingefallen ist: Ich hatte den Sensor mit 
5MBit/sec betrieben und bin heftig auf die Nase gefallen, als die 
SW-Kollegen den Sensor-Treiber wg. EMV umkonfiguriert haben (PAD_DRV von 
b"01" auf b"10"). Ich habe dann einfach den 'sampling-point' der SSC 
"nach hinten geschoben". Da mir die SW-Kollegen von der Aenderung nix 
erzaehlt haben, war das auch eine harte Nuss. Ohne Oszi keine Chance, 
weil du an der komplett falschen Stelle anfaengst zu suchen (das Timing 
auf der SSC hat ja vorher wunderbar funktioniert, also vermutest du da 
ganz sicher kein Problem...)

Viel Glueck!

PPS: Das ganze habe ich ohne Chipscope gemacht (hab' ich noch nie 
verwendet), also nur Datenblatt lesen, Messen mit'm Oszi, und 
Simulationsmodell fuer den Sensor schreiben...

Andreas H. schrieb:
> Ein Anfang ... ;-)
>
> Kannst Du bitte auch noch das Synthese Logfile & das Constraint file
> posten ?


Die habe ich leider nicht hier.

berndl schrieb:
> ich hab' mit dem Ding vor 2-1/2 Jahren rumgemacht, der ist schon ein
> bissle zickig auf der SSC. Musst du den evtl. erstmal mit diversen
> 'write' Kommandos initialisieren? Das war bei uns der Fall, das Ding
> hatte die SSC beim PON nicht aktiviert. Du musst das fuer genau deinen
> Sensor gueltige Datenblatt seeeeehr genau lesen...

Hallo berndl,
So wie ich das verstanden habe ist das per default aktiviert. Das 
Datenblatt habe ich natürlich gelesen, jeodch ist es meiner Meinung 
nicht immer eindeutig.

berndl schrieb:
> PPS: Das ganze habe ich ohne Chipscope gemacht (hab' ich noch nie
> verwendet), also nur Datenblatt lesen, Messen mit'm Oszi, und
> Simulationsmodell fuer den Sensor schreiben...

Das ist eine gute Idee. Werde ich am Montag mal machen.

Lothar Miller schrieb:
> Ich verstehe die Struktur dieses Designs nicht. Die Datei mit "top" im
> Namen ist auf jeden Fall nicht das, was gemeinhin als Toplevel angesehen
> wird: die Entity, die die Verbindung zur Aussenwelt darstellt...  :-/

Hm ja sorry. Dazu hätte ich was schreiben können. GMR ist der Teil der 
mal im FPGA laufen soll und mit dem wirklichen Chip (TLE5012) sprechen 
soll. Um das zu testen habe ich noch versucht den Chip (TLE5012) 
rudimentär abzubilden. Der unglückliche Name ist GRM_receiver. Die 
beiden habe ich dann in einer Datei Names Toplevel_grm mit einander 
verbunden. Die TB ist die Testbench von dem Salat. Das war etwas 
schlampig benannt. Wie würdest du das machen?

Lothar Miller schrieb:
> Also gut, dann ist es ja einfach, denn da drin ist der Fehler.

Ja in der mindestens :-) Hast du einen Tipp?

Lothar Miller schrieb:
> Das Einlesen mit der steigenden Flanke ist suspekt. Hast du dieses
> Timing mit dem Oszi kontrolliert? Laut DB erfolgt die Datenübergabe mit
> der fallenden Flanke...

Hallo Lothar,

danke für deine Antwort. Mit dem Oszi setze ich mich morgen mal dran. 
Das Einlesen sollte aber mit fallender Flanke geschehen. Nur das 
rausschreiben findet bei steigender Flanke statt.

1

        if (COUNTER_TLE_SIG mod 2) = 1 then

2

          SCK_OUT <= '1'; DEBUG_SCK <= 1;

3

        else

4

          DATA_SIG <= DATA_SIG((4*16-1-1) downto 0) & DATA_IN_SIG;

5

        end if;

Lothar Miller schrieb:
> Die Testbench ist praktisch die "Platine", die den simulierten TLE und
> dein FPGA-Design miteinander verbindet und ebenso den Takt und andere
> für das FPGA nötige Signale bereitstellt. In der Testbench werden also
> eines oder mehrere Simulationsmodelle und das FPGA-Design miteinander
> verbunden.

D.h. bei dir wäre dann die Toplevel und die TB eine Datei. Richtig?

Vielen Dank und Gruß
Spartanischer