Request: Less expensive way to display decimal numbers on LED displays

[rj45]

Hi!

So, some feedback I got on my youtube series is to avoid hexadecimal and use decimal as much as possible. I am currently building a blinkenlight frontpanel for the CPU I am building. And I want to display numbers with 7-segment LEDs instead of output pins for maximum blinkenlights.

So, in order to display in decimal on 7 segment displays, I need to convert a binary 32-bit number into a 10 digit BCD number. Here is the circuit to do that:

Each blue box contains this:

Here's the stats on that:

Now, this is just a front panel, I don't plan to include this as part of the CPU I export to verilog. It's only for debugging. So that's quite a lot of components just to convert a number into a more human friendly one. And I will need multiple of these to display all the numbers I want to display.

BTW, yes you can do this iteratively, but then you have to clock it 32x faster than the CPU itself, and deal with either multiple clock domains or figuring out how to single step a CPU when the debug displays take 32 cycles to update. But for reference this is what that would look like:

I would love if there was a decimal to bcd converter component that was super fast and didn't require 153 adders and comparators. Or alternatively, a set of LED displays that would work really well for displaying debug info inside a processor in a configurable base (decimal would be valid) and have that nice LED blinkenlight look. Or whatever better idea you come up with.

Thanks! And just an aside: playing around in Digital is a ton of fun! Thanks so much for working on this, it's so very appreciated!

[rj45]

To do this all in a ROM would be at least 4 GB per ROM...

I could replace the "> 4 ? +3" circuit with a ROM.... that would probably speed it up a bit? Maybe make a ROM for 3 of them, 2 of them and 1 of them. I still need 30 rows of them though. Maybe I could make a ROM that calculates 3 rows at a time. So there is optimizations I could do to make the circuit have fewer parts / simulate faster.

It's just kinda ridiculous how much logic is involved in doing this in a circuit. A CPU can do this in just a few instructions. Hence the request for some way to do this without simulating a ton of logic.

[xotmatrix]

Sorry for deleting the unhelpful post you replied to.

[hneemann]

Why not simply add a probe and select decimal format?

[xotmatrix]

If a probe (or any other text output) could allow one to set a system font, font size, and font color, this seems like it could be a good presentation solution. A user-supplied 7-segment font could fulfill the blinkenlights dream.

[rj45]

Yeah, it's mainly about the blinkenlights -- that is, making a front panel that's a bit of eye candy.

Edit: this is what I have so far:

Edit2: having a text element / probe that I can load a custom font, colour and size for would work fine, I found an open source 7-segment font with a copyright that allows bundling, so I can just provide that font in the git repo if I put this up on github (still undecided on that). So it would need to allow you to specify a specific font file so I don't have to explain how to make the frontpanel display correctly in a readme that people may or may not read.

[hneemann]

To be honest, I neither want to add a font selection box, nor a BCD encoder. So I would advise to just stick with the current solution with the BCD encoder, or build a custom BCD encoder component if there really is a performance problem. This repo would be a good starting point.

[rj45]

Would you be willing to add more blinkenlight options? Like a probe that looks like an LED display?

I mean, if the answer is no, perhaps some day I would have some time to dig into Java and build it myself. Would you accept PRs for aesthetic features like this by chance?

[eliask05]

You may want to take a look at a simpler solution that uses flip-flops: http://www.ingelec.uns.edu.ar/dclac2558/BCD2BIN.PDF (I couldn't find the original Xilinx application note).

[hneemann]

Would you accept PRs for aesthetic features like this by chance?

To be honest, I don't think so! That's why I created the custom component example repository: Everyone can add what they want without having to include everything in the main branch. This gives users the maximum freedom and at the same time keeps the main branch clean.

On the other hand, a BCD encoder is not that fancy either. Maybe one should add one after all. I'll have to think about it.

[rj45]

Okay, I totally understand. Feature creep is good to fight against. If you decide against adding the BCD encoder feel free to close this :-)

[hneemann]

Only 10 components required. :smile:

Nobody would ever build that in hardware. But in the simulation it works fine! bcd32.zip

[hneemann]

Now that it has become clear how easy it is to implement a BCD encoder for simulation, a corresponding component is no longer required.

[rj45]

Finally got a chance to look at it, very simple, and exactly what I was looking for. Thanks again!

[xotmatrix]

Today I learned there is a divide component.