robfinch

Members
  • Content Count

    28
  • Joined

  • Last visited

  1. robfinch

    Slow DDR3 RAM down

    I would agree with that. That is why I was wondering if there was a shutoff command? Suppose a burst of 4 packets of 128 bits is to be read. How does the controller get shutdown after reading the 4 packets? There is a READ command (001) and WRITE command (000), are there others? As far as I can tell, it will just keep reading, likely until it fills its fifo at least.
  2. robfinch

    Slow DDR3 RAM down

    I built and ran the DDR Test project and captured some output from the serial port. Found two issues with my code. 1) Multiple read commands were being sent back-to-back. It looked to me looking at the user guide 586 that this was needed to be able to read multiple data packets back. I now understand that the controller simply reads more-and-more data once a single read command is issued. 2) The address was being incremented for each read command submitted. Fixing these two issues did not give better results. There must still be another issue somewhere. I got it working! I switched f
  3. robfinch

    Slow DDR3 RAM down

    I am not saying there is anything wrong with the DDR controller. I only posted because I already spent two or three days looking for issues in my own code and cannot find any. It is modelled after the DDR controller code provided by Digilent. I have created a multi-port memory controller which allows multiple devices to access the RAM, each has its own read cache. I am sure there is a bug somewhere, but for now, I would just like to be able to try a lower frequency, in part if it works, I can postpone looking for the issue with my code and work on other parts of the project. I am using a WISHB
  4. robfinch

    Slow DDR3 RAM down

    Yes, thanks for the reference. Almost but not quite working, just by lowering the DDR3 clock frequency. At a higher frequency nothing gets written. So I would like to be able to try a lower frequency yet. $$F 10000 20000 333 $$D 10000 20000 :010000 333 333 010 014 018 01C 020 333 )*+3-3/3 :010008 333 333 333 014 018 01C 020 333 )*3333/3 :010010 333 00C 333 333 333 01C 020 024 33+3-3/0 :010018 333 00C 010 014 018 333 020 333 )*3,-3/3 :010020 333 00C 010 333 018 333 333 333 )*3,-3/3 :010028 333 333 333 014 333 333 020 024 )*3,3./3 :010030 333 00C 010 333 018 01C 0
  5. robfinch

    Slow DDR3 RAM down

    I was thinking of the DDR3 rate. The clock I was using was only 300MHz (which is used for double data rate transfers). But that is about the minimum accepted. I am too lazy to look up all the specs and try and define a custom slower part.
  6. robfinch

    Slow DDR3 RAM down

    It has been challenging getting the DDR3 RAM on the NexysVideo board to work reliably. For a while it appeared that the RAM might be bad. I tried running the traffic generator example and it reported no errors. However, my own circuit apparently causes issues. I spent a couple of days trying to identify what was creating an issue. The interface to the MIG component appears to be straight-forward. Writing to the RAM only updated the first byte in a burst. Then I tried lowering the clock rate to the DDR RAM and now it almost works. It is still not 100% but much better. Bytes other than the firs
  7. I found another device placing data on the data bus at the same time. After fixing this scan-codes appear to be okay.
  8. Having some issues with the host USB to PS2 interface on a NexysVideo board. The interface is returning $F8 instead of $F0 for the key-up scancode. It also looks like at least some of the other scan-codes are incorrect as well. Two different keys are returning the same scan-code. I have tried two different circuits, one I made myself, and one provided by Digilent with exactly the same results. I have tried two different keyboards with the same results. Is this an issue with the USB to PS2 PIC controller on the FPGA board? What could be causing this issue? Is it a common phenomena? Is there a w
  9. I would like to use a USB keyboard and mouse with a CmodA7. What is the best way to interface the USB to the CModA7? I have a PS2 controller or uart core available already. I would prefer some sort of adapter to PS2.
  10. It turned out not to be the RAM or controller. There was an overlapped buffer in software, updates by one routine trashed the values of the other.
  11. My project seems to work except for getting bits set high on readback from the sram. Would it help to put pulldowns on the sram data bits? For example: $FFFC0CDC is written and $FFFC0DCD ends up being read back. I can see this in the ILA. It does not seem to matter what the ram address is, bits are drifting high. The ram controller is running with a 120MHz clock. I've tried stretching out the write cycle or using multiple writes until the value written is read-back. I have also tried triplicate reads of the ram and using majority logic. I tried a slower clock as well, but my thought was that m
  12. I am using a slightly modified version of the I2C controller from opencores.org by Richard Herveille. The eeprom is being accessed programmatically by a RISCV compatible core that I'm working on. The controller and software work fine with the real-time-clock pmod. What I'd like to know is if the address is correct. I've seen zeros returned before for an incorrect address. I've tried both addresses. If I know the address is correct then I can eliminate that from my debugging. (Not using MicroBleze or AXI IIC bus interface IP).
  13. I'm having trouble accessing the EEPROM containing a MAC ID on the NexysVideo board and was wondering what the correct I2C address was? In the docs it says 1010000b but on the schematic it has address line a0-a2 tied high making the address 1010111b. The I2C is constantly returning all zeroes. The I2C controller (a different copy of it) in use accesses another I2C device without issues.
  14. The serial transmitter and DMA channel are on one side of a dual ported block ram, which has it's own clock domain. Ditto for the receiver. The other side of the block ram is connected to the micro on a different clock domain. In short the block ram is used to cross domains. It should be okay. There is also a global high-speed clock (100MHz) for some timing.
  15. Got it to work (serial version). First version. Hard-coded "Hello World!". The whole soc with transmit and receive is only about 300 LUTs. Probably a lot fewer LUTs than would be required for a video display. Now to get the micro working.