Re: odd bits
- To: misc
- Subject: Re: odd bits
- From: Christophe Lavarenne <Christophe.Lavarenne@xxxxxxxx>
- Date: Thu, 10 Oct 1996 17:32:38 +0200 (MET DST)
Wayne Morellini <waynem1@cq-pan.cqu.EDU.AU>:
> I heard that they didn't have to do it [odd bits] anymore and that future
> chips could do withoout it, is this right?
Where did you hear that?
Bit inversions speed up the carry chain which is the misc ALU critical path.
The address bus incrementer (which output is used for instruction word prefetch
and for desequencing and post-increment memory access instructions) has more
time to propagate carry because even the fastest memory references are at least
as long as several arithmetic or stack handling instructions.
I remember some discussion here about various carry lookahead techniques to
shorten the carry propagation delay. Welcome ALU specialists to explain that
again or give good references on the subject.
On most other processors, instruction decoding, register addressing, address
translation and other "translation lookaside buffers" require pipelines with
register dependency automatic detection and other registers aliasing features.
The carry paths (in the ALU and address generators) are probably still critical
in their respective pipeline stage, but there are probably other paths close to
critical, which make the pipeline period probably close to the carry delay.
Whereas in Chuck's chips, 5-bits instructions decoding delay is very short
because all the ALU outputs and register selects are computed in parallel and
signals are routed on parallel buses, so the ALU carry critical path is
enormous compared to any other on-chip sub-critical path (only off-chip memory
reference delays are bigger).
Eugene Leitl <Eugene.Leitl@lrz.uni-muenchen.de>:
> Apropos Chuck: Christophe, do you know why all major players (Chuck,
> Jeff) have become so suddenly incommunicado?
Because they are busy with iTv who give them money to live and develop misc.
Ting does the best he can with the MuP21, but he cannot live on selling it
because most forthers seem to find $250 still too much for a MuP21 board, so
he has to spend time working for money and therefore he is less responsive for
forthers requests ... the snake bites its tail.
>Apropos video processor: Christoph, is the MuP21's PAL signal standard/clean?
I used a tri-standard (NTSC-PAL-SECAM) tv-set and noticed that the video output
is still clean (although color shifted) when forcing the PAL mode.
But I never tried it on a PAL-only monitor, but I think that Stephen Pelc (MPE)
said he tried it.
> ... power dissipation ...
Regular synchronously clocked processors consume a good part of their power
only to shake strongly the net distributing the clock on the chip, such that
the clock skew is kept as small as possible compared to the clock period.
On self timed processors such as Chuck's designs, there is no globally
distributed clock, control signals take time to propagate (this is taken into
account by Chuck's silicon simulator) and no signal is really periodic, so
consumption and electro-magnetic radiations are better distributed over time
and therefore much less power is consumed in regard with the instruction
delays.
So before qualifying F21 as a "power hog", ask Jeff for power characteristics.
CL