Spartan II: Bus påstand om årsagerne flip flop tilstand korruption

[Elephantus]

Vi er ved at opbygge en memory bus interface mellem en Atmel ATmega103 LC og en spartansk II FPGA.Den ATmega har en asynkron ekstern hukommelse interface med en multiplex lavere adresse / data bus.
Som vores ur kilde frekvens ikke er tilstrækkelig til at drive de interne FPGA DLL at formere den eksterne klokke kilde, og de ATmega adresse låsen så signalet er for kort til at sikre, at adressen vil blive clocket til det indre DFF's, en ALE-drevet låsen var bruges til at prøve det hele adressen i FPGA, og klinke adresse blev synkroniseret senere.

Men af en ukendt årsag til nu, en bus påstand jævnligt forekommer i FPGA til en specifik skrive tilstand.Hvad er gådefuldt mere end bussen påstand er, at den ulovlige tilstand af bussen bliver lukket, i adressefeltet låsen.Den XST syntetiserer låsen som en faldende-kant drevet DFF med ALE som uret kilde.

Den ALE linje er inaktiv på det tidspunkt, bussen påstand, så det er gådefuldt, hvordan den uregelmæssige stat fra bussen bliver skrevet ind i adressen låsene.Bussen påstand er en uønsket tilstand, men det er mærkeligt, at det følger DFF's, som ikke kunne være i en overgangsperiode på det tidspunkt.

Jeg vil gerne have nogen mening om dette spørgsmål.

 

[tkbits]

Du siger du har bus påstand, men du behøver ikke angive, hvilke signaler påstand.

Du siger, at det sker i en bestemt skrive tilstand og giver ingen oplysninger om den tilstand, kun resultaterne.

Gør det vanskeligt at gætte, hvad der foregår.

 

[Elephantus]

Med bus påstand talte jeg på en påstand om ATmega multipleksede lavere adresse / data bus.Det skriver betingelse er helt specifik ansøgning, og jeg ønskede at undgå at komme i drift detaljerne i designet, så jeg ikke det.

Men det vigtigste spørgsmål, jeg ønskede at adressen er ikke bussen hævder selv, men det faktum, at den ulovlige data på bussen, som er forårsaget af den påstand er stikprøven i flip flops forbundet med bussen, som ikke kunne ændre tilstand på det tidspunkt (de er udløst af den faldende kanten af den eksterne adresse klinken give signal, som er (eller skulle jeg sige synes) inaktiv på det tidspunkt).

Spørgsmålet er, kan en uregelmæssig / udefineret / ustabil tilstand på inddatalinjer af DFF's korrupte af DFF's stater, eller skal jeg formode, at en uopdaget glitch er til stede på den adresse låsen give signal.

Hope this rydder lidt op.