Anton K. schrieb:

Wo kann man es umgeschaltet werden ?

Entweder über eine Configuration: https://nandland.com/configuration/ oder Du nimmst das Behavioural Model aus der Simulation raus.

Hallo Rick.D Wie nehme ich Behavioural model aus der Simulation heraus ?, In meine testbench definiere ich die UUT als Componente :

1

------------------------------------------------------

2

entity TESTBNCH is

3

end TESTBNCH;

4

-------------------------------------------------------

5

COMPONENT TopAS21 is

6

  generic(adrbit : INTEGER:=16; clkper :INTEGER:= 20);

7

  port(

8

    SYSCLK_P: in STD_LOGIC;-- Sysrtem clk 200 MHz

9

    SYSCLK_N: in    

10

           ---usw.....

11

------------------------------------------------

12

und definiere die Implementation :

13

-----------------------------------------

14

--- Implementation  UUT : AS21

15

begin

16

   UUT: TopAS21

17

  --generic map(adrbit: INTEGER:=16; clkper :INTEGER:= 20);

18

  port map(

19

    SYSCLKP,--IN,System clk 200 MHz

20

    SYSCLKN,-- IN

21

                ---usw ....

22

-----------------------------------------

wo ist da der Behavioural model ? Es tut mir leid mit der Beschreibung in nandland bin ich nicht klar worden. Bitte kannst Du mir helfen, Ich habe eine andere Simulation als wie ich oben beschrieben habe nie gemacht.Danke zum voraus. Anton

Mod: bitte wie über jeder Texteingabebox beschrieben die [vhdl] Tags benutzen!

Wie (über welche Menüpunkte) startest Du denn Deine Simulation?

Bei mir läuft die Simulation immer (!) unabhängig vom Synthesetool und daher hab ich bzgl. der Simulation alles im Griff. Aber ich weiß, das sich Modelsim auch aus der ISE heraus starten lässt...

Hallo Rick Ja ich starte es aus der ISE, ist das ein Problem. Im ISE habe ich überall gesucht ob man statt Behavioural andere Simulation starten kann, aber nichts gefunden. Wie machst Du es, start direkt im ModelSim ? Wie geht es ?

Das Modell hast Du schon erstellt (erstellen lassen?)

Danach muß man für die ISE ein neues prj-File erstellen: https://support.xilinx.com/s/article/45668?language=en_US

Anton K. schrieb:

Wie kann ich definieren, dass der ModelSim die Post_Map simulation durchführt

Nur mal grundlgegend: diese Simulation habe ich seit 20 Jahren nicht mehr gebraucht. Mir haben bisher dann immer 1. synchrones Design, 2. vernünftige Constraints und 3. eine Verhaltensimulation gereicht. Und die ersten beiden sollten sowieso Voraussetzung sein.

Was willst du mit einer Post-Mapping Simulation erreichen?

Hallo Lothar Mit post Map Simulation habe ich nichts erreicht. Bisher war es so, wenn etwas in der Simulation gelaufen ist (voraussetzung Testbench war ok) dann ist es auch nach der Synthese und Programmieren im FPGA gelaufen, FPGA . Kintex7/325, Tool: USE 14.7. Nun läuft den entsprechnde Modul in der Simulation (ModelSim) problemlos, dagegen wird ein Block in der Map wegoptimiert (konkret mulFP, =coregen muliplication FloatingPoint ). Da der Resultat in nachfiolgenden Cores gebraucht wird läuft die ganze Berechnung nicht mehr. Ich habe alle relevante Signale auf ein Testoutput geführt, so konnte ich mit dem LA genau fessstellen wo es nicht weiter geht.

Bitte Lothar, kannst es bitte kritisch anschauen, ich bin mir keines Fehlers bewust.Bin bereits ganzer Woche daran, am Rande von Verzweiflung. Der ganze Modul ITPModul.vhd in der Beilage.

Das Problem liegt in Process "runangle" state 25..29, Implementation siehe am Ende des Moduls. Die latency von mulFP ist 1, ich habe auch mit mehr probiert. Alle Signale sin SLV(31..0) in FP format, (singel Precision ) Die Input Signale FL12 und FL1 sind vorhanden, das konnte ich an testoutputs sehen. Der Resultat mul12 ist immer 0 (wegoptimiert), wird für nächste Multiplikator benötigt. Ich habe auch mit KEEP component probiert, ohne Erfolg.

use IEEE.STD_LOGIC_ARITH.ALL; use ieee.std_logic_signed.ALL; use IEEE.numeric_std.all;

Nein, das ist nicht gut.

Wo sind die Beschreibungen der Komponenten wie AxConv? Ohne die kann man das nicht simulieren.

Anton K. schrieb:

Nun läuft den entsprechnde Modul in der Simulation (ModelSim) problemlos

Testbench?

Anton K. schrieb:

Ich habe alle relevante Signale auf ein Testoutput geführt, so konnte ich mit dem LA genau fessstellen wo es nicht weiter geht.

Nein! Dafür gibt es die Simulation. Oder zur Not den ILA/SignalTap. Aber extern mit LA oder Oszi muss man echt nicht mehr friemeln.

Argh. std_logic_arith ist buggy, und falls ein coregen-Core noch sowas verwendet: einen weiten Bogen drum machen. Gibt einige Szenarien mit signed/unsigned und sign-extension, die bei std_logic_arith broken by design sind, resp. unterschiedlich umgesetzt wurden, die Details muesste ich ausgraben.

Der jetzige Stand, wenn ich richtig lese, ist also, dass du verifiziert hast, welche Komponente wegoptimiert wird. Oder funktioniert deine Post-Map gleich wie die Modelsim-Variante?

Die Post-Map-Simulation hilft dir nur, um Synthese-Fehler einzukreisen (die bei std_logic_arith definitiv in einigen Toolchains passieren koennen). Wenn du also schon weisst, dass im Mapping-Schritt was eliminiert wird, hast du erst eine andere Baustelle. Auch wenn es allenfalls mit std_logic_arith nichts zu tun hat, solltest du erst mal deinen Code aufraeumen und einzelne Berechnungen in abgetrennten Modulen sauber formal zu verifizieren. Zudem wuerde ich dringend raten, keine Float-Cores zu verketten, sondern intern Fixpoint zu rechnen und nur an den Dateninterfaces zwischen float zu konvertieren, um numerische Fehler im Griff zu behalten. Ich lese da vom Schiff aus: atan, sqrt... da geht hier die Warnlampe an. Und der Einsatz von Variablen ist noch eine ganz andere Geschichte, aber wenn's irgendwie laeuft...

Hallo Martin nur ganz kurz, weil ich unterwegs bin. Die module atan,acos,cos sin usw. diese Funktionen die ich selber machen müsste mit Taylor Aproximation weil die bestehenden Funktionen zu ungenau sind (ich benötige mind. Genauigkeit von 9 stellen nach komma), die habe ich natürlich nicht beigelegt, aber du kannst sicher sein das die funktionieren und auch nicht im FPGA optimiert werden. Wenn Du das ganze simulieren willst muss ich den ganzen Projekt senden, und das darf ich nicht. Das modul runangle ist nur etwa 20% von gesammten Projekt aber ausgerechnet hier gibt es problem, alle andere Teile laufen problemlos auch im FPGA. Das gesamte Projekt lauft problemlos in der Simulation(inkl runangle), das ich hier dann testoutput und LA benütze ist gewissemasen Tat der Verzweiflung, weil mit der Simulation lässt sich das Problem in "runangle" nicht einkreisen,. resp. das Problem kommt in der Simulaton gar nicht vor. Vielleicht probiere ich die die runangle in mehrere separate module aufzuteilen, ist da überhaupt eine Hoffnung das die Optimierung weg ist?

Anton K. schrieb:

Das modul runangle ist nur etwa 20% von gesammten Projekt aber ausgerechnet hier gibt es problem, alle andere Teile laufen problemlos

Das hab ich früher auch mal gedacht. Selbst, wenn jedes Teil bzw. Modul für sich funktioniert, muß das nicht für das Zusammenspiel der Module gelten.

Ansonsten gilt der Satz: Teile und Herrsche! Versuche das Szenario zu finden, wo der Fehler auftritt und prüfe zwischen den Modulen ob der Fehler links oder rechts von der Prüfstelle auftritt. Das geht so lange, bis man das fehlerhafte Modul isoliert hat.

Dann geht man wieder in die Modul-Testbench und füttert das Modul mit den Daten, die den Fehler provozieren und sucht in der Simulation nach dem Fehler.

Anton K. schrieb:

Das gesamte Projekt lauft problemlos in der Simulation(inkl runangle), das ich hier dann testoutput und LA benütze ist gewissemasen Tat der Verzweiflung, weil mit der Simulation lässt sich das Problem in "runangle" nicht einkreisen,. resp. das Problem kommt in der Simulaton gar nicht vor.

Das haben wir schon verstanden. Genau solche Diskrepanzen siehst du bei vielen Tools typischerweise wenn std_logic_arith verwendet oder sogar mit numeric_std gemischt wird. Da wuerde ich bohren und den Code als erstes aufraeumen. Wenn die Synthese aus einer nach Standard korrekten Beschreibung was wegoptimiert, kannst du es den Xilinx-FAEs per Post-Map-Sim nachweisen. Die kostenlose Hilfe endet dann auch hier. In die Simulation stecken wird das fuer dich keiner fuer gratis und umme, also brauchst du auch nicht mehr posten. Der Code ist in der jetzigen Form absehbar schon weder sauber verifizierbar noch fuer andere debugbar.

Hallo Anton,

du verwendest für den multiplier das Signal "mul12". Das ist scheinbar der result-vector. Und der wird für die nächste Operation am Eingang a verwendet. (Hab ich das richtig verstanden?)

Bei deinem Reset von deinem Prozess initialisierst du mul12 mit (others => '0'). Da das aber der Ausgang von deinem Multiplier ist kann das zu Problemen führen. Das hatte ich bei Xilinx auch schon. Bei mir hatte geholfen das Signal nicht im Reset zu behandeln. Das brauchst du nicht. Sobald valide Daten am Eingang des Multipliers anliegen liefert auch der Ausgang vernünftige Signale. Bis dahin ist es halt unbestimmt.

Grüße, Jens

Hallo Jens, vielen Dank führ den Hinweis, an das habe ich nicht gedacht, das könnte tatsächlich die uesache sein. Danke.

Und? War es das?

Simon R. schrieb:

Das kann doch maximal für den Zeitraum gelten, der sich durch die Laufzeit durch das Silizium ergibt?

Ja. Wenn man an den Eingang Daten anlegt, dann dauert es etwas und dann kommt ein valides Ergebnis raus. Wie lange das dauert hängt davon ab ob das getaktet ist und wie viele Takte das dauert und wie lange die Kombinatorik braucht für den Durchlauf.

Simon R. schrieb:

d.h. die Vorgabe des Ausgangswertes gilt nur eine (als Beispiel) halbe Nanosekunde?

Nein. Den Ausgangswert gibst du nicht vor. Und je nach Art von dem Bauteil also getaktet DSP mit Pipeline oder kombinatorisch wird der Ausgangswert irgendwann gültig, eben wenn gültige Eingangswerte angelegt wurden und die Latenz vorbei ist. Und dann bleibt der ausgang so lange gültig bis sich am Eingang was ändert und die Latenz erneut durchlaufen wurde.

Hallo Jens, Entschuldige wg keine Antwort. Bin erst aus der Ferien zurückgekehrt und muss zuerst den Stappel auf meinem Schreibtisch vernichten. Sobald ich dazu komme werde ich die Aenderungen machen und gebe dir Bescheid.Gruss Anton

Hallo Jens, ja das habe ich probiert, das hat nicht geholfen, habe festgestellt das nich nur der Ausgang Signal "removed" ist sondern die ganze mulFP Komponente (cmul12): .... The signal "itpexec/cmul12/sig0000009c" is sourceless and has been removed. The signal "itpexec/cmul12/sig0000009b" is sourceless and has been removed. The signal "itpexec/cmul12/sig0000009a" is sourceless and has been removed. The signal "itpexec/cmul12/sig00000099" is sourceless and has been removed. .... Input SignaleFL1 & Fl12 sind aber vorhanden und werden nicht "removed" weil die auch an anderen Stellen gebraucht wurden hier source implementation von mulFP: .... cmul12: mulFP port map(a=>FL1,b=>FL12,clk=>clk,ce=>ceadd1,result=>mul12);-- FL1 * FL12 => mul12

weiter info siehe Beilage ITPmodul.vhd, process runangle(clk)

Anton K. schrieb:

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; --use IEEE.STD_LOGIC_UNSIGNED.ALL; use ieee.std_logic_signed.ALL; --USE ieee.math_real.all; use IEEE.numeric_std.all;

Schmeiß doch bitte mal die std_logic_artih, die std_logic_signed (und die std_logic_unsigned) komplett raus und verwende sie nie, nie wieder! Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

Es bleiben drin die std_logic_1164 (wegen der Typen std_logic, std_ulogic und den zugehörigen Vektoren), numeric_std (wegen der Typen signed und unsigned) und wegen mir math_real (wenn mal Konstanten berechnet werden müssen und floating-point gebraucht wird).

Fall du VHDL-Literatur findest, die in den letzten 10 oder 20 Jahren geschrieben wurde und wo die Verwendung von std_logic_artih und std_logic_signed propagiert wird, dann schmeiß die weg. Der Autor hatte keine Ahnung. Leider.

Hallo Rick D. Nun habe ich aus allen Modulen die std_logic_signed .. usw ausgeschmissen. es kommen aber fehler, übrigens nur in einem alten Modul

conv_integer not declared und bei definition operator "+" ,cannot determine exact overloaded matching definitionfor +

was ist hier der ersatz ?

Was ist mit LIBRARY XilixCorelib muss man die benützen ?

Da nimmst du to_integer().

Achte auf das richtige Casten, dann funktioniert das.

Gruß, Jens

Danke Jens, jetzt nur noch letzte Fehler :

ERROR:HDLCompiler:1731 - "C:\AS_21A21_FPGA_ISE14_7\Ramp1.vhd" Line 491: found '0' definitions of operator "+", cannot determine exact overloaded matching definition for "+"

Die zeilen 488..492 -- vsptr_out:SLV((adrbit-1) DOWNTO 0):=(OTHERS => '0'); IF (vsptr_inp = maxbuf) THEN -- Bufferpointer inkrem. vsptr_inp := (OTHERS => '0'); ELSE vsptr_inp := vsptr_inp + '1';--zeile 491 END IF;

ist mir völlig unklar wo das fehler sein soll, ist erst aufgetaucht mit löschen von: use IEEE.STD_LOGIC_ARITH.ALL;

-- vsptr_inp:SLV((adrbit-1) DOWNTO 0):=(OTHERS => '0'); für inp ist die gleiche Definition Gruss Anton

Anton K. schrieb:

vsptr_inp := vsptr_inp + '1';

Wird zu

vsptr_inp := std_logic_vector(unsigned(vsptr_inp) + 1);

Die numeric_std kann nicht mit std_logic_vector rechnen. Und das ist gut so. Entweder man ändert den Typ auf unsigned:

1

 vsptr_out:unsigned((adrbit-1) DOWNTO 0):=(OTHERS => '0');

oder man castet mehrfach, wie von Gustl empfohlen.

Die richtigen Casts sind hier sehr übersichtlich aufgeführt: http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html

Danke Rick, dass du den Link geteilt hast! An den hatte ich heute auch schon gedacht, bin aber noch nicht dazu gekommen, den rauszusuchen. Da kann sich der TO einlesen, wie das richtig funktioniert.

@Anton: Was gibt es denn noch für Fehlermeldungen? War es das? Funktioniert es jetzt?

Grüße, Jens

Hall0 Jens. Danke für Nachfrage, Das gibt eine grössere Sache, mit der Umstellung von IEEE.STD_LOGIC_ARITH.ALL; auf NUMERIC gibt es hunderte von Meldungen wg, conv_integer => to_integer, und Operator + resp - Ich werde mich melden wenn so weit ist. Gruss Anton

Hallo Rick D. (rickdangerus) Eine ketzerische Frage: warum findest Du es gut, die NUMERIC std verkompliziert ja enorm , hier einige Beispiele:

ITPlin(std_logic_vector(iEB)) <= '1';--=> fehler line 868, was ist falsch ---ITPlin ist SLV(2..0),ieb ist Integer(0 to 2) ERROR:HDLCompiler:620 - "C:\AS_21A21_FPGA_ISE14_7\ITPModul.vhd" Line 868: Near std_logic_vector ; type conversion does not match type natural -----auchdas habe ich probiert => Fehler----------------- ITPlin(std_logic_vector(to_unsigned(iEB,3))) <= '1';

XLinAbs <= (Xlin XOR X"FFFF") + 1;--- fehler line 872 --XLinAbs und Xlin sind SLV(31..0) ERROR:HDLCompiler:1731 - "C:\AS_21A21_FPGA_ISE14_7\ITPModul.vhd" Line 872: found '0' definitions of operator "+", cannot determine exact overloaded matching definition for "+"

Was sollen die Vortteile sein ? Gruss Anton

Hallo Anton,

rechnen mit std_logic_vector ist nicht gut, da hier dem Syntehese Tool nicht klar ist, wie die Formatierung ist. Beispiel: std_logic_vector(15 donwto 0); Damit kannst du unsigned von 0 bis 65535 darstellen oder signed von -32786 bis 32785; Wenn du die neuen Bibliotheken verwendest wirst du gezwungen ordentlich vorzugeben, was für Datentypen du darstellen willst. Daher weniger anfällig. Daher wird das nicht verkompliziert, sondern der Entwickler muss ganz explizit angeben was er will. Das ist doch nicht schlecht, oder?

Und bei dir ist es so, dass du den Datentyp integer noch mit reinmischt. Das wird noch übler. Der passt da nicht so rein. Da sind unsigned und signed besser. Wenn du alles mischt, dann gibt es ein großes Chaos und führt zu Fehlern. Ist bei dir ja so, da ja Module wegoptimiert werden, obwohl du das so nicht möchtest. Du und dein Synthese Tool redet aneinander vorbei! ;-)

Zu deinen Fehlern: Mir scheint du mischt zwischen 1 und '1'. Das eine ist ein Integer und das andere ein std_logic, signed oder unsigned. Das musst du richtig casten.

Grüße, Jens

Hallo Jens, Stimmt das war ein fehler ( 1 oder '1'),der ich übersehen habe, nur nach beheben von einigen Fehler konnte ich neu kompilieren, im Mapreport sehe ich nach wie vor das ganze Menge von CORES entfernt werden (in der alte unkorigierte version). Im processs RUNANGLE benütze ich praktisch nur SLV(31 DOWTO 0) für die Inputs und Outputs Signale für die CORES (man darf hier nur SLV benützen). Heufig starte ich mehrere CORES gleichzeitig uber ce...., es ist mir aufgefallen das genau die CORES entfernt werden die Parallel gestartet wurden. vermutlich hat der Kompiler damit problem. Siehe ITPModul.vhd in der beilage, im Implementationteil am Filesende, Danke, dass Ihr mich darauf aufmerksam gemacht haben das ich obsolete Library benütze, selbsverständlich werde ich es korrigieren (erst 2 module habe ich gemacht) , aber das eigentliche problem hat es nicht gelöst. Ich versuch jetzt an einigen Stellen die CORES nacheinander zu starten. Gruss Anton

Hallo Anton,

welche Cores werden denn entfernt? Es ist ein bisschen schwierig, das aus dem process Runangle heraus zu suchen. Und welche Fehlermeldung steht im Synthese Report (also warum wurde das entfent. Das gibt ein Hinweis, was falsch sein könnte)?

Ich mutmaße mal: Es könnte sein, dass das Umschalten deines Processes durch die States nicht richtig funktioniert. Die Verzögerung machst du mit einer Variablen. Da gilt das Ergebnis gleich. Anders wenn es ein signal wäre. Dann wäre das Ergebnis einen Takt verzögert. Schau die ctrclk genau an. Das setzt du auf 1 und willst 1 subtrahieren und vergleichst auf 0. Wenn das alles gleichzeitig geht, dann gibt es unter dem Strich keine Verzögerung. Dadurch ist auch das Ergbenis von den Cores noch nicht da. Und vielleicht werden die Cores daher entfernt, da du die Ergbenisse ja nicht nutzen kannst (Die gibt es ja noch nicht). Die Struktur bläht das auch sehr auf. Die Verzögerung wird in jedem State neu implementiert. Heißt, jeder State hat diesen Subtrahierer. Das kostet enorm Ressourcen. Ich empfehle dir die Statemachine so umzubaunen, dass du spezielle states für die Verzögerung hast und die explizit anspringst. Der Rest wird dann auch deutlich lesbarer, da die ganzen "if () then else" in den States entfallen.

Grüße

Hmm, ich hab noch etwas anderes gefunden:

In deinem Process sind in der sensitvity list nur "clk". Reicht das? Da müssten mehr Signale sein. Mindestens noch der "reset" und "ImpLk". Wenn das nicht stimmt, dann bekommst du auch die tollsten Verhalten!

Mach mal folgendes: Änder den Process zu

1

runangle:PROCESS()   <-- DIESE ZEILE

2

VARIABLE ctrclk :INTEGER RANGE 0 TO 127:= 0;

3

VARIABLE startON :std_logic:= '0';

4

BEGIN

5

  wait until (rising_edge(clk));  <-- DIESE ZEILE  

6

7

  IF nrst = '0' THEN

8

        ....

9

        ELSE

10

        ....

11

        ENDIF;

Wenn du "wait until..." verwendest, dann musst du die Sensitivity List nicht mehr angeben. Dann gibt es auch keine fehlenden Signale mehr.

Grüße, Jens

Hallo Jens Tolle Idee mit der Verlagerung der If tehen else in separate modul. Das mache ich. Das mit der Verzögerung habe ich untersucht, in der Simulation scheint es richtig laufen, siehe beilage, das CORE mulFP mit Ausgang mul12 wird entfernt.Ist es möglich das nach compilation anderes verhalten da ist. Was die Sensitivity List anbelangt, so empfehlen die Xilinx(AMD) Leute es soll für Kintex7 nur voll synchrone betrieb sein d.h. auch das nrst soll voll synchron mit clk. Darum synchronisiere ich in separaten modulen alle Eingänge mit dem clk. Aber ich kann Dein Vorschlag ausprobieren, die Xilix Leute sind nicht allwissend. Nun habe ich eine neue Version gemacht (wo mulFP nicht parallel läuft) und warte bis es kompiliert wird (2 std) und dann sehe ich am Roboter ob es Aenderung gibt. Gruss Anton

Hallo Jens noch etwas ist sonderbar, bis zu STATEANGLE = 26 läuft alles auch im FPGA richtig. Wird der Compiler durch die viele If Then ELSe überfordert ? Gruss Anton

Simon R. schrieb:

Ein Mutliplizierer ist aber hart verdrahtet und hat keine pipeline Register.

Kommt wohl sehr auf das FPGA an. Die Xilinx US+ haben jedenfalls Register im DSP Block. Ob man die verwendet oder nicht hängt von der HDL Beschreibung ab oder wie man den IP Core (falls man den verwendet) parametrisiert.

Anton K. schrieb:

Wird der Compiler durch die viele If Then ELSe überfordert ?

Sicher nicht.

Resultat der letzte kompilation....siehe beilage

Was sagt denn der Synthesis Report? Da sollten schon Hinweise drin sein, wenn dann später beim Map etwas entfernt wird.

Anton K. schrieb:

Was die Sensitivity List anbelangt, so empfehlen die Xilinx(AMD) Leute es soll für Kintex7 nur voll synchrone betrieb sein d.h. auch das nrst soll voll synchron mit clk. Darum synchronisiere ich in separaten modulen alle Eingänge mit dem clk.

Da mischt du zwei Sachen zusammen. Man soll keinen asynchronen Reset verwenden. Das machst du ja schon richtig. Deiner ist synchron. Aber du musst bei deiner Version trotzdem die Sensitivity List richtig angeben.

Anton K. schrieb:

die Xilix Leute sind nicht allwissend.

Ich denke nicht, dass ich das besser als die Leute von Xilinx bin! Sicher nicht! :-)

