SDRAM on startkit

[pstnotpd]

Well, after some further digging in the (rather intimidating) SDRAM code I'm getting rather discouraged. I still think it can be done, but it would amount to creating a custom "PINOUT" directory. Basically the client API doesn't rely on ports, but the server setup certainly does.

[segher]

Looking at your portmap (which contains little mistakes btw),
the data/address lines are connected to 8B, 1M..1P, 4E, in
that order. If you stop using buffered ports it should be easy
to drive the pins in this configuration, but you probably need
to go somewhat slower. If you only store data in the "even"
bytes of the memory you can go faster, for bursts at least.

[pstnotpd]

Looking at your portmap (which contains little mistakes btw),
the data/address lines are connected to 8B, 1M..1P, 4E, in
that order. If you stop using buffered ports it should be easy
to drive the pins in this configuration, but you probably need
to go somewhat slower. If you only store data in the "even"
bytes of the memory you can go faster, for bursts at least.

I agree it is certainly possible to drive the pins and use the slice on the startkit, but I hoped (as doctek presumably did) to use the SDRAM softIP component. As far as I can figure out that is not a trivial change.

What mistakes are there in the portmap? It isn't mine, it was taken from the header file which is included in the startkit examples.

[sethu_jangala]

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?

The current implementation of the SDRAM component uses 16 bit port for A/D lines. But, the same lines are mapped to a 4 bit port, 8 bit port and four 1 bit ports on startKIT as 16 bit port is not available on the startKIT. So, the existing xSOFTip component of SDRAM will not work with startKIT as it is. You need to do certain changes in the code to implicate these.

Sethu.

[segher]

What mistakes are there in the portmap? It isn't mine, it was taken from the header file which is included in the startkit examples.

"Your portmap", as in, "not mine" -- I didn't know where you
got it from.

It mentions 4E twice, first time should obviously be 4D. The
rest looks reasonable, I haven't checked.

[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?

The current implementation of the SDRAM component uses 16 bit port for A/D lines. But, the same lines are mapped to a 4 bit port, 8 bit port and four 1 bit ports on startKIT as 16 bit port is not available on the startKIT. So, the existing xSOFTip component of SDRAM will not work with startKIT as it is. You need to do certain changes in the code to implicate these.

Sethu.

The response you just gave is the same as the one that started this latest round! I get it, I have to make "certain changes". But can you tell me what they are????? Segher and pstnotpd have been helpful, but not yet definitive. I really appreciate their contributions, but still no solution. I'm thinking of making an sdram board, but I'd like to know if it's possible to actually make use of it before I go to the trouble.

[pstnotpd]

I'm thinking of making an sdram board, but I'd like to know if it's possible to actually make use of it before I go to the trouble.

I think the gist of our answers is that it is certainly possible to use the SDRAM as all pins are mapped.

The softIP software component for SDRAM however does assume the pins to be mapped to a 16 port. This is standard on the slicekit, but for some reason (which I assume has to do with linking the hidden debug tile) on the startkit no such port is available.

If you want to use the softIP API (as I do) the sdram_server bit in the softIP should be changed to accept the 8/4/1 ports configuration to "act" as the 16 bit port in such a way that it is transparent for the "client" calls

Looking through the softIP code (module_sdram) I think this amounts to creating a new PINOUT_xxxx directory especially for the startkit, as in there the port mappings are actually made. As a lot of the code assumes dq_ah to be a 16 bit port all those references need to be re-mapped to the 8/4/1 ports in the correct order.

Considering the mix of assembly and xc I don't think it is an easy task, but there I can be wrong.

What I believe segher is hinting at is that you can ignore the softIP althogether and build your own implementation which, of course, does not have to adhere to any API specification.

[segher]

I think the gist of our answers is that it is certainly possible to use the SDRAM as all pins are mapped.

That, and you can drive the sdram interface much slower than
usual if you have to.

The softIP software component for SDRAM however does assume the pins to be mapped to a 16 port. This is standard on the slicekit, but for some reason (which I assume has to do with linking the hidden debug tile) on the startkit no such port is available.

It has nothing to do with connecting to the debug tile; the
tiles are connected via internal links. The chip does not pin
out all of port 16B, opting instead to pin out more 1-bit ports
(all of them). Startkit could have put 16A on the slice, but
it seems it was also prefered to have a greater complement
of 1-bit ports here.

What I believe segher is hinting at is that you can ignore the softIP althogether and build your own implementation which, of course, does not have to adhere to any API specification.

I wasn't hinting at that; I was just considering if the sdram
slice could work at all with startkit, and if so, how.

But yes, it may be easier to start from scratch, as always.

[Thorsten]

I wasn't hinting at that; I was just considering if the sdram
slice could work at all with startkit, and if so, how.

But yes, it may be easier to start from scratch, as always.

After spending plenty of hours and also some money for the SDRAMslice, I am kind of frustrated, that there is no (easy) way to make the SDRAM working with the startKIT. Well, it is of course always possible that things do not work like intended, but I cannot understand that the problem is known for many months, but XMOS still advertises in their current document https://www.xmos.com/download/public/Ex ... 0.9%29.pdf that the startKIT is fully compatible to the SDRAM.

[androider]

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!
....

... I'm thinking of making an sdram board, but I'd like to know if it's possible to actually make use of it before I go to the trouble.

I'm not having any issues starting up the sliceKit with an SDRAM module. Both the app_sdram_demo and app_sdram_benchmark worked without issue for me.

I say go for it.