Electronic – FPGA input synchronisation

The Xilinx tools can't interface in real-time as far as I know, neither can ModelSim (used by Actel's Libero IDE)
I don't know about open source simulators, there are some rather exotic projects out there so it's possible there is something that could do this.

However, this may be you an answer you didn't ask for (I'll delete it if it's not helpful), but I would consider building your own FPGA board to do this or at least get started along the way towards it. I etched my first FPGA board and though it was very simple (the board not the process ;-) ), it taught me an awful lot quite quickly.

Pros:

• Cheap
• Jump right in at the deep end and learn all you need to know about the hardware considerations. Forces you to read most of the datasheets first, and write your own starter code, which IMHO is often better than the plug and play dev board approach to learning.
• Only put on the board what you need to.
• Get's you further towards your goal of a real working design with possibly the same effort/research as the figuring out how to simulate it all in real-time would.

Cons:

• Still need to buy a programmer, although cheap versions of the Xilinx/Altera programmers can be found on eBay.
• If PCB/signal integrity design and issues are not something you wish to focus on, then you may not be interested in much of the knowledge to be gained by doing it this way.

I understand the etching your own board is probably unnecessary, I only did it because I had the FPGAs there, was impatient and didn't want to wait 2 weeks for a PCB to arrive. There are extremely cheap deals out here for 2-layer boards, which would do to at least run your design (possibly at lower speeds than eventually desired - normally the minimum layer count for a high-speed FPGA design would be 4, but these are much more expensive)

Anyway, Spirit Circuits does a completely free 2-layer "bare bones" PCB deal (one a month, one design, no mask or silkscreen) which comes in handy for a one off design.
Also, for proper 2 and 4 layer cheap prototype boards, ITead and Seed Studio go as low as $10 for 10 boards (or possibly 5 at that price) services.

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);