SDRAM on XGC/Xshell board or LS1 device

Non-technical related questions should go here.
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

SDRAM on XGC/Xshell board or LS1 device

Postby kster59 » Thu Dec 31, 2009 9:31 am

I wanted to use an LS1-128 like the Xshell schematic with the same port map: http://www.xmoslinkers.org/node/319

But when I read through the code, it is does not have the sdram function implemented in code!

I thought that was odd considering the sdram chip takes a lot of the available pins.

Does anyone have a modified version of the 16bit SDRAM driver for the 4bit or 8bit wide bus Micron chip?

The SDRAM docs page shows speed results for 16bit and 4bit modes but there's no code examples.

Looking at the Micron datasheet, it seems non trivial to go with the 4bit mode in terms of addressing and other details which I would rather not have to worry about if there is already a written 4 or 8 bit driver out there (I assume the 4 bit driver was written to take do the benchmarks).

Furthermore, the SDRAM code uses a 32bit output port for the address lines even though they are only 13 address lines. Aren't the remaining 32-13=19 I/O wasted by this assignment?

The XShell uses part of the P32A for multiple pins beside the address lines but the code isn't in the zip file so I'm not sure how SDRAM is written out on an LS1 device.

Any help would be appreciated. SDRAM support was a primary reason for picking the XMOS devices for me.
User avatar
DrFingersSchaefer
Experienced Member
Posts: 65
Joined: Fri Dec 18, 2009 1:27 pm
Location: The Interzone

Postby DrFingersSchaefer » Sun Jan 03, 2010 5:01 pm

kster59

Following your post I have been looking at the code etc and agree with you. The DRAM appears to be connected but not actually used. (I could well be very wrong about this as an XMOS newbie).

Whilst it should be eminently doable to drive DRAM, (as far as I can tell). My readings suggest that it can't be used for code space unless you start doing some clever paging or some such between the DRAM and the internal RAM.

IO looks to be carried out using separate instructions and there is no instruction that allows you to directly reference memory attached to IO much less execute instructions directly from it.

If anyone could shed some light on this I would love to know too....
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Postby kster59 » Mon Jan 04, 2010 9:05 am

I'm fully aware that the SDRAM cannot be used as normal memory.

I wanted to use it just for fast scratch buffer space.

After investigation a bit futher and looking at the code in detail, I have come to the conclusion that the L1 devices CANNOT support SDRAM and do anything else useful. You would need to dedicate almost all the pins and resources of the core to support SDRAM.

As written, the SDRAM driver code requires 13 address lines which must be on a 32bit port. In addition it requires a 16bit port for the data, 2 single port i/o for BA0 BA1, a 4 bit port for cmd and two extra unused i/o for a dummy clock block and sdram gate function.

The big kicker is the 13 address lines which must be a 32bit port. This gets rid of the remaining 32-13=19 i/o.

In summary, it'd be nice for someone to write a working SDRAM driver that doesn't use all the i/o pins. In theory, you could just use the 32bit port alone and leave the rest of the pins available but this would require a major rewrite and might not even be possible because the extensive use of clocked buffered i/o which depends on addressing complete ports.

I read through the Micron datasheet in detail and examined the code carefully to come to these conclusions but I would be happy to be proven wrong.

As it's written right now you can only use the sdram on the G4 512 devices or maybe some linked together L1-128 but you are dedicating an entire chip to the sdram function.

You would probably be much better off just using an FPGA and an sdram ip core.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Wed Jan 06, 2010 6:52 pm

The SDRAM example using XS1-G Development Kit here http://www.xmoslinkers.org/projects/sdram uses some 39 pins.

The Xshell project schematic appears to use 8 data,13 Address, 2 BA0/1 and 7 timing/control giving a grand total of I/O 31 pins.

Maybe I am looking at the wrong project its a a bit confusing.

You also indicate that it has to be a 32bit port. Is that true? or can one use 2*16bits or 16 + 8 + some other combination. Obviously the code would need to be re written in this case.

I am also intrigued by the possibility of using SRAM/SDRAM using a smaller number of pins. Although I am not sure what memory capacity we can realistically add on an L1

regards
Al
kster59
XCore Addict
Posts: 162
Joined: Thu Dec 31, 2009 8:51 am

Postby kster59 » Thu Jan 07, 2010 1:32 am

I think looking at the schematic is insufficient.

When you look at the code then it is much more complicated.

With the Xshell is it really complicated because there is no source code at all ;)

With XGC code, the code uses a clock out on a 1bit port then uses that clock as an input to another clockbase. It is documented in the code "//this pin must be free" or something like that.

