6502.org
http://forum.6502.org/

65Org16.x Dev. Board V1.0 using a Spartan 6 XC6LX9-3TQG144
http://forum.6502.org/viewtopic.php?f=10&t=1854		 Page 1 of 17
Author:  ElEctric_EyE [ Sun Jun 05, 2011 1:22 am ]
Post subject:  65Org16.x Dev. Board V1.0 using a Spartan 6 XC6LX9-3TQG144
I've previously bought 6 Spartan 6 XC6LX9-3TQG144 devices to use in my 6502SoC Project. This Spartan 6 device is a much more capable device than the Spartan 3 and would be a perfect fit for a low end 65Org16.x Core. It also has twice the internal BRAM's.

Maybe someone will say: Look at the Virtex 6... I'll have to say I can't solder BGA packages... I look to maximize board "real estate", so for a 144 pin QFP, the Spartan 6 is it. Comparing the Spartan 3 XC3S400-5TQ144 @$23 per part against the $14 XC6SLX9-2TQG144C(an even higher speed S6 than the previously mentioned version), makes it an obvious choice for the 65Org16 IMO. Other Opinions Welcome.

Now this is what made me start this thread: External memory choices.
I would like to use an SDRAM controller and a $11 32MBx16 Micron memory in 66-pin TSOP. But SDRAM to me implies some sort of cache? How about just a 2 cycle burst? So the x16 bit wide SDRAM just looks like a linear address space to the CPU?

I'm going to leave this intial post the most general it can be, in order to invite as much input as possible, and just say I've got my eye on a 10ns 1MBx16 SRAM from Cypress. It is the largest x16 wide SRAM I could find, but @ $29 a piece and 250+mA, it will limit mass storage... Still it is a 1Mx16...

I do have difficulty keeping in mind this should be a development board. I want to maximize the 4GB addressable RAM...

EDIT:Added links.
EDIT:Qualified Thread Title
Author:  Arlet [ Sun Jun 05, 2011 9:14 am ]
Post subject: 
It's a tough choice :)

Even though SDRAM benefits greatly from having a cache, it is certainly possible to start a project without one. The disadvantage will be slightly slower access, but this can be mitigated by putting frequently used parts of the memory in block RAMs instead (stack, zeropage, code). If you're writing your own programs in assembly, it will be hard to fill the block RAMs.
Author:  BigEd [ Sun Jun 05, 2011 9:56 am ]
Post subject: 
Hi EE
I had a look at the userguide for the LX9 microboard which I linked in this post, where on page 9 it says
Quote:
It is highly recommended that anyone creating a Spartan-6 MCB design thoroughly read the two User Guides (UG388 and
UG416), the MIG Master Answer Record 33566, and the associated Answer Records linked from that Master Record
MCB is the Memory Control Block, the free builtin SDRAM controller on some spartan6 devices. Unfortunately, the table on page 13 of UG388 tells us that your chosen LX9 has no MCBs and also gives some insight into how complex an SDRAM controller is. So SDRAM is perhaps going to be extra difficult with your chosen FPGA.

I agree that a cache isn't necessary - a buffer would be sufficient - but the latency will hurt performance unless there's enough cache to keep a healthy hit rate. It seems the effective speed of 167MHz SDRAM might be 14MHz or so for random access. I think SRAM will be the straightforward answer, although as Arlet says, you can help by mapping block RAM into important places.

