Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 335 subscribers
  • Views 635 views
  • Users 0 members are here
Related

non-AXI IP from verilog

Former Member

Hi,

I'm struggling with several issues integrating my own verilog code into my design. After days of google search I seems cannot find the right answer to my problem. I browsed through the HW tutorial topics but they do not seem to cover PL only IPs. Could you provide some insights or direction for me to look at?

My goal is to receive data from external LVDS parallel transmitter and buffer the data into DDR3 memory. Currently I decided to test the deserializer and encoded sync detector first before moving onto AXI-DMA buffering. I already have a verilog file with satisfactory behavior simulation done. But now I want to get timing simulation, package it into an IP and testing it on PL without buffering data. (Essentially making uZed only using FPGA part)

So here's a list of problem:
1. How to make ports in a module internal to FPGA?
When I run synthesis and implementing, vivado automatically assign all my ports to a package pin. And of course, a lot of errors are generated due to this. Is there a way I can make only the differential inputs to package pins while leaving the rest as buses or lines to FPGA?

2. Timing sim with external hardware behavior
The vendor provides a verilog emulator simulating the LVDS emitter. But it's not synthesizable since it's external hardware. Is there a way to feed the behavior sim from the emulator and check the timing sim of my receiver code?

3. Flip P/N for differential pair
Due to PCB layout constraints, all my pairs are swapped. I know applying a XOR mask would solve data pair swap problem. But what about CLK pair? Is there a built in inverter for BUFR or differential clock input buffer?

I know this is quite long but I would greatly appreciate your help!

  • 0

    Hi there,

    First, the Zynq part is a processor first, chip.  You will need to have that running at some point.  The FPGA component cannot load without that running, even if it is only a bare metal load.

    Developing the PL only is the same as developing any other FPGA hardware.  There is nothing special about it, except that you will need to incorporate the PS at some point in order to load the FPGA upon power up.

    Are you certain you need timing simulation?  From what I remember about your design, I think you are going to spend a LOT of time on something that is really not necessary.  Physical Timing (in my experience) is not typically performed in the industry due to the capability of modern FPGAs.  I would say that you really do not need this unless you are working with IBIS models of the hardware.

    To answer your specific questions:
    1) You make ports just like you would with any other FPGA design.  Define your entities and port maps, then wire together with the proper assignments.  Again, there is nothing special about using a PL only design when using Zynq.  Only when you start working with AXI.  To assign pins, have a look at our master constraints file.  That is how we recommend doing this.  Start with that file and modify it to suit your needs.
    You can find the file here: http://microzed.org/support/documentation/1519
    Search: "Programmable Logic Master User Constraints"
    If you are using a carrier card, please use the master constraint file listed for that carrier card.

    2) Again, I would not personally spend the time on this.  It is much more efficient to model the timing constraints in the system than it is to try to do a full hardware sim (if you even have the license for that).  Proper constraints will get you more than spending the time with a full hardware timing simulator.  Since you have a logical model, I would wire that into a simulation top level and then have that top level use your project code.  Then, when you build for simulation you use the simulation top.  When you build for real, use the correct TOP.  I've also seen this done with defines - however that generally ends up more complex due to file management issues.

    3) If you setup the clock wrong, I would suggest you use the PLL / MMCM to shift the clocks out of phase.  However, this starts to cause problems with timing constraints unless you match all your internal logic.  Depending on how "full" your design is, you might get away with using a NOT for your internal logic - however that starts to make things even more complex from a timing constraint issue.  My suggestion is to add comments and swap the logic in your HDL then use the phase shifted clock on your pins.  Again, this will make creating timing constraints challenging.  Be really careful when writing them!

    --Dan

  • 0 in reply to drozwood90

    Hi Dan,

    Thanks for your reply.

    I managed to get it running without trying to do timing simulation at 160MHz DDR. But pushing it further causes error. I do not have timing constraints at this moment yet.

    For number 3, I figured out by setting the IDDR to "opposite_edge" then the data is correctly receive. In the meantime, this also flips the sampling clock edge to rising edge expected in downstream AXI-stream interface!

    I'll update more on number 1 afterwards.

    Thanks!

  • 0 in reply to Former Member

    Hi there,

    Glad to hear things are looking well for you!  If you do not have constraints, I would not have expected it to run very well over 25MHz, if it even got that far enough to run to 100MHz.  Since you are running 160MHz, I HIGHLY suggest you get constraints in there.  Remember, you are configuring hardware, so the more you add the more it will change.  Just because it is running now, does NOT mean it will run the next time you build.  With constraints, it directs the hardware placer to ensure timing critical hardware is placed in such a way that it WILL work reliably.

    Without those, it is more or less random.  Although Vivado has some advanced place and route capabilities, you are severely handicapping it by not telling it the information it needs in order to do it's job.

    Again, I am glad things are working out!  Keep at it!

    --Dan

  • 0 in reply to drozwood90

    Hi Dan,

    Thanks for the comment. I just got the image successfully transferred to PS DDR3. A simple async stream data FIFO transits the 2 clock domain without problem. At this moment I need to address 2 issues.

    1. The AXI DMA has a transfer size limitation of 2^23 -1 bytes, or 1 byte short of 8MB in direct register mode. Since a 4K image in raw format will well exceed 24MB, is there anyway to circumvent this without resorting to Scatter Gather or VDMA? I'm not sure letting CPU handling the transfer complete interrupt to initiates another transfer will be faster enough to avoid FIFO overflow. BTW, I'm not sure why this 23bit limitation is there in the first place.

  • 0 in reply to drozwood90

    2. The bandwidth from the CMOS sensor can almost reach 1500MB/s. But the AXI DMA only specifies 300MB/s at 100MHz for S2MM channel. Supposedly I scale it to 150MHz and 64bit channel, it will still only be 900MB/s. That is still much short of 1.5GB/s required.

    I wonder why S2MM channel only has 75% of theoretical bandwidth compare to almost 99% usage of MM2S. Is there anyway to further improve this? The DDR1066 should be able to handle 4GB/s peak transfer rate which should not be a problem.

  • 0

    Hi there,

    It seems that you might want to ask Xilinx about the behavior of the chip.
    The Series 7 forums are located here:
    https://forums.xilinx.com/t5/7-Series-FPGAs/bd-p/7Series

    --Dan