I have two Avnet Spartan-3A 400 development boards. These boards have no external RAM, so any designs I did with them had access only to the RAM inside the FPGA.

I bought some Microchip 23K256 I/P SPI SRAM ICs to use with the FPGA board. The SRAM ICs are spec'd for a max SPI clock rate of 20 MHz. I was able to wire up a piece of stripboard to an IDE cable to plug into the board's 40 pin GPIO connector. The stripboard has 2 of the ICs connected using separate SPI busses. This allows data transfers of 16 bits instead of only 8.

After much banging and swearing, I got it working. I had a board construction error and many driver state machine problems, but it's now working. I've written a simple RAM diagnostic design that writes the inverted address as data, then reads back and compares, increment address and repeat.

The test ran overnight with no errors at SPI clock rate of 25.0 MHz. So the test is actually overclocking the SRAMs. And the ICs run cold.

Nice cheap way to get about 0.743 seconds of mono delay at 44.1 kHz sample rate.

EDIT ADD: The RAMs, while they passed the simple diagnostic test, did not function correctly in a delay effect when run at 25 MHz SPI clock. They did, however, function correctly when clocked at 20 MHz in the same application.

EDIT ADD: These RAMs, produced by Microchip seem like a nice addition to a dsPIC. The dsPIC has a built in SPI port which does all of the ugly SPI stuff without dsPIC code._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

So far, I've written several diagnostic tests. All of them work up to 20 MHz SPI clock. Some work up to 25 MHz SPI clock. Patterns are all zeroes, all ones, 0x5555, 0xAAAA, data=address, data=inverted address. These are written to each location and checked as soon as written. There is also random data test where all 32K is written with a seeded LFSR. It is reseeded to produce the same sequence for the read pass. All of these work.

What is still vexing me is that I've been able to integrate the RAM as a part of a synth project, it works only marginally. I hear the instrument and the delayed playback has noise in it. Of note might be that the design is croweded at 74% of the slices available. This causes a timing violation with respect to the IO pads used for the SPI busses. The violation states that it takes too long for a signal to go from it's last flip flop to the IO pad. I need to find a way to force that flip flop to be in the IOB (IO buffer)._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

I was able to tell ISE to "try" to place final flip-flops to FPGA pins inside the IOBs. This reduced the amount of the timing constraint violation and at the same time greatly reduced the echo noise I hear.

This is telling me that the crowded nature of the design (74% of slices) has made it difficult to efficiently route the signals going to FPGA pins.

I'm not sure how successful I will be at this, but the next step seems to be to lean the design. There are now some 14 block RAMs available, so perhaps I can eliminate some of the distributed RAM allocation in favor of block RAM and reduce the numbers of LUTs used as small RAMs.

Since the violation concerns the CS pin on the SRAM, I might be able to simply move that one clock earlier and eliminate the noise entirely??? Hope springs eternal._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

As I looked at the timing constraint violations, I saw that they pointed to two of the pins I was using for the SPI interfaces.

I knew that if I converted the SRAM board from 2 parallel SPI busses to a single shared SPI buss, I could eliminate 3 FPGA pins.

Sure enough, while this is slower (twice as long to read or write 16 bits), it solved the timing problem. It now takes 256 system clocks to do the read and write work, but that's less than the 768 allowed, so it works. All of the noise on echo is gone! _________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Hi
I was also looking for some type of volatile ram that use few pins.
I was looking for this SPI ram from microchip, but the size/price ratio is bad.. for almost the same price is possible to get an huge DRAM (that uses lots of PINs)..

I'm not aware of anything with a better price ratio. Static RAM is the easiest to use, but it's not very dense because it uses about 6 transistors per bit. DRAM not only has many many pins, it also requires a controller that handles the refreshing and arbitration of data access with refreshing. There is also the more standard form of static RAM which is simple, but still pretty small and will have lots of pins. I chose the 23K256 because it was the biggest SPI SRAM I could find._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

I have recently been successful in connecting a 23K256 SPI SRAM to a dsPIC33F using SPI at 10 megabits per second. The conductors for SPI are 2.5 inches long and have no termination (no termination is suggested by the manufacturer, Microchip). The device has run a random data reliability test for more than 24 hours with zero errors, so this looks to be a possible solution for external SRAM. At 10 megabits per second, a maximum data rate of 312.5 kbytes per second is possible. I am currently working to put this under DMA control since the code required to manage the SPI transfers is quite a burden (IMO). But the bottom line for now is that it works._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

I have two Avnet Spartan-3A 400 development boards. These boards have no external RAM, so any designs I did with them had access only to the RAM inside the FPGA.

I bought some Microchip 23K256 I/P SPI SRAM ICs to use with the FPGA board. The SRAM ICs are spec'd for a max SPI clock rate of 20 MHz. I was able to wire up a piece of stripboard to an IDE cable to plug into the board's 40 pin GPIO connector. The stripboard has 2 of the ICs connected using separate SPI busses. This allows data transfers of 16 bits instead of only 8.

