Can MOD54417 Flexbus be used in 32-bit mode

[corestar]

We're connecting an FPGA to a MOD54417 module. We would greatly prefer to set the port size to 32-bits by setting the CSCR port size to "00".

But I notice the platform reference says:

The MOD5441x provides 16 address lines (A0-A15) and a 16-bit data bus (D16-D31) running in mode 2. An address bus latch is included on the MOD5441x so external latch is not required for this mode.

Does that mean I'm stuck with the 16-bit port size (CSCR bit 7-6 set to "10" (ie 2)? Is there some sort of latch in the way that will stop us from driving data onto the 32-bit bus during a processor read?

[lgitlitz]

Hi,

I have recently experimented with a MOD54415 to communicate with an FPGA via a 32-bit and 8-bit bus. While there is an on-board latch, it is not exposed externally and is used just for interfacing with on-board flash. This latch should have no noticeable effect on the bus when interfacing with external chip-selects.
The CSCR setting I wound up using for 32-bit mode was:
sim2.cs[1].cscr= 0x00150D00;
I did not do extensive stability testing with these settings and you may need longer wait states depending on the load on your bus signals.

The tricky part is on the Xilinx side. Normally with an 8-bit/16-bit bus, the lower 24/16-bits of address remain on the bus for the data portion of the bus cycle. With a 32-bit bus that is not possible since there are only 32-bits of bus. That means that you must latch the bus twice, once for the address cycle and once for the data cycle. The problem with this is that the MOD54417 does not bring out the FB_ALE signal to a header in its default hardware configuration. There is a small hardware stuffing modification that can be done to bringout the FB_ALE signal but it is possible to get the bus working without the hardware modification.

The following code snippets are in verilog and has only been used in demo code, it should be vigorously tested before being used in a production environment. The only major draw back to this code is that is latching the address on nearly every clock cycle so it may consume a bit more power then if the FB_ALE was exposed.

Code: Select all

parameter base_addr = 32'h10000000;  //base address of external memory
reg [31:0]FB_Address;               // register to store latched address
reg [31:0]MyWriteReg ;             // Stores data when MOD5441x writes to address 0x10000010

//  If the flexbus chip select is inactive or flexbus output enable is inactive 
//  then we drive nothing on flexbus data line 
//  otherwise we use function func_FB_Dataout to decide what we drive on flexbus data lines 
//  Refer to MCF54415 Flexbus chapter for basic bus cycle diagrams

assign { FB_Bus[31:0] } =  ( (FB_N_CS1==1) || (FB_N_OE==1) ) ?  32'bz : func_FB_Dataout( FB_Address );

function [31:0] func_FB_Dataout( input [31:0] address );
    case ( address[31:0] )
        base_addr + 32'h100 :   func_FB_Dataout = 32'h01234567;  // If reading address 0x10000100 output 0x01234567
        base_addr + 32'h104 :   func_FB_Dataout = 32'h89ABCDEF;  // If reading address 0x10000104 output 0x89ABCDEF
        default :               func_FB_Dataout = address;                   // Any other address output the address
    endcase        
endfunction

// On every clock cycle that the chip select is not enabled, latch the address
// Since the CS is not asserted until after the address cycle, we will always have a latched address at CS assertion
// Once the chip select is active, check if the FPGA is being written to by the MOD5441x at a valid write address and save the data
always @(posedge FB_CLK)
begin
    if( FB_N_CS1 == 1 )
    begin
        FB_Address[31:0] <= FB_Bus[31:0];
    end
    else if ( FB_RNW == 0 )
    begin
        case( FB_Address )
            base_addr + 32'h010 :   MyWriteReg <= FB_Bus;  // example of a write operation from the MOD to the FPGA at address 0x10000010
            default : ;
        endcase
    end
end 

[corestar]

Hello lgitlitz,

Thanks for the detailed reply. Sounds like it might work. It does not change the board design, so I can always revert to 16-bit addr and 16-bit data if I need to.

I had planned to do something similar to what you suggest on the FPGA side, but I don't think I need any wait states. I can use the address phase go generate my own ALE based on the base address. The upper bits tell me if it is the correct CS and the lower bits are the offset for my internal system. Note: the ALE line would have been helpful though.

For a read, I'll just used the address right off the bus and the data will be available on the next clock cycle to drive the flexbus.

For a write, I'll need to latch the address and use it together with the data on the next clock cycle to drive the internal registers.

An issue is the Flexbus clock is pretty high jitter. Apparently as high as 10% FB_CLK. But very little logic will be driven by it. I drive the A side of various block RAMS and FIFO's with the flexbus clock and the B side with a clean low jitter clock.

[pbreed]

So if your willing to do a bit of rework...
Remove U2 (tiny part) and stuff R2 then TIP signal becomes ALE...
We could probably do that for you in for a fee in batches of 100 units.

[corestar]

Having ALE would be really helpful. The timing diagram (eg Fig 20-8 of RM) makes it look like the address is asserted for exactly 1 clock cycle during the address phase. But if that were not the case, I would have no way of generating ALE for exactly one pulse right before CS goes low on my own. I would have to add a wait state. Not the end of the world, but I'd rather not.

I took a look at a 54417 module and as near as I can tell there are no labels for U2 and R2. We have a micro soldering station and could do a few for prototyping on our own. But we need to find them first .

I also note that the datasheet says "An external data bus buffer is recommended for any designs that use data bus signals D16-D31". Can you clarify the reason for that?

[pbreed]

With the pins facing up and the ethernet connector on the right side.
In the very Top Left is a small 14 pin IC that is U2.
The foot print for R2 is under the body of U2.
(Don't think I can post an image here, submit a support request and I'll send a picture)

We have seen people run long signal wires that cause reflections and problems for the parallel flash that also used D16..D31

[pbreed]

We have also had uninitalized FPGA's provide problems accessing the data bus
messing up the boot process... so to minimize these issues we call for a bus buffer.

[corestar]

I'll go ahead and open a support case.

Prior to and during configuration, the Altera Cyclone V are supposedly tri-stated, so hopefully it will not interfere with the MOD54417 boot. We've done some initial tests with an FPGA eval board where is seems to work (we're probably the ones who had trouble with too long leads ) Some FPGA's have options to hold IO pins high or low which I could see would be a problem (eg HSWAPEN on Xilinx Spartan).

We had planned on configuring the FPGA from the Netburner. We would store about 8 MB of config bits in the FLASH and write it to the FPGA via SPI (sort of). Is it correct that DDR RAM on the MOD54417 does not use the Flexbus? So I could always read the bits from FLASH into a RAM buffer and then configure the FPGA from that if they conflict.

Thanks

[pbreed]

Correct the DDR on the 54417 is 100% separate bus.