Come per esempio un segnale molto lento?

Q

questionmark

Guest
Hi there,
Sto progettando un FPGA.Corre a freq clcok di 100MHz.Ho bisogno di campione di un ingresso asincrono al di fuori di FPGA.E 'un segnale lento, la freq è 100Hz (si prega di notare: non MHz), e l'aumento / EDGE di cui è lenta (circa 5 noi), e la variazione del periodo è di circa il 10%.Voglio contare il periodo di tempo di tale segnale.Cosa devo fare?Per esempio il segnale direttamente con 100MHz di clock o dividere l'orologio ad una molto più lento e che utilizzare il clock generato per esempio il segnale?Grazie!

 
Analitycy bezpieczeństwa Doctor Web wykryli nowego trojana zaprojektowanego do wykradania pieniędzy z kont bankowych osób korzystających z systemu And ...

Read more...
 
Hi questionmark,

Se la mia comprensione è corretta, il vostro obiettivo è quello di misurare il periodo del segnale la cui frequenza è di circa 100 Hz.Corretta?
È possibile mesure direttamente il numero di periodi di clock di 100 MHz che si adattano in un periodo del segnale, l'accuratezza dei Calcolo della più di un periodo è di circa 1
/ 1000 e la misura può essere aggiornato in ogni ciclo.
Mesuring il tempo durante i cicli di più a garantire un migliore precisione, ma il canges nei cambiamenti di frequenza vengono monitorate più lentamente.
Saluti

Z

 
grazie zorro.La vostra comprensione del mio obiettivo è corretta.
Credo che tu abbia notato che il segnale è molto lenta crescita / EDGE in calo, il che significa, molti dei campioni che colpirà la crescente / fronte di discesa del segnale lento.Si sa, la tensione sta cambiando in aumento / EDGE in calo, molti dei campionati di tensione è al di fuori del campo giuridico (per esempio, 0-0.9V come logica 0 e 1.8-2.5V, come logico 1).Sarà questa causa alcun problema?

 
questionmark,

Vorrei suggerire che il rimedio più affidabile per la vostra situazione si trova al di fuori della vostra FPGA.Ecco alcuni numeri per voi:

- La risoluzione del clock rispetto a quella del vostro evento esterno è: 100MHz/100Hz = 1 milione di orologi per un evento che è particolarmente elevato.Per ogni ciclo di lavoro si ve got metà di quella cifra che è di 500 orologi K.In condizioni ideali, si ll essere in grado di rilevare le variazioni da un minimo di 100Hz * (1/500K) = 0.0002 Hz nel vostro segnale in entrata.In modo da capire come accurate misurazioni volete che il vostro essere.

- Dopo aver detto che si dovrebbe notare che la crescente / EDGE di cui costituisce (5us/0.01s) * 100 = 0,05% del vostro evento esterno.Che è, mentre la risoluzione del tuo orologio è (1/500K) = 2u, avete errore intrinseco nel vostro sistema è pari al 0,05% del segnale in ingresso (la precisione).

- Dunque, secondo una prassi comune di ingegneria in cui si afferma che la precisione è di circa dieci volte peggiore di quella risoluzione, vi consiglio di don campione t il segnale più veloce (0,0005 * 10) ^ -1 = (0,005) ^ -1 = 200 normalizzato Hertz che, se tradotto nella tua sistemi risultati orologio in clk_sys / clk_event = 200 => clk_sys = 200 * 100 = 20 MHz solo!

Se siete interessati ad ottenere una migliore accuratezza, l'unico è stato possibile, a mio parere è quello di buffer il segnale esterno in modo che il crescente / figure fronte di discesa c'è di meglio.Questo può essere un confronto veloce che ci si sintonizza di conseguenza (soglia), o quello che trovano adeguata.

Spero che questo sia vantaggioso per voi.

Salute.

 
questionmark ha scritto:

Si sa, la tensione sta cambiando in aumento / EDGE in calo, molti dei campionati di tensione è al di fuori del campo giuridico (per esempio, 0-0.9V come logica 0 e 1.8-2.5V, come logico 1).
Sarà questa causa alcun problema?
 
