Forum: FPGA, VHDL & Co. Frequenzteiler


von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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 .

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

>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?

von Jan M. (mueschel)


Lesenswert?

@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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

@  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.

von stefan (Gast)


Lesenswert?

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!!!!

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Volker (Gast)


Lesenswert?

@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

von spartanne (Gast)


Lesenswert?

@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.

von Volker (Gast)


Lesenswert?

@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?

von spartanne (Gast)


Lesenswert?

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?

von Volker (Gast)


Lesenswert?

Ja, nun ist alles klor, danke vielmals

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

>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
:

von Volker (Gast)


Lesenswert?

@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
Noch kein Account? Hier anmelden.