Well, my thesis has about 74 pages and is constantly being revised. I am on my 3rd revision. As I write, and reflect on what I know, it seems as if I could do all the work I had previously done in 1 week. I guess that means I really know what I did.

I have to defend in 2 weeks from this day. The date and time are at 3:00 PM on April 20th. In the meantime the final contents of my thesis must be agreed upon by my advisor. Also, I must prepare a 45 minute presentation of the material to present to the thesis committee. This is a ton of work, and during that same 2 week span I will have completed one take home exam, a radar homework, an electromagnetic scattering hw, and put a lot of work into 2 term papers, on top of all the other stuff I have going on at home. Do I feel overwhelmed? Yes of course. When this semester ends I am going to look back and really be proud of myself.

Well, I really worked my tail off the last two weeks and actually built an ENTIRE receiver on another chip, built debugged, and modified two PCB boards. FPGA development is not something that takes minutes to do small things, it literally takes hours. I was almost entirely finished with the process until I had an impasse with the Altera FPGA and can conclude there is really no way I can get that board to work (access to the PLL’s must be through dedicated clock pins). As for the other board I worked so long on, it has a large problem with the Asynchronous FIFO. Asynchronous FIFO’s are very complex and are hard to get working.
As unfortunate and unsatisfying as it must sound, I must finish writing my thesis and move on. I put in so much hard work on the receiver, I am truly amazed at myself. At some points I really had to give ALL the strength I had to continue, and I pushed on. The project never reached full satisfaction, but I learned so much. I don’t even have a bitter taste in my mouth when I hear the words “digital receiver.” I truly gave it everything I had, and I am proud of myself and what I accomplished. I am so grateful to have had the opportunity to work on a thesis. It was a great experience, I am truly humbled.

I have been putting off updating this blog since I have been so busy. But I accidentally clicked on the bookmark I have for the page and felt I should at least post something.

As for the thesis, I have been making amazing progress after switching boards. I bailed on the board I had put so much hard work into, and got a board with an Altera Cyclone to work. It still doesn’t sit too well in my stomach that it works with the Cyclone but not with the Spartan, its a huge mystery still. Here are some quick updates.

I have to submit my thesis to my advisor by March 20th.
I will most likely be defending my thesis on April 16th.

Those dates are coming up extremely fast. I will try to post more of what I have been doing. So far it has been working 12 hour days, and picking up hours on the weekend. This lifestyle does not leave me a lot of extra time for blog posting. But I do keep in mind one thing. I absolutely love working on this receiver, its a blast.

Well I am meeting with my boss tomorrow to present why this thing has not been working for so long. Upon, researching and scrambling, and cramming to get this thing to work, I have realized huge thing: ITS NOT MY FAULT. I can honestly say everything I do is correct! There is something inherently wrong with the USB interface. This I can now conclude: When data is streaming the FX2 tranceiver crashes! I have it configured as it should be, so no firmware intervention is needed and … it crashes. Workarounds are the only way around this. Fixing the device when it crashes, monitoring for crashes, and so forth. I will let you guys know how the meeting goes and all the conclusions from it. Until then, take care.

Well I figured out how to use the logic analyzer in state mode and I have some results.

This was already known but “sometimes” the logic writes on one extra clock cycle even when the full flag is high. This will definitely cause a problem.

I seem to have a problem no matter what I do when I have the FPGA fill the FX2 buffer almost full. How I thought the system works is when the FIFO gets over 512 it will arm the packet. Which will enable the host computer to read the packet. When I fill the buffer not completely full, for example say I fill it with 1050 bytes, that will be 2 packets plus change. However, when I examine the stream after it has crashed I see there are a bunch of packets that never get armed! I have no idea why this would be.

Well, I have a logic analyzer and am working on getting it setup so I can do some heavy duty debugging. I did see some something strange upon setup. That is the main clock duty cycle seems to change quite drastically. Don’t know if the triggering level is right or not, but it just seems to loook weird. The duty cycle of the clock is perfect when viewing from the scope. I need to get a manual for this fossile of a logic analyzer I have to figure out how to program state logic.

To debug this logic I need to set up states and when the Empty or Write Enable goes high begin counting the number of clocks. I hope to see a trace with 1025 clocks instead of the 1024 the device is programmed to do. Then I will have isolated the bug.

Currently the FPGA fills the FX2 when it becomes empty. When the FX2 indicates it is empty it will fill its entire endpoint. Sometimes it just so happens that FPGA fills the FX2 on one extra cycle, thus 2 extra bytes get written. That is a brief summary of the current problem.

Today I tried 3 different things which have been tried before but thought I would try them again and see what would happen now that I got the new board.

1.) Fill the FX2 with a word when it is not full at full rate 48MHz.
-This streams data at 30MB/s, no errors in the data stream.
-Bit errors are found in the data.
-This cannot work since the data rate is at 48MHz.

2.) Fill the FX2 with a word when it is not full and the difference between the read and write pointer is 16.
- Sometimes the buffer will read 0 packets committed and 1026 bytes in the buffer. Two extra were filled. This breaks the data stream.

3.) Fill the FX2 when a programmable full flag is set. This programmable flag is set to go high when the amount of data in the buffer is 2 packets plus 50 bytes. For some reason the packets do not auto arm and I will see 512*2 + 50 = 1024 + 50 = 1074 bytes in the buffer. I will also see the buffer go from 2 packets and 50 bytes to 2 packets plus 52 bytes. Sigh.

I ALWAYS have a problem because the FX2 gets written “sometimes” with 2 extra bytes.

I NEED a logic analyzer.

As long as the bandwidth on the USB bus does not exceed 480Mb/s you can add as many of them to the USB bus (in theory). I beleive I will put this theory to the test since now I have two ZestSC1 boards.

The new ZestSC1 can also replicate the anomaly. This is bad news. The anomaly changes quite frequently. I tranferred 1GB of data nearly 3 times in a row without error. This is so frustrating.

The current board PASSES the self test program. However, it only transfers 1MB to and from the device. I would claim this is too small of a transfer size because I can transfer 1MB worth of data nearly flawlessly.