OpenCores

OpenCores

Testing an SDcard core.

First

Prev

2/4

Next

Last

RE: Testing an SDcard core. by btxsistemas on Aug 27, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q][q] 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk [/q] So peak transfer rate should be around 3MBytes/sec. [q]... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec [/q] Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? [q] 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). [/q] How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob[/q] OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk So peak transfer rate should be around 3MBytes/sec. ... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested.

RE: Testing an SDcard core. by btxsistemas on Aug 27, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q][q] 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk [/q] So peak transfer rate should be around 3MBytes/sec. [q]... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec [/q] Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? [q] 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). [/q] How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob[/q] OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk So peak transfer rate should be around 3MBytes/sec. ... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested.

RE: Testing an SDcard core. by btxsistemas on Aug 27, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q][q] 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk [/q] So peak transfer rate should be around 3MBytes/sec. [q]... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec [/q] Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? [q] 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). [/q] How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob[/q] OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. 2- ... In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk So peak transfer rate should be around 3MBytes/sec. ... 3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again. 4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read. 5- It [SPI clock dead time] is about 20.7uSec Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running? 6- ... the rxfifo send me a full state about each 4.2mSec (sounds right, really?). How deep is the rxfifo? How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting? Is the rxfifo being read (drained) while the rxfifo is being filled? If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high). Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period? - Bob OK Bob, let me clearify you some points. Yes, 3MBytes/s is what I expected from this core. Would be fine for me. The core is giving me, only 512 bytes each 4.20mSec plus 20.7uSec of time dead. Because that is the time that the core answers me, that it read a complete data block. The SPI clk is not continuosly running. I also can see burst of SPI clks each 4.20mSec more or less. The rxfifo is 512byte deep (this is part of the "spimaster core"). The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested.

RE: Testing an SDcard core. by eteam on Aug 27, 2010			eteam Posts: 32 Joined: Jun 5, 2009 Last seen: Mar 25, 2016
[q] The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. [/q] You don't need to go to much trouble. Just bring out the pulse for writing to the rxfifo. Here is what you should be trying to accomplish: 1. You should be filling the rxfifo as quickly as possible. Either the data fetch itself is running too slow, or there is too much dead time between fetches, or there is a logic bug which is giving you misleading information. 2. Is a byte fetch running as fast as it should? Trigger on the rxfifo write (push) pulse, with a probe also on the SPI clock. In burst mode, the rxfifo write pulse should be happening every 320nS (8 cycles of 25MHz SPI clock). If not, what is slowing down byte fetch in burst mode? 3. From one rxfifo write pulse to the next, is the SPI clock continuously running, at 25MHz, with 8 SPI clock pulses for each rxfifo write? If you see more or fewer than 8 SPI clock pulses per rxfifo write, then you have a state machine or logic error in the counting of SPI cycles. If the SPI clock is running slower than 25MHz, you have a problem in state machine or SPI clock gen logic. If there is dead time where SPI clock is not running in burst fetch, then you should look at state machine logic which needs to be 'tightened up'. The inner loop of burst fetch is the first thing to verify and possibly clean up. 4. After verifying the inner loop of burst fetch, is there dead time between burst fetch operations? Does a 512-byte fetch still take 4.2mS ? Look at the beginning and end of 512-byte fetch cycles -- before, during, and after the rxfifo FULL flag pulses high -- to figure out where time or cycles are being wasted. -- Bob Elkind The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. You don't need to go to much trouble. Just bring out the pulse for writing to the rxfifo. Here is what you should be trying to accomplish: 1. You should be filling the rxfifo as quickly as possible. Either the data fetch itself is running too slow, or there is too much dead time between fetches, or there is a logic bug which is giving you misleading information. 2. Is a byte fetch running as fast as it should? Trigger on the rxfifo write (push) pulse, with a probe also on the SPI clock. In burst mode, the rxfifo write pulse should be happening every 320nS (8 cycles of 25MHz SPI clock). If not, what is slowing down byte fetch in burst mode? 3. From one rxfifo write pulse to the next, is the SPI clock continuously running, at 25MHz, with 8 SPI clock pulses for each rxfifo write? If you see more or fewer than 8 SPI clock pulses per rxfifo write, then you have a state machine or logic error in the counting of SPI cycles. If the SPI clock is running slower than 25MHz, you have a problem in state machine or SPI clock gen logic. If there is dead time where SPI clock is not running in burst fetch, then you should look at state machine logic which needs to be 'tightened up'. The inner loop of burst fetch is the first thing to verify and possibly clean up. 4. After verifying the inner loop of burst fetch, is there dead time between burst fetch operations? Does a 512-byte fetch still take 4.2mS ? Look at the beginning and end of 512-byte fetch cycles -- before, during, and after the rxfifo FULL flag pulses high -- to figure out where time or cycles are being wasted. -- Bob Elkind

