Thank you Martin for your reply.

I wasent sure if rest of the 4 steps needed to be pushed to the FPGA ? And
if the current USRP implementation on the FPGA leaves that much room for
expansion?  This is where I was stuck, thinking if there was any other
alternate flow / solution ?

So, i guess the flow should be:

1) Generate the bits on the host. (Then, Pass on those raw bits to the FPGA)

Everything after this on the FPGA.

2) Mapping of the bits to symbols (This should'nt be difficult as this can
be implemented using look up tables in Verilog)  -- Needs to be implemented
in Verilog
3) Convolving the symbols with root raised cosine filter (or any other wave)
-- Needs to be implemented in Verilog
4) Sampling the resultant signal. -- Needs to be implemented in Verilog

After this, it should be normal flow of the existing GNU Radio FPGA
implementation.

Please correct me if I am going wrong or please reply if I am right (It is
easy to confuse no response with being right !)

Also, I would be more than happy to use your (Martin) code, as it will save
my time reimplementing the same logic again.

I think that my code would be more meaningful to others, once I have atleast
integrated the 'transmitter' portion.


Best Regards,
S. Mande.


P.S. Martin: I would be happy to use your code if you could send the same to
[EMAIL PROTECTED] (with appropriate rights / notices if you wish) ! It was
kind of you to suggest the same to me.




On 10/28/07, Martin Dvh <[EMAIL PROTECTED]> wrote:
>
> S Mande wrote:
> > Hi,
> >
> > I have implemented a convolutional encoder and a viterbi decoder in
> Verilog
> > and am trying to integrate it with the existing GNU Radio software and
> make
> > it available to everyone, once I integrate it.
> >
> > My encoder takes in the input binary bits and generates encoded binary
> bits,
> > based on defined parameters.
> >
> > I am first focusing on integrating the encoder with the GNU Radio
> software.
> > My understanding from the code is that the following steps are performed
> > while transmitting ( i.e. benchmark_tx.py, transmit_path.py, pkt_py,
> > modulation_utils.py ) :
> >
> > 1)    Generate random bits.
> > 2)    Map bits to symbols (gmsk or any other modulation )
> > 3)    Convolve the symbols with a wave and taking discrete samples
> > (Sampling)
> > 4)    Combine the step (3) samples with header information and make a
> > packet.
> > 5)    Pass it on to the FPGA.
> >
> > Generating bits and sending it to FPGA for encoding using my encoder
> module
> > and sending the encoded bits back to follow the above chain will
> possibly
> > not make sense as I am overusing the bus resources, which would defeat
> the
> > purpose of encoding in Verilog/FPGA . (bus usage should decrease by
> > transmitting raw bits across the bus).
> >
> > So, should I pass all the above (steps 1 to 5) functionalities into the
> FPGA
> > i.e. generate, "encode", map, convolve inside the FPGA and then pass it
> on
> > to the existing functionalities in the FPGA ?
> >
> > Or is there a more optimum way to do this ?
> Well you could still generate the random bits on the host.
> You should however implement the other steps on the FPGA.
> There are ways to implement optimized root-raised cosine filters and
> (fractional) resampler filters in the FPGA if you do BPSK or QPSK.
> (because you only have +1.0 and -1.0 values)
> (I have some code for that if you need it)
>
> You said you already had implemented a convolutional encoder and a viterbi
> decoder in Verilog.
> So it seems like combining all the parts is what has to be done.
> Where exactly are you stuck.
>
>
> > Any inputs on the above would help me. I am stuck with this problem for
> > quite some time now.
> Maybe it would help if you published what you got now somewhere, so people
> can help by looking at your code.
>
>
> >
> > Please correct me if I am going wrong somewhere.
> >
> > Thanks.
> >
> > Best Regards,
> > S. Mande.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to