Searching \ for '[EE]: More advanced system design..' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=more+advanced+system
Search entire site for: 'More advanced system design..'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: More advanced system design..'
2002\08\19@073629 by Kieren Johnstone

picon face
Hi,
I keep wondering how more advanced mainboards work, in handheld systems for example - my main question is, what sort of physical structure does the "data bus" have, and how (for example) would you define which device on the system has which memory range.  For example, the Cybiko handheld games system; the LCD controller is accessible at one memory range, the RAM chip at another, the ROM at yet another.  The expansion port has yet its own range.  What about I/O ports (such as on x86 architecture)?

Thanks,
Kieren Johnstone

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\08\19@075722 by Olin Lathrop

face picon face
>>
I keep wondering how more advanced mainboards work, in handheld systems for
example - my main question is, what sort of physical structure does the
"data bus" have, and how (for example) would you define which device on the
system has which memory range.  For example, the Cybiko handheld games
system; the LCD controller is accessible at one memory range, the RAM chip
at another, the ROM at yet another.  The expansion port has yet its own
range.  What about I/O ports (such as on x86 architecture)?
<<

There are two main ways of doing I/O with a processor.

On some processors, like the x86 family, there are special instructions like
IN and OUT that explicitly perform I/O.  The bus cycles caused by these
instructions have a dedicated line that becomes true that indicates this is
an I/O reference.  I/O hardware has to check this line and decode a
relatively small number of address lines to decide if that bus cycle is for
it.  The x86 uses 16 address lines for I/O, and therefore has 65536 possilbe
I/O locations.  Since these "addresses" are only used for I/O, the system
designers can chose to ignore some of the upper bits if they don't use 65K
I/O registers.  Most PC systems decoded only the low 10 or 12 bits.  Address
8012h is therefore the same as 0012h, but nobody uses 8012h.

On other processors, there are no special I/O instructions or bus cycles,
but the external memory address space is large enough so there is always
"extra" room beyond the physical memory.  I/O devices then respond as if
they were ordinary memory at addresses where there is no real memory.  This
can simplify a bunch of thing inside the processor, but each I/O device now
has to pay attention to more bus signals and address lines.  Since the total
address space (used for memory or I/O) is much larger than a traditional I/O
space, devices can map entire buffers or whatever into memory space.
Graphics cards commonly do this.

There are other issues, but this is the basic concept.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\08\19@081336 by Kieren Johnstone

picon face
I was really enquiring about the memory access methods too... am I then to
understand it works like this?:

* Each device is hooked onto the address/data bus lines from the CPU
* When the device recognises an address in it's range on these lines, it
performs a read (and puts the data on the data bus) or write (data bus ->
internal register / RAM / etc)

If this is so, how easy would it be to attach say any old parallel EEPROM?
How would you assign it an address range?  Would you recognise an
appropriate pattern in the 8 upper bits, if it was correct for the EEPROM,
feed the bus lines to the EEPROM (use the lower 24 bits of the address bus
to specify the address for the EEPROM access)?

-Kieren

{Original Message removed}

2002\08\19@094235 by Olin Lathrop

face picon face
> * Each device is hooked onto the address/data bus lines from the CPU
> * When the device recognises an address in it's range on these lines, it
> performs a read (and puts the data on the data bus) or write (data bus ->
> internal register / RAM / etc)

That's the basics.

> If this is so, how easy would it be to attach say any old parallel EEPROM?
> How would you assign it an address range?  Would you recognise an
> appropriate pattern in the 8 upper bits, if it was correct for the EEPROM,
> feed the bus lines to the EEPROM (use the lower 24 bits of the address bus
> to specify the address for the EEPROM access)?

Basically yes.  There are usually a few more bus details like timing and
handshaking.  Also, you are asking for a 16Mb address window.  You have to
make sure no other device responds to any address with the same combination
of high 8 bits.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\08\19@111216 by Sergio Masci

picon face
----- Original Message -----
From: Kieren Johnstone <.....misterfugitKILLspamspam.....HOTMAIL.COM>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Monday, August 19, 2002 1:05 PM
Subject: Re: [EE]: More advanced system design..


{Quote hidden}

