rehsd

In case anyone has followed Ben Eater and his 8-bit CPU project, I have built his 8-bit CPU in VHDL (after first building the breadboard version). I've learned much in the process (and have much more to learn). I thoroughly enjoyed the project. I've posted a series of updates in this blog post: VHDL 8-Bit CPU (Ben Eater edition) Working! (rehsdonline.com).
Edit: Updated with UART, Winforms app, and runtime RAM updates

In case anyone is interested, I posted a walkthrough of setting up an Arty A7-100T with the VGA Pmod, controlled by MicroBlaze. Suggestions to improve the write-up are welcome. Thanks!
https://www.rehsdonline.com/post/arty-vga-walkthrough

I'm currently working on building a 16-bit processor (breadboard/PCB-based). As part of this, I'm using an Arty Z7 to prototype concepts, and I have a VHDL version of the processor running. I'm using the HDMI output of the Z7 as a debug screen, which has been great.
A recent video giving a bit of an overview: 
I'm still working on the project. I'm posting updates to Building a 16-bit CPU on an Arty Z7-20.

Very cool project! Thank you for sharing!

I'm currently working on building a 16-bit processor (breadboard/PCB-based). As part of this, I'm using an Arty Z7 to prototype concepts, and I have a VHDL version of the processor running. I'm using the HDMI output of the Z7 as a debug screen, which has been great.
A recent video giving a bit of an overview: 
I'm still working on the project. I'm posting updates to Building a 16-bit CPU on an Arty Z7-20.

I was able to resolve this with the help of captain_wiggles_ over on r/FPGA. He/she pointed out that my frame pointer was a 32-bit pointer. I changed it to an 8-bit pointer and am writing the three bytes for red, green, and blue independently. Here is an updated function that prints a nice yellow box:

I was able to resolve this issue. For some reason, the block design wrapper was not updating with my changes. I deleted the wrapper, recreated it, and now everything seems to be working as expected.

I was able to resolve this with the help of captain_wiggles_ over on r/FPGA. He/she pointed out that my frame pointer was a 32-bit pointer. I changed it to an 8-bit pointer and am writing the three bytes for red, green, and blue independently. Here is an updated function that prints a nice yellow box:

I was able to resolve this issue. For some reason, the block design wrapper was not updating with my changes. I deleted the wrapper, recreated it, and now everything seems to be working as expected.

Vivado doesn't support any devices except Series 7 and later. Xilinx still posted a version of ISE in it's archives a while ago but it's a version of ISE 14.7 that has support for some devices removed. Getting any version of ISE to run on a recent version of Windows is not trivial.

Hi @rehsd,
It sounds like you got it working, but if you haven't seen it already you should take a look at this well done project by xc6lx45 on the Cmod A7:
Thanks,
JColvin

Hi @rehsd,
The main caveat I was going to mention was that the Pmod LVLSHFT does not work in a bi-directional fashion, but clearly you are already well aware of this limitation.
That being said, I think what you are proposing will work, or at least for what it's worth I would personally wire it up as you proposed (ensuring grounds between all the systems are connected of course) and presume that everything was going to work as advertised.
There is of course some delay associated with the translating of voltages, but this is in the single digit nanosecond range, as mentioned in Switching Characteristics section Table 7.8 of the SN47LVC1T45 datasheet (link).
Thanks,
JColvin

Hi @tnkumar,
That is correct. There are some considerations that you will have to take into account though.
The first, and most critical in my opinion, is logic resources on the FPGA; each Pmod takes some amount of the LUTs and other available logic resources on the FPGA. This can get further compounded if you use the Digilent made IPs which use different AXI peripherals to be able to communicate with the host processor (usually Microblaze on an Arty S7-50). I would highly recommend that you check that the designs you are intending to create are able to successfully fit and run on an Arty S7-50 by generating the bitstreams and if you are using a processor, the Vitis/SDK applications in advance before you buy a wide range of Pmods + the Pmod Shield, if only to save the hassle of returning products you aren't able to use.
The second is that most of Pmod ports on the Pmod Shield have 200 Ohm series resistors. In conjunction with the 200 Ohm series resistors that are also present on the Arduino styled header I/O pins on the Arty S7/A7/etc themselves, this can lead to some unexpected behavior on different modules i.e. slower speed, lower I/O voltage, etc, all potentially leading to the attached Pmod not working. I know I have experienced this first hand with different Pmods.
The third is power consideration. Most Pmods don't need a lot of power, but it's also non-zero amount. The DA9062 should be able to supply 2 amps worth of current on the 3.3 V rail, but Pmods are not the only things in the system that use that 3.3 V line.
My personal opinion, stemming from the second point and the fact that the Pmod Shield is no longer being sold/manufactured, is that if you are not considered about the overall look of the system, you may want to consider just individually wiring additional Pmods to the existing female header on the Arty S7, as that is all the Pmod Shield effectively does. This would also help facilitate using different features of communications like SPI where a number of the same communication lines can be shared between different Pmods, reducing the number of overall I/O used on the FPGA itself. You'd have to get the logic appropriately working to switch between the different modules at that point, but it's an aspect to consider when you have a lot of different modules on one system.
Thanks,
JColvin

