Hello people!! This is my first post so I don't know what im doing.
First off I'm relatively a noob with this stuff so if I'm doing something wrong that's why.

I plan on making a very modular ALU using only discrete logic and home made pcb's using my SLA printer. I'm very early in my design so nothing is finalized nor do I even have half the components to build this dang thing and test it. I'm using NI Multisim for simulations and KiCad for pcb fab.

I'm initially interfacing my ALU with a 4x4 keypad that stores decimal digits represented in 4 bit binary words. These words are stored in 4 bit registers and fed to displays.
My problem is that these 4 bit words can't be concatenate together AND equal the same number on the displays.

I know one way to fix this problem but it involves multiplying the 4 bit words by powers of 10 which is something I really want to avoid unless there is a dedicated IC for this exact job.

110001101001 ≠ 369
Hope this helps. I'm more then willing to share files or maybe even let people collab with this project


Full Setup

 

You will save yourself a huge headache if you allow your ALU to work in binary (hex) instead of decimal.

 

What are you going to do with this ALU?

 

The approach you are taking is known as using BCD -- binary-coded decimal. As you've noticed, it has the advantage of being friendly for user input and display output, but it is not friendly for doing arithmetic operations on.

Many early electronic adding machines, cash registers, calculators, and the like took this approach and there are a number of tricks, both in software and in hardware, that can be used get around it.

But there's a reason why virtually no machine uses this approach today -- instead, numbers are represented in binary internally. When input is received, it is converted from whatever format is provided by the input device to binary and when output is produced, it is converted from binary to whatever format is needed by the display device. This greatly narrows the scope of the problem and, again, there are both software and hardware tricks to help out.

What is your purpose with this project? Unless this is just something that you really want to do for the joy of doing it, you are likely to find yourself getting mired down in all kinds of details and problems.

 

This is a very poor choice for a first project. You said so yourself in your first paragraph:

"First off I'm relatively a noob with this stuff so if I'm doing something wrong ..."​

​

What you are doing wrong is trying to run a marathon before learning to crawl and walk. IMHO you should find pieces of this project to implement and build test fixtures for. In doing so you will develop the skills to attempt the design and construction of an ALU and eventually a whole processor.

 

This is a very poor choice for a first project

Poor in the sense it is very complex. As above, break it down into subsections you can understand and prove.

 

This is a very poor choice for a first project. You said so yourself in your first paragraph:

"First off I'm relatively a noob with this stuff so if I'm doing something wrong ..."​

​

What you are doing wrong is trying to run a marathon before learning to crawl and walk. IMHO you should find pieces of this project to implement and build test fixtures for. In doing so you will develop the skills to attempt the design and construction of an ALU and eventually a whole processor.

Thank you but I promise you i never said this is my first project by any means. I understand what you mean but I'm pretty much past the whole build a 555 timer circuit or make a register using only transiters or god forbid if I ever need to do boolean algebra again. Honestly I'm a fast and good learner when I put my all into a project that is actually challenging for me. I wiped this mess in 2 days in my free time after work LOL. I think i can figure this out with little trouble and if not so what?

 

The approach you are taking is known as using BCD -- binary-coded decimal. As you've noticed, it has the advantage of being friendly for user input and display output, but it is not friendly for doing arithmetic operations on.

Many early electronic adding machines, cash registers, calculators, and the like took this approach and there are a number of tricks, both in software and in hardware, that can be used get around it.

But there's a reason why virtually no machine uses this approach today -- instead, numbers are represented in binary internally. When input is received, it is converted from whatever format is provided by the input device to binary and when output is produced, it is converted from binary to whatever format is needed by the display device. This greatly narrows the scope of the problem and, again, there are both software and hardware tricks to help out.

What is your purpose with this project? Unless this is just something that you really want to do for the joy of doing it, you are likely to find yourself getting mired down in all kinds of details and problems.

