Jump to content
  • 1

Direct PMOD pin access bypassing GPIO


loberman

Question

Hi

This should be really easy to answer by the knowledgeable folks here.

If I just use the xdc constraints and map the pin in an FPGA design, will this route to the pmod pin mapped to a specific FPGA pin bypassing GPIO.

Of course I would not have any PMOD IP for the particular pmod in my design.

I am looking for a way to get a 10Mhz clock I added to the clock wizard easily out to a pmod pin.

Any examples would be great

Thanks

Laurence

Link to comment
Share on other sites

25 answers to this question

Recommended Posts

Hi

Well. its not much code, its exactly what Jon suggested I do.

I added another output clock of 10Mhz to the clock wizard

I then created a port as a clock output and connected the clk to the port

The JA Header notes say G13 is ja[0] so I constrained that below

##Pmod Header JA
#set_property -dict { PACKAGE_PIN G13   IOSTANDARD LVCMOS33 } [get_ports { ja[0] }]; #IO_0_15 Sch=ja[1]
set_property IOSTANDARD LVCMOS33 [get_ports pmod_ja_clk]
set_property PACKAGE_PIN G13 [get_ports pmod_ja_clk]

I am about to connect an Oscilloscope to the ja[0] pin to check the output. Everything synthesized and worked to create the bitstream.

I did not use any of the board JA IP, for this but I am using the IP for JC for the pmodOled.

This is somewhat of complex of a design because its running Linux as well.

Link to comment
Share on other sites

Hello

Thanks yep for ZYBO its a lot easier, I have done that already.

The access is made easier with the built in ARM processor on the ZYBO.

The challenge is the microblaze and AXI.

I am working on it  now, I hacked the pmodSD stuff and will and whatever I figure out to this post

 

Link to comment
Share on other sites

4 hours ago, loberman said:

Hello Gau_Veldt

You bring up an interesting point here for the Embedded Linux kernel interfacing to the PMOD

Right now I have access to all switches, LED and all the shield pins via the gpio interfaces on Linux that use AXI.

When one uses the Digilent IP to expose a PMOD jA to jd for example, you have to choose a pmod module however.

I want the same IP connected to the AXI bus but direct to the pmod so I can use the Linux GPIO driver to get the the native pins of a pmod interface.

From your post you seem to know how to do that. I was thinking of taking the most simple pmod connection and modifying the HDL.

If not I will have to write my one driver, but figured I would ask first.

Regards

Laurence

I am aware of the architecture to know what would be needed but researching how will have to wait until the end of March when I'm back from a family visit and am once again in front of Vivado and my Zybo board.  Any implementation details at this point would be speculation on my part.

 

 

Link to comment
Share on other sites

Hello Gau_Veldt

You bring up an interesting point here for the Embedded Linux kernel interfacing to the PMOD

Right now I have access to all switches, LED and all the shield pins via the gpio interfaces on Linux that use AXI.

When one uses the Digilent IP to expose a PMOD jA to jd for example, you have to choose a pmod module however.

I want the same IP connected to the AXI bus but direct to the pmod so I can use the Linux GPIO driver to get the the native pins of a pmod interface.

From your post you seem to know how to do that. I was thinking of taking the most simple pmod connection and modifying the HDL.

If not I will have to write my one driver, but figured I would ask first.

Regards

Laurence

 

 

Link to comment
Share on other sites

3 hours ago, Krish said:

Can you  send the code to me I want to know how to connect pmods in fpga nexus4 artix7 board mithinti.krishnavamsi@gmail.com

Thank you

Loberman basically already indicated what you'd need in HDL.

 

I'll just add most boards have a downloadable constraint file (at least this was the case for the Zybo).

 

Copy it into your project's (right clicking on the constraints in the sources pane followed by add new constraint files ensuring to check the "Copy files to project" option) constraints folder then open the constraints file (I'm using Vivado btw) and uncomment the lines for the desired pins (in this case one of the PMOD ports).  Be sure to check the hardware manuals that the PMOD port chosen is appropriate to the application (eg: "slow" ports with protection resistors are better for experimenting on a breadboard).

 

