Cmod out of the box code porting uart txd and rxd to gpio

[james Shaw]

Hello I've loaded the out of the box cmod A7 35T code to Vivado, I can load the code to the cmod but i'm having trouble making mods all id like to do is route the TXD and RXD uart signals to poi1 and poi2

Thank you

[JColvin]

Hi @james Shaw,

You can do this by with the following steps:

- Open the Out of Box demo in whatever version of Vivado you have, and then open the Block Diagram for the OOB.
- Go to the AXI Uartlite IP on the right hand side and delete the existing "usb_uart" port coming off the right hand side of the IP block.
- Double click on the AXI Uartlite IP to bring up the IP configuration wizard. In the Board tab, change the board interface dropdown from "usb uart" to "Custom" and then select OK.
- Expand the UART interface on the IP so that you see the rx and tx lines individually.
- Right click on both of them individually and select the "Make External" option. By default this will create two ports named "rx_0" and "tx_0", though you can rename them to whatever you like in the External Port Properties box in Vivado.
- Go to the Sources tab and right-click on the Constraints folder and select "Add Sources"
- Select "Add or Create Constraints" and then either add an existing Cmod A7 .xdc file (one is available Digilent's Github here: https://github.com/Digilent/digilent-xdc/blob/master/Cmod-A7-Master.xdc) or you can create your own if you don't want to have a file filled with commented out lines.
- The two lines you want for TxD to be assigned to pio1 and RxD to pio2 are as follows (formatted based on lines 42 and 43 of the above linked Cmod A7 master .xdc file)

set_property -dict { PACKAGE_PIN M3    IOSTANDARD LVCMOS33 } [get_ports { tx_0  }]; #IO_L8N_T1_AD14N_35 Sch=pio[01]
set_property -dict { PACKAGE_PIN L3    IOSTANDARD LVCMOS33 } [get_ports { rx_0  }]; #IO_L8P_T1_AD14P_35 Sch=pio[02]

- Generate the bitstream
- Profit?

This modification of course will not let you directly see the uart output on your computers serial terminal via whatever COM port as you are no longer sending the UART signals over the USB-UART bridge, but rather the two GPIO pins.

Thanks,
JColvin

[james Shaw]

I tried this and these are the errors

 

[JColvin]

Hi @james Shaw,

Could you attach a picture (or pdf output) of your block design and your .xdc?

Thanks,
JColvin

[james Shaw]

user_35t.pdfuser_35t.pdf

CMOD_A7_1166.xdc

[james Shaw]

This were I'm at today

 

CMOD_A7_TXD_GPIO_Port.pdf

[JColvin]

Hi @james Shaw,

The critical warning (UART has associated board param UARTLITE_BOARD_INTERFACE, which is set to board part interface usb_uart, but IP interface is not connected to any external port) can be fixed by double clicking on the AXI Uartlite IP in the Block Diagram. to bring up the IP configuration wizard. Then in the Board tab, change the board interface dropdown from "usb uart" to "Custom" and then select OK. Vivado will then probably want you to regenerate the bitstream.

The latest post of the log doesn't provide enough details as to what the issue might be; I would need to see the Messages tab. Presuming it is the same error associated with your earlier post here, https://forum.digilent.com/topic/23006-cmod-out-of-the-box-code-porting-uart-txd-and-rxd-to-gpio/#comment-67396 , that should be resolved by the steps in the above paragraph.

If this does not resolve the issue, let me know.

Thanks,
JColvin

 

[james Shaw]

Vivado_Error_log.txt

[james Shaw]

how do you make the CMOD A7 keep it's downloaded program after power cycle, and not return to the out of the box program?

 

[Pasqualino31]

I have been unable to get the My UART  (I've used my own design and several other verified designs) to take I/P from the keyboard using TeraTerm.  I came to the conclusion that it's not possible due to some proprietary wiring/configuration of the CMOD/FT2232H.

I purchased an FT2232H Mini Module which sits in a socket on an actual circuit board as does the CMOD-A7 and is wired to the CMOD board through the PMOD connector and by direct connections on the circuit board.  https://ftdichip.com/products/ft2232h-mini-module/

 

The FT_Tx is connected to the Rx I/P in my VHDL project and FT_Rx is connected to the Rx I/P.  I use the individual USB ports to power each of the boards, but The FT2232H does have it's ground connected to the CMOD-A7 board through a ribbon cable connecting the PMOD's together.  The CMOD-A7 is happy with this power configuration unless I connect the FT2232 to my desktop where the USB cable shields pulls everything to Earth ground.  I'm using laptops to get around this issue, but I was surprised that the USB cable actually had the metallic connector shell tied to its shield and was surprised that I picked up Earth ground in this manner.  Tying chassis of two units together through a cable is a built in ground loop.  The cables for the CMOD-A7 (and the Arty, which I am also trying out only with ALL the UART sigs connected through  the ribbon cable.) have completely isolated grounds.  The USB cables outer shells are not tied together and the FPGA App boards' PCB mounted shells are not connected to GND.

 

So after sorting through all this I get nothing on Rx or Tx.  I can transmit through the FT2232H 'on board' the CMOD (Just reading characters out of a ROM for a "Welcome Message" and sending them out through my UART Tx in the project.  It works fine so I know that circuit is good.)  The FTD drivers are obviously good, so it is some configuration or connectivity issue.

Maybe I need pullups on the OBUF's on the FPGA.  I included a schematic of how I have this wired up.  I followed the FT2232H Mini-Mod manual verbatim for self powering 

https://ftdichip.com/wp-content/uploads/2020/07/DS_FT2232H_Mini_Module.pdf

Page 7 describes how to wire up the module for USB self-power.

I'm going to double and triple check the connections and try pullups for driving the Mini-Mod.  I have an ILA configured and it shows data out, but none in.

 

Maybe there's something else I'm missing?

 

-Patrick

 

 

Edited June 14, 2022 by Pasqualino31
Incorrect Schematic

[zygot]

5 hours ago, Pasqualino31 said:

I have been unable to get the My UART  (I've used my own design and several other verified designs) to take I/P from the keyboard using TeraTerm.  I came to the conclusion that it's not possible due to some proprietary wiring/configuration of the CMOD/FT2232H.

No, you came to the wrong conclusion. Most UART issues are related to:

• Confusion with what device is driving the TxD and RxD pins... the FPGA or the USB UART bridge device.
• OS enumeration issues. For Windows add driver issues.
• A COM or TTY device already being used by another application ( like Xilinx tools )
• If you also work with Intel FPGA devices Windows has a problem deciding if an FT232x device is an Altera ByteBlaster or a COM device. It can get to be quite problematic if not addressed

Historically, CMODs have had issues with the COM device, especially if used at the same time as the JTAG device as one might do in Vivado Hardware Manager using an ILA or VIO.

Shield signals are meant to be isolated from Digital Ground.

I've used plenty of FTDI bridge device modules like the one that you are using. Good for high speed parallel data modes. Expensive as an alternate USB UART. Using these modules just adds complexity to a standard UART operating at 921600 or less.

By far the easiest to use for any FPGA board is the USB to TTL Serial Cable from Adafruit. All you need is two FPGA GPIO pins and a DGND pin. I never use the VBUS wire. It's also the cheapest way to add a UART to an FPGA design at the moment, that I know of. Adafruit and Sparkfun both have cheap USB TTL UART breakout boards. They are all a lot cheaper than an FTDI module. Make sure that your UART is compatible with your FPGA board. Usually this is 3.3V logic. UltraScale boards might require a lower logic voltage. There are TTL USB UART adapters to work with other voltages.

Unfortunately, this is a bad time to be buying these solutions; but you can still find some somewhere. Don't pay more than what the product maker charges.

I'm always using all 4 of my  USB to TTL Serial Cables on some board or another. They are an essential debug tool.

 

 

 

 

Edited June 14, 2022 by zygot

[Pasqualino31]

Thanks for the reply.  If you refer to my schematic you'll see that I have my FT2232 Mini-mod wired up correctly.  What I failed to show is the no PMOD connections.

 

I have completely bypassed the CMOD on-board UART and am using a tried and true UART design.  I have verified the FT2232H Mini-Mod with an Arty project, so I know this can be done.

I am with your four (4) points 100% when it comes to the UART problems from the FPGA boards.  I am aware that the USB Conn shell on the CMOD board is isolated from ground as is the shielding and the conn's on the USB cables themselves.  That's what made the fake that the shield for the FT2232 USB is attached to its connector shells AND the board mounted USB connector shell on the Mini-Mod board.  I was astonished!!!  It was the last thing I expected.  Using this with a desktop computer is out of the question since the mobo's USB conn are Earth grounded.  Laptops (not an I have owned) do not have their USB conn Earth grounded.  The Laptop I'm using now got me around this grounding issue.

 

In my case the FT2232H is configuring in windows as two serial ports.  I am using a laptob for this and am running a TerTerm dumb terminal configured at the 115,200 baud typical of this type of project.  I have a desktop with my Xilinx tools and this is how I'm programming the board (I have programmed the Flash and am able to program the FPGA.  I DO NOT use the CMOD USB port for the UART.  I have assigned unused general purpose CMOS3.3V std I/O pins for my UART Tx and Rx serial lines and I have the HW flow control signals all hooked up.  In fact, I suspect that the flow control IS what's causing this to fail. Like I said, I've checked this out before, but didn't use the HW flow control sigs.  Right now I have the DSR & DTR grounded.  They're of no use.  The reset#, RTS & CTS may need pull-ups, so I'm about to try that.

I have no choice in using an alternative.  This part was chosen so that a higher speed FIFO can be used as well.  It is on the board right now and I HAVE to make this work and there is NO reason why I shouldn't be able to make this happen.  It has to happen, there is NO alternative.  The FT2232H Mini-mod is there for a two (2) reasons and one of them (supposedly the easier of the two as I have made my share of systems that use RS232/422 over the last 25 years.)

 

I can worry about the High Speed async FIFO part of the FT2232H later, but right now I MUST get this UART to work.

 

I included images for the remaining UART sigs so you can see that they are not on the pre-wired ports to the on-board FT2232.  I also posted a screenie of my Windows Device Manager.  I have the ports configured to my baud rate o the FPGA and I configured the Tera Term dumb terminal emulator to these settings.  If I pull the USB from the mini mod board the virtual COM ports 3 & 4 go away.

 

This should work.  If I can Tx some chars from my Arty board I can at least confirm the configuration of the FT2232 Mini-Mod.  From there I'll have to try the CMOD design and probe the UART signals with an ILA and check the board sigs with an O'scope.    I'm praying this is not an FT2232 config thing.

 

Thanks,

 

-Patrick

 

So I ported this design to an Arty Board and will try things from there.

 

[Pasqualino31]

BTW:  Regarding the portion of my post that you quoted.  The CMOD-A7 can NOT use its on-board FT2232H as a full duplex UART.  Idid a poor job separating my actual  issue from the conclusion of not being able to use the Arty or the CMOD app board's FT2232H parts because I know the USB bridge used for JTAG and other things other things.  The config and actual wiring is proprietary.

My issue is with getting a completely separate FT2232H working, which I am certain it can.  It's just not working at the moment because of something I'm doing wrong.  

[zygot]

I have two of the original CMOD A7-35T boards and have used the onboard FT2232H UART as a full-duplex 921600 COM using the VCP driver and Putty. I don't know why you have been unable to do so. When I use the CMODs I rarely use the enumerated UART though because, for me they don't work with Vivado Hardware Manager running due to detachment issues. Digilent has added a design change a few years ago due to other complaints and I haven't noticed many posts about problems for quite a while. Perhaps your CMODs are older? Digilent has always maintained that customer issues with the CMOD USB issues are due to "bad cables". This doesn't jibe with my experience and vast store of USB 2.0 cables. Also, I've never had an issue configuring the FPGA on a CMOD. Anyway, when I do use the CMODs I always have 2 spare pins for a TTL USB UART cable or breakout board to provide connectivity to a PC.

I've used the FT2232H mini-module UARTs as a COM or TTY device at 921600 baud, no flow control, using the VCP driver ( Windows and Linux automatically use the VCP driver unless you go through the steps necessary to make them D2XX devices ). I've also used used the FT2232H mini-module UARTs at 12 MBaud with hardware flow control using the D2XX driver and API plus my own C software application. I am unaware of any serial Terminal application that uses D2 drivers.I suppose that I should have added a 5th point to my previous list as I sometimes forget to set Putty to "FLOW CONTROL = NONE" for standard VCP operation. Putty is a good serial Terminal application because you can find versions that work with Windows and Linux. For my experiments I use a custom PCB that connects a Terasic DE0 Nano to the mini-module and has headers to connect an RPI and the two "high speed" PMODs commonly found on Digilent Boards. I've also used the synchronous 245 FIFO interface with this setup. The CMODs do not have a robust design for such applications using it as a component, unlike the DE0 Nano. Besides the power supply design, the single DGND pin is very limiting.

I didn't see anything amiss in the schematics that you posted. Be aware that a number of FTDI bridge device pins have functionality that is tied to settings in the configuration EEPROM. FTDI has a utility to examine what these settings are. PWRSAV# is one of those and I don't use that functionality.

FTDI bridge devices with multiple channels have each enumerated by the OS that they are connected to. I've never had an issue with one enumerated device causing a problem with the other enumerated device. I have run into a lot of OS issues and use the appropriate utilities to debug OS issues. Windows Hardware Manager is generally uninformative as Microsoft 'doesn't play well with others'. The COM settings that WHM show don't necessarily have anything to do with actual application settings for the device.

921600 baud is the maximum that you can expect for a UART applicatin without flow control. If you HAVE to make your project work and are frustrated the the $10 investment in an Adafruit 'USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi' would certainly seem like a good investment. If you want a higher data rate then you are into more effort and things to work out.. and also some software work to create an application that works on your OS.

Your experience with different results when using a laptop verses standard PC is something that I've never run into... and rather bizarre. Perhaps this is a red flag that your issues involve something else? Edited June 16, 2022 by zygot

[Pasqualino31]

Hey Zygot,

Thanks for the reply.

I have to use a UART w/o SW.  It has to be all HW and I'm starting slow with the 115,200 baud just like the gazillion apps bundled with these FPGA app boards use, just to get it going.  For now I have the HW Flow control disabled for the same reasons, I just want it to work in any way, so simple is better.

The CMODs are pretty new CMOD-A7 35Ts (6 of them to make 6 boards).  I have to design this project 100% in VHDL, no Xilinx or 3rd party IPs, (needs to be portable) and  no embedded cores.  

I am not married to the idea of using TeraTerm, it's just a simple dumb terminal emulator that needs minimal configuration for ser port.  I actually have Putty installed for some embedded projects, but this UART is so damned simple that it's embarrassing me at this point that I have no COMs.

As for the USB Bridge drivers, I did a clean Win10 install on both the laptop and desktop this month and they automatically loaded the drivers, so they are most likely the VCP drivers.  I haven't tried this project on Linux for this project or for any UART for that matter.  I've used my Linux machine for PCIe and ethernet with an AC701 board, but not for a (what I pitched to be and expected to be) a simple UART.

I just need to sit down and calmly walk through this.  The deadline for this phase is approaching and I'm starting to second guess myself and am getting a bit discombobulated. 

With the Mini-Mod, there is no reason for this not to work, it's just too simple.  Using the on-board  FT2232H on the CMOD as a full duplex modem is another story.  I could only get that to fly in one direction, same thing for the ARTY.   I am surprised, no, very surprised that you got a full-duplex 921600 COM going using the onboard FT2232H.  That part is used for FPGA config and some other proprietary stuff (I think the SRAM has something hard wired to it.)   Either way, I gave up on that, I couldn't find anyone else who could get it to go, you are the first.

The different results from Laptop vs PC is that damned USB cable for the Mini-Mod.  I included a pic showing the USB cable conn shells tied to the shields and Mini-Mod GND.  It's not an issue when using the laptop for Mini-Mod and my Desktop for the FPGA boards.  No trouble with the laptop seeing the FT2232 and doing the PnP config thing as shown in the pics above.  I did clip my ground wire from the Mini-Mod to the IDC pins of the ribbon cable conn since there's no reason to connect the Laptop GND to the App Board Gnd. 

The attached pics show a continuity check verifying the shields to the USB cable for the Mini-Mod connected to the conn shells and the second pic verifying GND of Mini-Mod to shield connection. Never tie two chassis together unless you're trying to make a GND loop.  Make no mistake.  This is by design because the shell of the Mini-Mod is on the GND plane!  I never expected this.  It's a real problem with the PC because the MoBo USB connectors are tied to Earth ground.    

I really do appreciate the detailed replies, They're not just informative, they're therapeutic.  I'm working remotely from a lab I built in an old bedroom of my family home on Long Island during the COVID shutdown.  Moved out of here in 1981 when I joined the Navy and came back because I wanted my mommy, lol.  Since then all my brothers and sisters took the opportunity and moved away.  My youngest brother is still around, but he took the opportunity to work outside the home for the first time in a long while.  So it's me an a 97 yr-old woman who needs very little care and is not very demanding (except for her 3PM hamburger on Thursdays, medium rare and purchased from a particular local butcher) , but not at all useful to wax electronics.  The solitude can be maddening.  So I truly, from the bottom of my heart, appreciate the discussion.  I threw a pic of the "Poor Man's Lab".  I found the analog O'scope in the attic, it was a Xmas present from my father in 1979.  There's a cheap-O digi from Sigilent in the back.  I was thinking eyeing that Digilent Analog Discovery 2 since there's a $200 off deal if you buy an FPGA app board for > $100

 

 

Edited June 26, 2022 by Pasqualino31
TMI

[zygot]

You piqued my interest with your issues with the FT2232H_Mini_Module, since I've used this one and its siblings on many an occasion, so I looked at the schematic. Sure 'nuff, it shows a 0 ohm resistor connecting the USB shield (shell) to DGND. This is not good; but simple to correct. Depopulate R8. Shield grounds are intended to absorb transient energy sources, like ESD, [ and keep it from affecting ] the electronics and dissipate that energy to earth ground. Normally, this is chassis ground and isolated from any power supply ground.. or it can't server its purpose.

Every FPGA board that I've used ( and that is a very high number as I use FPGA development boards as prototyping platforms or even system components for one-off designs ) , has either an FTDI or Silicon Labs USB-UART bridge device serving as a serial interface port. I've never been unable to use any of these in full-duple mode. Somehow your world and mine don't appear to be connected. The Silicon Devices CY21xx devices don't use a startup configuration EEPROM like the FTDI. I believe that for no flow control they require the CTSn input to be low. Such devices from both vendors support hardware, XON/XOFF and no flow control, but use cases with FPGAs might be different. The FTDI FTxxxxH devices support 8 and 12 Mbaud rates. The other FTDI and Silicon Devices UART bridges support up to 2-3 Mbaud depending on the IO voltage.

See this post: https://forum.digilent.com/topic/2866-cmod-a7-35t-demo-project/

This is a CMOD A7-35T doing full-duplex using the on-board FT2232H bridge. Check it out. It's a 100% VHDL project ( though I've encapsulated part of it into a netlist because I didn't want to post the source code ). No Xilinx or 3rd party IP. I don't count the Xilinx clocking Wizard as IP. You can instantiate it as a macro, but the Wizard helps keep you from jitter issues. Except for FIFO and BRAM Wizards all of my projects are HDL code that I write myself. It's amazing what you can do just using VHDL or Verilog and no processor.

Again, the Adafruit TTL-USB Cable doesn't support hardware flow control and only uses Txd, RxD and DGND connections to implement a UART. The only issue with them is that I keep forgetting which color wire is which signal... but I've taken to adding comments to my code to help. Personally, my time is more valuable than the price of the cable.. and using it truly is straight-forward. With the FTDI modules you have to read schematics, understand drivers and their issues, know what the configuration EEPROM contents are and slog through not particularly high quality datasheets and design notes. ugh! If you need a (up to ) 40 MB/s PC-FPGA connection and are willing to write your own application, plus go though the exercise of changing the EEPROM contents this might be worthwhile. Rarely does a 921600 baud UART NOT get the job done. If I really need high speed I'll use an FPGA platform with a PCIe connector. But, it certainly shouldn't be an arduous journey to get your FT2232H Mini-Module doing 921600 full-duplex when connected to 2 FPGA GPIO pins and a good DGND reference.

I salute you for your service ( to both country and mother ). A salute to your home grown lab too. Edited June 18, 2022 by zygot

[Pasqualino31]

There is no 0-ohm resistor to shield.    The USB shield of the Mini-Mod is connected to GND of the Mini-Mod board by the Mfr (FTD).  The only thing I was able to do about that was to use a laptop PC for my USB Bridge Host.  When I use my desktop PC that pulls everything down to Earth GND and I can't have that.

Using a  laptop PC for my USB Bridge Host solves the ground problem.    I use my PC for the CMOD-A7-35T.   The grounded shield is no longer an issue, it is what it is.

**************

[edit]   I appreciate the link, but I've dealt with that project in the beginning.  It was the "last straw" for many reasons.  For starters, I had a hell of a time building it.  I had to open the DCP as its own project export the DCP as a Verilog netlist and then add the generated Verilog netlist files into the project and deleted the original DCP from the project. after trying a few other things out.  I couldn't get the Python script to run in Win10, but I tried.  Ultimately it just hammered home the point that using the on-board FT2232 was just not worth it due to all the proprietary nonsense.   The FT2232H is not capapble of handling all of this functionality, so you can't use the JTAG interface.   It was a particularly bloated UART, too and needed assistance with that Python script.  The contract requirements for this project were very specific about  no IP or Black Box modules and especially no software,  The system tests a digital power-down sequencer that deals with a very high power system.  The group is unhappy enough with having to support an FPGA.  The engineers are  electrical power guys as are their technicians.  The documentation reads like a beginners course in Xilinx/Vivado/VHDL.  Probably over 1./3 of my VHDL files are comments and verbose headers explaining the functionality in excruciating detail.  Then there's a design Document and a User's Manual.  They want no SW and no voodoo.  A lot of FAA and Government work is like that.  SW adds a whole new set of reliability work to certify and they don't like black boxes.  This is particularly true of the FAA.  

********

[end edit]

I built a project on Friday with an ILA to monitor all those lines and am making changes to my VHDL code now.  On Friday managed to get the system to "hiccup" the welcome message I have stored in ROM (BRAM) on the FPGA.  It is supposed to wait to send it, but It's triggering early for some reason.

A few changes had to be made:  The ILA needs at least a 20MHz clock.  If the frequency is lower, the ILA core will not be created.  No problem there, I doubled the system clock frequency and with the Generic parameters I have in place it should have adjusted the baud rate to match.  I'm about to run a simulation now because other things in the system are affected by the sys clock change.  It shouldn't be much work.

I'm using HW Ctl Flow, and Fridays build shows that the FT2232H pulls the RTS# line low at Rst# going low.  (I use a single cycle wide neg pulse from the FPGA which is much slower then the clock on the Mini-Mod which is 125MHz I believe.)  When that rst# pulse hits the Mini-Mod it brings the RTS# line down for about 1.25 us and it goes high again.  I'm not sure what the HW startup sequence goes, but I believe I'll monitor that line and wait for it to go high before sending a CTS# and then waiting for the Mini-Mod to pull the RTS# line down again.  Then I'll start sending my welcome message.  At the end of the welcome message I wait for the user to hit "Any Key" to continue and then send the "Main Menu" which will ask the user to hit a number from 0 to 6 to run a particular test.  Another message sometimes needs to be sent for certain tests.  There's an option on every message to hit the space bar to return to the main menu.  The Welcome Message is only at startup.

On Friday i got it to the point where i started with a blank screen since the welcome message was already sent.  I hit the "CR" key and got garbled txt in return.

So I'm close here.

I have a very good test bench for this system and once this UART problem is solved I'll be all but done with this.  When this project is complete, this proto board will make one hell of an Artix-7 project board.  I've got SPI,I2c, 1533, bi-directional  BUS-Switches opto-isolator loopbacks and lots of other things and no SW required. I was able to expand the I/O of the CMOD by tri-stating some outputs (12) and connecting them to bi-di bus switches.  I also have 12-bits of I/P on a 2:1, 12-bit Bus Mux, 16 bits of DIP SWs, a bank of 16 LED's and another bank of 12.  There's also a few random LED's and the 3 LEDs for the Mini-mod.

Edited June 27, 2022 by Pasqualino31

[zygot]

21 hours ago, Pasqualino31 said:

 

20 hours ago, Pasqualino31 said:

 

 

 

 I appreciate the link, but I've dealt with that project in the beginning.  It was the "last straw" for many reasons.  For starters, I had a hell of a time building it.  I had to open the DCP as its own project export the DCP as a Verilog netlist and then add the generated Verilog netlist files into the project and deleted the original DCP from the project. after trying a few other things out.  I couldn't get the Python script to run in Win10, but I tried. 

 

 

 

What version of Vivado are you using? Since I posted the original project Xilinx has changed many things that break even PLL/MMCM IP. It's fairly easy to re-create that IP from looking at the source code. I haven't had problems adding dcp netlists created in earlier tool versions into projects compiled with later tool versions. I frequently check posts to projects that I've put in the Digilent Forums and will reply to anyone needing assistance. As for the PYTHON script, Python 2 has been depreciated, so yes that code is obsolete ( unless you install Python 27 on your PC and follow the notes). Having Python 2 and Python 3 on Linux hosts can be problematic without some prep.

[edir] BTW, my demo project doesn't require that the PC user use the Python script. The design contains a component that allows the PC user to interact with the FPGA design hardware using ascii text. So you can dispense with the Python script and just use Putty or a serial terminal application. The Pyhon script just makes interacting with the hardware easier. The project notes cover this.

 

 

 

 

 

21 hours ago, Pasqualino31 said:

 

20 hours ago, Pasqualino31 said:

 

 

 

Ultimately it just hammered home the point that using the on-board FT2232 was just not worth it due to all the proprietary nonsense. 

 

 

 

The reason that I keep responding to your posts on this thread is that ther is no 'proprietary nonsense' affecting the UART connectivity on Digilent boards. FTDI UART Bridge devices support full-duplex operation as to Silicon Devices UART Bridge devices. Nothing about Digilent's hardware can change that. A good HDL UART certainly can do full duplex operation. What's left is OS issues, and design implementation issues.

 

 

 

 

 

21 hours ago, Pasqualino31 said:

 

20 hours ago, Pasqualino31 said:

 

 

 

The contract requirements for this project were very specific about  no IP or Black Box modules and especially no software,  The system tests a digital power-down sequencer that deals with a very high power system.  The group is unhappy enough with having to support an FPGA. 

 

 

 

This is where you are confusing me. You can't use a USB UART without software controlling the upstream USB Root HUB. If the hardware that your design needs to connect to doesn't use a processor and therefore just digital IO then you just need to know how to connect the signals in a compatible manner. I only pointed to my project as proof that you problems have nothing to do with Digilent's board designs. You can certainly prove that your HDL UART works by connecting it in a loopback fashion or to a second FPGA board. USB UARTs are not UARTs, they are USB devices. In the project that I posted, there is no software in the FPGA design. The only IP is the MMCM Wizard and that can easily be replaced with an HDL macro. The only software in the project is for the device connecting to the FPGA design, which in this case, happens to be a PC running Windows or Linux.



I recommend that most designers start off using the Vivado MMCM or PLL Wizard to avoid jitter issues as the tool takes that into consideration. Once the design is functioning properly you can always replace the Vivado IP with an HDL macro using the same settings. The macro allows you to select clocking options that might have a negative impact on your design.

 

 

 

 

 

21 hours ago, Pasqualino31 said:

 

20 hours ago, Pasqualino31 said:

 

 

 

A few changes had to be made:  The ILA needs at least a 20MHz clock.  If the frequency is lower, the ILA core will not be created.  No problem there, I doubled the system clock frequency and with the Generic parameters I have in place it should have adjusted the baud rate to match. 

 

 

 

Sounds like you are using the CMOD USB 12 Mhz as your global clock for your project. To get your project going, you can use an MMCM or PLL to make that any clock. If you are using a 12 Mhz clock for your UART logic that could be a problem for matching baud rates. A good HDL UART will be able to accommodate a good 15% baud period mismatch between DTE and DCE ends. There can be a lot of confusion about what a UART needs to do now that RS-232 is mostly obsolete and USB is how UARTs are connected in modern PCs. If you UART only operates a 9600 baud then clocking your logic at 12 MHz might be OK.



Simulation is necessary and good, but only as good as your testbench. Effective testbench writing is no easy, especially when external hardware needs to simulated.



My sense is that you are missing something very basic. I've done many designs similar to yours, and with similar requirements. I typically have no IP in my design 'deliverables' unless DDR is involved. I don't use soft processors for hardware design. I think that I understand your design constraints. I do frequently prototype a design using elements that won;t be in the final version, if that speed up development time. At some point in development all of my HDL designs use a USB UART and I've never had USB UART connectivity  issues on many platforms from quite a few vendors.



The CMOD is not a robust product for the type of project that you are doing for many reasons; 'proprietary nonsense.' has nothing to do with it. Implementing a UART interface in programmable logic using and HDL should be straight-forward unless there is some confusion about the basics.

[edit] Debugging UART interfaces that have a USB UART connection can be problematic. Since recent PCs don't have RS-232 or even serial ports you are limited to USB UART connections. Problems caused by OS drivers and application ( e.g. Vivado Hardware Manager ) quirks, can sometimes be avoided by using a separate PC for the design USB UART connection as for the configuration/debuggiing UART connection. This is especially true for Quartus designs as Windows frequently gets FTDI UART bridge devices confused. That's one reason why I like the Adafruit TTL USB UART cable as a debug interface. I can separate tool OS issues from OS driver issues. I heavily use a UART as a debug interface as it often can be more useful than the tool debugging resources.

 

 

Edited June 27, 2022 by zygot

[zygot]

I just downloaded the archive posted here: https://forum.digilent.com/topic/2866-cmod-a7-35t-demo-project/ onto my Centos 7 PC and created a bitstream using the free version of Vivado 2020.2. The only thing that I had to do was create a VIvado 2020.2 version of the clk_wiz_0 component instead of adding the CmodA735tDemo.xdc file to my project. The toplevel file has commentary to let you do this easily. I didn't encounter any issues. Just make sure that CmodA735T_Demo.vhd is set as the toplevel entity in your project. If you don't have Python 27 installed on your PC you can use Putty or whatever your favorite serial terminal application is, as long as it does 921600 baud. The README.txt file is reasonably informative about using the demo. Edited June 27, 2022 by zygot

[Pasqualino31]

I had no problem building it, just took a little work.  You have a file that I'm missing, so I had to export the DCP because I go a "missing file" warning, but I was still successful building it.  the Python script did not work.  I'll mess with all that another day.  It's definitely not what I need here, but it will give me something to work with in the future.  This UART is strictly a dumb terminal thing.  I do need the RTS/CTS HW control flow though.  

[zygot]

I configured my CMOD-A35T from Vivado Hardware Manager on Centos using the bitstream that I just built. I used Putty to read the Artix XDAC temperature sensor using the Python script as a guide. I didn't have any problems. Everything works; it's just a lot easier using a script.

I added the dcp file as a source file in Vivado.

My demo isn't meant to be used as a source for your project... just as proof that the CMOD-A35T UART does work. The demo doesn't use flow control because it's not required. If one wanted to send large amounts of data via a serial interface then it would be. How difficult this would be to implement depends on what your FPGA UART is connected to.

BTW, I always make sure that VIvado Hardware Manager isn't running while using the CMOD UART. For me this eliminates the OS from detaching the CMOD FT2232H endpoints. Usually I just use a TTL USB UART cable because it uses a Silicon Labs USB Bridge and that eliminates a lot of OS and application problems.

[Pasqualino31]

Well, the initial surprise of having the CMOD run a UART, full-duplex and at a pretty fair clip, it is no surprise that you can not access the JTAG chain because the FT2232 is not capable of any further functionality.  I have an Ubuntu install I can try this out on, but it won't fly in windows without some changes to the Python script and, like I said, I'm no a SW guy, so my knowledge of anything beyond ANSI C rolls off quickly.  I know enough TCL Python and C++ to get by for integration, but the only code I am proficient with is VHDL and SV which might be code, but it's not SW..

[zygot]

1 hour ago, Pasqualino31 said:

it is no surprise that you can not access the JTAG chain because the FT2232 is not capable of any further functionality

You are incorrect with this assumption. The FT2232H gets enumerated with 2 separate USB endpoints; one for JTAG and one for the UART. Both endpoints can operate 'simultaneously' ( that is they can both be enumerated and used by the same or different software applications at the same time ), The Digilent CMOD-A7-35T is the only FPGA board using an FTDI bridge for JTAG and UART endpoints that I've come across that seems to have issues. Every other such FPGA board that I've used doesn't exhibit this problem. Not everyone has reported the same experience. Digilent isn't the only company to use FTDI USB bridge devices this way.

 

1 hour ago, Pasqualino31 said:

I'm no a SW guy, so my knowledge of anything beyond ANSI C rolls off quickly

You don't have to know Python to figure out how to use the script that I've provided to interact with the demo hardware. It really helps if you read the /Doc/README.txt file in the demo archive. You cna use Putty on Ubuntu or Windows following the README commentary and glancing through the C7Test.py script. FOr instance, to read the XADC substrate sensor temperature:

From C7Test.py:

• xadc_read_reg             = '0'
  xadc_write_reg            = '1'

•  
  # Display FPGA core temperature in Celsius degrees
  def get_xadc_temp():
    TestData = 'W ' + xadc_write_reg + ' 0' + ' \x0D\x0A'
    ser.write(TestData)
    time.sleep(.2)              # delay
    TestData = 'R ' + xadc_read_reg + ' \x0D\x0A'
    ser.write(TestData)
    ResponseData = ser.read(regrd_length)
    n = int(ResponseData[4:regrd_last_data_digit], 16)
    t = float(n)*2015.0/(16.0*16384.0) - 273.0
    print 'FPGA Core Temperature = ', t   

In your serial terminal program this is what you type:

• W 1 0
• R 0

As the README.txt file mentions, there is a space between the W, 1, and 0 and every command line ends with the Enter key. After sending the command to read the xadc_read_reg (Reg0) the HDL will display the register and the std_logic_vector value of that register at the time the read command was received.

To read any of the HDL registers just type: R x   , where x is replaced by the register number.

What you consider to be a 'bloated UART' is much more than a UART in terms of functionality. It provides a way to use a PC serial terminal application to read and write HDL registers of any length in your configured FPGA device as it operates. Most importantly, the values written or read are in the correct bit order as the logic sees them; regardless of the endianess of the CPU on your PC. That's a pretty handy bit of 'IP' to have around for many purposes.

The reason why I posted this project was to provide an alternative to Digilent's typical MicroBlaze based demos. Now those are bloated. Moreover the sources in this project can be used with any version of Vivado that has been released since 2016.2, which was the version that it was created on, to create a bitstream . I'm pretty sure that Digilent can't point to a single one of it's demo projects that can make such a claim. I guess that Digilent's management would rather have their engineers spend their time modifying old project code to work with new tool releases than do work that creates income... not my problem; showing a horse where the water is and making it drink are two different challenges.

Edited June 29, 2022 by zygot

[zygot]

"I have an Ubuntu install I can try this out on, but it won't fly in windows without some changes to the Python script"

The reason why I use Python is that the same script can be used on either a Linux or Windows host. the only difference is that Windows has COM ports and Linu has TTY ports for UART connectivity. GUI applications are another matter. I developed the project code on Windows and have built it and run it on both Windows and various Linux distributions.

[Pasqualino31]

On 6/27/2022 at 11:51 AM, zygot said:

My sense is that you are missing something very basic.

um... yeah, definitely.

Your project is a great resource for me since I'm light on Python scripts and even lighter on these apps other than TeraTerm.  So I really appreciate your input, but I could really due without the sarcastic  "horse to water" crap, and other snarky sht, so cut it out.  I'm grateful for any input and yours will be particularly useful to me when I'm less busy. I'm not so bad at Python, but I separate any  py scripts: 2.7 in Unix type O/S and Py 3.1 on windows.  I really don't want to pick apart scripts and decode them with your "readme" docs.  That's a project onto itself.  I do appreciate the material though.

S-I-M-P-L-E is what I wanted and that's what I made for my customer.  Do you have customers?  This is a test system designed to work with minimal overhead.  Python scripts and other apps which requires setup beyond the scope of the average Union Electronic technician means I have to write a detailed instruction document.  Don't you dare tell me that the setup is simple enough to satisfy this requirement, so stop your f'n BS about how "easy" this project is to setup.  It doesn't work on a free-standing CMOD-A7 out-of-box, so it's no simple enough for my project of which you know next to nothing beyond the mistakes in my schematic you created in your mind to fit you narrative.  It's good work, but it's not a one-size-fits-all solution to anything but the app board you created it for,

I got the UART to work.  The /mini-Mod takes way longer than I imagined to come out of reset.  On top of that, the Vivado ILA wouldn't work with my system clock and that took a while to debug and then redesign with a different sys_clk.  Once I got the ILA up and running it was a walk in the park.  So quit wishing for my failure, it isn't going to happen.  The debug time it took to bring this up was short and I took a week off since this discussion started

Let me remind you that you are very fast to criticize and find errors that didn't exist (zero-ohm res to shield?  WTF???, what were you looking at?) On top of that, you are very presumptuous.  Who TF are you to say how much FPGA resource or whether a particular part or mod board is sufficient for my needs? I am the owner of an SCORP and this is a Purchase Order (PO) contract.  That means that I had to sell a cheap solution, so you have no frame of reference here, having not read the Contract Requirements.

I'm sure you're proud of your project, and it seems to be a useful resource.  I'm sure you're proud of it and you should be.  However, the fact that the CMOD does not behave like other app boards that use the FT2232H (Like my AC701 board.) is a pure non-sequitur, I'm using the CMOD-A7 and it's working with the Mini-Mod at this point... so there.  If you like, I'll make a build just for you that doesn't use the USB port of the CMOD for COMM's for any target board you want. 

No scripts needed, just a TeraTerm.

 

Edited July 4, 2022 by Pasqualino31

[zygot]

On 6/27/2022 at 4:23 PM, zygot said:

My demo isn't meant to be used as a source for your project... just as proof that the CMOD-A35T UART does work.

I'm not particularly proud of this demo. It was just a simple project with a few specific goals to achieve. It does, despite what you want to believe, work as a reasonable demo for the CMOD-A7-35T, out of the box, using current tools and minimal effort, and accomplishes the goals that I had for the project. If anyone wanting to try it out bothers to read the short documentation text file I expect that what's presented is potentially useful for them. No one posts demo projects with code for the purpose of being incorporated into someone else's project.

I really don't care about what happens with your project and have no interest in helping you complete it. I don't feel any compunction to defend any product vendor. I do feel compelled to make  an attempt at addressing statements that are posted to the forum that are just plain incorrect. Generally, I'm more concerned about the casual reader of posts who might be steered in the wrong direction by blatantly false conjectures than I am about correcting the person who wrote the post. 

Sometimes, trying to help, whether the effort is useful or not, is met with gratitude; sometimes with hostility and contempt. That is, unfortunately, life.

It is frustrating to have people excoriate and complain bitterly about statements and intent attributed to you that are not your statements or intent, or, more than often, the opposite of what you've posted or intended.  It's particularly sad to read your last post on this particular day.

These are indeed dangerous times.

Edited July 4, 2022 by zygot