Re: [Discuss-gnuradio] Encoder Integration

[S Mande]

Thank you everyone for your inputs.

I knew that integrating the Viterbi algorithm on the receiver side is going
to take a lot of work. And I had seen gr-trellis folder, which had the
Viterbi decoder implementation, which I was planning to use for the time
being.

I was thinking of atleast integrating the encoder on the transmitting side
first.

I think that if I replicate the transmitter side steps (steps 2 to 5 in my
earlier post) in Verilog on the FPGA, then the data packets getting
transmitted from transmitter side would be same as the current
implementation. Then, I can use the existing Achilleas's Viterbi decoder on
the receiver side to decode my data for the time being. *~*  Any comments ?
*~*

I am not sure, but dont see a reason why this should'nt work !

Does anyone has any comments on  *~*~*  if 4 steps (in Verilog) in my
earlier post, would 'replicate'  the existing transmitting steps or anything
else needs to be added?   *~*~*

I plan to finish the transmitter side implementation as soon as possible and
then moving ahead.


Best Regards,
S. Mande.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Johnathan Corgan]

Brian Padalino wrote:

> Rebuilding an entire FPGA image on the fly isn't in the cards just
> yet, though some high end Xilinx FPGAs do support "partial
> reconfigurability" which will allow a design to have a standardized IO
> interface and all the "guts" are reprogrammed without powering down
> the device.
> 
> This could allow, in theory, one "IO ring" to be made for the USRP and
> the user would fill in the "guts" with their signal processing
> application (eg: wideband TDMA, CDMA, narrowband FSK, etc).  As long
> as each of the guts had the same hooks to the outside, the FPGA can be
> put into a state of lockdown while being reprogrammed, and a reset can
> be applied to the guts once reprogrammed.

Not sure if USRP2 FPGA supports this or not.  Not a bad idea to floor
plan, get timing right, and lock down the non-DSP parts, and let the
user create an inner application with abstract ports.  But I'd be happy
with a compile-time logically equivalent code organization.  I think
Matt's already planning for it.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Johnathan Corgan]

Dan Halperin wrote:

>> In terms of software radio, reprogramming an FPGA with a different
>> bitfile is no different than changing a flowgraph, in my opinion.  The
>> only thing really hard in the chain is the RF front end for grabbing
>> the signals.  It's all "software" from that point on.
> 
> Agreed!

Agree as well.  While it is definitely (much) more work, hacking the
USRP FPGA code provides access to much wider swaths of spectrum on RX
and TX.

>> In all honesty, I wouldn't mind if the FPGA were more flexible at
>> compile time and less flexible at runtime.  I feel this would trim
>> away some of the "fat" associated with being so flexible at runtime,
>> and allow for better use of the USRP's FPGA for more low latency
>> processing.
> 
> In order for SDRs that think of their FPGA code as software (which I
> think has to be where this is going to realize its full power), it seems
> likely that we will need completely automated and reasonably fast ways
> to rebuild the FPGA on the fly. Do these exist?

I've done a few commercial contracts for custom FPGA code for the USRP.

One thing that's needed is a refactoring of the top-level code to allow
drop-in replacement of the "standard" functionality with a custom
module, while reusing all the peripheral logic, FIFOs, USB interface, etc.

Right now, however, the top level is completely separated into transmit
and receive paths which are independently configured, reset, etc.  This
is normally the case with host-based apps that can handle any
transmit-receive interdependencies in host code.  Without breaking this
model, then, it would be easy to refactor into a 'receive_app.v' and
'transmit_app.v' that would have a port list for the "inside API" from
the ADCs to the RX fifo and from the TX fifo to the DAC.

Then, if you only had a receive_app.v, there could be a stub
transmit_app.v that would ultimately result in all the transmit side
logic being pruned out during synthesis.

But some FPGA applications (like gr-radar) don't really separate RX and
TX functionality.  I suppose you could still join these together
underneath your custom transmit and receive app modules with some glue
between them.

Re-synthesizing the FPGA code is pretty simple with the Altera tools.
Unfortunately, these are Windows only.  Someone had some luck with
running these under Wine in Linux, but that's probably a pretty fragile
hack.

USRP2 uses a Xilinx part with their native Linux ISE port, and the
development build uses a Makefile to invoke the CLI tools.  So in that
environment, automating rebuilds for custom changes wouldn't be too
difficult.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Brian Padalino]

On 10/29/07, Dan Halperin <[EMAIL PROTECTED]> wrote:
> In order for SDRs that think of their FPGA code as software (which I
> think has to be where this is going to realize its full power), it seems
> likely that we will need completely automated and reasonably fast ways
> to rebuild the FPGA on the fly. Do these exist?

Rebuilding an entire FPGA image on the fly isn't in the cards just
yet, though some high end Xilinx FPGAs do support "partial
reconfigurability" which will allow a design to have a standardized IO
interface and all the "guts" are reprogrammed without powering down
the device.

