Line 1: |
Line 1: |
− | On start-up the FPGA must reset and initialize each component; especially the Ethernet controller. Functionality will also be supplied to [[Ethernet_packets#The_reset_cycle|reset the system on a command from the PC]]. | + | On start-up the FPGA must reset and initialize each component; especially the Ethernet controller (EC). Functionality will also be supplied to [[Ethernet_packets#The_reset_cycle|reset the system on a command from the PC]]. |
| | | |
− | == The DAC == | + | == Reset Requirements by Component == |
| + | |
| + | === The DAC === |
| | | |
| The AD5535 DAC has an active-low reset pin. Pulling that pin low will reset the DAC, zeroing all channels. | | The AD5535 DAC has an active-low reset pin. Pulling that pin low will reset the DAC, zeroing all channels. |
| | | |
− | == The temperature sensor == | + | === The temperature sensor === |
| | | |
| The AD7314 temperature sensor does not have a reset function. It self-initializes on powering up. | | The AD7314 temperature sensor does not have a reset function. It self-initializes on powering up. |
| | | |
− | == The ADC == | + | === The ADC === |
| | | |
| The AD7928 ADC does not have a reset pin, but does require that certain internal registers be reset upon powering up. The reset procedure is to hold the D<sub>in</sub> line high while performing two dummy conversions. During both dummy conversions, as well as the third conversation (during which good data can be loaded), invalid data will be returned to the FPGA. It may be worth considering adding a third conversion to the startup procedure that sets the control register to a certain known setting according to our specifications; perhaps setting the next conversion to return channel zero simply as a known point of operation. | | The AD7928 ADC does not have a reset pin, but does require that certain internal registers be reset upon powering up. The reset procedure is to hold the D<sub>in</sub> line high while performing two dummy conversions. During both dummy conversions, as well as the third conversation (during which good data can be loaded), invalid data will be returned to the FPGA. It may be worth considering adding a third conversion to the startup procedure that sets the control register to a certain known setting according to our specifications; perhaps setting the next conversion to return channel zero simply as a known point of operation. |
| | | |
− | == The Ethernet controller == | + | === The Ethernet controller === |
| | | |
| The CP2200/1 has a complex reset process, which is laid out in detail in the data sheet (see section 6.2 "Reset Initialization"). The main points of the process will be covered here. | | The CP2200/1 has a complex reset process, which is laid out in detail in the data sheet (see section 6.2 "Reset Initialization"). The main points of the process will be covered here. |
Line 33: |
Line 35: |
| | | |
| See [http://www.google.com/notebook/public/08003089451145463058/BDQm4IgoQs_jkx-4i Ethernet Controller Reset Sequence notes] for more information and specifics of implementation. | | See [http://www.google.com/notebook/public/08003089451145463058/BDQm4IgoQs_jkx-4i Ethernet Controller Reset Sequence notes] for more information and specifics of implementation. |
| + | |
| + | |
| + | == Reset Implementation == |
| + | |
| + | === General Board Start-up/Reset === |
| + | |
| + | The communication protocol between the PC and the control board includes packets that order full (hard) or a minor (soft) reset of the board. The former begins from scratch as if the power was just turned off: |
| + | * EC's reset is held low and the chip is guided through its long reset sequence |
| + | * Auto-negotiation is implemented but without the detailed synchronization scheme: it is presumed that the partner device will perform it, or that the FPGA will naturally shift into phase with the auto-negotiation cycle in the course of its repeated attempts to establish a link |
| + | * The MAC address registers are reset, requiring the board to re-learn the PC's address |
| + | |
| + | The hard reset follows into the soft reset stage, or the latter may be ordered with the appropriate packet. The PC's MAC address is acquired at this stage (communication until this point is via broadcast packets) and ADC and DAC resets may be requested at this point. The reset of ADC and DAC is, of course, redundant if this stage is following naturally from full start-up. |
| + | |
| + | In addition to the hard reset instruction and the "GSR" reset signal received from the EEPROM upon startup, the board is equipped with a reset pin header. Shorting its two pins is equivalent to the start-up GSR reset. Note that in the current design, only the GSR and this manual reset signaling constitutes a full hardware reset which clears all registers, latches etc. The hard reset packet repeats the board start-up in terms of the sequence of steps required, but does not clear the state of the board entirely. |
| + | |
| + | |
| + | === ADC Reset === |
| + | |
| + | The ADC reset is implemented very simply: natural or requested reset default the modules that poll the chip into a "NeedsReset" state. This state overrules the detailed serial instruction pattern sent to the ADC's input pin, tying it high for two communication cycles (i.e. a full channel request and read conversation). This satisfies the ADC's "dummy conversation" reset procedure. At this point NeedsReset is set to 0 and communication with the ADC proceeds as usual. This means that the first Query of data from the ADC (which happens after the hard reset stage in an effort to assemble a status packet for the PC to confirm that this stage is complete) will have invalid data from channel 7. |
| + | |
| + | |
| + | === Reset of the DAC === |
| + | |
| + | The DAC reset pin is pulled immediately upon reading the soft reset packet instruction to do so. The FPGA's registers holding DAC's values are reset simultaneously |