MCF547x FlexBus Timing

[bswimley]

I was hoping that someone could comment on the Timing diagrams provided in the MCF547x Reference Manual.

We are interfacing to an FPGA using the FlexBus, and are finding that the signal timings specified do not seem to be correct.

Some specifics:

1) Dotted lines indicated in the timing diagrams represent signal timing when internal termination is used (Auto Acknowledge = 1). Our observations are that the dotted line timings are not observered, but rather the solid line timiings (which are supposedly only for Auto Acknowledge = 0) are the timings in place.

2) We are attempting to do burst mode read DMA transfers from the FlexBus. Our FlexBus is set for 2 wait states for the initial transfer, but then we want to swap over to 0 secondary wait states (eg WS = 2, SWSEN = true, SWS = 0). We also have ASET = 0, RDAH = 0, WRAH = 0, AA = 1, PS = 0 (32 bit), BEM = 0, BSTR = 1, and I have tried BSTW = 0 and = 1.

Referencing the timings, we would expect CS to be active for a maximum of 7 clock cycles (when you take into account the additional 2 wait states we require at the beginning of the transfer). What we are observing is that CS is active for 12 clock cycles.

I can provide more detailed information if required. Can anyone comment on this timing diagram discrepancies?

Best Regards,

Brett Swimley

[melissa_hunter]

Hi Brett,

I want to provide some additional clarification on how the timing diagrams show internal vs. external termination.

The timing diagrams show that if you had two bus cycles (one with internal termination and one with external termination) where the /TA is asserted at the same time, then the chip select and control signals will deassert one clock earlier for the internally terminated cycle than the externally terminated cycle.

Have you tried using external termination instead of internal termination? Do you at least see a change in the number of clocks for a bus cycle if you do this?

-Melissa

[bswimley]

I talked this over with our hardware engineer, and he had the following comments:

1) We don't have /TA connected to the FPGA so we can't try an external acknowledge.

2) It was our impression that the timing diagrams in the Reference Manual were an exact number of clock cycles (at least for internal termination). Are you saying that these timing diagrams aren't necessarily exact, but internal termination would always cause chip select, etc. to deassert one clock cycle earlier than /TA if both were running two cycles?

I guess what we're asking is the number of bus cycles in the diagram wrong, would we actually see three cycles with external /TA?

[JWW]

Brett,

I glanced through your indicated settings and nothing jumps immediately out as being incorrect.. I am curious as to the transaction size that is attempted to this 32-bit port. When you see this long CS (12 cycles..), what do the TSIZ signals indicate?

Also, would you mind posting the register settings for each CS on the FlexBus.

Are you using the DMA to generate these burst reads? If so..what is the source of the DMA request? I assume it is programmed to use an external request from the FPGA.

-JWW

[bswimley]

Attached is a document that we put together that shows some scope/logic analyzer traces of some of the pertinent bus signals (as well as the Chip Select Register Settings). I may be able to get TSIZ, but don't currently have it. I am using the FPGA strictly as a memory mapped device for DMA, so I'm not using any of the external DMA request signals. They're hooked up but (a) I don't know if they'd buy us anything and (b) We're not sure of the handshaking protocol.


Im using the Motorola DMA API for the DMA. I'm using the DMA_ALWAYS initiator. Here's my DMA call (which works great in non-burst mode but we'd really like the extra performace of burst mode as we *think* it should work):

/* OK, set up the DMA transfer */
MCD_startDma( m_dmaRxChannel,
(char*)dma_adr,
4,
(char*)m_pEthernetInfo->data,
4,
len,
4,
m_dmaRxInitiator,
6,
0
| MCD_SINGLE_DMA
| MCD_INTERRUPT
#ifdef BURST_MODE_ENABLED
| MCD_TT_FLAGS_RL
#endif
,
MCD_NO_BYTE_SWAP | MCD_NO_CSUM );

dma_adr is essentially the address of the "FIFO" area of the FPGA. We allow the address to increment as we've found that if we don't do this, the DMA engine does not attempt to generate burst mode transfers, even though burst mode is enabled.

The m_pEthernetInfo->data pointer is a pointer in SDRAM to where we want to transfer the data contained withing the FPGA FIFO.

I hope this information helps clarify our situation.

Best Regards,

Brett

[JWW]

Brett,

Just to be sure.. You did disable the "global-ness" feature of CS0, by enabling the "valid" bit in the CSMR0 register. Just want to make sure as this will cause internal address decode conflicts, since CS0 will try to decode CS1 and CS2 accesses as well.

My assumption is that you have set this bit already, but just wanted to make sure.

-JWW

[bswimley]

It's certainly worth checking, but yes, the V bit is set in CSMR0. This occurs in our bootloader when we configure the Boot Flash.

We can get CS1 and CS2 to work, but we just don't get the performance we think we should get based on how we interpret the FlexBus documentation in the Reference Manual.

Regards,

Brett

[bswimley]

I wanted to follow up with this as I received information from Technical Support.

1) Regarding the burst mode transfer bus cycles, I had a macro set up incorrectly. It turns out that I did not have secondary wait states enabled as I thought I had. Correcting the macro, the burst mode transfers were indeed down to 6 cycles. One other thing we discovered, was that doing burst mode transfers as we are, we needed to keep our receive buffers 16-byte (burst line length) aligned for the transfer to work properly. This is similar to what needs to be done with the Ethernet DMA transfers.

2) I received this response from Technical Support regarding the extra clock cycle on the single long word write to the flex bus:

"After talking with one of the designers we have figured out what is happening. The FlexBus will insert an extra clock cycle into an internally terminated single write cycle if the BSTW bit is set. So in this case the timing ends up looking pretty much the same as an externally terminated cycle. Reads don't seem to be impacted at all, so you can still get a single clock pulse on a chip select for a read cycle."