Maker Pro
Maker Pro

SD-interface with CPLD-CPU?

rogerk8

Jul 28, 2011
179
Joined
Jul 28, 2011
Messages
179
Hi!

I wonder how you would bulid a SD-memory interface for for instance a Motorola 6809 CPU.

I have built a very primitive and similar CPU using a Xilinx CPLD (XCR3512XL).

I have, after hard work, managed to make three instructions work (JMP, LDA and STA).

There are two problems though:

1) The micro-programming of the instructions are hard and requires tedious EPROM-reprogramming as I go.
2) Speed is slow (<4MHz) due to old EPROMs (CPLD-limit is however some 150MHz)

I would very much want to upgrade this design now that my concept work.

One thought is to migrate the design to a FPGA (with internal ROM-functions) instead.

It however seems like I have to reprogram the whole CPU in that case.

So I'm thinking that maybe I could use a SD-memory as both "Hard Drive"/Program memory and "Instruction Register" instead (two separate SDs are however needed).

Please direct me to a site that in detail explains how a SD-memory work HW-wise. I have searched the web but found almost nothing of the kind.

Best regards, Roger
PS
Attaching a picture of my current CPLD-version.
 

Attachments

  • SSCN0139.JPG
    SSCN0139.JPG
    63.1 KB · Views: 286
  • SSCN0110.JPG
    SSCN0110.JPG
    81.2 KB · Views: 223
Last edited:

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
Jan 21, 2010
25,510
Joined
Jan 21, 2010
Messages
25,510
Damn. Typing all this for a second time (abbreviated this time).

I would consider several approaches:

1) bit banging (is this what you talk about as too slow?)
2) using another processor (e.g. ATMega/PIC?) dedicated to SD I/O
3) using a chip designed for the SD I/O
4) FPGA.

Only 3 or 4 are likely to get you anywhere near the 150MHz.

I would look at the various tutorials on the net. The SPI interface is apparently not the fast way to communicate with them, so perhaps you can explore the alternate approaches.

I'm also curious as to whether you're using wire-wrap or soldering to what appear to be wire wrap pins/sockets?
 

Druzyek

May 29, 2013
5
Joined
May 29, 2013
Messages
5
What do you mean by "Instruction Register?" I would be careful using an SD card for any kind of repetitive work since they can only be written to a limited number of times before they break.
 

Raven Luni

Oct 15, 2011
798
Joined
Oct 15, 2011
Messages
798
The SD specification is really easy to read. There are a number of serial protocols supported (the newer the card the more youll get). There are a couple of basic synchronous modes and higher speed asynchronous modes. You'd probably be looking to use the latter and youd really need a dedicated serial interface for that.

Also as a point of interest, theres more to these SD cards than meets the eye. My friend got a linux prompt on one recently.
 

Druzyek

May 29, 2013
5
Joined
May 29, 2013
Messages
5
Also as a point of interest, theres more to these SD cards than meets the eye. My friend got a linux prompt on one recently.

Ya, apparently some of them run ARM cores. Do you have a link to the prompt your friend got?
 

Raven Luni

Oct 15, 2011
798
Joined
Oct 15, 2011
Messages
798
It was a facebook post but I'll paste it here:

# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 421.06
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5

Hardware : KeyASIC Ka2000 EVM
Revision : 0000
Serial : 0000000000000000
# ls /dev/
console mmc mtd1 pty/ sda spidev1 ttyS1
fb0 mmc1 mtdblock0 ram sda1 tty urandom
gpio_i2c mmc2 mtdblock1 ram0 sdb tty0 zero
ka-main mmcblk0 null ram1 spi0 tty1
ka-pwm mmcblk0p1 nvram ramdisk spi0.0 tty2
ka-pwm1 mmcblk0p2 ptmx random spidev0 ttyS
loop/ mtd0 pts/ root spidev0.0 ttyS0
# ls /dev/
console mmc mtd1 pty sda spidev1 ttyS1
fb0 mmc1 mtdblock0 ram sda1 tty urandom
gpio_i2c mmc2 mtdblock1 ram0 sdb tty0 zero
ka-main mmcblk0 null ram1 spi0 tty1
ka-pwm mmcblk0p1 nvram ramdisk spi0.0 tty2
ka-pwm1 mmcblk0p2 ptmx random spidev0 ttyS
loop mtd0 pts root spidev0.0 ttyS0
 

rogerk8

Jul 28, 2011
179
Joined
Jul 28, 2011
Messages
179
Damn. Typing all this for a second time (abbreviated this time).

I would consider several approaches:

1) bit banging (is this what you talk about as too slow?)
2) using another processor (e.g. ATMega/PIC?) dedicated to SD I/O
3) using a chip designed for the SD I/O
4) FPGA.

Only 3 or 4 are likely to get you anywhere near the 150MHz.

