That_Guy

Members
  • Content Count

    9
  • Joined

  • Last visited

About That_Guy

  • Rank
    Newbie

Recent Profile Visitors

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

  1. So my current project is very simple, but I've yet to settle on how the control logic is going to be implemented. I think the FSM and Microblaze are both perfectly viable solutions, but I want to find the intersection of maximum learning and minimum complexity. The controller will be performing three tasks: -Pass alternating I and Q data from another module via usb to the user. -Receive data from the user via usb to set a desired frequency. -Interface with the clocking manager to request the new frequency. I am sure I could create an FSM to accomplish this, the USB controller has already been done, my hesitation is a lack of understanding of the AXI4 and DRP interfaces. I am familiar with 8-bit RISC AVR microcontroller, and if given a similar structure, I would think designing with a microcontroller would be almost trivial, but there is surely a learning curve to climb. The question boils down in my mind to a balance between the complexity of the FSM and the learning curve of Microblaze. I also am inclined to say some introductory experience with Mircroblaze would likely be desirable for a future employer. What do you think would be a better opportunity for learning?
  2. That's the main reason I was so surprised the questionably old 47uF electrolytic loosely dangling off the power pins made such a difference. The spikes I was seeing with the scope were relatively high frequency (High frequency for me anyways, 500MHz >> x >> 100MHz) and I would have thought an electrolytic would not have made much in the way of a difference. The sketchy electrolytic is a low bar to set, and I feel good about calling my work better than that, so I'm willing to hope for good behavior with my project. And the board I'm putting together for the CMOD-A7 is an "RF" front end so I'm distributing that ~60uF across the board in appropriate locations, though I'm only doing 10uF and 100nF caps, but the project is also not required to pick up anything above about 5MHz so I mean really is it RF? Either way, I've spent a healthy amount of time looking up best practices to treat this as a dry run for actual high frequency PCB design. I'm a bit on a tangent here, but I'll post up in the projects section at some point soon.
  3. I'll drop my two cents in here, though it looks like a pretty well hashed, but I think there's a pretty simple explanation that either got missed, or I missed in reading the thread. I show very similar issues with the CMOD-A7 disconnecting from my laptop. I took a scope to the USB power pins and found 2.5 volt transients across what I'd guess is the main USB power decoupling capacitor. My connector is about one inch long. Just a USB A male to micro USB male adapter. I didn't have any issues when using a ~3 foot long USB cable with a ferrite bead, and there were no issues when I was plugged into a USB splitter using the 1" connection. Odd. So, being the undergrad student, I broke the USB rule of 10uF and just mechanically wrapped the legs of a 47uF crummy electrolytic cap between the ground and VU pins, and made sure the electrical connection was good and secure with a small piece of electrical tape (I'm being sarcastic, just to be clear) BUT! Much to my surprise with such a janky setup, the problem just about vanished. Lucky enough for me, I'm going to be plugging the FPGA into a PCB that will wind up having about 60uF of ceramic decoupling goodness, so I'll already be adding the soft start protection to meet the USB spec, and I can keep using the teeny tiny 1" connector, I think.... Time will tell. In my eyes, USB power is really surprisingly noisy or something on the FPGA is pulling very ugly power spikes. I'm inclined to blame USB, but either way the parasitic inductance of a long cable and or ferrite bead seems pretty important for this little device. Oh, and I'd assume the USB hub fixed the problem by adding its own power management circuitry, after all, you wouldn't want all of the other devices attached to disconnect because of a power dip from plugging in something new. I also made a lot of assumptions here, so please, I'd love to hear your thoughts.
  4. Thank you both @xc6lx45 and @D@n, LUTs of useful info. Gave me plenty to dive into and consider for this project. I'm very inclined at the very least to include space on the PCB for an analog mixer to extend the range.
  5. I ran the CMOD a7 test you wrote, and got 1568ms. Great first usb test, though compiling in C# was new for me. Always the little things that trip ya up! One of the things that I don't get about creating a LO, it seems like it's very desirable to have a pure sin wave, and I'm not familiar with any good method for building a wide range high frequency generator. I have a bit of a desire to go above the project description and tack on something to allow me to look at ~100Mhz FM band, or 88.5 to satisfy my NPR needs, but the only 'good' thing I've found for LO generators are VCO colpitts oscilators, and to make a wide range with those looks to be a bit of work. If there's an FPGA trick for making a LO I'd love to know
  6. Yup! I fully recognize that SDR is quite a deep topic, and the emphasis for this project is "very simple" lol. The FPGA will be primarily an interface between the ADC and computer, we are only receiving signals (other team is transmitting) and we are keeping it under ~5Mhz carrier which should eliminate the need for a mixer or some of the tricky analog front end. It's a very basic introduction to SDR, but more than enough to keep me busy for a bit. Matlab has been a wonderful resource for figuring things out in the earlier stages, and I'm sure it'll continue to help as my team figures out what we're doing wrong.
  7. That_Guy

    Board repository path

    This seems like a silly question, but I've been told as a rule not to spend more than an hour on a silly problem. I am getting a healthy couple of warnings in Vivado about the board repository path (see attached). Just a typo, missed a backslash in the path. I've already made sure all Vivado_init.tcl files are correct. The project implements just fine, but I would love it if my warnings were meaningful, and I'd rather not suppress warnings How would I go about editing the path to resolve the warning? Cheers
  8. Hello all, I am studying computer engineering, but I have a strong leaning towards the hardware side. I have played around with FPGAs a little in community college, and I'm diving into a more in depth course now. Great timing too, as I am planning to use an FPGA for a (very simple) software defined radio. For any other new users scrolling through here, my analog discovery 2 has been an invaluable tool as a portable starter scope. I'm sure I'll accumulate more gear in the future, but for now it's more than capable for what I need.