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

65Org16.x Dev. Board V1.1 using a Spartan 6 XC6SLX9-3TQG144
http://forum.6502.org/viewtopic.php?f=10&t=1978		 Page 2 of 19
Author:  Arlet [ Sun Oct 30, 2011 6:38 pm ]
Post subject: 
ElEctric_EyE wrote:
Arlet wrote:
Yes, a block RAM. And you'd use the whole thing, so when the CPU is doing something else, you can read long bursts for the video...

This pretty much means this Spartan 6 would be dedicated for video. I was using block RAMs for zero page, stack and ROM for the 65Org16.

You can still do that. You'd only need one of the block RAMs for video FIFO, and you can still use the other ones for zero page, stack and ROM. But if you don't want to waste a block RAM on video, you can also make a small RAM out of LUTs. The beauty of the FPGA is that you can also make different decisions for various projects. Have you calculated how much zero page, stack and ROM you need for your project ? Maybe you won't even need all of it.

Quote:
How does that work? Does it just truncate a byte?


No, you put one 16 bit word in one side, and get the two bytes out in succession on the other side. You can also convert other widths. I believe that it will go from 1 bit to 32 bit, and the other way around.
Author:  ElEctric_EyE [ Sun Oct 30, 2011 10:32 pm ]
Post subject: 
Arlet wrote:
... But if you don't want to waste a block RAM on video, you can also make a small RAM out of LUTs. The beauty of the FPGA is that you can also make different decisions for various projects. Have you calculated how much zero page, stack and ROM you need for your project ? Maybe you won't even need all of it...

I wouldn't say waste, especially since this is supposed to be a gaming type development system. I think I misread your earlier statement "Yes, a block RAM. And you'd use the whole thing" a couple posts ago.
I think 512x16 words for zero page, 256x16 words for stack, and 16Kx16 words for ROM (8Kx16 of which would be dedicated to one of the machine code monitors (original 4Kx8) mentioned at the beginning of the thread) would suffice for a most basic "OS". Instead of booting into a high level language like BASIC on the C-64 for example, you'd be "in the guts" already at power on in this system.

I've been mulling over the video part of the project utilizing SDRAM all day at work. A couple questions...

1) If one can use an SDRAM for video, then surely the concept would be fully understood in order for one to use it more like an asynchronous static ram, say for CPU code storage on a different SDRAM?

If I were to think of what we have been recently talking about regarding FIFO, etc. and try to make this come about using schematics, I would have been daunted and would have quit or tried something easier (like monochrome graphics and a 6845 core. This has been planned for in the layout!). But I think I can grasp the Verilog beginnings, at least my attitude is positive about grasping the concept of putting this in Verilog, which leads me to my last question:

2) Place your cpu.v/ALU.v core at a level 10 of difficulty. What level of difficulty is the type of video interface which we have been discussing?
Author:  Arlet [ Mon Oct 31, 2011 6:29 am ]
Post subject: 
Yes, it would be fine to use the SDRAM for additional code/data storage. Especially now that the core has a RDY input, hooking up the SDRAM as if it were a regular asynchronous RAM would be quite easy. It would just be a bit slower, but there are a number of ways that could be improved. You probably won't even need a separate SDRAM. Video bandwidth is relatively low due to fairly low resolution, which would leave most of the bandwidth for the CPU.

For copying large amounts of SDRAM data, it's always possible to add a DMA controller that 'understands' how to address the SDRAM for maximum performance.

I'd say the complexity of the SDRAM controller varies between 7 and 12, depending on how optimized you wanted it to be. I've already finished a fairly simple controller that could be dropped in without much work. The arbiter would be fairly simple, I guess around 5.
Author:  ElEctric_EyE [ Tue Nov 01, 2011 12:59 am ]
Post subject: 
Arlet wrote:
...I'd say the complexity of the SDRAM controller varies between 7 and 12, depending on how optimized you wanted it to be. I've already finished a fairly simple controller that could be dropped in without much work. The arbiter would be fairly simple, I guess around 5.

I've downloaded your SDRAM controller before. It's further down on this thread... I know it's for a different SDRAM than I am using and that certain variables will need to be tweaked.
Been a long day at work, but I had to post an update of sorts.
Author:  Arlet [ Tue Nov 01, 2011 9:55 am ]
Post subject: 
ElEctric_EyE wrote:
I've downloaded your SDRAM controller before. It's further down on this thread... I know it's for a different SDRAM than I am using and that certain variables will need to be tweaked.
Been a long day at work, but I had to post an update of sorts.


Micron has free downloads of Verilog models for their SDRAMs, if you want to do some simulations.
Author:  ElEctric_EyE [ Tue Nov 01, 2011 11:34 am ]
Post subject: 
The SDRAM I've chosen is the 16Mx16Micron MT48LC16M16A2P-6A 54-pin TSOPII. $5.23ea from Avnet. Keeping my eye on the MT48LC32M16A2 32Mx16 54-pin TSOPII, price seems to have come down to $25ea. Used to be $38ea, still too much...

So, I am trying to understand the operation of SDRAM.
Looking at the functional block diag. on pg.10, I see that the memory is organized as 4 banks of 8192x512. I see the pins A0-A12 for the 8192 row address, and the 2 bank pins, but no pins for the 512 column address. I will read on, they must be multiplexed, ugh!

EDIT: Fixed protected link.
Author:  Arlet [ Tue Nov 01, 2011 11:50 am ]
Post subject: 
Correct. To perform a read or write, you must first activate a row. This is done by sending an ACTIVATE command, together with a row number on the address bits, and a bank number, and waiting a few cycles. After that, you can either send a READ or WRITE command with the column address, using the same address bits.

After you're done accessing a row, you need to precharge it before opening the next row.