After much banging and swearing, I got it working. I had a board construction error and many driver state machine problems, but it's now working. I've written a simple RAM diagnostic design that writes the inverted address as data, then reads back and compares, increment address and repeat.

The test ran overnight with no errors at SPI clock rate of 25.0 MHz. So the test is actually overclocking the SRAMs. And the ICs run cold.

Nice cheap way to get about 0.743 seconds of mono delay at 44.1 kHz sample rate.

EDIT ADD: The RAMs, while they passed the simple diagnostic test, did not function correctly in a delay effect when run at 25 MHz SPI clock. They did, however, function correctly when clocked at 20 MHz in the same application.

EDIT ADD: These RAMs, produced by Microchip seem like a nice addition to a dsPIC. The dsPIC has a built in SPI port which does all of the ugly SPI stuff without dsPIC code.

We used these for a class I took recently.
I think they may be expensive compared to other ram varieties, but the instructor gave them to us for the class project.

I looked up the FM25V01 part at Mouser which lists it at $6.03 each for quantities of 10. It is also a 16 kilobyte FRAM (where FRAM is nonvolatile ferroelectric RAM). As such, it's main advantage is that it's nonvolatile with 10 year retention span. This FRAM will run twice as fast as the 23K256, but dealing with a dsPIC SPI channel, this is no advantage because the dsPIC can do at best only 10 megabits per second.

The 23K256 is a 32 kilobyte SRAM (twice the size of FM25V01) and can be purchased for about $1.35.

23K256 is not expensive when compared with the FM25V01.

So the RAM one would select here would depend on the application. If nonvolatility is not required, then paying $6.00 for half the RAM would be quite expensive.

Also, Microchip has 23A1024 which is 1024 kbits (128 kbytes) priced at $1.73 and runs at the same speed as 23K256. Microchip shows that samples are available (which I am going to acquire)._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Here is the source code for the dsPIC33F using 23K256 SPI SRAM diagnostic program.

The program operates by generating 32768 pseudo random 8 bit numbers using a 32 bit LFSR and storing them in successive bytes of SPI SRAM. The program then reseeds the random generator and generates the same stream of random numbers again. This time, they are compared with data read from SPI SRAM. This is not a "project", you will need to set that up. The files in the zip are just source. linker script and other include files need to be supplied by the user. I'm using MPLAB ver 8.87.00.00.

EDIT ADD: The souce is not at all cleaned up and may have inaccurate comments as well as commented out code meant to diagnose it.

I have now soldered the 23LC1024 device into the board. I have set pin 3 to Vcc (reading AN1484 from Microchip). I modified the diagnostic and of course it doesn't work. I looked at the output with an oscope (SO pin on the SRAM chip) and it wasn't toggling, then I unsoldered the dsPIC pin from it so I'm seeing just the data coming from the SRAM chip and it's always low. I can see 5 bursts of 8 clock pulses, so that part is working (at least I get the 40 clocks required).

Now I am going to try another program that just repeatedly reads the mode register. Hopefully, that leads me to the problem.

I've written a simple program to write and read the mode register and I get zeros for data. To make sure that the dsPIC pin receiving data from the SRAM is not holding it at ground, I removed the wire and scoped SRAM pin 2, stays at ground.

I can see clocks and I can see data, both pins toggle between Vcc and Vss.

Scoping SRAM pin 2 I see Vss all the time...

I keep thinking I should replace the SRAM chip. I have another free sample.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; *** IMPORTANT ***
;
; THE FOLLOWING INSTRUCTION SEQUENCE WORKS TO PLACE THE dsPIC INTO HSPLL MODE
; RUNNING AT 40 MIPS. HOWEVER, IT WILL NOT RUN AFTER A PROGRAM OPERATION BY
; JUST SETTING MCLR TO Vdd. YOU MUST POWER CYCLE TO START THE PROCESSOR.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; From Tom Wiltshire - to get dsPIC running at 40 MIPS with 20 MHz xtal
;.....................................................................
; Set up Oscillator, PLL, DAC and all Pre/Postscalers
; We use the HS osc with external 20MHz crystal
;.....................................................................

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Set up to use UART1 as TTY out 115.2 kbaud. Pin 21 RP10

I've replaced the 23LC1024 with a new one. It does the same thing as the other one. I'm out of free samples at this point. When a 23K256 is soldered in, there is toggling on it's pin 2. When a 23LC1024 is soldered in, there is no toggling of pin 2. The instructions for reading and writing the mode/status is the same for both ICs.

I'm using the code posted above. All it does is provide a "scope loop". there should be some toggling of the SO output from the SRAM.

I haven't dug too deep into your code, mainly because it worked with the '256 and you made adjustments to the adr length. So I'm thinking you could have s slight difference between the two chips. I found a note in the 23xx1024 DS in Fig 3.8 that notes 3 Pin should not be left floating with Non-SQI operations.The text doesn't say a word about that and the pin diag shows it as NC. This is different then on the '256 where Pin 3 is a NC. Don't know if you made this change to you layout and don't know what happens if it IS floating but that's the only diff I can see so far.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.