Counting Number of Set Bits / TMDS / DVI on FPGA - Page 1
Forum section: electronics / beginners

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 05:10:56 am
content: I wanted to figure out how many bits were set in an 8 bit number. If you haven't guessed, this is for a TMDS encoder for DVI/HDMI.Just looking for tips/advice to see if I'm doing this all right. In the boxes is the logic itself (each stage determines a bit value for the number of 'set' bits), below is TMDS specific logic for deciding whether or not to use XOR or XNOR.This is meant for an FPGA by the way.-Brandon

author: joelby
author_rank: Frequent Contributor
timestamp: April 11, 2012, 05:52:18 am
content: For 8-bit values, you may be better off just using block RAM as a look up table. I would test both approaches and see which achieves timing, though BRAM would probably be simpler to implement and faster than combinatorial logic.

author: graynomad
author_rank: Regular Contributor
timestamp: April 11, 2012, 06:37:07 am
content: QuoteThank goodness for that.If you have some RAM why not just to a lookup table?EDIT: Oops, joelby beat me to it, that'll teach me to have dinner after loading the post and before responding______Rob

author: cybergibbons
author_rank: Frequent Contributor
timestamp: April 11, 2012, 06:54:24 am
content: I'd also say use RAM. It's such a small amount of RAM that distributed RAM would do the trick. With combinatorial logic, it's easy to make mistakes and miss timing requirements.

author: slateraptor
author_rank: Frequent Contributor
timestamp: April 11, 2012, 04:07:50 pm
content: If the guaranteed 1-cycle penalty incurred by using an instantiated ROM LUT isn't a big deal, I'd go that route, as everyone else has suggested.What FPGA do you intend to use btw?

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 04:35:09 pm
content: I'm using a Cyclone IV. I haven't looked into working with the built in block RAM yet, but I probably will end up using it. However I think it would be tough for it to address memory, and then clock it out, faster than my circuit would react. But I really have no clue. It sounds like something fun to do benchmarking on.-Brandon

author: olsenn
author_rank: Frequent Contributor
timestamp: April 11, 2012, 04:40:46 pm
content: My Verilog is rusty, so forgive me if this makes no sense, but what about:module countBits(number[7:0])reg count;initialbegincount < 0;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;if(number == 1) count <= count + 1;endendmodule

author: olsenn
author_rank: Frequent Contributor
timestamp: April 11, 2012, 04:42:15 pm
content: ...and of course you'd have to output the count register to whichever module needs it

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 04:51:24 pm
content: Can't check your Verilog... as I've barely played with HDLs yet.However, wouldn't adding each of the 8 bits to a counter take eight 4-bit full adders? 0-8 takes 4-bits to represent, and 8 add operations are done (unless you have a clock and run in O(n)... but I want O(1) [do those terms even apply here?]). And 8 4-bit full adders would take up a lot more space on the chip. However, at least we would know that your code will work properly (if syntax is in order). I haven't tested mine... it will be a pain to debug if it doesn't work, but I think it *should* just fine (famous last words).-Brandon

