Code VHDL - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; iClk : in STD_LOGIC; --input clock, constant 50 MHz signal rFlagEv : std_logic; --a decoded bit signal rFrame : std_logic_vector(13 downto 0); --the weird counter -- elsewhere in the code, rFlagEv is set when I want to count the event. It is hi for exactly one clock cycle. framecount : process (iClk) begin if rising_edge(iClk) then if (rFlagEv = '1') then rFrame <= rFrame + 1; else rFrame <= rFrame; end if; end if; end process framecount;
@CARRY 0;
The part is xc95144xl-tq100-10.
The timing constraint in the ucf file is TIMESPEC TS_iClk = PERIOD "iClk" 17 ns HIGH 50%
The timing report generated by ISE shows no paths failing at a clock rate up to 54 MHz.
Well due to the macrocell structure it's not a ripple counter, each bit of the counter would depend on the FF output of the lower order bits...this isn't a ripple counter. A ripple counter would cause the update of each bit without the action of a clock, as it's a combinational path from the LSB to the MSB. What you have is a synchronous counter without any carry look ahead.Sorry for the confusion; in the course of debugging I have tried a lot of different things and some of my notes are of the pass/fail type.
54 MHz is my design target, 50 MHz is the actual operating frequency.
17 nS was the design constraint when I wrote the above, but it checks only up to 56.5 MHz, which is fine. I now have the timespec at 17.7 but of course no change in behavior for all that.
The equations show that each bit of the counter is the AND of all the lesser bits, so that implies to me that it is a simple ripple counter.
Clarifies that the counter is counting correct internally, but you don't see bit 12 and 13 unless both are one. That's unlikely to happen by logic operation, more likely it's some kind of hardware problem. How do you monitor the counter output?It will count from 0x0000 to 0x0FFF three times, then jump to 0x3000, and go from there to 0x3FFF and on to 0x0000. It's as if bit 12 is stuck to bit 13.
- Since rFrame is defined as an internal signal rather than as an output how are you monitoring these bits that you say are not working?(My first post, hello!)
I have a product using a Xilinx CPLD that successfully runs code I wrote in ABEL some years ago. I am trying to port this over to VHDL. One little section of the code is a 14-bit counter. In my VHDL version, it counts successfully up to 12 bits, then goes nuts. It will count from 0x0000 to 0x0FFF three times, then jump to 0x3000, and go from there to 0x3FFF and on to 0x0000. It's as if bit 12 is stuck to bit 13. I suspect that a carry bit is not getting through.
Yes, more likely an external short than internal damage, e.g. a trivial solder short of adjacent pins. Asymmetrical drive strength of outputs works like wired OR.Maybe there is a short on the output pins for bit 12 and 13
Ah, I wish it were that easy. The pins aren't adjacent. The microscope and ohm-meter reveal nothing. The main thing is that I can be confident in my vhdl code. Now when I want to add features I don't have to boot up the Win95 box that has the ABEL compiler on it.
Not a lesson, it's a LAW...Murphy's!There is a lesson in there somewhere.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?