Grüße, Jens

Ich sende Synthese und Map report. Im Map report sehe ich häufig immmer den cIntFPAx block (Berechnung der Deformation), liegt die Ursache am anderer ort im TopAS21 ?

Hallo Jens Soll man also bei allen Processen die until Version verwenden ? Bei runangle habe ich es schon gemacht, warte was nach der Kompilation passiert - Gruss Anton

Hallo Jens da bekome ich mit der Aenderung auf until.. riesenlange Fehlerliste mit
94 error. Etwas fehlt ? Gruss Anton

Hallo Anton,

hast du bei process(clk) geändert zu process()? Da darf nichts mehr in der Klammer stehen.

Wenn es das nicht ist, dann poste mal die Fehler.

Grüße, Jens

Anton K. schrieb:

Soll man also bei allen Processen die until Version verwenden ?

Nein, das ist egal ob du

1

process(clk)

2

begin

3

   if rising_edge(clk) then

4

5

   end if;

6

end process;

oder

1

process()

2

begin

3

   wait until rising_edge(clk);

4

5

end process;

verwendest, es wird exakt die gleiche Hardware gebaut.

Hallo Gustl,

das hat bei mir in der Synthese aber Fehler geworfen. Ist da Xilinx eigen? Ich habe es gerade nochmal in meinem eigenen Design probiert. Wenn ich das schreibe, wie du oben angegeben hast, dann kommt folgende Fehlermeldung: ERROR:HDLCompiler:732 - "D:\Xilinx_Projekts\Xmega-FOC_V1.0.00\FOC_Operation.vhd" Line 195: Process cannot have both a wait statement and a sensitivity list.