author: free_electron
author_rank: Super Contributor
timestamp: April 11, 2012, 04:52:05 pm
content: If time is not an issue i use this trick :n-bit shift register. output of shift register drives enable pin on a counter.step1 : reset counter and load shift register.step 2 : apply n clockpulses. the latched data shifts out and controls the ENABLE pin of the counter. if the bit is 1 the counter is allowed to increment. if the bit is zero the counter does not increment.step 3: at 'n'th clockpulse : copy the counter in an output register.This thing is scalable. and requires very little resources. ( especially as the number of bits increases. for every extra bit you need only one extra flipflop in the input latch. and for every additional power of 2 you need an additional flipflop in your output counter and step counter. So , 32 bit system requires only 32 input flipflops and three time 5 flipflops (2^5 = 32). (5 for the step counter , 5 for the bitcounter and 5 for the output latch )

author: free_electron
author_rank: Super Contributor
timestamp: April 11, 2012, 04:54:17 pm
content: Quote from: olsenn on April 11, 2012, 04:40:46 pmVerilog is not a programming language... This doesn't work at all as all the expressions are evaluated in parallel. What you made is an or gate...when one of the inputs is high 'count' will be 1...

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 04:57:52 pm
content: Quote from: free_electron on April 11, 2012, 04:52:05 pmThis was my original thought, but I don't think I will be able to afford 5 clock pulses to do this. This will be for a TMDS implementation. If you're not familiar:http://www.oocities.org/yehcheang/Images/TMDS_Encoding_Algorithm.jpg. I'm only on the first 'decision'... not even the first stageI was wondering about that Verilog as well.. I didn't know if there was any sort of atomic protection.I think I'll have to go with my circuit (at this point I'm proud of it so it's going to be hard to convince me to not use it) or use a lookup table.It's actually really interesting that I'm working on this project again. During my Google interview 'how to count bits' was one of the questions. Sadly it was for computers, and obviously a lookup table was the option there.-Brandon

author: jahonen
author_rank: Super Contributor
timestamp: April 11, 2012, 06:31:04 pm
content: I don't obviously know implementation details but I somehow guess that small latency does not harm, so you can use as many clock cycles between DVI output and your pixel input as you like as long as you maintain the required throughput. So you can create a pipelined structure where each stage processes different pixel in various stages. That fits on a FPGA perfectly. In fact pipelined structures are preferred instead of complex combinatorial logic.I agree that using block RAM is the simplest way, and is resource efficient on Cyclone IV. It takes only one memory block. You can easily add the ROM using megawizard plugin manager in Quartus, it creates block symbol file etc. for you, when you enter some basic parameters, like data width and number of words. You can then punch an address into your ROM memory block in each clock cycle, and you get your result out after latency for each clock. Very simple.Regards,Janne

author: free_electron
author_rank: Super Contributor
timestamp: April 11, 2012, 06:48:45 pm
content: You can use your own clock. Given that internal clocks in FPGa's can be pumped up to 400 MHz ... even if you need 10 clockticks to calculate...ANyway , what you need can be resolved in a different way. you are not interested in the absolute bitcount... you only need to know if there are more 1's than zeros... so you can use a modified exor tree.look at two adjacent bits. if they are 01 or 10 -> eliminate them they balanced each other outyou need to build a block that has 2 outputs. 1 output tells you 'BALANCED', the other tell's you if its 0 heavy or 1 heavy...you need 4 of these blocks. this reduces your outputs to 4.now build a block that looks at two adjacent outputs. if both are balanced set an output 'balanced'. if they are not balanced look of one is 0 heavy and the other '1 heave and strike them out to 'balance ( exor gate ). if the result is again imbalanced it will be '0' heavy or '1 heavy'this output essentially tells you the output for 4 input bits. ( no need to look at all 8 )the outputs tells you : the block is either internally balanced , or it is leaning to 1 , or leaning to 0at the top level you only need to compare 2 blocks. if both yield 'balanced', or one is leaning 1 and the other leaning 0 you decide based on D0. in other instances you take the 'leaning' result.i'd have to work it out but i think all you need is about 6 xor gates and some AND and or gates.You can reduce the logic becasue you do not need an absolute bit count as a numerical value. you are only interested if the 1 and 0's are balance , leaning towards 1 or leaning towards 0.Now, here is another thing. This is for digital video. the bits are transmitted serially... so you can do away with the shifter altogether. all you need is a counter. drive the enable with the incoming bitstream , syncronize with the bitclock and by the time the last bit is received you have your answer.Sync a state machine to D7 , and at the moment D0 is in you know the answer. ( plus some propagation time, but well before the next clocktick ).Now, that being said. How are you going to capture this stream ? You will need a bloody fast FPGA to handle the bitstream ... TMDS uses a 165 MHz i/o clock.. guess what... it won't be a plcc44 on a double sided board ... FPGA's that can handle that are BGA , need 6 to 12 layer boards, matched impedance and tuned line lengths. And they need differential transceiver cells.... And you are trying to design this as a schematic... ( you don't know an HDL apparently .. ) Pardon my french but : FAIL !Second problem. Silicon Image holds the rights on TMDS ... if you build a decoder and publish it you will have to fork over some serious dough to them ...