RE: Testing an SDcard core. by btxsistemas on Aug 29, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q][q] The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. [/q] You don't need to go to much trouble. Just bring out the pulse for writing to the rxfifo. Here is what you should be trying to accomplish: 1. You should be filling the rxfifo as quickly as possible. Either the data fetch itself is running too slow, or there is too much dead time between fetches, or there is a logic bug which is giving you misleading information. 2. Is a byte fetch running as fast as it should? Trigger on the rxfifo write (push) pulse, with a probe also on the SPI clock. In burst mode, the rxfifo write pulse should be happening every 320nS (8 cycles of 25MHz SPI clock). If not, what is slowing down byte fetch in burst mode? 3. From one rxfifo write pulse to the next, is the SPI clock continuously running, at 25MHz, with 8 SPI clock pulses for each rxfifo write? If you see more or fewer than 8 SPI clock pulses per rxfifo write, then you have a state machine or logic error in the counting of SPI cycles. If the SPI clock is running slower than 25MHz, you have a problem in state machine or SPI clock gen logic. If there is dead time where SPI clock is not running in burst fetch, then you should look at state machine logic which needs to be 'tightened up'. The inner loop of burst fetch is the first thing to verify and possibly clean up. 4. After verifying the inner loop of burst fetch, is there dead time between burst fetch operations? Does a 512-byte fetch still take 4.2mS ? Look at the beginning and end of 512-byte fetch cycles -- before, during, and after the rxfifo FULL flag pulses high -- to figure out where time or cycles are being wasted. -- Bob Elkind[/q] Hi Bob. Here is some measure results. 1- Perfectly understable. 2- More or less yes, I've attached a picture of the measure of this. Blue wave is the rRxFifoWE signal, and the yellow one is the SPI clk. (in both pictures). Note that there are eight pulses of 25Mhz for each fifo save, but the time between saves in fifo is 480nSec, this is fine I supposed, in the measures you can see clearly where is the dead time that brings me to 4.2mSec final elapsed time to read 512 bytes. 3 and 4- Yes, youu can see it in the pictures. I've discovered that the dead time changes, probing with different cards, but always is a lot of time. Now my problem is how to find where the core is losing so much time, due I've not write this core, and following the code, is too hard for me to follow what the man who did it, want to do. :( I've noticed too , that in the opencores site, says that the core was updated June 10 2010, I've downloaded it again to see modifications, but the code is the same as before, so ????. Bob, do you have in hands this core, to get close it a view inside ? You're being agreat help, and teacher for me, thank so much !!. [q]<a href="uploads/1283095009_F0004TEK.BMP">F0004TEK.BMP</a> (76 kb)[/q][q]<a href="uploads/1283095134_F0005TEK.BMP">F0005TEK.BMP</a> (76 kb)[/q] The rest of measurements that you suggested me, will take me a bit of time to implement, I've only a flag for rxfifo full, not a flag for rxfifo empty, and I will do more modifications to the original code to test all what you suggested. You don't need to go to much trouble. Just bring out the pulse for writing to the rxfifo. Here is what you should be trying to accomplish: 1. You should be filling the rxfifo as quickly as possible. Either the data fetch itself is running too slow, or there is too much dead time between fetches, or there is a logic bug which is giving you misleading information. 2. Is a byte fetch running as fast as it should? Trigger on the rxfifo write (push) pulse, with a probe also on the SPI clock. In burst mode, the rxfifo write pulse should be happening every 320nS (8 cycles of 25MHz SPI clock). If not, what is slowing down byte fetch in burst mode? 3. From one rxfifo write pulse to the next, is the SPI clock continuously running, at 25MHz, with 8 SPI clock pulses for each rxfifo write? If you see more or fewer than 8 SPI clock pulses per rxfifo write, then you have a state machine or logic error in the counting of SPI cycles. If the SPI clock is running slower than 25MHz, you have a problem in state machine or SPI clock gen logic. If there is dead time where SPI clock is not running in burst fetch, then you should look at state machine logic which needs to be 'tightened up'. The inner loop of burst fetch is the first thing to verify and possibly clean up. 4. After verifying the inner loop of burst fetch, is there dead time between burst fetch operations? Does a 512-byte fetch still take 4.2mS ? Look at the beginning and end of 512-byte fetch cycles -- before, during, and after the rxfifo FULL flag pulses high -- to figure out where time or cycles are being wasted. -- Bob Elkind Hi Bob. Here is some measure results. 1- Perfectly understable. 2- More or less yes, I've attached a picture of the measure of this. Blue wave is the rRxFifoWE signal, and the yellow one is the SPI clk. (in both pictures). Note that there are eight pulses of 25Mhz for each fifo save, but the time between saves in fifo is 480nSec, this is fine I supposed, in the measures you can see clearly where is the dead time that brings me to 4.2mSec final elapsed time to read 512 bytes. 3 and 4- Yes, youu can see it in the pictures. I've discovered that the dead time changes, probing with different cards, but always is a lot of time. Now my problem is how to find where the core is losing so much time, due I've not write this core, and following the code, is too hard for me to follow what the man who did it, want to do. :( I've noticed too , that in the opencores site, says that the core was updated June 10 2010, I've downloaded it again to see modifications, but the code is the same as before, so ????. Bob, do you have in hands this core, to get close it a view inside ? You're being agreat help, and teacher for me, thank so much !!. F0004TEK.BMP (76 kb) F0005TEK.BMP (76 kb)

RE: Testing an SDcard core. by eteam on Aug 29, 2010			eteam Posts: 32 Joined: Jun 5, 2009 Last seen: Mar 25, 2016
[q] 2- More or less yes, I've attached a picture of the measure of this. Blue wave is the rRxFifoWE signal, and the yellow one is the SPI clk. (in both pictures). Note that there are eight pulses of 25Mhz for each fifo save, but the time between saves in fifo is 480nSec, this is fine I supposed[/q] No, it's not fine. This is a very small, well-defined problem. This is a good problem for you to solve first. Fixing this will help you learn a bit about the core state machine, and help you learn how to debug state machines. This is an ideal learning and debugging problem. [q]in the measures you can see clearly where is the dead time that brings me to 4.2mSec final elapsed time to read 512 bytes. 3 and 4- Yes, you can see it in the pictures. I've discovered that the dead time changes, probing with different cards, but always is a lot of time.[/q] Would you please explain what the two traces represent in the second waveform diagram? [q]Now my problem is how to find where the core is losing so much time, due I've not write this core, and following the code, is too hard for me to follow what the man who did it, want to do.[/q] I get the impression that you aren't all that familiar with state machines. If so, this an important skill set to develop. As I mentioned above, I would suggest troubleshooting the dead time between writes to the RX fifo. This is a smaller problem, and a small problem is good for learning. [q]I've noticed too , that in the opencores site, says that the core was updated June 10 2010, I've downloaded it again to see modifications, but the code is the same as before, so ????.[/q] I haven't looked at the code. Most designers include history notes in their source code, especially if the intend to distribute their code for others to use. Maybe there is a change history section in the 'readme.txt' file included with the archive. If you're still looking for change history, you can run a file compare program (there are plenty of freeware utilities available for download), and compare the two releases of unmodified source code. What is more important to you, fixing your design or learning how to fix your design? It's your decision, but it sounds like your design is mostly working. It may be faster and more instructive for you to stick with debugging the code you are currently using. [q]Bob, do you have in hands this core, to get close it a view inside ?[/q] I'm not very good at debugging strange source code from a distance. I'm more than willing to help guide you in debugging your design yourself, however. And you seem to be making some good progress on your own. I had much help from others when I was starting out, and I'm pleased to be able to return the favour. Some years from now (or maybe sooner), it will be your turn to be the guide. Once you become more comfortable with state machines, debugging and designing will go much smoother. Many experienced designers will routinely re-write source code which they've received from others. In re-writing the code, it forces you to understand the code at the same time you are adding your own comments and molding it to your own design style. If all source code worked perfectly, this would be unnecessary. You could treat the code as a 'black box'. Unfortunately, such 'perfect' code is rarely realised in the first draft. Regards, Bob 2- More or less yes, I've attached a picture of the measure of this. Blue wave is the rRxFifoWE signal, and the yellow one is the SPI clk. (in both pictures). Note that there are eight pulses of 25Mhz for each fifo save, but the time between saves in fifo is 480nSec, this is fine I supposed No, it's not fine. This is a very small, well-defined problem. This is a good problem for you to solve first. Fixing this will help you learn a bit about the core state machine, and help you learn how to debug state machines. This is an ideal learning and debugging problem. in the measures you can see clearly where is the dead time that brings me to 4.2mSec final elapsed time to read 512 bytes. 3 and 4- Yes, you can see it in the pictures. I've discovered that the dead time changes, probing with different cards, but always is a lot of time. Would you please explain what the two traces represent in the second waveform diagram? Now my problem is how to find where the core is losing so much time, due I've not write this core, and following the code, is too hard for me to follow what the man who did it, want to do. I get the impression that you aren't all that familiar with state machines. If so, this an important skill set to develop. As I mentioned above, I would suggest troubleshooting the dead time between writes to the RX fifo. This is a smaller problem, and a small problem is good for learning. I've noticed too , that in the opencores site, says that the core was updated June 10 2010, I've downloaded it again to see modifications, but the code is the same as before, so ????. I haven't looked at the code. Most designers include history notes in their source code, especially if the intend to distribute their code for others to use. Maybe there is a change history section in the 'readme.txt' file included with the archive. If you're still looking for change history, you can run a file compare program (there are plenty of freeware utilities available for download), and compare the two releases of unmodified source code. What is more important to you, fixing your design or learning how to fix your design? It's your decision, but it sounds like your design is mostly working. It may be faster and more instructive for you to stick with debugging the code you are currently using. Bob, do you have in hands this core, to get close it a view inside ? I'm not very good at debugging strange source code from a distance. I'm more than willing to help guide you in debugging your design yourself, however. And you seem to be making some good progress on your own. I had much help from others when I was starting out, and I'm pleased to be able to return the favour. Some years from now (or maybe sooner), it will be your turn to be the guide. Once you become more comfortable with state machines, debugging and designing will go much smoother. Many experienced designers will routinely re-write source code which they've received from others. In re-writing the code, it forces you to understand the code at the same time you are adding your own comments and molding it to your own design style. If all source code worked perfectly, this would be unnecessary. You could treat the code as a 'black box'. Unfortunately, such 'perfect' code is rarely realised in the first draft. Regards, Bob

RE: Testing an SDcard core. by btxsistemas on Aug 29, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q] No, it's not fine. This is a very small, well-defined problem. This is a good problem for you to solve first. Fixing this will help you learn a bit about the core state machine, and help you learn how to debug state machines. This is an ideal learning and debugging problem. [/q] Ok Bob, I will begin looking for that problem. [q] Would you please explain what the two traces represent in the second waveform diagram? [/q] Yes, the yellow one is the SPI clks, there are a lot in that image, each 4.2mSec. The blue one is the write fifo pulses together in about 245uSec, each the 4.2mSec again. They are consecutive block reads of 512 bytes each. [q] I get the impression that you aren't all that familiar with state machines. If so, this an important skill set to develop. As I mentioned above, I would suggest troubleshooting the dead time between writes to the RX fifo. This is a smaller problem, and a small problem is good for learning. [/q] Absolutely true, you're right, I should read a lot of theory, before try do do this.... I'm always very anxious to learn by myself, and that is so hard. [q] I'm not very good at debugging strange source code from a distance. I'm more than willing to help guide you in debugging your design yourself, however. And you seem to be making some good progress on your own. I had much help from others when I was starting out, and I'm pleased to be able to return the favour. Some years from now (or maybe sooner), it will be your turn to be the guide. Once you become more comfortable with state machines, debugging and designing will go much smoother. Many experienced designers will routinely re-write source code which they've received from others. In re-writing the code, it forces you to understand the code at the same time you are adding your own comments and molding it to your own design style. If all source code worked perfectly, this would be unnecessary. You could treat the code as a 'black box'. Unfortunately, such 'perfect' code is rarely realised in the first draft. [/q] What to say, you said all about this, you're right again, I will begin this (hope short)process of learn more about state machines, and try to debug and understand all the code done. Cheers. Alberto. No, it's not fine. This is a very small, well-defined problem. This is a good problem for you to solve first. Fixing this will help you learn a bit about the core state machine, and help you learn how to debug state machines. This is an ideal learning and debugging problem. Ok Bob, I will begin looking for that problem. Would you please explain what the two traces represent in the second waveform diagram? Yes, the yellow one is the SPI clks, there are a lot in that image, each 4.2mSec. The blue one is the write fifo pulses together in about 245uSec, each the 4.2mSec again. They are consecutive block reads of 512 bytes each. I get the impression that you aren't all that familiar with state machines. If so, this an important skill set to develop. As I mentioned above, I would suggest troubleshooting the dead time between writes to the RX fifo. This is a smaller problem, and a small problem is good for learning. Absolutely true, you're right, I should read a lot of theory, before try do do this.... I'm always very anxious to learn by myself, and that is so hard. I'm not very good at debugging strange source code from a distance. I'm more than willing to help guide you in debugging your design yourself, however. And you seem to be making some good progress on your own. I had much help from others when I was starting out, and I'm pleased to be able to return the favour. Some years from now (or maybe sooner), it will be your turn to be the guide. Once you become more comfortable with state machines, debugging and designing will go much smoother. Many experienced designers will routinely re-write source code which they've received from others. In re-writing the code, it forces you to understand the code at the same time you are adding your own comments and molding it to your own design style. If all source code worked perfectly, this would be unnecessary. You could treat the code as a 'black box'. Unfortunately, such 'perfect' code is rarely realised in the first draft. What to say, you said all about this, you're right again, I will begin this (hope short)process of learn more about state machines, and try to debug and understand all the code done. Cheers. Alberto.

RE: Testing an SDcard core. by eteam on Aug 30, 2010			eteam Posts: 32 Joined: Jun 5, 2009 Last seen: Mar 25, 2016
There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform? There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform?

RE: Testing an SDcard core. by btxsistemas on Aug 30, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q]There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform?[/q] Ha ha no Bob, it is not a school project, I'm 52 years old, neither a comertial project, it is for learn, for a challenge to read files more quickly as I usually do with a microcontroller, and maybe in some future, if I really need to do a project where I need to speed up the SD read task, will be usefull as comertial project. My market is very small here, and I can do all my customers ask for me, but I'm not never quiet, I want to learn more and more, so I bought a Altera DE2 board about year ago to learn about FPGAs, so I'm a begginer in this field, but just in a few days more I'll be selling a product to a customer of my, that uses a CPLD (VGA controller with SRAM for store images). So I take advance of what I learn too, I think it is good, but without getting crazy, and going slow. Happens that I love so much electronics, and for life circumstances, I can't get my diploma. :( All I designed was created by my mind, but yes, something are similar FSMs. OK, I will stop this, seems to be a psychology session...sorry :) Have a nice Monday Bob !!...and... what are you doing answering forums on Sunday night as me ??, I guess you love electronis too :) Cheers. Alberto. There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform? Ha ha no Bob, it is not a school project, I'm 52 years old, neither a comertial project, it is for learn, for a challenge to read files more quickly as I usually do with a microcontroller, and maybe in some future, if I really need to do a project where I need to speed up the SD read task, will be usefull as comertial project. My market is very small here, and I can do all my customers ask for me, but I'm not never quiet, I want to learn more and more, so I bought a Altera DE2 board about year ago to learn about FPGAs, so I'm a begginer in this field, but just in a few days more I'll be selling a product to a customer of my, that uses a CPLD (VGA controller with SRAM for store images). So I take advance of what I learn too, I think it is good, but without getting crazy, and going slow. Happens that I love so much electronics, and for life circumstances, I can't get my diploma. :( All I designed was created by my mind, but yes, something are similar FSMs. OK, I will stop this, seems to be a psychology session...sorry :) Have a nice Monday Bob !!...and... what are you doing answering forums on Sunday night as me ??, I guess you love electronis too :) Cheers. Alberto.

