6

This should be an easy one but stick with me here. I think that page 46 of the ISA Bus Specification by Intel shows it's read on the rising edge. Intro to the ISA bus by Mark Sokos seems to agree on line 413. Or is it read on some other clock edge?

Looking at this guy's design:

IC10, a GAL, asserts the '245 bus transceiver /OE only when /IORD or /IOWR is asserted. (I can post the logic equations if necessary) If my assumption is correct about when data is read/written to the bus, how would this work? If data is sampled on either edge of /IORD or /IOWR, this is a problem as the '245s /OE is changing state on that edge.

If this isn't correct, what the correct time to assert /OE on an IDE bus transceiver besides when either IDE chip select is asserted?

EDIT: a published Compaq schematic for an I/O card I believe asserts '245 /OE without regard to /IORD or /IOWR (referenced by the very helpful Michael Karcher here on retro SE), which further confuses me.

Improve this question
4
  • Would you mind adding a hint about which '245 on the "Compaq Multi-purpose controller schematic" you are talking about, preferably citing a page number on the schematic? As long as the output of that chip (selected using DIR) does not collide with anything else driving the lines at the same time, you can have /OE enabled all the time.
    – Michael Karcher
    Apr 24 at 11:13
  • Sure, it's page 7-30 and the filename I have here is "COMPAQ_DeskPro_386_Technical_Reference_Guide_Vol2_1986-09". It's the '245s on the upper left of the page. Really, enable /OE permanently? On the same thread, is there really a reason to enable the upper byte '245 only when /IO16 is asserted? Seems the full bus would be open and the upper byte would be ignored.
    – eesz34
    Apr 24 at 20:01
  • 1
    That chip is used to forward the top 8 bits between the IDE cable and the ISA bus. It has /IORD on the DIR pin, so when enabled, it sends data from the ISA bus to the drive, unless /IORD is asserted. If /IORD is asserted, it sends data from the drive to the ISA bus. This implies that it forwards data to the drive sometimes even when /IOW is not active. This is OK, because the drive only outputs data when /IOR is active, so there won't be a bus collision on the IDE cable (except possibly as short glitch during /IOR edges). The point is that CompaQ can save a gate this way by not decoding /IOW.
    – Michael Karcher
    Apr 24 at 20:10
  • After thinking about this a bit, that definitely makes sense if /IOWR is ANDed with the address decoder as you explain. I like the simplicity and need to try this on my breadboard as I work towards a final design.
    – eesz34
    Apr 24 at 20:43

4 Answers 4

Reset to default
11

The answer is, on neither edge really, as the data is read some time before /IORD rises.

The /IORD is an active low signal for any peripheral to start or stop driving the bus. It is not a latch signal itself.

By the time /IORD goes low, it has already been determined if this is an IO read cycle and address has been stable for decoding for some time, or if this is a DMA read cycle on some DMA channel.

After /IORD has gone low, it takes some time before a peripheral starts driving the data bus, and it may take even longer before data on bus is valid for this particular IO read.

And by the time /IORD goes high, CPU has already read the data bus and peripheral must stop driving the bus.

So as long as the data becomes valid and is valid when CPU reads it before /IORD is set high, the cycle is good, and that is why you can immediately stop driving the bus when it goes high.

Improve this answer
4

Each signal read on an edge needs specific setup and hold time, especially when driving a bus.

Therefore, enabling the bus driver with LOW on /OE is correct. It takes some time until all output signals have settled. Then on the rising edge of /IORD the reading partner can take the value safely. The outputs stay stable for an instance after /OE gets HIGH again.

To make sure that your circuit works, you need to read the data sheets of the concerned devices and check the propagation delay of the driver against the hold time of the receiver.

I even came across devices having negative hold times, meaning that you can de-assert the data before the clock edge. The data signals are internally delayed long enough to be safely captured.

Improve this answer
2
  • 1
    So are you saying /OE on the '245 should be asserted when the correct address is present AND /IORD is asserted? If the '245 goes tri-state as soon as /IORD de-asserts, the data value from the IDE device will not be present on the ISA bus anymore. I'm not sure if it's safe to assume the data signals will remain long enough after /OE goes high.
    – eesz34
    Apr 23 at 15:03
  • 1
    @eesz34 Assumptions are bad if you design a circuit, never do it. You need to be sure, especially as a non-expert. I extended my answer.
    – the busybee
    Apr 24 at 6:18
4

You've disregarded the propagation delays of the circuitry.

For reads...

The CPU/DMAC is under full control of the transfer, inc. when read data is latched and what /IORD is driven to.

At the end of the read cycle, it internally latches the read data, then negates /IORD.

The read data is captured long before the read negation ripples out through the CPU/DMAC pins, through gates and off to the '245s.

For writes...

The target peripheral latches the data on the rising edge of /IOWR i.e. as it is being negated.

That /IOWR rising edge reaches the peripheral fast through the 74F125 buffers.

That happens well before (a) the GAL can negate the '245 enables and (b) the '245s can then respond and tri-state the data bus. Until then, the '245s are still driving out the write data to the target.

Improve this answer
2

The data on the ISA bus is read at any time (not specified) at which the target is ready, before the host terminates the cycle. There is some default delay starting at the point of time in which /IORD is lowered, after which the target is assumed to be ready and have its data on the bus. If the target can't provide data in time, it is supposed to lower IORDY, asking for more time. The initiator is going to sample the data at any time after the default delay while IORDY is high. After the initiator sampled the data, it stops asserting /IORD.

So for reading from the bus, the logical AND (respecting positive/negative levels) of the address decoder output and the /IORD is a valid way to drive /OE on a 245-type buffer.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .