Simulation and Verification

[pev.hall]

I have a very simple VHDL file that ISIM cannot compile which is frustrating me. It was a complicated RTL file but I’ve managed to

distil the error.

Here is the file I cannot compile

------------------------------------------

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

entity entity_test is

    port (

        clk : in std_logic

    );

end entity_test;

architecture rtl of entity_test is

begin

    test_gen : for ii in 1 downto 0 generate

    begin

        process(clk)

            procedure test is

            begin

            end procedure;

        begin

        end process;

    end generate;

end rtl;

------------------------------------------

I’ve attached the isim debug output message.

I’m running ISE 13.4 on Windows 7 - 64 bit

I’ve opened a webcase but on a colleagues advice I’m opening this forum discussion as well.

Thanks,

Pev

[eilert]

Hi,

to me it seems like some exceptional error that should be reported to the xilinx ISIM developers.

Actually your code does nothing.

But compiling so many lines just to do nothing sometimes confuses tools.

It's a corner case that might not have been checked during software tests.

Only thing that makes me wonder is that the tool complains about some redefinition.

Regards

  Eilert

[rcingham]

ModelSim PE 6.5f gives a warning, but does compile it:
# ** Warning: nothing.vhd(27): (vcom-1401) Synthesis Warning: Signal "clk" is in the sensitivity list but is not read in the process.

[pev.hall]

The original code is about 323 lines long does a lot of stuff and still gives the exact same error.

I've fixed the problem by defining the procedure at the start of the generate loop. However this make my code quite a lot more ugly as now the procedure has a large lists of inouts.

The redefinition error make me think that instead of creating two different definitions of this procedure (each using its set of variables) each with a different name. It creates two but tries to gives them both the same name.

Thanks,
Pev

[eilert]

Hi Pev,

thanks for the feedback.

It was a little irritating how much you cout down your code.

Now after looking at it with the new informations one can look at it differently.

It's right that there would be two procedures of the same name but they should be local to the processes and therefore not raise the error.

Most often procedures are defined globally  in the architecture or in a package. This way you write the code just once and can use it multiple times in your architecture.

You choose for_generate to acheive partly the same effect. An interesting approach which should work.

Have you tried to use another simulator (e.g. Modelsim) or even to synthesize your code?

Does XST also throw an error?

If another tool accepts the code it's most obviously a bug in ISIM.

Make this clear to the Webcase Support Person and let it be forwarded to the ISIM developers.

One of the next versions of ISIM then hopefully will accept your code.

Until then you have to live with your workaround.

Have a nice simulation

  Eilert

[pev.hall · Accepted solution]

Hi Eilert,

Got a message through the webcase they say that this problem has already been fixed in a future ISIM version. I guess I'll just have to sit back and wait to find out which future version.

XST does not throw an error. However I have not put this module on the chip or does a post synthesis simulation.

I'm avoiding using modelsim as we are trying to get away form it. Extra money we can spend on hardware (we need both VHDL and Verilog). If my code needs modelsim to simulate then every one will need modelsim when they want to incorporate my code.

Personally I like using subprograms (procedures/functions) defined locally as I can use the in-scope variables/signals. It also means that the declaration is closer to the code so easier to maintain. I do use some global / package subprograms as well but most are local. This is just my personal preference of course.

I use the generate loop for creating multiple instances of modules and or processes. This is something you cannot do with subprograms. I see subprograms and generates tackling two totally different problems, unless I've missed something.

Thanks,

Pev

[eilert]

Hi Pev,

thats some good news. I hope the next ISIM release alredy can hanbdle your code.

It was not my intention to make you change your toolchain. Just sometimes it is quite handy to get a "second opinion" from some other tool, to verify the own tools behavior. Some Starter or Demo license is often sufficient for this.

In your case even the XST result revealed that not your code was the problem, but the tool.

And that was the first question to be cleared before digging deeper into the problem.

There are lots of programming styles each with their own pros and cons.

To our luck the languages support all these styles so each developer (team) can work the way they choose for best results.

Kind regards

  Eilert