home .. forth .. misc mail list archive ..

FYI: Re: MuP21 Programming Manual (fwd)


Re. MuP21 power burn. 20 mA at 5 V make 100 mW (about 60 mW at 3 V, 
though this might be an invalid extrapolation). If 1 mA is really 
idle (NOP loop) this makes a lot of difference: 5 mW idle vs 100 mW running.
Of course this does not involve DRAM refresh (2.5 MByte can take a lot 
juice) / cache SRAM, which at a guess, would take about twice that much. So 
this would mean roughly 200 mW for the entire board. Correct?

-- Eugene

---------- Forwarded message ----------
Date: Fri, 4 OCT 1996 19:10:28 GMT 
From: Jeff Fox <jfox@netcom.com>
Newgroups: comp.lang.forth
Subject: Re: MuP21 Programming Manual 

In article <32549922.3B82@bbs.wa4yse.ampr.org> 
 Andrew Sieber <kd4jtv@bbs.wa4yse.ampr.org> writes:
>I got my MuP21 and the Programming Manual in the mail a couple days
>ago, and I've got questions.  The manual is the third edition.

So did everyone else who read MuP21 documentation.

>The following are some inconsistencies I've seen, and I'm curious
>what the correct numbers are.  It may be that I'm simply
>misinterpreting what's in the manual; if so, somebody please let
>me know.
>100MHz reference on page 2.  (I think this one is correct- not sure.)

104 Mhz internal cpu clock (ie ~10ns instructions)

>80MHz reference on page 83. (I think this was intended to be 80 MIPS.)

80 MIPS is maximum theoretical throughput in DRAM.  (10-20 is more common)

>150MHz reference on page 85. (Perhaps this was a preliminary estimate?)

must have been preliminary.

>3 - 6V reference on page 5.
>4.5 - 5.5V reference on page 86.
>7V reference on page 93.  "Higher voltage, faster operation."

Some of the chip will work at 3V but not video (the voltages just
are not high enough to make a clean signal).  Video needs 4+    
faster operation occurs in the DRAMs as well as the P21 memory
i/o with increased voltage, but DRAMs don't recommend >5.5v.

I run P21 at 5.75 to 6.1v on my systems.

>20mA operating, 1mA idle, according to manual.
>I've read somewhere it's 50mA operating.  Which is right?

20 should be correct.

>How do you get the chip to "idle" if the clock
>is internal and can't be stopped?

thats what the NOP is for.  That is closest thing to idle.

>I also am curious about the clock used in the chip.  From what I've read
>in the programming manual, it uses an "analog clock" instead of a
>conventional diginal one.  What does this mean?  You can't run a CPU
>on sine waves, you need square waves.  The manual mentioned something
>about the analog clock allowing speedier rise/fall times, cleaner clock
>signal, etc.  It also implies that the clock runs faster when the
>voltage is higher.
>The only kind of clock schemes I can come up with for an on-chip clock
>are crystal or RC resonator circuits which turn their sine waves into
>square waves with schmitt triggers.  Perhaps I need to shut up and go
>get out a basic electronics book. :-)

No a basic electronics book won't cover what Chuck is doing in
VLSI.  Chuck is clocking things as fast as he can on chip.  This
means he designed all the internal clocking and gating circuits
.  Digital transistors are also analog transistors at this level.
To execute an instruction on his current chips the circuits must
clock through a dozen logic steps to complete a 2.5ns instruction.
Basic electronic books won't show you how to get your ciruits
clocking at .2ns.

>The memory map on page 7 designates 180000h - 1FFFFF as the sram space
>(fast and slow combined.)  This is a range of 512kB.  However, the
>next paragraph includes the statement, "As shown in the above memory
>map, only 256kB are allocated to sram" or something.  It then goes
>on to explain how to swap 4 banks of sram, each 256kB.  Am I missing
>something here?

Yes, there is a 256k window into ROM address space.  (two actually
one high speed, one low speed).  And there are two bits in the
memory configuration register that deliver two more bits of
addressing to ROM.  This gives 4 256k byte windows into ROM or
1 megabyte of ROM space but you only see 256k at a time.
P21 only addresses 1K of SRAM, (two address spaces actually
one selects slow memory one selects fast memory) and Dr. Ting's
boards use the SRAM address space as i/o decode addresses.