RE: Testing an SDcard core. by eteam on Aug 30, 2010			eteam Posts: 32 Joined: Jun 5, 2009 Last seen: Mar 25, 2016
[q]... what are you doing answering forums on Sunday night as me ??, I guess you love electronics too :) Cheers. Alberto.[/q] I'm self-employed. I don't get weekends or evenings off! Good luck with your project, sounds like you are having fun. - Bob ... what are you doing answering forums on Sunday night as me ??, I guess you love electronics too :) Cheers. Alberto. I'm self-employed. I don't get weekends or evenings off! Good luck with your project, sounds like you are having fun. - Bob

RE: Testing an SDcard core. by btxsistemas on Aug 30, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q]I'm self-employed. I don't get weekends or evenings off! Good luck with your project, sounds like you are having fun. - Bob[/q] I'm self-employed too, thank you so much again for your help Bob !! I'll be posting when I've more doubts or a progress, and yes, this is funny for me :) Best regards. Alberto. I'm self-employed. I don't get weekends or evenings off! Good luck with your project, sounds like you are having fun. - Bob I'm self-employed too, thank you so much again for your help Bob !! I'll be posting when I've more doubts or a progress, and yes, this is funny for me :) Best regards. Alberto.

RE: Testing an SDcard core. by rsdio on Aug 30, 2010			rsdio Posts: 17 Joined: Feb 1, 2010 Last seen: Mar 4, 2014
[q]There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform?[/q] Would you care to give pointers or links to any of these? There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform? Would you care to give pointers or links to any of these?

