Suggested DRAM type usage...
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.
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
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
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.
OK when russ has his repo setup I'll make a pull request to it with the code in question in it.
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.
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.
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
Oh wish I was! I am just starting a complete redesign of the L2 Amino version in KicadIf you UK guys are not all down the pub already....
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?
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.
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.
- Attachments
-
- 2011_03_04 Proc 1 IO.pdf
- (150.14 KiB) Downloaded 291 times
2011_03_04 Proc 1 IO.pdf- (150.14 KiB) Downloaded 291 times
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
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
- Attachments
-
- Screen shot 2011-03-04 at 2.29.53 PM.png
- (22.42 KiB) Not downloaded yet
Screen shot 2011-03-04 at 2.29.53 PM.png- (22.42 KiB) Not downloaded yet
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
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
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
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: 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?
Excellent point.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.
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?
Yes, that's a good idea, but I'd prefer not to have to cross the OTP bridge in haste.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.
-
Folknology
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
- Contact:
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
Can anyone help Russ out with some OTP boot code to boot over C or D links?
regards
Al