Hallo,
ich versuche schon seit zwei Tagen einen Multiplizierer, den ich mir im
Coregen erstellt habe, zu simulieren. Habe mir mittels Coregen unter
Math einen normalen Multi 2x32bit mit 5 Pipelinestufen und ce erstellt.
Dann die .v-Datei in ein neues Projekt für Spartan3E eingefügt und
folgende Testbench drumherum gebaut:
1
`include"../ce_p_multiplier.v"
2
3
modulemutli_tb();
4
regclock,enable;
5
reg[35:0]a;
6
reg[31:0]b;
7
wire[63:0]p;
8
9
// Initialize all variables
10
initialbegin
11
$display("time\t clk reset enable counter");
12
$monitor("%g\t %b %b %b ",
13
$time,clock,enable,p);
14
clock<=1;// initial value of clock
15
enable<=0;
16
a<=2;
17
b<=5;
18
#10 enable <= 1;
19
20
21
#1000 enable <= 0;
22
#5 $finish; // Terminate simulation
23
end
24
25
// Clock generator
26
alwaysbegin
27
#5 clock <= ~clock; // Toggle clock every 5 ticks
28
end
29
30
// Connect DUT to test bench
31
ce_p_multipliermulti(
32
enable,clock,a,b,p
33
);
34
35
endmodule
Wenn ich das ganze jetzt allerdings mit ISIM simuliere, liegt am Ausgang
des multis eine konstante 0 an, egal was ich an die Eingänge lege und
wie lange ich es laufen lasse.
Im Internet habe ich nur von ähnlichen Problemen mit ModelSIM gelesen,
weil man dafür die XilinxCoreLib erst kompilieren muss. Für ISIM sind
sie ja bereits vorkompiliert. Liegen bei mir auch etliche v-Dateien in:
F:\Vista\Xilinx\ISE_DS\ISE\verilog\src\XilinxCoreLib
Habe jetzt schon stundenlang google gefragt und Xilinx-Tutorials
gewälzt. Muss ich die diese Corelib noch irgendwo eintragen?
(Verilogprojekt?)
Hab die Version 12.2 des ISE und Windows 7 Prof 64bit.
Wäre froh, wenn mir jemand helfen könnte, ich bin echt am Verzweifeln...
Danke im Voraus.
Michael
Michael Burger schrieb:> egal was ich an die Eingänge lege und
Welche Polarität hat der Reset? Gibt es einen?
> wie lange ich es laufen lasse.
Wie lange ist lange?
Duke
Der Reset steht nur noch oben in der Ausgabeliste fürs Display
(Copy&Paste). Genutzt wird er nicht, da der Multi selbst ja keinen Reset
hat. Er hat nur ce, clk, a, b und die Ausgabe p.
Also laut Xilinx sollte er 6 Takte brauchen bis das Ergebnis am Ausgang
anliegt. Aber egal ob ich 6, 10, 20 oder 103 Takte (jeweils nach dem
ce-high versteht sich) mache liegt am Ausgang dauerhaft die 0 an.
Michael Burger schrieb:> // Connect DUT to test bench> ce_p_multiplier multi(> enable, clock, a, b, p
sicher dass die Ports in der richtigen Reihenfolge sind?
Inferieren?
Wo genau? Bei diesen ganzen Guides blick ich nicht mehr durch... Und
dann sind die auch teilweise mehrere hundert Seiten lang. Hab jetzt
allein das In deepth Tut für ISIM und den ISIM Usersguide durchgeschaut.
Ich brauche halt 7 Multiplizierer in meinem Projekt wo sie auf 3
verschiedene Module verteilt werden sollen.
Sebastian B. schrieb:> Beispiele zur direkten Verwendung der ganzen Xilinx Komponenten findest> du hier (nicht die neueste Version vermutlich):>> http://www.xilinx.com/support/documentation/sw_man...
Ja, aber die direkten Primitives verwende ich nur im Notfall, z.B. beim
DCM (ich mag dieses Wizardgeklicke nicht, paßt nicht in meinen
Workflow...)
Ich meinte
xst.pdf ->
Chapter 3 XST HDL Coding Techniques ->
Multipliers HDL Codingn Techniques -->
Pipelined Multipliers HDL Coding Techniques -->
Pipelined Multiplier (Outside, Single) Verilog Coding Example
Duke
Gerade bei den Standard-Mul usw. muss man keinen Core verwenden. Einfach
die Operation hinschreiben und gut. XST macht automatisch den HW-Mul
rein, wo es geht. Das nennt sich dann "infer" im englischen. Auf Deutsch
könnte man dazu "Aus der Beschreibung ableiten" sagen, das Wort
"inferieren" gibts nicht.
Danke soweit schonmal. Aber ich brauche dann auch noch Dividierer,
Wurzel ziehen und Expotentialfunktionen. Ist das alles so zu lösen?
Wohin könnte ich mich mit meinem eigentlich Problem melden? Weil auf
unserem Uniserver funktioniert das Simulieren der Komponenten. Aber da
habe ich erstens einen Virtex2p dran und VirSIM, was ich beides lokal
nicht haben. Es muss also irgendwie gehen.
Danke nochmal.
Michael Burger schrieb:> Aber ich brauche dann auch noch Dividierer,> Wurzel ziehen und Expotentialfunktionen. Ist das alles so zu lösen?
Für Division und Wurzelziehen habe ich State-Machines, die ich aber
nicht rausgeben darf.
Was willst Du denn machen? Eventuell läßt sich Deine Rechnung
vereinfachen (Division mit Zweierpotenzen geht z.B.). Wie schnell muß
das alles gehen?
Bei vielen Berechnungen kannst Du wählen zwischen Ressourcenverbauch und
Rechengeschwindigkeit.
Duke
Duke Scarring schrieb:> Eventuell läßt sich Deine Rechnung vereinfachen> (Division mit Zweierpotenzen geht z.B.).
Das kann die Synthese schon ewig, das ist bei unsigned ja nur eine
Umverdrahtung (also nicht mal ein Shift wie bei uCs). Und bei signed
gibts evtl. Probleme mit der Rundungsrichtung...
Es wird ein Raytracer in Geometrischer Algebra für Dreicksnetze. Die
Berechnungen lassen sich nicht weiter vereinfachen. Die Division ist zum
Normalisieren der 5D konformen Punkte. Es wird daher auch durch andere
Werte geteilt als Zweierpotenzen, somit muss richtig dividert werden.
Die Wurzel ist zum Normalisieren der Richtungsvektoren, somit auch nicht
zu ändern und die Expotentialfunktion wird beim
Blinn-Phong-Beleuchtungsmodell für den spekularen Anteil gebraucht.
Ebenfalls nicht zu entfernen.
Habe jetzt auch schon im offiziellen Xilinxforum um Hilfe gefragt. Seit
4 Tagen no reply :(
Michael Burger schrieb:> Es wird daher auch durch andere> Werte geteilt als Zweierpotenzen, somit muss richtig dividert werden.> Die Wurzel ist zum Normalisieren der Richtungsvektoren, somit auch nicht> zu ändern und die Expotentialfunktion wird beim> Blinn-Phong-Beleuchtungsmodell für den spekularen Anteil gebraucht.> Ebenfalls nicht zu entfernen.
Alles klar, da brauchst Du richtige Recheneinheiten, keine abgespeckten.
Welche Bitbreite haben Deine Vektoren?
Wie schnell müssen die Berechnungen laufen?
Meine Division benötigt 1 Takt pro Bit und die Wurzelberechnung ca. 1.5
Takte pro Bit.
Wieviel Platz hast Du dafür?
Wieviele Berechnungen müssen davon parallel ablaufen?
Alternativ könntest Du Dir auch den CORDIC-Algorithmus anschauen. Damit
sollten sich alle Deine Berechnungen lösen lassen.
Duke
Den Cordic habe ich ja auch schon im Auge.
Der Algorithmus selbst ist noch in Strahlenerzeugung, Schnittest und
Schnittpunktberechnung geteilt, mit Fokus auf dem Schnittest. Hier
laufen 5 Multiplikationen gleichzeitig, weil die Geometrische Algebra
dies ermöglicht. Sonst wird hier nur + und - sowie Vergleiche gebraucht.
Meine Vektoren sind allesamt 32bit breit. Ich arbeite mit einem selbst
erstellten Fixpunkttyp, wobei nur 4 bits für vor dem Komma und 28 für
hintendran zur Verfügung stehen (da vor dem Komma
implementierungsbedingt max. -1 und +1 stehen kann). Beim
Multiplikationen "biege" ich durch Shifts das Komma wieder an die
richtige Stelle und schneide den Rest ab. Die entstehenden
Rundungsfehler kann der Algorithmus abpuffern.
Michael Burger schrieb:> Den Cordic habe ich ja auch schon im Auge.>
Den Cordic hätte ich in VHDL parat. Allerdings benutzt du einen
Fixpunkttyp.
Wie kommst du nur mit den großen Datenmengen im Spartan 3E klar?
Alles in den exteren RAM und dann auf den VGA Port?
@Duke
Da es eigentlich nur ein Teil, eines Teils, meiner Masterarbeit ist,
sollte es über fertige Cores laufen, da sonst jeglicher Aufwandsrahmen
gesprengt wird.
@Rene D
Auf dem Spartan3 teste ich nur einzelne Module mit ausgewählten
Dreiecken und Strahlen, so dass mir seine Größe reicht. Das eigentlich
Projekt läuft auf einem Virtex 2 an der Uni mit Unterstützung einer
dedizierten CPU und einem Linuxbetriebssystem. Dort stürzt das Projekt
allerdings stehts beim starten des Linux auf dem Board ab und ich
versuche jetzt durch diese Einzeltests rauszufinden, wo genau es hängt.
D. I. schrieb:> Wie soll man CORDIC denn sonst vernünftig machen wenn nicht mit> Fixpunkt?>> Mit Floating-Point ist das ja ewiges rumgekrüppel
Richtig.
Ich glaube Cordic hätte hier einen richtigen Einsatz.
Es sind auf direktem Weg die Funktionen
y=K*sqrt(x^2+y^2)
y=K*e^z=K(sinh(z)+cosh(z))
berechenbar.
K ist ein fester Faktor und ist nur abhängig wie oft die Iteration
ausgeführt wird.
Bisher habe ich nur Sinus und Cosinus mit dem Cordic berechnet. Doch das
gibt der Algorithmus mit anderen Startparameteren und
Entscheidungskriterien beim Drehen auch her.
