EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: Mechatrommer on April 09, 2012, 01:21:38 am
-
for months i've been keep thinking from time to time what project should i do with my idling fpga and programmer in the the drawer. the problem is not how difficult to program/implement it yet, but the problem is i cant think of any useful stuff that i want/can to do with it, causing lack of motivation/enthusiasm. if i want to do more complex stuff, i dont have enough capacity/knowledge to do that. do i have a problem here? can anybody give some simple and usefull suggestion? or should i exercise the blinking led or "hello world" with fpga? thats pretty boooring :P
-
LOL. I'm kind of in the same boat. I bought a couple of highish-end CPLDs for something (I forget what for now) and now need to "put them to use." So I need to come up with a project that fits the bill.
I was thinking about a simple 'Pop-a-shot' type game but scale it down and use ping pong balls or something like that instead of basketballs.
Obviously, this is the sort of that could be done with a microcontroller but I already have the parts and need to do another VHDL project to keep from getting too rusty.
-
LCD Controller or something of that nature? Maybe for the PSP LCD display - there are plenty on ebay
-
i'm not into game stuff or the like. i mean something more usefull and practical for everyday use. lcd controller? it could be it, but i also have this arm dev with lcd lying around, hmm. thanks for idea 8.
edit: i think i'm more prone in data acquisition/generation, but not sure the mechanism is, maybe i'm just too weak in digital logic.
-
Did you buy a rubidium frequency standard? You could build a frequency counter.
-
Interface it with a fast ADC, and make a direct digital downconversion RF receiver. Software defined radio is a really interesting area these days, and FPGAs have the speed to do it.
-
Read a DVI signal (or maybe just the first x,x pixels).
The protocol is all documented and it can come in useful.
-
Did you buy a rubidium frequency standard? You could build a frequency counter.
I was thinking of that. A frequency counter sounds simple - just count the number of cycles in a second? Turns out that makes a really useless frequency counter.
Put 100Hz into your frequency counter driven by your recently calibrated 0.000000001% accurate rubidium standard reference and you get a result out of either 99 Hz, or 100 Hz or 101 Hz - only 1% accuracy.
The way all modern frequency counters work is they have a gate time that you can set to 0.1 secs, 1 secs, 10 secs, etc. The counter then has to measure the total period of as many cycles as possible that will fit within the gate period. It returns the total period, and the number of cycles, and from this, frequency and period is calculated. This way, you get the best possible resolution regardless of frequency. Getting the logic right is not a bad project.
It is the kind of project you could do in steps.
If your FPGA is one of the bigger ones with Phase Locked Loop libraries available, you could turn the 10MHz reference frequency in into 100MHz for an extra order of magnitude.
If you want to read more on this, see the HP Journal article on the HP 5315A timer/counter:
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1979-01.pdf (http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1979-01.pdf)
In fact, the HP journals have some brilliant articles explaining their new ideas. They are all online, they are interesting to read (except when they start talking about their computer designs) and you could find some inspirations for a design.
Richard.
Edit: I better add this link to to the HP 5345A counter - the first to use reciprocals:
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf (http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf)
-
Thanks for the links, Richard. I'll have to check them out.
-
Did you buy a rubidium frequency standard? You could build a frequency counter.
no its getting expensive after dave made the review. but i think that high precision isnt necessary for now. i'm thinking just getting any cheapo oscillator and try to make the programming right. when finalized, its just a matter of changing the freq reference to make it "precision device". the Richard's idea about multiplying clock seems interesting, i guess thats how rigol interleaved their adcs to get 1GSps out of 4x150MSps adc. but all, thanks for idea guys, keep it coming.
-
Reciprocal counting is the way to go. It makes possible to make low-frequency frequency measurements (like 1 kHz or below) with a good resolution without waiting for ages. But of course, it comes with the price: you'll need a divider to calculate the actual frequency.
I have been doing a major overhaul of my ICM7226 (now obsolete) based frequency counter, replacing it with a FPGA-based design. That indeed uses reciprocal counting and is really improvement for the mentioned reason. Integrated FPGA PLL is really handy to boost internal clock frequency. My target is 200 MHz internal clock, it might be just realizable, we'll see. Just the part which counts the actual gate length needs that frequency, other parts can run much slower.
Counter VHDL design has been ready for a while and I have tested on separate board that it works, I just need to design a better front-end and a PCB which fits to existing mechanics. For your interest, current design uses slightly less than 1500 LE's (Altera Cyclone III).
Perhaps the divider was the most complex part to get right (that means it took me a while to understand the algorithm :-[ from some university slides), another thing is that you have several clock domains. Synchronizing between those requires some care. Of course the divider would be much easier to implement in a MCU, but what fun is that :) Or actually, I have two dividers, first one to calculate the frequency up to Hz resolution, and then second one which calculates fractional digits based on the remainder of the first divider. Remainder is multiplied (multiply operation is cheap thanks to integrated multipliers) by 10e6 to resolve the decimal digits. Then I convert resulting binary values into BCD.
Regards,
Janne
-
I will have another go posting this reply - this time in the right thread.
If you intend on using FPGA's with a micro, the very first thing I would do is sort out a good general interface on the FPGA for the micro.
You probably want a serial interface like I2C, or it can even be a very basic custom interface.
You want to have configuration and data registers on the FPGA that are read/write to and from the micro. All these registers have to be addressable, so you need to add the addressing to your serial protocol. You want to be able to take an interrupt signal from the FPGA and send it into an interrupt pin on the micro. The reason why you want configuration registers readable is it means the micro does not have to remember the state of the FPGA. It can just read in the current state, flip a bit or two and write it back.
Even if you don't think your projects will need things like configuration registers, you probably will. You will almost certainly find you can add extra useful functionality with just a simple switch (a bit in a register) and some simple logic. You might want to add debug and diagnostic features. You might want calibration data.
On the micro, you probably want to develop a solid routine for accessing the FPGA. For example, say a program is in the middle of talking to the FPGA and an interrupt occurs that also wants to talk to the FPGA. How do you stop the FPGA getting confused? A single routine that handles all the communication may be able to ensure that things happen properly.
It may even be that there are libraries available that can do this, but that does not matter. The thing is that you want to get this sorted first, so when you get to a real design, then interface is trivial and it is already fully working. You know how to add an indefinite amount of registers. Initially you would just do very simple things with the interface, like linking data registers to FPGA pins so you can get working input and outputs controlled by the micro.
If you don't develop some building blocks like this, then when you start a design, it can feel overwhelming, and you can spend days trying to debug your functional logic when all the time the fault is just in the communications with the micro.
If you end up using the same interface with different FPGA projects, it makes it easy to combine them into a single design later.
There are of course FPGA projects that need full parallel data busses, but you can do a lot with just a serial interface.
It may seem an unexciting project, but the thing is it takes you from a point where it all seems overwhelming and just too hard, to a point where you can start adding real functionality with just one extra design step. And as I mentioned before, the moment you start adding functionality, the micro is already fully talking to the FPGA from the moment you start.
In case this all sounds like something very complex, I have done this on chips with a few hundred macrocells. You can start with one data register and one configuration register, as long as you know how to add extra when you need it.
Richard.
-
It may seem an unexciting project
yes it may sound uninteresting and nonfunctional, but i fully appreciate/know what you are talking about. this is building a general library that can be reused over and over. the first time is yes overwhelming, but later when doing another 2 or 10 projects using the same library, it will save alot of time, and we can keep building complex projects over and over with little effort. i will keep in mind of this, but...
In case this all sounds like something very complex
for a person like me... yes its very complex, if its in a fpga :( i need to "fpga for dummies" first... we'll see.
-
Maybe you'll like this site: http://www.fpga4fun.com/ (http://www.fpga4fun.com/)
-
for low incoming frequencies: use the incoming signal as the gate ... and count the number of ticks you get from the reference oscillator... ( as opposed as counting number of ticks from the input signal using a fixed gate time )
-
Sometimes when you are learning things, you cant think what is usefull but what can you do...
Start out with just making a simple logic expression A+B(C'+D) or something like that... use switches to control the inputs and an LED to view the output.
Next expand into a counter, press a button, it counts up, add a clear, interface with a 7 segment, use more than one 7-segment if desired.
Now take that counter and give it a clock, add a start and stop button. you now have a stop watch.
Create a data logger of times, when you hit stop it sends the time to a computer (UART-RS232) running HyperTerminal (or some flavor thereof)
now have the computer send data to the FPGA, make a PWM generator that works with UART, send it a frequency and a duty cycle or a pulse width and let it go to town.
use something other than UART like SPI.
This is more or less the path I took.
-
Another way to make a precise counter is by creating a dds. Use a binary search algorithm to tune the dds frequency so it matches the incoming frequency.
You start the dds cycle on rising edge and use a phase comparator to detect the next rising edge. Early ? Frequency binary step down... Late ? Frequency step up. For a 28 bit control word it would take 28 periods of the incoming signal to lock.
And 28 bits is a lot ...
Making a dds in an fpga is easy. An accumulator and a register is all you need. And since fpga's can run fast internally ...
-
@Tony: thanks for that advice. maybe it will be my path as well. since "fpga i dont get it", maybe as well i should open up some "combinational logic" book :P because i'm really poor at it.
-
maybe as well i should open up some "combinational logic" book :P because i'm really poor at it.
Digilent has some books on FPGA design. Here's one that they offer for free: http://www.digilentinc.com/classroom/realdigital/ (http://www.digilentinc.com/classroom/realdigital/)