Re: bits, timings, mem maps, etc.

[Andrew Sieber <kd4jtv@xxxxxxxxxxxxxxxxxxx>]

Christophe Lavarenne wrote:
>> If I were to add inverters to the odd address pins and two-way inverters
>> to the odd data pins, then would ALL of the inversion mess go away?
>
>Yes, but then the odd pins would be slower, and therefore all the chip would be
>slower. Why pay continuously at runtime what you can do once at compile time?

I was only suggesting inverters as a way of asking a question.  I wanted
to
make sure I understood what was going on with the inversions MuP21 does.
Of course I would not use inverters in an actual circuit, as it would
be a waste of inverter chips and potential MuP21 speed.
Thanks for your explanation.
I also just checked my mail and found Jeff's response to this question,
so
I say again, I am _not_ planning to actually implement a circuit using
inverters, even if I could get it to work.  I was merely trying to
understand
exactly what the chip does.  Anything to make the chip go faster is
great,
and I'll not sacrifice those gains by putting inverter chips on the
processor.
And yes, of course negative logic is just as good as positive logic, and
so
is interleaved logic.  Whatever makes the chip go fast.
>> If I use the fast I/O space for 15ns sram hookup, and run a program out of it
>> (I know the program would have to be <1k), will the program run faster, since
>> it does not have to access relatively slow dram?
>
>Instructions and data fetches from fast RAM will be faster, but data fetches
>from DRAM, slow I/O or byte memory spaces will still have their corresponding
>timings, because the MuP21's memory timing generator is driven by the address
>decoder, which also drives the different chip selects.

Since even with a long string of single-cycle/instruction stack
operations,
the processor must still load operands from memory every fifth cycle, it
seems to me that even with 15 PICOsecond sram chips the processor would
still only run at 80 MIPS.  It must always waste every fifth cycle
accessing memory and not executing an instruction.  Beyond a certain
point,
making the sram faster won't do anything for the processor's speed.
Is my logic correct here?

Eugene Leitl wrote:
>In http://pisa.rockefeller.edu:8080/MISC/latest/8 Jeff has written:
>"You are quite right about performance.  Even though the video processor uses
>only 25% of the memory bandwidth directly there is a parasitic effect due to
>off page memory access.  When both the cpu and the video processor are
>running on different pages of DRAM then each video processor memory access
>will be offpage and will force the next cpu memory access to be offpage too!
>Thus under these conditions the cpu only gets 1/3 of the bandwidth, not
>3/4."

This indicates one advantage of putting your <1k program in 15ns sram
on the I/O area, because assuming you only access the dram relatively
infrequently for video buffer updates, the video coprocessor can have
control over the dram while the CPU accesses only the I/O space
for its program.  Then the dram would change pages less often, and
everything would run faster.

Joe Zott wrote:
>Currently we are expanding our development staff so if you are interested
>or know of someone who is interested please have them send me a resume. We
>need software developers (all levels), testers, system administrators, IC
>designers, etc.

Bad timing!  Can you hold off your hiring until, say, Spring of 2001?
(That's when I graduate from college.)  :-)

Eugene Leitl wrote:

>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).

Power varies with the square of the voltage.  If the chip takes 20mA
at 5V, then 100mW is correct, but 60mW at 3V is not.  At 3V, the chip
would consume 36mW, because the current would be 12mA.  Of course,
this assumes that the chip has a relatively constant impedance of
250 ohms, and I don't know whether or not it does.
If I weren't as lazy as I am, I'd get out a meter and measure the
current at these two voltage levels. :-)

I have been confused about the paging schemes for I/O and ROM, and I
think a lightbulb just went off.  I'd like to make sure I understand it
correctly:
There are two 1k address spaces for I/O.  They both map to the same
physical bit patterns on the MuP21's address lines, and externally
the only difference between addressing one I/O space or the other
is the speed of the bus transaction.
Similarly, with the ROM, there are two 256k address spaces designated
for ROM.  Assuming the same ROM page is selected by the configuration
register, an access to the fast and to the slow rom spaces yield
exactly the same addresses on the MuP21's address pins, and the
only difference between the two rom address spaces is the speed of
the transaction.  So when the program selects a rom address, bits
19 and 20 state that rom space is going to be used, and the
configuration register specifies what actually appears on address
pins 18 and 19.  Bits 0-17 map directly to the address pins, and
bit 18 specifies whether the transaction will be fast or slow.
Is all of this correct?

What are the differences between the fast.rom and the slow.rom
ROM image files for P21Forth?  I have not purchased a development
board from Offete, nor do I plan to.  I'm building my own on a
breadboard (I sure hope I don't have timing problems with those
relatively long wires!) and am modelling it after schematics
in the Manual.

Thanks in advance for help.

--Andrew Sieber
kd4jtv@bbs.wa4yse.ampr.org