Hi @rehsd,
This is correct. All of the instances in the Pmod Shield documentation that refer to JA, JB, etc., are referring to the Pmod Shield Pmod host ports themselves, not whatever host FPGA/microcontroller it might be placed on top of has in terms of Pmod ports (as an example, an Arduino board has no Pmod Host ports).
The way the Pmod shield makes the connections to the host system is through the pins on the underside of the board to connect to the female IO headers on the host system.
The bit about the SPI, UART, and I2C Pmods on the shield are only relevant for the Digilent microcontrollers since microcontrollers are hardwired to a particular protocol 'engine' on the processor. FPGAs do not have this limitation with pins connected to their fabric as you can configure the FPGA to create a protocol bus of whatever variety you like (limited by speeds, I/O standards, and termination of course, but that's not an issue for SPI, I2C, UART, and GPIO Pmods).
To configure those Pmod ports for something like the Arty A7 35T, you would do something like this in the .xdc (after you add the Pmod IP/Hierarchy and make the Pmod_out connection external, which you can then name to something else) for Pmod JA on the Pmod Shield:
#set_property -dict { PACKAGE_PIN U11 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin1_io }]; #Arty A7 Arduino header pin 26, Shield JA1 #set_property -dict { PACKAGE_PIN V16 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin2_io }]; #Arty A7 Arduino header pin 27, Shield JA2 #set_property -dict { PACKAGE_PIN M13 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin3_io }]; #Arty A7 Arduino header pin 28, Shield JA3 #set_property -dict { PACKAGE_PIN R10 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin4_io }]; #Arty A7 Arduino header pin 29, Shield JA4 Let me know if you have any questions.
Not on the weekends when the Digilent staff is not working. 
Thanks,
JColvin
 

To anyone struggling with DDR for processorless designs, have you looked at this?
https://forum.digilentinc.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/

Hi - I am Kumar. I just got my Arty S7-50 board today. I have an interest in robotics. I am looking to learn FPGA programming and considering using Verilog to start with. I also got a PMOD ENC. I hope I can learn by engaging in the forums

@rehsd - Good to know that you got your PMOD OLEDrgb to work. Today, I also got my PMOD OLEDrgb working. It is good to know that it is possible to add 2 PMOD OLEDrgbs to the same FPGA board, if needed
 

@thinkthinkthink, thanks again for your helpful suggestions. I was able to resolve the issue. I had to delete the design wrapper and recreate it. Everything is working great now!

@thinkthinkthink and @JColvin have been helpful with questions I have been posting.

I was able to get video output working! ? After moving data sections to DDR via the linker script, my build with 640x480 worked.

Hi @rehsd,
Yes, in general you should be able to use multiple of the same Pmod as all Microblaze would really see is that there is more than one AXI Quad SPI IP (in the case the Pmod OLEDrgb). The two IPs would need to have different names, but the names can be changed directly in the block design.
As a caveat, I haven't attempted this with the Pmod OLEDrgb in particular, but you would be able to add the extra IP in Vivado and see the bitstream still successfully generates (and if the SDK/Vitis still successfully builds the project) as much of the debugging work can be done prior to actually purchasing anything.
Thanks,
JColvin

Disconnect from the Board flow tab and try again with manual constraints.

Maybe it's also worth deleting the uartlite IP and adding it back again.

You can also try regenerating the bitstream after clearing IP cache from Tools->Settings->IP and/or manually constraining those pins in the board XDC file to your UART interface. It's pretty pointless to do any debugging if those pin connections haven't been made inside the FPGA. What I hope will happen is after you add an ILA to your design and regenerate the bitstream, Vivado will finally do its job properly during the synthesis and implementation phases.

Check your UART interface with an ILA. This should be the first thing to do when debugging in Vivado.

Welcome @rehsd!