SDRAM on startkit

[pstnotpd]

I'm trying to get the SDRAM demo working on the startkit.

I have changed the target to STARTKIT in the make file, removed the slicekit support includes and adjusted the port assignment

on tile[0]: sdram_ports ports = {
XS1_PORT_16B
, XS1_PORT_1J -- CAS
, XS1_PORT_1I -- RAS
, XS1_PORT_1K -- WE
, XS1_PORT_1L -- CLK
, XS1_CLKBLK_1 };

as derived from startkit_portmapping.h from sw_startkit_examples.

.... but to no avial. It builds with the usual bi-directional warnings but the demo itself fails.

What am I forgettting?


I

[segher]

16B is not fully pinned out. Did you add any SDRAM device,
anyway? Connected how?

[Folknology]

Not all slice sockets are created equal, it's a rather slippery and somewhat inconsistent standard. The introduction of the Startkit's slice socket messes with some of my own personal slices :-(

P.S. It would be great if Xmos published a guide to designing slices in order to avoid such incompatibilities.

regards
Al

[pstnotpd]

16B is not fully pinned out. Did you add any SDRAM device,
anyway? Connected how?

It's the standard SDRAM slice from the slicekit.

[pstnotpd]

16B is not fully pinned out. Did you add any SDRAM device,
anyway? Connected how?

Well, after peering through the portmaps and code that indeed seems to be the problem. There is no 16 bit port mapped to the pcie at all, where the whole point of the SDRAM server is to map addressing through using 16 pins.

I wonder if the demo in it's current form can be used at all.

[sethu_jangala]

16B is not fully pinned out. Did you add any SDRAM device,
anyway? Connected how?

Well, after peering through the portmaps and code that indeed seems to be the problem. There is no 16 bit port mapped to the pcie at all, where the whole point of the SDRAM server is to map addressing through using 16 pins.

I wonder if the demo in it's current form can be used at all.

The SDRAM demo does not run on startKIT in the current form as the existing xSOFTip component uses 16 bit port. In the startKIT, the Address/Data pins are mapped to 8 bit port, 4 bit port and four 1 bit ports. You have to change the existing SDRAM component to make it work with the startKIT.

Sethu.

[pstnotpd]

The SDRAM demo does not run on startKIT in the current form as the existing xSOFTip component uses 16 bit port. In the startKIT, the Address/Data pins are mapped to 8 bit port, 4 bit port and four 1 bit ports. You have to change the existing SDRAM component to make it work with the startKIT.

Thanks for confirming. It seems I'm learning to read the hardware docs correctly now :)

[doctek]

So is the exciting conclusion that you can't use the SDRAM Demo with StartKit? That's one of the main reasons I got one!

Comment by Sethu:

You have to change the existing SDRAM component to make it work with the startKIT.

Could you elaborate on exactly what changes would be required?

[pstnotpd]

So is the exciting conclusion that you can't use the SDRAM Demo with StartKit? That's one of the main reasons I got one!

Comment by Sethu:

You have to change the existing SDRAM component to make it work with the startKIT.

Could you elaborate on exactly what changes would be required?

I think I understand what is going on, so I'll give it a go.

The softIP for the SDRAM cannot be used as that assumes a 16 pin port being available on the PCIe.

Code: Select all

on tile[0]: sdram_ports ports = {
  XS1_PORT_16B
, XS1_PORT_1J -- CAS
, XS1_PORT_1I -- RAS
, XS1_PORT_1K -- WE
, XS1_PORT_1L -- CLK
, XS1_CLKBLK_1 };

So the problem is the XS1_PORT_16B assignment. Funny enough the actual struct declaration shows it to be a 32 bit port. I'm not sure why it is done that way.

Code: Select all

typedef struct sdram_ports_PINOUT_V1_IS42S16400F
{
  //Data and Address muxed along with bank address
  buffered port:32 dq_ah;

  //Control Signals
  out buffered port:32 cas;
  out buffered port:32 ras;
  out buffered port:8 we;

  //Clock
  out port clk;

  clock cb;
} sdram_ports_PINOUT_V1_IS42S16400F;

This implies the dq_ah should be a continous mapping which, unfortunately, does not appear to be the case with the pinned out ports of the startkit.

As Sethu states and can be verified on page 14 of the startkit hardware manual the startKit PCIe only has a combination of 8, 4 and 1 pin ports available. This is also visible in the startkit_port_mapping.h file which is in the sw_startkit_examples package. In that file you can also see that the ports are not in the correct order to be used directly.

Code: Select all

//////////////////////////////////////
//startKIT PCIe port mappings for the SDRAM Slice
//https://www.xmos.com/en/support/documentation/xkits?subcategory=sliceKIT&product=15829&component=16080

/*

port SD_WE = XS1_PORT_1K; //SDRAM Write Enable
port SD_CAS = XS1_PORT_1J; //SDRAM CAS
port SD_RAS = XS1_PORT_1I; //SDRAM RAS
port SD_CLK = XS1_PORT_1L; //SDRAM Clock driven from XCore
port SD_ADQ0167 = XS1_PORT_4C; //SDRAM Address and Data for bits 0, 1, 6, and 7
port SD_ADQ2345 = XS1_PORT_4E; //SDRAM Address and Data for bits 2, 3, 4, and 5
port SD_ADQ8 = XS1_PORT_1M; //SDRAM Address and Data for bit 8
port SD_ADQ9 = XS1_PORT_1N; //SDRAM Address and Data for bit 9
port SD_ADQ10 = XS1_PORT_1O; //SDRAM Address and Data for bit 10
port SD_ADQ11 = XS1_PORT_1P; //SDRAM Address and Data for bit 11
port SD_ABD = XS1_PORT_4E; //SDRAM Address and Data for bit 12
//SDRAM Bank Address and Data DQ13/BA0
//SDRAM Bank Address and Data DQ14/BA1
//SDRAM Data DQ15

*/

So what I think needs to be done is change the SDRAM softIP component to accept this weird port order. Perhaps some declaration wizardry can get this done transparently but I'm not sure structure redefintion would be accepted using ports.

Anyway. I think the SDRAM slice itself will work fine, but the demo at this point will not.

[pstnotpd]

So the problem is the XS1_PORT_16B assignment. Funny enough the actual struct declaration shows it to be a 32 bit port. I'm not sure why it is done that way.

... answering my own question. These are buffered ports (shift registers) as explained in the XS1 port specifcation

That still doesn't help much unfortunately.