>On page 117, it states that you need to xor all your data and literals
>with AAAAA to counteract the hardware's peculiar odd-bit inversion.

You must do this if target compiling or metacompiling from some
system that does not have the same bus as P21.

If you compile code for a negative logic machine on a postive 
logic machine then you XOR all 16bit data with $FFFF so it looks the
right way on the other machine.  If you compile for P21 on a positive
logic machine you xor with $AAAA or with $5555 on a negative logic
(1 is 0v, 0 is 5v) type machine.

>If your data has nothing to do with addresses, then it seems to me
>that this is unnecessary.  Am I thinking correctly on this?

No.  If you write a program 1 1 +  and compile it on P21 and view
it on P21 you see 1 1 +.  If you look at it with a logic analyzer
you see AAAAB AAAAB + because P21 represents 1 with AAAAB on the
bus in hardware.  It does this xor of AAAAA in hardware on the
data and address busses but is of course transparent to P21 itself.

But if you compile 1 1 + on the pc for P21 you must represent 1 so
P21 knows its a 1.  On the PC you must xor it with AAAAA.
This is target or metacompilation issue.  It is one of the advanced
Forth topics that you are struggling with at the moment.

>Somebody had posted in this newsgroup that the MuP21 does
>one's-complement
>arithmetic.  I see no evidence of that.  Can somebody confirm or deny?
>It looks to me that if I add 00001 to FFFFE, I get FFFFF, which is not
>what a one's complement adder would do, unless I'm totally messed up
>in the head (I did only get three hours sleep last night, so I may be.)

Very good.  You are right about this.  Although people have stated here
that P21 is one's-complement this is because people have heard
Chuck say "he uses it his way."  

It is in fact twos complement.

There is some confusion however because it has a 20 bit memory bus
and a 21 bit alu.

If you look at 21 bit numbers you get

0-FFFFF as positives and 100000-1FFFFF as negative.  -1 is 1FFFFF
and if you add 1 you get 0 etc.

if you look at 20 bit numbers then 0-7FFFF postive   and 80000-FFFFF
as negative.   -1 (FFFFF) + 1 is 0.

Because of carry only move 8 bits per instruction time a + or +*
can require more than one cycle.  To save a fraction of a cycle
Chuck uses left justified numbers for counters so for 1000h iterations
he will say F0000 then add 10h 1000h times to get overflow to 21bits.
His explanations of his left justfied math has lead to people thinking
P21 is one's-complement.

>On page 100, in gives on of Chuck Moore's talks.  He states that "last
>night I designed my latest keyboard, which I will tell you about some
>other time."  His thumb-ring keyboard he described in the talk seemed
>pretty neat- does anybody happen to recall if he's described his
>"latest"
>(as of the 1991 talk) keyboard?

He has done many.  He uses a pc keyboard today, but only uses 7 keys
most of the time in OKAD.  He has added a Forth to OKAD so it
can interpret from the keyboard in a pretty conventional fashion.

>On page 104, he says, "In fact, I'm designing my own language today."
>He says Forth programmers would hate it.  Has he said anything more
>about
>it?  Is OK what he was talking about?  If it's OK, _I'm_ not hostile to
>it, and I can program in Forth.
>
>If anybody can help answer the above, I'd really appreciate it.
>
>--Andrew Sieber
>kd4jtv@bbs.wa4yse.ampr.org

No he is not talking about OK.  Although OK explored some of his
ideas about this.

He often talks about a stripped down Forth.  Chuck thinks that ANS
Forth resulted in a very confusing thing.  Chuck likes simplicity.
In my opinion the closest thing that he has published to his
latest ideas about his current language is the F21 instruction set,
or his assembler for MuP21.

He likes -IF and -UNTIL which use carry instead of 0.  And IF and
UNTIL don't remove arguments like normal Forth.  He doesn't need
a lot of stack space or most of the stuff added to Forth over
the last twenty years.

As he once said, "What you take away is more important than what
you add."

Jeff Fox