Vivado HLS 2015.x config_interface -register_io

Hello!
In VHLS 2015.x there is new option: config_interface -register_io. From User guide it is not clear to what types of interface this option can be applied though. Can you confirm that this option can be applied to ap_bus m_axi interface signals? If yes does this mean that AXI Register Slice core is additiobally inserted on this m_axi interface? 
I am using Virtex-7 2000t device and trying to fight timing issues in my hls core by flourplanning hls core to different SLR. HLS core has AXI master interface to AXI bus with external DDR memory. All AXI bus components including AXI Interconnect IP and DDR3 MIG core are flourplanned to SLR1 and HLS core to SLR2. I know that it is critical to register all nets that cross SLR boundary on both sides of it. I can insert AXI register slice on AXI Interconnect IP  port and I what to do the same on HLS side. 
If config_interface -register_io can not do what I want my second thought was to add one more AXI Interconnect IP on HLS side inserting AXI register slice on port that is to connect to main AXI Interconnect.
What can you suggest?  
 

Thanks for the reply.
Took a while to test your suggestion.
axi mmu was not enough to change the behavior of the address editor.
Still, I failed to have my AXI master interfaces capable of 64 bit addressing.
The axi master should support 64 bits for the axi_mmu to map 64bit addresses.
Though, Vivado (address editor) thinks my module has only 32bit aw_addr / ar_addr channels, even though I do have 64bit aw_addr / ar_addr channels.
Actually,
My goal was to provide a DMA64 (high memory DMA in other cases)capability to a prototype DRAM based SSD on the VC709 board.
This function was required in order to eliminate the need of bounce buffers (bouncing high memory buffers into DMA'able addresses via memcpy & stuff) in the host side.
In this case, the AXI master is my module, accessing to the axi pcie axi slave port, looking at axi2pci apertures.
I had to access axi2pci apertures which has axi addresses mapped way above 0xFFFF_FFFF (something like 0x0001_0000_0000_0000 ~ 0x0001_FFFF_FFFF_FFFF axi2pci apertures, to access host side DMA addresses such as 0x0000_0003_EC0B_0000)
During the way, I failed to address axi2pci above 32 bits even though I gave "config_interface -m axi_addr64" with my HLS module.
Eventually I managed to use the axi datamover IP, or axi cdma IP in order to achieve my goals, since the IPs were capable of addressing 64 bit axi addresses.
Though I am still wondering about 64 bit address generation in HLS.  Actually what happens when we apply "config_interface -m axi_addr64" directive. 
If it worked as I intended, I could have made AXI4 mm transactions directly from my HLS code.
Regards,
Woong.
 

Similar Messages

  • Rtl co simulation licensing issue with vivado hls 2015.2

    ERROR: [Simtcl 6-50] Simulation engine failed to start: A valid license was not found for simulation. Please run the Vivado License Manager for assistance in determining which features and devices are licensed for your system.
    I am using 30 day evaluation, c simualtion and c synthesis are workikng but rtl cosimulation not working

    Hi
    Vivado evaluation license includes HLS license.
    http://www.xilinx.com/products/design-tools/vivado/vivado-webpack.html
    Please attach the license file along with report_environment.

  • GEP is not of right type for indices! [Vivado HLS 2014.4, 2015.2, synthesis internal error]

    [Vivado HLS 2014.4, 2015.2, synthesis internal error]
    Hello,
    I am randomly getting an error "GEP is not of right type for indices". (check the included files)
    Some time it is presented as internal error sometimes GEP error appears.
    If i reset vivado HLS error disappears dissapear and if i run synthesis again it works.
    But problem is not the interface itself. Design is top big to share (and quite unusual with very specific needs). I would like to make a sample, but i don't know what error means and I don't know what causing the issue.
    Did anyone met this error?
    Does anyone have any idea what is causing the problem? (If i find out, I will make a samle. )
    explanations for types in sources:
    descrFifo_r and descrFifo_w are instances of Multififo and  all arrays are defined with
    #pragma HLS ARRAY_PARTITION variable=xx complete dim=1
    multififo is implementation of multichannel  fifo it to same block ram in one cycle only one channel can write and only one can make read request and only one can collect delayed data
    It is tested and works in HW
     

    Hello,
    Thank you debrajr you gave me hope that that issue is fixable.
    I removed associated ARRAY_PARTITION directives, it did not help.
    I used script to remove all ARRAY_PARTITION directives and error seems to be the same.
    So i tried to remove all the pragma and result is still same.
    (If i compile my code, it runs with 0 Valgrind errors/warnings, so there is not pointer mismatch or any other problem of this kind, from c++ point of view, everythink seems to be OK)
    But I found line, which causes the bug.
    From some reason sometimes reading from MultiFifo<...>.bm_rd.dout fail with this error.
    Today I found that sometimes I accidentaly read from very different output interface (not even connected with Multififo<>), I have fixed this section I did not met any synthesis errors for long time, that could mean that the issue was this impossible access on this interface.
    Is there some way to let Vivado HLS write out all internal problems? Somethink like debugmod?
    Is there way to write for example top 10 critical paths ? It would be really helpfull.
    It tooks me nearly 3 days to debug this and this project is small (just ~1500 lines of code)....
    Problem fixed for now.
     

  • How to use vivado hls::mat with AXI-Stream interfaces (not AXI4 video stream) ?

      Hello, everyone. I am trying to design a image processing IP core with vivado hls 2014.4. From xapp1167, I have known that video functions provided by vivado hls should be used with AXI4 video stream and VDMA. However, I want to write/read image data to/from the Ip core through AXI stream interfaces and AXI-DMA for some special reasons.
      To verify the feasibility, a test IP core named detectTest was designed as follows. The function of this IP core is reading a 320x240 8 bit gray image (bit 7-0 of INPUT_STREAM_TDATA) from the axis port "INPUT_STREAM” and then output it with no changes. I fabricated a vivado project of zedboard and then test the IP core with a AXI-DMA. Experimental results show that the IP core works normally. So it seems possible to use hls::mat with axis. 
    #include "hls_video.h"
    #include "hls_math.h"
    typedef ap_axiu<32, 1, 1, 1> AXI_VAL;
    typedef hls::Scalar<HLS_MAT_CN(HLS_8U), HLS_TNAME(HLS_8U)> GRAY_PIXEL;
    typedef hls::Mat<240, 320, HLS_8U> GRAY_IMAGE;
    #define HEIGHT 240
    #define WIDTH 320
    #define COMPRESS_SIZE 2
    template<typename T, int U, int TI, int TD>
    inline T pop_stream(ap_axiu<sizeof(T) * 8, U, TI, TD> const &e) {
    #pragma HLS INLINE off
    assert(sizeof(T) == sizeof(int));
    union {
    int ival;
    T oval;
    } converter;
    converter.ival = e.data;
    T ret = converter.oval;
    volatile ap_uint<sizeof(T)> strb = e.strb;
    volatile ap_uint<sizeof(T)> keep = e.keep;
    volatile ap_uint<U> user = e.user;
    volatile ap_uint<1> last = e.last;
    volatile ap_uint<TI> id = e.id;
    volatile ap_uint<TD> dest = e.dest;
    return ret;
    template<typename T, int U, int TI, int TD>
    inline ap_axiu<sizeof(T) * 8, U, TI, TD> push_stream(T const &v, bool last =
    false) {
    #pragma HLS INLINE off
    ap_axiu<sizeof(T) * 8, U, TI, TD> e;
    assert(sizeof(T) == sizeof(int));
    union {
    int oval;
    T ival;
    } converter;
    converter.ival = v;
    e.data = converter.oval;
    // set it to sizeof(T) ones
    e.strb = -1;
    e.keep = 15; //e.strb;
    e.user = 0;
    e.last = last ? 1 : 0;
    e.id = 0;
    e.dest = 0;
    return e;
    GRAY_IMAGE mframe(HEIGHT, WIDTH);
    void detectTest(AXI_VAL INPUT_STREAM[HEIGHT * WIDTH], AXI_VAL RESULT_STREAM[HEIGHT * WIDTH]) {
    #pragma HLS INTERFACE ap_fifo port=RESULT_STREAM
    #pragma HLS INTERFACE ap_fifo port=INPUT_STREAM
    #pragma HLS RESOURCE variable=RESULT_STREAM core=AXI4Stream metadata="-bus_bundle RESULT_STREAM"
    #pragma HLS RESOURCE variable=INPUT_STREAM core=AXI4Stream metadata="-bus_bundle INPUT_STREAM"
    #pragma HLS RESOURCE variable=return core=AXI4LiteS metadata="-bus_bundle CONTROL_STREAM"
    int i, j;
    for (i = 0; i < HEIGHT * WIDTH; i++) {
    unsigned int instream_value = pop_stream<unsigned int, 1, 1, 1>(INPUT_STREAM[i]);
    hls::Scalar<HLS_MAT_CN(HLS_8U), HLS_TNAME(HLS_8U)> pixel_in;
    *(pixel_in.val) = (unsigned char) instream_value;
    mframe << pixel_in;
    hls::Scalar<HLS_MAT_CN(HLS_8U), HLS_TNAME(HLS_8U)> pixel_out;
    mframe >> pixel_out;
    unsigned int outstream_value = (unsigned int) *(pixel_out.val);
    RESULT_STREAM[i] = push_stream<unsigned int, 1, 1, 1>(
    (unsigned int) outstream_value, i == HEIGHT * WIDTH - 1);
    return;
      Then I tried to modify the function of detectTest as follow. The function of the modified IP core is resizing the input image and then recoverying its original size. However, it did not work fine in the AXI-DMA test. The waveform captured by chipscope show that the ready signal of INPUT_STREAM was cleared after recieving servel pixels. 
    GRAY_IMAGE mframe(HEIGHT, WIDTH);
    GRAY_IMAGE mframe_resize(HEIGHT / COMPRESS_SIZE, WIDTH / COMPRESS_SIZE);
    void detectTest(AXI_VAL INPUT_STREAM[HEIGHT * WIDTH], AXI_VAL RESULT_STREAM[HEIGHT * WIDTH]) {
    #pragma HLS INTERFACE ap_fifo port=RESULT_STREAM
    #pragma HLS INTERFACE ap_fifo port=INPUT_STREAM
    #pragma HLS RESOURCE variable=RESULT_STREAM core=AXI4Stream metadata="-bus_bundle RESULT_STREAM"
    #pragma HLS RESOURCE variable=INPUT_STREAM core=AXI4Stream metadata="-bus_bundle INPUT_STREAM"
    #pragma HLS RESOURCE variable=return core=AXI4LiteS metadata="-bus_bundle CONTROL_STREAM"
    int i, j;
    for (i = 0; i < HEIGHT * WIDTH; i++) {//receiving block
    unsigned int instream_value = pop_stream<unsigned int, 1, 1, 1>(INPUT_STREAM[i]);
    hls::Scalar<HLS_MAT_CN(HLS_8U), HLS_TNAME(HLS_8U)> pixel_in;
    *(pixel_in.val) = (unsigned char) instream_value;
    mframe << pixel_in;
    hls::Resize(mframe, mframe_resize);
    hls::Resize(mframe_resize, mframe);
    for (i = 0; i < HEIGHT * WIDTH; i++) {//transmitting block
    hls::Scalar<HLS_MAT_CN(HLS_8U), HLS_TNAME(HLS_8U)> pixel_out;
    mframe>>pixel_out;
    unsigned char outstream_value=*(pixel_out.val);
    RESULT_STREAM[i] = push_stream<unsigned int, 1, 1, 1>((unsigned int) outstream_value, i == HEIGHT * WIDTH - 1);
    return;
      I also tried to delete or modify the following 2 lines in the modified IP core. But the transmitting problem existed too. It seems that the IP core cannot work normally if the receiving block and the transmitting block in different "for" loops. But if I did not solve this problem, the image processing functions cannot be added into the IP core either. The document of xapp1167 mentioned that " the hls::Mat<> datatype used to model images is internally defined as a stream of pixels". Does that caused the problem? And how can I solve this problem? Thanks a lot !
    hls::Resize(mframe, mframe_resize);
    hls::Resize(mframe_resize, mframe);
     

    Hello
    So the major concept that you need to learn/remember is that hls::Mat<> is basically "only" an hls stream -- hls::stream<> -- It's actually an array of N channels (and you have N=1).
    Next, streams are fifos; in software that's modeled as infinite queues but in HW they have finite size.
    The default value is a depth of 2 (IIRC)
    in your first code you do :
    for all pixels loop {
      .. something to read pixel_in
       mframe takes pixel_in
       pixel_out is read from mframe
       .. wirte out pixel_out
    } // end loop
    If you notice, mframe has never more than one pixel element inside since as soon as you write to it, you unload it. in other terms mframe never contains a full frame of pixel (but a full frame flow through it!).
    In your second coding, mframe has to actually contain all the pixels as you have 2 for loops and you don't start unloading the pixels unless you have the first loop complete.
    Needless to say that your fifo had a depth of 2 so actually you never read more than 3 pixels in.
    That's why you see that the ready signal of the iput stream drops after a few pixels; that's the back pressure being applied by the VHLS block.
    Where to go from there?
    Well first stop doing FPGA tests and chipscope if you did not run cosim first and that it passed.
    you would have done cosim and it had failed - or got stuck - then you would have debugged there, rather than waiting for a bitstream to implement.
    Check UG902 about cosim and self checking testbench. maybe for video you can't have selfchecking so at least you need to have visual checks of generated pictures - you can adapt XAPP1167 for that.
    For your design, you could increased the depth of the stream - the XAPP1167 explains that, but here it's impractical or sometimes impossible to buffer a full size frame.
    If you check carefully the XAPP, the design operates in "dataflow" mode; check UG902 as to what this means.
    In short, dataflow means that the HW functions will operate in parallel, and here the second loop will start executing as soon as data has been generated in the first loop - if you understand, the links between the loops is a stream / fifo, so as soon as a data is generated in the first loop, the second loop could process that; this is possible because the processing happens in sequential order.
    Well I leave you to read more.
    I hope this helps....

  • Cannot launch vivado simulator 2015.1: behav/compile.bat' script "Please check that the file has the correct 'read/write/execute' permissions"

    Hi,
    I'm trying to run a verilog simulation using the vivado simulator 2015.1 on Windows 7.
    I get the following error when I attempt to launch simulation:    
    ERROR: [USF-XSim-62] 'compile' step failed with error(s) while executing 'D:/projects/axi/axi_test_system/axi_test_system.sim/sim_1/behav/compile.bat' script. Please check that the file has the correct 'read/write/execute' permissions and the Tcl console output for any other possible errors or warnings.
    The tcl console repeats the same message, "Please check that the file has the correct 'read/write/execute' permissions"
    I cannot find any problem with the permissions.  I believe that windows will always execute a .bat file.   Within the same project, I can run elaboration, synthesis and implementation without problems. 
    Any idea why the simulation compile script won't run?
    Thanks,
    Ed

    Hi,
    Thanks very much for your detailed reply. These were the right questions based upon what I told you.   
    However, I took the code home last night and ran it on my webpack 2014.2 release.   It still failed, but I got completely different error messages.   These messages correctly pointed me to an undeclared signal in my testbench. Once fixed, the compile worked and the simulator launched. 
    This morning, I fixed the signal name in my 2015.1 setup, and it also compiled and launched correctly. 
    So, the problem wasn't actually related to file permissions.  It seems like the 2015.1 error message may be broken compared to 2014.2.  
    I was running the Vivado GUI, clicking on "Simulate > Run Behavioral Simulation"
    Thanks again for your help. 
    Regards,
    Ed  
      

  • KC705 eval board - Just purchased, but Vivado license shows as 30 day eval only, should be 1 year license

    Hi Xilinx Users,
    We just purchased a few KC705 Kintex-7 FPGA eval boards about one month ago and installed the licenses, but now see that all licenses are for 1 year, except the Vivado license which is for a 30-day trial.
    *The Xilinx web-page that describes this kit states that a 1 year Vivado license is included*
    -Has anyone run into this and knows how to resolve it?
    Thanks in advance for any help!
    Felix
     

    Hello ,
    From the attached xinfo file, it seems that you are having valid license to use the Software for 1 year. The license is permanent with version limit of 2016.07 (July, 2016). To know more about version limit, please check 
    http://www.xilinx.com/support/answers/33770.html
    The feature which is going to expire on 14-Aug-2015 is Vivado HLS and this won't stop you from using other features of Vivado. You can continue with your design.

  • There is a missing letter of Path name or file name when vivado SDK linking object files

    I used vivado SDK 2014.3 to complie the third source code and could get *.o files. But when linking them, there was an error to show that No such file or directory. I found that there was lack of letter in path name of object file.  It's a SDK bug or I don't set up correctly? 
    Thank you for an early answer.

    I tried it in vivado SDK 2015.1, but there was still the same problem. And I found that it was successful if only importing a small part of source code. What is the reason for this situation?

  • HLS IP with multiple outputs

    Hello all,
    I'm currently working with Vivado HLS (2014.4) and am trying to generate an IP with has an generic amount of OUTputs.
    For better explanation I've made an "block-image" (sort of) how it should look like when imported in Vivado (in a Block Design):
    So it gets an array of booleans (preferable generic!) and splits it into "sizeof(bool[])" output signals.
    What I mean with generic is showed in the following picture:
    This is the "utility vector logic"-IP from Vivado. There you can set, if double-clicked, the parameter "CSIZE" which directly sets the size of in- and output arrays to CSIZE.
    I'm trying to achieve something similar:
    I want to Input an array  "in[CSIZE]" and split it into CSIZE output wires!
    Best would be if i would be able to set the parameter CSIZE of my synthesized IP in Vivado, the way it's done in the "utility vector logic" - IP through the Properties menu.
    1) Is this even possible with High Level Synthesis?
    2) If not: Is it possible with a fixed size input array (like in[5]) and then manually set the number of output wires to e.g. 5?
    3) If this is too isn't possible: How does is work to output a boolean array ("Res[9:0]") like it's done in the "utility vector logic"-IP?
    3.1) Which directives would i have to use to achieve this goal?
    Because right now, I don't know how to output a boolean array as signal (it always changes to memory, or if implemented as Pointer it's no output (it's on the left side)
    It should look something like this (analog to "utility vector logic"):
    where in and out are boolean ports.
    Preferable the size of the in- and output array is generic and settable in the Vivado properties menu (like mentioned in the example above)!
    4) Could you give me according c++ code snippets to solve my problems and to achieve my goal?
    My goal is to connect multiple own IP's (theirs clock) with the multiple output ports of the generated IP above (therefore multiple outputs).
    I'm grateful for every answer I get!
    Thank You very much!
    Best regards,
    Tilo

    Hi
    You can't use VHLS to get an IP with parameters;
    To be optimal, a change of parameter would need the generated RTL to change, and at the moment, if you wanted to change your IP then you need to rerun C-synthesis. In other words, VHLS doesn't generate IPs with parameters.
    For the other question , check the use or array partition complete;
    Be aware that outputs have a valid driven interface by default - that's because the outputs may not be valid at every clock cycle when the IP is running.
    An example of what you described might be this clock divider that generates N outputs where gen_clk[i] is input clock divided by (M/rate[i])
    const unsigned int n_outputs = 5;
    void top(unsigned int M, unsigned int rate[n_outputs], bool gen_clk[n_outputs]) {
    #pragma HLS array_partition variable=rate complete dim=0
    #pragma HLS array_partition variable=gen_clk complete dim=0
    #pragma HLS interface ap_none port=gen_clk
    #pragma HLS pipeline
    unsigned int i;
    static unsigned int counter[n_outputs];
    static bool int_clk[n_outputs];
    for(i=0;i<n_outputs;i++) {
    // pipeline (II=1) at top level makes this loop unrolled
    bool clk_enable = counter[i]>M;
    int_clk[i] ^= clk_enable;
    counter[i] = clk_enable ? counter[i]-M: counter[i]+rate[i];
    gen_clk[i] = int_clk[i];
    but be aware that the tool tells you clearly:
    @W [RTGEN-101] Port 'gen_clk_0' with mode 'ap_none' may require an associated data valid signal to correctly communicate with other blocks or a test bench; automatic C/RTL co-simulation may not be able to verify such a port.
    In IPI you may not be able to integrate this as the outputs are not decorated as being of type "clocks".
    I hope this helps.

  • Simulation error : size mismatch in mixed language port association with VIVADO simulator

    Hi,
    I have instantiated a VHDL module in  a verilog top file . When I tried to simulate the verilog top , I received the following error .
    ERROR : Size mismatch in mixed language port association , vhdl port  vid_data
    (Simulation tool : VIVADO simulator . VIVADO ver : 2015.1)
    // Following is the instantiation of  VHDL module in verilog top file
    VPS  VPS_inst 
         .clk (VPS_clk),
         .reset_n(~user_reset),
         .vid_active_video(data_valid),
         .vid_data(data_to_mem)
    The port 'vid_data' is declared in the VHDL module as std_logic_vector (15 downto 0)
    "vid_data   : out std_logic_vector(15 downto 0)"
    'data_to_mem' is declared in verilog top file as  "wire  [15:0]   data_to_mem" . 
    No size mismatch exists actually . But , I am getting the above mentioned error in simulation.
    I have searched for similar threads . Nothing was useful . 
    Does anyone know how to solve this?
    Thanks and Regards
    Raisa
     

    You might also get this error if you mis-spelled "data_to_mem" such that the declaration did not match the instantiation port map.  For example:
    wire  [15:0] data__to_mem;  // double underscore before "to"
    VPS  VPS_inst 
         .clk (VPS_clk),
         .reset_n(~user_reset),
         .vid_active_video(data_valid),
         .vid_data(data_to_mem)  // only one underscore before "to"
    In Verilog this is not an error unless you disable automatic net inference.  In this case Verilog is happy to create a single wire for data_to_mem, but then you would be trying to attach a 1-bit wire to a 16-bit port.  That would also be valid in Verilog, but not allowed for connections to VHDL.
    I typically avoid this sort of error by placing:
    `default_nettype none
    at the top of each Verilog file, and
    `default_nettype wire
    at the bottom of each Verilog file.  This prevents the automatic creation of wires when you mis-spell or forget to declare nets.

  • RE: (HLS) Why does Verilog pointer requires two clocks to get updated??

    In HLS (2015.2), I created a simple comparator circuit. The HLS C-simulation worked fine. The HLS C-function compares
    8-bit integers received from an 8-bit data bus against a fixed array of 8-bit integers. If the first integer matches, a pointer is incremented, and the C-function will then look for the 2nd integer in the array. If the sequence of 8-bit integers on the data
    bus matches the sequence of bytes in the stored array, a  match is detected.
    After observing a good C-simulation, I instantiated the HLS Verilog file code into the original manually generated top-level
    chip Verilog code, and attempted a Modelsim simulation. It did not work!!
    The HLS generated Verilog file has the ports below:
    ap_clk
    ap_rst
    ap_start
    ch(7:0)   <---    This is the incoming 8-bit data bus.
    ch_valid   <----   This is an input that indicates the ch(7:0) data bus has valid data.
    ap_return   <---   This is the match signal.
    If ch_valid is HIGH, the comparator compares ch(7:0) data bus against the known internal fixed array of 8-bit integers. The
    ch(7:0) data bus changes every ap_clk. The problem with the HLS verilog code is that two clock cycles are needed to update the pointer, which points to the next integer in the fixed array. For the HLS circuit to work properly, the ch(7:0) data bus can't change every clock-cycle. The ch(7:0) data bus needs to be stable for 2-clock cycles. The only reason I found this was
    due to the ModelSim simulation. In the C-code below, the fixed array is "pattern0", while the pointer is "check0."
    int compare (uint8_t ch, int ch_valid, int sop)
    uint8_t pattern0[24] = {0xaa, 0xbb, 0xcc, 0xdd, 0x12, 0x34, 0x56, 0x78, 0x11, 0x11, 0x22, 0x22, \
                                    0x33, 0x33, 0x44, 0x44, 0x22, 0x22, 0x33, 0x33, 0x44, 0x44, 0x55, 0x55};
    static int prematch0 = 0, check0 = 0, match0 = 0;
    int j;
    if (ch_valid == 1) {
        if(check0 < sizeof(pattern0)){
             if(ch == pattern0[check0]) {
                prematch0 = 1;
                check0 = check0+1;
             else {
                 prematch0 = 0;
                 check0 = 0;
         else if ((check0 == sizeof(pattern0)) && (prematch0 == 1)) {
              check0 = check0;
              match0 = 1;
              prematch0 = 1;
         else {
              check0 = check0;
              match0 = match0;
              prematch0 = prematch0;
    else {
           check0 = check0;
           match0 = match0;
           prematch0 = prematch0;
    return (match0);
    If I write this code manually in Verilog, the check0 pointer is updated in one clock cycle.
    Questions:
    Why does HLS need two clock cycles to update the check0 pointer?
    Do I need to set an HLS directive to cause the verilog code to be generated in a different way?
    Does the C-code need to be written differently?
    Thanks,
    Roy

    Hi Debraj,
    Thanks for the response. I have another question.
    I quicly took the C-code above and added a Verilog clock statement.  The code below would execute in one clock.
    Is there any way I can re-write the C-code to reduce the 2cc down to 1cc, or is this not possible?
    always @(posedge ap_clk) {
       if (ch_valid == 1) {
           if(check0 < sizeof(pattern0)){
                if(ch == pattern0[check0]) {
                    prematch0 = 1;
                    check0 = check0+1;
                else {
                    prematch0 = 0;
                    check0 = 0;
           else if ((check0 == sizeof(pattern0)) && (prematch0 == 1)) {
                check0 = check0;
                match0 = 1;
                prematch0 = 1;
           else {
                check0 = check0;
                match0 = match0;
                prematch0 = prematch0;
        else {
           check0 = check0;
           match0 = match0;
           prematch0 = prematch0;
    Thanks,
    Roy

  • HLS creates internal clock enable??

    In HLS (2015.2), I created a simple comparator circuit. The HLS C-simulation worked fine.
    The HLS C-function compares 8-bit integers received from an 8-bit data bus against a fixed array
    of 8-bit integers. If the first integer matches, a counter is incremented, and the C-function
    will then look for the 2nd integer in the array. If the sequence of 8-bit integers on the data
    bus matches the sequence of bytes in the stored array (distributed memory Eg. ROM), a  match
    is detected.
    After observing a good C-simulation, I then instantiated the HLS Verilog file code into the actual
    hardware, and attempted a Modelsim simulation. It did not work!! This is a very simple circuit. The
    Verilog file has the ports below.
    ap_clk
    ap_rst
    ap_start
    ch(7:0)   <---    This is the incoming 8-bit data bus.
    ch_valid
    ap_return   <---   This is the match signal.
    If ch_valid is HIGH, the comparator should compare ch(7:0), against the known internal fixed array of 8-bit
    integers. The signal ch(7:0) changes every ap_clk. The problem with the hardware is that HLS
    created an internal clock enable. For this circuit to work, the ch(7:0) bus needs to be stable for
    2-clock cycles. The only reason I found this was because saw what was happening in ModelSim.
    When coding in C, there is no concept of clock. I thought HLS was intended to allow the user to create
    code and to not be concerned with clocks and other hardware events.
    Questions:
    1. Is the purpose of HLS to allow a software programmer to be able code and create hardware, or does an HLS
    programmer need a hardware background?
    2. If the HLS programmer does not need a hardware background, how would a software programmer find
    an internal clock enable?
    3. Is there a switch to prevent HLS from creating code that uses internal clock enables, or does the C-code
    need to written in a certain way?
    Thanks!

    In HLS (2015.2), I created a simple comparator circuit. The HLS C-simulation worked fine.
    The HLS C-function compares 8-bit integers received from an 8-bit data bus against a fixed array
    of 8-bit integers. If the first integer matches, a counter is incremented, and the C-function
    will then look for the 2nd integer in the array. If the sequence of 8-bit integers on the data
    bus matches the sequence of bytes in the stored array (distributed memory Eg. ROM), a  match
    is detected.
    After observing a good C-simulation, I then instantiated the HLS Verilog file code into the actual
    hardware, and attempted a Modelsim simulation. It did not work!! This is a very simple circuit. The
    Verilog file has the ports below.
    ap_clk
    ap_rst
    ap_start
    ch(7:0)   <---    This is the incoming 8-bit data bus.
    ch_valid
    ap_return   <---   This is the match signal.
    If ch_valid is HIGH, the comparator should compare ch(7:0), against the known internal fixed array of 8-bit
    integers. The signal ch(7:0) changes every ap_clk. The problem with the hardware is that HLS
    created an internal clock enable. For this circuit to work, the ch(7:0) bus needs to be stable for
    2-clock cycles. The only reason I found this was because saw what was happening in ModelSim.
    When coding in C, there is no concept of clock. I thought HLS was intended to allow the user to create
    code and to not be concerned with clocks and other hardware events.
    Questions:
    1. Is the purpose of HLS to allow a software programmer to be able code and create hardware, or does an HLS
    programmer need a hardware background?
    2. If the HLS programmer does not need a hardware background, how would a software programmer find
    an internal clock enable?
    3. Is there a switch to prevent HLS from creating code that uses internal clock enables, or does the C-code
    need to written in a certain way?
    Thanks!

  • Max achievable frequency in HLS code

    I am looking for the maximum frequency (smallest clock period) at which I could run the test code that I attach, targetted for Zynq (ZC702). It is the design of a very simple IP block with hls::stream input and output , with an s_axilite control.
    It simply computes two multiplications and the expf function, all in single-precision floating point and inside a pipelined for loop with an initiation interval II=1.
    1) If the solution is set with a clock period of 10.0ns, then synthesis and implementation (export) will meet the timing (I am using Vivado HLS 2014.3). But if I lower it to 5.0ns (as an example), then synthesis expects 4.36ns (uncertainty 0.62ns), but implementation will report 6.011ns and fail. (I am aware that synthesis only estimates the timing).
    2) I have also read the post in the HLS forum regarding "registered stages" and the suggestion of trying "reg(...)" available in #include <hls/utils/x_hls_utils.h>. If I apply this idea, then synthesis estimates 5.29ns (uncertainty 0.62ns), but implementation reports 5.681ns.
    2a) If I only compute the reg( expf (...) );  inside the for loop, then implementation will just achieve 4.990 ns.
    Based on this behaviour, I cannot find a procedure to find out the minimum clock period (max clock frequency) at which the IP block will work. (I cannot keep running implementation (RTL export) for every idea I come up with)
    QUESTION 1: Could you please provide guidance on this regard?
    QUESTION 2: just because the depth of the pipelined for loop increases should not mean that the minimum clock period increases, am I right? (I would expect the tool to automatically register intermediate results accordingly in order to achieve the targetted clock period). Is there an alternative to reg(...), or any other approach I could follow?
    Thanks in advance,
    Javier
     

    hello
    In your code if you think that the FSM is the issue, then you should remove the for loop!
    I'm not joking.. when you remove it, then your IP will have an II of 1 and a latency N; but from your integration perspective, this is almost the same: you still need AXIS IPs to push data to the VHLS IP.
    The fact that your VHLS IP read an unknown number of samples and then stops and has to be restarted in SW doesn't help you. It's a bit of overhead actually.
    If you remove the loop you should find that it goes faster.
    Last point, I don't know what is the F max achievable in the ZC702 's programmable logic but I think that 200 MHz should already be plenty!?
    What is the rest of the design going?

  • Need Urgent Help : Using VIVADO Design Suite for PCI Express 3.0, 8 lane, and AXI Interfaces for Video Processing

    My scenario is as follows :-
    1) I am building a Image Processing Application and using VIVADO HLS for that.
    2) I have synthesized my design using VIVADO HLS, and export it as IP-XACT format.
    3) I have imported it in VIVADO Design Suite, and added to the IP catalog, in a new project created.
    4) Since I am building an image processing pipeline, I am using AXI Stream interfaces, 1 input stream, and 1 output stream, and mentioned that in the HLS tool itself..
    5) I have a Virtex 7 690T FPGA, and have accordingly chosen the board throughout the HLS process, and the project.
    6) We want to use a PCI Express 3.0, through DMA access to the CPU.
    7) Now I am stuck here regarding how to proceed forward, I have gone through most of the Xilinx documentation, but am still not clear about what to do from here on.
    8) There are these 3 variables for me, AXI Stream Interface, DMA, PCI Express 3.0, all I have right now is the IP of the Image Processing pipeline that I generated through VIVADO HLS.
    9) Also at a later stage we would like to stream in Video, and process it through our image processing pipeline.
    Please help me with an overview of steps that I need to follow to get my design together and working on a real FPGA hardware with my Computer(windows OS), as in what Xilinx IP blocks do I need to use, how will I be able to exploit the maximum bandwidth from the PCI Express Interface in my specific case of send image through a stream, what tools will I need to use at every stage.
    I would be highly grateful if you guys can help me, we have a dealine to meet.
    Please let me know if we need any extra information.
     

    School project?

  • Axi Master DDR (MIG) tester

    Hi guys I'm trying to create a DDR stresser on my project, so I created an Vivado HLS IP core that has one axi-master interface and one axi-lite-slave(for parameters) the code is bellow
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    unsigned int memDDR3Tester(unsigned int start, unsigned int size, unsigned int mode, unsigned int data, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors)
    #pragma HLS INTERFACE s_axilite port=numErrors bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=failedAddr bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=expectedVal bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=start bundle=CRTL_BUS
    #pragma HLS INTERFACE m_axi depth=512 port=memPtr
    #pragma HLS INTERFACE s_axilite port=data bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=mode bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=size bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=return bundle=CRTL_BUS
    unsigned int result = 0;
    unsigned int idxMemAddr = 0;
    unsigned int errorCounter = 0;
    *numErrors = 0;
    *expectedVal = 0;
    *failedAddr = 0;
    switch (mode)
    * Send 0xAA55 (16b1010101001010101) or 0x55AA if the address is odd/even
    * write then read and stop on the first error
    case 0:
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    *expectedVal = value;
    *failedAddr = idxMemAddr;
    // Bail out on the first error
    *numErrors = 1;
    break;
    break;
    * Send an incremental value but don't stop if some error occured and return the number of errors
    case 1:
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned int value = idxMemAddr;
    memPtr[idxMemAddr] = value;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned int value = idxMemAddr;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    errorCounter++;
    *numErrors = errorCounter;
    break;
    * Send just a value and read it back
    case 2:
    memPtr[start] = data;
    if (memPtr[start] != data)
    result = 1;
    *expectedVal = data;
    *failedAddr = start;
    break;
    * Send on mode burst (memset) the value 0xAA55 (16b1010101001010101)
    case 3:
    //memset((unsigned int*)memPtr,(int)0xAA55,(size_t)(sizeof(unsigned int)*size));
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    memPtr[idxMemAddr] = 0xAA55;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    if (memPtr[idxMemAddr] != 0xAA55)
    result = 1;
    errorCounter++;
    *numErrors = errorCounter;
    break;
    return result;
    #include <stdio.h>
    unsigned int memDDR3Tester(unsigned start, unsigned int size, unsigned int mode, unsigned int data, volatile unsigned int memPtr[512000000], unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors);
    int main()
    unsigned int memPtr[10];
    unsigned int expectedVal;
    unsigned int failedAddr;
    unsigned int numErrors;
    unsigned int result;
    printf("Test mode 0\n");
    result = memDDR3Tester(0,10,0,0,memPtr,&expectedVal,&failedAddr,&numErrors);
    printf("Result mode 0: %d Expected: %d failedAddr:%d numErrors:%d\n",result,expectedVal,failedAddr,numErrors);
    for (int idx = 0; idx < 10; idx++)
    printf("DDR3[%d]=%x\n",idx,memPtr[idx]);
    return 0;
    The first problem is that I can simulate the on C/C++ but not co-simulate I get those errors:
    Determining compilation order of HDL files.
    INFO: [VRFC 10-2263] Analyzing Verilog file "C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_master_memPtr.v" into library xil_defaultlib
    INFO: [VRFC 10-311] analyzing module AESL_axi_master_memPtr
    INFO: [VRFC 10-2263] Analyzing Verilog file "C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v" into library xil_defaultlib
    INFO: [VRFC 10-311] analyzing module AESL_axi_slave_CRTL_BUS
    ERROR: [VRFC 10-46] write_start_count is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:201]
    ERROR: [VRFC 10-46] write_start_run_flag is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:202]
    ERROR: [VRFC 10-46] write_start is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:738]
    ERROR: [VRFC 10-552] declarations not allowed in unnamed block [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:738]
    ERROR: [VRFC 10-1040] module AESL_axi_slave_CRTL_BUS ignored due to previous errors [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:11]
    ERROR: Please check the snapshot name which is created during 'xelab',the current snapshot name "xsim.dir/memDDR3Tester/xsimk.exe" does not exist
    These are the results for C/C++ simulation:
    Compiling ../../../test_core.cpp in debug mode
    Generating csim.exe
    Test mode 0
    Result mode 0: 0 Expected: 0 failedAddr:0 numErrors:0
    DDR3[0]=aa55
    DDR3[1]=55aa
    DDR3[2]=aa55
    DDR3[3]=55aa
    DDR3[4]=aa55
    DDR3[5]=55aa
    DDR3[6]=aa55
    DDR3[7]=55aa
    DDR3[8]=aa55
    DDR3[9]=55aa
    @I [SIM-1] CSim done with 0 errors.
    Anyway after exporting to vivado and connecting the mig and the microblaze through an Axi Interconnect, I got this: (Artix 7 Avnet demoboard)
    The addresses:
    On Xilinx SDK my code to initialize the core and test it this:
    #include <stdio.h>
    #include <xmemddr3tester.h>
    #include <xparameters.h>
    #include <xil_cache.h>
    XMemddr3tester doMemDDR3Test;
    XMemddr3tester_Config *doMemDDR3Test_cfg;
    #define SIZE_ARRAY 10
    unsigned int *topMemDDR = (unsigned int *)0x80000000;
    void initDDRTester()
    int status = 0;
    doMemDDR3Test_cfg = XMemddr3tester_LookupConfig(XPAR_MEMDDR3TESTER_0_DEVICE_ID);
    if (doMemDDR3Test_cfg)
    status = XMemddr3tester_CfgInitialize(&doMemDDR3Test,doMemDDR3Test_cfg);
    if (status != XST_SUCCESS)
    printf("Failed to inititalize\n");
    int main()
    int idx = 0;
    unsigned int error;
    initDDRTester();
    for (idx = 0; idx < SIZE_ARRAY; idx++)
    topMemDDR[idx] = idx*2;
    printf("DDR3 tester console\n");
    Xil_DCacheFlushRange((unsigned int)topMemDDR,sizeof(unsigned int)*SIZE_ARRAY);
    XMemddr3tester_Set_mode(&doMemDDR3Test,0);
    XMemddr3tester_Set_data(&doMemDDR3Test,0);
    XMemddr3tester_Set_start(&doMemDDR3Test,0x80000000);
    XMemddr3tester_Set_size(&doMemDDR3Test,(unsigned int)SIZE_ARRAY);
    XMemddr3tester_Start(&doMemDDR3Test);
    while (!XMemddr3tester_IsDone(&doMemDDR3Test));
    error = XMemddr3tester_Get_return(&doMemDDR3Test);
    printf("Test done %d\n",error);
    Xil_DCacheInvalidateRange((unsigned int)topMemDDR,sizeof(unsigned int)*SIZE_ARRAY);
    for (idx = 0; idx < SIZE_ARRAY; idx++)
    printf("DDR3[%d]=%x\n",idx,topMemDDR[idx]);
    return 0;
    By some reason it seems that is the data is not been sent to the MIG (I though initialiy that could be a problem with the Cache but it seems that is not the case, anyway I disabled the cache on the microblaze)
    So to resume the questions:
    1) Someone knows what could be wrong on the Co-Simulation
    2) The address autogenerated for the mig is also updated somehow on the HLS core? (I tried to manually set the pointer address on Vivado HLS but it didn't synthesised)
    3) Do you guys seem something wrong on this design?
    4) Can I use the ILA to see the DDR3 interface (Or should I use the "Mark Debug option?)
    Thanks.

    Hi  thanks, I've changed the parameter name and the previous error on the simulation disappeared, but now I have a comsim.pc.exe crash during the C post checkign phase.
    INFO: [Common 17-206] Exiting xsim at Tue Jul 14 10:48:04 2015...
    @I [SIM-316] Starting C post checking ...
    @E [SIM-379] Detected segmentation violation, please check C tb.
    @E [SIM-362] Aborting co-simulation: C TB post check failed.
    @E [SIM-4] *** C/RTL co-simulation finished: FAIL ***
    So what I did was to simplify the IP core more to only send 0xaa55 or 0x55aa on the master interface:
    core.cpp (Used to generate the IP core)
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    // 1Gb limit
    #define MAX_MEM_SIZE 200000
    unsigned int memDDR3Tester(unsigned int size, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors)
    #pragma HLS INTERFACE s_axilite port=numErrors bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=failedAddr bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=expectedVal bundle=CRTL_BUS
    #pragma HLS INTERFACE m_axi depth=512 port=memPtr
    #pragma HLS INTERFACE s_axilite port=size bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=return bundle=CRTL_BUS
    unsigned int result = 0;
    unsigned int idxMemAddr = 0;
    unsigned int errorCounter = 0;
    *numErrors = 0;
    *expectedVal = 0;
    *failedAddr = 0;
    * Send 0xAA55 (16b1010101001010101) or 0x55AA if the address is odd/even
    * write then read and stop on the first error
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    #pragma HLS LOOP_TRIPCOUNT min=256000000 max=256000000 avg=256000000
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    /*if (idxMemAddr > size)
    break;*/
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    #pragma HLS LOOP_TRIPCOUNT min=256000000 max=256000000 avg=256000000
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    *expectedVal = value;
    *failedAddr = idxMemAddr;
    // Bail out on the first error
    *numErrors = 1;
    break;
    /*if (idxMemAddr > size)
    break;*/
    return result;
    test core
    #include <stdio.h>
    unsigned int memDDR3Tester(unsigned int size, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors);
    unsigned int memPtr[20];
    int main()
    unsigned int expectedVal;
    unsigned int failedAddr;
    unsigned int numErrors;
    unsigned int result;
    printf("Test mode 0\n");
    result = memDDR3Tester(10,memPtr,&expectedVal,&failedAddr,&numErrors);
    printf("Result mode 0: %d Expected: %d failedAddr:%d numErrors:%d\n",result,expectedVal,failedAddr,numErrors);
    for (int idx = 0; idx < 10; idx++)
    printf("DDR3[%d]=%x\n",idx,memPtr[idx]);
    return 0;
    But again the simulation on C/C++ works but I have some trouble on the co-simulation part.
    I also tried to change the for loop to hava a fixed constant iteration and on the midle of its code break if the condition size is met:
    // Write
    for (idxMemAddr = 0; idxMemAddr < MAX_MEM_SIZE; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    if (idxMemAddr > size)
    break;
    The problem is that if I try to synthesize this I got this error:
    Stack dump:
    0. Running pass 'Generate interface primitives' on module 'C:/Users/laraujo/ddrStresserVIV_2015/solution1/.autopilot/db/a.o.2.bc'.
    0x000007FEC7CBE4E0 (0x0000000000000003 0x00000000059368D0 0x00000000059368D8 0x0000000002924BF0), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x331210 bytes(s)
    0x000007FEC773080A (0x0000000000000004 0x0000000005553D20 0x0000000006A51FB0 0x00000000001D8200), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A1C3A bytes(s)
    0x000007FEC77300D3 (0x0000000006E80350 0x00000000001D7DC0 0x0000000006A52E60 0x00000000001D81C0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A1503 bytes(s)
    0x000007FEC7732D7A (0x0000000000000000 0x0000000006E819D0 0x0000000005553D20 0x0000000006DBEDD0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A41AA bytes(s)
    0x000007FEC7731385 (0x00000000001D8300 0x00000000001D8410 0x00000000059366F0 0x00000000059366F0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A27B5 bytes(s)
    0x000007FEC7738D25 (0x0000000000000000 0x00000000059366F0 0x0000000000000000 0x0000000000000001), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5AA155 bytes(s)
    0x000007FEC7C56777 (0x0000000000000004 0x0000000006E04480 0x0000000005936460 0x0000000006D8EE90), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x2C94A7 bytes(s)
    0x000007FEC7C557B0 (0x0000000000000004 0x00000000001D8CD9 0x0000000006D8EE90 0x0000000000000000), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x2C84E0 bytes(s)
    0x000007FEC7149148 (0x00000000000011C2 0x00000000001D8CD9 0x0000000000000000 0x000007FEC827CF70)
    0x000007FEEFB2B1A4 (0x000000000235DCC0 0x000000006DED2E12 0x0000000006A303B0 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1F94 bytes(s)
    0x000007FEEFB2D9C9 (0x000000006DF52B18 0x0000000000000096 0x0000000006A3CA50 0x000000006DF1937C), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000096 0x0000000006A3DA50 0x0000000000000096), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x0000000006A3CA50 0x0000000000000096 0x0000000000000096), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DE52A28 (0x0000000000000000 0x00000000023268B8 0x0000000000000001 0x0000000000000002), TclEvalObjEx() + 0x348 bytes(s)
    0x000000006DE5A88A (0x0000000000000000 0x00000000002FD600 0x00000000002FD600 0x0000000000000000), TclDumpMemoryInfo() + 0x340A bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000002 0x00000000023268B8 0x00000000023268B8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A0BCA0 0x000000006DF53178 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000003771A50 0x00000000002FD600 0x000000006DF53178 0x000000006DEE329B), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000000000753 0x0000000000000000 0x0000000000000003 0x0000000000000003), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002326848 0x0000000002326848), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006978220 0x000000000027BE36 0x6666666600000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006A30110 0x00000000002FD600 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000002326800 0x00000000002FD600 0x0000000000000000 0x0000000000000002), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE6909A (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000023267F0), TclDumpMemoryInfo() + 0x11C1A bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000002 0x00000000023267E8 0x00000000023267E8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A3C250 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DF193BD), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000004 0x00000000023265B8 0x00000000023265B8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A46280 0x0000000000000000 0xFFFFFFFF00000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000100000005 0x0000000002326348 0x0000000002326348), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006B2E270 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x00000000023261F8 0x00000000023261F8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A39340 0x0000000002326040 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006BA4660 0x00000000002FD600 0x0000000002325DA0 0x00000000001DBCA0), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000006A2AF20 0x0000000000000000 0x0000000000000003 0x0000000002325FF0), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002326040 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000028FD7AB 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x00000000028FD6D0 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x00000000029335F0 0x00000000029335F0 0x00000000001DC270 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x0000000000000FD5 0x0000000000000FD5 0x00000000029335F0 0x0000000000000FD5)
    0x000007FEEFB2B1F3 (0x0000000006CB7430 0x0000000006A4B554 0x0000000000000001 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DF193BD), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000005 0x0000000002325960 0x0000000002325960), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x00000000058C2F40 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DE93BFC), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002325798 0x0000000002325798), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000005A24060 0x00000000023255E0 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006CB4370 0x00000000002FD600 0x0000000002325340 0x00000000001DD280), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000006CB5120 0x0000000000000000 0x0000000000000003 0x0000000002325590), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x00000000023255E0 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x000000000564D91E 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x000000000564CFB0 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x0000000000275870 0x0000000000275870 0x00000000001DD850 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x00000000000008EB 0x00000000000008EB 0x0000000000275870 0x00000000000008EB)
    0x000007FEEFB2B1F3 (0x0000000000000001 0x00000000069D3448 0x0000000000000001 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000000000000 0x0000000000000001 0x00000000055CDFE0 0x000000006DF193BD), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000009 0x0000000002324ED8 0x0000000002324ED8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000005A86490 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002324D48 0x0000000002324D48), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x00000000033DBBE0 0x0000000002324B90 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x00000000055CC390 0x00000000002FD600 0x00000000023248F0 0x00000000001DE860), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x00000000055CA650 0x0000000000000000 0x0000000000000003 0x0000000002324B40), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002324B90 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000033CBBD1 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x00000000033CBA10 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x0000000000275CD0 0x0000000000275CD0 0x00000000001DEE30 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x00000000000008EB 0x00000000000008EB 0x0000000000275CD0 0x00000000000008EB)
    0x000007FEEFB2B1F3 (0x000000000286D420 0x000000006DED2E12 0x00000000055CCE70 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000005931EF0 0x0000000000000000 0x0000000000000000 0x0000000000000002), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002324370 0x0000000000000001), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000055978F0 0x0000000000000001 0x0000000000000001), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DEBA4F0 (0x00000000002F7FD0 0x00000000002F7FD0 0x00000000002FD600 0x0000000000000000), Tcl_FSEvalFileEx() + 0x250 bytes(s)
    0x000000006DEC5B24 (0x0000000000000001 0x0000000000000008 0x0001F82056300000 0x000000000020C5A0), Tcl_Main() + 0x554 bytes(s)
    0x000007FEEFB2D1F1 (0x0000000000000002 0x0000000000282B3A 0x0077005C00640065 0x000007FEF5AE43B8), ?issue@TclManager@xpcl@@QEAAHHPEAPEAD_N@Z() + 0x371 bytes(s)
    0x000007FEC718FC52 (0x0000000000000000 0x01D0BE1535026984 0x0000000000000000 0x0000000000000000), ?main@Syn@@YAHHPEAPEAD@Z() + 0x1082 bytes(s)
    0x000000013F0B124B (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
    0x00000000776C652D (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s)
    0x00000000778FC521 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
    @E [HLS-102] Encountered an internal error;
    For technical support on this issue, please visit http://www.xilinx.com/support.

  • System generator vivado2014.4-- Cordic 6.0 sincos Error

    Hello,
    I am using Matalb 2013a and system generator set to Vivado 2014.4.
    When i use Cordic core 6.0 in sysgen it works only for default settings (Ex: Input width=16) ands when i change this to 15, it gives me following error. Please help me in resolving this.
    (Note: THis worked for me when i used vivado 2013.4, after upgrading it to 2014.4 i am facing this problem)
    XSim Initialization Error:
    Please make sure that PlanAhead library path, D:/Xilinx/Vivado/2014.4/lib/win64.o, is also added in your LD_LIBRARY_PATH environment.
    XSim engine error: Failed to initialize XSI interface for shared library, C:\Users\Test/AppData/Local/Xilinx/Sysgen/SysgenVivado/win64.o/d78635fddddea05b8799f9713c06fed8/xsim.dir/cordic_v6_control_9b05c557329eca08f3c704b6ded5fce6_behav/xsimk.dll.
    ERROR: XSim shared library, C:\Users\Test/AppData/Local/Xilinx/Sysgen/SysgenVivado/win64.o/d78635fddddea05b8799f9713c06fed8/xsim.dir/cordic_v6_control_9b05c557329eca08f3c704b6ded5fce6_behav/xsimk.dll, doesn't exist.
    Error occurred during "Simulation Initialization".
    Thanks,
    Ashwini

    Having the same problem with Vivado 2015.1/R2015a combination, with Vivado HLS block:
    XSim Initialization Error:
    Please make sure that Vivado library path, C:/Xilinx/Vivado/2015.1/lib/win64.o, is also added in your LD_LIBRARY_PATH environment.
    XSim engine error: Failed to initialize XSI interface for shared library, C:\Users\username/AppData/Local/Xilinx/Sysgen/SysgenVivado/win64.o/921eaf9a7f9e95ffa5dd4669062a19ea/xsim.dir/blockname_behav/xsimk.dll.
    ERROR: XSim shared library, C:\Users\username/AppData/Local/Xilinx/Sysgen/SysgenVivado/win64.o/921eaf9a7f9e95ffa5dd4669062a19ea/xsim.dir/blockname_behav/xsimk.dll, doesn't exist.

Maybe you are looking for