Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Wait, Not so Fast!

Sign in to follow this  


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.
Sign in to follow this  


Recommended Comments

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?) :)

Share this comment

Link to comment
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).

Share this comment

Link to comment
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 :)

Share this comment

Link to comment
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.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!