CSEE4823x Handout #27e Prof. Steven Nowick 11/2/16 PROJECT #1: FAQ (frequently-asked questions) The following summarizes some questions/answers and clarifications about the project. These clarifications supplement the other handouts, and you must follow them for a correct solution. ====================================================================== ========================== SOME GENERAL USEFUL HINTS: ========================== I2C Protocol and FSM Specification: ----------------------------------- An I2C bus symbol is not a simple code on the bus at some point in time. Rather -- as presented in the handouts -- it involves observing the bus signals OVER A TIME 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 the I2C bus during this time period, going through more than one state, as needed, to capture each symbol. Also, remember that the local clock is very fast, relative to SCL. You *shouldn't* be trying to catch a 'transition' or 'edge' on an input. Rather, you should follow normal FSM conventions, and over time (and use multiple states if necessary), monitor the actual values of signals 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. One may notice 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 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 any 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 either one of these two styles (your choice which one). ====== 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. ============================================= I2C MASTER FSM: floating outputs and inputs ============================================= Q. In the I2C master control FSM, are any of its direct outputs ever floating? A. NEVER! You are designing a standalone FSM controller. Its outputs must always be 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, through external tri-state drivers (see Handout #27). However, 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. You should assume that SCL and SDA at all times are either 0 or 1. (Recall that a floating SCL or SDA wire in the I2C bus goes by default to a 1 value.) ==================================================================== 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. Follow the guidelines in the handouts on what are the assumptions just before the master controller wins arbitration, as to bus values, etc. ====================== '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 #27. ============================================================= Transmitting/Receiving Data or Address: SDA vs. SCL changes? ============================================================= Q. When transmitting or receiving either an address or data, what is the actual relationship between changes in the SDA signal and the SCL clock pulses? A. There are two cases. When the master is sender, as the designer, 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 impose 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 read mode, the master receives inputs bit-serially from the I2C bus and outputs locally on its output 'data_received'. Also, in write mode, it receives inputs bit-serially on 'bit_send' which it will then output on the I2C bus. ---------- 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. The master will be reading each bit from the I2C bus, and outputting it as soon as received, on 'data_received'. In a robust design, you must conservatively wait for the data bit symbol to be fully received (i.e. SCL pulse complete) before beginning to output the bit on 'data_received'. However, given that we assume each bit will be transmitted using the correct protocol, you have the freedom to start outputing each bit on 'data_received' earlier, as soon as you detect that it is valid on the I2C bus. Your choice. NOTE: 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 on 'bit_send' before starting this serial output? A. NO. As the master receives each bit on 'bit_send', it should output that bit onto the I2C bus. Q. In write mode, how long will a data bit remain valid on the 'bit_send' input? A. Your choice. Simply make a good and clean decision. 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. NOTE: 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/NACK, incorrect protocols, etc. =================================================================== Q. The official protocol lists 'STOP' as only arriving after complete data byte transmissions (each followed by an ACK or NACK). 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 any ACK or NACK, 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 scenarios indicated on the handouts. Of course, Handout #27 does ask you to handle one important form of error-handling, in the version #2 design: parity errors in byte transmission. 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 #27 or in this FAQ. ======================== modelling/handling DC's: ======================== There are different cases, depending on whether the DC is on an input or output. Also, we distinguish cases below where an input can take on either 0 or 1 value (i.e. -), vs. where one value may never occur. ------------------------- master controller inputs: ------------------------- Q. If an input can take on any value, how do we list it? A. 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). 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 input W has only one value (say 0), and cannot take on the other value (say 1). Then the W=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 W=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. This approach allows the CAD synthesis tools to treat these cases as DC's and further optimize the FSM implementation. It also makes your state diagram less cluttered. 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. 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 #27, 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. -------------------------- master controller outputs: -------------------------- Q. If an output Z may take on *either* value 0 or 1 in a given state, and this output is ignored, how should I specify? For example, the outputs on 'SCL_out', 'SDA_out', and 'data_received', when they are not needed or otherwise specified in the requirements: should they be specified as DC's? A. 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' or '1'. This can make your simulation more manageable. Alternatively, you can specify it as a DC. EITHER WAY: your choice. However, be very careful only to do the above where the output is not required to have a specified value by the Project #1 assignment or other I2C documentation. -----------------------------------------------------------------------