RE: Testing an SDcard core. by metalm on Aug 30, 2010			metalm Posts: 4 Joined: Aug 21, 2009 Last seen: Jun 5, 2012
[q][q]There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform?[/q] Ha ha no Bob, it is not a school project, I'm 52 years old, neither a comertial project, it is for learn, for a challenge to read files more quickly as I usually do with a microcontroller, and maybe in some future, if I really need to do a project where I need to speed up the SD read task, will be usefull as comertial project. My market is very small here, and I can do all my customers ask for me, but I'm not never quiet, I want to learn more and more, so I bought a Altera DE2 board about year ago to learn about FPGAs, so I'm a begginer in this field, but just in a few days more I'll be selling a product to a customer of my, that uses a CPLD (VGA controller with SRAM for store images). So I take advance of what I learn too, I think it is good, but without getting crazy, and going slow. Happens that I love so much electronics, and for life circumstances, I can't get my diploma. :( All I designed was created by my mind, but yes, something are similar FSMs. OK, I will stop this, seems to be a psychology session...sorry :) Have a nice Monday Bob !!...and... what are you doing answering forums on Sunday night as me ??, I guess you love electronis too :) Cheers. Alberto. [/q] Hi Alberto! my name is Diego from Argentina too, my suggestion is: if you want speed, then you need the SD in 4-bit wide mode (not-spi!) Altera DE2 only has wired it's SD slot in spi mode, so your only alternative is making your own sd adapter and connect it to another port. saludos! There is an abundance of good state machine design tutorials on the internet. Is this a school project or a commercial project? Have you designed any state machines of your own? What do you have for a development platform? Ha ha no Bob, it is not a school project, I'm 52 years old, neither a comertial project, it is for learn, for a challenge to read files more quickly as I usually do with a microcontroller, and maybe in some future, if I really need to do a project where I need to speed up the SD read task, will be usefull as comertial project. My market is very small here, and I can do all my customers ask for me, but I'm not never quiet, I want to learn more and more, so I bought a Altera DE2 board about year ago to learn about FPGAs, so I'm a begginer in this field, but just in a few days more I'll be selling a product to a customer of my, that uses a CPLD (VGA controller with SRAM for store images). So I take advance of what I learn too, I think it is good, but without getting crazy, and going slow. Happens that I love so much electronics, and for life circumstances, I can't get my diploma. :( All I designed was created by my mind, but yes, something are similar FSMs. OK, I will stop this, seems to be a psychology session...sorry :) Have a nice Monday Bob !!...and... what are you doing answering forums on Sunday night as me ??, I guess you love electronis too :) Cheers. Alberto. Hi Alberto! my name is Diego from Argentina too, my suggestion is: if you want speed, then you need the SD in 4-bit wide mode (not-spi!) Altera DE2 only has wired it's SD slot in spi mode, so your only alternative is making your own sd adapter and connect it to another port. saludos!

