RetroBSD

2.11BSD operating system for microcontrollers
It is currently Tue Sep 25, 2018 1:12 am

All times are UTC




Post new topic Reply to topic  [ 94 posts ]  Go to page 1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Sep 02, 2011 10:12 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I'm wondering if the following idea has any merit - connect a 512k x 16 bit static ram to the 16 bit port on the cpu and use it for swap space. It should be significantly faster than the sd card and it would mostly eliminate the issue of wearing out the sd card. Does anyone have any thoughts on whether or not this would be worthwhile?


Top
 Profile  
 
PostPosted: Fri Sep 02, 2011 12:38 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Yes, it's really a good idea. It will use a lot of cpu pins, though. Better solution would be to use a simple PLD as SPI interface to external SRAM.

_________________
--Serge


Top
 Profile  
 
PostPosted: Fri Sep 02, 2011 4:30 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
There were offline discussions on that in past. For example, you may use FRAM (e.g. FM25H20, 256kx8, SPI 40MHZ, 8pin), but frams are expensive. Or you may connect sdram (e.g. those from older pc dimms) of any size (e.g. you need ~28 pins for a 16MByte one), or any kind of interface to any kind of sram/dram.
The SPI on pic32 is quite slow however, only max 25MHz, it is not proven that 40MHz (brg=0) works reliably. With DMA and above FRAM you may achieve r/w speeds 3MByte/sec max (@25MHz SPI) for large blocks. You need 8pcs of it for 2MByte swap.
Maybe MCHP will come with a native 4bit high-speed sdhc interface soon (;-)..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Tue Sep 06, 2011 6:03 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
As the r304 speed up the job switching significantly, and therefore swap r/w, it seems the swap cannot be held on sdcard for too long. What can I do (as a proof of concept) is to connect one fram 256kx8 to a separate spi channel. This would require to redirect r/w of swap to spi3 or 4. So for the future we may need 3 spi channels - for example spi1 and spi2 for sd0, sd1 and spi3 for swap.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Tue Sep 06, 2011 1:13 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Separate swap device is great. But 256kbytes is not enough: 1Mbyte is needed. Several FRAM chips could be put on the same SPI port, with different select pins.
--Serge

_________________
--Serge


Top
 Profile  
 
PostPosted: Tue Sep 06, 2011 4:26 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Of course, but I've got only one :).

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Fri Sep 09, 2011 10:39 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I just ran across the following design for attaching an SDRAM chip to a PIC32:

http://retromaster.wordpress.com/pic32/interfacing-sdram-to-pic32/

It might make for a very cost effective method of adding a large amount of swap, at the cost of some performance and the loss of a lot of pins. I don't know if the requirement to disable interrupts while accessing the ram would be a problem or not.


Top
 Profile  
 
PostPosted: Fri Sep 09, 2011 12:28 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1079
Location: Sunnyvale, CA
Interesting solution. Disabling interrupts is not a problem. But why not to use a simple SRAM 2Mx8? How many glue logic will it require?
--Serge

_________________
--Serge


Top
 Profile  
 
PostPosted: Fri Sep 09, 2011 1:39 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
No really good reason other than the SRAMs turn out to be relatively expensive. 256K x 8 chips are really quite cheap, but the 2M x 8 chips seem to be in the $10 to $20 dollar range, or are only available in BGA formats so far as I've found. That seems excessive to me for this project. However, adding a $2 to $5 chip seems very reasonable.



Top
 Profile  
 
PostPosted: Sat Oct 01, 2011 1:41 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I've managed to connect a 8M x 16 SDRAM chip (only 8 data lines used) that was scavenged from a dead hard drive to a UBW32 board. After converting the previously referenced code to compile using the chipkit compiler, making some adjustments in order to avoid using PORTE and for the layout of the SDRAM chip, and fixing a couple of bugs, the 8 megs can be read/written in 512 byte blocks. Read/Write speed is just shy of 6MB/s.

The tentative plan at this point is:
1) Rewire the address lines and adjust code to make it easier to adjust for different SDRAM chips.
2) Do more extensive testing to verify reliability.
3) Add support to the Retrobsd startup code for ram-based code in the kernel (as the SDRAM primitives must be run from ram due to timing).
4) Create a simple patch to Retrobsd to read/write the swap blocks from/to the ram as an initial test.
5) Attempt to figure out how to set up the ram chip as a real block device, as there is 6 MB free even with a 2MB swap - it might make a good place to write temp files?

8-16MB SDRAM chips are currently available for almost nothing (ignoring the possibility of recycling an old one). Future Electronics is currently selling 8M x 16 chips (AS4C8M16S) chips for 1.38 each in quantities of 1.


Top
 Profile  
 
