PTSmith

Newcomers
  • Content Count

    17
  • Joined

  • Last visited

About PTSmith

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you, JColvin! Might I suggest adding this very useful information to section 1.1 of the CMOD A7 data sheet. Paul Smith Indiana University Physics
  2. Yes, I think a schottky diode in series with pin 24 is the right way to go. Shorting D1 vs Removing D1 are completely different. Shorting D1 will "back power" the USB port as you say. But if D1 is removed then no current can flow either from or to the USB connector. The question is whether the USB communication will still work. Please ask your engineer whether removing D1 will cause the FTDI chip to lose power. My guess is that the FTDI chip gets powered from the 3.3 volt regulator and the CMOD FTDI USB will still work from user-supplied VU if D1 is removed.
  3. PTSmith

    CMOD A7 100 MHz clock in

    I have several of these available from other projects; I guess it is what you mean by a "stamp" module: https://store.digilentinc.com/jtag-hs3-programming-cable/
  4. PTSmith

    CMOD A7 100 MHz clock in

    The TE0725 looks like a good option for me.
  5. I don't understand why it is so hard for Digilent to answer this question; really this information should be on the data sheet.
  6. I'd like to know the answer to this question as well; does removing D1 work as expected? Does the USB communication still work if D1 is removed? How about a external diode in series with pin 24? Shouldn't this protect an external power source?
  7. PTSmith

    CMOD A7 100 MHz clock in

    OK, thanks for replying, xc6. I found the clock thread here: you populate IC4 and remove R80. I can put an Abracon ASEMB-100.00MHZ-LY-T there instead of the ASEM1 part on the schematic with better specs. Hopefully this will keep the 100 MHz noise on the CMOD, so maybe a better solution than bringing it in on LVDS. I haven't tried the LVDS_25 input as my CMOD is in my lab on campus and I'm not allowed to go in right now; so strictly thought based design work right now; mostly working on the system PCB. Yes, the one ground pin only is a big drawback for the CMOD. I've been thinking of allowing the option of soldering one or more braids from the CMOD ground to my PCB ground. It's not obvious there is a place to solder to on the CMOD, though, so probably not a good idea. There are two ground pins on the PMOD connector ... I did find a thread discussing using leftover IO pins as extra grounds: No convincing evidence in this thread that this helps, at least no measurements. Probably worth a try if all else fails, but I'm nervous about designing in the CMOD A7 and then not having it work. I can probably get away with the single CMOD A7 ground pin but I wouldn't mind looking at some alternative boards; this does seem like the weakest point in the CMOD A7 package.
  8. PTSmith

    CMOD A7 100 MHz clock in

    Hello xc6lx45, I suppose I could live with a single ended clock input to the CMOD A7; I'm mainly worried about radiating noise to nearby sensitive analog circuitry so think differential would be quieter. The mod to swap the oscillator on the CMOD A7 sounds interesting; I actually thought about this a while back. But, the 12 MHz also goes to the USB through R80 (is this the resistor you mention removing?) The USB bridge chip isn't shown on the schematics for some reason (I guess it's on the deliberately blank page 5) but unless there is some other option I would imagine the USB bridge doesn't work after this mod. Is there more information on this mod somewhere? If you look at table 1-55 in UG471 there is a superscript (1) for the LVDS_25 line which says "Differential inputs for these standards can be placed in banks with VCCO levels that are different from the required level for outputs. " Also, at the bottom of page 92: " It is acceptable to have differential inputs such as LVDS and LVDS_25 in I/O banks that are powered at voltage levels other than the nominal voltages required for the outputs of those standards (1.8V for LVDS outputs, and 2.5V for LVDS_25 outputs). However, these criteria must be met: The optional internal differential termination is not used (DIFF_TERM = FALSE, which is the default value)." So, I'm pretty sure I can use an LVDS input on the CMOD A7, although it would be nice to hear from someone who has actually done this.
  9. PTSmith

    CMOD A7 100 MHz clock in

    So, I want to bring in a 100 MHz clock and route it to a CMT to generate a bunch of lower frequency clocks all phase-locked to the 100 MHz. I appreciate I can't output an LVDS signal, but it looks like I should be able to bring in an LVDS signal as long as I supply my own 100 ohm termination to pins 18 and 19 for example. Am I missing anything? Paul Smith Indiana University Physics
  10. Modified test vhdl so I can start and stop writing with the two buttons on the CMOD A7. Wrote over 1 Gbyte with no problems. Wrote continuously for 100 sec and counted 554,508 blocks or almost 2.84 Mbytes/sec. So, almost 3X faster than what I need.🤣 Time to move on to design of the PCB.
  11. I modified my VHDL so that I can initiate a write of 256 blocks by pushing a button on the CMOD A7; it works as fast as I can push the button, so I guess my loop just tries again too soon; evidently the sd_busy being low doesn't really mean the card is ready for a new multi-block write. One new discovery; on maybe one out of 50 tries the write of 256 blocks takes longer than 50 ms; I've seen 63 and 76 ms. Still fast enough, but yet another thing I don't understand about SD cards.
  12. If I write 16 blocks it takes 6.44 ms, or 1.27 Mbytes/sec. If I write 32 blocks it takes 9.24 ms, or 1.77 Mbytes/sec. If I write 256 blocks, it takes ~50 ms, or 2.6 Mbytes/sec. One surprising thing is the value of erase_count doesn't seem to make any difference; for example changing from 1 to 32 when writing 32 blocks it still takes 9.24 ms; at least thats how long the sd_busy signal stays on. I haven't been able to write some number of blocks, terminate the write, wait for sd_busy to drop, then initiate another write of the same number of blocks; SimpleSDHC just stays always busy and stops acknowledging write data after the first block in the second group of blocks; sometimes with error 3, but usually no error. I guess what I have is good enough for what I want to do; I can just start a multi-block write and stream data to the SD card a block at a time. But I worry that I don't really understand why erase_count doesn't matter, nor why I can't stop and then start up writing again.
  13. So, multiple block write seems inherently faster: two blocks took 3.5 ms (faster than one block!). Maybe because of the erasing? 4 blocks took 3.9 ms; 525 kBytes per second.
  14. So, I had to work on other stuff for the last few months, but have gotten back to this. Found a controller I liked even better at: https://github.com/ibm2030/SimpleSDHC Was able to write a single block of 512 bytes to an SD card and view it on a Mac with: dd if=/dev/disk3 | hexdump | more It took 184 uS to transfer the data, or 2.8 Mbytes/sec. The card stayed busy for 5.3 mS, so write speed is 96.6 kbytes/sec. Seems plausible. However, not fast enough for my application; I'd like to get 1Mbyte/sec write speed if possible which would give me a comfortable margin. I want to try a multiple block write next which hopefully will be faster. I suppose the more blocks the faster. But, it's not at all clear to me what is the maximum number of blocks the card will accept. Also, it's not obvious what the erase_count input does or whether I need to use it. I guess I can figure it out, but wouldn't mind a hint.
  15. Fun and interesting read; I especially liked your term "jenga design". 😉 Here is an even newer version of the spec: https://www.sdcard.org/downloads/pls/ Neither include the SPI timing diagram; have you seen it anywhere? Probably not necessary... I presume your 8 Mbits/sec write to SD is averaged over some long time...