SDRAM slice to DIAMOND slot of USB Slice Kit

[tilde]

Hello,

I would like to use my USB slice kit with SDRAM in DIAMOND slot. I found a tutorial which uses module SDRAM, and it works fine with SDRAM slice in SQUARE slot.

On DIAMOND slot there is a 32 bit slot, instead of 16 bit on square. I think it is the problem.

In slicekit selector guide from XMOS I found the SDRAM slice is supported on DIAMOND slot, but in that case they Requires port assignment to use top 16 bits of 32-bit port.

How to do it?

SDRAM has a buffered port, with 32 bit buffer (buffered port:32 dq_ah;). When I using squere the port is 16 bit wide, and when I use DIAMOND the port width is 32 bit.

[mon2]

Hello tilde, let me try to explain the issue and possible solution:

On DIAMOND slot there is a 32 bit slot, instead of 16 bit on square. I think it is the problem.

Correct. The SDRAM server code is tied to the same relationship in that, for a single cycle, the SDRAM code is expecting only 16 bits of the data to stick or be read from the hardware.


SDRAM has a buffered port, with a 32 bit buffer definition (buffered port:32 dq_ah;). When I using square the port is 16 bit wide, and when I use DIAMOND the port width is 32 bit.

Correct. When a port is defined to be 32 bit wide and buffered, this means that 32 bits of data can be sent or received to the physical port pins before the buffer must be reloaded or emptied to avoid data loss.

Take for example the following 32 bits of data: 0xFEDCBA9876543210 which is to be written to the 16 bit hardware port. The following order of writes will occur:

Clock Cycle #0

Bits 15..0 of the hardware port = 0x76543210

Clock Cycle #1

Bits 15..0 of the hardware port = 0xFEDCBA98

Finished.


Now if the hardware port is 32 bits,

Clock Cycle #0

Bits 31..0 of the hardware port = 0xFEDCBA9876543210

but since the DIAMOND slot does not have the higher 16 bits mapped to the PCIe pins, the upper 16 bits of data will be lost. Respectively the same in a read = ignore the top 16 bits.

In the SDRAM design, a 16 bit physical port is applied for the hardware interface with a 32 bit buffer in the port definition. So this means that in a single clock cycle, 16 bits of the 32 bit buffer will be sent out or read from the hardware pins. Respectively, in 2 clock cycles, all 32 bits of the buffer will be consumed. Again, the software module for the SDRAM is closely tied to this relationship so care must be taken to port to other pins / alternate slice sockets.

In slicekit selector guide from XMOS I found the SDRAM slice is supported on DIAMOND slot, but in that case they Requires port assignment to use top 16 bits of 32-bit port.

How to do it?

The use of the DIAMOND slot on the USB kit is relatively straightforward for the port pin mappings. Please review the following source code:

https://github.com/xcore/sc_sdram_burst ... am_demo.xc

and specifically:

on tile[0]: sdram_ports ports = {
XS1_PORT_16A, XS1_PORT_1B, XS1_PORT_1G, XS1_PORT_1C, XS1_PORT_1F, XS1_CLKBLK_1 };

you may take the above definition and map to your DIAMOND slice port definition.

For example,(please check for accuracy but should be ok)

on tile[0]: sdram_ports ports = {
XS1_PORT_32A, XS1_PORT_1J, XS1_PORT_1I, XS1_PORT_1K, XS1_PORT_1L, XS1_CLKBLK_1 };

That was the easy part. Now the code must be reviewed so that you can support the source code to perform its function using this now wider 32 bit port. Keep in mind that now, with the DIAMOND slot, each clock cycle will dump or read 32 bits AND the top 16 bits of the 32 bits will be ignored / lost since they are not mapped to the hardware port. That is, the top 16 bits of this 32 bit port are not to be used.

For this reason, not sure I would agree with the statement from the slicekit selector on how to support the DIAMOND slot. Believe the text should have read "use the BOTTOM 16 bits of the 32 bit port" since they are mapped like the original 16 bits (ie. 1:1).

The SDRAM code is required to initialize the SDRAM; then R/W with the SDRAM device. Consider to search the SDRAM wiki on this topic. We have at least 2 months invested in this IP and have made progress on supporting this code on the StartKit + SDRAM board. However, the documentation and code are not yet finished so we need more time before we release to the public.

At least for us, the code is quite challenging to review but we have learned many new concepts. To meet the strict timing of the SDRAM component, some of the code is in assembler - more fun !! Without a doubt, the code is clever and crafted by some very sharp individuals. However, severely lacking proper and much required documentation on how this all works.

On topic, would you read off the part markings on your SDRAM module ? Interested to know which version you have. We have the ISSI "F" device on our lab board but interested to know if others were produced.

Time permitting, will review the same project as yours to see if we can support the DIAMOND slot on the USB Slice Kit. Our USB Slice Kit was recently ordered last Friday so have not yet set up the tool in the lab. The code is complex but if taken slowly, there is a lot of value to learn about XMOS.

Hope this helps.

Kumar

[tilde]

Hello,

I have SDRAM slice: XA-SK-SDRAM,
and the SDRAM chip is: IS42S16400F-7TLI

Thank you, for answer.

I started work on this problem, but this need more time. Now I have another job, so I waiting for a working tutorial, with 16 bit port support. :)