Help with ISA, IO Port interface
Sean
Xilinx FPGA and need to build ISA ports into the FPGA in VHDL.
Therefore, some confusion I'm having about ISA is making it difficult
for me to make these ports. If anyone could help I'd be grateful.
I need to be able to read 16-bit values into the PC via the ISA/PC-104
bus. I had been told that since the ISA bus (in later versions
anyway) supports 16-bits that I could access full 16-bit words through
single ports. This would be done because the system would drive the
!BHE signal low (Byte High Enable signal, which is active low) and
that would indicate a transfer on the upper 8 bits of the bus
(D8-D15).
However, in the software end of things the functions we're using to
pass data out of the PC through the IO ports (and read data from the
ports) seems to be saying that it is breaking the 16-bit words into
two bytes and sending one byte through one port and another byte
through another port. It seems to be doing this rather than using one
port and enabling !BHE to do a single 16-bit transfer. I'm using the
older Borland Turbo C++ compiler and the outport and inport (really
just the inport, but the outport has the same situation) functions in
dos.h and conio.h.
So say I did this:
unsigned char value;
value = 23;
outport(0x300, value);
My impression was that the full 16-bit "value" would be pushed over
the 0x300 port. However, the help menu in borland seems to say one
byte of those 16-bits goes through 0x300, while the other byte
actually goes through 0x301.
If I changed the outport command to an input like this:
value = inport(0x300)
I was again under the impression that a full 16-bit value was coming
through port 0x300. Instead, Borland seems to say that one byte comes
from port 0x300 and another comes from 0x302. (why would the input
skip "over" a port number for a transfer?? seems odd to me).
So do these function actually do only one transfer through one port,
or are they really "extrapolated" into assembly instruction that do
two consecutive port transfers, one for the high byte and one for the
low byte? The reason I need to know is when I build my ISA ports in
VHDL I need to know whether to make them support 16-bits (if these
functions output all 16-bits via one port) or if I just need to build
a single 8-bit port and use two of them for each connection I need to
the PC (one for the high byte and one for the low byte)? Thanks all.
Jack Klein
comp.lang.c++:
> My problem has to do with the fact that I'm interfacing a PC with a
> Xilinx FPGA and need to build ISA ports into the FPGA in VHDL.
> Therefore, some confusion I'm having about ISA is making it difficult
> for me to make these ports. If anyone could help I'd be grateful.
You're probably asking in the wrong place, as C++ knows nothing at all
about ISA or ports or any hardware device at all. All input and
output is defined in terms of high level streams, not in terms of
hardware devices or memory addresses.
> I need to be able to read 16-bit values into the PC via the ISA/PC-104
> bus. I had been told that since the ISA bus (in later versions
> anyway) supports 16-bits that I could access full 16-bit words through
> single ports. This would be done because the system would drive the
> !BHE signal low (Byte High Enable signal, which is active low) and
> that would indicate a transfer on the upper 8 bits of the bus
> (D8-D15).
>
> However, in the software end of things the functions we're using to
> pass data out of the PC through the IO ports (and read data from the
> ports) seems to be saying that it is breaking the 16-bit words into
> two bytes and sending one byte through one port and another byte
> through another port. It seems to be doing this rather than using one
> port and enabling !BHE to do a single 16-bit transfer. I'm using the
> older Borland Turbo C++ compiler and the outport and inport (really
> just the inport, but the outport has the same situation) functions in
> dos.h and conio.h.
The functions and headers that you refer to above are not, and never
have been, part of either the C or C++ language. They are
non-standard compiler specific extensions, and off-topic here.
> So say I did this:
>
> unsigned char value;
> value = 23;
> outport(0x300, value);
>
> My impression was that the full 16-bit "value" would be pushed over
> the 0x300 port. However, the help menu in borland seems to say one
> byte of those 16-bits goes through 0x300, while the other byte
> actually goes through 0x301.
>
> If I changed the outport command to an input like this:
>
> value = inport(0x300)
>
> I was again under the impression that a full 16-bit value was coming
> through port 0x300. Instead, Borland seems to say that one byte comes
> from port 0x300 and another comes from 0x302. (why would the input
> skip "over" a port number for a transfer?? seems odd to me).
>
> So do these function actually do only one transfer through one port,
> or are they really "extrapolated" into assembly instruction that do
> two consecutive port transfers, one for the high byte and one for the
> low byte? The reason I need to know is when I build my ISA ports in
> VHDL I need to know whether to make them support 16-bits (if these
> functions output all 16-bits via one port) or if I just need to build
> a single 8-bit port and use two of them for each connection I need to
> the PC (one for the high byte and one for the low byte)? Thanks all.
<completely off-topic>
If you want to see what instructions the compiler generates for these
non-standard functions, look at the assembly language output or
disassemble the object code for the function itself. Then read an
Intel data book to see what the processor does with those instructions
(download for free at http://developer.intel.com).
If you want to see what sort of bus cycles these instructions result
in on your particular hardware platform, get out a scope or logic
analyzer and look at the address, data, and control lines.
But the operation of the ISA bus (or any other bus) is not defined at
all by the C++ language.
</completely off-topic>
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
John Harrison
"Sean" <creo...@yahoo.com> wrote in message
news:b97bab2f.02040...@posting.google.com...
> My problem has to do with the fact that I'm interfacing a PC with a
> Xilinx FPGA and need to build ISA ports into the FPGA in VHDL.
> Therefore, some confusion I'm having about ISA is making it difficult
> for me to make these ports. If anyone could help I'd be grateful.
>
[snip]
Your problem appears to have nothing at all to do with C++. Please ask on a
hardware programming group, you are off topic here.
john
Alexander Terekhov
Jack Klein wrote:
[...]
> If you want to see what instructions the compiler generates for these
> non-standard functions, look at the assembly language output or
> disassemble the object code for the function itself. Then read an
> Intel data book to see what the processor does with those instructions
> (download for free at http://developer.intel.com).
Right, for example:
http://www.intel.com/design/Pentium4/manuals/24547006.pdf
"IA-32 IntelŽ Architecture
Software Developer's
Manual
Volume 1:
Basic Architecture
....
12.1. I/O PORT ADDRESSING
The processor permits applications to access I/O
ports in either of two ways:
- Through a separate I/O address space.
- Through memory-mapped I/O.
Accessing I/O ports through the I/O address space
is handled through a set of I/O instructions and
a special I/O protection mechanism. Accessing I/O
ports through memory-mapped I/O is handled with
the processors general-purpose move and string
instructions, with protection provided through
segmentation or paging. I/O ports can be mapped
so that they appear in the I/O address space or
the physical-memory address space (memory mapped
I/O) or both.
....
12.3.1. Memory-Mapped I/O
I/O devices that respond like memory components
can be accessed through the processor's physical-
memory address space (see Figure 12-1). When using
memory-mapped I/O, any of the processor's instructions
that reference memory can be used to access an I/O
port located at a physical-memory address. For example,
the MOV instruction can transfer data between any
register and a memory-mapped I/O port. The AND, OR,
and TEST instructions may be used to manipulate bits
in the control and status registers of a memory-mapped
peripheral devices. When using memory-mapped I/O,
caching of the address space mapped for I/O operations
must be prevented. With the Pentium 4, Intel Xeon,
and P6 family processors, caching of I/O accesses
can be prevented by using memory type range registers
(MTRRs) to map the address space used for the memory-
mapped I/O as uncacheable (UC). See Chapter 9, Memory
Cache Control, in the IA-32 Intel Architecture Software
Developer's Manual, Volume 3, for a complete discussion
of the MTRRs.
The Pentium and Intel486 processors do not support
MTRRs. Instead, they provide the KEN# pin, which when
held inactive (high) prevents caching of all addresses
sent out on the system bus. To use this pin, external
address decoding logic is required to block caching
in specific address spaces."
And what does our lovely Microsoft say?
"...The volatile type specifier can be used...
...or by special hardware such as memory-mapped
I/O control registers".
Gee! But that's pretty much the same[1] that is
required/intended by the C/C++ *standard* writers
(including "footnotes" and C-Rationale volume).
Ouch, but that's definitely off-topic here. Well...
sorry for the "off-topic" stuff then.
regards,
alexander.
[1]
http://groups.google.com/groups?threadm=a8hgtr%24euj%241%40news.hccnet.nl