author: Rufus
author_rank: Super Contributor
timestamp: April 11, 2012, 06:51:15 pm
content: Quote from: gamozo on April 11, 2012, 05:10:56 amhttp://read.pudn.com/downloads183/sourcecode/embed/857895/xapp460/dvi_demo/rtl/tx/encode.v__.htmSupposed to manage 700Mb/s in a Spartan3A

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 07:37:25 pm
content: Interesting that they add them all up instead of using a lookup table... I guess the 'decision' process really doesn't need to be fast though, it only has to run at the pixel rate. My fastest PLL runs at about 450MHz, so I'm going to be stuck with that.At 450MHz I could run 1080p @ 20Hz... but would a monitor complain if I don't give it 60Hz refresh rate?-Brandon

author: slateraptor
author_rank: Frequent Contributor
timestamp: April 11, 2012, 07:43:52 pm
content: Quote from: gamozo on April 11, 2012, 07:37:25 pmIf you get your architecture to f'n properly at 450MHz, I'd be impressed.

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 07:53:30 pm
content: Quote from: slateraptor on April 11, 2012, 07:43:52 pmThe output will have to throw the bits out at 450MHz. My calculations will only have to be done at 45MHz (I can calculate on the pixel rate, data goes out at 10x pixel rate). I don't think 45MHz is very impractical... and I'm sure I can PISO bits out at 450MHz. I don't have much of a clue though.

author: cybergibbons
author_rank: Frequent Contributor
timestamp: April 11, 2012, 07:55:21 pm
content: Looking at the image of the algorithm, isn't the idea that this can be processed serially, bit by bit? There doesn't seem to be any need to change this into bytes before performing the operation.

author: joelby
author_rank: Frequent Contributor
timestamp: April 11, 2012, 10:20:23 pm
content: Some FPGAs have built-in SERDES blocks, which make high speed serial data I/O much simpler, because you can send them 4, 5, or 8-bit words (or whatever) at a fraction of the line rate. This makes it quite easy to achieve sensible fabric timing on inexpensive FPGAs such as the Xilinx Spartan-6. I'm not sure which Altera series incorporate SERDES, but it's well worth seeing if yours does.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: April 11, 2012, 10:47:11 pm
content: There are many ways to count bits:http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetNaive

author: gamozo
author_rank: Regular Contributor
timestamp: April 11, 2012, 11:03:23 pm
content: Quote from: joelby on April 11, 2012, 10:20:23 pmI only saw things about SERDES and LVDS... however the LVDS output on my chip can run a 10-bit line with a serial output at 840MHz! That probably can get me to 720p. I'll wait till I get home to see what megafunctions I can throw in there. Perhaps LVDS is optional.(http://www.altera.com/literature/hb/cyclone-iv/cyiv-53001.pdf- Section 1-31)-Brandon

author: Rufus
author_rank: Super Contributor
timestamp: April 11, 2012, 11:33:39 pm
content: Quote from: gamozo on April 11, 2012, 07:37:25 pmBut does it? If the synthesiser is any good a combinatorial logic expression will be minimised and fitted to the hardware regardless of how it was expressed in HDL. If you coded a large case statement which looks like a lookup table the end result should be the same.

author: free_electron
author_rank: Super Contributor
timestamp: April 12, 2012, 12:57:31 am
content: the key to the TMDs system is that you do not need to count bits ! you only need to know if the word is 'balanced' and to which side it leans.For every zero you need a one.Here's how its done in the real silicon: 4 bit counter loaded with combination 1000 for every incoming bit that is 1 they increment. for every incoming bit that is zero they decrement.if at the end the counter is still at '1' they use te last received bit as parity. For other combinations you only need to look at the LSB of the 4 bit counter.Don't know if this is portable to FPGA.... the i/o structures may not have fast enough flipflops..

