Welcome to the IP Integration Node

[vwan]

Thanks for playing with the IP Integration Node and giving us very valuable feedback.

As for issue (1): I agree that the wizard style configuration dialog is inconvenient if users only want to change the data type because they need to go over all of four configuration pages. We will try to improve this user interface during productization.

For Issue (2): Would you please send your complete VHDL file to me? I'll look into this more and we will make the IP Integration Node also be able to support it if possible.

[--thatguy]

Here you go.  Simple SCTL with HDL node that compiles.  The same code when sent to the IP integration node doesn't get past the first generation step.  If you go into the VHDL file you'll see where I commented out the fix.

[AndyBrown]

I have been seeing some issues with the IP Integration Node when I have to regenerate.  Right now I'm using LabVIEW as my test bench to verify small snippets of VHDL code.  Thus far I have a setup with 2 VI's:

• the subVI which only contains an IP Integration Node and the controls and indicators to wire things to the connector pane
• the main VI which serves as a test bench and performs the algorithm in both the host using desktop LabVIEW and calls the subVI then compares the two results

The problem that I am seeing is when I have to make a change to the something in the VHDL code.  When I do this and re-run the main VI I get all zeros out and sometimes it runs incredibly slow.  I've tried at least the following steps:

• Closing both VI's and re-opening and re-running the host
• Closing both VI's and re-opening the subVI and re-doing the generation and then opening the main VI and re-running
• Closing LabVIEW and re-opening LabVIEW and the two VI's and re-running

None of these seems to solve the issue.  The only thing that seems to work is to:

1. Close and Re-open LabVIEW
2. Open the sub-VI and regenerate
3. Then open the main VI and run

It seems that once the main VI has been run that the DLL is still in memory and the only way to get it out of memory is to close LabVIEW.  It also appears that regenerating with that DLL still in memory causes issues.

On a possibly related note, I've found that whenever the regeneration fails like this, the next time I go back into the dialogs to perform another regeneration the 'Reset IP' configuration has toggled from my desired choice of "Before first Call" to the "Compile or Load".  This doesn't seem to happen any other time.  All the other settings (including FXP definitions) seem to keep their settings.

[vwan]

The IP Integration Node should first be checked by the Fuse which is a Xilinx tool that generates simulation model. The Fuse cannot support the partial mapping with "open" so it reports errors. The HDL node doesn't need that check because it cannot support simulation. Obviously it's not convenient in some cases like yours, but I'm afraid we don't have a way to resolve it in the near future because we cannot do anything to the Fuse tool.

At this point, I don't have a workaround for you more than changing your VHDL :-(.

Thank you for reporting this to us.

[vwan]

Hey Andy, how does your main VI call the sub VI? Would you send your use case to me so that I can look into it more carefully? The IP Integration Node should unload the dll once the VI it resides in stops.

As for the "Reset IP" issue, it sounds like a bug. We'll fix it during productization. Thanks for reporting all these to us.

[thill]

I'm having trouble compiling when using the IP integration node.  I am able to use the ISE environment to synthesize my code (I do this as a check to make sure there won't be errors when using the LVFPGA compiler), but when I try to compile this same code using the IP integration node, I see errors that would normally be found during the Check Syntax process (data bus width mismatches).

I have tried deleting the local folders on both the client and the server to make sure an old copy of the file wasn't being used, but I still see the same error.  Is this a known issue for the IP integration node?  I've used the HDL node many times in the past and have never seen an issue like this one.

[Newton_Petersen]

Hi,

The only known limitations are the port list can only have vhdl types of std_logic and std_logic_vector. There can also only be one entity in the top level vhdl file. Can you post the vhdl and the VI using the IP Integration Node which has this issue?

Thanks...

[sedy]

hi andy, i have been using ip node lately,and saw ur mAC code, so,u know good amount of vhdl. i had few questions for u,if u cld help

1) hav u tried to use types other than boolean/fixed point.e.g i tried using integer array,it dosnt work.is there a way to create integer arrays.

2) so, is there a way to add package file into ip node?

thnks

sid

the code goes here

library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_arith.all;

package int_array is

type integer_vector is array( natural range <> ) of  integer;

end int_array;

use work.int_array.all;

entity add_intarr is

   generic (n:natural :=4);

    port( a,b:in integer_vector(n-1 downto 0);

          ci: in integer;

          sum: out integer_vector(n downto 0));

end add_intarr;

  architecture a1 of add_intarr is

   begin

    process(a,b)

      variable cin , s:integer_vector(n downto 0);

        begin

          cin(0):=ci;

          for i in 0 to n-1 loop

              s(i):= a(i)+b(i)+cin(i); -- must add arrays,element by elemnt

                  if s(i)>9 then

                      s(i):= s(i)-10;

                      cin(i+1):= 1;

                  else

                      cin(i+1):=0;

                  end if;

           end loop;

         s(s'left):=cin(cin'left);

         sum<=s;           

    end process;

   end a1;

[thill]

The only types of I/O I ever add to the HDL nodes and/or the IP Integration nodes are FXP, U8 through U64, I8 through I64, booleans, and on rare occasions, boolean arrays.  I have never tried to use an integer array.  I simply wouldn't know how to match the VHDL interface (the entity declaration) to the LVFGPA interface in that case.  If you stick with FXP and booleans, you can't go wrong and you can always match a VHDL entity--regardless of bus widths.

With the packages, I don't recall having tried this, but I'm pretty sure that if you properly reference the package in your VHDL code and include all the necessary files in the HDL node, then it should work out fine.

Also, one thing to take note of in your code is that you won't be able to see your generic inputs with the IP integration node interface which means that your VHDL will always use the default.

[sedy]

hi,thnks thill.

well, i guess i need to declare everything boolen array,and use arith/mumeric package to convert to integer.

as for genric, i have seen that if i cjange the generic  initial value in vhdl code,it changes in ip node too.so, that should be fine,right?

sid