(However, I don't think 4Gbyte is necessary to show off the advantages of 65Org16. Even with just 64k of memory, having the whole of memory available for zero page, for stack, and having reasonable size buffers accessible with single-word indexes are all advantages available at once. Anyone concerned about stack overflowing into data areas need only fit 256k of memory to have 64k of dedicated stack. [or make a variant CPU with a smaller stack pointer.])

1 Mbit SRAM is 64kwords x 16 - is that the size you have in mind? (I recommend you spell out Mbit and Mbyte to avoid confusion!)

Cheers
Ed
Author:  Arlet [ Sun Jun 05, 2011 10:32 am ]
Post subject: 
A plain SDRAM controller isn't too hard to design in the fabric, so you wouldn't have to worry about the MCB.

Pure random access is pretty bad (even with a cache), but random access within the same row only results in a latency of 2 or 3 cycles. The size of the row depends on the chip, but is around 1kB. You can make the memory controller smart enough to keep the row activated after an access.

Doing random reads from 10 ns SRAM at 100 MHz clock speed takes 3 cycles, so the difference isn't really all that big.
Author:  ElEctric_EyE [ Sun Jun 05, 2011 12:28 pm ]
Post subject: 
Note: When I say MB I mean Megabyte. Mb=Megabit.

Arlet wrote:
... If you're writing your own programs in assembly, it will be hard to fill the block RAMs.


I did forget to mention, I do intend for all the BRAMs to be used as ROM for the user code. Not sure yet, but I think that it will be a max of 32Kx16. The 1MBx16 SRAM will be at the bottom of memory to cover zero page stack: $0000_0000-$000F_FFFF.
Author:  Arlet [ Sun Jun 05, 2011 1:13 pm ]
Post subject: 
I think you'll get better performance if you use block RAM for frequently executed code, or interrupt handlers, and use external RAM for the rest of the code. That way, you can use some of the block RAMs for stack/zero page.

You can still use the block RAMs as code storage. After init, copy the contents of the block RAMs to external RAM, and then reuse the same blocks as zero page/stack.

Also, running code from external RAM (even SDRAM) isn't so bad, because often you'll need several bytes in sequence, and you can program the memory controller so that it will start a burst at every read, so the next byte will be ready when the CPU needs it. For straight stretches of code, that only access internal memory, that means you can run at full speed.
Author:  ElEctric_EyE [ Sun Jun 05, 2011 1:16 pm ]
Post subject: 
Arlet wrote:
A plain SDRAM controller isn't too hard to design in the fabric, so you wouldn't have to worry about the MCB...

Do you have the time to do this?
Author:  Arlet [ Sun Jun 05, 2011 1:33 pm ]
Post subject: 
Sure, I have already made one. It needs to be optimized a bit for this purpose, but that's not a lot of work.

By the way, the Spartan-6 also allows configuration by external SPI Flash, instead of the Xilinx PROMs. The nice thing about this is that after configuration, the SPI pins turn into user I/O, so you can access the SPI Flash from the FPGA. If you take a bigger Flash device than needed for the FPGA configuration, you can store user data in the Flash, and copy it to the external RAM. (Edit: see XAPP951)
Author:  ElEctric_EyE [ Sun Jun 05, 2011 5:46 pm ]
Post subject: 
Arlet wrote:
I think you'll get better performance if you use block RAM for frequently executed code, or interrupt handlers, and use external RAM for the rest of the code. That way, you can use some of the block RAMs for stack/zero page...

Ah you're right. Maybe 256 bytes for the bottom of zero page ($0000_0000-0000_00FF) and 256 bytes for top of stack ($0001_FF00-$0001_FFFF) should be good! The rest for code. The external RAM ($0000_0000-$000F_FFFF) would be not active when the internal zero page or stack was active.

Arlet wrote:
Sure, I have already made one. It needs to be optimized a bit for this purpose, but that's not a lot of work...

Good! The part I have in mind is a 200MHz -5 speed grade that is mentioned in the first post. The link is there. Is this speed realistic?

Arlet wrote:
...By the way, the Spartan-6 also allows configuration by external SPI Flash... you can store user data in the Flash, and copy it to the external RAM. (Edit: see XAPP951)

I've seen the Xess boards use them. Consider it in the design then. I'll search for a suitable device.
Author:  Arlet [ Sun Jun 05, 2011 6:02 pm ]
Post subject: 
Quote:
Good! The part I have in mind is a 200MHz -5 speed grade that is mentioned in the first post. The link is there. Is this speed realistic?


The easiest way to test this, is to run a constrained synthesis with the code you have now, but with the new part selected. I'm guessing 200 MHz is probably a bit too much for the core.
Author:  ElEctric_EyE [ Sun Jun 05, 2011 7:33 pm ]
Post subject: 
Right, I don't have the time to test SDRAM config's. I should probably stick with SRAM.

Looking at an SPI Flash, since the S6 will need 2.6Mb for programming, an 8Mb device would leave ~350KBx16. Getting the config data to the Flash seems to still be supported by iMPACT. Now how to get .bin data (user programs) to the remaining part of the Flash...
Author:  Arlet [ Sun Jun 05, 2011 7:46 pm ]
Post subject: 
For the max clock speed, it doesn't matter if you take SRAM or SDRAM. My SDRAM controller was used in a project where it was running at 100 MHz on a Spartan-3, much faster than the 6502 core. I'm expecting that on a Spartan-6, the core will also be the limiting factor.

To get the max speed, you can just take the project you have now, change the device settings, and provide a rudimentary .ucf file with valid pin numbers.
Author:  ElEctric_EyE [ Sun Jun 05, 2011 7:56 pm ]
Post subject: 
Hmmmm. I did mean a -5 speed grade for the SDRAM.

Your controller could then run <=200MHz?, but at least >100MHz since this is a Spartan 6, not a Spartan 3.
Author:  Arlet [ Sun Jun 05, 2011 8:15 pm ]
Post subject: 
Ah, I see that you were referring to a DDR SDRAM chip. My controller can only handle the old fashioned SDRAMs, not the DDR.

Regular SDRAM is available in TSOP, e.g. MT48LC16M16A2TG-7E, 256Mbit, for $13, max speed 133 MHz. That would give you a top speed of somewhere between 100 and 133 MHz, depending on how far the core can be pushed.
Author:  ElEctric_EyE [ Sun Jun 05, 2011 10:25 pm ]
Post subject: 
Just got home from work, sorry for slow responses all day.
Will recheck and update my initial post on this thread soon. My fault for thinking it was DDR. I just now rechecked your original post on your SDRAM controller. Not actually a big deal though. 16MBx16 SDRAM is a decent size!
Checking your original IC you had mentioned on Daryl's SBC thread, it is available @166MHz speed. So maybe is the one you just pointed out. I'll check that, because top speed will not be sacrificed for bloated memory.

I'll go back and rework the design for the internal BRAMs to be used for a limited zero page and limited stack as I mentioned earlier.
Page 1 of 17 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/