For extra credit: create a (bridged, meaning a separate 64-bit register latches this counter's output to a different clock domain) HDL 64-bit counter clocked by the 10 MHz (or faster) signal and create an AXI interface to make it accessible to the PS (linux).  Then modify the /dev/random kernel driver to use the counter for entropy (/dev/random) whenever input from USB peripherals or network occurs.

 

Link to comment
Share on other sites

Within Vivado you would go to the board tab and click on the particular pmod for the nexys4. Then choose what type of pmod ypu will plug into that pmod port.

Digilent has pro-actively supplied the IP in the Vivado library so when you choose a pmod the IP will get included and Vivado will offer to auto configure it. Let it do that and you will be all set.

I am using Linux to drive the pins via gpio and the 10Mhz was a separate clock I needed for my project.

Thanks

Laurence

Link to comment
Share on other sites

I confirmed all is well on the scope and the 10Mhz is on the output pin.

Scope frequency slightly varies as expected between 9.9 and 10.1 Mhz but its clearly working as it should.

If you just want to interface from the fabric of the FPGA to the PMOD pin its easier as Jon has shown to just use a constraint base don the Pin#

Use the Digilent provided xdc file for the Nexys4 to get your pin numbers.

 

Link to comment
Share on other sites

On 14/01/2018 at 2:17 PM, Gau_Veldt said:

I've driven PMOD lines directly from HDL as part of a PWM driver to vary the brightness of LEDs when connected (via resistors) to the PMOD line jumpered onto a breadboard from one female end of a 12-to-2x6 PMOD splitter cable (the other end I reserved for plugging in a keyboard via a PMOD PS/2 adapter).  It works fine to uncomment the appropriate PMOD port lines in the XDC file (and add those pin names into the entity declaration, as output in my case).

 

In VHDL something like your problem I'd achieve by first using the clock wizard to make the initial 10 MHz clock, uncomment the desired PMOD declaration (in my case the Zybo there's six: JA through JF, I typically use JE since it has protection resistors and unpaired inputs making it more suitable for breadboarding in conjunction to the PL) and then a single signal assignment in the architecture section to drive the desired PMOD signal with the output signal from the clock.

 

