Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10

[Vincenzo Pellegrini]

Dear John,
let me first thank you for your interest in our work upon SR-DVB and,
particularly, MA.
I consider it and the questions you asked us a great honor.

This said, well:

for MA paper. We're striving to get the first articles on paper
somewhere around September/October 2010. We will do all that is in our
power to reduce this time as much as possible.

I'm not aware of any means to disclose MA content earlier than that
without losing opportunity to have it published in some major wireless
signal processing conference / journal.
If you are, please tell, we're looking forward to suggestions.

MA is well suited for all radio signal processing implementations
running on GPPs and DSPs (I actually suspect we can apply this concept
even on FPGAs), so there really is no problem at all in using MA
within GNURadio.
Actually I would probably be one of the happiest men on the planet if
people from this community just could find MA interesting enough to
start investing some of their time producing MA-SDRs (and, why not,
MB-SDRs) within GNURadio. I believe great potential exists along this
road, and I'd love to be given the opportunity to prove it. So far I'm
endeavouring to do my best with the instruments I can currently
access.

Also, consider that the average 10.something acceleration factor that
we obtained both on the Viterbi decoder and on the Borjesson
synchronizer is something we got to in about 7 months of
Master-thesis-level work done just with currently available RAMs,
currently available caches and currently available CPUs, which are
totally unaware of  the MA approach.
We believe (and will work in order to prove) that, by means of a few
minor tweaks to currently available commercial CPUs and memories
(which would make them MA-friendly), dramatic computational
efficiencies can be achieved. This would give substantial
contribution, along with the ultra precious tools already in place,
such as GNURadio and the USRP, to move real world, real-time radio
design from circuit-level to SW-level development, with all the
consequences in terms of accessibility to developing communities that
we all know very well.

So far, after having worked on SDR implementations for about 3.5 years
(not so many, but still something more than a few months), I have met
a few SDR approaches and frameworks along the road. GNURadio is by far
the best. Particularly I find it settled on a very interesting
trade-off point between on the fly reconfigurability capabilities /
code re-usability and low level computational HW control.

Reasons for developing a small ad-hoc framework have nothing to do
with GNURadio unfitness. They are mainly a matter of personal taste
driven by the following reasons, in order of importance:

1. Ease of synchronization
when building up a receiver, alignment on data streams is absolutely
crucial. Indeed it is one of the major things differentiating  a
receiver from a transmitter.
If nothing changed since I asked last time, we obtain block
synchronization in gr by adding some sort of additional
synchronization stream reaching all blocks that need a synchronization
mark. This actually maps in SW what you do on the test bench when you
carry around the sync cable to all connected subsystems of the test
chain.
If I can touch and move my samples directly (i.e. not rely on a
runtime system that pushes samples throughout the chain but simply
decide how to move them around) I have non need for additional synch
signals/streams.

2.Dependencies
with our framework we are (currently) only dependent on libursp and
fftw. Being dependent on the bunch of sw that gr requires... makes me
feel like standing on a tower of glasses. Maybe this is just because
I'm not that good as a programmer, especially if you assume a modern
programming style, but really I feel better this way.

3. Simplicity
Being really "basic-level" as a programmer, I came up with something
extremely basic. I mean, what we call newRADIO, hardly exists.
Therefore, learning how to program within it is a matter of minutes (I
really mean actual minutes). And, though probably incomplete, it
simply works well for us, giving us a good feeling that we can touch
and control our computational resources at a very low level.
My point is that:

  .:. Abstraction is useful but has a cost, so all abstractions not
directly required
      by a strong need should be avoided

  .:. Abstraction is the MAGIC in traditional software, where most of the
      complexity is LOGICAL. With logical issues, abstraction rules.
      Still, with SDRs most of the complexity is computational, and most of the
      effort should be devoted to improving computational performance of the
      system rather than making it "logically more powerful".
      Indeed, we have been building radios for ages just with silicon.
      Using lines of code instead of that is already sufficient in my opinion to
      produce enough innovation and provide enough flexibility to our
      new generation of radios. I don't expect approval on this, but
      my personal opinion is that templates and other similar creatures
      (probably even classes) are not substantial to SDR.

  .:. Yes, by programming almost bare-metal as we do, it is easier to make
      mistakes. But an SDR is not a database and has another peculiarity:
      It spans very quickly its own state space, as a consequence it
is very easy
      to produce tests that quickly show problems and anomalies.
      I mean: a bug in a database can appear under some very particular and rare
      conditions, Soft-DVB and SR-DVB do transit throughout all of
their possible
      states in seconds. If there's something wrong you simply notice it.

4.License
I was once told by a GPL enforcer that with Soft-DVB I had two options:
release, or put it in a drawer.
I did not really know whether he was right or not.
But I felt like, after all the work spent there, I wanted to be able
to decide myself what to do with the code. What to release, when and
how. Maybe just to decide to release everything at once, but actually
I felt I had the right to be the one taking such choice. The day after
I was developing my own framework.

John,
thanks for giving me the chance to discuss these issues.
Though aware of their scarce popularity, I hope my considerations can
be of some utility. I'm interested in further discussion.

my best regards to you and everybody

vincenzo









-- 
Vincenzo Pellegrini
http://www.youtube.com/user/wwvince1