Grazie per il vostro aiuto, Manny_Calavera e tkbits.
Io uso un 2-FF fase di sincronizzare il segnale esterno asincrono prima che entri in contrasto con la logica di evitare la condizione peggiore tkbits menzionati.Ma come risolvere il problema di altri, vale a dire, i campioni che ha colpito il sorgere / fronte di discesa sarà 0 o 1 a caso (dipende da rumore?).Il che significa che mi metterò un segnale campionato, come dimostra il sequestro.
Come posso misurare un segnale del genere?
Ci dispiace, ma è necessario il login per visitare questo allegato

 
Come ti ho detto prima, la cosa migliore da fare è quella di buffer il segnale lento esternamente come non si può andare in giro slew-rate in software!

 
Hi Manny_Calavera,
grazie per il suggerimento, ma mi dispiace non mi riesce quasi mai a "buffer il segnale lento all'esterno".Come fare?BTW.Il segnale viene da un altro dispositivo a bordo e non ho il controllo.Inoltre, non posso aggiungere alcun dispositivo aggiuntivo alla pensione in quanto la commissione è già lì.
e, sto pensando di usare un hardware contatore per misurare il periodo del segnale, non il software, anche se credo che HW / SW non è il punto chiave della questione.

 
Allora devi accontentare di quello che hai in mano.Assicurati di buffer il segnale all'interno della FPGA, e procedere con le vostre misure di duty cycle.Solo tenere a mente i limiti del sistema in termini di precisione.A parte questo, non credo che si possa fare nulla.Quello che volevo dire da un software è il firmware configurabile.Sono d'accordo che si tratta di una forma di progettazione hardware, ma alla fine si tratta di un approccio algoritmico in contrasto con hardware dedicato.Comunque questo è irrilevante.Se you'r appassionato di ottenere il massimo assoluto di metodo, pensare a correggere le vostre misure con qualche "a priori" della conoscenza come il tuo aumento / la speranza di fronte di discesa accoppiato con i dati statistici derivati e aggiornato nel corso di un regolare intervalli distanziati.Alla fine, il sistema imparerà e coverge a risultati accettabili.

Salute.

 
questionmark ha scritto:

Ma come risolvere il problema di altri, vale a dire, i campioni che ha colpito il sorgere / fronte di discesa sarà 0 o 1 a caso (dipende da rumore?).
 
zorro ha scritto:Il problema causato da slew rate lento può essere risolto con un comparatore con isteresi (ad esempio un cancello trigger Schmidt).
 
FPGA cosa stai usando?Famiglie Xilinx hanno Digital Clock Manager che condiziona l'ingresso di clock e elimina skew.Voglio dire che è possibile alimentare il segnale di uno di quei DCM di ottenere una versione pulita di esso.

 
Se il segnale non era rumoroso si andrebbe bene, giusto?

Ora, scoprire come il rumore che si ha.Usando sqrt (4kTR) se si conosce la resistenza della sorgente, o utilizzando il tuo oscillo.Se la deviazione standard del segnale è, diciamo 10mV, e il tuo sweep va 200kV / s, allora sarete durante 50nanosecond in tale 1sigma.A seconda del BER si può ammettere, si può prendere 4sigma, così si dovrebbe campione a 0.2us.Che è decimare di un fattore 256.O media.

 
E 'abbastanza bello vedere che mi e Fogh quasi raggiunto le stesse conclusioni con metodi completamente diversi.

Ricordo che quando ho detto:
--Quote:

Pertanto, secondo una prassi comune di ingegneria in cui si afferma che la precisione è di circa dieci volte peggiore di quella risoluzione, vi consiglio di don campione t il segnale più veloce (0,0005 * 10) ^ -1 = (0,005) ^ -1 = 200 hertz normalizzato che, se tradotto nella tua sistemi risultati orologio in clk_sys / clk_event = 200 => clk_sys = 200 * 100 = 20 MHz solo!
 
CMOS babe ha scritto:

FPGA cosa stai usando?
Famiglie Xilinx hanno Digital Clock Manager che condiziona l'ingresso di clock e elimina skew.
Voglio dire che è possibile alimentare il segnale di uno di quei DCM di ottenere una versione pulita di esso.
 
tkbits,

Sono d'accordo con te che in casi normali, questo sarebbe pericoloso come transizione a lungo in stato indefinito servirà a nulla, ma per aumentare la probabilità di un fronte del clock hit conseguente disastro.Tuttavia, non pensate che il buffer il segnale all'interno della FPGA pigro può ridurre il rischio, come le caratteristiche di commutazione (digitale non analogica) del buffer ora avrà la precedenza su quella del segnale esterno?Naturalmente il rischio sarà sempre presente come qualsiasi segnale esterno asincrono.Ma il problema con la lenta transizione è superata a scapito delle prestazioni tempi di degradazione (tempo limite vaghi), che è un altro problema ora.Tenete a mente l'architettura del IOB nella FPGA.Inoltre, in questa particolare applicazione, non vi è alcun bisogno di 3-sincronizzatore palco come è garantito che l'orologio interno colpito il segnale dopo un cambiamento si è verificato.Mi piacerebbe sentire il vostro parere a questo riguardo.Tra l'altro, Thanx for the link interessanti.

Salute.

 
questionmark ha scritto:zorro ha scritto:Il problema causato da slew rate lento può essere risolto con un comparatore con isteresi (ad esempio un cancello trigger Schmidt).
 
a implimet sxhmit scatenare tutto il necessario per l'uso del diodo, e pull up o pull down resistenza (che dipende dalla polarità sei rilevazione) resistenza, è sufficiente collegare il vostro signalto input un ingresso FPGA, e lo stesso segnale di ingresso attraverso diodo per il secondo ingresso e creare confronto dentro, se sarà necessario un uso più con una precisione due diodi in tre ingressisaluti,

 
Manny_Calavera ha scritto:

Inoltre, in questa particolare applicazione, non vi è alcun bisogno di 3-sincronizzatore palco come è garantito che l'orologio interno colpito il segnale dopo un cambiamento si è verificato.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top