• Content Count

  • Joined

  • Last visited

  1. lovely, I seem to have been defeated by a misleading Vivado message. Marking this as solved.
  2. 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}
  3. 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
  4. 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
  5. 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>
  6. 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
  7. 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
  8. 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