Suggested DRAM type usage...

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Re: Suggested DRAM type usage...

Postby dan » Fri Mar 04, 2011 3:00 pm

OK so I've asked about this and basically, you're right. We do have an L2 sdram driver that does 12.5 because of the reasons you set out. Its partly written in ASM, and is shall we say, under optimised. I don't see a problem with releasing that code to be incorporated in the xcore sdram repo, but I'll have to check and get back to you.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Fri Mar 04, 2011 3:27 pm

Thanks Dan

I would definitely be interested in looking at the code and seeing the sort of results you guys are getting (I'm sure others would also) as I have not to date seen an L2 SDRAM implementation.

regards
Al
Last edited by Folknology on Fri Mar 04, 2011 3:52 pm, edited 1 time in total.
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Postby dan » Fri Mar 04, 2011 3:49 pm

OK when russ has his repo setup I'll make a pull request to it with the code in question in it.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Fri Mar 04, 2011 8:30 pm

If you UK guys are not all down the pub already....

I've just been smacked by the SDRAM design for the L1-128TQFP. it's using P4D for the several control lines, when I need that 2w Link to be the boot path from the upstream processor.

There are very few free I/0 lines with this design, so I think the best move will be to multiplex those 4 bits, ensuring they come up as 2w link on reset, then switch to the control lines once the processor is up.

Can anyone suggest any other angles, or tips?

--r.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Fri Mar 04, 2011 9:25 pm

If you UK guys are not all down the pub already....
Oh wish I was! I am just starting a complete redesign of the L2 Amino version in Kicad

Multiplexing those lines sounds rather painful and I can't believe you ran out of pins on a L1-128!

What else is on the L1 connection wise?
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Fri Mar 04, 2011 9:47 pm

I can hardly believe it myself.

The design is a nice proof-of-concept, but since it uses X0D0 and all the XLA pins for the ram, it means it can only be loaded from OTP or JTAG. It was probably never used "in anger".

I attach a pdf with my allocations. Apart from XLC and XLD, there are 5 1b ports free. But it does not look simple to patch the command stuff from P4D onto those pins, because P4D is used buffered and clocked. That's the kind of risk I want to avoid at this stage.

I did not want another device, but it *is* an easy way around. Of course it does use another pin to switch the bus. We can look for a better answer later, but not for this board.

Soooo... it looks like I'll use this http://www.fairchildsemi.com/ds/FS/FST3257.pdf It's a 3v part, unlike some other variants which are 4v.
You do not have the required permissions to view the files attached to this post.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Fri Mar 04, 2011 11:41 pm

I'll be very interested in any comments on my cunning mux plan....

Background: I'm implementing the XMOS sdram design.

Goal: I need XLB 2w to link to the master node at boot time, and then switch so that the existing code can drive Port 4D, to control the DRAM.

Options are few. I don't want to redevelop the code at this stage, and I must get a layout to the FAB asap. -- I need to go with what I've got, and trust that the SDRAM code is workable.

Answer: Mux the X0d[16..19] between the bootstrap link XLB and the DRAM device.

Principle of op: RAMCTL_N is on X0D23 and will be un-driven at reset (all ports are inputs), therefore pull high. High on the S pin enables the B2 side of the mux, which enables the link. Once the network is loaded, the ram driver will pull RAMCTL_N low, thus enabling the B1 side of the mux, and allowing DRAM control. RAMCTL_N will remain low until the next reset.

If anyone else has implemented this in anger, they will have crossed this bridge. Any comments?

--r
You do not have the required permissions to view the files attached to this post.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Mar 05, 2011 12:24 pm

Hi Russ

I can see what your doing, but how will L1-128 communicate with the other XS1 cores on the board if that link is muxed out for the memory control during normal usage?

Clearly the link would have to be mapped in the XN file along with the other links, but then somehow is the software you are unmapping the link and mapping a port, this isn't something I have ever done might be some Assembly required for that kind of voodoo, particularly if your turning the link on and off dynamically.

Are you using Links B and C to the other XS1 I can't quite tell from the table? if so maybe you could use these to boot with your own OTP code, again some assembly, required but it removes the ugly muxing.

regards
Al
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Sat Mar 05, 2011 4:10 pm

Folknology wrote: I can see what your doing, but how will L1-128 communicate with the other XS1 cores on the board if that link is muxed out for the memory control during normal usage?
I have dedicated the XLC and XLD both 5w to communication up and down. The issue was that I could not boot over either of them, so I switch in XLB 2w just for the reset/boot.
Folknology wrote: Clearly the link would have to be mapped in the XN file along with the other links, but then somehow is the software you are unmapping the link and mapping a port, this isn't something I have ever done might be some Assembly required for that kind of voodoo, particularly if your turning the link on and off dynamically.
Excellent point.

I was anticipating I'd map both the 5w and this special 2w link in the XN file, for the purpose of booting, but never actually define either end of this 2w link within any code, so no traffic should ever try to traverse that link.

Am I missing something here?
Folknology wrote: Are you using Links B and C to the other XS1 I can't quite tell from the table? if so maybe you could use these to boot with your own OTP code, again some assembly, required but it removes the ugly muxing.
Yes, that's a good idea, but I'd prefer not to have to cross the OTP bridge in haste.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Mar 05, 2011 4:43 pm

Sorry I meant links C and D rather than B, that would be what I would probably opt for rather than muxing, and then ask for help on the OTP front, I'm sure Xmos or others must have done this sort of thing before.

Can anyone help Russ out with some OTP boot code to boot over C or D links?

regards
Al

Who is online

Users browsing this forum: No registered users and 1 guest