Jump to content
  • 0

Ask for help about Pmod I/O


ZYLL

Question

Hi, I need help about Pmod I/O. I have a Zedboard and I use GPIO to control some pmod pins to output voltage signal. I use SDK and c language to achieve it, but it seems like that the each time I use "XGpio_DiscreteWrite" it cost me more than 0.1 microsecond, i.e., it changes voltage with frequency much less than 10MHz. This is really slow comparing to its clock frequency. I have noticed that in the embed topic there are arguments about PS, PL side but I have totally no idea about how to improve the performance. 

On the other hand, I also need to use another pmod pin to "trigger" my board, i.e., when I send a high voltage to the pmod pin, the program started to work. It's really similar to the interrupt example in the tutorial, but I still cannot achieve it.

Thanks for your help! 

 

Link to comment
Share on other sites

14 answers to this question

Recommended Posts

Hi ZYLL,

AXI GPIO core is fairly slow, although I could not find a specific switching rate, other users have found that it works around 2-3 MHz. If you are doing bit-banging using AXI GPIO this is the best you can hope for. I recommend either writing your own GPIO core, although I don't know how much of an improvement it will be, or moving the whole part of the project which uses the AXI GPIO core in to the PL and making a custom core for it.

Regarding the trigger signal, use AXI interrupt controller core which you can configure either on edge or on level and you should receive an interrupt when the signal changes. 

Regards,

Cipi

Link to comment
Share on other sites

17 hours ago, Ciprian said:

Hi ZYLL,

AXI GPIO core is fairly slow, although I could not find a specific switching rate, other users have found that it works around 2-3 MHz. If you are doing bit-banging using AXI GPIO this is the best you can hope for. I recommend either writing your own GPIO core, although I don't know how much of an improvement it will be, or moving the whole part of the project which uses the AXI GPIO core in to the PL and making a custom core for it.

Regarding the trigger signal, use AXI interrupt controller core which you can configure either on edge or on level and you should receive an interrupt when the signal changes. 

Regards,

Cipi

Thank you Cipi, 

Yes I know that the switching rate is limited without writing GPIO core myself. Fortunately 2-3 MHz is somehow okay for my purpose. 

The trigger signal to interrupt is shown everywhere, but the trigger signal to start is not that easy. For example, in Vivado I can add interrupt in the AXI_GPIO IP but not a sudden start. I think the principle is similar but I tried some approaches but all failed. 

Link to comment
Share on other sites

It's unclear to me what you mean by: "when I send a high voltage to the pmod pin, the program started to work". Do you want to reset the software part (C code) or do you want it to be like an enable signal for the hardware part or do you want the project to initialize and then wait for the interrupt signal?

Link to comment
Share on other sites

1 hour ago, Ciprian said:

It's unclear to me what you mean by: "when I send a high voltage to the pmod pin, the program started to work". Do you want to reset the software part (C code) or do you want it to be like an enable signal for the hardware part or do you want the project to initialize and then wait for the interrupt signal?

Hi, I would like to run part of the c code only after the trigger signal is received. The signal works as a switch that turns on my code. 

Link to comment
Share on other sites

@ZYLL,

It might make more sense to review your requirements--this really seems like a backwards way of solving a problem.

It sounds like you want something to happen on an external signal.  I also get the impression that you want to send information, either this signal or some other, at a high rate of speed once the signal takes place, right?

This is really the purpose of the programming logic (PL).  Care to share your full scenario of what you are trying to do?  You might find doing it in the PL makes a *lot* more sense than in the PS.

PS (CPU) advantages: CPUs can be easier to program than FPGA logic, and faster/easier to reconfigure and debug.

PS disadvantages: CPUs are very hard to make deterministic in time.  They were really never designed for that purpose.  Real-Time software has always been a challenge.

PL advantages: Everything is deterministic in time.  You can often handle interactions at 2-10ns level precision (depending on the complexity of the interaction).  Unlike the CPU, you can control *exactly* how the timing will work out--from receiving the signal until processing it is complete.  Real-time interaction is usually the default, although you can mess it up.   ;)

Dan

Link to comment
Share on other sites

12 hours ago, ZYLL said:

Thank you Cipi, 

Yes I know that the switching rate is limited without writing GPIO core myself. Fortunately 2-3 MHz is somehow okay for my purpose. 

The trigger signal to interrupt is shown everywhere, but the trigger signal to start is not that easy. For example, in Vivado I can add interrupt in the AXI_GPIO IP but not a sudden start. I think the principle is similar but I tried some approaches but all failed. 

Hi @ZYLL

FYI, you can send interrupt from PL directly to the processing unit bypassing the GPIO. It is not well described but it works on rising edge with no added latency. I am convinced that interrupts are the best way to make both PL and PS working on the same goal and doing what each can do best. Because PS has many resources connected to it and requires very little coding, neglecting it would be counterproductive, at least in a standalone mode.

It should be mentioned that nested interrupts are not documented by Xilinx, thus, very difficult to use. When I needed I could find some information only on ARM site. It means it could cost you time if you need more than one interrupt.

 

Link to comment
Share on other sites

@Notarobot, @ZYLL,

Sadly, I have no experience with a Zynq, but from the experience I do have let's think about how fast something might respond to an interrupt:

  1. If you are already within an interrupt, then you will need to wait for that interrupt to complete (unless you nest interrupts)
  2. Once the interrupt routine starts, you will then need to load the routine from memory into the cache.  This may cost you 240ns or more (this is based upon my experience with the DDR3 on the Arty, your memory may or may not be faster, your flash *WILL* be slower.)
  3. While the interrupt routine is servicing your interrupt, you are not doing anything else.

The PL side of the zynq will bypass all of these restrictions.  Still, @Notarobot's recommendation is not a bad one---just understand where your latencies are and pick the best option for your application,

Dan

Link to comment
Share on other sites

@D@n, @Notarobot

In a way you both are right. Generally speaking if you have an interrupt and based on that interrupt you want to do something "simple" as GPIO control or interface control (SPI, UART, I2C, etc.) and the timing is extremely important then it is strongly advised to program it in to the PL; this is also this case if you are dealing with a complex project and you PS code is starting to mess with your overall performance of the project. I am a strong advocate of using as much of the PL as possible because that is the advantage of an FPGA and especially of the ZYNQ.

But if you need something sequential like a certain order to the execution of a project then it is easier to use the processor, yes you loose execution time but you gain transparency and simplicity which for a project with a "higher complexity", such as using multiple interfaces in a certain order or implementing stacks, is important. So rather than creating a enormous state machine just to accommodate a certain sequence it's easier to just use the PS and coded it in C.

The bottom line is:

1. We do not know what the user wants to do, might be something easy might be something which is more than just some GPIO and an interrupt signal 

2. We do not know the extent of his knowledge, he might be more proficient in C than in HDL which means it would be easier for him to just use the PS

3. We do not know if high performance is a requirement for what he wants to do, he might not need high speed execution time, it would be nice to have it but it is not a necessity

4. We do not know if he has a deadline (self imposed or otherwise), and this is the most important for him because based on this information he must choose if he will venture in leaving his comfort zone and learning something new or he needs it ASAP and then just tries to make it work somehow (this is bad practice by the way) based on what he knows and as little as possible effort.

We are speculating here and until we get more information you both are, in a sens, right.

Cipi

Link to comment
Share on other sites

@D@n @Notarobot @Ciprian

I actually have very limited experience on how to program in PL. My purpose is just simple GPIO control so I know it might be really good to just use PL. The question is all of the tutorials about zedboard I can find is use Vivado and SDK and use C to control everything. Would you like to give some example or tutorial about how to do so? 

For my purpose, I need to switch the GPIO signal with frequency at least 1MHz, so at this level use PS and C is somehow sufficient. But of course the higher frequency I can get, the better the project is. 

BTW, I already make it work; I just wonder can I make it better so don't worry too much about a deadline. Hopefully learning how to use PL would not cost me too much time, say several months or more. 

Link to comment
Share on other sites

Dear @ZYLL

In my understanding your exercise of driving GPIO at 1 MHz is just an exercise because it doen't make other sence to keep the processor busy doing a task that can be done by one small process in PL. You can start / end this process by the processor. PL can notify the processor about events invoking an interrupt.

My advice is to learn HDL. You board will be able to do many tasks in paralles and free the processor for supervisory and communication functions. Personally I like and use VHDL because it is strongly typed language and majority of coding mistakes can be flagged as you type. It is more verbose than verilog but I find that VHDL code is easier to understand becuase the code is well structured. I made couple attempts switching to verilog in the past in order to add another skill but didn't find it worth the effort.

It should be said that lot of people prefer Verilog.

 

Link to comment
Share on other sites

@Notarobot,

Heresy!  How dare you teach anyone anything but Verilog!  :P 

@ZYLL,

Learn Verilog.  It's much better.  :lol:

You'll find examples and tutorials for both Verilog and VHDL on asic-world.  Like @Notarobot, I learned Verilog first and now struggle to like VHDL.  Given that I struggle to use VHDL, I can say that one reason why I like Verilog is because of the free and open source tools that support Verilog.  My favorite one is Verilator, but yosys is another example.  In other words, my choice would be to use Verilog regardless of the tools, but since open source supports Verilog so well ... you should pick Verilog as well.  ;)

Dan

Link to comment
Share on other sites

Hi to all,

I just wanted to note that regardless of language choice we should mind that not all statements are synthesizable. Different vendors use different versions of HDL languages and open source tools not always in sync with vendors.

I believe that using open source design tools introduces additional unneccessary risk and, personally, I would use only vendor's tools for industry applications. Perhaps for education open source is acceptable.

Apology for unclear statement and confusion.

Link to comment
Share on other sites

@Notarobot,

Care to clarify?  "I believe that using design tools introduces additional unnecessary risk ..." is rather ambiguous.  I'm not familiar with an approach to working with an FPGA that doesn't use "design tools" (Vivado being a common one).  So ... can you explain what you are referring to?

Dan

Link to comment
Share on other sites

Hello,

I hate to jump in here, but in order to not confuse any future readers of this thread about what the original question was (since I believe ZYLL's question has been answered at this point; using HDL will be the way to go to toggle a pin a high frequency reliably), I would recommend that discussion on the various merits of tools whether provided by the community or a vendor for their own products be relocated to a separate thread.

I'm personally okay at this point in time with the discussion happening on the Forum in general (in fact I'm curious to see people's thoughts on it), but just not on this thread per se. I can help with this in terms of the splitting of the thread if that is helpful.

Thanks,
JColvin

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...