If requested I could place the PWM LEDs-via-PMOD VHDL source (only a single VHDL file, not counting XDC since these are board specific and I don't include them) on github.

 

PS: I'll add here that it is also possible to rename the signal lines in the XDC to match the names used by an HDL project (making it easier to use a generalized project on different boards) rather than searching and replacing signal names in the project sourcefiles to match the XDC.  This is likely the less error prone way and more friendly for end users of projects intended to work on a variety of boards (making it easy to upgrade to a Zybo2 or Zedboard from an original Zybo, perhaps).

 

PSS: In the context of the PMOD documentation "GPIO", from an HDL perspective, is going to mean the PL generally (notwithstanding particular IPs that may already do so) accesses the PMOD lines directly.

Can you  send the code to me I want to know how to connect pmods in fpga nexus4 artix7 board mithinti.krishnavamsi@gmail.com

Thank you

Link to comment
Share on other sites

Hi @loberman,

The pmod Bridge makes it straightforward to connect the board files and a set of interfaces with standard a pinout.
So if the pmod uses a normal spi interface, it's easy to configure the bridge and connect it to the qpsi controller. 
Doing non-standard pinouts with it is not as convenient. Lots of concat and slice ips. If you want to use it to connect a non-standard thing. Then you will need to configure both the top and bottom channels as gpio, and deal with all of the tristate pins for each of the 8 ports.

cheers,

Jon

Link to comment
Share on other sites

Hi @loberman,

Have you tried using "create port"  by right clicking in the block design in empty spot in the design? You can dictate the name used, in out or inout and if it is a clock and then constrain the pin created in the wrapper with an xdc. You could use the clock wizard to generate a clk and connect it to the port.  If you are also using the other pins on that port with a pmod IP core then make the pmod out external and constrain those pins in the xdc as well. 

cheers,

Jon

Link to comment
Share on other sites

I created two Vivado IP's for this purpose.  One is PMOD out and the other is PMOD in.  The verilog is basically wire in and assign out.  

This way I can map the 'PMOD' interface on the block design and connect to one of the PMOD board components.

-Brian

Link to comment
Share on other sites

... and there are completed projects in the Digilent Project Vault with source code, including constraint files...

Note: Vivado is good at letting you know if you have multiple drivers for output signals destined for a particular constraints file pin. The designer has more of the burden for input signals, though trying to assigning the same name to an IO pin in the constraints file will cause a bitgen error.

Sometimes I change my HDL to agree with the default FPGA board constraints file and sometimes I change the constraints file names to agree with my HDL. I decided to add this paragraph because it raises another issue. Some FPGA vendor tools ( Intel's Quartus is the worst ), especially with the IP schematic design flow, want total control over some of the source files, particularly where the IO pin location, IOSTANDARD, output current etc. parameters live. All of the FPGA vendors discourage modifying these files manually. In general I don't like the GUI tools for setting this information so I manually modify the files. Quartus is particularly difficult to get along with and I make sure that it isn't running when I do my modifications. Xilinx tools are a wee bit more accommodating of users like me. Figuring out the syntax for setting timing constraints and feature constraints ( particularly from Xilinx documentation ) is not always an easy task and in cases where I just can't get an answer from the documentation letting the GUI offer the correct syntax can be helpful. I prefer know the syntax and hand editing the appropriate source file. Some users will never have to worry about timing constraints or more than selecting the pin location and  IOSTANDARD. 

Like chess there are a lot of strata of complexity where you can live in the FPGA development neighbourhood and find happiness.

Link to comment
Share on other sites

I've driven PMOD lines directly from HDL as part of a PWM driver to vary the brightness of LEDs when connected (via resistors) to the PMOD line jumpered onto a breadboard from one female end of a 12-to-2x6 PMOD splitter cable (the other end I reserved for plugging in a keyboard via a PMOD PS/2 adapter).  It works fine to uncomment the appropriate PMOD port lines in the XDC file (and add those pin names into the entity declaration, as output in my case).

 

In VHDL something like your problem I'd achieve by first using the clock wizard to make the initial 10 MHz clock, uncomment the desired PMOD declaration (in my case the Zybo there's six: JA through JF, I typically use JE since it has protection resistors and unpaired inputs making it more suitable for breadboarding in conjunction to the PL) and then a single signal assignment in the architecture section to drive the desired PMOD signal with the output signal from the clock.

 

If requested I could place the PWM LEDs-via-PMOD VHDL source (only a single VHDL file, not counting XDC since these are board specific and I don't include them) on github.

 

PS: I'll add here that it is also possible to rename the signal lines in the XDC to match the names used by an HDL project (making it easier to use a generalized project on different boards) rather than searching and replacing signal names in the project sourcefiles to match the XDC.  This is likely the less error prone way and more friendly for end users of projects intended to work on a variety of boards (making it easy to upgrade to a Zybo2 or Zedboard from an original Zybo, perhaps).

 

PSS: In the context of the PMOD documentation "GPIO", from an HDL perspective, is going to mean the PL generally (notwithstanding particular IPs that may already do so) accesses the PMOD lines directly.

Link to comment
Share on other sites

@loberman

As to assigning GPIO in your FPGA design. As long as the name of your signal on the toplevel port is the same as the name in the constraints file; and not commented out and matching the pin designator on the schematic then you are good to go. This raises the issue of what kind of design flow your are using. I generally don't use the schematic board design flow; just HDL. For me this is straightforward. For users of the board design flow and Digilent scripting this might be a bit more complicated. Regardless of how you do this I always recommend that you check at least the following:

  • Use the schematic to make sure that the FPGA IO pin matches the constraints file pin assignment
  • Make sure that the bank IO voltage supports the IOSTANDARD that is compatible with whatever you are connecting to externally.
  • Read the Vivado or ISE "compilation" flow messages to make sure that there are no issues with the GPIO signals in you design
  • Check the post "compilation" pin report to verify that you IO pins are assigned to the pin that you expect and that the IOSTANDARD matches you expectation.

As to the 10 MHz clock that you want to drive your PMOD output pin. My advise here is that it depends on how complicated your FPGA design is and how much of the routing resources it takes up and what it is that your 10 MHz signal is driving. Since you used the clocking Wizard to create you clock, at least you haven't made the mistake of pretending that a logic derived signal is a clock. Doing that causes all kinds of problems. Here's the part where you have to evaluate as to whether or not your PMOD 10 MHz clock is suitable or not. Some FPGA IO pins are clock capable; that is clock line signals can be driven out on them or driven into them and then into the internal clock lines. This is a best practice and what you should always do. Internally to the FPGA real clock line routing resources are differentiated from logic routing resources for a variety of reasons. Some IO pins can only be connected to logic derived signals. Should you try to connect a clock line signal to an IO pin that isn't designed to do this one of the Vivado tools ( synthesis, place and route, bitgen...) will either present a message complaining about or, best case, fail in bitgen with a DRC error. Typically people get around this by adding logic that makes the "clock" logic derived. This is not recommended. All kinds of issues, particularly during synthesis and routing, can result in doing this; not to mention that your clock is less than pristine. Plus you are developing a bad habit that make you a much less competent FPGA developer than you might imagine. That is not to say that for trivial designs you can't be happy with the results and think that everything is just fine.

Sometimes, for reasons that are unavoidable, seasoned FPGA experts do the wrong thing because there is no other choice. But knowing that you did the wrong thing and understanding why it's wrong and carefully documenting the wrong thing is different than doing the wrong thing and thinking that you're a genius.

Lastly, and I hope that I'm not confusing the issue, it is sometimes acceptable to pretend that a logic signal is a clock. One example that comes to mind is an SPI or I2C interface. I have used logic derived signals for these many times. These are (usually) low frequency interfaces and allows controlling setup and hold timing in logic ( this is good when such timing is variable ). Of course the logic design is complicated enough to cover these requirements. I added this paragraph to illustrate why the analysis of whether or not your clock output is "good enough" for your application is your responsibility. The difference for my SPI (I2C) example is that in this case the Xilinx tools are oblivious to that fact that an IO signal is used as a clock... and the HDL designer has taken on timing responsibilities and addressed them in the design.

good question

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...