I enjoyed seeing you use DDT to test the memory/bram config. Very clever. I'd forgotten all about that tool. Are you planning a video on using dual clocks with the block ram on the ice40?
Thanks! Yeah, I have been using dual clocks on some tests. But I can't use them with my 2067 Z8S180 board because A6 is connected to a pin that becomes special purpose (output only) if I try to use PLL #2 on the 2057 FPGA board. 😞 Eventually, I will put together a single board with an FPGA, CPU and I/O interfaces on it and will change the pin assignments at that time to remedy this issue.
@@JohnsBasement I was thinking along the lines of a video explaining how to interface block ram for a vdp. The CPU runs at 18.36MHz and the pixel clock is likely to be 25MHz as that clock is available from an external source. Looking forward to future videos in this series as I always learn or relearn something.
@@DennoWiggle Yes. As luck has it, I have 25 on the oscillator. As I approach the VDP, I should be able to clock the CPU-side of the BRAMs with the PHI clock and then run the read-side at 25MHz in a write-only style configuration and have no domain crossing concerns. Later, if I decide I want the CPU to be able to read from the BRAMs that hold the video data, I will have to add a TDM MUX and synchronize the read transactions to the PHI clock between read accesses by the video-generator logic. Worst case, we might have to add wait-states.
Thanks John. This is a good explanation. I recall reading something in the data sheets about the timings for bram. It takes one clock to latch the address and then the data out is stable on the next clock. This would have interesting impacts on VGA circuits I think. Would the sync and other signals from a VGA circuit have to be delayed to account for the 2clock cycle access time in the bram?
Be careful how you count the cycles. Assuming you are talking about the VDP test code (part of the github repo, but work in progress) there SHOULD be one clock that sets the read-address and then the next clock will load the data into the pixel shift-register. The entire thing is currently implemented as a simple pipeline. Run the test bench, you SHOULD see the enable on the shift register go active after the clock cycle that set the read address for the BRAM.
I think the fact they call it dual port is fine. It's just "Simple Dual Port" as opposed to "True Dual Port" which might be what most people expect. On Xilinx block RAM has different port modes depending on how it's configured too, as you eluded to. Like everything in electronics design everything comes in many flavors and levels of capabilities making everything more complex to design around.
+1 being interested in seeing video added to the project. I‘m not quite getting the obsession of swapping in the video memory into the cpu memory space though (at least on slower 8bit cpus which the s180 isn’t) the s180 can transfer memory contents very quick and efficiently with its DMA controller which has access to the full 1MB address space btw.but because often times you transfer data in blocks you could also implement vram access via auto incrementing address counters in the video circuitry (like it was done in many old video chips TMS9918A, MOS8563 VDC, NEC μPD7220… and the CommanderX16’s VERA does this too) I think this would be quite fun having a self contained little s180 with color text or even tile based graphics+ some sprites 😮
Wow. So in depth. How many videos are you planning for this series.
I don't know yet. This series will likely run into 2026 and then some as I go where my hobby takes me.
I enjoyed seeing you use DDT to test the memory/bram config. Very clever. I'd forgotten all about that tool.
Are you planning a video on using dual clocks with the block ram on the ice40?
Thanks!
Yeah, I have been using dual clocks on some tests. But I can't use them with my 2067 Z8S180 board because A6 is connected to a pin that becomes special purpose (output only) if I try to use PLL #2 on the 2057 FPGA board. 😞
Eventually, I will put together a single board with an FPGA, CPU and I/O interfaces on it and will change the pin assignments at that time to remedy this issue.
@@JohnsBasement I was thinking along the lines of a video explaining how to interface block ram for a vdp. The CPU runs at 18.36MHz and the pixel clock is likely to be 25MHz as that clock is available from an external source. Looking forward to future videos in this series as I always learn or relearn something.
@@DennoWiggle Yes. As luck has it, I have 25 on the oscillator. As I approach the VDP, I should be able to clock the CPU-side of the BRAMs with the PHI clock and then run the read-side at 25MHz in a write-only style configuration and have no domain crossing concerns.
Later, if I decide I want the CPU to be able to read from the BRAMs that hold the video data, I will have to add a TDM MUX and synchronize the read transactions to the PHI clock between read accesses by the video-generator logic. Worst case, we might have to add wait-states.
Thanks John. This is a good explanation.
I recall reading something in the data sheets about the timings for bram. It takes one clock to latch the address and then the data out is stable on the next clock. This would have interesting impacts on VGA circuits I think. Would the sync and other signals from a VGA circuit have to be delayed to account for the 2clock cycle access time in the bram?
Be careful how you count the cycles. Assuming you are talking about the VDP test code (part of the github repo, but work in progress) there SHOULD be one clock that sets the read-address and then the next clock will load the data into the pixel shift-register. The entire thing is currently implemented as a simple pipeline. Run the test bench, you SHOULD see the enable on the shift register go active after the clock cycle that set the read address for the BRAM.
I think the fact they call it dual port is fine. It's just "Simple Dual Port" as opposed to "True Dual Port" which might be what most people expect. On Xilinx block RAM has different port modes depending on how it's configured too, as you eluded to. Like everything in electronics design everything comes in many flavors and levels of capabilities making everything more complex to design around.
+1 being interested in seeing video added to the project. I‘m not quite getting the obsession of swapping in the video memory into the cpu memory space though (at least on slower 8bit cpus which the s180 isn’t) the s180 can transfer memory contents very quick and efficiently with its DMA controller which has access to the full 1MB address space btw.but because often times you transfer data in blocks you could also implement vram access via auto incrementing address counters in the video circuitry (like it was done in many old video chips TMS9918A, MOS8563 VDC, NEC μPD7220… and the CommanderX16’s VERA does this too) I think this would be quite fun having a self contained little s180 with color text or even tile based graphics+ some sprites 😮
Stay tuned!!!