Actually each device has one or more chip enable inputs allong with its
address inputs. The address inputs allow it to decode and respond to an
address in the range 0 to N (where N might be 255 for a device which has 8
address lines). So if you put together 8 such devices they would all respond
to the same addresses (0 to 255). This is where the chip enable inputs come
in. You would (in this example) take address lines 8, 9 and 10 to another
chip (glue logic) that would convert these 3 address lines into 8 chip
enables. Each of these chip enables would be tied to a seperate device. The
address lines 0 to 7 would be connected to all 8 of the devices. Each device
would then only respond to its own allocated address range e.g.
000 0000 0000 to 000 ffff ffff for device 0
001 0000 0000 to 001 ffff ffff for device 1
010 0000 0000 to 010 ffff ffff for device 2
011 0000 0000 to 011 ffff ffff for device 3
101 0000 0000 to 101 ffff ffff for device 5
etc

Some times this is complicated by the fact that a device actually responds
to a larger number of address bits than it has address lines. This is
achived by stobing the address into the device in chunks.

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\08\19@132753 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What no one has mentioned (surprisingly) is that you have to be
careful with the bus width.  For example, hooking up an old EPROM to
a PC bus.  Old EPROMS are, in general, 8-bit devices.

Modern (PC) CPUs are, in general, 32-bit devices (except for the
64-bit parts that are still under the final stages of development,
and the ancient 16-bit devices).

This gives you 2 options: 1) use tie the remaining bits beyond those
used by the EPROM low, when the address is valid, and 2) use 4 ganged
EPROMS all with the same enable circuit.

Well, you could probably work out some other options, but those are
the simplest, by far.  How were you planning to implement this?  Old
ISA bus?  PCI bus?  If either of those, you don't need to worry too
much about the PC bus structure, but instead about the spec for the
particular bus that you'll use.

If, on the other hand, you're simply interested in learning about
busses, here's what I know of them (though I'm probably just
reiterating what's been said):

Busses are, in general, parallel in format.  They are composed of two
seperate busses, the address bus, and the data bus, which are
sometimes multiplexed by the use of control lines (ALE(adress latch
enable) WR(write) RD(read) are the common control lines).  If the
busses are not multiplexed, the WR and RD lines are still needed, but
the ALE can be implied.  There is no clock, in general, instead,
everything is controlled by the edges of the WR, RD, and ALE lines.

If you're attaching a device to the address bus, a multiplexer IC and
some inverters can be used as an easy way to decode the address bus
into an enable signal for the target device.  A multiplexer can be
used as a sort of a boolean function generator.  If you want more
info on that, it's probably somewhere on the web, but if you can't
find it, ask me, or the list.

In this way, busses are actually pretty simple in concept.  The
process is pretty much as follows for at least one kind of
multiplexed bus

1) address goes on bus
2)ALE signals address is valid
3)the target device reads the address
4)the address is removed from the bus on the opposite edge of ALE
5)WR or RD indicates which device writes to the bus
(WR and RD can be combined into a single signal through use of the
ALE edge, but this can be somewhat more complex)
6)The data appears on the bus
7)on the opposite edge of WR and RD, the data is read by the
appropriate device, and removed from the bus

I think that pretty much covers one scheme for bus interfacing,
though there are several.  There are likely many good books and much
online information available regarding bus type devices.  I suggest
looking into other information sources if you want to know more.

Feel free to correct me, anyone, though I think I've got things
pretty accurate here.

Regards,

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWEqxQVk8xtQuK+BEQIqAACgv+a9nDJuheh3XaSTMzK4y5Ik/p4An3BW
zWwsh2XFRyNA4S1Dz4sXBm0B
=9t6m
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\08\19@141231 by Harold M Hallikainen

picon face
       I really don't see any advantage to a separate I/O map over use of
memory mapped I/O. The Io/M pin on processor with a separate I/O could be
replaced with one more address line, doubling the size of the memory map.
The use of a separate I/O map requires the processor to have special I/O
instructions. These instructions are always limited when compared with
instructions that operate on memory. So, by using memory mapped I/O, we
get a simpler processor and more powerful instrucions for use on I/O.
       It is true that more bits need to be decoded when using memory mapped
