board to board (ZC706 to ZC706) communication

[Niranjan]

Hello sir,

I want to do board to board (ZC706 to Zc706 FPGA) communication through PMOD USBUART board. I have read some stuff available on internet but not getting exact method how to do the same. will you please help me?

1. Can i do communication? If yes, can you please share some code or material related to that so that it will help me.

Thanks.

Niranjan Nimgaonkar

[jpeyron]

Hi @Niranjan,

You should be able to use 2  Pmod USBUART as  communication between two ZC706 . You would use the Pmod Ports along with something like a micro usb to micro usb . In the block design use the Uartlite IP Core  or the second UART in the ZYNQ processor and make that UART bus external. You will need to constrain the UART pins in the wrapper in an xdc file.  After you generate a bitstream and launch SDK here is a polled SDK example that should be a good reference. 

thank you,

Jon

[zygot]

@jpeyron

Use 2 Pmod USBYART modules to interface two FPGA boards?

Am I missing something here?  If you want to connect a PC to your FPGA board these might be fine (  your PC has a USB Controller chip) These PMODs use the FT232R which is a downstream USB device. Connecting two downstream devices through a USB cable is not a good idea.

Other thoughts:

Make sure that your FPGA PMOD supports 3.3V logic standards ( I haven't checked for the ZC706 board ).

If you want to connect two FPGA boards using a UART-like interface why not just use 3 wires ?

( TxAout --> RxBin, TxBout --> RxAin, GND )

You can probably do this using flying wires ( 6" or less ) and have almost any baud rate you desire.

If your boards are farther apart or you want to avoid interference issues you moght try to find a few cheap TTL-RS485 level converter modules.

Check out my Differential PMOD Challenge  in the Project Vault for some ideas.

To All: USB is NOT a peer-peer interface.

[Edit] I should have mentioned that since you are using the PMODs you will also be using the PL. I haven't looked for your device but it may be possible to route the ARM UART though the PL and not have to do any UART HDL design work. By far the quickest and easiest ( for me ) is to implement UARTs in the PL and just wire up the interface. Digilent makes PMOD cables to make the setup more mechanically stable.

[jpeyron]

Hi @Niranjan,

I agree with @zygot that there is better ways to accomplish communication between the two boards. 

1) Can you be more specific on your project needs and limitations.  

               a) What data rate are you looking to do between the two boards.

                b) What other peripherals are you using

thank you,

Jon

[zygot]

Just to be clear... what I'm saying is that connecting two USBUART PMODs together with a USB cable is a really BAD, BAD idea!

[Niranjan]

Hello all,

Some data will be generated in PS of one Board and it has to be transferred to PS as well as Pl of other board. It will be approx. of 10 to 20 bytes. Since the ethernet interface we are already using in this for other data transfer, i need to have some other method (like uart). 

[zygot]

@Niranjan

Well you say how large a chunk of data is but not how often you want to transfer a chunk of data. Assuming that your idea of a UART will suffice in performance I can only say what I'd do. The simplest approach involving the least effort would be to route an unused PS UART through the PL on both boards and connect the TX, RX lines using a PMOD cable. You might be able to use the control signals as well though I doubt that this is necessary. This approach requires no HDL whatsoever.

You will have to make the proper constraints assignments and provide for the new PL GPIO in the board design schematic.

As to how you do that... that's part of your workload...

There's also the CAN interface though you might have to provide your own PHY (check your board to see if it's already there). I know of at least one regular post submitter who would go that route.

Pretend that you're hearing this in the voice of Sir Alec: "Use the can Luke! Use the can!" He'd probably be saying "Use the Loo" but we'd know what he means. If you want advice on using CAN post a question here and you'll likely get a reply form that particular contributor.

[Niranjan]

Hello @zygot,

I have done the same thing i.e routing uart0 of zynq PS through pmod pins (tx,rx,and gnd).

Transmitter system :- 

I am using zc706 boards and want to do communication between them using uart0 of zynq PS. As shown in snapshot, i have taken tx and rx pin of uart0 of system 1 and assigned it to pmod pins (aj21 and ak21) . I ran the simple code of hello world. Instead of hello world i send the characters "ABC" and observed the output of tx pin on ILA as well as osciloscope. It is correct. I have attached snapshot to this post. 

 

Receiver system :-

In the same i made design for receiver system just cross connected wires tx to rx and rx to tx and assigned pmod pins on board 2. But i am not getting any output on those pmod pin(rx). While running programme on receiver system, I triggered ILA for rx pin i.e whenever it receives any data on rx pin , ila wil get triggered and we wil see the output. But ILA is not at all triggered. 

 

ILA clock- 50 MHz (fclok_out0) form zynq ps.

1. what must be the issue?

 

[zygot]

@Niranjan

It seems that you spent the time to figure this out ( I failed to mention that you needed to swap pin assignments for the two boards if you use a straight cable... ).

When things don't produce the expected results the first thing that I do is check the post bit generation pin report to confirm that all of the new pin assignments are indeed correct**. I'm not completely understanding your terminology.... a UART is a full duplex interface and you seem to use transmitter and receiver as references to the boards in your system... but if you're seeing the Tx data on one board's PMOD pin then you likely have the PS pin mux set up correctly. I always use the devide and conquer approach to debugging, I'd try to confirm that one board can talk to a known good UART or itself as a first step.

I always convert the board diagram into HDL and use a wrapper to instantiate that into my toplevel design source code so you might have to verify that the Uart GPIO direction assignments are correct.

I don't see any glaring issue with what you've already done from reading your last post.

