Newsgroup: it.hobby.elettronica.digitale
Titolo: Demodulazione I e Q in una FPGA

Salve a tutti, è la prima volta che scrivo qui spero di rimanere in
linea con il manifesto.
Vi spiego il mio problema, devo realizzare un Digital Down Converter
all'interno di una FPGA. Sono al primo stadio ovvero la moltiplicazione
con il seno e coseno per la demodulazione, visto il particolare rapporto
di frequenze scelto questo si traduce in una moltiplicazione della
sequenza di ingresso per (1 0 -1 0) per la componente I e per (0 -1 0 1)
per la componente Q.
Ho pensato allora di passarei il segnale di clock all'interno di un
contatore modulo 2 e di usare l'uscita di questo contatore come segnale
di selezione per una sorta di multiplexer a quattro ingressi. Il codice
VHDL di uno di questi due "multiplexer" lo trovate di sotto.
I tool che uso sono Xilinx ISE 6.1 e Modelsim XEII 5.7c.
Nella simulazione con i tempi (quella dopo il PAR) ho notato alcune
transizioni indesiderate. In particolare quando il segnale SEL si trova
passa al valore "01" i bit di uscita non cambiano tutti insieme, e
quindi ci sono una serie di transizione "spurie".
Visto che sono nuovo a questo tipo di progettazione mi chiedevo se
questo può essere un problema, se dipende dal codice scritto male,
oppure se è fisiologico.
Ho provato anche a modificare il codice utilizzando invece del segnalde
DEMOD_OUT una variabile di appoggio DEMOD e poi effettuando
l'assegnazione a DEMOD_OUT solo alla fine del process, ma l'RTL
sintetizzato è identico nei due casi.
******************Q_Demod.vhd***************************
library IEEE; 
use IEEE.STD_LOGIC_1164.ALL; 
use IEEE.STD_LOGIC_ARITH.ALL; 
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity Q_Demod is
port(
    CLK     : in  STD_LOGIC; 
    INPUT   : in  STD_LOGIC_VECTOR(13 downto 0);
    SEL     : in  STD_LOGIC_VECTOR(1 downto 0);
    DEMOD_OUT : out STD_LOGIC_VECTOR(13 downto 0)
    );
end Q_DEMOD;
architecture Behavioral of Q_DEMOD is
begin
------------------------------------------
process (CLK)
begin
   if rising_edge(CLK) then
     case SEL is
       when "00" => DEMOD_OUT <= "00000000000000"; --  0
       when "01" => DEMOD_OUT <= (not INPUT) + 1;  -- -1
       when "10" => DEMOD_OUT <= "00000000000000"; --  0
       when "11" => DEMOD_OUT <= INPUT;            --  1
       when others => NULL;
     end case;
  end if;
end process;
------------------------------------------
end Behavioral;
******************Q_Demod.vhd***************************
-- 
Il Paradiso lo preferisco per il clima, l'Inferno per la compagnia.
(Mark Twain)
 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 quindi ci sono una serie di transizione "spurie".
Non si capisce bene la frase, si trova o passa?
Queste transizioni le hai subito dopo il clock o indipententemente
dal clock?
Nel primo caso e' normale che i vari segnali di un circuito sincrono
non commutino tutti esattamente insieme, sarebbe un caso rarissimo
se lo facessero. Percio' il dato viene preso quando anche il bit piu' lento
si e' stabilizzato, e questo lo si deduce dal'analisi temporale che
i tools forniscono. Spero che fosse quello che volevi sapere. Ciao.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 i tools forniscono. Spero che fosse quello che volevi sapere. Ciao.
Si in effetti è giusto quello che dici. Insomma è normale che ci sia un
pò di transitorio prima dello stato finale.
Ora sto avendo un altro dubbio, ho ripetuto la simulazione scalando il
clock ai valori che avrò sulla scheda, quindi a 64MHz, in pratica ho
impostato Tup=Tdown=7812ps (finora avevo usato i valori di default
ovvero Tup=Tdown=50ns).
Beh ho notato delle cose un pò strane (almeno per me che sono nuovo a
queste cose), in pratica c'è una fase iniziale (almeno 3/4 colpi di
clock) nella quale l'uscita non cambia, poi dopo inizia a funzionare ma
rimane ritardato di quei 3/4 colpi di clock rispetto all'ingresso. Ho
come il dubbio che il circuito sia troppo lento per quel clock,
l'analisi temporale del circuito mi restituisce questi valori:
Timing Summary:
---------------
Speed Grade: -6
   Minimum period: No path found
   Minimum input arrival time before clock: 4.062ns
   Maximum output required time after clock: 4.575ns
   Maximum combinational path delay: No path found
