I am writing a device driver as well as diagnostic software for PCI card, wich is capable
of PCI burst transfers – it is not a bus muster.
How does one explicitly force PCI burst transfers?
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
One uses READ/WRITE_REGISTER_BUFFER_UCHAR/SHORT/LONG and let the HAL do
the right thing.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Richaed Sliwinski
Sent: Thursday, September 13, 2001 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
The hardware will take care of it provided you send data to consecutive
addresses at the right speed, and provided no other transfer interlopes
within your intended burst. For example, many video boards can take control
streams through DMA, and they can handle all controls written to a single
address, but they also map their control port(s) to a largish contiguous
space to allow the driver writer to exploit bursting by DMAing data to
consecutive addresses. Note that bus reads will break your burst. Also
remember you’re not alone on the bus, someone else’s activity may break your
burst. And if you don’t supply data fast enough the bursts will be broken.
The best way to look at it is, get yourself a logic analyzer and put it in
the PCI bus, and look at the traces, you’ll see how much you’re bursting,
and how long your bursts typically are; you can write a small program to
test your bursting capability, and go from there.
Hope this helps!
Alberto.
-----Original Message-----
From: Richaed Sliwinski [mailto:xxxxx@interlog.com]
Sent: Thursday, September 13, 2001 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Not in a diagnostic program, no, that’s not acceptable! In the device driver
maybe it’s ok to punt to authority, although I myself would doubt that
Microsoft and their HAL know my hardware better than I do. If nothing else,
when everything fails I can walk down the hall and talk to the chip
designer. I personally feel like bypassing is almost always better than
comply, but hey, there may be more than one way to skin this cat.
Incidentally, one more thing I’d suggest: write the diagnostic first, and
make sure to modularize your hardware level i/o so that you can reuse the
routines in the driver.
Alberto.
-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Thursday, September 13, 2001 7:58 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Burst PCI target read/write transfers.
One uses READ/WRITE_REGISTER_BUFFER_UCHAR/SHORT/LONG and let the HAL do the
right thing.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Richaed Sliwinski
Sent: Thursday, September 13, 2001 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Burst PCI target read/write transfers is a function of the CPU’s
north-bridge chipset. There really isn’t a special opcode in the x86
instruction set to signal such a read, so it would be up to the north-bridge
to somehow combine the reads and produce the right request. So far, Intel
has not supported anything like this.
On the other hand, you can usually get short *write* bursts using the CPU,
if you have write-combining turned on in the north-bridge chipset. The rule
of thumb for PCI burst transfers, is that the source of the data must master
the bus. So, if you wish to burst data from a board into the CPU memory, you
cannot use the CPU to do reads.
It will be terribly inefficient. The best you will be able to do will be
word-size reads, with lots of bus protocol overhead. If you master the bus
with the board that has the data to send, then you can do burst *writes*
into the north-bridge chipset.
All modern north-bridges support this, but the maximum burst length varies.
It is usually the cache-line length of the memory interface behind the
north-bridge, so it may
be only 16 or 32 bytes, or some other small number.
This means that no matter what, you won’t be able to achieve that nirvana of
PCI bus speed, 132 MBytes/sec. Also, there is always CPU contention for the
memory behind the north-bridge, which always gets top priority over incoming
PCI bus transfers. Realistically, I’ve seen maximum 80 MByte/sec transfers,
and that was only obtained by using bus mastering data sources.
One uses READ/WRITE_REGISTER_BUFFER_UCHAR/SHORT/LONG and let the HAL do the
right thing.
In this case a simple memory read (MR) occurs. So you need a hardware
decision, develop your own PCI controller that will master the bus.
Regards,
Max
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Friday, September 14, 2001 6:29 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Burst PCI target read/write transfers.
Not in a diagnostic program, no, that’s not acceptable! In the device driver
maybe it’s ok to punt to authority, although I myself would doubt that
Microsoft and their HAL know my hardware better than I do. If nothing else,
when everything fails I can walk down the hall and talk to the chip
designer. I personally feel like bypassing is almost always better than
comply, but hey, there may be more than one way to skin this cat.
Incidentally, one more thing I’d suggest: write the diagnostic first, and
make sure to modularize your hardware level i/o so that you can reuse the
routines in the driver.
Alberto.
-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Thursday, September 13, 2001 7:58 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Burst PCI target read/write transfers.
One uses READ/WRITE_REGISTER_BUFFER_UCHAR/SHORT/LONG and let the HAL do the
right thing.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Richaed Sliwinski
Sent: Thursday, September 13, 2001 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@acronis.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Looks like this is a northbridge-dependent feature, and I don’t think you can control it.
Max
----- Original Message -----
From: Richaed Sliwinski
To: NT Developers Interest List
Sent: Friday, September 14, 2001 1:20 AM
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You can make bursting more likely, especially on writes. If you are trying to maximize throughput to
memory mapped addresses,
ideally you want to enable the CPU cache, if your device is cache-coherant, then use the newer MMX
instructions to write cache lines at a time to the PCI bus, or read cache lines with prefetch.
If you can’t enable the cache, you want to turn on write-combining for the address range. With a P3
you can get up to 4 cache lines in flight at a time, I think this is 8 on the P4. The chipset will
try to do write combining based on what is outstanding, giving reasonable bursts (hopefully).
I’ve heard of tests where writes from P3’s had sustained transfers of 180MB/sec, but I forget the chipset.
The read performance was more like 20-30MB/sec.
if you are trying to really transfer anything valuely close to those rates, get the hardware redesigned to be a bus master.
-DH
----- Original Message -----
From: Maxim S. Shatskih
To: NT Developers Interest List
Sent: Saturday, September 15, 2001 12:01 PM
Subject: [ntdev] Re: Burst PCI target read/write transfers.
Looks like this is a northbridge-dependent feature, and I don’t think you can control it.
Max
----- Original Message -----
From: Richaed Sliwinski
To: NT Developers Interest List
Sent: Friday, September 14, 2001 1:20 AM
Subject: [ntdev] Burst PCI target read/write transfers.
You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Thanks from the bottom of my heart to everyone that replied.
THE ORIGINAL QUESTION:
I am writing a device driver as well as diagnostic software for PCI card, wich is capable
of PCI burst transfers – it is not a bus muster.
How does one explicitly force PCI burst transfers?
TO SUMMARIZE:
OPTION ONE.
Burst transfer using the System (Slave) DMA to PCI target device.
Doesn’t work, due to the fact that the System (Slave) DMA supports only transfers to ISA bus.
OPTION TWO.
Burst transfer using READ_REGISTER_BUFFER.
Doesn’t work. On a logic analyzer I can view only series of single transfers.
Apparently the north-bridge is responsible for producing PCI target
read burst transfers. So far Intel has not supported anything like this.
SOLUTION:
The PCI controller that will master the bus.
This is the only “clean” solution to force explicitly PCI burst transfers.
Thanks again to all that replied.
Richard Sliwinski
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Option Two can possibly work - if the north bridge is set up properly.
It is allowed to do write combining by the PCI spec.
Max
----- Original Message -----
From: Richaed Sliwinski
To: NT Developers Interest List
Sent: Friday, October 12, 2001 7:22 PM
Subject: [ntdev] Burst PCI target read/write transfers.
Thanks from the bottom of my heart to everyone that replied.
THE ORIGINAL QUESTION:
I am writing a device driver as well as diagnostic software for PCI card, wich is capable
of PCI burst transfers – it is not a bus muster.
How does one explicitly force PCI burst transfers?
TO SUMMARIZE:
OPTION ONE.
Burst transfer using the System (Slave) DMA to PCI target device.
Doesn’t work, due to the fact that the System (Slave) DMA supports only transfers to ISA bus.
OPTION TWO.
Burst transfer using READ_REGISTER_BUFFER.
Doesn’t work. On a logic analyzer I can view only series of single transfers.
Apparently the north-bridge is responsible for producing PCI target
read burst transfers. So far Intel has not supported anything like this.
SOLUTION:
The PCI controller that will master the bus.
This is the only “clean” solution to force explicitly PCI burst transfers.
Thanks again to all that replied.
Richard Sliwinski
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com