PostPosted: Sat Oct 01, 2011 2:57 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Great job madscifi! I would not expect such r/w speed (6MByte/sec with 512block). I've got few sdram dimm sticks free on the flee market (16 and 64MB sdrams) as I saw the code some time back. Maybe one 373-like latch might be used- this would double the capacity (16bit data). Did you rewrite the code with #defines for signals? P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sat Oct 01, 2011 3:34 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
For example- these are chips which are easy to get (and easy to solder) from old pc sdram dimms (you get 8-16pcs of them on each dimm):
HY57V168010C 2Mx8
HY57V651620B 4Mx16
HY57V658020B 8Mx8
P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sat Oct 01, 2011 4:29 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
AS4C8M16S is pin to pin as the HY57V651620B (but twice the cap.)

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sat Oct 01, 2011 6:14 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
One my idea to somebody who is keen to design a pcb for sdrams: it seems all these legacy sdrams (e.g. AS4C8M16S HY57V651620B HY57V658020B and many others) are in 54pin TSOP II (400milx875mil 0.8mm pin pitch) package. They are pin2pin compatible, the only issue is the data_bus, where the 8bit versions have got the 8_not_used_bits set as NC. However, not in "8L+8H" fashion but in "even-odd-like-pin" mode. So when designing the board for 8bit operation with retrobsd, it would be good to use these SDRAM pins:
Pin Data
2 DQ0
5 DQ1
8 DQ2
11 DQ3
44 DQ4
47 DQ5
50 DQ6
53 DQ7
and all the other data pins set to gnd. This allows to deploy both 16 and 8bit versions on the same pcb.
I hope so :). P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Oct 02, 2011 6:38 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I don't think there is enough slack in the timing to use an external latch to extend the data to 16 bits (at least, not without slowing down the SDRAM clock or changing to single word bursts). If port B or F is used for data then all 16 bits could be used (and the data rate would, of course, double to just under 12 MB/s). Port F would interfere with retrobsd, and port B would make all of the analog inputs unavailable for future use. Too many choices and none of them are obviously the right choice.

Thanks for the layout info for the 8 bit chips - it looks like it would be possible to layout a board that allows for 8 or 16 bit chips and that allows for the full number of data pins to be used as appropriate (with appropriate code changes). However, one would probably lose use of the upper 8 pins even if a 8 bit chip was used. I don't know if 16 bit data is worth the loss of pins or not.

I keep thinking that a better approach to adding swap space would be to use a FPGA to interface to the ram. This might also allow the FPGA to be used as an 4 bit SD card interface (see http://opencores.org/project,sdcard_mass_storage_controller), a VGA interface, etc. However, with the existence of projects like Raspberry Pi I think anything that complicates or adds expense is probably not a useful idea.


Top
 Profile  
 
PostPosted: Sun Oct 02, 2011 3:12 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
I think the beauty of retrobsd on pic32 is the extreme simplicity = simple pic32 chip and a cheap sdcard, and you may run many jobs (handling megabytes of data) in timesharing manner with a quite large comfort of unix. The maximum complication people may accept is the external swap - i.e. with external sdram when the L version of chip is used. When you run many jobs the _most_overhead_ time is spent in r/w the swap. So 6Mbyte/sec might speed up the stuff significantly (with the newest process scheduler at least). And maybe you can place there TCPIP buffers or others too. The FPGA is a big complication (dev effort, space, power consumption, price..), unless you think to implement the MIPS or ARM core directly into fpga as well (i.e. XULA-200 at http://www.xess.com/prods/prod048.php ).
:) P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Oct 02, 2011 3:31 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
BTW, with XULA-50 ($39) you can implement an external 8MB swap via SPI, I think. And with XULA-200 an external 4bit sdcard high-speed interface too. The bottleneck will be the SPI speed of pic32, however. P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Oct 02, 2011 5:52 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
To the SDRAM - as far as I do understand the sdram topic: when you are manually bit-banging the sdram's control signals (you do..), then you may(??) connect Data_lines and Address_lines in parallel (to use the SAME bus).
So we need:
Xbit address + 16(8)bit data = 16 pins only (one port), and plus the sdram's control signals (~5-6??). This may decrease the numbers of pins significantly :).
P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Oct 02, 2011 9:39 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Another point:
>3) Add support to the Retrobsd startup code for ram-based code in >the kernel (as the SDRAM primitives must be run from ram due to >timing).
I would say we need to run the stuff from ram because we want to do swap r/w fast. Timing: I cannot imagine I have to bitbang sdram so fast, the timing requirements are usually coming from the pentium_x or amd_x memory controller module specs for a specific speed. People run sdrams with pic16f, atmega8 etc. I think Eniac will do as well. The sdram can held info for seconds, I am sure, without refreshing under normal conditions. If I run it at 1.5V and +125 degree Celsius I would be much careful. You may experiment- when you change ns for microsecs nothing happens, and it will work fine.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 1:30 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I agree with you that the extreme simplicity is one of the nice things about the Retrobsd project.

Those XULA boards are exactly the boards I've been considering using if I do try any FPGA experiments.

I was going to say that the address lines and data lines needed to be physically separated if you ever wanted to do a write, but after some consideration I see that is wrong. If you are willing to give up one in eight of the bytes in the ram then it would be possible to share the address and data lines (the first byte of each burst would contain its own column address). Very clever.

The SDRAM chips have a self-refresh mode. Essentially, tell them to go to sleep and they will simply keep doing self refresh operations until they are told to wake up. So there is no need to do refresh operations when you are not reading/writing. That simplifies things a lot. I've coded the block copy operations so that each operation reads/writes a couple of bursts of bytes, puts the ram into self refresh mode, turns on interrupts, waits a couple of cycles (during this time interrupts can be serviced), and then disable interrupts and continues on to the next couple of bursts. When the entire operation is complete the chip is put back into self-refresh mode so it can simply be ignored until one wishes to do a real read/write.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 94 posts ]  Go to page 1, 2, 3, 4, 5  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission