To do today:
- [/] Email students my schedule for today. - Did that, also included some instructions in the email.
- [/] Get students started developing DAC interface. - Discussed this in the email, copied datasheet to Dropbox folder. Then we examined the schematic had some discussions
- [/] Do receiving on SMA connectors, which I picked up from the office yesterday. - OK, did receiving with date back-dated to yesterday. Also checked to see if the receptacles fit in the thru-holes. The pins seem to be slightly too thick (perhaps because they are square instead of round as expected). They could probably be filed down to the point they would fit. Try that next. Couldn't find a suitable file in the lab. [ ] Bring a nail file or something from home tomorrow.
- [ ] Work on MCU C code while students are studying the DAC.
- The control signals (in OrCAD) output from the FPGA are: DACCLK (pin A13), DACIN (pin E11), and DACCS (pin Y2). The 6 DACs are daisy-chained together as a shift register, in the order (from first (least significant) to last (most significant)) VTH1 - VTH6.
- DACCLK is the CLK (input register clock) input to all the DACs (all clocked in parallel);
- DACIN is the D_IN serial input to all the DACs (really to just the first one on the chain, and daisy-chained to the others),
- DACCS is the CS_n/LD control input to all the DACs (all controlled in parallel).
- The protocol to program the DACs is then (ignoring timing details, which David is figuring out):
- (1) Make sure DACCS is lowered, so that we can load new values.
- (2) Stream the 72 (12x6) data bits, last threshold first, MSB first for each threshold, out to the shift-register chain as follows:
- Assign the new value of DACIN to the next bit; wait a bit.
- Raise DACCLK; wait a bit.
- Lower DACCLK; wait a bit.
- (3) Raise DACCS; wait a bit. (This is when the DAC outputs are actually changed.)
- The DAC transfer function should be approximately linear, with the range 0=0V to 4,095=~+2.5V, except that in practice it may not be able to get quite all the way up to +2.5V, since we are only supplying it with VCC=2.5V, instead of at least 2.7V as was required by the spec. As a test, we should set our max threshold to 4,095 and measure the output voltage with a multi-meter or the scope. (Note that if it is not +2.5V, this will limit our sensitivity to low-amplitude pulses.)
- David worked out the detailed timing sequence for the output control.
- Our plan is to have the new DAC_control module automatically program some default levels into the DACs after a short pause after it first turns on, then afterwards accept & program new 72-bit words from an external client on request.
- Then we'll also write another module DAC_CPU_IF (CPU interface) which remembers the current 72-bit word in a register, and takes a 16-bit PIO output bus from the CPU as its input. Bits 11-0 (12 bits) are the new threshold level, bits 14-12 (3 bits) is the ID 001-110 (1-6) of the DAC whose level to set, and bit 15 (1 bit) is set to 1 to accept a new 12-bit word (load it into the register), and then (just afterwards) to 0. Then, when all thresholds that need to be modified have been loaded, the high nibble should be set to 1111 (F=15) as a special command which tells DAC_CPU_IF to tell DAC_control to start the sequence to program the new levels; then (just afterwards) bit 15 is cleared. The driver code in the MCU should wait long enough, after sending this command, to allow the entire programming sequence (for all 6 levels) to finish. (This hard-coded delay keeps the interface simple by avoiding the need for return handshakes.)
No comments:
Post a Comment