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>