progress with octave model

Greetings MEP!

Due to a block of uninterrupted time, I managed to hack and slash my way through beginnersville in Octave. I conquered plotting today. Right now, I have an RF and an LO signal attractively plotted in a png (attached). 

The goal is to model the five-port device in Octave, then build it in VHDL. If  you have MATLAB, you should be able to load up the Octave model (attached as well)

If you are wondering what a five-port device is, please know you are not alone. If you have access to IEEE Communications June 2010 issue, then there is an article in there that describes them, including some built and tested examples. 

Here's a snippet from an optical article in wikipedia that refers to the superset of the five-port, which is named six-port. In the IEEE article, the sixth port is described by a dependent equation if you assume that you know the local oscillator power. Since the designer should know this, the design can be simplified down to a five port device. Five ports is as simple as you can get, and has almost all the performance of a six port device. 

"In principle, the six-port device consists of linear dividers and combiners
interconnected in such a way that four different vectorial additions of a
reference signal (LO) and the signal to be detected are obtained. The levels of
the four output signals are detected by balanced receivers. By applying suitable
base-band signal processing algorithms, the amplitude and phase of the unknown
signal can be determined."

I asked the author of the article for the design files used, and hope to hear a response. Having gerbers of a working five-port device that just happens to work on our bands would be a big step forward for this line of research. 

If you've worked on, with, or near six/five port devices, I'd love to hear about it. 

More soon!

 -Michelle W5NYV

Weekly Report 6 August 2010

Greetings MEPsters!

I have a report.

While pedaling away at the gym in continuing efforts to not be fat, I admitted to feeling kind of down in the dumps about tools for MEP. I was feeling somewhat chumpish because it isn't reasonable to ask participants to spend thousands of dollars on MATLAB, Simulink, etc. And, it's easy to start blaming the lack of tools for lack of progress. 

After given a pep talk concerning open source, I installed Octave (open source alternative to MATLAB) and found something called ScicosLabGtk (open source alternative to Simulink). I installed it too. 

After a couple hours of reading tutorials, Octave is less scary and more useful than I expected.

The practice problem I selected was to implement the constraint length 7, rate 1/2 code used on the Voyager space program. 

Also, some time back Roger AD5T sent an article from the June IEEE Communications journal about 5 port devices. I'm asking around to see if we can build some of these. The center frequency is 4.5GHz, and the bandwidth is a whopping 3GHz. The RF and LO are the inputs, and the various combinations thereof comprise 3 outputs. Power detectors are used to make an output signal. There are no mixers. It's kind of whacky, but the article showed working hardware that I'd like to duplicate and evaluate. That sort of bandwidth, by my reckoning, includes both MEP bands at 3.4 and 5.8GHz. 

I can't attach the article due to copyright issues, but I am working on getting it reinterpreted to share on mep-dev. More soon!

Here's an early snapshot of the Octave practice problem included below. It's not (yet) elegant. 

I'm going to do this problem in Octave, then implement it in VHDL using the free version of the Xilinx tools. Remember, version 12 is out, so install and/or upgrade. That will be our baseline VHDL tool for MEP. The idea is to have a mathematical model of the things we do in Octave, and a model in VHDL. The two implementations should agree. 

# Voyager Encoder

# we have a 7-bit register with taps on top

# at 0, 2, 3, 5, 6 (inverter)

# and taps on the bottom 

# at 0, 1, 2, 3, 6 (noninverted)

# signals are multiplexed at the end to get the result.

taps_inverted_side    = [1, 0, 1, 1, 0, 1, 1]

taps_noninverted_side = [1, 1, 1, 1, 0, 0, 1]

register = zeros(1,7)

register(1,1) = 1

# To access the item at row i and column j, just use the command  register(i, j)

# set up a loop

# !!!this needs to be made to work for arbitrary length input

i = [1:10]

for Clock_cycle = i

Clock_cycle

# !!!make this generic in the future. Gate the xors with the taps from above by using AND.

inverted_side = !xor(register(1,7),(xor(register(1,6),(xor(register(1,4),(xor(register(1,1),register(1,3))))))))

noninverted_side = xor(register(1,7),(xor(register(1,4),(xor(register(1,3),(xor(register(1,1),register(1,2))))))))