Mi sembrano troppo vicini al periodo del clock, ma non saprei in realtà
come legare le due cose, mi sapete dare una mano ad interpretare tali
valori?
-- 
Life is not a cabaret. It's a fucking circus.


 quindi ci sono una serie di transizione "spurie".
E' normale... Nel senso che è insito nella tua descrizione VHDL...
Il problema nasce dal fatto che hai descritto un circuito completamente
combinatorio, che contiene un multiplexer a 4 bus da 14 bit (che già di per se è
una discreta fonte di ritardi di propagazione e skew), preceduto da un sommatore
a 14 bit, anch'esso puramente combinatorio.
Quando selezioni il ramo del mux corrispondente a "01" il segnale deve
attraversare oltre al mux anche il sommatore. Questo è uno dei circuiti più
lenti che si possono implementare in una FPGA! [Anche usando i carry chain
dedicati] Di conseguenza i vari segnali ci impiegano un bel pò prima di arrivare
tutti all'uscita del mux.
Se questo è o meno un problema per il funzionamento del circuito non posso
dirtelo in base alle informazioni che hai dato. Anche le eventuali soluzioni
dipendono da molti fattori.
Qual è l'applicazione?
A che frequenza vengono campionati I e Q?
Qual è la frequenza del clock principale del sistema?
Cosa c'è a valle del Down Converter?
Ciao,
A.D.

 Cosa c'č a valle del Down Converter?
Subito a valle di questo blocco ci saranno due filtri passa basso (con
decimazione) e poi altri stadi come filtro adattato ...
Sul fatto che la mia entity sia lenta qualche dubbio mi era venuto (se
guardi anche l'altro messaggio nel thread), mi sapresti mica consigliare
un modo di implementare la stessa cosa in un modo piů veloce?
-- 
E' una notizia importante, per radio la possono vedere tutti. (Aldo
Biscardi)


 un modo di implementare la stessa cosa in un modo più veloce?
Sicuramente se quel codice lo infili in una cpld avrai prestazioni migliori.
Comunque con una struttura pipelined puoi avere eccellenti risultati
anche con dispositivi meno efficienti.


 per quelle sequenze (1 0 -1 0) e (0 -1 0 1).
scusa, non sono affatto esperto in materia e anzi sto studiando adesso 
queste cose. Mi spiegheresti - se hai voglia - il perchè di questo 
ragionamento ?
Grazie,
Marco / iw2nzm

 un modo di implementare la stessa cosa in un modo più veloce?
Il modo migliore per risolvere il problema (anche considerate le frequenza in
gioco) è quello di "pipelinizzare" il più possibile il datapath, cioè introdurre
dei registri prima di (o addirittura in mezzo ad) ogni blocco combinatorio
lento. Ad esempio nel codice che avevi postato ci andrebbe almeno un registro
dopo l'adder, ed uno dopo il mux. Il ritardo di attraversamento dei
registri (cioè il numero di cicli di clock richiesto) non dovrebbe essere
influente
ai fini del funzionamento a regime del circuito, ci sarà solo
un ritardo fisso tra l'ingresso del segnale e l'uscita dei dati demodulati.
Questo ritardo in genere non dà fastidio, ma dipende dall'applicazione! Ci sono
certi standard o protocolli che impongono dei limiti massimi.
Ciao,
A.D.
P.S. Anche io sto lavorando ad un baseband processor per ora... Da quì la mia
curiosità... :-)

