Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

12 bit counter won't scale up to more bits

Status
Not open for further replies.

GarryM

Newbie level 4
Joined
May 31, 2016
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
64
(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.

For the record, it looks like this:

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;



The ABEL code contains this little nugget up at the top:
Code:
@CARRY 0;
the use of which I don't recall, but I have dim memories of having to experiment with different values to get it to work.
Is there some trick I need to learn to use in making larger counters?
 
Last edited by a moderator:

FPGA synthesis tools have timing analysis to check if a design is able to run at the intended clock frequency and usually also implement timing driven synthesis to tune the design for maximum speed if required. So the first step would be to write suitable timing constraints and determine the achievable counter speed.

Not knowing the used CPLD, its logic core topology and timing specification, it's hard to decide if 14 bit counting is already too much. Recent programmable logic devices can implement considerably wider counters at 50 MHz.

The code snippet doesn't show how rFlagEv is generated. Hopefully synchronous to iClk? But if it involves a large combinational delay, it could still cause problems. In case of doubt, it should be registered before being used as count enable.
 

Thanks for the quick reply.
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.
rFlagEv is synchronous, set by the rising edge of iClk, and cleared on the next rising edge. It is a simple AND of 3 input bits.

The big puzzlement to me, is that the exact same board works with the old jedec file, so it's hard to blame the hardware. But that may be a distraction.

It's not clear to me how to set constraints on the counter itself, if they are needed. For instance, I know a ripple-carry counter is slower than a look-ahead synchronous counter, but can't find any reference that tells how to specify one or the other.
 

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.
 

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.

This doesn't match...17 ns is 58.8 MHz not 54 MHz so does timing pass for the 17 ns clock period or an 18.5 ns clock period?

- - - Updated - - -

I haven't worked with the CPLDs in ISE...does ISE produce an output that shows what product terms were used to implement the design. Perhaps by looking at that it can be determined if the implementation was done correctly. That part should be able to produce a 14 bit counter without any issue.

- - - Updated - - -

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.
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.

So you've verified the equations for bit-12 and bit-13 are inverted based on the previous 12-bits and 13-bits respectively? If so your observations on the hardware are very strange. You say the original file works, as a 14-bit counter or as a 12-bit one? It's not clear from your posts as you discuss scaling up the counter. If the original file was a 12-bit counter, perhaps you should first attempt to create a 12-bit VHDL version and make sure that works first. Can you create a 14-bit counter in the original ABEL syntax?
 

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.
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?
 

(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.
- 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?
- You should try simulating the entire design. Once over the initial hurdle of simulating anything, it's much easier to debug in sim than it is in real hardware.
- Since you haven't posted the entire design, it's quite possible that there is nothing in the unseen logic that depends on the two new upper bits in which case those two bits will be optimized out since they are not needed.

Kevin Jennings
 

After more testing with the older jedec file, I find that while it appears to work at first, if I look long enough I can see that all is not well. Built a new board and both designs work. So it was a HW problem after all. Best guess, the Xilinx chip is damaged internally, but that's another day.

Thank you all for putting your minds to this. Sometimes just telling your troubles to another is the key to solving them.
 

Awsome, I was wondering along with others if the board or CPLD were damaged somehow.

Maybe there is a short on the output pins for bit 12 and 13, if an output driver of the CPLD has stronger drive for a low signal than a high output you would see 0x0000 - 0x0FFF 3 times and only on 0x3000 - 0x3FFF would you see 1's on bits 12 and 13.
 

Maybe there is a short on the output pins for bit 12 and 13
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.
 

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.
 

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.

Well there is always ESD damage of the part itself, which can be anything from catastrophic failure to a "it seems to be okay" latent failure.
 

Part has been swapped out; problem solved.
We have built & shipped over 200 of these modules since 2006. I have never seen a failure like this. How is it that the one faulty unit ever built is the one I use to test my new code? There is a lesson in there somewhere. Thanks again to all.
 

There is a lesson in there somewhere.
Not a lesson, it's a LAW...Murphy's!

- - - Updated - - -

If you have the budget, I would suggest having a failure analysis done on the part (though with only 200 units over 10 years maybe not) to see if it was a one off defective part or if there was some systemic issue in the handling of the part (ESD). That might be something you want to know as there may be other latent defects fielded now.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top