There's no real reason for this project other then to learn. I understand why people think im a dumb ass for picking a project so complex but honestly I like the challenge. Im not looking to build a full on CPU any time soon with this thing, I really just want something with a user friendly input/output with the option to do more with it much later on.

 

You will save yourself a huge headache if you allow your ALU to work in binary (hex) instead of decimal.

Im not working in decimal? The keypad is a temporary input devise and the output is converted to decimal so a actual human can read it. Im just trying to find some way to make the input devise compatible before It gets stored into the A and B registers. I could make some long ass truth table and whip out some boolean algebra but nah, too many wasted logic gates.

 

What are you going to do with this ALU?

Currently I just wanna store two binary values in registers and preform basic arithmetic and maybe some logical operations too. I also plan to make it future proof meaning if i wanna hook it up to a custom cpu far in the future I can without de-soldering anything.

 

Thank you but I promise you i never said this is my first project by any means. I understand what you mean but I'm pretty much past the whole build a 555 timer circuit or make a register using only transiters or god forbid if I ever need to do boolean algebra again. Honestly I'm a fast and good learner when I put my all into a project that is actually challenging for me. I wiped this mess in 2 days in my free time after work LOL. I think i can figure this out with little trouble and if not so what?

I think you described yourself accurately in your original post and I still think you are biting off more than you can chew! But hey, do I know. I've just been there, did that, and did it better.

 

Im just trying to find some way to make the input devise compatible before It gets stored into the A and B registers.....

Im not looking to build a full on CPU any time soon....

Well, you did describe it as an Arithmetic/Logic Unit design, rather than just the I/O, so it's sensible that the I/O is designed as a compatible addendum to the ALU, rather than the other way round.

 

This is a very poor choice for a first project

I understand why he said it but its not by a long shot LOL. Yeah... i won't lie its a challenge but one i feel this build is do able for me

 

There's no real reason for this project other then to learn. I understand why people think im a dumb ass for picking a project so complex but honestly I like the challenge. Im not looking to build a full on CPU any time soon with this thing, I really just want something with a user friendly input/output with the option to do more with it much later on.

Here's something for you to consider.

There is a project called Nand2Tetris in which you build (in simulation) a (nearly) complete computer with nothing but 2-input NAND gates and D-type flip flops. You then write an assembler for it. You then implement a stack-oriented virtual machine for it. You then write a compiler for an object-oriented language. You then write the operating system libraries for it.

This is a very, very carefully designed and scoped project, so you really can do all of this. It is intended as a one-semester course, usually at about the sophomore level in college, with the only assumed knowledge about a semester's worth of programming in a high-level language. At the high school level it is often stretched into a full year course, but not always. It's an amazingly flexible project and has been used successfully from high school to post-graduate levels, with the difference being how much handholding is down and/or how much additional tasks are added.

Aside from the book (which you can get from Random House for $40 and get on Amazon marketplace for a bit over half that), there is no cost -- all of the software tools are freely downloadable. The book is extremely well written and quite affordable, plus the first half (of the first edition, the second edition came out about a year ago) is available for free on the authors' website. There is also a Coursera course that you can audit for free (you just don't get access to the handful of graded assignments) or get some semblance of credit if you pay for it (I think it's $49).

If you do this course, you will be in a very good position to start tackling a project like the one you are talking about here -- and I can pretty much bet that the decisions you make in that project will be much different, and better informed, that the ones you would make at this point.

Reason for edit: Add book price info.

 

I think you described yourself accurately in your original post and I still think you are biting off more than you can chew! But hey, do I know. I've just been there, did that, and did it better.

thanks for the input

 

Here's something for you to consider.

There is a project called Nand2Tetris in which you build (in simulation) a (nearly) complete computer with nothing but 2-input NAND gates and D-type flip flops. You then write an assembler for it. You then implement a stack-oriented virtual machine for it. You then write a compiler for an object-oriented language. You then write the operating system libraries for it.

This is a very, very carefully designed and scoped project, so you really can do all of this. It is intended at a one-semester course with the only assumed knowledge about a semester's worth of programming in a high-level language. At the high school level it is often stretched into a full year course, but not always.

Aside from the book, there is no cost -- all of the software tools are freely downloadable. The book is extremely well written and quite affordable, plus the first half (of the first edition, the second edition came out about a year ago) is available for free on the authors' website. There is also a Coursera course that you can audit for free or get some semblance of credit if you pay for it (I think it's $49).

