• Please review our updated Terms and Rules here

Article: Designing an 8 bit ALU in a CPLD

I don't know anything about CPLDs.

This was an interesting article.

On the one hand, building an ALU using a logic code that has things like "ADD" seems a bit like cheating. But at the same time, what's the point of having higher level logic if you have to NAND and XOR your way just to increment a counter. Doesn't seem very productive.

I'm sure if you wanted to, you could make an ALU from synthetic NAND gates using this language, but for all practical purposes, why would you?
 
That was my reaction. I mean, how is the add operation implemented? Does it use carry-lookahead or is it simply ripple-carry? For someone new to VHDL, it might be useful, which is why I posted it.
 
You need to look at the synthesizer output to see how the add operation is actually implemented (and it might not say if addition is treated as a primitive). The toolchain most likely has multiple possible implementations available and selects one based on the provided constraints. Given enough freedom, synthesizer outputs can vary wildly between runs as well, and I don't see any constraints (except for the pin mapping) specified. So the actual implementation might even change between runs.

I don't see any clock signal / registers either, so I would assume all outputs to glitch a lot until they eventually stabilize, and without time constraints, a ripple-carry implementation is likely.

Thank you for posting the article. I have only used FPGAs, but not CPLDs before.

I'm sure if you wanted to, you could make an ALU from synthetic NAND gates using this language, but for all practical purposes, why would you?
Click to expand...
Generated code may do this. In my opinion, neither Verilog nor VHDL are very pleasant to use but without alternatives, so they are targets for many higher-level languages (such as Matlab).
 
However, this doesn't answer my original objection: In VHDL or Verilog when addition is used, what's the carry mechanism? I suspect strongly that it's ripple-carry, as this can easily be synthesized for any number of bits. Carry-lookahead is a bit more complex.

I suspect also that either VHDL or Verilog's addition algorithm is incapable of working in signed ones' complement math, though I haven't researched that one (namely, managing end-around carry). Of course, one can implement this at a lower level in the language.
 
Last edited:
You get what you pay for of course...

If you let the tool supplier decide how they are going to implement your VHDL description then you will get something...

If you specify exactly what you want, it will take longer to implement, but you should get what you actually specified.

Dave
 
Chuck(G) said:
In VHDL or Verilog when addition is used, what's the carry mechanism? I suspect strongly that it's ripple-carry, as this can easily be synthesized for any number of bits. Carry-lookahead is a bit more complex.
Click to expand...
The final carry mechanism is whatever the synthesizer decides to synthesize, which it will do based on constraints, available primitives and the initial random seed. Verilog and VHDL only specify the what, not the how. If you want an explicit implementation, you have to be explicit (and the optimizer may still replace the whole thing anyway).

There are ways to annotate the description to guide the synthesizer, but these are toolchain-specific.

Chuck(G) said:
I suspect also that either VHDL or Verilog's addition algorithm is incapable of working in signed ones' complement math, though I haven't researched that one (namely, managing end-around carry). Of course, one can implement this at a lower level in the language.
Click to expand...
The VHDL std_logic_vector does not support arithmetic at all (the article uses both std_logic_unsigned and std_logic_arith, which overload it for unsigned arithmetic; they are no longer recommended). The numeric_std library provides both unsigned and signed types (two's complement). To my knowledge, there is no support for one's complement in the language standard.

Verilog's typing system is much weaker, so I'd assume one's complement to be missing as well.
 
Bottom line: If you want it done right, do it yourself. :)

One gotcha when using CPLD instead of FPGA is that most synthesis limits you to a single clock domain, so various synchronization methods are required. Like all design tools, just because it works in simulation doesn't mean it'll work in the real world.

I'm old and USAn, so I use Verilog.
 
>>> just because it works in simulation doesn't mean it'll work in the real world.

That is all part of the training! Well, it worked OK when I was simulating it...

Dave
 
daver2 said:
>>> just because it works in simulation doesn't mean it'll work in the real world.

