Routing additional Zynq hard block I/O to PEC_FPGA

Using Zynq Programmable Logic and Xilinx tools to create custom board configurations

Routing additional Zynq hard block I/O to PEC_FPGA

Postby 9600 » Sun May 04, 2014 11:17 am

There has been some discussion about whether the Zynq's 2nd I2C and Ethernet controllers should be routed to GPIO pins, and presumably this could also be done for the 2nd UART or SDIO, or CAN bus or SPI.

Wondering if some of these interfaces should be routed to GPIO in the default image, on the assumption that this would be useful to many, and those who wish to implement some custom interface will be building their own image anyway. If so, what would be the ideal combination given the available pins?

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby parapara » Sun May 04, 2014 12:43 pm

9600 wrote:Well, we already have HDMI and headless bitstreams, and then as well as 2nd Ethernet you could also route things such as the 2nd I2C to GPIO. And maintaining bitstreams for every different possible combination of options would be quite time consuming...

Good point, having a ready-made bitstream for each combination is a no-go.

Does verilog allow for the connection to be easily commented out, allowing users to assemble their own bitstreams?
I understand that it's hard to comment out the HDMI part, given it's complexity and usage of universal PS-PL interconnects.
But the passthrough code might be simple enough. (Newbie's assumption. Wrong?)

Hmm.. now I'm a bit unsure.. can unused PL's GPIOs be used by the PS (without bitstream changes)?
If so..
then of course I agree that blocking the GPIOs is not a good idea and
the passthrough paths would be better disabled by default.
But if not..
Then anyone wishing to use the PL GPIOs would have to assemble the bitstream anyway
I expect simple passthrough connections to take minimal resources, no harm. (Another newbie's assumption)


PS: Located what exactly is passed to the PL. No surprise there.
Zynq TRM wrote:1. When the Ethernet MII/GMII interface is routed through EMIO, other MII interfaces (e.g., RMII, RGMII, and SGMII)
can be derived using appropriate shim logic in the PL that attaches to PL pins.
parapara
 
Posts: 7
Joined: Thu May 01, 2014 8:35 pm

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby FHuettig » Mon May 05, 2014 6:27 pm

parapara wrote:Does verilog allow for the connection to be easily commented out, allowing users to assemble their own bitstreams?
I understand that it's hard to comment out the HDMI part, given it's complexity and usage of universal PS-PL interconnects.
But the passthrough code might be simple enough. (Newbie's assumption. Wrong?)

The verilog part of this is quite simple. If you look at the current top-level you'll see that there are `defines for the current options:
  • 7010 vs 7020
  • single-ended/differential GPIO
  • HDMI vs headless
  • E16 vs E64

These options are set in a version.v file in the root folder of each fpga project. Sometimes other things are required such as location constraints for the IOs that exist on 7020 but not on 7010, but it's generally simple.

Depending on which of each of those options is defined some code is included or not, or other things are defined, in order to make them all work from a single source tree. HDMI happens to be simple too because all the complicated stuff is done in XPS cores rather than in the RTL, so the top-level only has to route the signals to the right pins or for the headless version it just ties them off. Other things like a second ethernet or I2C could also be easy especially if you're OK leaving the pins with their current "GPIO" names. In those cases the XPS project has to be updated to add the interfaces you want, give those PS pins names, then a new "system" stub is created with the new IOs, and they just have to be connected at the top level. That part may sound more complicated than it is. To prove it I'll add options to the RTL (at some future time) to support the second ethernet (12 pins), I2C (2 pins), UART (2 pins), SPI (6 pins), CAN (2 pins), and timers (2 pins each) in any combination. It would be nice if there were a correspondingly simple way to add these things to the XPS Project, maybe there is and I just don't know it. The XPS GUI modifies a couple of files (mhs and xml) to instantiate these things. Once things are changed in the RTL then the devicetree always needs to be updated so the right drivers are loaded and everyone knows the correct addresses.

I also think it's reasonable to branch one more set of projects so users have the option of using a bitstream with 48 (or 24 for the 7010) GPIOs OR one with -all- the available peripherals and whatever GPIOs remain. If other combinations are needed they can be created. For the 7020 boards this new configuration will support all the peripherals named above, for the 7010 I need to save 4 pins, so I'm thinking to cut out the second timer and the CAN bus. Anyone have a preference?

As to -when- I will do this... not immediately. Give me a week and check back.

parapara wrote:Hmm.. now I'm a bit unsure.. can unused PL's GPIOs be used by the PS (without bitstream changes)?


Not without bitstream changes, anything that goes through the PL has to be defined in the bitstream. However, things can be connected in the bitstream and simply not used if they are not needed. Conceivably (no promises here!) one could even use extra GPIO signals to define which peripherals were connected to GPIO pins and which weren't, leaving the unused pins as ordinary GPIOs. This is essentially what happens on the MIO pins, where the FSBL defines what peripherals come out on which MIO pins when the device boots, except in this case things could be changed under software control. In my far-off vision every add-on card has an I2C-accessible ROM on two predetermined pins, and software can read what card is connected, route the needed interfaces, and go from there...

parapara wrote:I expect simple passthrough connections to take minimal resources, no harm. (Another newbie's assumption)


That's correct.

-Fred
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby 9600 » Mon May 05, 2014 8:38 pm

FHuettig wrote:To prove it I'll add options to the RTL (at some future time) to support the second ethernet (12 pins), I2C (2 pins), UART (2 pins), SPI (6 pins), CAN (2 pins), and timers (2 pins each) in any combination.


Ah, very cool and many thanks, Fred!

I also think it's reasonable to branch one more set of projects so users have the option of using a bitstream with 48 (or 24 for the 7010) GPIOs OR one with -all- the available peripherals and whatever GPIOs remain. If other combinations are needed they can be created. For the 7020 boards this new configuration will support all the peripherals named above, for the 7010 I need to save 4 pins, so I'm thinking to cut out the second timer and the CAN bus. Anyone have a preference?


That would be great and would seem like a good approach for the 7010 — I expect that those with a need for a 2nd CAN bus are going to be more likely to know how to go about generating their own bitstream.

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby FHuettig » Mon May 05, 2014 9:05 pm

9600 wrote:I expect that those with a need for a 2nd CAN bus are going to be more likely to know how to go about generating their own bitstream.

To be clear, I was only proposing one CAN bus on the 7020 and none on the 7010, though there are two available. Two timer interfaces on the 7020, one on 7010. And only one SPI for either device (with three chip selects) though there are two available. I agree with you that anyone needing something more sophisticated can create it (or at least ask for it), but this "high-connectivity" version should satisfy most people who want to do things besides bit-bang a bunch of GPIOs.

-Fred
Last edited by FHuettig on Tue May 06, 2014 3:14 am, edited 1 time in total.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby timpart » Mon May 05, 2014 10:45 pm

A while back I commented that the UART has no flow control. I think I've since read somewhere in the Zynq`manual that GPIO lines can be used to provide RTS, CTS etc. So perhaps that could be an option too. Andrew @9600 had some cunning ideas for using a serial link I recall. (see the thread referenced above).

The control lines would be raw signals without a buffer chip like Tx and Rx have on the board, so some care might be needed.

I like the sound of Fred's I2C idea.

Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby rec » Mon May 05, 2014 11:53 pm

In systems which consist of a single parallella board the PEC_NORTH and PEC_SOUTH signals could be looped back to each other inside the FPGA to form a ring with a single Epiphany chip in it. Or the elink lines could be just terminated with no connection inside the FPGA. Then the IOs on the PEC_NORTH and PEC_SOUTH connectors could be rerouted for other purposes.

-- rec --
rec
 
Posts: 13
Joined: Mon Dec 17, 2012 3:29 am

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby FHuettig » Tue May 06, 2014 3:35 am

rec wrote:In systems which consist of a single parallella board the PEC_NORTH and PEC_SOUTH signals could be looped back to each other inside the FPGA to form a ring with a single Epiphany chip in it. Or the elink lines could be just terminated with no connection inside the FPGA. Then the IOs on the PEC_NORTH and PEC_SOUTH connectors could be rerouted for other purposes.


I'm not sure what purpose it would serve to loop the NORTH and SOUTH eLinks together, I think any message routed out the north side, then entering the south side, would just be routed northward again. But at any rate this can not be done within the FPGA. The NORTH and SOUTH eLinks are routed only to the PEC (Samtec BSH) connectors, not the FPGA. Only the EAST eLInk goes to the FPGA.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby 9600 » Tue May 06, 2014 6:45 am

timpart wrote:A while back I commented that the UART has no flow control. I think I've since read somewhere in the Zynq`manual that GPIO lines can be used to provide RTS, CTS etc. So perhaps that could be an option too. Andrew @9600 had some cunning ideas for using a serial link I recall. (see the thread referenced above).


Turns out you were giving me more credit than due in that post, Tim. I can't think of many uses for hardware flow control with the Parallella UART, other than perhaps if you wanted to:

  • use a GPS RX with ntpd (ISTR it uses one of those lines for sampling the RX pulse-per-second output), or maybe one of those little atomic clock (MSF etc) RX
  • program an Arduino and have auto-reset via IDE (although Parallella is 3.3v logic)

In the post you referenced I was suggesting that in using a Raspberry Pi as a "watchdog" or terminal server for a Parallella cluster, you could use its GPIO to switch the routing of the Pi's UART between the UARTs of number of Parallella boards.

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Routing additional Zynq hard block I/O to PEC_FPGA

Postby parapara » Wed May 07, 2014 7:26 pm

timpart wrote:A while back I commented that the UART has no flow control. I think I've since read somewhere in the Zynq`manual that GPIO lines can be used to provide RTS, CTS etc. So perhaps that could be an option too.
Tim

Actually, it's not just "using GPIOs"
The Technical Reference Manual is pretty explicit about existence of the control signals
Paragraph 19.1 UART: Introduction wrote:Modem control signals: CTS, RTS, DSR, DTR, RI and DCD are available only on the EMIO interface

Actually, there is even a section about operating those signals (Section 19.2.11 "Modem Control")
parapara
 
Posts: 7
Joined: Thu May 01, 2014 8:35 pm

Next

Return to FPGA Design

Who is online

Users browsing this forum: No registered users and 1 guest

cron