If you do this course, you will be in a very good position to start tackling a project like the one you are talking about here.

Honestly biggest help here. I think I'll sign up for the course. I looked over the course material and it looks great although the first couple of modules will be a cake walk until we hit machine code. Honestly that's fine though because im interested in it. I'll probably work on both the course and this project and share ideas.

I think the biggest problem I have is not knowing the correct terminology. I really don't even think this ALU project is all that hard either. Its just going to have 2 operands and a output register with Op codes and flags, literally the basics. Unless im missing something fundamental i really think this project is currently in my scope. The only reason I need help is that usually the the i/o isn't hooked up directly to the ALU. I already stated my solution but people probably thought that im working in decimal because i mentioned powers of 10 or whatever. Trust me im not that foolish. I just don't know the terminology nor do i think anyone even looked at my messy and very early schematic LOL.

Overall I probably will take that course you gave me once I look into it a bit more. I'm really grateful that at least someone seems to care, thanks!

 

People think you are trying to work in decimal because you appear to be trying to work in decimal (or, more correctly, binary-coded decimal, BCD).

You are storing each digit of a decimal number as a four-bit binary value in a separate register. That means that the weight of the value stored in each register is an integer power of ten. That's a decimal representation.

 

People think you are trying to work in decimal because you appear to be trying to work in decimal (or, more correctly, binary-coded decimal, BCD).

You are storing each digit of a decimal number as a four-bit binary value in a separate register. That means that the weight of the value stored in each register is an integer power of ten. That's a decimal representation.

I don't mean to come off as rude but since the beginning of this thread I've always known that. I could easily fix up a binary multiplier circuit for each digit that multiples by powers of 10 then sum up all the products and store them in new registers. Or just scrap the keypad entirely and use regular switches as a binary input. The problem is the way the keypad interfaces with the registers. The only reason i even made the thread is to see if someone knew of a way that didn't involve a whole multiplier circuit and for each A and B registers mind you. This is what i have been trying to get at and it would 100% work. I just don't wanna solder 50 million sockets of full and half adders to my pcb if I don't have too, wasting space, money, power, and a longer delay between calculations......

 

The keypad is a temporary input devise and the output is converted to decimal so a actual human can read it. Im just trying to find some way to make the input devise compatible before It gets stored into the A and B registers.

Apart from early calculators, I can't think of an example of a decimal keypad being interfaced in hardware at the keyswitch level. I understand the challenge of what you are attempting, and the satisfaction of making it work (if possible), but it is MUCH simpler to perform the logical processes of interface and display conversion in software.

There are limits to the appropriateness of any design solution, and your approach is stretching the practical capabilities of chip-implemented boolean logic. For example, you are faced with the problem of BCD-to-Decimal conversion for input and back again for display which you fear will lead to a hardware morass.

Where you are now, switches and lights for direct boolean I/O are appropriate. Once your architecture has evolved to the point of having controlled I/O paths, software can drive a more human-friendly I/O.

There are lots of instructional videos about various architectures, both combinatorial and microcoded. You might find it very instructive to explore the use of a microcoded keyboard interface. Maybe something based on this: https://www.alternatezone.com/electronics/plc.htm

 

Doing BCD to binary and back in hardware is more complex than an entire simple ALU with add, subtract, and, or and xor, which is all a simple CPU needs.

If you want to use a keypad and 7 segment displays, why not use hexadecimal? Then you can work completely in binary with no conversions.