author: gamozo
author_rank: Regular Contributor
timestamp: April 12, 2012, 01:08:12 am
content: I essentially just add the bits, and ignore the extra complications of decrementing. Then I compare if it's >4, =4 or <4. You can see the comparison logic at the bottom of the schematic, below the boxes. Pretty simple.

author: amspire
author_rank: Super Contributor
timestamp: April 12, 2012, 02:37:08 am
content: The trouble with complex combinatorial logic is you can end up with a fair bit of gate delay, and you need to allow for worse case settling time. It is hard to judge if this is a problem without knowing the device you are using.If instead you set up a synchronous pipeline, then you can use counters or whatever you want, and you can still output at the full clock speed. If it takes 8 clock cycles for a counter to count the bits, and a couple more to then encode the data, just have a 10 stage synchronous pipeline, and every clock cycle, all the data just moves one step down the pipeline to the next set of registers. You get maximum speed without any critical gate delay problems.Richard.

author: joelby
author_rank: Frequent Contributor
timestamp: April 12, 2012, 02:59:24 am
content: Unless you really want to re-invent the wheel, Xilinx have a reference design that implements a TMDS encoder and decoder. I've just had a look and it simply does this:Code:reg [3:0] n1d; //number of 1s in dinreg [7:0] din_q;always @ (posedge clkin) beginn1d <=#1 din + din + din + din + din + din + din + din;din_q <=#1 din;endThe actual encoder should be portable to any FPGA. I've no idea if Altera have a similar app note and reference design, but I'd be surprised if they didn't.XAPP495 is available fromhereand the design fileshere(latter requires a free Xilinx account).

author: gamozo
author_rank: Regular Contributor
timestamp: April 12, 2012, 04:07:11 am
content: Thanks for all the help guys!I'm going to go ahead and reinvent the wheel for my first prototype (I love working with gates), and then I'll make a 'proper' implementation.Tonight I made a simple tester for stage 1 of the TMDS encoding and outputs to LEDs. Stage 2 will be tricky because it relies on the past data's parity.What I get to see:-Brandon

author: joelby
author_rank: Frequent Contributor
timestamp: April 12, 2012, 04:08:55 am
content: Cool! The schematic looks like a nightmareHave you considered using HDL?

author: gamozo
author_rank: Regular Contributor
timestamp: April 12, 2012, 04:42:48 am
content: Quote from: joelby on April 12, 2012, 04:08:55 amI've been doodling gate-based circuitry in my notebook since I was 11. Now that I have an FPGA I can make all my dreams come true (without 100 hours of breadboarding)... it looks like art to meBut once I get bored of drawing gates (I've got a lot in my system to get out), I will use an HDL.-Brandon

author: amspire
author_rank: Super Contributor
timestamp: April 12, 2012, 07:14:18 am
content: Quote from: gamozo on April 12, 2012, 04:42:48 amI like designing with gates as well, as long as I can see some kind of structure, so it is possible to make sense of it.When it looks like randomly connected gates, I hate it.Here is my take on a solution to your problem using gates. I have only done the first four bits, but there is a pattern that can be repeated for as many bits as you want. The output (I hope) is an ordered list of bits starting at the bottom and growing up. If only one bit is set on the input, the bottom bit only will be set on the output. If 3 bits are set on the input, then bottom 3 will be set on the output.Each stage handles one more bit then the previous stage. Each stage consists of an AND gate at the top and an OR gate at the bottom. The intermediate bits use one AND gate and one OR gate each. Obviously each time you add a bit, the delay increased by two gate delays.The rough logic is that if a output bit is set in the preceding stage, it stays set. If it was not set, then it gets set if the next lower bit is set, and the topmost bit of the stage is set. You only have to look at the topmost bit in stage to see if a new bit needs to turn on, since all the lower ones have been processed in the previous stages.To check for =4 bits set then takes an XOR gate to the 4th and 5th outputs. To check for <4, you just invert the 4th output. To check for >4, you take the 5th output directly.Probably not the most efficient solution, but it can be comprehended at least.Richard.

