CSEE4823 Handout #28e Prof. Steven Nowick 11/3/12 PROJECT #1: 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/12/12 ====================================================================== =================================== Clarification on #28f: simulations =================================== Q. In Handout #28f, the two required simulations on the version #2 design, with master in "read mode", are (viii) and (ix). Each says "the slave transmits a byte of data with wrong parity". Doesn't the slave always include the correct parity? A. YES. To clarify Handout #28f on simulations (viii) and (ix): when I indicate 'the slave transmits one byte of data with wrong parity', I mean: " "the slave transmits one byte of data (with correct parity), which is corrupted during the transmission on the bus. The master then receives the byte with a parity error." ----------------------------- The following was already broadcast by email on 11/2 and 11/9. I repeat it here in the FAQ below: ==================== revised Handout #28: ==================== A reminder about the revised #28 handout, and requirements for ACK and NACK: I mentioned in class that a couple of the handouts #28a-d have different approaches to handling and use of ACK/NACK symbols. The quick summary: a. Handout #28a (p. 5, item #8b) indicates that, for master receiving ("read mode"), the master *omits* any acknowledgment for the *final* data byte. In contrast: b. Handout #28d (I2C Bus Specification and User Manual [NXP]) indicates that *every* data byte must be acknowledged, whether in 'read mode' or 'write mode'. In addition, it indicates that NACK (as well as ACK) are used in different cases even of *error-free* transfers. That is, in *normal* (i.e. *error-free*!) transmission, *both* ACK and NACK are used in the I2C protocol The original Handout #28 followed a. above. The *corrected (revised) new Handout #28* asks you instead to FOLLOW b. ABOVE. Details on when to use ACK vs. NACK are provided in the NXP manual (#28d). READ ALL RELEVANT SECTIONS CAREFULLY. ====================================================================== 11/11/12 ====================================================================== ====================================================================== **CORRECTION:** timing of "byte_done" signal ==> FOR VERSION #2 DESIGN ONLY, READ MODE <== ====================================================================== Q. In the handouts, it indicates that the 'byte_done' input always comes after the 8th bit is transmitted or received. However, in the VERSION #2 DESIGN (with error-detection), with "read mode", how can the slave unit know to output an 8th parity bit (at end of each data byte), if it does not get the "byte_done" input asserted high at end of the *7th bit*? Shouldn't 'byte_done' come after the 7th bit in this case? A. YES. This is a small missing requirement. CORRECTED VERSION: Version #1 design: no change from handouts ("byte_done" still arrives after the 8th bit) Version #2 design: WRITE MODE -- no change from handouts ("byte_done" still always arrives after the 8th bit) Version #2 design: READ MODE -- *CHANGED BYTE_DONE* OPERATION - ADDRESS BYTE: as before, "byte_done" comes after 8th bit is received by slave - DATA BYTES: **NEW** -- "byte_done" comes after *7th bit* is received by slave ====================================================================== 11/3/12 ====================================================================== --------------------- GENERAL USEFUL HINTS: --------------------- ====================================================================== Designing the Moore-Style FSM Specifications (symbolic state diagrams) ====================================================================== 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, to input *levels*. You cannot 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. SOME USEFUL HINTS about this design problem: A 'symbol' is not a simple 'code' on the bus at some point in time. Rather -- as clearly specified in Handout #28a 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 received or transmitted -- starting with SCL low, going to SCL at a high value (and waiting there possibly many local clock cycles!), and finally ending with SCL going low again. 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 clock ticks and multiple states if necessary), monitor the different levels the signals go through on the bus. =================== 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 this project. ====== 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 two specifications in the form of a Moore symbolic state diagrams. ==================================================================== 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 FSM's 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. You should *not* activate the slave's protocol before a master communicates with it, but you do need to be able to receive and observe all other bus activity. Follow the guidelines in Handout #28d on what are the assumptions on when there is no activity, as well as during bus arbitration and other steps. =================================================================== 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 #28 does ask you to handle one important form of error-handling, in the version #2 design: parity errors in data bytes. 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 #28, or in this FAQ (or in other announcements in lecture or email). ------------------------- TECHNICAL CLARIFICATIONS: ------------------------- =============================================================== 'addr_match': When does it arrive during address transmission? =============================================================== Q. When the initial address is sent, is 'addr_match' asserted (if there is a match) at the end of the 7-bit address, or at the end of the 8-bit address *byte* (including R/W bit)? A. Since I have not specified, you can use either possibility. However, clearly indicate which of the two assumptions you are making. ============================================================== 'byte_done': When does it arrive during address transmission? ============================================================== Q. When the initial address is sent, is 'byte-done' asserted at the end of the 7-bit address? or at the end of the 8-bit address *byte* (including R/W bit)? A. 'Byte_done' is asserted at the end of the 8-bit address *byte* (including the R/W bit). ============================================================================ Slave as Transmitter: How does it know when it has transmitted a data byte? ============================================================================ Q. When the slave is configured in transmission mode, and it is sending data bytes to the master, how does the controller know when it has sent a complete serial data byte on the I2C bus? A. The external slave unit hardware supplies an asserted-high 'byte_done' primary input signal whenever a complete data byte has been passed as inputs to the controller (for transmission on the I2C bus to the master). You can assume the remaining external slave unit (outside of your FSM) can directly monitor the I2C bus, count SCL cycles, and correctly assert 'byte_done'. ============================================================= Serial Outputs: data and address bits: when to output them? ============================================================= Q. The slave, when it receives an address from the master, must output address bits to its local unit bit-serially on 'addr_out'. Also, the slave, in receiver mode, must output data bits to its local unit bit-serially on 'data_out'. Should it wait till it receives the complete address or data byte before starting this serial output? A. NO. As soon as a new address or data bit is recognized on the inputs, output it bit-serially. =============================================================== Serial Outputs: data and address bits: how long to keep them? =============================================================== Q. The local slave receiver clock, "Clk_hi", is much faster than the bus clock, "SCL". So, if I produce a bit-serial address or data output bit, it may be many local clock cycles before the next bit arrives at the inputs. Should my FSM maintain the same output bit value (on addr_out or data_out) during this wait? A. YES. Once you output a data or output bit, your FSM should keep the output bit at that value until the next bit arrives. (This allows a long 'window' for the rest of the slave to sample and use it.) =============================================== Timing details of 'addr_match' and 'byte_done': =============================================== Q. At the end of a byte or address, when the last bit is received or sent on the I2C bus, when exactly should we assume that the local slave hardware unit detects it, and asserts "byte_done" and/or "addr_match"? A. Remember that the I2C bus clock, SCL, is slow and the local slave clock, Clk_hi, is fast. Also, that there is *no relationship* between these two clocks. Therefore, SCL may change arbitrarily close to Clk-hi. You cannot assume that the local hardware is instantaneously fast, and at any 'epsilon' after SCL, the local clock would have already produced an answer of 'byte_done' or 'addr_match'. In fact, 'addr_match' is only the result of converting the input address via the FSM to a local output address which is then processed. So, you cannot assume that the instant SCL changes, that the next local clock has had time to observe and compute based on it. Therefore, the FSM may need to wait one or more local clock cycles until the local hardware has asserted 'byte_done' and/or 'addr_match'. In fact, as stated in Handout #28, 'addr_match' first requires the complete address to be passed through the slave FSM to output 'addr_out', bit-serially, for local processing. Likewise, the handout indicates that when the slave is a receiver, it must pass the complete data byte through the slave FSM to output 'data_out', bit serially, for local processing. So follow the Handout #28 guidelines in a straightforward way: as an address or data arrives, the FSM must translate it to local bits (bit-serially) on addr_out or data_out, respectively. You cannot assume an instantaneous response from the local slave unit of byte_done or addr_done. However, you can assume the response comes very soon (but may require an extra local clock cycle or two). ============================================ I2C SLAVE FSM: tristated outputs and inputs ============================================ Q. In the I2C SLAVE FSM, are any of the 5 direct outputs (SDA_out, SDA_enable, data_out, addr_out, nack_sent) 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 an FSM. That said, remember that what you may sometimes be tristating is the FSM's output connection to the SDA bus. The FSM disables the *separate external tristate driver* shown in the figure in Handout #28. That doesn't mean that any of the 5 FSM direct outputs are tristated -- they are not. Q. What about the FSM's 4 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 4 inputs. (And, for the period where the master may 'release' control of the SDA bus, this doesn't mean that the SDA bus value will change randomly: the required handouts tell you what value the SDA bus will have during this period.) ============================================================= Transmitting/Receiving Data or Address: SDA vs. SCL changes? ============================================================= Q. When the slave transmits or receives data, or when it receives an address, what is the actual relationship between changes in the SDA signal and the SCL clock pulses? A. There are two cases. When slave is sender, you can fix the relationship between SDA and SCL changes, as long as they correctly fit the I2C bus protocol -- since you are designing the slave controller. However, when slave is receiver, you cannot make assumptions on how the master sets SDA vs. SCL changes (since you are not designing the master) -- since you are not designing the master. More details: (i) slave as sender: In this case, since you are designing the slave 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) slave as receiver: In this case, since you are not designing the master controller 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 master. In this case, your slave controller design must handle ANY LEGAL TRANSMISSION MADE BY THE MASTER, i.e. that fits the I2C protocol for symbol encoding. =========================================== handling and specifying DC's (don't-cares): =========================================== There are 2 uses of DC's in your specification: to refer to both cases where an input can be either 0 or 1, and to those cases where some values never happen. It is important to specify DC's correctly in your state diagrams, both to provide a complete specification, and to allow the CAD tools to exploit DC's for optimized synthesis. FOLLOW THESE GUIDELINES: (a) slave controller inputs: If an input W may have *either* value 0 or 1 in a given state, you can more compactly 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. Then the W=1 value (in this example) is a DC. The goal is that you should OMIT SUCH DC'S from the FSM specification, and only list the *possible* input values. In this example, you should have no outgoing arcs with the impossible W=1 input value. Likewise, if certain input vectors are not possible in a given state, 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. (b) slave controller outputs: if an output Z may have *either* value value 0 or 1 in a given Moore 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. =============================================================== DC's (don't-cares): details on slave controller inputs/outputs =============================================================== Q. What assumption should we make on 'addr_match/bit_send' input? What is its default vaule, and can it ever be treated as a don't care? A. It is never a DC. During receipt of an address, assume the 'addr_match' input is *always* 0, *except* when a successful address match occurs at the end of the address transmission. In the latter case (only), assume 'addr_match' is 1, for one local clock cycle. At all other times, it is 0, except when 'bit_send' is used. Q. What about 'byte_done' input? A. A similar answer. Assume it is only 1 when a byte is done, and otherwise *always* 0. Q. What about 'nack_sent' output? A. A similar answer. For your version #2 specification, assume it is only 1 for one local clock cycle after a NACK is sent or received on the bus, and otherwise *always* 0. Q. What about the outputs on 'data_out' and 'addr_out' when they are not needed? For example, can 'addr_out' bits be arbitrary when we are processing data bytes, and can 'data_out' be arbitrary when we are processing address bytes? A. YES. For these cases, when processing data bits, you can treat the 'addr_out' outputs as 'don't care's'; when processing address bits, you can treat the 'data_out' as 'don't care's. *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. ====================================================== How does the rest of the slave receiver hardware work? ====================================================== Q. How do the other slave receiver components know how to produce 'byte-done', 'addr_match', etc.? A. You don't need to know details, since you are not implementing it. But if you want to imagine how it *could* be implemented, there can be a small amount of extra control, which detects START and STOP (separate detection, with some local hardware monitoring the system I2C bus, i.e. examining both SDA and SCL (the latter to detect system clock pulses). A shift register can be enabled after START arrives, operating under falling edge of system clock, SCL, to slowly clock in your 'addr_out' bits; since your slave receiver is holding them for many local clock cycles, they will be shifted correctly on SCL going low. Same technique can be used for the data bits. A small counter, kicked off by START, can monitor SCL, and count off whenever a byte has been received. (A cleverer design would probably have changed your slave receiver, to output additional control to the shift registers and counters, but we are simply assuming some external control takes care of the operation.) In any case, you do not need to design or implement any of this external hardware! It is not part of this mini-project. ======================================================================