I would look at the various tutorials on the net. The SPI interface is apparently not the fast way to communicate with them, so perhaps you can explore the alternate approaches.

I'm also curious as to whether you're using wire-wrap or soldering to what appear to be wire wrap pins/sockets?

Thank you Steve for your input!

The first obstacle I am trying to circumvent is the simple (but slow) EPROM Program Memory. This is simply due to the fact that it is tedious to physically change it whenever I want to run a new program.

So I am thinking about a SD-card. While it will have to emulate an EPROM I will probably have to load it into a RAM at start-up i.e each time I want to run the program. The RAM can then be read like the EPROM and nothing except ease of use is changed.

But how do I load it into a RAM? I know it is serial and you now even say SPI.

As you now understand my dream is to be able to just pull the SD and reprogram it in the computer and push it back again into the CPU to run other programs.

This is on the other hand regarding using SD as Program Memory only.

I wonder how I would proceed if I also want to store data non-volatile.

In fact, designing a SSD-drive, so to speak.

On the other hand, I do not feel this latter part being so important (right now).

What is important is to be able to read a SD-card into a RAM at start-up.

If I get to know about the actual procedure I can reuse it for the realisations of the instructions.

The instructions are being realised by the so called Instruction Register (IR) which's address bus is 16-bit wide and data output bus is 48-bit wide (6 EPROM's neccesary today).

Thankful for more tips!

Best regards, Roger
PS
Yes, I have wire-wrapped it all.
 

Attachments

  • SSCN0116.JPG
    SSCN0116.JPG
    80 KB · Views: 204
  • SSCN0118.JPG
    SSCN0118.JPG
    62.6 KB · Views: 211
  • SSCN0128.JPG
    SSCN0128.JPG
    57 KB · Views: 289

rogerk8

Jul 28, 2011
179
Joined
Jul 28, 2011
Messages
179
What do you mean by "Instruction Register?" I would be careful using an SD card for any kind of repetitive work since they can only be written to a limited number of times before they break.

Hi Druzyek!

Thank you for that tip!

My main use for a SD-card would be to read from.

I would very much like to know how it it can be read and how to store that data in an ordinary RAM.

Please, see my post to Steve above for more details.

Best regards, Roger
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
Jan 21, 2010
25,510
Joined
Jan 21, 2010
Messages
25,510
I'd be looking at "ROM emulators". In theory all you need is a RAM chip that cannot be written to by the computer, and some bit of "magic" to load the RAM from another source at power-up.

Here is something on the web.

Another (and perhaps simpler) option is to build up a small board that is essentially a ram chip with a battery backup. It needs to be able to switch on and off the write enable line so it can be programmed once and then have further writing disabled.

I have (for historical interest more than anything else) some "chips" that were made this way. They were a RAM chip and a battery. They would retain memory for 10 years. Sadly, the ones I have are over 30 years old :) I may be able to look up the datasheet for them as it may give you some ideas...

Sadly, I didn't list them in my stock list -- probably because they're a curiosity more than something I'll ever use.

OK, this isn't what I have, but it's effectively the same. And it sounds like you can still get them! The datasheet seems to indicate that it might be able to do what you want. Have a "programmer" that uses the write line and your normal circuit that does not.

It may be useful to use ZIF sockets to allow you to move the chip without damaging it.
 

rogerk8

Jul 28, 2011
179
Joined
Jul 28, 2011
Messages
179
I'd be looking at "ROM emulators". In theory all you need is a RAM chip that cannot be written to by the computer, and some bit of "magic" to load the RAM from another source at power-up.

Here is something on the web.

Another (and perhaps simpler) option is to build up a small board that is essentially a ram chip with a battery backup. It needs to be able to switch on and off the write enable line so it can be programmed once and then have further writing disabled.

I have (for historical interest more than anything else) some "chips" that were made this way. They were a RAM chip and a battery. They would retain memory for 10 years. Sadly, the ones I have are over 30 years old :) I may be able to look up the datasheet for them as it may give you some ideas...

Sadly, I didn't list them in my stock list -- probably because they're a curiosity more than something I'll ever use.

OK, this isn't what I have, but it's effectively the same. And it sounds like you can still get them! The datasheet seems to indicate that it might be able to do what you want. Have a "programmer" that uses the write line and your normal circuit that does not.

It may be useful to use ZIF sockets to allow you to move the chip without damaging it.

Thank you Steve, this is brilliant! :)

One reason is the suggestion of ZIF-sockets, why didn't I think of that? :confused:

The other reason is battery-powered RAMs.

My goal is to build a computer from scratch.

However, my CPLD-CPU cannot store any data for arbitrary external computer usage.

I don't mind my computer being very simple.

I could appreciate building a separate circuit board that both can store data to a RAM and read data from a RAM.

This way my "Floppy Disc" would be a physical battery backed-up RAM only.

I'm just playing around now :)