author: gamozo
author_rank: Regular Contributor
timestamp: April 12, 2012, 05:23:17 pm
content: I wanted to share also my explanation about how my little design works.https://www.eevblog.com/forum/beginners/counting-number-of-set-bits/?action=dlattach;attach=23082;imageEach stage (in the boxes) is essentially the same, but they process 1 less bit.The XOR gates cascade all of the way through, to determine if the number of ones is even or odd. In the first stage, this determines if there are an even number of ones (sbits == 0) or if there are an odd number (sbits == 1).The AND gates keep track of how many sets of two there are (thus, the second bit (2^1)). Even though there are 7 AND gates, it's impossible to have more than four set due to the design. Now the outputs of all the AND gates represents floor(red[7..0] / 2) [not in binary, but by the number of ones present... for example 0110100 is 3].The second stage repeats this process, but now it determines if there's an even number of twos, and also it now uses the AND gates to create the representation of floor(red[7..0] / 4).Finally the 3rd stage gets the third bit, and the fourth stage determines the final bit. (Note that the AND gates from the third stage are never used, but are just shown to show the pattern and are optimized out at compile-time)Below all of these boxes is the logic to determine if it's =4, <4 or >4... and then determines which operation to use based on these.Here's an example:Code:0 & = 0 -> stg11 ^ = 1 -------------\| & = 0 -> stg11 & = 1 -> stg1 | ^ = 1 -----------\1 ^ = 0 -------------/ \\0 & = 0 -> stg1 | & = 1 -> stg11 ^ = 1 -------------\ / ^ = 0 -> sbits| & = 0 -> stg1 /0 & = 0 -> stg1 | ^ = 1 -----------/0 ^ = 0 -------------/stg1[6..0] = 1000010sbits = 0Actual number of bits in the original string:4 (0b100)You can see how if you count the number of set bits in stg1, you get 2.Multiply this 2 by 2 and you get 4... coincidence? No.TL;DR: Come to think about it... what I'm doing is just base conversion using modulus.-Brandon

author: A-sic Enginerd
author_rank: Regular Contributor
timestamp: April 20, 2012, 10:32:31 pm
content: This is probably a bit 'after the fact' in looking at the dates on replies, but here's my $0.02.I actually had need of this very thing (counting ones in a reg) some time back, only for an actual ASIC. You hate to use a LUT as that takes real estate. Shift reg is the most obvious answer (small logic, easy to implement).....until you're counting 32 or 64 bit regs. Then it gets very expensive. Can't afford the latency. So that set me on a hunt. I think I ran across the very same link someone else pointed out earlier about how many algorithms there are to count 1's. I played around with a couple variants and synthesized each to see what they really looked like. (yes, I'm working in an HDL...Verilog to be specific).The one that gave me the best solution, trading off area and doing it in a single clock cycle and still meeting timing was a simple for loop. (yes, for loops are a synthesize construct.....if used properly)Code:// sorry, I'll probably wind up mixing in some SystemVerilog syntax, but you'll get the gistalways_combbegincount = 6'b0; // counter is this big because I'm counting a 32 bit regfor (integer i=0; i<32; i=i+1)count = count + my_reg;endThis is actually, basically the same code as someone else wrote out from a Xilinx example it's just this one stays neater and tighter from a syntax perspective when the number of bits you're counting grows.Soooo, what does that give me. Well, it actually winds up looking very similar to what you built by hand.I can't be certain of the exact logic constructed, but it was similar enough I'd say you're spot on. (lots of XOR blocks staged serially). The difference here is coding it in HDL lessens the strain on the grey matter. And when you're block is a few hundred thousand gates, you can't afford to be drawing stuff out by hand.Few other tidbits to take note of: if you haven't experienced it already, the actual clock speed you can get the FPGA to run at is dependent on how much utilization you have and the congestion / routing issues (as others have mentioned).Yes, you can very likely get the IO / serdes / whatever to run at speed, but the internal logic can sometimes be a challenge to get to speed. I worked on a project that we stuffed into a very large, very expensive FPGA that had the serdes running at 1.5Gbps, but it was a stretch to get the internal logic to run at anything faster than 35MHz.EDIT: DOH! hit post and realized the html conflicts with the Verilog syntax I was trying to type.