Please Find Below Our Comments Regarding the PU Schematics

Please find below our comments regarding the PU schematics.

Thank you for your comments. Please find in blue, our answers.

1. Clocks

From the schematics, it is not clear who provides the main clock

to the Input FPGAs. Is it the motherboard (FEB_Clk) or is it

the Output FPGA (OI_Clk)? The latter is a bit strange and could

render bi-directional synchronous communication between the Input

FPGA and the Output FPGAs a bit tricky to implement, if needed.

The FEB_clk is used to format the input data.

The OI_clk is only used for the InFPGA configuration from the OutFPGA.

My impression is that you did this to be able to provide either FPGA

with 40 MHz OR 80 MHz clock, if needed. But we would definitely

prefer a solution with a global TTC_CLOCK fanout with equal timing

for all devices.

- Why not use a 2305 PLL to fan-out the TTC_CLOCK to all FPGAs,

and you may also keep PU_CLOCK going to the Output FPGA only.

- Or, why not use a 2308 clock PLL to fan out the TTC_CLOCK and

its double. A version of this chip has 4 outputs at the incoming

clock, and 4 more outputs at double the frequency. One pair of

(TTC_CLOCK and 2*TTC_CLOCK) would go to each of the three ALTERAs

(we can use dedicated clock inputs, of which the 20k has 4,

and the 1k has two).

When I wrote the code to configure the InFPGA from the OutFPGA, the OI_clk phase was an issue, but I managed to make it work on the demo board. But I agree, it is better, if the TTC_clock is distributed with equal timing to each FPGA.

ð The TTC_clock will be distributed to each of the 3 FPGA through a 2305 PLL.

ð Moreover, to implement a bi-directional serial communication between the InFPGA and the OutFPGA, 3 lines are kept between the OutFPGA and each of the InFPGA (data, read enable and write enable)

2. Clocks

According to the latest DSP errata SPRZ011G, issued end of September,

BECLKIN must still be provided during the DSP reset (Advisory 1.03.1).

You should therefore provide BECLKIN to both DSPs, unless you wish

to wait until TI fixes the problem.

- You may use two of the remaining outputs of U701 to provide

the local oscillator clock to BECLKIN.

=> We have chosen this solution.

- Or, you could use the remaining outputs of the 2305 mentioned at

<1.> to provide TTC_CLOCK as BECLKIN for both DSPs.

- Or, you could use the remaining outputs of the 2308 mentioned at

<1.> to provide TTC_CLOCK as BECLKIN for one DSP, and 2*TTC_CLOCK to

the other DSP.

3. I would like to propose a change in the DSP to FIFO interface.

The reason for the change is to allow the FIFO flag offsets to be

programmed by the DSP. The ability to program the FIFO flag offsets

could alleviate some of the not-so-nice features of the 6414 EDMA.

The summary of changes is:

- Connect the DSP /BSWE (instead of /BCE0) to the FIFO /WEN;

- Connect the DSP /BCE0 (or any /BCEx) to the FIFO /LD,

and disconnect the FIFO /LD from the FIFO_HI net;

- Connect the DSP /BARE to the FIFO /MRS,

and disconnect the FIFO /MRS from the Output FPGA (FIFOx_Rstn)

and from its pull-down;

- Connect the FIFO /PRS to the Output FPGA (FIFOx_Rstn) and you

may leave the pull-down on FIFOx_Rstn if you wish;

- Connect the FIFO /PAF to one of the DSP's general-purpose pins GPIO.

The rest of the flags may go to the Output FPGA (especially

important are /EF and /PAE);

- The DSP data lines to the FIFO may not be swapped: D0 should

remain D0 and so on through D15.

More details can be found in a four-page note at:

http://www.nevis.columbia.edu/~simion/rod_work/dsp_fifo.pdf

This note also mentions briefly the possibility of using the FIFO

D16 and D17 (and Q16 and Q17), as well as connecting the remaining DSP

/BCEn to the Output FPGA. This may be useful to keep the Output FPGA

informed about what's going on with the output data.

=> This point is in study. However, our first impression is that it is a bit superfluous.

4. Should we allow the Output FPGA to control the FIFOs /OE?

With Daniel, we don’t think it is necessary.

