After working with the grad students in the wit lab for a few weeks, I became bored of how stuff failed to work. I felt like I was spending a lot of time on this project but not getting any real work done.
I got fed up with waiting and took matters into my ow hands. I came to this wit lab because I wanted to contribute my VHDL and FPGA knowledge. So I asked the professor G chen Who was working on the VHDL stuff. At the time there was no one working on it.
He knew that I desired to work on an FPGA project. so he told me to make a "special counter". The idea seemed simple enough. count a few signals and TADA! magic.....I wasn't sure what was so special about the counter so I pressed for details as to what this was. Was there a state machine to describe this? Was there some documentation? He pointed to a box with knobs on it. It looked like a VCR except it wasn't. This machine was the special counter that professor wanted. What bothered him was that the counter wasn't customizable enough, so he wanted an fpga implementation of it to have more control.
The only problem was I had no idea how to start.
I needed some advice from someone more knowledgeable them me. Professor Vahid probably knew what to do. As I explained the problem to him, I began to answer my own question. Seems to be a habit of mine to ask questions I have at least ONE answer to.
The problem was balancing what the professor wanted verses what the actual machine does. It confused me as to what this machine is suppose to do and I wasn't sure how the professor wanted to customize it. I asked, but no details surfaced.
"as a base.....start with something you do know how to make. make it similar to the machine on your professors desk. Ask him if thats want he wanted and if he says no, then you can make changes to accommodate" said Vahid.
It was what I needed to hear. I was trying to swallow the entire meal instead of taking it one bite at a time. What professor G chen wanted was a mystery so what I had to do was make something that wasn't a mystery.
Mistakes were made in the process of creating this device. I wasn't sure what it was suppose to do. My first assumption was that a transmitter would shoot out a trigger signal to the receiver and then after a short delay it would send a byte of information to the receiver.
I made a bunch of fancy state machines which took a LOT of time to create and conceptualize. only to realize that it wasn't what the professor wanted. Its not as bad as it sounds cause I was close. Instead of sending a byte of information, he actually wanted a "rising edge" counter.
*face palm* that would have saved me soooooo much time and effort..... if I did a rising edge counter, instead of what I was TRYing to do then I would have been done a week earlier.
I made some modifications such that the number of rising edges would show up on the seven segment led screen on my spartan 6. The numbers showed up obviously, but they were inconsistent. I used a wave form generator as input to my device and my device would count the rising edges it would get.
why was the numbers in consistent? was my spartan board too slow? was it my programming?
I attempted to simplify my design and the error eventually shrank, but it wasn't good enough for me. I wanted 99.99% accuracy.
I anazlyed the test bench results again and again and noticed a ridicules amount of delay. This delay may have been responsible for over counting or under counting.
It must have had to do with the nested state machines I was using. My last card was to get down and dirty with low level implementation. Gates.
I went ahead and made my own adder and register and all the parts needed to make my counter come to life. The amount of code for this ended up being WAY smaller then my previous implementation with state machines. I even paid attention to what RTL design xilinx was generating for my code. if I had used a state machine it would have been a huge mess. But since I was making everything, it would be much easier to read and I was have certain expectations as to what SHOULD be there. If a latch formed and a combinatorial loop formed, I knew there was a problem in my design.
Doing it in the low level really really really paid off. I had no errors and there was hardly any delay. If there was a delay, it was all expected. Seeing as how my device runs at 100 mhz, a delay of one cycle probably wouldn't matter much especially when my input device wasn't going to be any faster than 10khz.
I was able to create a generic mux that used one hot encoding in its select line.
a decoder was made to translate binary number into their hexadecimal equivalent.
I made a counter that would count from zero to 9 and then would over flow.
There are only two things left for me to do. I need to add another register between the four digit decimal counter and the interface to the seven segment. while the counter counts, it will need to be saved somewhere and that register is where it will need to be saved.
A state machine would need to be made (either literally or figuratively) to control when the counter would count , pause or reset. it would need to control the register like when it would receive the new value. shouldn't bee much longer before i am complete.
One thing that would could also do is to make a clock divider in the way that gang specified.
one input has the clock and it would have several outputs. the first would be
clock/256 then
clock/256/256 then
clock/256/256/256 and so one.
You want your AN sm to rotate slowly rather then as fast a possible. It probably doesn't matter that much but for some reason I'm concerned with using too much power.