RE: Testing an SDcard core. by btxsistemas on Aug 30, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
[q] Hi Alberto! my name is Diego from Argentina too, my suggestion is: if you want speed, then you need the SD in 4-bit wide mode (not-spi!) Altera DE2 only has wired it's SD slot in spi mode, so your only alternative is making your own sd adapter and connect it to another port. saludos! [/q] Hi Diego. Yes, I know that, but I choose spimaster supposing that I could get at least 2000-2500Kbps at least (more than I get with the micro). I've a SD card socket to attach to the DE2, what I havent is any code for SD Mode. Do it by myself is very hard for me at this time. Maybe with my training, and getting a good speed with this core, Then I will learn more, and I would go for the SD Mode code. Thank you. If you want my private is: "btx" at btxsistemas (.com) plus the ar. Saludos. Alberto. PS: No tengo la menor idea de como hacer el codigo para el modo SD. Aun cuanto lei la especificacion, parece chio basico. :) Hi Alberto! my name is Diego from Argentina too, my suggestion is: if you want speed, then you need the SD in 4-bit wide mode (not-spi!) Altera DE2 only has wired it's SD slot in spi mode, so your only alternative is making your own sd adapter and connect it to another port. saludos! Hi Diego. Yes, I know that, but I choose spimaster supposing that I could get at least 2000-2500Kbps at least (more than I get with the micro). I've a SD card socket to attach to the DE2, what I havent is any code for SD Mode. Do it by myself is very hard for me at this time. Maybe with my training, and getting a good speed with this core, Then I will learn more, and I would go for the SD Mode code. Thank you. If you want my private is: "btx" at btxsistemas (.com) plus the ar. Saludos. Alberto. PS: No tengo la menor idea de como hacer el codigo para el modo SD. Aun cuanto lei la especificacion, parece chio basico. :)