#print what is in our register

register

#advance values of register

register(1,7) = register(1,6)

register(1,6) = register(1,5)

register(1,5) = register(1,4)

register(1,4) = register(1,3)

register(1,3) = register(1,2)

register(1,2) = register(1,1)

register(1,1) = 0

endfor

Update from Defcon 18

Greetings from Las Vegas.

If you'd like to listen to the audio from a few talks that I've attended at DEFCON, then here are the links.

Moonbounce, by Matt Krick K3MK (closest thing to MEP so far)

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=xBdg9gnWT2z4

A request to hackers to collaborate with the Department of Defense.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=Pz91nFJvpvfH

A call to action from Dark Tangent concerning https: becoming the default experience for browsing the web.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=f1Tp9Cc0lXhd

Bytes and Bullets, an authors' panel. Authors have written books about cyberwarfare and share their perspectives on the issue.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=hqxcrT5RfDqG

I missed a talk about hacking FPGA bitstreams, but I'll try and track down the presenter tomorrow.

-Michelle W5NYV

FPGA for space applications

http://www.xilinx.com/products/virtex5qv/index.htm I've been keeping a lookout for components potentially useful for a digital satellite payload. What do you all think of this one?

NEON test code explorations

Hello everyone! Here's a bit of what's going on this week. 

We were looking again at dotproduct.c from the neon_test archive. This time, we were referring to it as a template for creating a version of dotproduct that takes 16-bit signed integer inputs and returns a 32-bit signed integer output. This is in order to port a demodulator Phil Karn is working on to ARM/NEON. This forced us to think more carefully aboutregister allocation, and we ran into a subtlety we didn't fully understand.

In the original dotproduct.c, half of the elements are multiply-accumulated into q8, and half into q9. Then at the end, q9 is added into q8. Like this:

...

vld1.32 {d0,d1,d2,d3}, [%1]!
vld1.32 {d4,d5,d6,d7}, [%2]!
vmla.f32 q8, q0, q2
vmla.f32 q9, q1, q3
bgt 1b
vadd.f32 q8, q8, q9
...

We thought, why not change this to accumulate directly into q8? This would be logically equivalent:

...

vld1.32 {d0,d1,d2,d3}, [%1]!
vld1.32 {d4,d5,d6,d7}, [%2]!
vmla.f32 q8, q0, q2
vmla.f32 q8, q1, q3
bgt 1b
# no vadd.f32 required
...

We ran this on the Beagleboard, and it does indeed get the same answer. But it's about 30% slower.

The two vmla instructions in the original code are independent in both inputs and outputs, whereas the two vmla instructions in our new version share the destination register q8. It would appear that the execution hardware in the processor on the Beagleboard is smart enough to do those two operations largely in parallel if the inputs and outputs are independent. That's very cool.

So, the questions are:

1. Is that the correct explanation of what's happening?

2. How were we supposed to know that such parallel execution was possible? Put another way, how can we find out whether the same is true of any other two operations, short of coding up multiple versions and trying them out?

3. There must be a limit on how many operations (such as vmla's) can proceed in parallel. I think there are enough registers available to do more in the dotproduct.c code, but the original code stopped at two. So I'm guessing the author was able to know that two was the maximum for parallel execution. Is this in the documentation somewhere or did the author have to run experiments?

Apologies to Philip Balister, who will get a slightly longer version of this email! 

We're making progress learning ARM and NEON code and enjoying ourselves in the process. 

-Michelle W5NYV, Paul KB5MU

Bit Error Rate Tester notes from today's strategy session

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=0kgpTq2CwW6x
-Michelle W5NYV

VHDL bit error rate tester update

A VHDL module was written today that implements a pseudrandom number generator (PRNG) with an external clock. This is another small step towards a bit error rate tester (BERT). KB5MU talked today about what a BERT looks like, and I learned that they come in pairs - there is a transmit side part of the tester, and a more complex receive side of the tester. It all made sense, and I will post a drawing of where we're going with the VHDL later tonight.

I made a quick summary of the website statistics for May, and am reading the documentation at Open Cores to see how to start a project.
 -Michelle W5NYV