5. Since the DSP BECLKOUT2 now runs directly to the FIFO, having CLKOUT4

or CLKOUT6 available to the Output FPGA is a good way to verify

that the DSP is in a happy state, up and running (PLL locked at the

right frequency) after power-up. The happy state of the DSP can

be verified through the VME interface. These signals may later on be

configured as general-purpose pins.

Please connect CLKOUT4 or CLKOUT6 to the Output FPGA - either to

general I/O pins, or to dedicated fast inputs (in the last case we

give up the possibility of using them as DSP inputs later on).

If PCB routing is not an issue, then I would privilege CLKOUT6.

=> I am not sure it is necessary, however as we have free pins, both CLKOUT6 will be connected to the OutFPGA.

6. There is no general-purpose line from the Output FPGA to the DSP

which could be used as a CPU (not EDMA) interrupt source!

See Table 14-4 on page 14-5 of the Peripherals Manual SPRU190D,

or see the last paragraph on page 17-3 of SPRU190D.

We would propose to connect the DSP GPINT0 to the Output FPGA.

(TOUTx could be used for Input FPGA LED blinking instead,

see also item <9> below.)

Originally, there was an interrupt for each half feb in the InFPGA.

ð Both ext_int7 was removed from the InFPGA and connected to the OutFPGA.

7. For the McBSP2 connection to the Output FPGA:

Please connect both CLKX2 (ClkX1<2> and ClkX2<2>, DSP outputs)

to dedicated fast inputs instead of general-purpose Altera I/O pins.

=> OK

8. We would propose to have pull-ups or pull-downs on all DSP

configuration lines, BEA14 thru BEA20. Even better, why not connect

BEA14 thru BEA17, via 1k resistors, to the Output FPGA? There would

be 4 resistors for BEA14 thru BEA17 for each DSP, but the Altera side

can be common for both DSPs.

This may be useful if faster versions of this DSP will become

available, but we may need to readjust the EMIF clock rate to

keep our interfaces functional.

For the same reason, we would propose to have an optional pull-up

also on CLKMODE0, in addition to the pull-up on CLKMODE1.

=> To save pins, the first idea was adopted and a pull up resistor was added to CLKMODE0 and BEA14.

9. Please connect the DSP TINP0, TINP1, TOUT0, TOUT1 to the Input FPGA.

For example, TINPx would be used to count the transitions on the

G-link LINKRDY or ERROR flags. The total count will be available to

the DSP at any time. TOUTx could be used to issue a timeout,

if needed.

These pins can also behave as general-purpose unidirectional signals.

=> these 4 signals have been connected to the InFPGA, in case we want to use them.

10. The DSP data sheet states that the EMU2 thru EMU11 pins are "reserved

for future use, leave unconnected". (EMU10 used to be EMUCLK0 and

EMU11 used to be called EMUCLK1.) However it seems that you connect

EMU0 thru EMU9 between the two DSPs. Of these signals, only EMU0

and EMU1 are really used. What is the reason for connecting EMU2

thru EMU9?

=> This is a mistake. EMU2 to emu9 must not be connected.

11. You did a very small change on the way EMU<0> and EMU<1> may be

pulled down. They used to have individual jumpers, and now

there is a unique jumper and when the jumper is absent, then the

EMU<0> and EMU<1> are tied together via a 2k equivalent resistor.

Are you sure this is OK, given that the EMU pins can be outputs?

=> a Jumper will be foreseen for each emu 0 and emu 1 pins ( 2 jumpers in total).

12. The DSP signals GP9 and GP10 are going straight to the connector

and to the outside world. This sort of contradicts our unwritten

rule that the DSP should be electrically "isolated" from the MB

as much as possible (this is also related to the power-up issues).

However we are not convinced this is a real problem.

Also, this forces to generate the BUSY signal by software only.

What if we need to raise the busy signal much faster, for example

when an error is detected by the Input FPGA? Perhaps it would

be better that the DSP BUSY goes through the Input FPGA, where

it could be OR-ed with some lower-level condition.

ð For the moment, we have changed nothing, as we do not think it is necessary.

ð Can be rediscussed if free pins.

Power supply

------------

P1. [Comment regarding the missing GND/HSINK connection for U803 removed,

after checking the netlist.]

You should still verify the power dissipation for this component