RE: Testing an SDcard core. by btxsistemas on Sep 6, 2010			btxsistemas Posts: 27 Joined: Jun 21, 2008 Last seen: Aug 6, 2013
Hi all, I'm back again. After a long analisis of the FSM's, I get the following results. The rRxFifoWE time seems to be ok, it's about 480nSec, between pulses, due the lost clks during the code of the FSM. But.... what I found, is that in the readWriteSDBlock.v module, there is a big delay inserted into the RD_TOKEN_CHK_LOOP. (It is RD_TOKEN_DEL2 and RD_TOKEN_DEL3.) There is two anidated loops, that produces a big delay, I don't know exactly why those are there, but I found that reducing this dead time, I get until 1.1Mbytes/sec data transfer, not with all differents card, but adjusting this delay, I get with all cards that I've to test (three total) about 750Kbytes/Sec working fine. You can adjust that delay changing the "`define MAX_8_BIT 8'hff" constant in the spiMaster_defines.v file. Then I modified the FIFO part of the core, to get the data save in a SRAM of my DE2 board instead in the FIFO, after that, I insert a VGA crtl in my top module, to let me see a image previously stored in the SD card in a VGA screen, reading it from the SRAM. Ok, what I get, is that all works fine, but the data rate is very poor to show video with this configuration. Although I checked one card at 1.1Mbytes/Sec reads. (That's obviously) What I want to get with this core, is some speed close to 2.5Mbytes/Sec to get a reasonable video demo, but, seems that it is not possible using the SD in SPI mode. I believe that this speed limitation, is due the SD card type, more than the own core. What to you think ? I'll be listening for some comments. Cheers. Alberto. Hi all, I'm back again. After a long analisis of the FSM's, I get the following results. The rRxFifoWE time seems to be ok, it's about 480nSec, between pulses, due the lost clks during the code of the FSM. But.... what I found, is that in the readWriteSDBlock.v module, there is a big delay inserted into the RD_TOKEN_CHK_LOOP. (It is RD_TOKEN_DEL2 and RD_TOKEN_DEL3.) There is two anidated loops, that produces a big delay, I don't know exactly why those are there, but I found that reducing this dead time, I get until 1.1Mbytes/sec data transfer, not with all differents card, but adjusting this delay, I get with all cards that I've to test (three total) about 750Kbytes/Sec working fine. You can adjust that delay changing the "`define MAX_8_BIT 8'hff" constant in the spiMaster_defines.v file. Then I modified the FIFO part of the core, to get the data save in a SRAM of my DE2 board instead in the FIFO, after that, I insert a VGA crtl in my top module, to let me see a image previously stored in the SD card in a VGA screen, reading it from the SRAM. Ok, what I get, is that all works fine, but the data rate is very poor to show video with this configuration. Although I checked one card at 1.1Mbytes/Sec reads. (That's obviously) What I want to get with this core, is some speed close to 2.5Mbytes/Sec to get a reasonable video demo, but, seems that it is not possible using the SD in SPI mode. I believe that this speed limitation, is due the SD card type, more than the own core. What to you think ? I'll be listening for some comments. Cheers. Alberto.

First

Prev

2/4

Next

Last

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.