Odd behavior Spartan3E 500k on Nexys2

[tompoh]

Greetings.

I have designed logic circuitry that has 12 channels with 12 square wave signals at some arbitrary user defined frequency through frequency division by means of a counter and extra circuitry. These 12 frequency division units are connected to the same clock. I implemented this circuit on the old Nexys boards and it works fine with no problem. I have had to purchase a nexys2 on which I have implemented the same design. Strangley on the Nexys2 I get odd results, sometimes the output frequency on one to three channels being twice, three times and even half the expected frequency while being ok on the rest of the channels (The channels have identical circuitry ). If I implement the design with different constraints the problem shifts to different channels. I do not understand what is happening and to be honest, it does not make much sense.

Does anyone have some ideas.

 

[permute]

1.) you aren't using a UCF file.
2.) you have a UCF file, but it's not included in the project.
3.) you have a UCF, but have used "TNM" instead of "TNM_NET". one pushes through the input buffer, the other doesn't.
4.) you have mixed case in the UCF, but not in the HDL. While VHDL is not case sensitive, the UCF file is a bit more tricky.
5.) your HDL has counter logic that has async inputs that are used. Such logic can always fail, but can fail always in some implementations. This is particularly true when the user uses fabric resources to derive other clocks.
6.) the pads are not defined in the UCF.

keep in mind that digilent has horrible reference designs (in general). If you've used their code as a reference, you might just be seeing the effects.

 

[tompoh]

1.) you aren't using a UCF file.
2.) you have a UCF file, but it's not included in the project.
3.) you have a UCF, but have used "TNM" instead of "TNM_NET". one pushes through the input buffer, the other doesn't.
4.) you have mixed case in the UCF, but not in the HDL. While VHDL is not case sensitive, the UCF file is a bit more tricky.
5.) your HDL has counter logic that has async inputs that are used. Such logic can always fail, but can fail always in some implementations. This is particularly true when the user uses fabric resources to derive other clocks.
6.) the pads are not defined in the UCF.

keep in mind that digilent has horrible reference designs (in general). If you've used their code as a reference, you might just be seeing the effects.

The UCF file was defined automatically using xilinx user constraints editors, and it is included in the project hence I do not think 1, 2, 3, 4, and 6 are applicable in my case. I have changed the logic definition so that I do not have any async inputs but I am still getting the same problem. The design can be described as follows:

** clock into counter.
** counter value in to comparator. ( 'equal' is an output pin asserted when counter value is equal to value stored in latch)
** comparator 'equal' output into counter synchronous reset.
** comparator 'equal' output is also output signal at twice the desired frequency
** comparator 'equal' output into toggle flip flop to give 50% duty cycle signal at desired frequency

 

[permute]

That seems simple enough. I'd still double check all of the UCF related issues. You seem to place a lot of emphasis on ISE to "do the right thing". I guess the last thing to do is to confirm that timing analysis was done successfully. The reports will list if a constraint has been renamed/removed. the PAR and TWR reports are good choices.