That is all part of the training! Well, it worked OK when I was simulating it...

Dave
Click to expand...

Oddly, there are many simulations that work in the world of analog electronics that don't work in reality.

Especially so in RF circuit design, because the sim has no idea of the grounding scenarios and isolation/ shielding between stages of the real apparatus, and assumes they are "ideal". It cannot predict positive feedback pathways that exist in reality between components & stages.

All kinds of common feedback pathways and component proximities exist that the sim knows nothing of.

When the man and the woman got too physically close in the Movie; The Island,the computer said "Proximity Alert" so the guard would separate them.

Also the computer wouldn't let him have Bacon for breakfast because his urine sodium was too high. But the computer was stupid (not its fault bad programming) because, if the Kidneys are working properly they deal with increased sodium (within extreme limits) so he could have had the Bacon with no ill health effects, only positive ones, as it would have made him happy. Another case of a sim malfunctioning perhaps.

One of the "classics" that takes my fancy is the humble two transistor multi-vibrator. If you want it to start in a sim, you had better put some asymmetry into it. In the real world, there is always some and noise voltages too, so in the real world these circuits oscillate, not necessarily so in the sim.

Simulators save a lot of time and money. But in many areas I work in with RF circuits, they are a hindrance not an asset. In other areas, people cannot be without them and follow their outputs as though they are Gospel.
 
I had an interesting problem when I encoded the Apollo Guidance Computer (AGC) schematics into an FPGA. The AGC logic consists purely of expandable, 3-input NOR gates. Now, FPGA synthesis tools do not like cross-coupled NOR gates forming S/R flip-flops. So, I simulated a 3-input NOR gate with a NOR gate and a D-latch clocked to simulate the correct transfer time. This largely worked except when a pulse was generated into the resulting logic. On a real cross-coupled NOR gate S/R latch it would work. On the FPGA equivalent, it went into oscillation!

I also had fun and games with chains of inverter gates in series. I worked out that the AGC was using these inverter gates to delay signals to ensure that signals arrived coincidentally at the logic after some intermediate processing (path equalisation). Of course, the synthesizer thought I was being mad putting lots of inverters in series - so replaced them with a piece of wire! Adding the D-latches worked fine for this.

What I ended up doing was analysing the AGC logic to work out how it worked, and then made an FPGA design decision as to whether I required a 3-input NOR gate only or a 3-input NOR gate with a D-latch on the output. I also needed to work out whether the latch should be present on the SET or RESET side of a S/R latch.

No substitute for knowledge!

I am actually glad I did this project - I learned an awful lot in a short space of time about how to persuade the synthesizer tool to do what I wanted it to do rather than what it wanted to do!

I entered the AGC logic into a spreadsheet. Used a VB script to validate the digital logic that I had entered and then automagically generated commented VHDL code from the spreadsheet content. I could then 'tweak' the logic by setting various flags in a column of the spreadsheet.

Dave
 
The CPLD design tool Quartus and its predecessor Maxplus have rich set of TTL library for 20+ years, so for the original post, I'd do classic design with 74181 ALU and 74182 carry look ahead but with Quartus's TTL library of 74181 and 74182 which are all combinatorial logic inside.

If the original design was in schematic, then you are probably better off capturing the design using schematic entry in CPLD or FPGA and take advantage of existing TTL library. I have captured UltraWarp accelerator for Apple II which has 43 TTL logic into a 128-macrocell CPLD using Quartus schematic entry. I recall the 128-macrocell CPLD is about 70% utilized.
Bill
 
I too prefer schematic capture (using recognisable logic blocks such as TTL functional devices).

Prototype in TTL and wire-wrap and then convert to a CPLD or FPGA (well, in the very old days at least!)!

Dave
 
Tools, tools. VHDL and Verilog are pretty poor for asynchronous pulse-coupled logic, for example. They won't tell you how to design with parametrons, for example.
 
You must log in or register to reply here.
Back
Top