** It's a good habit to check the pin report every time you assign IO pins new functionality.

[Niranjan]

hello @zygot,

I have checked everything in my code. Everything is correct. But i am not getting output on rx pin. What should i do now? 

How can i debug the code from now?

 

[zygot]

11 hours ago, Niranjan said:

Everything is correct

Welcome to debugging, where things get interesting and your work grades your design effort. Hopefully, you don't have too much confidence in any such assertions like the one above.

I find myself in your position more often than I'd like to admit. Sometimes it turns out to be something completely unexpected... usually it ends with a slap on the forehead and DOH! You idiot!... Fortunately, we're working in the PL so there are options, Hopefully you have a few spare IO pins. Just as a sanity check I'd bring out the TxD and RxD internal signals to new GPIO that I'd name dbg_xxx. These can be observed wiht a scope or since I always have a few TTL USB UART cables or modules lying around try to loop back communication to a second COM port in my PC. I'd certainly try getting the PC to talk to one of your boards directly through your current pin assignments.Pay careful attention to signal directionality and be sure to avoid two sources driving any pins which could be easy to do. I might use a mux in the PL controlled by a physical switch to help with that.  I never ask myself "DO I have to draw you a picture?" because usually the answer is yes... Your brain might be wired differently.

Have you verified that the current signal IO standards are correct? It might not hurt to revisit the Zynq documentation for moving PS UART pins to the PL... this isn't always totally straightforward.

[edit] Oh, and I forgot to mention that when things get really confusing I plod through all of the Synthesis and P&R messages. Sometimes Vivado and I aren't understanding each other the way that I assume we do. If I were smarter, I'd probably do this step after each bitstream production... but I want to keep moving...

[zygot]

@Niranjan,

I had some time yesterday and created a Zynq design that brings out the unused PS UART0 to pins on a PMOD via the PL. I don't have your board but I did use a Zedboard which is close enough. I just wanted to verify that my advice was usable. I used Putty and a TTL USB UART for testing.

The effort wasn't without hitches. Since my first hardware included both uarts the SDK decided to associate UART0 instead of the default UART1 as the port for stdin/stdout. It took a while to realize and fix this. My first build also had a copy/paste error that assigned UART0_TX to the wrong pin. As it's been a while since I've used the SDK it took awhile to realize that I couldn't attach UART1 to the Console like I've always done in the past. The combination of errors and tool version changes made for a lot of necessary work. Basically though, most of the pain was dealing with the SDK software. It reminded my why I'd rather do everything in HDL** rather than mess around with all of the burden and nasty surprises that come with FPGA processor development. But making use of PS interfaces that aren't used on a particular board is not all that hard, once you remember where all of the Eclipse controls are located.

** Except for once, when I installed the tool version to match a demo, I've never been able to create a workable project for board design, TCL scripted Digilent demos. Very often the IP in the demos can't be updated so they are locked and getting a bitstream is impossible... haven't figured this out yet. When I try to revive or change one of my own old project that was working when I left it a few years past I've gotten familiar with the bugs and peculiarities of more recent Vivado versions ( thankfully ISE is old but I know what I'm getting ) and I end up trying to update them into new tools. This almost always means scratching around to resolve incompatibility issues, particularly in the SDK.. and many many hours of effort that displaces time for actual design. Still, I do use those ARM-based FPGA devices when I have not other reasonable choice.

[Niranjan]

hello @zygot,

Can you please send me the some code for communication between 2 boards rather than sending data from fpga to PC and vice versa  in one system only?

[zygot]

You can get the SDK to add a few example projects for any device in the system. Open the system.mss and click on the OS (the default is the standalone but you may have chosen another one when you created your BSP). Scroll down to the uart_x that you run through the PL and click on the demonstration examples. There is a nice variety of demonstrations and you probably want to add them all. The SDK will build these for the uart you selected. This is one nice feature of the SDK. If you chose another OS, such as the RTOS I'm not sure if examples are available. You likely want to use the interrupt driven example as a basis for your design ( depending on how you designed your overall software control). Of course, there are a lot of ways to arrange your communication protocol so I hope that you've spent some time thinking about how it will work. The simpler the better. Understand that the purpose of the example code is to show you the basic requirements to implement a particular interface and not to solve your problems... that is they are there for you to pore over and understand how they work.

I can't send you code because your application is unique to you. If your SDK OS has a hardware abstraction layer then you will likely need to find other sources for example code. I rarely need (or want) a full-up OS like Linux for embedded applications.

[edit] I should have mentioned that since you have at least two FPGA boards ( and ony you know what else ) you have a system. The basic system definition and design approach should be the first thing to flesh out. This includes inter-board communication; for instance are the boards peer-peer or is there a hierarchy? You can always tweak the system design if the lower level considerations demand it once you start fleshing out the actual implementation. If you haven't given any thought to the system interactions and structure then you are in for a lot of unnecessary work as the project nears integration.

[Niranjan]

I have done so much a things but not getting output. If you know where i am going wrong please let me know , else let it be.

[zygot]

@Niranjan

Well let's start with what has gone right so far. Separate your problem(s) into less complex systems. Can both boards interact with a PC terminal program? You can use a TTL USB UART on PL pins to do this ( be sure to use the ground wire ). Inexpensive versions of these are offered by Adafruit or Sparkfun. I use Putty but the SDK will allow you to set up a terminal to connect to any COM port enumerated by your OS. Of course, you have to have a physical UART to do this. If either Tx or Rx isn't working the most likely issue is a pin location or IOSTANDARD constraint mistake.

You really haven't provided enough information about what you've done for a third party to be very helpful.