Tuesday, July 20, 2004

Memory access bytes the big one

I have determined for all intents and purposes that writing a controller to access memory is the worst job on the face of the planet.
 
I want to interface my serial port program on the hardware side with a device that will store received bytes into memory and then, upon receiving a trigger, will write back the whole stored buffer.
 
It is not that it is hard, but it is just a pain in the ass.  You are having to put so much thought and planning to interface something that you did not design.
 
For instance, the board that I am using has 4 banks of 64kx16 RAM.  The initial problem is that I only want to do byte access...  So I have to device some clever way to fool the RAM into giving up bytes out of the 16 bit data that it stores.  Luckily the RAM has byte-high and byte-low read and writes.
 
I could just use one of the bytes and leave the rest be for now, but then I would only be using half of the RAM.  This would be similar to twisting your oreo and only being able to eat half (I know you'd choose the cream side but imagine that one time when there is half cream on both... oooh I knew that would get to you).
 
The next problem is that if I decide to use all 4 banks of RAM then I need some way to multiplex the data busses and address busses because -- of course -- they each are connected to the FPGA separately.
 
I think after considering this I will just access one of the RAMs, this gives me 64Kx16 or 1,048,576 bits of data that I can store in my buffer, this would be equivalent to 131,072 characters (which is more than I have ever written in my life except maybe for this post).
 
Well I suppose I better stop wasting time complaining and get back on the ball...
 
Will post back with schematics when the time is right.
 
Jae reluctantly out

1 Comments:

At 2:34 PM, Jae said...

PS: that post had 1,785 characters for those of you that were counting.

 

Post a Comment

<< Home