Suggestions on how to interface to Intel Type bus

[seulater]

I have a few Intel type IC's that I need to interface to the address / data bus.

I have the usual ~CS, ~RD & ~WR pins, yet the Motorola processor has ~CS R/~W & ~OE.

I tried the following but with no luck
MOT --- Intel
~CS to ~CS
R/~W to ~WR
~OE to ~RD

Then I got the scope out and the data sheet and see that the RD & WR signals need to be low a after the CS goes low, and the RD & WR signals need to return to high before the CS goes high.

Yet when I probe the MOD I see that the CS & OE or the CS & W lines go low together and raise together, I believe this is my problem. Does anyone have a wiz bang ideas how to get these Intel type devices to work on the Mot. Bus ?






Though I there are many options for the CS signal there

[Chris Ruff]

If this was a problem I had to solve I would either:
1. synthesize the signals in software if it doesn't have to operate all that fast
2. synthesize the signals using an FPGA using the CLK to qualify edges
3. use a serial interface !? use a Z80 ??

Are you sure the chip(s) won't work with the signals at the module's interface? Most of the chips I have worked with over the years require read and write to be in position when cs* is strobed. I have used OR gates and such to generate the signals I have needed to talk with chips like you are talking about. I am not aware of any requirement that RD* and WR* have to raise in any sequence after CS* od OE* are strobed. If you are designing a product that has to meet some level of qualification you will need to understand *everything*, but if you are building a prototype or one-off, I think you can make the Intel-type bussed chips work fine.

Chris

[seulater]

I actually have 2 different chips that I am trying to interface. Both of which are the Intel type bus.
#1) is an OKI ML7204 VoIP codec IC.
#2) is a S1D13742 Epson LCD controller.

Neither of which was a able to communicate to using the bus. I was able to talk to then just fine with my ARM7's address and data bus who's style is much like Intel.

The only way I was a able to talk to them was to use a 16-bit latch with tri state outputs to do the following:

When I want to write to the OKI I do this:
#1) write my data to the latch from the MOD5234.
#2) using GPIO pins, manually bit twiddle the CS,RD lines to the OKI part to read in that data from the latch.

When I want to read the OKI I do this:
#1) using GPIO pins, manually bit twiddle the CS,WR lines to the OKI part to write that data to the latch.
#2) on the MOD, I just do a memory read for CS3 and it read that data from the latch.

The above works fine, but if I remove the latches neither chip works the OKI or the Epson.

[Chris Ruff]

So the latch/software generated signal methods are too slow? You don't want to add the latches? How's about the FPGA method? I've used the Xilinx on a few designs with ASM instructions to move signals in the driver code successfully.

Chris

[lgitlitz]

I think I see where your issue is here... it is a bit complicated. You need a signal on the bus to tell you when to write the data. It looks like your chip needs a WRB that tells when to begin and end the write, somewhere while the CS is asserted. Reading data is the same except the signal is the RDB.

We ran into a very similar issue when connecting the the quad UART IC for the PK70. Using the narmal connections we were able to read but writing did not work. So we have a 16C754 quad UART IC. There are 4 channels, each with its own chip select. There are also 3 address inputs and an IOR, IOW for enabling reading or writing.
The solution here was to run A0-A2 to the 3 address inputs. We then decode the A3-4 address lines to the 4 CS inputs for the 4 UARTS with a DM74ALS138 decoder. We then use two separate CS signals to control reading or writing. I am attaching the schematic for this blade board. Ignore the second DM74ALS138 IC with IOW and IOR outputs, this was another solution we tried which did not work and is not stuffed on the board.

We then had the following CS inits:
sim.cs[1].csar = ( BASEADDRESS >> 16 );
sim.cs[1].cscr = 0x3160; /* 00 11 00 0 1 01 10 0000 */
sim.cs[1].csmr = 0x00000001;
pWriteBaseAddr = ( PBYTE )BASEADDRESS;

sim.cs[2].csar = ( ( BASEADDRESS + 0x20000 ) >> 16 );
sim.cs[2].cscr = 0x3160; /* 00 11 00 0 1 01 10 0000 */
sim.cs[2].csmr = 0x00000001;
pReadBaseAddr = ( PBYTE )BASEADDRESS + 0x20000;

Another issue you might run into is the CS will tell the connected device that the processor is about to write data but data is not valid for another half clock cycle. When I created the bus interface on a CPLD of the Digital Blade I needed to compensate for this delayed data. I trigger the writes to occur on the rising edge of the CS. There is a good chance that your device will be OK with the half clock cycle delay since it probably already reads the data on the WRB rising edge. If not you might want to add a latch to delay the CS a half clock cycle.

I have fixed this issue with uploading PDFs. I have attached both the schematic for the Quad UART blade. I have also attached newly created VHDL code for the bus interface on the Digital Blade board. This will be helpful if you decide to use a CPLD/FPGA to translate the bus signals.

-Larry

[seulater]

Chris, the latch/GPIO method does work. but i was trying to do it a better way. I wanted to try to steer clear of adding a chip to the address bus just to capture the high speed data only to in the end bit twiddle the data in. Buti do thank you for your suggestions. As far as the FPGA or CPLD goes I don't know anything about them

Larry, Thanks for the informative tip I will fly wrap a 138 in and see how it goes.

[lgitlitz]

You probably need no additional hardware, just a rerouting of the signals. The DM74ALS138 will not be needed for your design if there is only a single CS. We only used this to decode the 2 high order address lines to the 4 CS we need for the quad uart. If you only have have 1 CS on your OKI part then you can just route the highest order address line to this CS. For example if you have 1 CS and 3 address inputs then A0-A2 go to your address inputs. A3 then goes to your CS input. We use the address to act as a chip select since this will always be asserted before the CS is asserted. The Address line->CS on this chip will be asserted often... anytime there is a write to a SDRAM address with A3 = 0. This should not matter since there will be no read or write activated unless one of the two coldfire chip selects activate either the WR or RD signals on the OKI bus.

[seulater]

OK, I just finish some extensive testing after adding the lvc138.

As per Larry's suggestions, this is what I did.

The connections on the LVC138 as follows.

Input Side
A input = MOD R/~W pin.
B input = GND
C input = GND
G1 = source
~G2A = MOD ~CS3 pin
~G2B = gnd

Output Side
Y0 = OKI's ~WR pin
Y1 = OKI's ~RD pin

I fired it up and holy $&@#! It worked!!!!
I took a peek at the signals on the scope and now the WR pin goes low a mere 11ns after the A8 pin goes low. Seems strange as hell to me that this little change in timing made it work.

Anyhosel, so I tried other ideas on this theme, wont go into the boring details of all the different way I tried to use the signals and the 138 but NONE of them worked.
My only concern right now is even though it appears to be working just fine, how close am I on the edge to it not.

In any event I want to say thank you to the people to contributed to me getting this to work. Now if I can only add a bit more delay to the ~WR pin I would feel more comfortable.

[seulater]

I would feel more comfortable pushing the WR line out a bit further, do you think I should string a line of 6 inverters together to get a tad more delay, or am I just being a freak.

[lgitlitz]

I remember the frustration and extra board spin from the quad UART blade with a similar bus interface. Glad to hear that you were able to get this one working.