Jump to content

tnkumar

Members
  • Posts

    42
  • Joined

  • Last visited

Posts posted by tnkumar

  1. On 12/18/2021 at 9:11 AM, tnkumar said:

    Thanks @thinkthinkthink
    For 2019.1, I downloaded from Releases · Digilent/Zybo-Z7-20-pcam-5c · GitHub
    I see the directory as below and on clicking on the Vivado project file, it opens in Vivado 2019.1

    In the link you provided, I just see a .keep file. Where can I find the Vivado project file which will open in Vivado 202x.y?
     

    image.png.760303ef9b563f343b7c29d14fcdbc32.png
     

    @thinkthinkthink - Any suggestons?

  2. 4 hours ago, thinkthinkthink said:

    It was already updated to 2021.1 on our github. Here's the Vivado repo branch and Vitis repo branch.

    Thanks @thinkthinkthink
    For 2019.1, I downloaded from Releases · Digilent/Zybo-Z7-20-pcam-5c · GitHub
    I see the directory as below and on clicking on the Vivado project file, it opens in Vivado 2019.1

    In the link you provided, I just see a .keep file. Where can I find the Vivado project file which will open in Vivado 202x.y?
     

    image.png.760303ef9b563f343b7c29d14fcdbc32.png
     

  3. 9 hours ago, zygot said:

    Gee, those were your takeaways? Sigh...

    You've used the Red Pitaya so you have an idea how one custom Linux build runs on a dual core 600 MHz ARM processor. Don't expect those results with Microblaze. As nifty as that instrument is, it still lacks features that one might expect for the money.

    As for the PMODNIC100, this is a strictly low ( 10BASE-T) speed Ethernet solution. I've done 12 Mbaud USB UART interfaces with DE0 Nano and CMODs. The ENC424J600 is an odd bird among Ethernet solutions and the PMOD SPI interface is the slowest possible way to get data into and out of it. Make sure you are comfortable with the support that Digilent supplies for that device as far as software drivers and logic connections go. I'd be pretty surprised if you will find Linux drivers ( what kernel version are you intending to use? ) for that PMOD. But, I'm used to surprises.

    Be aware that ( as of Vitis 2020.2 ) Petalinux still hasn't been integrated into Vitis and requires a separate and not easy install. You can only use Linux hosts of a certain distribution and version, much like Vivado, but with cross-compiler tools it's even more important to follow the rules.

    I'm not one to stand in the way of anyone pursuing their obsession but considering how this discussion has turned from your initial post to the most recent on I'm hoping that you aren't distracted by subject material that really is peripherally related to logic design and development. If you want to do custom Linux programming then the RPI4 is cheaper and faster.

    Programmable logic is pretty cool and very complicated. Programmable logic paired with a computer is even cooler and a whole lot more complicated if you want to do more than have Vivado wire up a limited set of IP for you to play with. Everyone has their own path to follow, so well wishes to you as you choose yours.

    Thanks @zygotfor listing implications of going down this path. I think I will leave PetaLinux out of my pursuits for now. 

  4. Thanks @zygot and @asmi for additional perspectives.

    I had the following takeaways

    -try and create a minimlist kernel, possibly with a driver for a PMOD Ethernet interface

    - you can have Petalinux in non volatile memory

    Not that I intend to immediately try these, but that these are possibilities.

  5. 8 hours ago, asmi said:

    There are some specific requirements for your MB design in order to run Linux - MB itself has to be configured to run Linux (there is a preset in MB's customization dialog), you need to have at least 32 MBytes of memory (Arty-S7 has more, so that's fine), you need to have a timer, a UART port (so that you can talk to it), and a QSPI interface for storing Linux image (I think this is optional, though it wouldn't hurt for sure), and an interrupt controller. Pretty much all Xilinx-provided IPs have a driver for Linux. You will also need access to Linux installation (virtual machine will work too), as all Petalinux stuff only works in Lunux.

    I don't know of any guide specific to Arty-S7, not do I have an actual board to write one, but it's not very complicated. You can go through this guide: https://numato.com/kb/mimas-a7-microblaze-and-linux-how-to-run-linux-on-mimas-a7-fpga-development-board/ to get an idea of what's involved.

    Unfortunately information is kind of scattered all over the place, here are requirements for MB system taken from UG1144:

    One bummer is that Arty-S7 doesn't have Ethernet, so you can't use what I think is the biggest advantage of running Linux - which is networking. But you can still make it work, I've done it for Spartan-7 on an open-source board I designed for those who would like to get a jump start on designing their own boards. The device was Spartan-7 S50, which is what you have on Arty, so it's got more than enough logic resources to make it happen.

    Thanks @asmi for all the pointers. It is heartening to know that Linux may be possible. Regarding Ethernet, possibly this https://digilent.com/shop/pmod-nic100-network-interface-controller/ PMOD can be used with the ArtyS7-50?

  6. 9 hours ago, asmi said:

    you can run Linux on Microblaze as well).

    @asmi - Can you point to tutorials that show how Linux can run on MicroBlaze? Would this be possible on Arty S7-50? The tutorials I came across using Vivado / Vitis 20.1 point to the use of MicroBlaze with c/c++

  7. 2 hours ago, asmi said:

    PCI Express has insane latency compared to AXI HP bus available for Zynq. It also requires, well, actual PCI Express host, while Zynq solution is self-contained on a single chip. Zynq DDR3 controller peaks at a bit over 4GB/s, which is enough for a lot of applications. If your design need more, you can add another memory controller in PL, but I suspect that fabric speed will become a limiting factor somewhere in that area. You can step up to Zynq-030, which sports faster Kintex fabric and can implement 933 MHz DDR3 controller, which will give you all the bandwidth you'll ever need, and you can set up your design such that ARM CPUs will have access to part (or all) of that memory as well as that of the hardIP side - the limiting factor here is address space, but this can be side-stepped by banking.

    Seriously? External board with PCIE and a PCIE card with FPGA is cheaper/better/easier than just a single chip?

    I don't have any commercial experience with it myself, but some of my customers did some designs on a board I built for them, so my experience is only anecdotal. That said, these customers were super-happy with results, with the main advantage being time to market, so there is definitely a place for it. Again, yet another tool in our toolbox to learn about so that we can use it when a need arises.

    That is one possible use case, but Vitis basically produces IP blocks that can be connected to any other logic in Vivado, you can use them even with pure FPGAs like Artix. HLS is great for stuff like advanced math, FFT, image processing via OpenCV, as Xilinx includes a library of these functions ready to be used in your C/C++ code, allowing for extremely fast iterations - as you can debug your code as a regular C/C++ application, with compilation being pretty much instant, and only move to hardware once you've ensured that your code works properly - and even here you can use the very same C/C++ testbench you used to debug your code, to run a co-simulation to verify that generated core still works properly.

    If you are interested and have some time, I recommend you to watch the following YT playlist: https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHC They are one of the best video tutorials I've seen on this subject, even if they are a bit dated.

    Thanks @asmifor sharing the link to YT HLS video tutorials. I had also come across (~8 mins video)

     that very nicely explained the beneift of HLS in some scenarios.

    @zygot - It is ok for threads to diverge from the original question ?. I learnt a lot reading the discussions with @asmi and you
    I have been working with FPGAs for about 4 weeks and these discussions are very beneficial for me.

  8. 13 hours ago, thinkthinkthink said:

    You can get an OV7670 camera module and some MTE cables and connect them to Pmod ports. Just be aware that you'll need maybe 2 or 3 Pmod ports for one camera module. I've managed to pull it off on the old ZYBO board.

    Thanks @thinkthinkthink. Do you have the details of how you got this to work with 2 or 3 PMOD ports, even though it was with the ZYBO board? What are MTE cables?

  9. 4 hours ago, JColvin said:

    Hi @tnkumar,

    That is correct. There are some considerations that you will have to take into account though.

    The first, and most critical in my opinion, is logic resources on the FPGA; each Pmod takes some amount of the LUTs and other available logic resources on the FPGA. This can get further compounded if you use the Digilent made IPs which use different AXI peripherals to be able to communicate with the host processor (usually Microblaze on an Arty S7-50). I would highly recommend that you check that the designs you are intending to create are able to successfully fit and run on an Arty S7-50 by generating the bitstreams and if you are using a processor, the Vitis/SDK applications in advance before you buy a wide range of Pmods + the Pmod Shield, if only to save the hassle of returning products you aren't able to use.

    The second is that most of Pmod ports on the Pmod Shield have 200 Ohm series resistors. In conjunction with the 200 Ohm series resistors that are also present on the Arduino styled header I/O pins on the Arty S7/A7/etc themselves, this can lead to some unexpected behavior on different modules i.e. slower speed, lower I/O voltage, etc, all potentially leading to the attached Pmod not working. I know I have experienced this first hand with different Pmods.

    The third is power consideration. Most Pmods don't need a lot of power, but it's also non-zero amount. The DA9062 should be able to supply 2 amps worth of current on the 3.3 V rail, but Pmods are not the only things in the system that use that 3.3 V line.

    My personal opinion, stemming from the second point and the fact that the Pmod Shield is no longer being sold/manufactured, is that if you are not considered about the overall look of the system, you may want to consider just individually wiring additional Pmods to the existing female header on the Arty S7, as that is all the Pmod Shield effectively does. This would also help facilitate using different features of communications like SPI where a number of the same communication lines can be shared between different Pmods, reducing the number of overall I/O used on the FPGA itself. You'd have to get the logic appropriately working to switch between the different modules at that point, but it's an aspect to consider when you have a lot of different modules on one system.

    Thanks,
    JColvin

    Thanks @JColvinfor a very detailed answer. It answered all my questions and helped to understand the detailed considerations regarding PMODs and the shield. Thanks 

  10. 16 hours ago, JColvin said:

    Hi @rehsd,

    This is correct. All of the instances in the Pmod Shield documentation that refer to JA, JB, etc., are referring to the Pmod Shield Pmod host ports themselves, not whatever host FPGA/microcontroller it might be placed on top of has in terms of Pmod ports (as an example, an Arduino board has no Pmod Host ports).

    The way the Pmod shield makes the connections to the host system is through the pins on the underside of the board to connect to the female IO headers on the host system.

    The bit about the SPI, UART, and I2C Pmods on the shield are only relevant for the Digilent microcontrollers since microcontrollers are hardwired to a particular protocol 'engine' on the processor. FPGAs do not have this limitation with pins connected to their fabric as you can configure the FPGA to create a protocol bus of whatever variety you like (limited by speeds, I/O standards, and termination of course, but that's not an issue for SPI, I2C, UART, and GPIO Pmods).

    To configure those Pmod ports for something like the Arty A7 35T, you would do something like this in the .xdc (after you add the Pmod IP/Hierarchy and make the Pmod_out connection external, which you can then name to something else) for Pmod JA on the Pmod Shield:

    
    #set_property -dict { PACKAGE_PIN U11   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin1_io  }]; #Arty A7 Arduino header pin 26, Shield JA1
    #set_property -dict { PACKAGE_PIN V16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin2_io  }]; #Arty A7 Arduino header pin 27, Shield JA2
    #set_property -dict { PACKAGE_PIN M13   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin3_io  }]; #Arty A7 Arduino header pin 28, Shield JA3
    #set_property -dict { PACKAGE_PIN R10   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin4_io  }]; #Arty A7 Arduino header pin 29, Shield JA4

    Let me know if you have any questions.

    Not on the weekends when the Digilent staff is not working. 

    Thanks,
    JColvin

     

    Thanks @JColvin. So, if I were to connect the Pmod shield to an Arty S7-50, at a total system level, I will have the PMODs (JA, JB, JC and JD) on the base Arty board and in addition have PMODs provided by the shield. So, in effect, more than 4 PMODs. Is my understanding correct?

  11. 16 hours ago, zygot said:

    My opinion is that for someone just starting out learning about FPGA development should start with a board just like yours. FPGA devices with an embedded hard ARM complex just adds to the complexity... and there's plenty of complexity for a beginner in programmable logic to master.

    A very small percentage of my projects involve a processor in the FPGA, whether a soft-processor like MicroBlaze or a hard processor like ARM. At some point you need to be able to create you own IP and designs that are FPGA vendor agnostic. And even if you are targeting a ZYNQ ir the like, you will need to have good logic design experience. Trust me, the Arty can keep you busy for a very long time honing those skills.

    I think that a lot of people ( especially those who work for ARM Holdings ) see the ZYNQ as a microprocessor with some FPGA logic attached. I see it as an FPGA with an attached, relatively high performance microprocessor. A lot of my projects are just that... one or more FPGA devices that communicate with a PC or SBC via PCIe or USB 3.0. This can usually provide more processing horsepower and flexibility than an ARM based FPGA. Software development is easier as well. My ZYNQ projects usually require two software projects; one for ARM and one for a PC. If you are building a small embedded system then ZYNQ is a pretty nice way to go.

    Put off the ZYNQ platform until you have mastered logic design verification and debugging. When you need to use an ARM-base device you will be in a much better place to do so effectively.

    Thanks @zygot for your perspective. Very helpful

  12. I currently have an Arty S7-50 board and have started learning FPGAs about a month ago.

    When I browse for FPGA tutorials, I come across Zynq quite often.

    When is it useful to have a Zynq board to learn FPGAs? or is it good enought to continue with Arty S7-50?

     

     

  13. 12 minutes ago, rehsd said:

    @tnkumar, if the shield gives me additional Pmod ports, I can take advantage of them. If the ports are simply duplicates, and I'm only getting one extra Pmod port, I'm guessing I can directly connect to the underlying pins for the JE (5th) connection.

    Digilent staff -> Can you speedily respond to questions from customers / potential customers?

  14. On 12/11/2021 at 1:31 PM, rehsd said:

    I see the Pmod Shield has JA, JB, JC, JD, and JE connections. I am using an Arty A7. Am I correct to assume that JA, JB, JC, and JD on the shield are the same as those on the Arty, or are they different?

    What about JE? It is on the shield, but the Arty doesn't have a JE. Is it an additional Pmod connection that I can use (just needing the proper mapping in the XDC)?

    Thanks!

    @rehsdIf the Arty A7 already has the JA, JB, ... ports, why do you need the Pmod shield? Can we not use the pmod connectors on the board? Or is it that these PMODs are in addition to those on the board and hence you can have 4 Pmods from the base boards and 5 more from the shield. I have hardly seen response to questions from any Digilent staff. May I request Digilent staff to monitor the forum and respond to questions in a timely manner? 

  15. 7 hours ago, zygot said:

    Xilinx Document Navigator. Use it.

    It used to be a lot easier to find technical information and application notes from Altera and Xilinx but this tool installed with Vivado is the best way to browse what's available from Xilinx. Lately, I've found it difficult to even use DocNav as most of the time I have to be logged into my Xilinx user account to access information. For some reason DocNav on Centos has been crashing after downloading one document. The cookie wars between those monetizing the internet and those trying to protect user security seems to be getting out of hand these days.

    You can also find information about various industry standard busses from ARM.

    Digilent and other vendors like ADI have IP repositories in Github that include a some AXI HDL examples. @D@nhas some useful insights here: https://zipcpu.com/

    If you are going to use ARM based FPGA devices effectively then you need to learn how the AXI or AMBA busses that connect the ARM cores to the logic work. Not everyone owning a ZYNQ based platform posting to the Digilent Forums want to be bothered, or has the time, or has the skill needed to design interfaces to these busses. That's the only reason why I'd suggest using alternate means.

    A good place to start would be UG761_axi_reference_guide.pdf available from DocNav.

    Beware that there are subtleties about the use of AXI for ARM based FPGA devices that aren't immediately obvious. Debugging ZYNQ software that encounters AXI buss faults as a result of poor or incomplete AXI-logic interfaces is difficult. Since ZYNQ devices use ARM cores I'd suggest referring to the ARM ydocumentation. I've written AXI IP but don't use it enough to consider myself an expert. Even Xilinx has issues with it according to a few sources. 

     

    Thanks @zygot for the pointers. I will check it out. I am using MicroBlaze on Arty S7-50

  16. 15 hours ago, asmi said:

    ?‍♂️ Of course you can. You can create however many testbenches you want in a single project, and each one can have it's own configuration, or you can have multiple simulation settings for the same testbench. More information is here:

    https://www.xilinx.com/video/hardware/using-vivado-logic-simulator-for-multiple-sim-sets.html

    You can also integrate your own HDL modules right into IPI diagram, and you don't have to use AXI bus for that - through that bus obviously greatly expands your connectivity options. I use this approach all the time because you don't have to mess around with connecting wires manually. The only limitation is that current SystemVerilog modules can not be added, so you will have to write a Verilog wrapper for any SV code you might have in order to add them into IPI diagram.

    Also you can create multiple diagrams within the same project - either for reusing common sub-blocks (though you can create logical sub-blocks within single diagram too), or - how I use it most often - for simulating my own HDL modules which have AXI bus interface, as AXI Verification IP allows you to check AXI compliance and easily simulate whatever AXI transaction you need, or it can simulate a memory which is "visible" to the simulation testbench such that you can inject some predefined data if that what you need (this is handy if you work on a module which need to have some sort of DMA capability). These additional diagrams can be used for simulation only, or for both simulation and actual hardware design.

    So, yeah, this is what professional do - they learn their tools instead of blaming them. Only amateurs blame their tools.

    Thanks @asmi for sharing the details about simulation sets. Very useful. Can you point to where I can learn more about AXI?

×
×
  • Create New...