Also, on the XMOS devices the pins are mapped to ports. In the SDRAM source code, the address pins a1-a12 are mapped in reverse order to the 32bit port A12->P32A[31], A11->P31A[30], etc. In the code it says something about saving time by doing a bitreverse.

I played around with the portmappings and you end up with a lot of dead pins. If you map the 13 address pins to the upper bits of 32bit port you lose the lower bits for sure unless they're being used as an XMOS link.

The XC code uses some special manipulations that aren't in the XC programming manual and you need to guess what they do.

Part of the driver is also written in assembly with no comments and the XMOS assembly language is quite different from other ASM languages like x86 or 8051 or PIC I am familiar with so there's a long learning curve there.

The random driver also uses 3 threads and I'm not sure exactly why that is necessary.

It would be nice for someone to clean up the code so it could be used on a minimum of pins (maybe fill the 32bit port alone) and offer the 4bit version also. I think even a working version on the XShell schematic would be very helpful.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Postby jonathan » Thu Jan 07, 2010 6:53 am

kster59 wrote: The XC code uses some special manipulations that aren't in the XC programming manual and you need to guess what they do.
Can you identify these manipulations here? Thanks!
Image
User avatar
DrFingersSchaefer
Experienced Member
Posts: 65
Joined: Fri Dec 18, 2009 1:27 pm
Location: The Interzone

Postby DrFingersSchaefer » Thu Jan 14, 2010 9:04 pm

If pin count is an issue, have a look at PSRAM sort of DRAM with on board controller. it gives larger capacity at lower cost and uses a SRAM addressing structure.

If you use a SRAM addressing structure you could multiplex the address bus to reduce Address pin count (ie put some of the the high order address pins through a register. accesses to low order sequences of addresses then remain single IO cycle access. You incur an extra IO Cycle to rewrite the high order bits only as you need to cross the block boundary.

Sure it's a compromise but Pins versus Speed always is. You trade one off against the other.

For your dram you can have an 8 bit data-bus (SRAM & PSRAM too) but you need to do 4 fetches (IO Cycles) to make a 32 bit word.

As you have observed, where you want speed and pins you will need to go up a device (or two).
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Mon Jan 18, 2010 1:15 pm

The PSRAM looks like a good idea, unfortunately I can only seem to find BGA based chips from Micron which means going to a 4 layer board. Also they seem to be 16 bit wide rather than 8 bit.

@DrFingersSchaefer Do you have any links that could help out, I'm rather new to this?

The ideal scheme (for low pin count) would be an SRAM/PSRAM with 15/16bit address + paging and an 8 bit data.

regards
Al
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Mon Jan 18, 2010 2:22 pm

Having re-examined the XShell schematic http://www.xmoslinkers.org/node/319 and the Micro datasheet I decided to revisit this thread

@kster59
I played around with the portmappings and you end up with a lot of dead pins. If you map the 13 address pins to the upper bits of 32bit port you lose the lower bits for sure unless they're being used as an XMOS link.
I think this is a mistake (although I might be understanding ports incorrectly, please correct me) The precedence on ports works the other way around The 32bit port has the least priority on the pins. That is if any or the successively lower bit width modes are enabled they override the pins on the port. Thats is a 16 bit port will override the 32bit, 8 bit will override 16,32bit, 4 bit will override 8,16,32bit and a 1 bit (in this case) will override the 32 bit port directly. A link will override all of them.

So if this is the case those other pins are available for usage and only the upper end of the 32 bit port is actually used, the rest is masked out by various overrides on different ports (or ignored).

In which case the XShell schematic should work. Does that mean it works with the example SDRAM code (http://www.xmoslinkers.org/projects/sdram)from the XDK? I haven't examined it in any detail at this point, but it would certainly need changes for sure as the chips is different, as is the size and width.

That makes L1-TQFP128 a good candidate

Thoughts?
User avatar
dave
Member++
Posts: 31
Joined: Thu Dec 10, 2009 10:11 pm

Postby dave » Mon Jan 18, 2010 3:13 pm

Reading these posts, I realised that our documentation about port precedence is not very clear. The key paragraph is at the top of page 31 of the 'XS1 ports specification' document.

If a narrow port shares pins with a wide port and the narrow port is enabled, those pins of the wide port that are not shared with the narrow port will still be available for use.

So, for example, if you were to enable P8B and P16A on a G4 core, the lower 8 bits of P16A would be available for use, or if you were to enable P8B and P32A, the lower 28 bits of P32A would be available. Or if you were to enable P8B, P16A and P32A, the lower 8 bits of P16A and the lower 20 bits of P32A would be available.

Note that internally the ports always operate at their specified width. You would notice this if, for example, you were serialising data to or from a port with shared pins.

I'll see if we can explain all this more clearly in the documentation.

Who is online

Users browsing this forum: No registered users and 0 guests