If you are about equally at home with an FPGA or a microcontroller for development purposes, a microcontroller will cost less in small quantities.
The lowest cost FPGA listed at DIGIKEY in 1,000 quantity is $US2.85/1000.
Digikey have a microcontroller part which would do this task for about $US0.30. This is an "outlier" and you would usually expect to pay $US0.50 - $1.00 in 1000 quantity. For $US0.68/1000 you get this ST offering - STM8S103xx with UART, SPI, IIC, 5 x 10 bit ADC, multiple timers and 28 I/O lines.
When it comes to doing "bits and pieces" around your core design a microcontroller is going to be substantially more flexible and take less time, unless you are an FPGA guru.
Assembly wise both FPGA and microcontroller are similar. In most cases you will need external driver ICs or discrete components to drive higher current loads - which probably includes your 7 segment display if it is LED (and not if it is LCD).
What you want to do is called a Numerically Controlled "Oscillator", or NCO. It works like this...
Create a counter that can increment by values other than 1. The inputs to this counter are the master clock, and a value to count by (din). For each clock edge, count <= count + din. The number of bits in din is the same as the number of bits in the counter. The actual count value can be used for many useful things, but what you want to do is super simple.
You want to detect every time the counter rolls over, and output a pulse to your motor when that happens. Do this by taking the most significant bit of the counter and running it through a single flip-flop to delay it by one clock. Now you have two signals that I'll call MSB, and MSB_Previous. You know if the counter has rolled over because MSB=0 and MSB_Prev=1. When that condition is true, send a pulse to the motor.
To set the pulse frequency, the formula is this: pulse_rate = main_clk_freq * inc_value/2^n_bits
Where inc_value is the value that the counter is being incremented by and n_bits is the number of bits in the counter.
An important thing to note is that adding bits to the counter does not change the range of the output frequency-- that is always 0 Hz to half of main_clk_freq. But it does change the accuracy that you can generate the desired frequency. Odds are high that you won't need 32-bits for this counter, and that maybe just 10 to 16 bits will be enough.
This method of generating pulses is nice because it is super easy, the logic is small and fast, and it can often generate frequencies more accurately and with better flexibility than the type of counter+comparator design that you have in your question.
The reason why the logic is smaller is not only because you can get by with a smaller counter, but you do not have to compare the entire output of the counter. You only need the top bit. Also, comparing two large numbers in an FPGA usually requires a lot of LUTs. Comparing two 32-bit numbers would require 21 4-Input LUTs and 3 logic levels, where as the NCO design requires 1 LUT, 2 Flip-Flops, and only 1 logic level. (I'm ignoring the counter, since it is basically the same for both designs.) The NCO approach is much smaller, much faster, much simpler, and yields better results.
Update: An alternative approach to making the rollover detector is to simply send out the MSB of the counter to the motor. If you do this, the signal going to the motor will always be a 50/50 duty cycle. Choosing the best approach depends on what kind of pulse your motor needs.
Update: Here is a VHDL code snippet for doing the NCO.
signal count :std_logic_vector (15 downto 0) := (others=>'0);
signal inc :std_logic_vector (15 downto 0) := (others=>'0);
signal pulse :std_logic := '0';
. . .
process (clk)
begin
if rising_edge(clk) then
count <= count + inc;
end if;
end process;
pulse <= count(count'high);
Best Answer
Developing an FPGA is a knowledge based skill. There's a delicate balance between abstraction and understanding, and the reason tutorials tend to be so long is based on the least common denominator for understanding by their audience. No one teaches the process in abstract before 'practical' experience because of some ingrained believe system people have that because tools are GUI based they should be intuitive. The Xilinx development process may be complex enough to belie that belief. Hence you get repetition for rote learning.
To demonstrate you're unlikely to be fulfilled by 'short' tutorials see Command Line Tools User Guide (Formerly the Development System Reference Guide) which is 411 pages long (PDF, 4.9 MB). Chapter 2., Design Flow, is 17 pages long and the numerous flow diagrams it contain are detailed enough you need to zoom in on them.
Try googling with command line based Xilinx FPGA development as search terms. You'll find all sorts of interesting references, threads and the occasional tutorial. You could also note that Xilinx tutorials serve two purposes, both as a map to provide inculcation in their prescribed methodology using their graphics user interface centric tools but also to promote new silicon features and their applications.
Some of the short tutorials you'll find through the search might be Verilog instead of VHDL based, but the only place you'll really find a distinction in the process is in XST (Xilinx Synthesis Technology, the synthesizers), where there are distinctions in modeling language feature support.
There are several threads on the use of Makefiles which enforce a knowledge framework on tool process.
It's likely useful to have on-line access to Xilinx Help (ISE Help) although you'd likely find information faster with Google Search than trying to parse the Help tree or search through Xilinx Documentation.
And as you can see by reading various threads on the subject you're not alone in wanting to learn the actual methodology instead of being inculcated in how cute their tools are or what features they are promoting 'now'. (Tutorials tend to have a short half life).
There's a 32 page tutorial (tutorial.pdf) for a 0-9 seven segment display counter on a fairly modern Spartan-3 FPGA board. From this and the other answer to your question you might get the idea that tutorials are generally target platform specific.
Those found at institutes of higher learning (e.g. FPGA_Design_Flow_Xilinx.pdf, 10.8 MB, GUI oriented, Xilinx tool version specific) also serve to reinforced the idea of platform targets (as well as tutorial half life).
You might expect a tutorial example to be made available for a specific platform target, e.g. Xilinx ISE and Spartan-3 Tutorial or Lab 9 – Tutorial. You'd also note some tutorials are based on incrementally acquiring skills through a series of labs in a particular course.