Man muss sogar schreiben:

1

process

2

begin

3

   wait until (rising_edge(clk));

4

5

end process;

Also sogar die Klammer muss ich weglassen. Dann gibt es auch keine Fehlermeldung mehr.

Grüße, Jens

Du hast natürlich Recht, man muss die Klammern weglassen.

Aber du meintest was anderes, oder?

Du hast Recht, das if() then else statement und das wait until statement synthetisiert genau gleich. Nur die Schreibweise ist anders.

Ich habe für mich nur das wait until() angewöhnt, da ich sonst auch mehrfach Fehler bei der sensitivity list hatte.

Wie ist denn deine Meinung? In dem Code, den Anton gepostet hat, sind sehr viele Prozesse drin. Ich würde immer nur einen Prozess verwenden pro File und die Verschaltung in der Top Entity machen. Wie ist denn deine Empfehlung?

Grüße, Jens

Gute morgen Jens Das mit dem wait until funktioniert nicht ,einige varianten probiert anzahl fehler 93..95:

runangle:PROCESS() -- zeile 1464 ----runangle:PROCESS, auch probiert VARIABLE ctrclk :INTEGER RANGE 0 TO 127:= 0; VARIABLE startON :std_logic:= '0'; BEGIN ---wait until Clk'event and clk = '1'; -- auch probiert wait until (rising_edge(clk));
--IF rising_edge(clk) THEN -- org IF nrst = '0' THEN stateangle <= 0; ctrclk := 0; FXYZaOK <= '0'; --....... END IF;-- nrst if/else --END IF; --clk END PROCESS;-- end runangle, zeile 1825

INFO:HDLCompiler:1061 - Parsing VHDL file "C:/AS_21A21_FPGA_ISE14_7/synch.vhd" into library work ERROR:ProjectMgmt - 92 error(s) found while parsing design hierarchy. INFO:HDLCompiler:1061 - Parsing VHDL file "C:/AS_21A21_FPGA_ISE14_7/AxConv.vhd" into library work INFO:HDLCompiler:1061 - Parsing VHDL file "C:/AS_21A21_FPGA_ISE14_7/CosFP.vhd" into library work INFO:HDLCompiler:1061 - Parsing VHDL file "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" into library work -- ausserhalb von runangle--------------------- ERROR:HDLCompiler:806 - "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" Line 1918: Syntax error near "PROCESS". ERROR:HDLCompiler:806 - "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" Line 1924: Syntax error near "BEGIN". ERROR:HDLCompiler:806 - "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" Line 1948: Syntax error near "PROCESS". ERROR:HDLCompiler:806 - "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" Line 1959: Syntax error near "port". ERROR:HDLCompiler:806 - "C:/AS_21A21_FPGA_ISE14_7/ITPModul.vhd" Line 1960: Syntax error near "port".

Liegt das Problem am Werkzeug :ich verwende ISE 14.7(nt), versP.20131013 installiert 2019, bisher kaum Probleme damit gehabt Umschahalten auf vivado ist nicht gegangen weil CORES in Vivado sich vielfach unterscheiden von CORES in ISE 14.7 Grus Anton

Anton K. schrieb:

warum findest Du es gut, die NUMERIC std verkompliziert ja enorm ,

Finde ich nicht. Sie führt zu klaren Schnittstellen.

