Hallo, ich habe ein frequenzteiler durch 16:1 geschrieben , es lauft alles in ordnung, aber beim Simulation habe ich paar Probleme die zu beschreiben, Ich bitte euch um Hilfe Im Anhang schicke ich dir Simulation, mit altera Danke im vorraus .
>es lauft alles in ordnung... Gut. >aber beim Simulation habe ich paar Probleme Schlecht. Da waren schon 9 Leute da, die dir helfen wollten, oder wenigstens Interesse an deinem Problem zeigten. Aber für eine halbwegs brauchbare Aussage fehlt noch Input: - Fehlerbeschreibung - Zielplattform - Enwicklungsumgebung - Sourcecode - Testbench Und was die Hölle ist ein odt-File, wer kann damit was anfangen, wozu gibt es Screenshots?
@Lothar: odt heisst OpenDocumentText, kann man inzwischen auch mit Word oeffnen. Ausser dem Screenshot zweier Clocks in der Simulation und dem Screenshot des Quellcodes ist da nichts zu sehen. @Stefan: - Screenshots bitte als Bild und nicht eingebettet in eine Textdatei anhaengen. - Sourcecode bitte als Textdatei anhaengen. - Wo liegt dein Problem? - "rising" ist ein seltsamer Name fuer einen Takt. - Wo liegt dein Problem? - Warum benutzt du Variablen? Voellig unnoetig und eine moegliche Fehlerquelle. - Wo liegt dein Problem?
@ Jan M. Danke, man lernt nie aus ;-) OpenOffice konnte das Ding öffnen, man ist eben schon verwöhnt mit dem selbstständigen interpretieren von Dateinamen. Und wehe, das allmächtige System kennt den Dateityp dann nicht... @ Stefan Also, ich würde das Dokument so auslegen, dass alles geht, und dass das geteilte Signal etwas verzögert (ca. 5ns) am Ausgang des FF sichtbar wird. Aber kommt das nicht von dem generischen Programmieren, wenn man es nicht versteht? Da steht:
1 | :
|
2 | generic(n: integer := 16); |
3 | :
|
4 | variable Z: integer range 0 to n-1; |
5 | :
|
6 | :
|
7 | if Z=n then ---> hier gehts schief <--- |
8 | :
|
Muss ja irgendwie schiefgehen... Z ist definiert als range 0 to n-1 und wird auf n abgefragt. da hätte es aber schon vorher eine warning geben sollen.
Vielen dank für euere Hilfe leute Wie gesagt , ich sollte ein Programmierbareteiler in VHDl schreiben und die Simulation beschreiben, da habe ich einfach als beipiel Frequenzteiler durch 16:1 geschrieben, Ich bin momentan im labor, es ist ja ein Teil von mein Projektarbeit Sie haben es gut gesagt : in der Simulation sieht man ja nicht viel was man beschreiben soll, aber der Prof verlangt von mir einen beschreibung !!!!!!!!!! und da liegt ja mein Porblem.... Wenn jemand noch was zu sagen von der Simlution wäre ich sehr dankbar!!!!
Teiler durch 16:
1 | :
|
2 | signal cnt : std_logic_vector(3 downto 0); |
3 | signal div16 : std_logic; |
4 | :
|
5 | process (clk) |
6 | begin
|
7 | if rising_edge(clk) then |
8 | cnt <= cnt+'1'; -- Überlauf automatisch, weil nur 4 Bit breit |
9 | end if; |
10 | end process; |
11 | :
|
12 | div16 <= '1' when cnt="0000" else '0' ; |
13 | :
|
Ein programmierbarer Teiler ist aber einer, dessen Teilerverhältinis zur Laufzeit umgeschaltet werden kann. Das hat nur zum Teil mit einem z.B. in VHDL programmierten Teiler zu tun. @ Stefan Mach dich mal schlau, was du eigentlich machen sollst. Ich bin mir nicht sicher, dass du die Aufgabe verstanden hast... Musst du eine Testbench schreiben, die den Zähler selbständig testet? Falls ja, dann sollten in der Testbench ein paar Abfragen mit assert, report & Co auftauchen. Da hilft es dann nicht, wenn eine schöne Waveform auf dem Bildschirm auftaucht, das hat mit automatisiertem Test wenig zu tun.
@Lothar bei dem letzten Bespiel setzt du div16 außerhalb des Prozesses mit der when Abfrage. Auf diesem Signal können meiner Meinung nach kurze Spikes entstehen, falls die 4FF des Counters nicht exakt gleichzeitig schalten. Der Conter besteht aus FF3,FF2,FF1,FF0 Zustand Counter 0011 Zustand +1 ist 0100 Wenn nun FF0,FF1 einen Hauch früher auf "0" gehen als FF2 auf "1", wäre der Counter für einen ganz ganz kurzen Bereich auf dem Stand "0000" was somit für einen Spike auf dem Signal "div16" sorgen kann. Oder bin ich da zu besorgt? Gruß Volker
@Volker Mach dir da mal keine Sorgen. Die kurzen Spikes bei div16 gibt es natürlich wenn der Counter seinen Zustand wechselt, aber bis zur nächsten Taktflanke ist es auf jeden Fall stabil. Wird erst bei hohem Takt evtl. ein Problem wenn hinter div16 noch viel Logik vor dem nächsten FF hängt, da dann die Setup-Zeit des nächsten FF verletzt werden könnte. Abhilfe würde dann das hinzufügen von FF in der div16 folgenden Kombinatorik (Pipelining) schaffen. Aber das ist bei dir sicher kein Problem.
@spartanne, danke, kommmt halt auch auf den Verwendungszweck des Signals "div16" an, wenns nach außen auf einen Pin geführt wird und für was externes als Takt dienen soll, wäre das so nicht geeignet. Also meiner Meinung nach wäre es doch besser das ganze innerhalb des Prozesses zu machen, da ist immer alles synchron zum Haupt-Takt. Sehe ich das richtig?
Ja, wenns nach außen geführt wird dann takte div16, d.h. mache das Signal zu einem FF. Da wackelt dann nix mehr am Ausgang. Bei interner Verwendung kommts halt auf die Anwendung an. Bei diesem Beispiel sicher egal, man handelt sich durch takten von div16 halt einen Takt Latency ein, d.h. in Lothars Beispiel ist div16 '1' bei Zählerstand "0000". Wenn man nun div16 in einen getakteten Prozess mit aufnimmt dann ist div16 '1' bei Zählerstand "0001". Alles klor?
>Auf diesem Signal können meiner Meinung nach kurze Spikes entstehen, >falls die 4FF des Counters nicht exakt gleichzeitig schalten. Richtig, da werden Spikes entstehen. Die FFs werden niemals zum gleichen Zeitpunkt schalten, ein paar ps sind da immer drin ;-) Ok, also nochmal. Und diesesmal registriert. Zur Ausgabe an externe Teilnehmer (aus Sicht des FPGAs)...
1 | :
|
2 | signal cnt : std_logic_vector(3 downto 0); |
3 | signal div16 : std_logic; |
4 | :
|
5 | process (clk) |
6 | begin
|
7 | if rising_edge(clk) then |
8 | cnt <= cnt+'1'; -- Überlauf automatisch, weil nur 4 Bit breit |
9 | div16 <= '0'; |
10 | if (cnt="1111") then -- 1 Takt Latency beachten |
11 | div16 <= '1'; |
12 | end if; |
13 | end if; |
14 | end process; |
15 | :
|
@Lothar, an dich mal ein dickes Dankeschön, finde deine Beiträge immer sehr imformativ. Gruß Volker
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.