From:                              Davis, Mark

Sent:                               Wednesday, September 07, 2011 10:44 AM

To:                                   Usher, Nathan

Subject:                          RE: LLRF2 RCM pin usage

 

Nathan,

 

(this has gone through several revisions as I think this through and refresh my memory on what can be done with each of the parallel ports on the Rabbit…)

 

I think I have digested most of this now, and I can see one basic problem:

 

As indicated on my summary of the Rabbit Core Module pin usage, the direction (input or output) of all of the Parallel Port C signals on the Rabbit are fixed.  All the even #’d signals (0,2,4,6) are Outputs and all the odd #’d signals (1,3,5,7) are Inputs.  The primary use of these signals are the inputs and outputs for the Rabbit serial ports that are (natively) capable of clocked (synchronous) I/O, hence they are the ones that need to be used for interfaces like SPI.   You can use these signals for something besides serial I/O, but you can’t change their direction.

 

What this means is that the LLRF2 signals Rab_SPI2.MOSI and Rab_SPI1_MOSI are ALWAYS outputs from the Rabbit.  There is no way I can change that.

 

While it has been some time since I wrote the code for communicating with the EEPROM, I believe that both the DSP and the FPGA will need to be able to use the Rab_SPI2.MOSI signal to send (at the very least) a read command to their respective EEPROMs.  Which means that having the Rabbit always trying to drive that line high or low is indeed a problem.

 

So what is needed is a way to disconnect the Rabbit from the Rabbit from the Rab_SPI2.MOSI signal whenever it is not using the SPI2 bus.

 

The simplest solution would seem to be to use the PROG_B and /DSP_RESET signals.  Both these are outputs held at ground level during a reset/reboot, which is the same state the Rabbit will have them in whenever it needs to use the SPI2 bus.  And in this state, both the DSP and the FPGA will be disconnected from the bus.  So if the logic was added to the circuit to disconnect the Rabbit from the SPI2 MOSI signal whenever either one was high, that would avoid conditions that could result in some combination of the FPGA, DSP, and Rabbit sinking/sourcing a current from/to 1 or 2 of the others on this line.

 

 

Notes/Questions: 

 

·         You didn’t mention it, but I assume that the FPGA and DSP must also be capable of driving the clock signal and that all master devices need to keep that at a high impedance state when not using the bus.  Thankfully, the Rabbit signals that provide the serial port clocks CAN be set to Input mode for this purpose.

 

·         You state that Rab_SPI2.DSPen/Rab_SPi2.FPGAen can be driven (low, I assume, from the rest of your explanation) by the Rabbit or the DSP/FPGA.  I assume that means the Rabbit should either set them to Input mode or open-drain output mode (an option for Parallel Port D signals).

 

·         I assume that reading from their respective ROMs is the ONLY thing the DSP and FPGA do with the SPI2 interface, that they only do this after they are reset, and it is up to the Rabbit to ensure they don’t try to do this at the same time.  Once the Rabbit is holding both PROG_B and /DSP_RESET high, the Rabbit has no control over what happens on the SPI2 bus.  So it would be up to the FPGA and the DSP to coordinate any additional (possibly conflicting) activities on their own.

 

 

And last but not least:

 

·         Could you send me a copy of each of the schematic pages in PDF format?

 

·         Would it possible to get one of the prototype boards for testing basic functionality with?  The DSP and FPGA don’t have to have fully functional configurations, just something that correctly responds to the things the Rabbit has to do (i.e. returns some identifiable values for reads, accepts writes, etc).  Read values don’t need to be realistic, so long as there is a way to tell if we got back the expected register (i.e. using the same value for everything wouldn’t be very helpful – perhaps something as simple as setting them all to 10x their ID, or (for R/W values) the last value written to the register.

 

 

Mark

 

 

From: Usher, Nathan
Sent: Tuesday, September 06, 2011 4:27 PM
To: Davis, Mark
Subject: Re: LLRF2 RCM pin usage

 

Mark,

 

All of the Rab_SPI2.x pins are part of the same SPI bus.  There are five devices on the bus: the ZWorld (master), DSP (master), FPGA (master), FPGA's ROM (slave), and DSP's ROM (slave).  Rab_SPI2.DSPen is the chip select for the DSP boot ROM and can be driven by either the ZWorld or the DSP.  Rab_SPI2.FPGAen is the chip select for the FPGA boot ROM and can be driven by either the ZWorld or the FPGA.  The PROG_B signal is the reset signal for the FPGA, and /DSP_RESET is the reset for the DSP.  To guarantee that the other chips aren't trying to use the SPI bus when you are trying to program the ROM, hold both other chips in reset.

 

In normal operation, you should set all Rab_SPI2.x signals, /DSP_RESET, and PROG_B as inputs.

 

When downloading a new file to either ROM, follow this procedure:

1)         Drive both PROG_B and /DSP_RESET low.  (this guarantees the DSP and FPGA won't try to drive the SPI pins)

2)         Set Rab_SPI2.MOSI to output.

3)         Pull either Rab_SPI2.FPGAen or Rab_SPI2.DSPen low to select the correct ROM (both signals have pull-ups)

4)         Write the file to the ROM

5)         Set Rab_SPI2.MOSI, Rab_SPI2.FPGAen, and Rab_SPI2.DSPen to input

6)         Release PROG_B (it has a pull-up)                (the FPGA will configure itself from the ROM, then release the SPI bus)

7)         wait for FPGA_done to go high

8)         Release /DSP_RESET            (the DSP will now control the SPI bus)

 

 

Any low pulse on /DSP_RESET will reset the DSP and cause it to reload from its ROM.  Any low pulse on PROG_B will cause the FPGA to reload its configuration from its ROM, but to reset the FPGA it would be best to follow the procedure above (skipping steps 2-5), to guarantee everything boots in the same order each time.

 

 

The Rab_SPI1.x pins are completely independent of the Rab_SPI2.x pins, so they have no effect on programming the ROMs.  The Rab_SPI1 protocol is unchanged from the previous protocol with the exception of register addresses being added/moved.

 

 

 

 

On Sep 6, 2011, at 3:37 PM, Davis, Mark wrote:

 

Nathan,

 

Attached is a summary of my understanding of the usage for the Rabbit Core Module signals for the new LLRF2 controller.  Please review it and let me know of anything that is not correct and provide the answers to my questions about some of the things I know are not yet clear.

 

In particular I suspect there are problems with my assumptions regarding the following signals and their relationships:

 

/DSP_RESET

Rab_SPI1_DSP_EN

Rab_SPI2.DSPen

 

Rab_SPI2.FPGAen

PROG_B

FPGA_DONE

 

<Pin usage for RCM3200.rtf>