The one RAM already in use could be made battery backed-up using two diodes. I would however probably have to keep either CS or Write inactive after power has been shut off (both are active low).

But this way I can store my files on the RAM, move it to the special computer-adaptor (CA) and upload them to another computer using ordinary RS232 and the Hyper Terminal(?)

In a similar way, I can download a program to the Program Memory (also consisting of a battery backed-up RAM) using that same CA.

This means that both the Program Memory and the RAM/Floppy has to be battery backed-up RAMs.

Now to the fun part. The EPROMs and the RAMs I use are almost exactly pin compatible. Only A14 and A15 differs.

Further more, the RAM I use (A605308A) is much faster than the EPROMs I use (27C512).

This means that a speed of some 50MHz might be feasable after all!

Once more I thank you for your tip!

I will consider this further.

It would be a true pleasure if "nothing" more than ZIF-sockets and battery backed-up RAMs are needed.

Best regards, Roger
PS
If there only was a 64kX8 M48Z35 available. Then I would not need to rewrite all the addresses for the IR. But there are two bits "empty" so I can actually use a 32kX8 even though it will be hard work.
 

Attachments

  • CPU_schematic_15.3.jpg
    CPU_schematic_15.3.jpg
    86.5 KB · Views: 255
Last edited:

Solidus

Jun 19, 2011
349
Joined
Jun 19, 2011
Messages
349
Roger,

Your project particularly interests me as I've been working for awhile now in FPGA development. In fact, on my blog and one of my projects is working up a 8086 replica into an FPGA for implementation. Depending on the size, I may be able to get the other peripherals somewhat integrated as well. If you ever need a second opinion, be sure to drop me a line.

The SD protocol is nice because it is usually synchronous - that is, you have a separate CLK pin provided. In asynchronous transmission, generally 7-8 bytes of 01010101 are transmitted at the start of a frame (transmission cycle) to synchronize the host and receiver clocks. While this conserves pin count, it means you have to have a good bit of logic to synchronize a PLL or clock network to that start byte frame.

On a CPLD, logic area isn't the specialty, so the SD protocol is fairly well suited to your application. There are a couple concerns I have, if you tell me more about your project I can help you whittle them down.

As detailing above, SD protocol logic may be a bit taxing for the CPLD, so I'll go over some alternatives below, but here is the datasheet to a Toshiba SD card.

Looking at that, in Section 6.2.1 you can see that the SD card only requires 6 pins - CLK, CMD, and DATA[0:3]. This means that you have a data bus of 4 bits in transmission per clock cycle. You will have to adjust the protocol logic to fit your register or cache sizes within the CPU itself.

It may be easier to implement an SPI MISO/MOSI protocol instead of SD, in which the DATA-3 pin will be asserted low and the command CMD0 given by the CPLD as per the data sheet.

The other thing is that it may be easier to implement a MCU (ARM to get the speed) to do the logic, and bit-bang the CPLD with 8-bit frames. It would tie up more pins (9 as opposed to 6, as you would have to have a CLK assertion), but you wouldn't have latency in the commands between the CPU and the MCU to the depth that you would with an integrated approach as the MCU would (hopefully!) be optimized to the task.

If you do want to implement full protocol functionality, that datasheet does provide you with the timing references for the protocol. Also search on OpenCores, they may have something that you can tailor to fit the CPLD.

Best of luck,
Eli Fedele
(solidus)
 

Solidus

Jun 19, 2011
349
Joined
Jun 19, 2011
Messages
349
Some second thoughts I've had while mulling over what you've put up so far:

Possibly try some Z80-era RAM chips - they should be still available in DIP format, and with friendly 5V power lines, you can't go wrong. You could also base your system off the Z80 interface architecture (addressing RAM on one bus, banging data out on another bus, your CPLD certainly has the pin capability for that).

Migration to an FPGA if you're working in a modern HDL like Verilog, VHDL, or any number of their derivatives is not hard. Some of the code may need reworking, but it isn't anything along the lines of reprogramming the entire device.

If you'd like, I can work on writing you a basic SD protocol IP. I need to practice my Verilog a bit more so if you'd like me to let me know.

One thing you can take advantage of is the front-end logic description component of the HDLs - that is, it takes a lot of the brains out of having to do description, at least for programmable logic devices. An example is that you can implement an ADD (add without carry command) as simple as writing:

Code:
module adder (
input [7:0] INPUTA,
input [7:0] INPUTB,
output[7:0] OUTPUT,
input CLK
);
always @ (posedge CLK)
begin : adder
OUTPUT = INPUTA + INPUTB;
end
endmodule

The idea being that the IDE will takeover most of the logic to figure out how to implement it. I'm sure you know this, but the same works for multiply and divide commands. Carry-out and status register functions can be achieved by programming a carry out output and wiring it to the appropriate status register bit.
 
Top