jamey.hicks

Members
  • Content Count

    67
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Like
    jamey.hicks got a reaction from charlieho in How to connect an external FIFO to FPGA   
    I'm going to echo @xc6lx45 and suggest that you reconsider. Does your Kintex have insufficient BRAM for an on-chip FIFO? Using BRAM would be so much easier.
    If you choose to use the external FIFO, you'll have to adapt the logic that you use to interface to the FIFO to use the signaling of this other FIFO.
    Sometimes it helps to post more context: what do you want the system to be able to do that it does not now?
  2. Like
    jamey.hicks got a reaction from sourav in FMC LPC   
    I don't know if any of the FMC pins connect to XADC, so pretty much all the signal pins are digital.  Some are capable of differential signaling and some are routed for clocks.
    The reason I suggest the schematics rather than the FMC spec is that it depends on what kind of FPGA pin the FMC connector pin is connected to. According to the FMC spec, LAXY_P and LAXY_N would be a differential pair, but they might not be connected to a differential capable pair of pins on the Zedboard.
    Furthermore, it's safest to develop basic FPGA logic and provide an xdc constraint file with the desired pinout and ensure that Vivado can place and route your design with the desired pinout before you build a PCB with an FMC connector.
  3. Like
    jamey.hicks reacted to xc6lx45 in Vivado slowness reality check   
    For comparison: My labToy project on CMOD A7 35 builds in 3:40 min (excluding clock IP, measured on my wristwatch by resetting synthesis, then "generate bitstream").
    It's not a large project - about 20 % of DSP used and slices touched - but not trivial either.
    A hello-world project compiles in maybe 1 min, give or take some. But my desktop was built for the job (water-cooled i7 4930 @ 4.5G, 32G quad-channel RAM, M2 SSD).
    Most of this doesn't help with a one-LED design, but there are a number of things that will slow down the run considerably:
    - Use correct timing constraints:
    For example, a LED driven from logic clocked at 200 MHz can be very difficult to route (but at the 12 MHz crystal frequency it shouldn't matter much).
    A simple
    set_false_path -to [get_ports LED] makes it "don't-care".
    - Throw in extra registers where appropriate, especially between blocks (which tend to be physically separate). Most of the time, it does not matter whether the signal arrives one or two clock cycles late, and some spare registers will simplify implementation. This is especially useful for register rebalancing.
    - For the extra registers, it may make sense to use a "don't touch" attribute. E.g. in Verilog:
    (* DONT_TOUCH = "TRUE" *)reg [5:0] wa [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg [17:0] wd [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg we [1:NWRDELAY]; When I have multiple, parallel instances of a timing-critical block, the input registers are logically equivalent, get optimized away, and then P&R takes ages because timing is so difficult. The "don't touch" attribute" keeps them separate, possibly using a couple of FFs more than strictly necessary.
    - Removal of redundant logic can take a long time. For example, when I simulate pipelined DSP like the "labToy" generators I simply carry all data all the way through the pipeline, even though most of it isn't needed. Optimization will eventually remove it, but the cost is runtime. The LabToy example includes 8 instances each with a 6-lane 14-cycle 18-bit wide pipeline, and it adds minutes to the synthesis time if I don't remove the unused ends of delay chains in the source code.
    - Read and understand every warning, and read the timing report. "The compiler is my friend"
    For example, with PLL blocks it is easy to create duplicate clocks with the same frequency (one from the constraints file, one from the IP block). Timing analysis tries to (and will eventually) sort out all possible interactions, but it takes a lot of time and can create meaningless but difficult routing constraints.
    - Fix "critical warnings" related to timing. Even if common sense tells the design will work e.g. classroom demo with buttons,  Vivado will waste a lot of time trying the impossible.
     
     
     
     
  4. Like
    jamey.hicks reacted to JColvin in Pin mapping for JTAG-SMT2-NC?   
    Hi @Sarah,
    Based on the JTAG SMT2 Reference Manual, the GPIO can be used for a number of applications, though the usual application for the GPIO2 would be to connect to the PS_SRST_B pin in Zynq based devices as you have noted. We (Digilent) do not have the timing information about when the Xilinx tools use this pin to reset the Zynq's processor core at various times during debugging operations, though it looks like Xilinx does have a little bit more information about it in their Zynq-7000 Technical Reference Manual here as well as some additional documentation for Zynq devices here.
    Thanks,
    JColvin
  5. Like
    jamey.hicks got a reaction from gwideman in Vivado slowness reality check   
    Vivado is not fast, but it's a big improvement over its predecessor (Xilinx ISE). I found Altera Quartus to be quite slow also.
    You can enable reuse of place and route results when you make small changes to the design and that will save some time during development. It still has to do synth_design and opt_design before reusing placement/routing results, but it does save time.
    Build times increase with design size, but they increase faster if the toolchain has to work hard to try to meet timing constraints.
  6. Like
    jamey.hicks got a reaction from Carson in Xilinx FPGA Spartan 6   
    I've been using a Spartan6 with an FT2232H to program the board via openocd. You need a recent enough version of openocd to have Spartan6 support.
    I believe the Digilent programming module also uses an FTDI chip, in which case openocd should work. If it's an FT2232 there are two JTAG channels. If you try each one you should be able to enumerate and program the FPGA.
    Looks like you need the latest openocd release: 0.10.0
        http://openocd.org/
    I have an Ubuntu package built for amd64 and armhf in the Connectal PPA:
      https://launchpad.net/~jamey-hicks/+archive/ubuntu/connectal
    If it's useful I can have it build the package for other releases or architectures.
    openocd uses libusb, so it will work on OSX and, I believe, Windows.
  7. Like
    jamey.hicks got a reaction from jpeyron in Pmod Wifi board with Basys3   
    Yay! Source! https://github.com/Digilent/vivado-library/tree/master/ip/Pmods/PmodWIFI_v1_0/drivers/PmodWIFI_v1_0
  8. Like
    jamey.hicks got a reaction from Nilakshan in How to use on board USB/UART interface in Zybo?Couldn't find any MIOP pins as mentioned in reference manual   
    I haven't used the JDK on zedboard or zybo, but I did run Android on zedboards and was able to get its GUI to display, which uses quite a bit of Java. Android really needs a GPU, which zynq does not have, so I do not recommend this path for a GUI.
    If JFRAMES works in Ubuntu 16.04, you might be able to run it on the ARM processor of a zybo, if you run Ubuntu on the zybo. In this case, you only need a small program to run on the zybo.
    Another option, if you have some skill with networking, is to run your UI on another machine and stream the data to it over ethernet from the zybo.
    If you know javascript, websockets is a good option for interaction between the GUI and a small amount of code on the zybo.
     
  9. Like
    jamey.hicks got a reaction from shashi in File system in vivado SDK to run on ZED board   
    I don't use the Xilinx SDK because I prefer to run Ubuntu or Android on zedboard, zybo, etc. Ubuntu works really well because so many prebuilt packages are available and it's so familiar to developers.
    With either of these, filesystem access is available as usual.
  10. Like
    jamey.hicks got a reaction from sLowe in Can I program zybo in PS and PL?   
    It sounds like you want a BRAM FIFO rather than a BRAM.
  11. Like
    jamey.hicks got a reaction from JColvin in communication between FPGA and processor in same board   
    1) You target OCM vs DRAM by using different addresses in your AXI read/write requests. Adam Taylor has a blog entry about the OCM address ranges, which are configurable:
       https://forums.xilinx.com/t5/Xcell-Daily-Blog/Adam-Taylor-s-MicroZed-Chronicles-Part-49-Using-the-Zynq-SoC-s/ba-p/518579
    2) Assuming you are reading/writing OCM from applications, you will need to be able to mmap() OCM into your application processes. Are you running Linux on the Zynq PS?
    Here is the Linux driver for OCM: https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm/mach-zynq/zynq_ocm.c
    3) Once you get the previous two parts working, it should be just like communicating through DRAM but with lower latency and probably higher bandwidth. But if there are other parts you have questions with, please post the questions here.
  12. Like
    jamey.hicks got a reaction from D@n in Version control of Vivado projects   
    I find it difficult to work with VIvado project files. When I have tried to use on that has been checked in there have been problems about absolute paths that are incorrect when I check out the project.
    For that reason and others, I use a non-project flow with Vivado and actually do not generate .xpr files. My Tcl scripts use "in memory projects". This style fits my approach to things and allows me to redirect temporary files to subdirectories so it is easy to keep track of which files to commit.
    I have not tried Digilent's generate_project script. My tcl scripts are in https://github.com/cambridgehackers/fpgamake in case they are helpful.
    Looks like Digilent has two Github "organizations". I found the create_project.tcl script, so I can answer your question about what to check in. If you follow this style, you do not have to commit any file that is created by Vivado. They're all reproducible from the original sources and tcl script.
    If you use IP cores or IP integrator after creating a project, you may want to commit files under project.srcs. I tend to copy the commands that generated the cores or board design from the vivado.jou file into the project creation Tcl script.
  13. Like
    jamey.hicks got a reaction from JColvin in Running Vivado from the command line   
    I almost always run Vivado in scripted mode. It's so much more convenient that way. And Vivado is so much better than ISE.
    I use Vivado in GUI mode to add or use the integrated logic analyzer. It is possible to instantiate integrated logic analyzers from scripts, but the GUI is required to use it.Here is a simple script that should do what is requested:
    create_project $module -in_memory -part $partname add_files file.vhd read_xdc file.xdc synth_design -name $module -top $module -part $partname write_checkpoint -force $module-synth.dcp link_design opt_design place_design write_checkpoint -force $module-place.dcp phys_opt_design route_design write_checkpoint -force $module-routed.dcp report_timing_summary write_bitstream $module.bit  
      Caveat: I have not tested this particular script and I do not write vhdl. I usually run synthesis and implementation with separate invocations of vivado because I use a hierarchical flow, synthesizing multiple netlists per design. The scripts I use are in fpgamake: https://github.com/cambridgehackers/fpgamake/blob/master/tcl/synth.tcl and https://github.com/cambridgehackers/fpgamake/blob/master/tcl/topdown.tcl which are synthesis and implementation scripts that are more comprehensive.
    The VIvado tcl commands documentation is pretty good: http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug835-vivado-tcl-commands.pdf
     
  14. Like
    jamey.hicks reacted to grf in Moving to Linux   
    Hey Jamey Hicks
    Thanks for your   https://github.com/cambridgehackers/fpgajtag project.  I have been hacking on it to try to solve my issue with djtgcfg issues on an Anvyl board. 
    fpgajtag recognized my Anvyl board straight after a build. 
    I have some 'patches' to allow it to recognize basys2 and nexys3 boards if you would like them. 
    I presume that that the fpgajtag tool is not intended to be 'Series 7 Only', but that testing has been limited to Series 7, is that a fair assessment?
    Gary  
     
  15. Like
    jamey.hicks got a reaction from grf in Moving to Linux   
    Speaking of third party solutions, we have an open-source utility for programming Xilinx FPGAs. It starts up and runs faster than the Xilinx tool and only requires libusb in order to run. It works from Linux and Mac. It appears there is a libusb for Windows, so someone could probably get it working on Windows also. We're always happy to see a pull request.
       https://github.com/cambridgehackers/fpgajtag
     
     
  16. Like
    jamey.hicks got a reaction from JColvin in Moving to Linux   
    Speaking of third party solutions, we have an open-source utility for programming Xilinx FPGAs. It starts up and runs faster than the Xilinx tool and only requires libusb in order to run. It works from Linux and Mac. It appears there is a libusb for Windows, so someone could probably get it working on Windows also. We're always happy to see a pull request.
       https://github.com/cambridgehackers/fpgajtag
     
     
  17. Like
    jamey.hicks got a reaction from JColvin in Modifying BRAM initial value quickly   
    The initial value is stored as a bunch of properties. You can load the design into Vivado, use set_property to modify the initial values, and then generate a new bitstream without doing any other steps.
    I have done this sort of thing with MMCM to modify generated clock frequencies, but have not done it with BRAMs. However, the principal is the same so I expect it to work.
     
  18. Like
    jamey.hicks got a reaction from a2retro in General Vivado question   
    I find Vivado to be so much better than ISE that I won't work with any devices it does not support. Before Arty, there was a pretty big price gap between Spartan boards and Artix boards, but now I would say use Vivado as much as possible.
    Licensing-wise, I think Vivado and ISE are comparable. Vivado webpack will work with Zedboard and Zybo, and typically other Xilinx boards come with device-locked licenses for those boards.
  19. Like
    jamey.hicks got a reaction from Count0 in Moving to Linux   
    I have also had lots of problems with VirtualBox crashing. In my case, that was on a Mac OS X host, but it was only doing file I/O. I found VMWare and Parallels to be much more robust than VirtualBox.
  20. Like
    jamey.hicks got a reaction from delfy in [Help]. Digilent FMC with Zedboard Designing Architecture   
    Which FMC board did you buy? If it was the Zynq Video and Imaging Kit then this app note describes a reference design that sounds like a good starting point.
    http://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/14_5/UG926_Z7_ZC702_Eval_Kit.pdf
  21. Like
    jamey.hicks got a reaction from LDS in LDS   
    Hi Rex,
    BRAM is loaded from the FPGA configuration bitstream along with the logic, so the block RAM will be loaded when the board powers up.
    Jamey
     
  22. Like
    jamey.hicks got a reaction from Alejandro Wolf in Zybo: Linaro/Archlinux and physicall memory buffers   
    Hi Alejandro,
    Use DMA: I kind of know how to use DMA on baremetal on the software side, but I have no idea how to make a custom IP that comunicates with the DMA modules. I have a decent understanding how master and slave AXI full interfaces works tough. By "Use DMA", I assume you mean the central DMA controller, since you already have AXI masters that can read and write system DRAM via the HP ports. I do not think this approach will solve any problems for you, because you still would need a way to allocate memory to use as buffers.
    Write a custom driver that works the way my IP needs. We wrote a couple of fairly generic device drivers. One simplifying assumption we made was to add address translation to our hardware. It's pipelined and it is not very big, but it's implemented in Bluespec System Verilog so you might not be able to use it. However, the design is simple, so I do not think it would take you long to implement something similar.
    The MMU is simplified because portalmem allocates the largest physically contiguous regions it can, starting at 2^8 pages, then 2^4 pages, then single pages.
    The first driver we have is portalmem, which enables user-space programs to allocate dma-bufs. Each memory region allocated has a corresponding file descriptor, so the regions can be passed between processes atomically and memory-mapped. Also, the file descriptor can be passed to an FPGA device driver, which can get the virtual->phys mapping for the region as a scatter-gather list.
    The second driver is zynqportal, which passes the scatter-gather address translation info to the hardware. It also enables user-space to mmap the hardware registers and wait for interrupts via the poll() system call. This driver depends on just a few registers being implemented in the logic plus a command and response FIFO to interact with the MMU.
    In case this is helpful, here are pointers to the drivers and the MMU:
    https://github.com/cambridgehackers/connectal/blob/master/drivers/portalmem/portalmem.c
    https://github.com/cambridgehackers/connectal/blob/master/drivers/zynqportal/zynqportal.c
    https://github.com/cambridgehackers/connectal/blob/master/drivers/bsv/MMU.bsv
    Hack with things like dma-mapping, contiguous memory allocations, memory maps, etc. I looked for a way to do DMA from user-space but did not find it. Did I miss something?
    Make a "don't touch" region of ram for Linux, so the HW can work with it. I do not know how many memory regions you need to allocate, but the simplest way to get contiguous physical memory from the kernel is to reserve it off the top, passing "mem=xxx" in the kernel cmdline, where "xxx" is less than the amount of memory on the board.
     
  23. Like
    jamey.hicks got a reaction from JColvin in Zybo won't boot from SD card   
    I believe you need a partition marked bootloader in your boot.bin so that the ROM-based firmware knows which software to run.
    The FSBL configures some of the CPU peripheral registers. If you use your own firmware instead of the FSBL, you will need to ensure that you configure everything that you need.
  24. Like
    jamey.hicks got a reaction from JColvin in Turn off Networking support in Linux Kernel   
    It looks like you found a missing dependence in CONFIG_RPMSG which has not been found before because very few people build Linux kernels without networking support.
     
    I believe if you deselect RPMSG in menuconfig you will be able to build a kernel. The configuration for it is under drivers somewhere.
     
    For extra points, you could make a patch that adds "depends on NET" to the config RPMSG entry in drivers/rpmsg/Kconfig and send that to the Linux kernel mailing list or to the maintainer of RPMSG.
  25. Like
    jamey.hicks got a reaction from JColvin in Basys 3: Error when implementing project   
    Do you have location constraints for those ports? I think that message usually just means you haven't assigned locations.