RetroBSD

2.11BSD operating system for microcontrollers
It is currently Thu Oct 18, 2018 9:51 pm

All times are UTC




Post new topic Reply to topic  [ 94 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Oct 03, 2011 1:52 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
So would this work (one 16bit port and one 8bit port shall be used)?
[/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 2:20 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Or the 16bit version :):
[/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 2:36 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Or for both 8 and 16bit sdram versions (TSOP 54pin):
[/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 2:36 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I believe it would work. There will have to be some code changes made to support that layout. It complicates the block addressing a little bit.

DQM does not need to be connected to the PIC unless you plan on implementing the ability to interrupt burst operations - none of the code I've been working on supports such operations so I've simply tied DQM to ground (actually I'm using a 16 bit chip so I've tied UDQM to VCC and LDQM to GND).


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 4:29 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I'd like to request some advice on how to approach the asm code. I have two working versions - one written in a style at references the io port registers using the direct+index addressing, the other written using register indirect (with the offset always zero).
direct+index:

This is very much like the original code, with changes to make everything easy to change to use new ports. It is more efficient than the other in that it requires fewer temp registers and less code space, but it depends on defining the position relationship between io port registers within the code itself (I've been unable to get the assembler to allow the relationships to be computed from the system headers). I don't like the fact that the relationship between io port registers is defined in the code, but I don't suppose the relationships of the io port registers is likely to ever change.
register indirect:

This approach uses some macros to paste together the names of the registers (ugh), but it only depends on the names of the registers as defined in the system headers. The end result is a bit larger than the first as it uses more temp variables, and I think it is harder to read, as all of the tightly timed register reads/writes reference temp registers, so one constantly needs to refer back to determine what precisely that register is holding.
Example: Register indirect
/* Sends ACTIVE command */
sdram_active:

/* Get ready. */
la t0, LAT_(ADDRESS_IO)
la t3, LAT_INV(CONTROL_IO)
li t7, (1<<CONTROL_CS_BIT)|(1<<CONTROL_RAS_BIT)
/* Set row */
output_address
sync_clock
.set nomacro
/* Active */
sw t7, (t3)
clock3
/* Command Inhibit */
sw t7, (t3)
clock3
/* Command Inhibit */
clock4
.set macro
/* Return */
jr ra
nop

Example: Direct+index
/* Sends ACTIVE command */
sdram_active:

/* Get ready. */
la t0, TRISA /* Port Base */
li t7, (1<<CONTROL_CS_BIT)|(1<<CONTROL_RAS_BIT)

/* Set row */
output_address
sync_clock
.set nomacro
/* Active */
sw t7, SDR_CONTROL_TRIS+LAT_OFFSET+INV_OP_OFFSET(t0)
clock3
/* Command Inhibit */
sw t7, SDR_CONTROL_TRIS+LAT_OFFSET+INV_OP_OFFSET(t0)
clock3
/* Command Inhibit */
clock4
.set macro
/* Return */
jr ra
nop

I'm not particular happy with either approach. Does anyone have a preference, or even better a better approach?


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 5:50 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
..thanks, U/LDQM saves 2 pins.. (I am trying to shuffle the data lines a little bit because of routing).. BA0 and BA1 can be then put on the "JP2 Port" if it helps.
[/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 6:35 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Oops - I misdirected you - since I was not using the upper data bits I tied UDQM high, but you'll want to tie it low since you potentially use the upper data bits.

You really want to make certain that the least significant 8 bits from the PIC port route to DQ0, DQ2, DQ4, DQ6, DQ9, DQ11, DQ13 and DQ15. Otherwise it will be difficult to make the code work with a 8 bit ram chip. I'll suggest the following wiring approach as I believe it will minimize code complexity and maximize read/write speed (RxN represents bit N of port X on the PIC):
Rx0 -> A0 -> DQ0
Rx1 -> A1 -> DQ2
Rx2 -> A2 -> DQ4
Rx3 -> A3 -> DQ6
Rx4 -> A4 -> DQ9
Rx5 -> A5 -> DQ11
Rx6 -> A6 -> DQ13
Rx7 -> A7 -> DQ15
Rx8 -> A8 -> DQ1
Rx9 -> A9 -> DQ3
Rx10 -> A10 -> DQ5
Rx11 -> A11 -> DQ7
Rx12 -> A12 -> DQ8
Rx13 -> BA0 -> DQ10
Rx14 -> BA1 -> DQ12
Rx15 -> DQ14
Of course it might be physically a bit of a mess on the board.

Edit: Actually, you can scramble the connections between A[0-7] and DQ[0,2,4,6,9,11,13,15] however is convenient, so long as Rx[0-7] connects to A[0-7] in sequence.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 7:09 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
[/url]
The 8 pull-up resistors do return 0xFFxy when 8bit device is used (so the input does not float).

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 8:04 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I have not traced every wire but it looks good. I don't think the pull up resistors are necessary. On an 8 bit chip the lines they are connected to are indicated as NC on the SDRAM chip, so there is no need to pull them up. I'm assuming that NC means they are not connected internally, but that it is safe to connect something too them. However, I'm not 100% certain that is correct. If NC means that the pin on the SDRAM should not be connected to anything then the idea of a single layout for 8 or 16 bit chips is not going to work.

Edit: Also, when the code is configured to use an 8 bit chip there is no reason to change the unused data lines to be inputs on the PIC, so the pullups not needed for that purpose either. On the other hand I don't imagine that they would cause any problems.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 8:55 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
..yea we may remove the pull-ups.. Here is an example of pcb. Not easy to route..
[/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 9:14 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
[url=http://retrobsd.org/wp-content/uploads/2011/10/retrodram16_8e.jpg][/url]

[url=http://retrobsd.org/wp-content/uploads/2011/10/retrodram16_8e_pcb.jpg][/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 10:53 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
You are definitely getting ahead of me :) That is good.

I've made an attempt to create a version of the assembly code that will work with your board and a 16 bit chip. It has not been tested yet, and I've not had time to change the associated C code to use it correctly, but I wanted to make it available in case you have more time than I do to work on it. I need to rewire my existing board before I can test the code.

See https://github.com/madscifi/Misc_Utils/tree/master/sdram_interface_16_shared/sdram_interface/core
for the assembly code. It will not stay there long term, but it was the easiest place for me to make it available at the moment.



Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 3:06 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Better you might rewire your testbed and test the code when you get time, so we may get a feedback for above hw layout. There could be a lot of issues still. When it works then we can either finalise the pcb or to make a bigger board with pic32 on it.
I've put the .zip file with the latest eagle schematics and board into media library (here on this site). No warranty of any kind. Published under same licence as retrobsd. P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Oct 03, 2011 10:14 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
You'll probably want to add the DQM lines back to connecting with the PIC. I realized, late last night, that it is probably possible to write the code so that all of the memory can be used, but it will require that the DQM lines can be controlled by the PIC. Sorry about suggesting that the were needed.


Top
 Profile  
 
PostPosted: Tue Oct 04, 2011 1:05 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
You have to sleep at late night.. Otherwise the pcb will never be ready.. :). DQM is used for masking a lower or higher byte when you want to change only one byte in the memory. Would this help with the "1+3" burst issue?
Also - which signals has to be pulled up (I did /CS recently) for a case when the pic is floating (i.e. during startup)? P.
PS1: at the time the 4164 and 41256 were the top models we were inserting a 33-50ohm resistors in series with signals to match at high speeds (~few MB/sec). Hopefully this is not required with this design..
PS2: as the next step we remove the sdram from the pcb.. :)
[url=http://retrobsd.org/wp-content/uploads/2011/10/retrodram16_8f_pcb.jpg][/url]

[url=http://retrobsd.org/wp-content/uploads/2011/10/retrodram16_8f.jpg][/url]

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Tue Oct 04, 2011 10:46 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I think a resistor on CS makes sense. I don't think RAS, CAS, WE, LDQM or LDQM need them. But I'm not an expert. And signal integrity issues is something I know just enough about to know that I know absolutely nothing of interest. Fortunately we are only using a 20MHz clock, so we can get away with a lot that a design attempting to run the ram at 133 MHz cannot.


Top
 Profile  
 
PostPosted: Tue Oct 04, 2011 2:31 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I've rewired my board so that it basically matches your board design. The code can now read/write the first 12 words of ram as 3 bursts of four sixteen-bit operations, so your idea of sharing the data and address lines appears to be working. DQM is definitely needed in order to be able to use all of the memory, but the U/L DQM wires can be tied together - only one pin is needed on the PIC. At this point most of what remains is some house cleaning to adjust for the new address line layout and it will soon be back to reading/writing the entire chip, but I'm out of time for this evening.

Writing is about half the speed of reading due to the shared data/address lines. I might be able to speed writing up a bit - it depends on whether or not I can short circuit a write burst without causing a precharge. I need to read through some datasheets in more detail.


Top
 Profile  
 
PostPosted: Tue Oct 04, 2011 3:46 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Great! Happy to see the idea works. Let me ask you following to the code:
1. would it be possible to port the stuff to C (even it might be a little bit slower)?
2. I think we use clock generated by pic32 in hardware (therefore the timing restrictions) - would it be possible to bitbang the clock as well (even it might be a little bit slower)?
3. the manuals (at least for the chips I've got) say "Programmable Burst length: 1,2,4,8 or Full page for Sequential Burst" - why we use only 4?
4. for current code and 16bit operation - does it mean we can write at 6MBytes/sec and read at 12MBytes/sec (+-)?
5. to the control signal's pull-ups - the CLK, CKE, UDQM and LDQM inputs are not affected by /CS, therefore the question on pull-ups for the case sdram's inputs float.
P/

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 9:33 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Responding to the questions out of order:

2) Actually, the tight timing is due to the requirements of the SDRAM - the hardware timer is simply an easy way to meet the requirements. The specs say that the frequency of the clock must be stable while reading/writing/refreshing. It might be possible to slow the clock when in-between such operations, but it is not recommended by Micron (ignoring the fact that you can turn the clock off completely during self-refresh). Yes, it would be possible to bitbang the clock and it would be slower. It would probably be necessary to move more of the functionality down into the assembly code if the clock was bitbanged.

1) I think one would have to very significantly slow down the ram interface in order to write the bitbang functions in C. Since the clock needs to be stable it would have to be hardware generated and the C code would have to sync with the clock at every step.

3) Full page would not work since you need to store the data in the registers in order to keep up. Burst lengths of 1 will not work since we are sharing data/address lines. I'm currently using 4 as the ASM I functions that I'm using pass the result of a read back as a return, so 64 bits is all that is easily available. I'm planning on changing the asm to pass the data in/out via a pointer and always use 8 byte bursts as that has the best performance. Since the whole idea is to make an efficient swap (and maybe temp device) individual reads and writes are not really useful. It would be simple enough for someone to adapt the code to other burst lengths.

4) Roughly, yes. I think I can get the write speed up to something near 8 MB/s by moving to 8 word bursts and terminating the second write sequence early.

5) Ok.

Jim


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 12:20 pm 
User avatar

Joined: Mon Nov 12, 2012 3:17 pm
Posts: 164
Location: Bratislava, Slovakia
Guys,
I took Pito's design and manually rerouted it, as my favourite/cheap local PCB manufacturer allows worse clearance and drill diameters than his design expected. What worse, his original design was somehow suboptimally routed - it is sometimes hard to force the autorouter do its job correctly. I also added second ground plane and made board a bit smaller.
Two layers board is still suboptimal for design such as this (DRAMS were always a bit challenging, since old 4164), but I believe it should work.
After a bit cleanup I'll put eagle files here.
http://jaromir.xf.cz/_fil/dram1.png

_________________
http://jaromir.xf.cz/
https://hackaday.io/jaromir/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 94 posts ]  Go to page Previous  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