I/O. In simple systems, you might just take the most significant address
line and say that in one state it's talking to memory, in the other it's
talking to I/O. I've typically used a bipolar PROM or a PLD to decode the
address lines into chip selects. One device could generate chip selects
to the memory devices and an I/O chip select. A second device could
further decode the I/O area down to each device.
       I first learned of memory mapped I/O when moving from the DEC PDP-8 to
the PDP-11. I thought memory mapped I/O was a very clever idea then.
Still do!

Harold



FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

Reach broadcasters, engineers, manufacturers, compliance labs, and
attorneys.
Advertise at http://www.hallikainen.com/FccRules/ .


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\08\19@145031 by Sergio Masci

picon face
----- Original Message -----
From: Harold M Hallikainen <RemoveMEharoldhallikainenTakeThisOuTspamJUNO.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Monday, August 19, 2002 6:37 PM
Subject: Re: [EE]: More advanced system design..


>         I really don't see any advantage to a separate I/O map over use of
> memory mapped I/O. The Io/M pin on processor with a separate I/O could be
> replaced with one more address line, doubling the size of the memory map.
> The use of a separate I/O map requires the processor to have special I/O
> instructions. These instructions are always limited when compared with
> instructions that operate on memory. So, by using memory mapped I/O, we
> get a simpler processor and more powerful instrucions for use on I/O.
>         It is true that more bits need to be decoded when using memory
mapped
> I/O. In simple systems, you might just take the most significant address
> line and say that in one state it's talking to memory, in the other it's
> talking to I/O. I've typically used a bipolar PROM or a PLD to decode the
> address lines into chip selects. One device could generate chip selects
> to the memory devices and an I/O chip select. A second device could
> further decode the I/O area down to each device.
>         I first learned of memory mapped I/O when moving from the DEC
PDP-8 to
> the PDP-11. I thought memory mapped I/O was a very clever idea then.
> Still do!
>
> Harold
>

Well that's one way to look at it. Another is that you can use the I/O line
to tell the rest of the hardware that you are about to use the address bus
in some special way. It can also help with slow periperal chip timings.
Actually there is a very good reason to have special instructions for I/O
which are distinct from normal memory accesses. They let the CPU know when
the access is to a periperal chip. With a little extra hardware (in the CPU)
you can distinquish between user and supervisor modes and trap a runaway
user program that has crashed and is trying to execute data which happens to
be a write to a periperal chip. And all without a complex MMU and
sophisticated runtime executive.

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2002\08\19@150658 by Jim

flavicon
face
  "I really don't see any advantage to a
   separate I/O map over use of memory
   mapped I/O."

Simple "byte" I/O, perhaps not.

But consider that a separate I/O instruction actually
translates (maps), in effect, an address to "hardware"
via an additional processor output pin that in effect
"decodes" those I/O instructions and therefore does not
require the designer to provide additional hardware to
decode an address from memory space - for a small
system it saves hardware decode logic that would
otherwise be required ...

Such direct connection "support" IC's such as the Z80
SIO, PIO, CTC chips were I/O devices that were addressed
via I/O instructions, all these are all capable of
interrupting and supplying the lower portion of an
interrupt service address during interrupt service ...
through the use of an "I/O" instruction no additional
address decode off the address bus is required.

RF Jim

{Original Message removed}

2002\08\19@162102 by Olin Lathrop

face picon face
>         I really don't see any advantage to a separate I/O map over use of
> memory mapped I/O.

It is pointless to debate this here.  Both methods have their pros and cons.
Many processor designers have done what you suggest, partly for the reasons
you state.  On the other hand, many others have done it the other way, also
for good reasons.  Notice that I'm not giving arguments for either because
that kind of pissing match is a waste of time.  I'm just pointing out that
many people who spent their careers designing processors have chosen both
methods.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2002\08\21@161922 by Peter L. Peres

picon face
On Mon, 19 Aug 2002, Harold M Hallikainen wrote:

>        I really don't see any advantage to a separate I/O map over use of
>memory mapped I/O. The Io/M pin on processor with a separate I/O could be
>replaced with one more address line, doubling the size of the memory map.
>The use of a separate I/O map requires the processor to have special I/O
>instructions. These instructions are always limited when compared with

Afaik the idea was to have separate instructions so they could add wait
states for them. F.ex. all Intel CPUs since 8080 have slower IO
instructions than memory access instructions. This cannot be a
coincidence.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...