XCore Exchange

This would remove the need for mux, and save me the pin that I'll use for selection.

It does blow my wad regarding OTP, though.

I'll need to give it some more thought. I think I'll go ahead with the mux for now, and remove it in a later version, if some different boot options materialize..

Russ, do you need/use all of the 32 pins of the P32A?

You know that the use of P32A doesn't prohibit the use of other "smaller" ports charing the same pins !?
(I hope that was true for Links as well)

So if you only need say 24 pins of 32, you might use the C or D link as well.

russf wrote:Yes, that's a good idea, but I'd prefer not to have to cross the OTP bridge in haste.

Yeah. But you can test OTP code without having to burn it, so development of it isn't
so hard, you just have all the caveats with actually using the parts in production.

@lilltroll : Yes, I knew I could do that, but if I whittle C and or D (both of which I need) down to 2w, I might hurt throughput. At this stage, I'll try to keep my options open (by adding the mux). If It turns out that I have the headroom, I'll do as you suggest.

@segher : OK. Well I might end up putting a boot program in OTP. But I'm not excited about doing the research.

russf wrote:@lilltroll : Yes, I knew I could do that, but if I whittle C and or D (both of which I need) down to 2w, I might hurt throughput.

Can't you use links A and B instead?

You could use (the low 20 bits of) P32A for address and most control bits, and P16B for
the data bits. Nice and clean.

@segher : OK. Well I might end up putting a boot program in OTP. But I'm not excited about doing the research.

Think of it as an exciting new challenge, as a learning opportunity ;-)

>>You could use (the low 20 bits of) P32A for address and most control bits, and P16B for
the data bits. Nice and clean.

Agreed, but if you check the pdf I posted earlier, you'll see the only few ports that remain are circled, and of course LC and LD that I need for the app. That SDRAM design is a pin-hungry beast, but fast.
https://www.xcore.com/forum/download/file.php?id=344

>>]Think of it as an exciting new challenge, as a learning opportunity ;-)
If you knew what was on my plate, you'd know why I'm not looking for yet more learning opportunities... :roll:

But thanks for the humor ;)

--r.

I am surprised... I started this thread just to have the opinions from you experts, and I have seen so much demands... And some answers.

Thanks for the answers, and I think I will stick with SDRAM for simplicity - DDR is just too complex and they like clock in check - but yep, there are such thing as 100MHz DDR, still a bit strict in the way the wirings are laid out.

Thanks.

You guys can still post here, I won't interrupt anymore. Just thanking you guys for some info, that's all.

100 MHz DDR will not work with the current XMOS chips because they can sample up to 60 MHz. If you reduce the frequency to 50 MHz and maybe use 2 8 bit ports for the data lines you may sample on both edges of the clock... I wonder how do you tell the port to sample on the falling instead of on the rising edge... btw now that I think of it DDR DRAM outputs are not stable during the transitions of the clock...
You may be better off with 16 bit SDRAM @50 MHz though... If used for video output, one burst read at 50 MHz can be used per scan line... and the rest of the accesses being done during the blanking periods... just a though.