• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 1086 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TI PCI1520 transfer speed problem to CF Card in PIO/ATA Mode

Tom Evans
Prodigy 170 points
Other Parts Discussed in Thread: PCI1520

We have a design based on an MPC5200. We have two TI PCI1520 chips connected to its 33MHz PCI bus.

One PCI1520 connects to two PCMCIA slots we use for device expansion, and the other connects to two Compact FLASH sockets for storage.

We're running Linux, and it comes with all the appropriate drivers for this hardware.

The problem is that we can't seem to get the PCI1520 to perform the PIO Reads and Writes at any speed faster than 1MHz, which limits our raw transfer speed to a rather poor 2MB/sec. A raw "dd" from the CF to /dev/null peaks at 1.7MB/s, and file reads over Ethernet peak at 1.4MB/s The CF cards can sustain 6MB/s, and we'd like to get closer to that if we can.

The Compact Flash card is being run in 16-bit PIO mode. We have a minor suspicion that the PCI1520 might be able to run a bit faster in Memory Mode, but our drivers don't support that (and the only data sheet difference we can find is the 150ns vs 210ns read signal width). Where it is running slow doesn't seem to be due to the bus cycle active period though.

We have the PCI1520 programmed to the fastest IO speeds we can find. An Oscilloscope shows IORDY going low for about 220us and then remaining high for 800us. That proves the CF card isn't slowing things down by inserting any wait states. I would have expected that the IO cycles should be able to be closer together than this.

Meanwhile, on the PCI side of the bus, the PCI1520 is obeying the rules and "giving up" after 16 PCI bus cycles, forcing the PCI master to retry. This is called a "Delayed Transaction". The following trace shows the CF/PCMCIA "IORDY" in Yellow and the PCI "DEVSEL" signal in Blue. At the top of the picture can be seen the 256-word bursts as the CD disk sectors are being read, and the gaps between them.

It looks like the state machine in the PCI1520 is taking a while to start the PIO cycle, and can't get the data read in less than the 16 clocks (500us) at which point it is required to force a "Delayed Transaction". This then wastes another 200-400us or so while the PCI bus retries and then runs the next cycle.

If there was an option to change the PCI standard

Does anyone know if there's anything simple we can do to get the performance up? I realize that for the best performance we should be using the chip as a CardBus Bridge (capable of 66MB/s or whatever) but our hardware was finalised over 4 years ago and we have units in the field.

Thanks,

 

  • 0
    Prodigy 170 points

    I wrote:

    > If there was an option to change the PCI standard

    I meant to write:

    If there was an option to change the PCI standard so the "Retry" time could be changed and the "Delayed Transaction" avoided then it might help the timing.

    Inspection of the PCI1520 Data manual found the following:

    4.34 Diagnostic Register

    Diagnostic RETRY_DIS. Delayed transaction disable.

    Diagnostic RETRY_EXT. Extends the latency from 16 to 64.

    I'm now writing to the Diagnostic Register and it does prevent the "Delayed Transaction". It hasn't changed the resulting timing at all though. Each cycle ends at pretty much the exact same point that it does with the retry in the middle, and it doesn't then start any earlier. Each transaction is taking about a microsecond as shown in this trace:

    It is taking about 400us from DEVSEL (which indicates the start of a PCI cycle) to IORDY, which takes another 200us. Then there's another 200us before the PCI cycle is completed, even though the data is available at the end of the IORDY. Our PCI master is then taking another 200us before staring the next cycle. All up about 1000us per transaction.

    The following URL has a table that indicates that PIO-0 should be able to manage 3.3MB/s, but I don't know if there's anything in PCMCIA/CF that should prevent that sort of speed

    http://www.pixelbeat.org/speeds.html

    Tom

     

  • 0 in reply to Tom Evans
    TI__Guru* 76130 points

    Hello Tom,

    Unfortunately, the PCMCIA cores present in all TI CardBus controllers were designed for compatibility with the broadest possible range of devices rather than performance. There is no functionality present that would allow for improved performance.

     

    Regards.

  • 0 in reply to Elias Villegas M.
    Prodigy 170 points

    Thank you for your prompt response.

    Since what I'm trying to do is impossible I can now stop. In retrospect we should have connected the CF card sockets to the CPU's ATA controller.

    This project was made a little more difficult than it needed to be, as there is no PCMCIA-side timing information in the PCI1520 manual at all. The only thing I had to go on was the statement that it "conforms to the standards":

    The Texas Instruments PCI1520, a 208-terminal dual-slot CardBus controller designed to meet the PCI Bus Power
    Management Interface Specification for PCI to CardBus Bridges, is an ultralow-power high-performance
    PCI-to-CardBus controller that supports two independent card sockets compliant with the PC Card Standard (rev.
    7.1).

    The PC Card Standard lists "standard" transfer modes that are faster than the PCI1520 is capable of, including cycles as fast as 100ns. The "high-performance" noted above probably only applies to the CardBus functionality.

    I eventually found timing diagrams and detailed specifications in the PCI1211 manual, assuming some commonality with the later part. With the programming we're using that should give a 480ns IO cycle or a 440us Memory cycle. There's nothing in there that documents the large delay between back-to-back cycles that stretches it out to 1000ns though.

    Tom