since it runs at 1.5V dropout.

What do you mean ?

P2. In the new DSP data sheets (latest is SPRS146E), the DSP pins

R5 and F3 are regular 3.3V power supply pins. They were indeed

labeled "Reserved, must be pulled up with 10k" in older versions.

[The fact that they are now power supply pins has been confirmed

explicitely by TI tech support.]

OK

P3. DSP Core Power Suppy:

In the new DSP data sheets, there is a typical value listed

for the core supply current. It is 750 mA measured with "average

activity (50% high/50% low power)". Our power supply (switcher)

has been calculated/dimensioned for only 2 A of core supply current.

To be conservative, we would have to assume a max. of 3-4 A for

both DSPs. The main component (the TPS54610) is fine, but the

2.7 uH ELL6SH inductor, for example, is only rated for 2.4 A!

I have re-calculated the power supply components using the 4 A

specification. You can find two output examples at:

http://www.nevis.columbia.edu/~simion/rod_work/swift_4A_eff.pdf

http://www.nevis.columbia.edu/~simion/rod_work/swift_4A_siz.pdf

The requirement to have an input voltage ripple smaller than 40 mV

makes it necessary to have _two_ 100 uF caps on the 3.3V input

(for some reason this does not show up properly in the schematics,

but see the "Bill of Materials").

There is a tradeoff between the inductor size and the desired

efficiency. In the first case, the inductor turns out to be

relatively large. You could run the "Swift designer"

program from TI by yourself, to see if there is a better solution.

But I believe that the current DSP power supply (copied from the

6414 Demo) is not adequate to power two DSPs.

In study.

P4. There are fewer bypass caps (on each rail) per one DSP than in the

previous design?

We think we have enough caps.

The area is very busy.

We use now 0603 resistor instead of 0402, as preferred by our cabler.

P5. In the previous design (I mean the 6414 demo) the oscillator providing

the (50 MHz) CLKIN was powered directly from the 3.3V, not from

the switched 3.3VDB. This was done following an advice from TI,

that in order to prevent the DSP from drawing a lot of current

at power-up (possibly preventing the successful power-up), the DSP

should be provided with a running clock at and during power-on.

The argument, then, was that the /RESET signal is needed to

maintain most of the I/O pins in their high impedance state, but this

/RESET is synchronized internally to the DSP clock. So in order to

have the internal reset reflect the state of the /RESET pin, the clock

must be running. I do not know if this is still valid.

We would suggest you power the crystal oscillator and its fan-out

buffer from the direct 3.3V instead of the switched 3.3VDB.

OK

JTAG

----

J1. The TDI output (gate 1 of U704) is always enabled. What is the

purpose of the 1k pull-up on TDI ?

J2. The TMS output (gate 2 of U704) is always enabled. What is the

purpose of the 1k pull-up on TMS ?

J3. Gates 1 and 2 of U703 (PU_TDI, PU_TMS) may be enabled or disabled

depending on the presence of the "JTAG" jumper. Do you rely on the

JTAG cable being plugged into HP701 in order to maintain valid levels

on PU_TDI and PU_TMS, if the "JTAG" jumper is absent ? Yes

J4. If this is the case (i.e. a JTAG cable must be plugged into HP701

if the "JTAG" jumper is absent) then what is the purpose of the 1k

pull-up on PU_TCK ?

J5. Our impression is that you intended to have 1k pull-ups on

PU_TDI, PU_TMS and PU_TCK. right

J6. Do you rely on the motherboard to provide the proper logic

level on TRSTn when the "JTAG" jumper is present, and do you rely

on the presence of the JTAG cable into HP701 to provide the

proper level on TRSTn when the "JTAG" jumper is absent ? yes

The JTAG chain on the PU can be driven either from the PU (connector JP701) or from the mother board. In case the MB drives the chain, the JTAG jumper must be present. We agree it is a bit dangerous, but this should be temporary, in order to test the DSP emulator. (this can be done only from the PU). On the final board, the connector JP701 should not be populated, and the JTAG chain always driven from the MB.

J7. In the previous design, the bus buffer 74LVTH125 was powered from

the switched 3.3VDB instead of the direct 3.3V. This was to make

sure that the DSP inputs driven by this buffer were in fact not

driven during the initial power-up.