Ich hatte schon Projekte auf dem Tisch die falsch gerechnet haben, weil der eine Entwickler im ersten Modul mit std_logic_signed gerechent hat und der nächste Entwickler im nächsten Modul mit std_logic_unsigned. Im übernächsten Modul war dann wieder std_logic_signed Mode :-(

Simon R. schrieb:

Ein Mutliplizierer ist aber hart verdrahtet und hat keine pipeline Register.

Wenn man im (Xilinx-)FPGA Multiplizierer haben möchte, dann verwendet man als erstes die MUL oder DSP-Blöcke. Und die haben nun mal (mehrere) Register, damit man dort auf Speed kommt. Ausgänge vorzubelegen ist natürlich Quatsch.

Jens W. schrieb:

In dem Code, den Anton gepostet hat, sind sehr viele Prozesse drin. Ich würde immer nur einen Prozess verwenden pro File und die Verschaltung in der Top Entity machen. Wie ist denn deine Empfehlung?

So wenig Prozesse wie möglich, sonst kommt man leicht durcheinander.

Wenn man nur einen Takt hat, dann reicht i.d.R. auch ein Prozess pro Datei bzw. Entity. Das erhöht sich, wenn mehrere Taktdomänen ins Spiel kommen oder die 2-Prozsee-Methode verwendet wird: https://www.gaisler.com/doc/vhdl2proc.pdf

BTW:

1

  type T_recstate is (S0, S1, S100,

2

                      S11, S12, S2, S3, S30,

3

                      S300, S301, S302, S303, S304, S305, S306, S307, S308, S309,

4

                      S31,

5

                      S310, S311, S312, S313,

6

                      S32, S320, S321, S322,

7

                      S33, S34, S340, S35, S36, S37, S38,

8

                      S39, s391, s392, s393, s394,

Ich würde bei dieser Benennung der States nach zwei Tagen nicht mehr durchblicken.

Bei mir sieht das z.B. so aus:

1

    type tx_state_type is (idle, dest0, dest1, dest2, dest3, dest4, dest5, source0, source1, source2, source3, source4, source5, ethtype0, ethtype1, data);

2

    signal tx_state     : tx_state_type := idle;

Hallo Rick Ich möchte hier zu bedenken zu den verschiedenen Aenderungsvorschlägen; Es funktioniert alles im FPGA tadellos mit eine Ausnahme und die ist der Process RUNANGLE im ITPmodul. Die gesamte sehr komplizierte komunikation zum überordnete CPU über die bidirektionale 8 bit Schnittstelle (das riesige Statediagram S0.. S9) lässt sich leider nicht anders machen, wenn man als Ausserstehende nicht den durchblick hat, ich habe es. Und die kommunikation funktioniert tadelos. Auserdem auch die kommunikation zum Roboter und die ganze Achsenpositionierung. Zugegeben das die SDI komunikation könnte in ein separate modul ausgelagert werden, aber die läuft ebenfalls wie auch positionieren der Achsen (sog. LinStz Befehle: interpoliieren innerhalb eine Ebene),usw,usw. Also vorläufig werde ich nicht am Top21 ändern sowie einem grossen Teil von ITPmodul. Mein einzige Problem ist die InversTransformation die im RUNANGLE statfindet. Meine Vermutung, dass es am parallel laufen von CORES liegen könnte hat sich falsch erwiesen. Langsam habe ich den verdacht ob es am Werkzeug selber liegt das da überfordert wird. Als nächstes werde ich versuchen den Process RUNANGLE zerstückeln. Gruss Anton

Hallo Rick Ich möchte hier zu bedenken zu den verschiedenen Aenderungsvorschlägen; Es funktioniert alles im FPGA tadellos mit eine Ausnahme und die ist der Process RUNANGLE im ITPmodul. Die Deformationberechnung im Top21 ist noch nicht getestet darum weiss ich nicht ob evt. hier problem sein könnte, dies konnte ich auch versuchseweise abschalten. Die gesamte sehr komplizierte komunikation zum überordnete CPU über die bidirektionale 8 bit Schnittstelle (das riesige Statediagram S0.. S9) lässt sich leider nicht anders machen, wenn man als Ausserstehende nicht den durchblick hat, ich habe es. Und die kommunikation funktioniert tadelos. Auserdem auch die kommunikation zum Roboter und die ganze Achsenpositionierung. Zugegeben das die SDI komunikation könnte in ein separate modul ausgelagert werden, aber die läuft ebenfalls wie auch positionieren der Achsen (sog. LinStz Befehle: interpoliieren innerhalb eine Ebene),usw,usw. Also vorläufig werde ich nicht am Top21 ändern sowie einem grossen Teil von ITPmodul. Mein einzige Problem ist die InversTransformation die im RUNANGLE statfindet. Meine Vermutung, dass es am parallel laufen von CORES liegen könnte hat sich falsch erwiesen. Langsam habe ich den verdacht ob es am Werkzeug selber liegt das da überfordert wird. Als nächstes werde ich versuchen den Process RUNANGLE zerstückeln. Gruss Anton

Hallo Anton,

am Tool liegt das nicht. Ich verwende auch die ISE 14.7. Im Synthese Report von dir sind noch 26000 Warnungen. Da würde es mich nicht wundert, wenn alles läuft. Dann wären es weniger Warnungen.

Poste mal bitte deine letzte Version der Datei. Ich bau den Process runangle mal nach. Dann kann ich selbst schauen, was da nicht stimmt. Nur heute schaffe ich es nicht mehr. Ab morgen hab ich Zeit und würde die auch investieren.

Grüße, Jens

Hallo Jens, das ist sehr lieb, vielen Dank. Das herauszulösen ist ja gar nicht zu einfach, aber wenn RUNANGLE schon die Achsen A1FP und A2FP Liefert für die Startposition ist damit schon gewonen. Bis jeztzt Liefert es nur A0FP,A3FP,A4FP , die A1FP und A2FP bleiben Null. Das RUNANGLE solLte die Achsenwerte in FPformat liefern. Die Werte für Test Startposition :XS=500,YS=-200,ZS=120, Weiter Benötigt man XT=-200,YT=500,ZT=-170, Die Werte Für L1=350,L2=390,L3=150. Start des RUNANGLE mit dem Impuls ImpLK = '1' , 1 takt, CLK ist 100MHz ZuM RUNANGLE werden noch andere SRC file benötigt für div Trig.Fkt die mit Taylor Aprox. Rechnen , wg. bessere Geauigkeit als im CoreGen. Wie kann ich mich bei Dir revanchieren ? Gruss Anton

Hallo Jens Gute Morgen. Hier die Werte die meine Simulation Liefert für die StartPosition : A1FP = 3F9B3277 = 1.2124776 rad A2FP = BFB0DF87 = -1.3818215 rad In etwa selbe Werte bekome ich von der Grafische Simulation im sketch. Darf ich Dich fragen mit was für Hardware baust Du es auf ? Es wäre für mich nützlich auch ein System zu haben wo ich kann in der Hardware etwas aufbauen und die Signale dann anzuschaen. Gruss Anton

Hallo Anton,

ich räume dir erstmal runangle auf. Beim Rest, das wird schwierig, da ich deine IPCores ja nicht habe. Aber wir werden sehen.

Also, der Reihe nach: Du hast oben die alten Librarys wieder eingefügt. Du hast da vermutlich zurück gebaut. Das ist keine gute Idee!

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.STD_LOGIC_ARITH.ALL;

4

--use IEEE.STD_LOGIC_UNSIGNED.ALL;

5

use ieee.std_logic_signed.ALL;

6

--USE ieee.math_real.all;

7

use IEEE.numeric_std.all;

Die vertragen sich nicht miteinander!

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.NUMERIC_STD.ALL;

Mehr brauchst du nicht!

Dann scheinst du eine Reihe Signal zu haben, die nicht verwendet werden. Da kannst du mal aufräumen, damit du den Überblick nicht verlierst.

Ich habe runangle mal ausgeschnitten in eine eigene Datei. Da sind nur die Signale drin, die in runangle verwendet werden. Den Rest habe ich erstmal rausgeschmissen. Ich habe auch auf das wait_until() Statement geändert und das synthetisiert erstmal ohne Fehler. Beachte auch, dass wenn du nicht mehr dein IF rising_edge(clk) THEN verwendetst, dass du auch am Ende das ENDIF für die If-Anweisung entfernst! Sonst gibt es natürlich Fehler!

Als nächstes werde ich den Prozess, den du gebaut hast, ein bisschen verschlanken. Und ich werde für die Verzögerungen, in denen du auf Ergebnisse wartest, in Signale ändert. Das funktioniert bei mir gut.

Schau dir bis dahin mal das File von mir an und vergleiche mit deinem!

Grüße, Jens

Frage: Was machst du denn mit der Variable startON? Die wird zwar zugewiesen, aber ich finde nichts, dass die auch mal verwendet wird. Und das ist gerade im State 27, wo bei dir etwas wegoptimiert wird!

Grüße, Jens

Hallo Jens bei mir ist gerade Internet ausgestiegen, zur not schreibe ich über mobile hotspot. am nachmittag soll ein Monteur kommen. in der zwischenzeit scchaue ich was mit dem start on ist, Gruss Anton

Hallo Jens StartON :das ist obsolet, die Variable brauche ich nicht mehr, habe vergessen es konsequent entfernen. Es kommt auch vor in Bresenham process als Variable, dort braucht auch nicht mehr, hier muss nur "IF strimp = '1' Then" sein und das überall startON weglassen.

Hallo Anton,

kein Stress! Im Anhang die aktuelle Version. Ich habe alle "Warte-Schleifen" von dir in einen eigenen State gepackt. Mit dem neuen Signal merke ich mir, wo es danach weiter gehen soll. Wenn du also eine Wartezeit brauchst, dann machst du folgendes:

• weise die Wartezeit zu auf ctrclk
• definiere mit den nächsten State mit next_stateangle
• springe in den Warte-state

Damit fallen in den einzelnen cases die If-statements alle weg. Und damit sparst du dir auch in jedem State den Subtrahierer. Das Zeug wird ja alles parallel gebaut! Das ist anders als in Software! (und du kommst aus der SW-Entwicklung oder? Deine Struktur verrät das!)

Aber! Das Verhalten ist ein bisschen geändert. Du setzt ja in den States die CE-Signale für deine Cores, damit da was berechnet wird. Bisher waren die CE-Pulse immer nur einen Takt lang. Jetzt sind die Pulse so lange wie die Wartezeit. Macht vermutlich nichts, aber wenn doch, dann müsste man Zwischenstates einbauen. Auch keine große Sache. Oder du trimmst das hin, über die Wartezeit.

Man kann aber auch den FP-Core so bauen lassen, dass es ein Signal gibt, wenn der fertig ist (das würde ich machen). Dann brauchst du gar keine Wartezeit mehr. Dann "pollst" du das Signal für "Berechnung fertig" und erst dann springst du in den nächsten State.

Wie soll es weiter gehen? Zwischenstates einbauen oder Signal pollen?

Grüße, Jens

Hallo Jens Entschuldige,Ja ich habe zuletzt wieder auf mein alte backup zurückgeschaltet weil am schluss überhaupt nichts gelaufen ist. Die von Dir vorgeschlagene Aenderungen habe ich in 2 modulen machen können aber am schluss daran gescheitert mit z.Bsp XLinAbs <= (Xlin XOR X"FFFF") + 1;--nur ein neg => pos umkehrung da habe ich mit std_logic_vector(unsigned(Xlin) XOR X"FFFF")) + '1') probiert aber das hat NUMERIC nicht passt. Am schluss , da ich weiter machen musste habe ich zurück auf mein backup zurück gegriffen Grüsse Anton

PS.Ich bin immer noch in Mobile Hotspot, muss ich wieder ausschalten

Warum ist denn die Belegung der Ausgangssignale noch drin?

1

        calcok   : out std_logic                     := '0';  -- signalisiert alle berechnungen sind fertig

2

        XAout    : out std_logic_vector(31 downto 0) := X"00000000";  --virtuelle aktuelle koordinate

3

        YAout    : out std_logic_vector(31 downto 0) := X"00000000";

4

        ZAout    : out std_logic_vector(31 downto 0) := X"00000000";

5

        ITPmod   : out std_logic_vector(2 downto 0)  := "000";  --ITP für Status Meldung an CPU

6

        oAXdif   : out std_logic_vector(95 downto 0) := (others => '0');  --Sollwertdiff(16Bit) von  inv.Transfer und Lin

7

        oImpLk   : out std_logic                     := '1';  --impulse von xyz itp

8

        enditp   : out std_logic                     := '0';  -- ende von Kontur:=0 (enditp-)

9

        itprun   : out std_logic                     := '0';  -- =1:interpolator läuft,aktuelle Sollwerte in oAXinkr(6x 32bit)

10

        testdata : out std_logic_vector(15 downto 0) := X"0000"

Hallo Anton,

