ttlworks wrote:
Drass, that's impressive work.
Thanks Dieter. Coming from you that means a lot.
Quote:
Using two 74AC541 chips (ROUT.ALUA and ADJ.ALUB) for injecting data into ALUA.BUS and ALUB.BUS would increase the bus capacitance there,
and it adds to the propagation delays.
Agreed. These would likely be FET switches in the final design but capacitance is nevertheless going to be an issue. There are several buses with significant load on them, and ALUA and ALUB are among them. Also, with many ICs on those busses, trace length and termination will be issues as well. No shortage of things to worry about.
Quote:
ADJUST.LO happens to be a 74AC574 with output enable, so to me it would make sense to wire the ADJUST.LO outputs directly to the
outputs of the ALU.B register (which also is a 74AC574), then to make creative use of the output enables of both chips.
;
Nice! I think it works Dieter. Great suggestion.
This does, however, bring up a good point worth discussing. CLK-to-Q tpd and Output-Enable-time are usually pretty close (they are on 74AUC16374s, for example), but there is additional delay required to generate an OE control signal. In general, an OE signal is only likely to arrive at a register after a CLK-to-Q delay (assuming no decoding) of wherever that control signal is coming from.
The BCD2 flip-flop and ALUB in the schematic above make for a good example to illustrate the point. Say we used BCD2 to generate BCD.CYCLE2 and /BCD.CYCLE2 control signals to output-enable ALUB and ADJUST.LO respectively (as I think you are suggesting). That makes sense. We get ALUB normally, and then switch to ADJUST.LO for the BCD2 cycle. That's good, but now the data from ALUB arrives at the FET adder
after the CLK-to-Q delay of BCD2
PLUS the OE time of ADJUST.LO. By contrast, the data from ALUA arrives at the FET adder after just a single CLK-to-Q delay.
The additional OE delay for ADJUST.LO is fine in this case because we split the FET carry chain in to 4-bit segments for BCD operations. But it would not be ok for an 8-bit binary operation which might follow when switching back to ALUB. We are saved in this case by the fact that the cycle after a BCD operation never requires the ALU, so we get a free cycle for ALUB to switch back. In other situations, however, the switching delay would be prohibitive.
Quote:
Also, I would replace the ROUT.ALUA (74AC541) with a 74AC574 with outputs wired to the outputs of the ALUA register (74AC574) and to make creative use of the output enables of both chips.
ROUT.ALUA is used during normal 8-bit binary operations so unfortunately I don't think we can afford the switching delay in this case.
Quote:
Hmm... ALUB.SEL (74CBT3245) select input is switched by a signal generated by the BCD2.A flipflop.
In theory, you could replace ADJUST.LO (74AC574) by two 74AC574 chips, one feeding ALUB7..4, the other feeding ALUB3..0,
and to do some more creative tinkering with the output enables.
This would throw the ALUB.SEL chip out of the design.
Yup, this works nicely, along the lines described above.
Quote:
WB (74AC574) has some spare flipflops, so it looks ideal for throwing flipflops like ALUC.A and BCD2.A out of the design,
but this sure won't increase the readability of the schematics.
In the final schematic we might have to sacrifice readability for PCB real estate. I think you're right to point it out.
Some great suggestions here Dieter. I'll make a note of the improvements for the next rev of the schematic. Thank you!
BigEd wrote:
(Is there a simulation setup being used for these ideas, or is it all by brain power alone? If it were me, I'd quite like to run an exhaustive 512 calculations...)
Of course your'e right, BigEd. Thanks for the comment.
The Logisim model for this design is still a work-in-progress. I do have this specific BCD circuit modelled and have manually run the inputs through a range of values to confirm the results. But it's by no means exhaustive. That will have to wait. In the meantime, I am comforted by the fact that the basic logic is the same as in the C74-6502, which has been tested exhaustively. With some luck, I won't find major errors in this rendition of the circuit when I finally do get the model up and running.