Connect with us

SD-interface with CPLD-CPU?

Discussion in 'Microcontrollers, Programming and IoT' started by rogerk8, Aug 17, 2013.

Scroll to continue with content
  1. rogerk8

    rogerk8

    176
    0
    Jul 28, 2011
    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.
     

    Attached Files:

    Last edited: Aug 17, 2013
  2. (*steve*)

    (*steve*) ¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd Moderator

    25,497
    2,838
    Jan 21, 2010
    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?
     
  3. Druzyek

    Druzyek

    5
    0
    May 29, 2013
    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.
     
  4. Raven Luni

    Raven Luni

    798
    8
    Oct 15, 2011
    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.
     
  5. Druzyek

    Druzyek

    5
    0
    May 29, 2013
    Ya, apparently some of them run ARM cores. Do you have a link to the prompt your friend got?
     
  6. Raven Luni

    Raven Luni

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

     
  7. rogerk8

    rogerk8

    176
    0
    Jul 28, 2011
    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.
     

    Attached Files:

  8. rogerk8

    rogerk8

    176
    0
    Jul 28, 2011
    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
     
  9. (*steve*)

    (*steve*) ¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd Moderator

    25,497
    2,838
    Jan 21, 2010
    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.
     
  10. rogerk8

    rogerk8

    176
    0
    Jul 28, 2011
    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.
     

    Attached Files:

    Last edited: Aug 20, 2013
  11. Solidus

    Solidus

    349
    4
    Jun 19, 2011
    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)
     
  12. Solidus

    Solidus

    349
    4
    Jun 19, 2011
    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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-