verstehe. Aber das kann ein Problem werden! Wie oben schon geschrieben, die alten Bibliotheken machen Probleme. Du wirst nicht drumrum kommen auf die neuen Libs zu ändern. Du musst nur auf den richtig Datentyp casten. Das müsste so aussehen:

1

-- achte auf die richtigen Klammern!

2

XLinAbs <= std_logic_vector((signed(Xlin XOR X"FFFF")) + 1);

Ich habe es mit deinen Libs auch mal synthetisiert und da kommt das gleiche raus bei mir (gleiche Warnungen, keine Fehler).

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.STD_LOGIC_ARITH.ALL;

4

--use IEEE.STD_LOGIC_UNSIGNED.ALL;

5

use ieee.std_logic_signed.ALL;

6

--USE ieee.math_real.all;

7

--use IEEE.numeric_std.all;   <--- rausnehmen

Nur die numeric_std würde ich dann mit rausnehmen.

Grüße, Jens

Hallo Jens vielen Dank für die viele Arbeit. Leider ist die neueste version von RUNANGLE nicht mitgekommen. Ich habe seit 30 Jahren Hardware für CNC Steuerungen entwickelt, zunehmend ist dazu immer mehr Software.Die Letzte CNC Generation war mit Spartan6 bestückt,also ein reine Softies bin ich nicht. Warte jetzt auf deine neue Version. Grüsse Anton

Hi Anton,

sorry, da ist wohl beim Anhängen der Datei was schief gelaufen. Ich versuche es nochmal.

Was ist denn mit der Variable startON? Kann die weg? In runangle wird sie nicht verwendet.

Grüße, Jens

Als nächstes würde ich die mulFP Cores mit rein nehmen und schauen, ob die in runangle auch entfernt werden. Sollte nicht, da es momentan auch keine Fehlermeldung gibt.

Aber klar, da fehlt auch noch ein großer Teil! Heute Abend mach ich noch ein bisschen weiter.

Du könntest versuchen dein runangle gegen meines auszutauschen und dann sehen, ob immernoch Fehler drin sind, also ob was wegoptimiert wird.

So wie ich deine Struktur verstehe sind Control Logik und Datenpfad getrennt. Das finde ich gut, das mache ich auch so. Die Daten (also das was berechnet werden soll) reichst du von einer Componente (mulFP,...) zur nächsten weiter. Und wann wer was machen soll wird in den Processen aus ITPmodul gesteuert.

Wenn also die Steuersignale aus ITPmodul richtig kommen, kann man parallel schauen, ob Daten von einer Componente zur nächsten verloren gehen.

Nebenbei: Die CE Signale für die einzelnen Cores bräuchtest du nicht. Da könntest du komplett drauf verzichten (soweit ich das gesehen habe). Wenn du an einen FP-Core sinnvolle Eingangswerte anlegst, brauchst du nur warten, bis das Ergebnis am Ausgang ansteht. Und so lange sich die Eingänge nicht ändern, ändert sich auch der Ausgang nicht.

Grüße, Jens

Hallo Jens also den ganzen ITPModul habe ich geschafft mit der Umstellung für NUMERIC std mit 2 Ausnahmen ?? : ---------- ursprünglich----------- --IF Lka < Lk THEN..Lka:integer,LkSLV(31..0) ---Lka <= Lka + 1; --------neu ---------------------------- IF (to_unsigned(Lka,32) < to_integer(unsigned(Lk))) THEN Lka <= to_integer(to_unsigned(Lka,32) + 1);

da gibt es zuerst fehler,später dann keine, komisch??

Hallo Anton,

das ist ein schönes Beispiel! Da vergleichst du einen std_logic_vector mit einem Integer.

Da zwingt dich numeric_std, dass du hier ordentlich vorgibst, wie der std_logic_vector zu verstehen ist. Signed, Unsigned, was auch immer. Und wenn du das sauber vorgegeben hast, dann synthetisiert das auch immer gleich. Egal auf welcher Plattform. Genau das ist der Vorteil von nureric_std!

Gruß, Jens

Hallo Jens So probierte ich mit dem Neuen REUNANGLE die Synthese neu. Also nach der Synthese und generieren des Prog.Files, Schaute ich ich den MAP report,.. Keine Aenderung, nach wie vor fast alle Coregen componenten werden removed,darunter auch das mul12 usw. Ich habe parallel be Xilinx angefragt und habe ich diese interesante Antwort erhalten: siehe Anhang Was meinst dazu ? Werde suchen ob ich es finde. Bitte kannst du mir die letzte von dir geänderte Version von RUNANGLE senden? Grüsse Anton

Hallo Anton,

ich weiß nicht genau was du meinst? Die letzte Version, wo ich runangle geändert habe, ist ein paar posts weiter oben angehängt. Oder meinst du eine andere Version? Was genau brauchst du von mir?

Hast du das verwendet und dann kamen die Fehler? Oder hast du da noch andere Sachen geändert?

Grüße, Jens

Hallo Jens Vermutlich meinte ich das Du noch etwas mehr geändert hast, und wolte mit meinen Aenderungen vergleichen. Ich bin seit gestern dabei den gesamten Projekt auf NUMERIC std abzuändern. Als letzte bin ich daran den TOP zu ändern, das ist ein grosse Brocken. Danach werde ich wieder eine Compilation probieren. Melde mich dann. Ein Problem : CtrlReg(11 DOWNTO 10) :=std_logic_vector((Unsigned(ChanelNr) +1),2);

Error: ../TopAS21.vhd(5075): (vcom-1583) Illegal type converson from 'std.STANDARD.INTEGER' to 'ieee.NUMERIC_STD.UNSIGNED' (numeric to array).

muss ich hier eine zwischenvariable machen ? Gruss Anton

Anton K. schrieb:

CtrlReg(11 DOWNTO 10) :=std_logic_vector((Unsigned(ChanelNr) +1),2);

Das Problem ist das ":=" das kannst du so nicht verwenden. Du musst "<=" verwenden.

Gruß, Jens

Hallo Jens Nun habe der gesamte Process auf NUMERIC STD geändert dazu bei allen Processen das wait until. Resultat ist ziemlich ernüchternd. Nach der Generierung von Prog.file und Laden in PROM /Starten FPGA funktioniert gleich wie vorher, einige Kleinigkeiten müssen noch korriert werden, aber im Grossen und Ganzen hat sich überhaupt nicht geändert, Achsen A1,A2 = Null, Im Map report sieht man auch das die ensprechende Komponenten "removed" werden, genau die,die es verhindern das die 2 Achsen Kalkulation nicht durchgeführt wird. Nur etwas ist mir aufgefallen: Number of LOCed IOBs =100% avaiable=159,used=159, alle andere resourcen sind meistens unter 50%. Ist da irgendwo maximum erreicht und darum werden die kopmponenten entfernt? Ich wersuche demnächst die Deform.Berechnung die sehr aufwendig und im moment nicht benötigt ist wegzulassen Gruss Anton

Anton K. schrieb:

Number of LOCed IOBs =100%

Das ist gut, wenn da 100% stehen, weil dann alle IO-Signale am dem Pin rauskommen, welches im Constraint-File angegeben ist.

avaiable=159,used=159,

Du hast 159 IOs und alle sind in Verwendung.

alle andere resourcen sind meistens unter 50%.

Das ist gut so. Wenn eine Ressource auf 100% geht, kann der Rest manchmal noch auf normale Logik gemappt werden, aber im Prinzip wäre dann das Design zu groß für das jeweilige FPGA.

Kannst Du evtl. jetzt das aktuelle ITPModul.vhd nochmal hier einstellen?

Hallo Anton,

das ist natürlich ernüchternd, wenn da nicht gleich alles geht. Dennoch ist das nicht umsonst! Die Arbeit hast du richtig investiert!

Und den Rest findet man jetzt auch noch!

Bitte poste nochmal deine letzte Version von ITPmodul.vhd.

Grüße, Jens

Hallo Jens Ja das ist wie verhext. Ich habe mir grosse Hoffnungen gemacht. Anbei der geänderte ITPModul. Schöne Abend Anton

Hallo Anton,

ich schau mir nochmal das gesamte Modul an. Ich brauche ein bisschen, da sehr viele Cores verwendet werden. Mal sehen, ob ich das alles rekonstruieren kann.

Gibt es für das Modul ITPmodul.vhd eine Testbench? Die wäre noch wichtig, damit man das mal testen kann, was da so los ist.

Grüße, Jens

Hallo Jens Nein es gibt nur eine sehr komplexe testbench die überordnete CPU mit allen Meldungen simuliert. Aber ich könte eine mal machen, braucht nicht allzuviel Aufwand. Nur für RUNANGLE oder für den ganzen ITPModul ? Gruss Anton

Hallo Anton,

nur für Runangle wäre gut, dann könnte ich den ausgeschnittenen Prozess von mir testen.

Mir ist noch etwas aufgefallen:

1

WHEN 27 => -- A3FP :=sub1min * AZFP, a3FP fertig,FL11^2,Fl2^2,FL12^2 

2

          IF ctrclk > 0 THEN

3

            ctrclk := ctrclk - 1;

4

            cesqL <= '0';--FL11^2,Fl2^2,FL12^2=> SqL1,sqL12,sqL2  fertig

5

            ceA3FP <= '0';--a3FP fertig

6

            stateangle <= 27;

7

          ELSE  

8

            IF strImp = '0' THEN

9

              --StartON := '0';

10

            END IF;

11

            ceadd1<= '1'; -- startsqL1+sqL12,Fl12*FL1

12

            ctrclk := clkTomul;

13

            stateangle <= 28;

14

          END IF;

Kannst du das mal testen, ob das was hilft?

Grüße, Jens

Das ist der state, wo der mulFP wegoptimiert wird. Da muss ein Fehler sein! Schau mal genau auf den ELSE-Pfad. Da ist eine zweite if-Abfrage auf strImp. Das signal wir für Start-Interpolation genutzt. Aber die Anweisung ist dann leer, da du StartOn nicht verwendest. Jetzt ist das eine if-Abfrage ohne else-Zweig. Das hat bei mir schon Probleme gemacht. Danach kommt direkt das ceadd1 <= '1'. Das ist das Ce-Signal, das direkt auf den mulFP geht, der wegoptimiert wird. Entferne mal komplett die nicht-genutzte if-Anweisung. Also:

1

WHEN 27 => -- A3FP :=sub1min * AZFP, a3FP fertig,FL11^2,Fl2^2,FL12^2 

2

          IF ctrclk > 0 THEN

3

            ctrclk := ctrclk - 1;

4

            cesqL <= '0';--FL11^2,Fl2^2,FL12^2=> SqL1,sqL12,sqL2  fertig

5

            ceA3FP <= '0';--a3FP fertig