Mentre io pensavo ad una intro simpatica "Marco Trapanese" scriveva:

Beh spiegare cosa? Quale è il punto che non ti è chiaro? 
Il concetto è tuttosommato semplice, la DDC non è nient'altro che una
demodulazione (quindi moltiplicazione per la portante e filtraggio
passabasso per eliminare le repliche indesiderate), con la differenza
che tutto è fatto in digitale, quindi il mixer è in realtà un
moltiplicatore, la portante è in realtà una sequenza digitale, ed il
filtro è un FIR realizzato con moltiplicatori e sommatori.
-- 
Confucius say... Girl laid in tomb may soon become mummy.


 curiosità... :-)
Cool, tu invece di preciso per che cosa lo stai realizzando?
-- 
User error. It's not our fault. Is not! Is not!


 Cool, tu invece di preciso per che cosa lo stai realizzando?
Dovrebbe essere un baseband (modem) per segnali spread spectrum...
il target iniziale è una modulazione DSSS tipo quella usata in 802.11,
poi se ci riusciamo vorremmo provare anche con OFDM ed altre cose
un pò più sofisticate...
Alla prossima,
A.D.

 Beh spiegare cosa? Quale è il punto che non ti è chiaro? 
come dicevo sto studiando queste cose da pochissimo tempo. Quello che 
non mi è chiero sono due cose:
- il 4 nella relazione (4 * 112 MHz) / 64 MHz = 7 cosa rappresenta ?
- perchè se il risultato è un intero dispari allora le sequenze sono (1 
0 -1 0) e (0 -1 0 1) ?
Grazie della pazienza!
Marco / iw2nzm

 0 -1 0) e (0 -1 0 1) ?
L'idea è molto semplice. Diciamo x(t) il tuo segnale da demodulare, x(t)
sia un segnale a banda stretta di frequenza centrale f0, allora lo puoi
scrivere come somma delle componenti seno e coseno:
x(t)=I(t)sin(2*pi*f0*t)+Q(t)cos(2*pi*f0*t)
Ora campiona il segnale negli istanit kT con T=1/fc
(fc=frequenza di campionamento).
Il segnale campionato sarà:
x(kT)=I(kT)sin(2*pi*k*fo/fc)+Q(kT)cos(2*pi*k*fo/fc)
ora per semplicità x(kT),I(kT) e Q(kT) li chiamiamo x(k),I(k) e
Q(k), inoltre poni 4f0/fc=d avrai:
x(k)=I(k)sin(d*pi*k/2)+Q(k)cos(d*pi*k/2)
Se prendi d intero dispari (lo ottiene scegliendo opportunamente le
frequenze) vedrai che quelle sequenze seno e coseno hanno una succssione
del tipo:
  k  =  0      1      2      3      4      5      6
sin  =  0      1      0     -1      0      1      0
cos  = -1      0      1      0     -1      0      1 
e quindi:
x(k)= -Q(0)   I(1)   Q(2)  -I(3)  -Q(4)   I(5)   Q(6)
Da cui vedi che se moltiplichi x(k) proprio per quelle due sequenze seno
e coseno otterrai le due componenti I e Q. 
x(k)*sin = 0     I(1)   0   -I(3)   0     I(5)    0
x(k)*cos =-Q(0)   0    Q(2)   0   -Q(4)    0    Q(6)
Un filtraggio passabasso per eliminarei gli zeri intervallati e
riallineare le sequenze ed il gioco è fatto, avrai ottenuto le due
componenti I(k) e Q(k).
-- 
I need someone really bad... Are you really bad?


 un pò più sofisticate...
Sono molto simpatiche le modulazioni per segnali spread spectrum, io ho
avuto modo di vedere qualcosina qualche anno fa, quando ho realizzato
una piccola relazione su Bluetooth (allora emergente).
-- 
(Across a drawing of a skeleton) Waiting for the perfect man.
