Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

What's the easiest way to read response signal?

Status
Not open for further replies.

slirenem

Newbie level 6
Joined
Feb 3, 2012
Messages
13
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,388
Hi everyone,

I start with FPGA now. At the beginning have one simple question. By my FPGA I try to communicate with some appliance. How could I read a response signal the easiest? If it comes into one of declared STD_LOGIC port. My FPGA is Spartan 3 (I use Xilinx developing software obviously). The simplest way which comes into my mind is send it by RS232 to computer but it requires RS232 handler and additional connection, additionaly in the future incoming responses will be much faster so RS232 will be too slow. Any other way to see that signal's bytes?

Regards
slir
 

Re: Read response signal

Hi,
Here are several questions
1. You want only read input signal in FPGA? or both read and send signal to PC?
2. Is there limited connection between FPGA and appliance? you worry about the "additional connection"..
3. How fast the response is?
 

Re: Read response signal

I apologize that I didn't answered here so long. This "appliance" (I see this word is used rather for household machines :D, sorry for my english) is SD card.
Its communication interface has one command line and up to four data lines, so:

1a. I have to read command responses. I would like to see responses to check what SD 'say' to me (it's usually 48 bits), don't need to send them to PC. In code I have to compare responses to check if they have established values and if I should change state, go into the next step.

1b. I'd like also send data to PC, but priority is to initialize card by mentioned above commands and responses.

2. I was worry because additional connection requires additional components and I'm not advanced so it complicates case. But there is rather no more contraindications :).

3. How fast... this is still mystery for me. By commands I could set data 50 MB/s or even 104 MB/s (UHS class) but to be honest I can't find out how fast are commands and responses. I know only that default speed of data bus is 12,5 MB/s and additionally found this:

"After power-on or CMD0, all cards' CMD lines are in input mode, waiting for start bit of the next command. The cards are initialized with a default relative card address (RCA=0x0000) and with a default driver strength with 400KHz clock frequency. In case of 3.3V signaling, default driver strength is specified by the Driver Stage Register (DSR) if supported and selected highest driving current capability. In case of 1.8V signaling, default driver strength is specified by type B driver."

But don't know if it will be 400 kHz, or something from DSR (don't know the context). Know that it will be 3.3V at the beginning so it will no be "type B driver???".
 

Hi,
You'd better describe your project in some details. It seems to me that you are trying to build a SD card reader/writer on FPGA. In this case, you have to implement SD card protocol in FPGA, there is no easiest way to do it. For testing purpose, attach a scope on command line is a simple way to find out what's going on on the line.

As I known, SD card could work with SPI ....maybe implement a SPI interface in FPGA is a good idea.

The speed of SD card depends on internal chip in the card, 400KHz is the default rate. which means you can always contact with SD card at 400KHz after power on or CMD0.By reading related registers, you can find out how fast it could work on.

By sending data to PC, you definitely need an interface to talk to PC. RS232, CAN, USB, Ethernet etc. No matter which one you choose, you still need implement corresponding interface in FPGA.
 

Hi,

SD card reader/writer on FPGA
yes, that's my goal. I saw other projects and have idea how to build it. I'm also familiar with "SD Specifications Part 1 Physical Layer Simplified Specification Version 3.01", "SanDisk SD Card Product Manual Version 2.2" and others docs, so I know what kind of commands I should send and how should responses look (bit by bit) to have SD Bus communication ( not SPI because it's too slow).

I didn't know how to analyze that what I get from SD card. Now I'm trying to find out how ChipScope Pro works. I could use it to know responses. About sending data, at first I think I will use RS232 and some buffor (FIFO ?). If I understand it good: RS232 gives me 115 200 b/s --> 14,4 KB/s; data speed form SD card is 50 MB/s (slower speed selected) --> 50 000 KB/s / 14,4 KB/s = 3472,(2) - it's how many clock cycles I will have to wait send bit form buffor. When it will work I will think about something faster, probably USB.

I see I have test commands speed when I will have my development board finally.

Regards
slir
 

As I wrote I read about communication protocol. I also saw VHDL and C examples with SPI usage (from forum too, I read all threads on forum about SD cards controllers). So I hope it will not be the problem when I will start with real device, but thanks for links:)

PS. ChipScope is not beginners friendly tool :D
 

Hi,silirenem
I don't much about SD card, I just saw someone using SPI to talk with SD card.

And theoretically, there is no limit to the speed of SPI, it's just a shift register. The speed only depends on how fast the hardware can handle it.

In you case, I am sure your FPGA supports more than 50MHz, if both master and slave support 50MHz, SPI should not be a problem.

And actually, we are talking about two questions:
1. How the FPGA communicate with SD card.
2. How to read/Write SD card on PC.
We'd better discuss them separately.
 

Hi,
to accomplish Ultra High Speed (UHS) it is needful to use SD Bus mode, not SPI mode. So card is the weakest link.

1. One thing niggles me, if I will get some responce into the input, can I store it in some signal declared in architecture? Will be it keeped after transmission there and I could then compare this signal with others or transmit it to PC?

2. This issue I think I can put off until I initialize the card.
 

Of course, you can keep a data in signal. And the best way is always to write a simple code to verify your idea.
 

Well, what I know about SD card thing is, if you are using a file system in SD card, then it couldbe a much more complex project for you. For example, you format SD card in windows with FAT format and copied a text file, and if you are to read that, then you should know the file system to read data. What you have said so far is believed to be not using file-system.

If that is the case, you can first try reading a stored data from SD card. Then upon success you can move on to bulk read\write. One of friends did so initially and then implemented successfully.

---------- Post added at 14:52 ---------- Previous post was at 14:50 ----------

Even you can try reading that data and display in chipscope. If not, you can try displaying the read data in LEDs\LCDs too...
Dont approach for Bulk data and involve into high speed problems. First read fixed data and prove your RTL is good...then you can progress slowly...
 

Hi,
like you deduced, I don't want to use file system, just read/write raw data. Firstly want to initialize card, see responses, registers. Then I want rather to write something. It should be easy to see that data by PC reader and hex editor, I hope. Additionally it seems to me that writing is easier to do. Later reading and finally trying to extract the highest speed.
Thanks for interesting in my work :)
 

Additionally it seems to me that writing is easier to do.

Oh really?.
I thought reading is easy....

If you can write data successfully then the only way to validate is by reading that :)
I think there is some SD Card ID which can be read irrespective of filesystem. Just like vendor ID.Check that out. If you could read that, you are on the right path....
I'm not sure, just check if that ID can be read..
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top