6

            stateangle <= 27;

7

          ELSE  

8

            ceadd1<= '1'; -- startsqL1+sqL12,Fl12*FL1

9

            ctrclk := clkTomul;

10

            stateangle <= 28;

11

          END IF;

Jetzt ist mein Post durcheinander geraten. Die Grüße musst du dir an den Schluß denken ;-)

Gute Morge Jens Ja furchtbar das ich es nicht gesehen habe, so ein Blödsinn, wie ein Anfänger. Dabei, habe ich es x mal angeschaut. Grüsse Anton

Hallo Jens Von laute Aerger über mich habe vergessen Dir vielen Dank zu sagen Grüsse Anton

Guten Morgen Anton,

war es das? Funktioniert es jetzt?

Grüße, Jens

Eine rudimentäre Testbench ist im Anhang. Die Simulation startet damit:

1

$ vcom *.vhd

2

Model Technology ModelSim SE-64 vcom 10.7f Compiler 2020.03 Mar 23 2020

3

Start time: 08:43:39 on Aug 22,2024

4

vcom addfp.vhd afkt.vhd arcCosFP.vhd atanFP.vhd axconv.vhd cmpgr.vhd compfp.vhd CosFP.vhd divfp.vhd fptoint32.vhd func_c.vhd int16tofp.vhd inttofp.vhd ITPModul.vhd ITPModul_tb.vhd mulfp.vhd sqrtfp.vhd subfp.vhd 

5

-- Loading package STANDARD

6

-- Loading package TEXTIO

7

-- Loading package std_logic_1164

8

-- Loading package NUMERIC_STD

9

-- Compiling entity addFP

10

-- Compiling architecture test of addFP

11

-- Loading package std_logic_arith

12

-- Loading package STD_LOGIC_UNSIGNED

13

-- Compiling entity afkt

14

-- Compiling architecture Behavioral of afkt

15

-- Compiling entity arcCosFP

16

-- Compiling architecture Behavioral of arcCosFP

17

-- Compiling entity atanFP

18

-- Compiling architecture Behavioral of atanFP

19

-- Compiling entity AxConv

20

-- Compiling architecture test of AxConv

21

-- Compiling entity cmpgr

22

-- Compiling architecture test of cmpgr

23

-- Compiling entity compFP

24

-- Compiling architecture test of compFP

25

-- Compiling entity CosFP

26

-- Compiling architecture Behavioral of CosFP

27

-- Compiling entity divFP

28

-- Compiling architecture test of divFP

29

-- Compiling entity FPtoInt32

30

-- Compiling architecture test of FPtoInt32

31

-- Compiling entity func_c

32

-- Compiling architecture Behavioral of func_c

33

-- Compiling entity int16ToFP

34

-- Compiling architecture test of int16ToFP

35

-- Compiling entity IntToFP

36

-- Compiling architecture test of IntToFP

37

-- Compiling entity ITPModul

38

-- Compiling architecture Behavioral of ITPModul

39

-- Compiling entity ITPModul_tb

40

-- Compiling architecture testbench of ITPModul_tb

41

-- Loading entity ITPModul

42

-- Compiling entity mulFP

43

-- Compiling architecture test of mulFP

44

-- Compiling entity sqrtFP

45

-- Compiling architecture test of sqrtFP

46

-- Compiling entity subFP

47

-- Compiling architecture test of subFP

48

End time: 08:43:39 on Aug 22,2024, Elapsed time: 0:00:00

49

Errors: 0, Warnings: 0

Ich habe die Simulation etwas erweitert. Jetzt knallt es hier:

1

# ** Fatal: (vsim-3421) Value 15 is out of range 0 to 2.

2

#    Time: 335 ns  Iteration: 0  Process: /itpmodul_tb/dut/runITPlin File: ITPModul.vhd Line: 861

Das ist die zugehörige Codezeile:

1

  iEB := to_integer(unsigned(Ebene));-- Ebene für linSatz

iEB darf nur Werte zwischen 0 und 2 einnehmen, aber Ebene hat vier Bit...

Gute Morge Jens Guete Morge Rick D Leider ist es nicht,das wäre zu schön. Auch nach der Aenderung ,alles beim gleichem. Jens vielen Dank für Deine Testbench werde ich zuerst anschauen. Rick , Ja das mit dem iEB muss ich überprüfen. Gruss Anton

Hallo Rick D Danke für den Hinweis, das habe ich korrigiert,aber wenn RUNANGLE läuft wird runITPlin gar nie aktiv, und iEB ist nicht in RUNANGLE vorhanden. Zur Erklärung: Es hat zwei Modi: LinearModus = nur in zwei ausgewählten Achsen, dann sind nur die Processe mit ...lin aktiviert, dient zum testen und einstellen der einzel Achsen, ist bis jetzt gelaufen. XYZModus : Interpolation in allen 6 Achsen mit Inverstransformation von virtuellen XYZAchsen, dann läuft nur RUNANGLE mit bekannten fehler. Gruss Anton

Hallo Anton,

kannst du noch das "AxConv.vhd" zur Verfügung stellen? Sonst kann man ITPmodul nicht bauen.

Grüße, Jens

Hallo Jens Ich denke für den gesamten ITPModul testen hat eigentlich kein sinn, weil alle anderen processe funktionieren problemlos in der gesammten Umgebung. Ich will nur das RUNANGLE allein kompilieren mit entsprechende Inputs. Und so werde ich es auch aufbauen. Gruss Anton

Hallo Udo K Unabhängig von Arith oder Numeric, wo sonst soll man noch sonst suchen, hast Du ein Tipp ? Gruss Anton

Hallo Anton,

ich habe jetzt das ITPmodul vollständig nachgebaut. Soweit kann man nicht auffälliges finden. Ich denke der Fehler hängt vielleicht nicht direkt an runangle, obwohl er da erstmals auftritt.

Deine Berechnungen enden alle in AxConv.vhd, soweit ich gesehen habe. Aber die Ausgänge von dem Modul, sind nicht angeschlossen. Du hast zwar Signale definiert, aber die enden im Nirgendwo. Was, wenn das Tool dann logischerweise auch alle Berechnungen für die Ergebnisse mit wegoptimiert? Und mul12 ist das erste Signal, das du siehst, dass nicht mehr da ist. Was ist mit allen Signalen danach? Fehlen die dann auch? Was geschieht mit den Ergbenissen von AxConv?

Grüße, Jens

Hallo Jens Der Endgültige Resultat der Berechnungen sind die A0FP bis A5FP die in einem ARRAY namens AFPinp(5..0) abgelegt sind. Die A0FP bis A5FP sind radiant winkel der Achsen. Im AXconv/ItpImpGen werden daraus die Inkremente gemäss der Auflösung der Inkrementalgeber. Alle andere Signale im RUNANGLE dienen nur dazu um die A0FP bis A5FP zu berechnen, und es ist keine der überflüssig ist. Am besten sende ich dir RUNANGLE Signale von ModelSim Gruss Anton

Noch ein Bemerkung, keine der Signale endet in niergendwo sondern enden in irgendeiner komponente und am schluss bekommt man die Winkel Gruss Anton

Hallo Jens Ich baue ein kleines system mit nur runANGLE mit outputs A0FP bis A5FP und sehe dan nach der kompilation was passiert. Gruss Anton

Hallo Jens anbei alle Signale des runangle sowie Axconv. Grüsse Anton

Hallo Anton,

das habe ich schon richtig verstanden mit dem Array und den Signalen AFPinp(5..0). Aber wo gehen die hin? Wo verwendest du den Winkel weiter? Die müssen doch entweder innerhalb von ITPmodul weiter gehen oder an eine andere Komponente in der Top Entity. Aber dann müssten diese Signal in der Port map auftauchen.

Du berechnest die Winkel, verstanden. Aber, anders als in SW, musst du die Signale weiter verwenden, sonst werden die entfernt, da nicht gebraucht. Und dann wird auch alles entfernt, das für die Berechnung gebraucht wird.

Grüße, Jens

noch etwas: Die Ergebnisse von AxConv (6x) werden über ITPImpGen an Impswitch und dann weiter als output der ITPmodul Entity an Top übergeben und dort weiter verarbeitet.zulezt resultiert es in den Sollwerten an die Achsenantriebe. Gruss Anton

Anton K. schrieb:

und dann weiter als output der ITPmodul Entity an Top übergeben und dort weiter verarbeitet.zulezt resultiert es in den Sollwerten an die Achsenantriebe.

Da muss ich drauf rumreiten! Ich sehe es nicht, wo der output definiert ist!

1

entity AxConv is

2

  port (

3

    nrst    : in std_logic;

4

    clk     : in std_logic;

5

    ceConv   :  in std_logic;

6

    AFPinp  :in std_logic_vector(31 downto 0);--Input Achse in  FP

7

    Resol    :in std_logic_vector(31 downto 0);--Achsen Auflössung in Inkr/Rad :C_AxRad

8

    AchsInkr   :out std_logic_vector(31 downto 0);-- Anzahl Inkremente

9

    AXgrd    :out std_logic_vector(15 downto 0)-- Achsenwinkel In Grd.X

10

    );

11

end AxConv;

Das ist der Port von AxConv. Dabei sind AchsInkr und AXgrd die Ausgänge. Diese weißt du in der ITPmodul auf das Signal AXGr vom Typ T_Axr zu

1

SIGNAL AXGr    :T_Axr;-- Winkel der Achsen A0..A5 in GRD.X, (std Logic vector)

2

cA0conv: AxConv port map(nrst=>nrst,clk=>clk,ceConv=>ceAxx,AFPinp=>A0FP,Resol=>C_A0rad,

3

    AchsInkr=>AXInc(0),AXGrd=>AXGr(0));--A0

Wenn das Signal aber irgendwo an die Portmap gehen soll, dass die Ergebnisse weitergereicht werden, müsste irgendwo so etwas stehen:

1

xyz <= AXGr(0);

Dabei muss xyz in der Portmap vorhanden sein! Das finde ich aber nirgends!

Grüße, Jens

Hallo Udo K Vielen Dank, aber Du schreibst von Modul, meist Du damit das Betreffende Process. In dem Modul ITPModul sind einige Processe die bis auf eine vollständig laufen. Nur das Process RUNAngle und deren Ausgänge F1FP sowie F2FP sind auf Null als folge von Optimierungen. Die übrige Ausgänge von Process RUNANGLE sind OK. Die Optimierung beginnt bei cmulFP12, wobei die beide Eingänge des FP multiplizierer keine Konstanten sind und bei paralel laufende Komponenten die übrigens gleiche Eingänge für z.Bsp Quadrat bilden benötigen nicht optimiert werden. der Log file meldet nur von loadless Signale, diese werden aber im nächsten process im gleichem Modul durchaus benützt. Das Werkzeug kann gar nicht wissen ob die Ausgänge konstant sind weil die Berechnung nur alle 10 us gestartet wird dazwischen passiert nichts. Gruss Anton

