robfinch

Thanks, yes, there are a lot of issues to resolve when using the DDR3 RAM. It is definitely very challenging to make use of the DDR3 bandwidth, especially if multiple devices need to access the RAM. I have been working on a memory controller to make this easy to do which sits between the MIG controller and the rest of the system. It is available at: https://github.com/robfinch/Memory-Cores/tree/main/mpmc10, but is still “in the works”. Using the MIG controller the latency is something like 25 clock cycles, although the throughput is single cycle excluding things like refresh and commands. I figure one is doing very well to make use of ½ the max bandwidth in a system with multiple bus masters needing access to the RAM. 1/4 is probably more realistic. I ended up building the multi-port memory controller with a system cache. A lot of bandwidth is made use of by burst fetching multiple 128-bit packets. The MIG controller burst fetches 16 bytes per burst, then the MPMC bursts the burst fetches. Streaming ports in my MPMC fetch 64 * 16 byte bursts or 1024 bytes at a time. With a fixed latency of about 29 clocks to fetch 16 bytes fetching 64 times as much data takes only about 100 clocks. This is not much worse than some of the longer running CPU instructions.

You could also use a delta-sigma DAC with an output pin connected to a Resistor-Capacitor. It requires a high-impedance buffer to use the output.

Okay, I am confused now. DDR RAM AFAIK uses both edges of the clock to transfer data. While the clock is 400MHz using both edges means twice the data is transferred per clock. I think that means that data is effectively transferred at 800 MHz. Since it is a 16-bit bus that is 1600 MB/s.

II figured this issue out shortly after posting.

Thanks for the heads-up on the OLED display. I am looking forward to an updated OLED core. I have not worried about the power cycling and been using FPGA for about six years so far. The OLED still works; but I have not used it for every project. I find the OLED is too small to read at a distance. I have the FPGA board on a table about 10 feet from my workstation. I use the HDMI port and a monitor to get a readable display. It would be better to have the OLED display hooked up with a longer cable and that likely means some sort of serial interface. I find the PMODs work okay for me. I use the 12-bit ports as two independent six bit ports sometimes. They are not designed to be high-speed device I/O. Since they are generally not connected to high-speed I/O perhaps a pmod expander port based on shift registers could be useful. A couple of PMODs on my wish-list are a source of random values, and a color composite output module.

I am wondering how there could be any issues with using the USB serial port and keyboard at the same time? In my current project using the serial port causes the keyboard to misbehave. Also, sometimes the keyboard is frozen when the FPGA is loaded. Powering off and on, or unplugging and plugging the keyboard back in again fixes this. Has anyone heard of issues like this? The project I am working on is pretty complex, a multi-core 68k system so I suspect it could be either a software or hardware issue in the code somewhere. I thought I would check in case someone else found a similar issue, I have been trying to resolve this issue for days.

It sounds to me like the OP is trying to replicate an incoming waveform at half frequency. I have not used this before, but could not the triangle wave be fed into the analog input ports of the FPGA, measured with XADC component, recorded then output at one half the rate? A delta-sigma DAC could be used for output.

You have got me thinking about what I am trying to do. I may be trying to put too much functionality into one CMod. I suppose I could use multiple CMods but that’s a pricey solution. I like the fact that it can be treated like an IC and embedded into another project without having a huge board and cables. The small form factor appeals to me. It can be used as a prototype to the FPGA chip without having to develop a board. I suggested a 64-pin 0.9” wide dip as it still fits in a breadboard. But a 68 pin PLCC form factor would be okay too; might be harder to prototype with though. The lots of undedicated I/O pins appeals to me. I have designed a CModA7 into a single board computer where it is used for miscellaneous functions including address decoding for other devices, so lots of address inputs, serial I/O port, VGA port. Address and data bus, plus read/write and circuit select take 26 pins. There are only 44 digital I/O on a CModA7. I would like to be able to support two or more serial ports (with cts, rts) and more VGA output signals, but there just are not enough pins. Seems like I need jut a few more pins. I would like it also to control a clock generator. And SPI port as well. Random bitstream port. So, some more GPIO’s would be good. Even if there were only a handful more pins some sort of I/O muxing could be done. Things I do not care about for the CMod: More switches and LEDs and other random peripherals. DDR memory. I have been looking at a ZYNQ board as it has some appeal having the processor on board already.

I like the CModA7 but wish it had a few more I/Os; I am always running out. A 64-pin dip module would be great.

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.

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 from dumping the read data into a reg to dumping it into a block RAM cache. It seems to work perfectly now. Now I am wondering about the power consumption of the controller if just keeps reading data even if the data is not needed. How does the read get shut off? What happens if the write fifo is full? Does a write command need to be issued to empty it?

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 WISHBONE interconnect in my project. AXI is a great way to go, but it has a little bit more overhead to it.

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 020 333 333,-3/3 :010038 333 333 010 333 333 01C 020 024 33+,3330 :010040 333 333 010 014 333 333 333 024 33+,3.30 :010048 333 00C 010 333 018 01C 333 333 )*33-3/3 :010050 333 00C 333 333 018 01C 333 333 )333-3/3 :010058 333 333 010 333 333 333 020 333 3333-3/3 :010060 333 333 010 014 333 333 333 024 33+,3.30 :010068 333 00C 010 333 333 01C 020 333 )*+3-.33

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.

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 first one can be updated. I was wondering if there was an alternate slower part that could be selected in the MIG generator? I would like to experiment with lower clock rate. The minimum clock rate for the part still appears to be too high. The clock rate only goes down to 600MHz and I would like to try 533 to see if things work. My gut tells me the RAM has gone bad.

I found another device placing data on the data bus at the same time. After fixing this scan-codes appear to be okay.

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 way to fix this?

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.

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.

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 maybe the ram cells were being discharged by extra long cycles.