Wait, Not so Fast!

Published November 25, 2005
Advertisement
Fortunately I have never needed a wait state generator for anything I have ever designed. Now that I am using an expansion system I need one. This is due to the ability of the CPU to access memory on an expansion board and complete transfers to/from that memory. The CPU writes a control word to a register that selects which expansion slot the CPU wants to communicate with (not to be confused with an I/O address), the starting addresses for reading and writing, and address increment/decrement controls, then begins to access the memory on the card as a single I/O address through a "BIOS" port. For this to work, the expansion circuitry needs to keep track of what addresses the CPU is reading and writing to. This is where the wait state generator comes into play - to tell the CPU to wait until the circuitry is ready. When the CPU accesses the BIOS port the address counters will automatically increment/decrement, thus the need for two wait states while the counters and output circuitry sets up for the access. This BIOS memory on each card is how the plug and use system works. When a card is plugged into a slot the system recognizes the change and automatically tries to identify the card type, hardware, drivers, system resource requirements, etc.





The top picture is the timing that I will need to follow while the bottom picture is the basic wait state generator (with some test parts added) in a simulation program I use.
Previous Entry DMA is Good
Next Entry Ouchy
0 likes 5 comments

Comments

Pouya
Quote:Wait, Not so Fast!
Must... resist... sex jokes...
November 25, 2005 09:12 PM
etothex
Just a few suggestions/questions:

1. Why are you gating the clock signals? Especially two layers of logic - that's just asking for a static logic hazard, which is death to a edge-triggered device. Sometimes it's necessary to gate inputs to CP, but I don't think this is a good scenario for that.
2. The state machine will wake up in an indeterminent state because you're not asynchronously clearing on reset. A better way would be to feed /Q into the first D input instead of Vdd. Of course this only works if your design can accept a synchronous clear instead of an asynchronous reset.

All in all, looks good. I like your net naming (Maybe I should name some of my nets /CRAP?) :)
November 25, 2005 09:26 PM
Caitlin
There, thats a better picture. Most of the gates are just to condition the inputs from the switches so they are timed as if they are coming from the CPU, namely the switch labeled CRAP. The 74161 is also a placeholder to see if the circuit will cause counting. As for reset timing, its not an issue since the logic will be reset to the desired state upon the first assertion of ALE and CLK, which is during a memory opcode fetch and not an I/O operation (what the circuit is designed for).
November 25, 2005 10:15 PM
etothex
Ahh, that makes more sense. As long as you know what you're doing :)

Circuit design is very much an art and - like programming - it's easy to develop a personal style. My circuits teacher, really a god of digital design, insisted that everything be used in the way it is intended - clk goes to the CLK pin, /RESET goes to the set/reset pins, and everything else is done logically.

Of course, I'm of the opinion that if it works, then don't fix it :)
November 25, 2005 10:52 PM
Caitlin
I agree with the notion that pins need to be used as intended. Here is what happened on my first design pass before I looked at the Intel docs (I quickly found out the circuit was faulty though):



However when looking at the Intel docs I came across this circuit:



Hey! It's already done for me so all I needed to do was add another wait state (for good measure, I might just use a single state from what I am seeing in simulation), some logic, and voila! All of that said, this circuit will still need tested in a breadboard to ensure it works as intended before I finalize it and find out later that it produces glitches. Ordering a bunch of PCBs with faulty designs would be a bad thing.
November 25, 2005 11:04 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement