Not much compared to the "norm" around here, but... http://www.delorie.com/electronics/bin2seven/
My first verilog/cpld project
Started by ●February 8, 2008
Reply by ●February 8, 20082008-02-08
On Feb 8, 4:55 pm, DJ Delorie <d...@delorie.com> wrote:> Not much compared to the "norm" around here, but... > > http://www.delorie.com/electronics/bin2seven/Neat. Some great things grow from small beginnings. Here's what I've been hacking on: http://repo.or.cz/w/yari.git Cheers, Tommy
Reply by ●February 9, 20082008-02-09
On Feb 9, 1:55 am, DJ Delorie <d...@delorie.com> wrote:> Not much compared to the "norm" around here, but... > > http://www.delorie.com/electronics/bin2seven/I remember seeing the thread in s.e.d. :) To enhance readability a bit, I would keep the BCD value as a 10 bit vector, rather than split it up between the 3 digits. In bcd.v, you can then write your case statement as: case (ibin) 0 : bcd = 10'h0; 1 : bcd = 10'h1; 2 : bcd = 10'h2; 3 : bcd = 10'h3; ... 255 : bcd = 10'h255; endcase In top.v, extract the individual digits for further processing: wire [1:0] bcd2 = bcd[9:8]; wire [3:0] bcd1 = bcd[7:4]; wire [3:0] bcd0 = bcd[3:0];
Reply by ●February 9, 20082008-02-09
>Not much compared to the "norm" around here, but... >http://www.delorie.com/electronics/bin2seven/Don't worry about the norm. Keep a clarity of exposition in your code and you'll soon overtake most other engineers (who often can't communicate their work clearly after 20-30 years). "I still think people could be documenting what they write much better" (Knuth, 1996) Mike
Reply by ●February 9, 20082008-02-09
DJ Delorie <dj@delorie.com> wrote:> >Not much compared to the "norm" around here, but... > >http://www.delorie.com/electronics/bin2seven/I would have tried a 256 way case converting directly from 8 bit binary to 16 segments including the leading zero blanking function. Effectively expressing the ROM solution in verilog. Let the synthesiser do the work. I don't know how 'big' the result would be but you might be pleasantly surprised. Also it might be more efficient to latch the segment outputs not the binary inputs (at the expense of a little extra data hold time). The macro cells driving the segments have flip flops which are otherwise unused. I also noticed you are outputting oz for blanking, that probably takes more logic that forcing inactive for blanking. --
Reply by ●February 9, 20082008-02-09
Arlet <usenet+5@c-scape.nl> writes:> 255 : bcd = 10'h255;Neat trick, thanks. I use a perl script to generate the big tables anyway, so readability wasn't high on my list.
Reply by ●February 9, 20082008-02-09
nospam <nospam@please.invalid> writes:> I would have tried a 256 way case converting directly from 8 bit > binary to 16 segments including the leading zero blanking > function. Effectively expressing the ROM solution in verilog.I started with that, but consider the blanking, lzblanking, and inverting - that's a 2048 way case. Plus, I wouldn't have had reusable BCD and 7segment modules left over ;-)> Let the synthesiser do the work. I don't know how 'big' the result > would be but you might be pleasantly surprised.I found that the size of the result was somewhat independent of the way I expressed the logic (I tried a LOT of ways trying to fit it into the '36). So I might as well go with something that's readable, editable, and reusable.> Also it might be more efficient to latch the segment outputs not the > binary inputs (at the expense of a little extra data hold time). The > macro cells driving the segments have flip flops which are otherwise > unused.That keeps you from using the blanking signal as a PWM brightness control, or the polarity signal to drive LCDs.> I also noticed you are outputting oz for blanking, that probably > takes more logic that forcing inactive for blanking.I figured since the output drivers had unused enables already, it would just hook into those, saving some gates.
Reply by ●February 12, 20082008-02-12
DJ Delorie wrote:> Not much compared to the "norm" around here, but... > > http://www.delorie.com/electronics/bin2seven/Aughhh! Isn't there a better way to do the binary to BCD conversion? Not that there'd be any difference in performance or area, just that the brute-force enumeration of all possible states seems ugly. I'd hate to do this for a 12-bit or wider conversion. Jon
Reply by ●February 12, 20082008-02-12
On Feb 12, 12:03=A0pm, Jon Elson <el...@wustl.edu> wrote:> DJ Delorie wrote: > > Not much compared to the "norm" around here, but... > > >http://www.delorie.com/electronics/bin2seven/ > > Aughhh! =A0Isn't there a better way to do the binary to BCD conversion? > Not that there'd be any difference in performance or area, just that the > brute-force enumeration of all possible states seems ugly. =A0I'd hate to > do this for a 12-bit or wider conversion. > > JonA 256x10 ROM is pretty clean if it implements in a BlockRAM. If it goes to distributed logic, I'd suggest a Binary to BCD conversion such as that covered in http://www.xilinx.com/support/documentation/application_n= otes/xapp029.pdf (a reasonably-sized url - WooHoo!) coauthored back around `97 by our own Peter Alfke. In those days I was just starting to venture out from the schematic realm into HDLs. I used the app note to get my head around the simpler conversion technique that I ended up implementing as a function in a picoBlaze LCD display driver recently. Clean. - John_H
Reply by ●February 12, 20082008-02-12
Jon Elson wrote:> > > DJ Delorie wrote: > >> Not much compared to the "norm" around here, but... >> >> http://www.delorie.com/electronics/bin2seven/ > > > Aughhh! Isn't there a better way to do the binary to BCD conversion? > Not that there'd be any difference in performance or area, just that the > brute-force enumeration of all possible states seems ugly. I'd hate to > do this for a 12-bit or wider conversion.Perhaps using the Divide and Modulus operators ? -jg
