okonomiyonda

Members
  • Content Count

    11
  • Joined

  • Last visited

  1. Well, the first part of my question is answered. I tried again with some older iPhone headphones, and the headphones that came with Project Morpheus, and neither of those had the extreme distortion. Then I retried with my Sony WH-1000MX3s, but this time with the power off in pass through mode. Distortion was gone. I kept playing the same scale, but toggled the headphone power on and off, and was able to repro/fix the distortion. So it really seems like for some reason talking into the mic (or the mic picking up on the sound from the headphones) was causing the distortion. Weird. The weird
  2. I have some RTL to generate square waves and output them to the AMP3, but I am getting some interesting distortion. For my test, I generate square waves for ascending notes from C3 (130.8Hz) to B5 (987.799Hz), and repeat. The lowest 14 notes sound horribly distorted, the middle octave notes sound OK, while the highest notes have some really weird super low pitch harmonics I can hear. I'm almost 99% sure this is a stupid RTL bug, but I want to check my assumptions first assumption 0: class D amplifiers can work with my headphones. I did see this interesting thread claiming that a cla
  3. Super late on this, but I am posting just in case anyone reads this in the future. AMP3 does indeed have an I2C config mode, but it also has a simple mode that requires no configuration aside from setting some jumpers. You pass it a few clocks, and the I2S serial data, and its off you go. No I2C required
  4. lovely, I seem to have been defeated by a misleading Vivado message. Marking this as solved.
  5. new hypothesis. I'm not great with analog electronics, but decided to take a look at the schematic anyway https://reference.digilentinc.com/_media/reference/programmable-logic/arty-a7/arty_a7_sch.pdf Assuming the bit at the top is the PMOD headers, I notice that the JA and JD pins are labeled {JA1, JA2, JA3, JA4, JA7, JA8, JA9, JA10} {JD1, JD2, JD3, JD4, JD7, JD8, JD9, JD10} But the B and C pins have positive and negative appended to their names {JB1_P, JB1_N, JB2_P, JB2_N, JB3_P, JB3_N, JB4_P, JB4_N} {JC1_P, JC1_N, JC2_P, JC2_N, JC3_P, JC3_N, JC4_P, JC4_N}
  6. Looking at this a little closer, it seems some boards have positive and negative swapped because of PCB routing considerations. If this is what's going on, what is the best way to deal with this for the HDMI data and clock? I currently have OBUFDS OBUFDS_red (.I(TMDS_shift_red [0]), .O(hdmi_out_p[2]), .OB(hdmi_out_n[2])); OBUFDS OBUFDS_green(.I(TMDS_shift_green[0]), .O(hdmi_out_p[1]), .OB(hdmi_out_n[1])); OBUFDS OBUFDS_blue (.I(TMDS_shift_blue [0]), .O(hdmi_out_p[0]), .OB(hdmi_out_n[0])); OBUFDS OBUFDS_clock(.I(clock_in_25MHz_pix), .O(hdmi_out_p[3]), .OB(hdmi_out_n[3])); So it wo
  7. I recently moved my HDMI project from S7 to A7, and I am getting implementation warnings leading to bitstream errors. On the S7, I had to following setup // HDMI notes: we're using pmod JA. // for the S7: // top row is N14, M14, L18, L17 // bot row is N18, M18, M17, M16 // so TMDS1 is {L18, L17} = {hdmi_out_n[1], hdmi_out_p[1]} = green // so TMDS0 is {N14, M14} = {hdmi_out_n[0], hdmi_out_p[0]} = blue // so TMDS2 is {M17, M16} = {hdmi_out_n[2], hdmi_out_p[2]} = red // so CLOCK is {N18, M18} = {hdmi_out_n[3], hdmi_out_p[3]} where my constraints file has ## PMOD Header JA se
  8. First of all, thanks for the reply. That really cleared up quite a few things for me. if I understand you correctly, I think the board file lives at MIG_IP.srcs\sources_1\ip\mig_7series_0_4\mig_a.prj for me. If that's the right file, it seems to have the incorrect input frequency in it <Controller number="0"> <MemoryDevice>DDR3_SDRAM/Components/MT41K128M16XX-15E</MemoryDevice> <TimePeriod>3000</TimePeriod> <VccAuxIO>1.8V</VccAuxIO> <PHYRatio>4:1</PHYRatio> <InputClkFreq>333.333</InputClkFreq>
  9. starting a new post rather than repeatedly editing the original. I have made a bit of progress. Diffing the A7 and S7 mig projects, the main ayashii difference was the S7 sets sysclock to Single-Ended, and refclock to No Buffer. The A7 project uses No Buffer for both clocks. Changing the A7 project sysclock to Single-Ended allows me to successfully get through implementation. However I do still have a few questions. Is modifying the mig project really what I have to do? I don't see many other people posting they they had to change things Is there a way to get it to work with No Buf
  10. hey everyone I'm trying to get the MIG-generated DDR3 example working on my Arty A7-100. I'm using the mig project at https://github.com/Digilent/vivado-boards/blob/master/new/board_files/arty-a7-100/E.0/mig.prj and my ucf is Arty_C_mig.ucf. I have a clock wizard generating a MMCM, taking in the 100MHz clock and outputting a 200MHz clock for the refclock and a 166.66667MHz clock for the sysclock. When I run implementation, I get the following warnings and errors [DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell u_mig_7s
  11. I'm just getting started with FPGAs, Arty, and Zynq, so I apologise if this is a beginner question or what I'm saying doesn't make total sense. I'm trying to figure out how to read/write DDR and use the UART from the FPGA side with no involvement from the CPU/PS. I've seen Vivado tutorials where you connect the FPGA over AXI and have the CPU sit in a while loop and printf to the UART. I've seen Vivado tutorials where the CPU sits in a while loop, waits for AXI data or interrupts from the FPGA, reads data from memory, flushes the cache, and sends the data to the FPGA. What I can't seem to