CSEE4823 Handout #29d Prof. Steven Nowick 11/12/11 HW#5: FAQ (frequently-asked questions) The following summarizes some questions/answers and clarifications about the mini-project. These updates are important to read: these clarifications supplement the other handouts, and you must follow them for a correct solution. Listed from most recent to oldest: ====================================================================== 11/17/11 ====================================================================== ==================================================== local counter: counting period for demo simulations ==================================================== Q. For the 'required simulations' specified in Handout #29e, you are told to assume that the local counter 'always counts 5 clock cycles' between a transition on its input cnt_enable to a transition on its SCL_toggle output. What does that mean? A. The above statement provides a complete and unambigious answer to the question of how the counter operates. We are in the synchronous world, and behaviors are measured in # of clock cycles. We are also using standard Moore machines, whose behaviors are well-defined. In particular, in a Moore machine, an input (such as 'cnt_enable') arrives at some legal time (i.e. not right at an active clock edge). After 5 active clock edges later (i.e. rising edge), the resulting Moore machine output will then go to the correct new value (i.e. SCL_toggle changes value). ================================================== timing when applying inputs: for demo simulations ================================================== Q. Can we provide the master controller with new inputs right on its active clock edge (i.e. rising transition)? A. This question has been covered in detail in the earlier course material and reading, both for FF's and for basic Moore FSM's. Inputs must never change right near or at an active clock edge, otherwise there can be failure of setup or hold times. See discussion in B/V on FF's, Moore machine basics, etc. ====================================================================== 11/14/11 ====================================================================== ====================================== clock stretching: write vs. read mode ====================================== Q. Do we need to support clock stretching for both master in send mode (write) and receive mode (read)? A. Yes. Nothing on the handouts indicates that clock stretching is reserved for only one mode. Clock stretching may occur not only if the slave local clock is slow, but even if it is relative fast if its processing of data is slow. ====================== more DC clarification: ====================== There may be a bit of confusion in my use of "DC" below in FAQ. I am using the term DC in two ways: to refer to both cases where an input can be either 0 or 1, and to those cases where one value never happens. So let me clarify better. master controller inputs: if an input W may have *either* value 0 or 1 in a given state, you can specify it in the state diagram as a '-' or 'x' (and need to determine how to specify it correctly in your VHDL code, which may not be the same way) if an input W can have *only one* value in a given state, say 0, you should list it as a '0' and *omit* any use of a 1 value for W in any of your input vectors in that state The goal is to allow a synthesis tool to note cases which are impossible, and simplify the resulting design (see 11/14/11 FAQ below) master controller outputs: if an output Z may have *either* value value 0 or 1 in a given state, and it is ignored, then for simplicity, you may arbitrarily fix the output to a given value '0' (to make the FSM operation a bit easier to simulate). This can make your simulation more manageable. See below in FAQ (11/12/11). ====================== 'byte_done' operation: ====================== Q. What assumptions can we make about when 'byte_done' gets asserted? A. The entire behavior of byte_done is specified in Handout #29. ============== handling DC's: ============== Q. If an input value is not possible in a given state, do we list it? How important is it for us to handle such DC's? A. In a given state, suppose a given signal X only has one value (say 0), and cannot take on the other value (say 1). Then the X=1 value is a DC. The goal is that you should OMIT DC'S from the FSM specification, and only list the *possible* input values. So, in this case, you should have no outgoing arcs with the impossible X=1 value. Likewise, if certain in put vectors are not possible, e.g. XY=10 or 01, while others are possible, XY=00 or XY=11, then you should only list outgoing arcs with transitions on XY = 00 and 11, and have no arcs for the impossible input vectors. The motivation is that this modelling approach allows CAD tools to treat these cases as DC's and further optimize the FSM implementation. NOTE: The above is an important but small optimization. If you list all input combinations, you will get a high grade, and only a small amount deducted. But for full credit, you should only list *possible* input vectors. ====================================================================== 11/12/11 ====================================================================== ========================== SOME GENERAL USEFUL HINTS: ========================== An I2C bus 'symbol' is not a simple 'code' on the bus at some point in time. Rather -- as clearly specified in Handout #29a and others -- it is *observing the bus signals OVER A TIME PERIOD* (i.e. typically through an entire SCL high period). This time period can take *multiple* local clock cycles. So your FSM likely will need more than 1 state to fully process the entire time period during which a single 'symbol' is transmitted or received. Have the FSM observe the values on SDA during this time period, going through more than one state as the time period progresses and SCL goes high, stays high, then goes low again. Also, remember that the local clock is very fast, relative to SCL. You *don't* (and shouldn't) be trying to catch a 'transition' or 'edge' on an input. Rather, you should use normal FSM conventions, and over time (and multiple states if necessary), monitor the different levels the signals go through on the bus. Q. Can we use 'edges' (i.e. transitions) on the input arcs of the state diagram? And can we assume extra hardware for the controller (beyond the FSM)? A. NO. Several students have noticed that some of the bus 'symbols' (such as START and STOP) involve an 'edge' (i.e. rising or falling transition on SDA, when SCL is high). It is fine to notice this. But it does *not* mean you can mark the Moore state diagram arcs with 'transitions' on the input. This totally violates all the usual Moore design conventions, and makes no sense (unless you invent your own non-standard synthesis flow -- which I am not allowing). A typical Moore machine only looks at, and responds, only to input *levels*. Do not assume various extra hardware to convert FSM inputs, etc. Just follow the straightfoward design problem, as presented in the assignment, which is close to how such a design would be done in industry -- with a simple 'normal' Moore FSM controller. =================== VHDL FSM templates: =================== Q. What template should we use for writing VHDL for a symbolic Moore state diagram? A. VHDL for a symbolic Moore FSM state diagram was already covered in your required B/V reading. In particular, B/V presented 2 alternative VHDL template styles: (i) VERSION #1: following Fig. 8.29 (3rd edition), (ii) VERSION #2: following Fig. 8.33 (3rd edition). Use one of these two styles (your choice which one) for HW#5. ====== Reset: ====== Q. Do we need to add a reset signal as an input to the state diagram of the slave controller? If not, how will it be reset? A. You should not add a reset signal to the state diagram, it will make it too complicated. Instead, just assume that the final FSM implementation has FF's with appropriate reset, so it can be driven to the correct start state. A reminder: do not implement the FSM! The assignment simply asks you to create a specification in the form of a Moore symbolic state diagram. ============================================= I2C MASTER FSM: tristated outputs and inputs ============================================= Q. In the I2C master controller, are any of the outputs ever tristated? A. Never! You are designing a standalone FSM controller. Its outputs are always either 0 or 1. You should never list 'Z' for any output of the FSM. That said, remember that what you may sometimes be tristating is the FSM's direct communication with the SDA bus. That doesn't mean that any of the immediate FSM direct outputs are tristated -- they are not. Q. What about the FSM's inputs? At some point in the protocol, the master is supposed to release (i.e. let float) the SDA bus, and the slave takes over. How do I model this? A. You do not need to model this. Simply simulate your Moore FSM. Even though the SDA output goes through a tristate driver sometimes onto the SDA bus, which is also the same bus which serves as the SDA input, you should simply treat the FSM inputs and outputs *separately*, as independent unrelated wires. Just simulate to be sure that you are enabling the output tristate driver at appropriate times, and driving the output to the correct value. You do *not* need to model whether the SDA input 'floats'. The 'floating' will not be visible to the FSM! Assume that at all times, some unit is driving the two I2C bus wires, so your FSM should always receive only 0 or 1 values on its inputs. ==================================================================== Initial State: Should I handle non-START events on the system bus? ==================================================================== Q. In the initial state, can anything happen besides first sending a START symbol? A. Of course! In your start state, before arbitration is won by the master, you definitely should handle cases where there are events, before any START symbol arrives. No one has said that nothing else ever happens on this bus. Another master may be active during this time. Also, follow the guidelines in Handout #29 on what are the assumptions just before the master controller wins arbitration, as to bus values, etc. ============================================================= Transmitting/Receiving Data or Address: SDA vs. SCL changes? ============================================================= Q. When transmitting or receiving data or an address, what is the actual relationship between changes in the SDA signal and the SCL clock pulses? A. There are two cases. When master is sender, you can fix the relationship between SDA and SCL changes, as long as they correctly fit the I2C bus protocol. However, when master is receiver, you cannot make assumptions on how the slave sets SDA vs. SCL changes. More details: (i) master as sender: In this case, since you are designing the master controller, you can specify any relationship between the change in SDA and the clock pulse of SCL (i.e. # of clk_hi pulses separating them), as long as it follows the protocol specification presented in the handouts and documentation. Note that you *cannot* change SCL and SDA simultaneously (i.e. in the same clk_hi cycle) during address or data bit transmission -- this violates the specification for data bit symbols. (ii) master as receiver: In this case, since you are not designing the slave controllers and don't necessarily know their exact operation, you *cannot* make assumptions or requirements on how close or far the SDA changes are from the SCL clock edges, for any symbols transmitted by a slave unit. In this case, your master controller design must handle ANY LEGAL TRANSMISSION MADE BY THE SLAVE, i.e. that fits the I2C protocol for symbol encoding. ==================================================== Serial Inputs/Outputs: when to output them locally? when are they received locally? ==================================================== The master, in write mode, receives inputs bit-serially on 'bit_send' to output on the I2C bus. Also, in read mode, the master receives inputs bit-serially from the I2C bus and outputs locally on its output 'data_received'. ---------- Read mode: ---------- Q. In read mode, when should the master generate the correct next "data_received" output for a new data bit on the I2C bus? A. In a robust design, you need to wait for the entire data bit symbol to be received (i.e. SCL pulse complete) before beginning to output the bit on 'data_received'. However, given that I am not requiring you to check for errors in transmission for this problem, you have the freedom to start otuputting the bit on 'data_received' earlier, when you detect that it is on the I2C bus. Your choice. Clearly indicate in your writeup which approach you are assuming, i.e. when does 'data_received' output a new data bit. Q. In read mode, how long should a data bit be valid on 'data_received'? A. Your choice. Simply make a good and clean decision, and clearly indicate your decision in the writeup. ----------- Write mode: ----------- Q. In write mode, should the master wait till it receives a complete data byte before starting this serial output? A. NO. Same answer as above for 'read mode'. Q. In write mode, how long will a data bit be valid on 'bit_send'? A. Your choice. Simply make a good and clean decision. However, you should assume that the rest of the master unit provides the correct input value on 'bit_send' on time, when it is needed. How long it remains stable on the input 'bit_send' is your decision. Clearly indicate in your writeup which approach you are assuming, i.e. when does 'bit_send' output a new data bit. ======================================================== Error Handling: early STOP, no ACK, invalid data, etc.? ======================================================== Q. The official protocol lists 'STOP' as only arriving after complete data byte transmissions (each followed by an ACK). Do I need to handle other cases, such as STOP arriving in the middle of a data byte, or middle of an address, etc.? What about not receiving an ACK, glitchy data, etc.? A. It would be nice if you can handle these cases. However, I did not ask for it, and you are not required to. You only have to handle the 'regular' scenarios indicated on the handouts. So the answer is: NO. You don't have to handle any other error detection or faulty transmission cases, other than what is specified in Handout #29, or in this FAQ (or in other announcements in lecture or email). ================================================================== Don't Cares: what to assume about unspecified inputs and outputs? ================================================================== Q. What about the outputs on 'SCL_out', 'SDA_out', and 'data_received', when they are not needed or otherwise specified in the requirements? Can they ever be specified as DC's? Similarly, what about the master input 'bit_send', can it ever be specified as DC? A. YES. However, you must be very careful to only specify as DC where not otherwise required to have a value by the HW#5 assignment or other I2C documentation. *However,* for simulation and specification, it may be easier for you to just fix these output values to 0 when not needed. Either way is fine. Q. What about inputs from the I2C bus (SCL_in, SDA_in) and inputs/outputs for the local counter (cnt_enable, SCL_toggle, byte_done, start/stop'): can they ever be specified as DC? A. NO. The initial local counter signal values are all given to you in Handout #29, i.e. before the start of the protocol when the master is inactive. The SCL bus values *may* change when the master is inactive (see above), but you must understand when they can change and model these changes -- i.e. for before the master wins arbitration, or after it relinquishes arbitration. That is, you can't assume nothing will happen on the bus during the inactive period, other masters may be active and your FSM must accept the input changes during these periods (before it is active) that appear on the I2C bus. Therefore, when the master is inactive, i.e. before it wins an arbitration (before START) or when done (after STOP), you *must* allow any possible changes explicitly in your FSM specification that may occur on SCL_in and SDA_in, due to other bus activity. -----------------------------------------------------------------------