Hallo Jens Das AXConv wird 6X für jeder Achse gleichzeitig aufgerufen, siehe implementationsteil.Der input ist AFPinp siehe zeile 2085 bis 2095 im ITPModul. Gestartet werden sie parallel(sehr wichtig) von process ITPImpGen mit ceAxx. Danach werden die 6 resultate in Array AchsInkr(5..0) abgelegt. das funktioniert für alle übrige Achsen A0,A3,A4. da es sich um gleiche komponenten handelt kann es einmal laufen oder nicht laufen.Siehe auch Modelsim wo alle laufen. Gruss Anton

ja das signal AXgr ist nur für überprüfung ob die Winkel in Grad vernüftige werte liefern, diese Output wird tatsächlich nicht weiter benützt,ist nur für test. Kann ich auch wegschalten. Gruss Anton

Hallo Anton,

ja, das habe ich auch so gesehen und verstanden. Da bin ich bei dir. Nur mit den Ergebnissen habe ich ein Problem. Das Array, in dem die Ergebnisse abgelegt werden, wo gehen die hin?

Du kannst nicht einfach Werte in einem Array ablegen und nichts mit machen. Das geht in C, aber nicht in VHDL.

Der Optimierer denkt so: "Wenn das Ergebnis nicht verwendet wird, dann brauche ich auch die Eingänge nicht, dann brauche ich auch nichts, was davor kommt."

Daher bleibt die Frage: Wo gehen die Ergebnisse aus AxConv weiter?

Grüße, Jens

Anton K. schrieb:

ja das signal AXgr ist nur für überprüfung ob die Winkel in Grad vernüftige werte liefern, diese Output wird tatsächlich nicht weiter benützt,ist nur für test. Kann ich auch wegschalten. Gruss Anton

Dann verstehe ich es nicht. Geh mal zum mulFP zurück, der wegoptimiert wird. Das Ergebnis wird in AxConv gebraucht, das nur für Testzwecke ist. Gehen die Ergebnisse von mulFP noch irgendwo anders hin? Wo sie auch tatsächlich direkt gebraucht werden?

Wenn nein, dann ist der Optimierer am Werk!

Gruß, Jens

ja habe ich bereits geschrieben, noch mals genauer, schaust Du den ITPImpGen, da wird Diferenz zu vorherigen AXinc gerechnet und beschränkt auf 16 bit(AxDiff),alles Array. Dann wird die Differenz von allen 6 Achsen in ein oAxdif(95 downto 0)..(=6 x 16=96 bit) kopiert und dies über die Schnittstelle(entity) an TOP weiter gereicht zu weiteren Verarbeitung.Danach ist noch einiges im Top an Berechnungen bis die resultate an SDI D/A wandler geschickt werden. alles klar ? Gruss Anton

Udo K. schrieb:

Die NUMERIC_STD ist doch völlig unnötig.

Nein, leider nicht.

Die alten Synopsis STD_LOGIC_ARITH sind komfortabler, und funktionieren mit jedem Synthesetool einwandfrei.

Ja, für Schreibfaule sind die komfortabler, aber es lassen sich damit wunderbar logische Fehler einbauen, die sich bescheiden debuggen lassen. Das will man nicht.

An dem liegt es doch nicht.

Das ist hier in dem Fall sicher richtig.

Mach das wieder rückgängig, und konzentriere dich auf den eigentlichen Fehler, sonst verlierst du vor lauter Änderungen völlig die Übersicht.

Warum? Den Fehler wird man auch so finden, aber bei VHDL-Code mit std_logic_arith braucht man mit debuggen gleich gar nicht anzufangen.

Wenn man an ce wackelt und mehr als 20 ms wartet, passiert auch was in der Simulation. Was muß man tun, damit stateITP nicht ständig zwischen State 5 und State 6 springt?

Hallo Udo K Komische Sachen ---------im ITPImpGen steht -------------------- FOR i IN 0 TO 5 LOOP vAXdif(i) <= std_logic_vector(signed(AXinc(i)) - signed(AXalt(i)));-- --Differenz errechnen inn 32 bit AXdif(i)<= std_logic_vector(signed(vAXdif(i)(15 DOWNTO 0)));--beschränken auf 16 bit, wird im ImpSwitch weiter verarbeitet END LOOP; ---------im Synthesis report steht------------------------ WARNING:Xst:2677 - Node <vAXdif_5_16> of sequential type is unconnected in block <itpexec>. WARNING:Xst:2677 - Node <vAXdif_5_17> of sequential type is unconnected in block <itpexec>. WARNING:Xst:2677 - Node <vAXdif_5_18> of sequential type is unconnected in block <itpexec>. --- usw. für alle 32 bits ------------------------ Ich wüsste nicht was da unconnected ist ?? Gruss Anton

Hallo Rick D CE hat mi state 5 oder 6 nicht zu tun, ist schon lange auf 0 (1clk impuls). Hier wird auf strimp gewartet, das kommt von aussen und weil auf der Leitung störungen kömmen, muss man da den Richtige Puls abwarten, und es darf nicht weiter gemacht werden, wird auch übrigens angezeigt, also off. Gruss Anton

Hallo Anton,

schau mal in das Bild. Das ist aus ITPImpGen.

Im state 2 weist du zu: AXalt(0) <= AXinc(0)

In state 3 berechnest du die Differenz: vAXdif(i) <= std_logic_vector(signed(AXinc(i)) - signed(AXalt(i)));

Aber wenn AXalt = AXinc (aus dem state 2) ist, dann ist das Ergebnis doch immer 0, oder? Macht das Sinn?

Grüße, Jens

Bild vergessen:

Und im gleichen State verwendest du das Ergebnis weiter: AXdif(i)<= std_logic_vector(signed(vAXdif(i)(15 DOWNTO 0)));

Wenn das aber ein synthesefähiger Code sein soll, dann gibt es das Ergebnis von vAXdif(i) aber erst im darauffolgenden Takt. Da bist du aber schon im nächsten State.

Da sollte man in der Simulation mal ganz genau hinschauen.

Für alle anderen hänge ich mein gesamtes Projekt mal in den Anhang.

Grüße, Jens

Hallo Jens, da bin ich unabhängig zu Dir darauf gekommen, da muss ein State dazwischen sein. Aber mein Problem löst es damit nicht. Ich bin fast fertig mit dem KleinSystem RUNAngle, morgen kann ich es vermutlich testen. Gruss Anmton

Hallo Jens Ich habe dein Roboter_test Projekt angeschaut, entschuldige, aber was soll ich damit. Von einem Roboter Test ist es noch sehr weit entfernt. Mit dem löst man nichts.

Es geht mir darum Fehler im RUNANGLE zu finde, dazu habe ich ein testsystem bereits erstellt und hoffe auf diesem Wege das Problem Einzukreisen. Brauche kein Zusätzlichen Roboter Test, der Roboter steht bereits bei mir im Labor mit allen testeinrichtungen. Da hast etwas falsch verstanden. Gruss Anton.

Hallo Anton, das ist auch nicht für dich. Das ist für alle, die hier mitlesen und auch mit reinschauen wollen. Mehr gibt es ja nicht. So wie Udo meinte, er braucht Sourcen, wenn er mithelfen will.

Gruß, Jens

Udo K. schrieb:

std_logic_arith war lange Jahre der Industriestandard,

Industriestandard (=Euphemismus für veraltete Technik zu Fantasiepreisen (aus de.sci.electronics)).

Das std_logic_arith bei Nachwuchs nicht mehr beliebt ist, hat nichtzuletzt politische Hintergründe.

Hier kann ich das mit dem Blödsinn zurückgeben.

Da sitzt du ganz schnell auf einem grossen Scheisshaufen.

Jupp. Den hast Du auch, wenn Du die arith verwendest. BTDT.

Anton K. schrieb:

Ich wüsste nicht was da unconnected ist ??

Im Kommentar steht, das die oberen 16 Bit nicht verwendet werden. Das scheint für das 5. Array-Element auch zu stimmen, sonst würde die Meldung nicht kommen.

Anton K. schrieb:

Hier wird auf strimp gewartet, das kommt von aussen und weil auf der Leitung

Ok, wenn ich nach ca. 20 ms auf strimp wackele, geht es in stateITP auch weiter. Es wackelt auch in statebrsh, aber nicht so, das ImpLk mal auf '0' gehen würde, damit in runangle was passiert.

Was genau muß man denn alles machen, damit in stateangle Action ist?

Übrigens, wenn Du 20 ms Zeit hast, um auf ein externes Signal zu warten (ist das auch einsynchronisiert?), dann würde es m.E. reichen eine Rechenpipeline zu haben und die nacheinander mit den verschiedenen Achsparametern zu füttern...

Um das ganze abzuschliesen. Ich habe folgende Versuch gemacht, ein Testprogramm der nur folgendes macht: atanFPo = xinp * Yinp, Input und output im FP format, IP_coregen Mul Floating Point Komponente(vers 6.1): mulFP1 Simulation liefert richtige Resultate,Kompilation ohne Fehler jedoch im MAP wird der Block MulFP1 (implementation cmulFP1) "removed" mit Erklärung:

The signal "cmulFP1/blk00000001/blk0000001c/sig0000017b" is sourceless and has been removed.

Was ja nie und nimmer stimmt, Ein- und Ausgang sind Entity-signale, im übrigen habe ich auch mit internen Signalen Probiert(auskomentiert), => das selbe Resultat Das Testprogramm ist so einfach, dass da kaum ein Fehler möglich sind. Wer das nicht glaubt kann es selber ausprobieren, siehe Beilage mit Testprogram ,testbench und ucf file. Ich lasse mich gern belehren wenn ich hier ein Fehler gemacht habe. Gruss Anton

Häng mal bitte die Komponente mulFP1 noch mit an...

Ich habe neu noch einmal probiert mit mulFP (IP logiccore 5.0) diese mit ND, RDY usw. es hat bereits in der Simulatiion mit Warnung:

** Warning: (vsim-8683) Uninitialized out port /testbnch/UUT/cfuncmul/U0/FP_OP/EXCEPTION has no driver.

This port will contribute value (U) to the signal network.

Dies führt später bei der Kompilation zu "remove" den Block cfuncmul