As you can see, performing a single random access read or write takes quite a few cycles, that's why access to SDRAM should happen in bursts as much as possible. In addition, you need to worry about refreshing the SDRAM on a regular basis.

The SDRAM controller code takes care of all of this.
Author:  ElEctric_EyE [ Tue Nov 01, 2011 12:29 pm ]
Post subject: 
Ah, ok I see the commands table on pg.31. Send it 2 commands with the address embedded within the commands. That's not too bad...

So when it does a burst read or write, it is getting data from successive columns.

On the command table there is a LMR, Load Mode Register. The bits defining the LMR are on pg.46.

Arlet wrote:
...The SDRAM controller code takes care of all of this.

Yes, checking it out. Maybe now I can make some heads and tails of it. I've made a symbol of it to see the I/O's and get a general feel. I see the CPU sends a read & write address A0-A21 (2M), but the SDRAM you used is a 4Mx16. Did you only use half of the RAM?

EDIT:Oops, A0-A21 is 4M.

Symbol:
Image
Author:  Arlet [ Tue Nov 01, 2011 12:48 pm ]
Post subject: 
ElEctric_EyE wrote:
Yes, checking it out. Maybe now I can make some heads and tails of it. I've made a symbol of it to see the I/O's and get a general feel. I see the CPU sends a read & write address A0-A21 (2M), but the SDRAM you used is a 4Mx16. Did you only use half of the RAM?


The A0-A21 refer to the 16-bit word address, so it's also 4Mx16. I didn't have byte addressing, and the 6502 wasn't hooked up directly to the SDRAM. I used a block RAM to map part of the SDRAM into the 6502 address space, and a separate DMA controller to move big bursts from SDRAM to block RAM, and back. The dual port block RAM had a 8 bit interface on one port (connected to CPU), and a 16 bit interface on the other port (connected to SDRAM).
Author:  Arlet [ Tue Nov 01, 2011 12:56 pm ]
Post subject: 
ElEctric_EyE wrote:
So when it does a burst read or write, it is getting data from successive columns.


Usually, but it's also possible to change the column address with each read/write cycle, so you can do random access within one page.
Author:  ElEctric_EyE [ Tue Nov 01, 2011 1:15 pm ]
Post subject: 
Ok, fixed the link.

What size block RAM did you use?

As far as your code, the only thing I should have to modify to make it work with the 16M SDRAM is the Address length?

This will have to be the end of my progress on the SDRAM front for now, before I start experimenting with some code. I feel pretty confident with merging buses with Verilog now using registers.

I need to head back to the project and try and tie up some loose ends to get the display working again. And then back to trying to make the I2C work (not related to SDRAM). Then I would like to come back and test reading/writing the SDRAM data to the display. Thanks for your help!
Author:  Arlet [ Tue Nov 01, 2011 1:23 pm ]
Post subject: 
ElEctric_EyE wrote:
What size block RAM did you use?


2KB. That's the native Spartan3 block RAM size, but you can make bigger ones by combining several.

Quote:
As far as your code, the only thing I should have to modify to make it work with the 16M SDRAM is the Address length?


The address length, yes, but also the page size which is 512 words (9 bit) instead of 256 words (8 bit). This means that the end_of_page/end_of_rd_page signals need to be modified, as well as the sdram_ba, and sdram_addr assignments. You also need to check the sdram_delay values, and the refresh period.
Author:  ElEctric_EyE [ Wed Nov 02, 2011 6:42 pm ]
Post subject: 
I should've thought of that...

I spent a few hours today working with the Spartan 6. ISE is being very strict in not allowing timing signals to go offboard, except if the user adds very specific commands in the .ucf file. Spartan 6 series appears to have been made to give priority for DDR timing signals and assumes all timing signal going offchip are for such...

I need to take a break from troubleshooting for a couple reasons:

1) Troubleshooting within ISE is usually the most exasperating compared to software or board design/layout. Alot of effort must be expended with little reward until the final goal has been reached and the circuit works. On a good note, I've checked my wiring and most everything seems to be in order, except the MCP2200 which when not powered by the USB can drag down/add noise some lines. Most importantly, the reset line. So I've unsoldered and lifted that pin off the board.

2) I need to take 2 ASE tests for my job as auto tech, in the next 2 weeks, so I need to study. Hopefully, I will be refreshed after I pass at least 1 of those tests. 1 is most difficult...

I will be lurking as usual. :wink:
Author:  ElEctric_EyE [ Thu Nov 03, 2011 11:54 pm ]
Post subject: 
Clock forwarding is the topic I needed to investigate, in order to bring an original clock source within the FPGA out to a pad/pin.
With the Spartan 6, timing is indeed much more strictly controlled so it seems some extra measures are needed. I tried to tap off of an internal Phase2 clock and put it through an output buffer for the TFT, like I did with the Spartan 3 successfully. It was easy enough with the Spartan 3 series... When I try to do the same tap from an internal clock on the Spartan 6, it is expecting another input, not an output signal. This thread on Xilinx forums explains it better, the poster is experiencing the same problem.

I will not be able to test this theory until 2 weeks, but I thought I would post my findings.

Also, I found out the Spartan 6 has the ability to set I2C style outputs. Previously, I've been setting all outputs for LVTTL...
Author:  Arlet [ Fri Nov 04, 2011 6:44 am ]
Post subject: 
If you mind don't that the clock gets divided by two, you can use a simple toggle flip-flop on the output.

Otherwise, you'd have to instantiate a DDR flip-flop like the thread says. I've done the same thing on my Spartan-3 design to get the SDRAM clock off the chip.

Basically you should never use combinatorial logic to get signals off the chip, because you get glitches and poor control on timing. Instead, always register the signals, and put the logic in front of the register.
Page 2 of 19 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/