This could allow, in theory, one "IO ring" to be made for the USRP and
the user would fill in the "guts" with their signal processing
application (eg: wideband TDMA, CDMA, narrowband FSK, etc).  As long
as each of the guts had the same hooks to the outside, the FPGA can be
put into a state of lockdown while being reprogrammed, and a reset can
be applied to the guts once reprogrammed.

The reprogramming time is on the order of milliseconds to hundreds of
milliseconds I believe, but I could be mistaken.

More information with regards to the Xilinx specific implementation
can be found here:


http://www.xilinx.com/products/design_tools/logic_design/advanced/partialreconfig.htm

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Padalino wrote:
> On 10/29/07, Achilleas Anastasopoulos <[EMAIL PROTECTED]> wrote:
>> PS: I have mixed feelings about all this being implemented on the FPGA:
>> is this a software or a hardware radio?
> 
> In terms of GNURadio, I can agree with the mixed feelings.  I feel
> that GNURadio is a good framework to explore the spectrum and radio
> communications systems.
> 
> In terms of software radio, reprogramming an FPGA with a different
> bitfile is no different than changing a flowgraph, in my opinion.  The
> only thing really hard in the chain is the RF front end for grabbing
> the signals.  It's all "software" from that point on.

Agreed!

> In all honesty, I wouldn't mind if the FPGA were more flexible at
> compile time and less flexible at runtime.  I feel this would trim
> away some of the "fat" associated with being so flexible at runtime,
> and allow for better use of the USRP's FPGA for more low latency
> processing.

In order for SDRs that think of their FPGA code as software (which I
think has to be where this is going to realize its full power), it seems
likely that we will need completely automated and reasonably fast ways
to rebuild the FPGA on the fly. Do these exist?

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJhu2y9GYuuMoUJ4RApLhAKC2gVlZYHQeANpbQKTPyr9HfzE6bgCfa7Qd
Zc1C/VJSOgL08B4r/VIrW1Q=
=dQRO
-END PGP SIGNATURE-


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Brian Padalino]

On 10/29/07, Achilleas Anastasopoulos <[EMAIL PROTECTED]> wrote:
> Brian,
>
> FYI, soft versions of the Viterbi decoder (named soft-input/soft-output
> blocks) are already implemented in gr-trellis.
> In addition a serially concatenated code, and corresponding turbo
> decoder is implemented using these blocks in the corresponding
> examples directory.

Very nice.  Thanks for pointing that out!

> Achilleas
>
> PS: I have mixed feelings about all this being implemented on the FPGA:
> is this a software or a hardware radio?

In terms of GNURadio, I can agree with the mixed feelings.  I feel
that GNURadio is a good framework to explore the spectrum and radio
communications systems.

In terms of software radio, reprogramming an FPGA with a different
bitfile is no different than changing a flowgraph, in my opinion.  The
only thing really hard in the chain is the RF front end for grabbing
the signals.  It's all "software" from that point on.

In all honesty, I wouldn't mind if the FPGA were more flexible at
compile time and less flexible at runtime.  I feel this would trim
away some of the "fat" associated with being so flexible at runtime,
and allow for better use of the USRP's FPGA for more low latency
processing.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Achilleas Anastasopoulos]

Brian,

FYI, soft versions of the Viterbi decoder (named soft-input/soft-output 
blocks) are already implemented in gr-trellis.

In addition a serially concatenated code, and corresponding turbo
decoder is implemented using these blocks in the corresponding
examples directory.

Achilleas

PS: I have mixed feelings about all this being implemented on the FPGA: 
is this a software or a hardware radio?



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[Brian Padalino]

Here are some of the thoughts running through my head in no particular order.

You don't have to have the RRC filter for transmit if you don't want
to.  The CIC and the reconstruction filter of the DAC should take care
of filtering out a good portion of the extra spectrum.

To achieve the best performance with the convolutional code, some
interleaving should also be used to utilize time diversity on the
burst transmission.

The modulator LUT should really be an M-QAM LUT that can be configured
to restrict itself to QPSK or BPSK as well.

Another option would be to try to figure out a CPM style mapper that
can be used and/or updated in-band to utilize a different number of
CPM waveforms that require no extra filtering and have the filtering
built into the LUTS.

The Viterbi decoder will probably not be of use while there is no
receiver functionality built into the FPGA as well.  As such, the
testbench for the Viterbi decoder should probably be extremely
extensive and more effort should go into making the decoder extremely
generic (eg: How many ACS units to use in parallel, should traceback
be done in a burst or windowed, programmable constraint length and
generator polynomial, etc).

How hard would it be to change the algorithm to be a soft output
Viterbi algorithm (SOVA) for use with Turbo Codes?  Here is a little
stub:

http://en.wikipedia.org/wiki/Soft_output_Viterbi_algorithm

Robustness is key to utilizing this code in the fullest extent.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Encoder Integration

[S Mande]

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

Re: [Discuss-gnuradio] Encoder Integration

[Martin Dvh]

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

[Discuss-gnuradio] Encoder Integration

[S Mande]

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 ?

Any inputs on the above would help me. I am stuck with this problem for
quite some time now.


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