Der vorherige Versuch mit mulFP1(IP Logiccore Vers 6.1) gibt keine Warnung bei der Simulation, aber bei der Map wird das Block cfuncmul trotzdem "removed) Ich sende sowohl MulFP(IP5.0) wie auch mulFP1(IP6.1). Wie man es probiert es werden generel IP Komponenten bei allen Versuchen entfernt. Ob es an ISE14.7 oder IP Versionen 5.0 oder 6.1 liegt kann ich nicht sagen.

Anton K. schrieb:

... bereits in der Simulatiion mit Warnung:

** Warning: (vsim-8683) Uninitialized out port

This port will contribute value (U) to the signal network.

EXCEPTION ist ein Ausgang, der nicht getrieben wird. Da der Ausgang auch nicht gelesen wird, spielt das keine Rolle.

---

Dies führt später bei der Kompilation zu "remove" den Block cfuncmul

Nein, da kommen halt nur 'U's raus, aus dem Port. Das hat mit dem Rest des Blocks nichts zu tun.

Der vorherige Versuch mit mulFP1(IP Logiccore Vers 6.1) gibt keine Warnung bei der Simulation, aber bei der Map wird das Block cfuncmul trotzdem "removed)

Simulation und Synthese sind zwei verschiedene Paar Schuhe. Die Simulation schmeißt eigentlich nichts raus, es sein denn vopt ist aktiviert. Aber die Synthese erkennt, das sich bei Deinem Block das Ergebnis nicht ändert und damit wird er eliminiert.

Ich sende sowohl MulFP(IP5.0) wie auch mulFP1(IP6.1). Wie man es probiert es werden generel IP Komponenten bei allen Versuchen entfernt. Ob es an ISE14.7 oder IP Versionen 5.0 oder 6.1 liegt kann ich nicht sagen.

Das Problem wird vermultich vor dem cfuncmul liegen. Möglicherweise klemmt ein Eingang schon dauerhaft auf Null oder 'ce' wird nie aktiv. Das läßt sich mit einer Gesammtsystemtestbench herausfinden. Oder Du ziehst Dir die Signale InpA, InpB und ce1 mal auf ein Chipscope und schaust, ob die überhaupt wackeln.

Vielen Dank für die ausführliche Antwort. Eines verstehe ich nicht, bei dem Testprogram sind bei Implementation die Eingänge und Ausgänge verbunden mit Entity Eingängen sowie Ausgang. Und diese wiederum sind in ucf file direkt mit den Chip Ein und Ausgängen verbunden. Bei der Synthese wird doch die Tstbench nicht verwendet. Darum kann am Eingang vom Chip kein Wert sein, erst beim fertig programmierte FPGA werden Werte an den Eingang gelegt und am Ausgang ausgelesen.

So war es bis jetzt immer, seit 20 Jahre arbeite ich mit FPGAs und verwendete dabei auch IP Logicore ohne Probleme. Aber, das IP Floating Point verwende ich erstemal mal, und in der gegebene Applikation ist es die einzige Lösung. Sowohl bei Testprogramm wie auch bei der eigentliche Applikation (dort werden div FP ca. 50 mal implementiert; addFP,DivFP,mulFP, sqrtFP). Aber wenn schon bei dem einfache Testprogramm mit nur mulFP nicht läuft kann die eigentliche Applikation auch nicht laufen. Gruss Anton

Genau dafür wird die Testbench ja verwendet, um die IOs der FPGAs zu simulieren und gfs die übernehmenden Register, Serializer und das damit verbundene Zeitverhalten und Zusammenspiel mit externen Chips.

Mit dem LogiCore hat das erstmal gar nichts zu tun und sollte getrennt betrachtet werden.

Wenn ich mir den thread wieder durchlese, sind viele Tipss und Ansätze komplett Banane, weil wieder völlig unnötig, alles durcheinander geschmissen wird.

Man sollte mal strikt darüber nachdenken, physikalische Simulation und logische Simualtion zu trennen. Bei letzterem kannst du dich voll auf eine reine funktionale Simulation beschränken und die Interna mit einigen Werten beschicken, was dann komplett simulierbar ist, wie es auch real mit diesen Werten laufen würde, inklusive der kritischen Fälle wie Überlauf, Rauschen, Fehler etc.

Der Core muss jeweils in seiner Umgebung funktionieren und eine entsprechend angesetzte TB liefert eigentlich sofort, wo es mangelt.

Anton K. schrieb:

Aber wenn schon bei dem einfache Testprogramm mit nur mulFP nicht läuft kann die eigentliche Applikation auch nicht laufen.

+1

Lade mal eine Simulation hoch. Nicht den FPGA. Nur das Modul, wo es nicht geht.

in aller Regel liegt das an einer unvollständigen Initialisierung. Diese ist zwar für die letztliche Funktion nicht unbedingt nötig, wenn der Schaltkreis irgendwie anlaufen darf und sich fängt, ist aber fpr die Verifikation unerlässlich.

Auch und vor allem deshalab sind physische SIM und Logic SIM zwei unterschiedliche Paar Schuhe.

Hallo, bei der Simulation lauft alles wunderbar, nicht nur das kleine tesprogramm sondern auch die gesamte Applikation. In der Simulation sieht man leider nicht wo das Problem wegen Entfernen aller IP komponenten bei der Kompilation sein kann. Interesanterweise lauft die Simulation trotz der Warnungen richtig, Resultate aller Berechnungen sind richtig. Diese Warnung kommt immmer bei Simulationsstart , für die Simulation hat es aber keinen Einfluss.

** Warning: (vsim-8683) Uninitialized out port

This port will contribute value (U) to the signal network.

Gruss Anton

Ich kann bei der Synthese von arctanFP kein Problem entdecken.

Hallo Rick.D Vielen Dank für dein Einsatz ,ja so sieht es bei mir auch. Hast Du aber auch den "Map report" angeschaut ? Wenn es bei Dir keine "removed Block" gab, so ist nur eine Erklärung möglich, das bei meine Installation ISE14.7 etwas nicht stimmt. Gruss Anton

Hier noch wie sich bei mir presentiert, sowie Map report

Irgendwas wird shcon rausgemappt:

1

Section 4 - Removed Logic Summary

2

---------------------------------

3

  26 block(s) removed

4

  39 block(s) optimized away

5

  17 signal(s) removed

Es werden auch keine DSP48 benötigt:

1

IO Utilization:

2

  Number of bonded IOBs:                        99 out of     210   47%

3

4

Specific Feature Utilization:

5

  Number of RAMB36E1/FIFO36E1s:                  0 out of     135    0%

6

  Number of RAMB18E1/FIFO18E1s:                  0 out of     270    0%

7

  Number of BUFG/BUFGCTRLs:                      1 out of      32    3%

8

    Number used as BUFGs:                        1

9

    Number used as BUFGCTRLs:                    0

10

  Number of IDELAYE2/IDELAYE2_FINEDELAYs:        0 out of     300    0%

11

  Number of ILOGICE2/ILOGICE3/ISERDESE2s:        0 out of     300    0%

12

  Number of ODELAYE2/ODELAYE2_FINEDELAYs:        0

13

  Number of OLOGICE2/OLOGICE3/OSERDESE2s:        0 out of     300    0%

14

  Number of PHASER_IN/PHASER_IN_PHYs:            0 out of      24    0%

15

  Number of PHASER_OUT/PHASER_OUT_PHYs:          0 out of      24    0%

16

  Number of BSCANs:                              0 out of       4    0%

17

  Number of BUFHCEs:                             0 out of      96    0%

18

  Number of BUFRs:                               0 out of      24    0%

19

  Number of CAPTUREs:                            0 out of       1    0%

20

  Number of DNA_PORTs:                           0 out of       1    0%

21

  Number of DSP48E1s:                            0 out of     240    0%

22

  Number of EFUSE_USRs:                          0 out of       1    0%

23

  Number of FRAME_ECCs:                          0 out of       1    0%

24

  Number of IBUFDS_GTE2s:                        0 out of       4    0%

25

  Number of ICAPs:                               0 out of       2    0%

26

  Number of IDELAYCTRLs:                         0 out of       6    0%

27

  Number of IN_FIFOs:                            0 out of      24    0%

28

  Number of MMCME2_ADVs:                         0 out of       6    0%

29

  Number of OUT_FIFOs:                           0 out of      24    0%

30

  Number of PCIE_2_1s:                           0 out of       1    0%

31

  Number of PHASER_REFs:                         0 out of       6    0%

32

  Number of PHY_CONTROLs:                        0 out of       6    0%

33

  Number of PLLE2_ADVs:                          0 out of       6    0%

34

  Number of STARTUPs:                            0 out of       1    0%

35

  Number of XADCs:                               0 out of       1    0%

36

37

Average Fanout of Non-Clock Nets:                3.19

Aber da immer noch 774 Register und 850 LUTs gebraucht werden, wird die eigentlich benötigte Funktion auch noch drin sein. Sonnst würde er alle Ausgänge einfach auf GND legen.

Hallo Rick.D Ich habe Dir vorher die Datei Map report geschickt(arctan_map.mrp.txt), schaust Du bitte hinein, bei mir wird effektiv die Komponente mulFP entfernt. Genau das ist das Problem.!! Darf ich wissen mit was für Version von 14.7 Du arbeitest ? Gruss Anton

Ah, den Map-Report hatte ich übersehen. Ich habe nun bei mir den gleichen FPGA eingestellt und den Core angepasst (sieh Bild). Außerdem konnte damit Deine ucf-Datei fast vollständig verwendet werden.

Es gibt zaw immer noch Unterschiede, aber weder bei mir noch bei Dir wird der Multiplizierer wegoptimiert. Es werden jeweils zwei DSP48-Blöcke verwendet.

Das was unter 'Removed Logic' aufgeführt wird, ist Logik aus dem Core, die für die ausgegrauten und nicht genutzten Signale da ist (core.png).

Dein Problem liegt nicht am Core sondern weiter vorn (ce nicht angesteuert?).

Hallo Rick.D Wiso wirst Du so sicher das es am ce liegt ? Im Testprogramm: arcTanFP.vhd wird das ce zuerst 1 gesetzt, bei nächstem clock dann ND beim nächsten clk wird gewartet auf rdy und erst beim nächste clk wird ce rückgesetzt. Es geht eigentlich hier nicht um das Testprogrammli sondern dies ist entstanden, weil bei der eigentliche Applikation (wo 55 x cores verwendet werden) alle in der Map report als removed aufgeführt werden und die tatsächliche Berechnungsresultate am Ausgängen des FPGA gleich = 0 erscheinen. Somit muss ich davon ausgehen das auch die aktiven teile der verwendeten cores eliminiert werden. Gruss Anton

Anton K. schrieb: