Vivado Generics synthesis issue.

[taimur123]

Hello all,

I am synthesizing a VHDL which contains several packages and source files, design in  Artix- 7. I am using Vivado 2015.4. 

In my design, In one of the package, I am setting parameters for the source files. In a source file, I am port mapping 2 constants from that package as Generics. "WINDOW_LENGTH" and "ACQUASITION_LENGHT".

I also updated my source files, declared both these CONSTANTS as Signals, and assigned to the corresponding register in the module, but still i got the same warnings.

The code compiles without error, behavioral simulation works just fine, but when I synthesize my design,  I get the following warnings which make me think the tool removed the signals.  I don't get any clue on why the tool is removing the signals.

Please find my attached synthesis report.

Any help would be appreciated.

Thanks,

• [Synth 8-3332] Sequential element (\config_reg[window_length][6] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][3] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][2] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][1] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m3][6] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m3][4] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m3][2] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition][6] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition][5] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition][3] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition][2] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition][1] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\en_ram_reg[3] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\en_ram_reg[2] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\en_ram_reg[1] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\en_ram_reg[0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m1][0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m3][0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m2][0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][6] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][4] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_length][5] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][4] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][0] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][1] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][2] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[acquisition_length][3] ) is unused and will be removed from module ram_ctrl.
• [Synth 8-3332] Sequential element (\config_reg[window_p_acquisition_m3][1] ) is unused and will be removed from module ram_ctrl. ....
• .........................................

[florentw]

Hi @taimur123,

The tool removes the signals if it thinks they are not needed. It could be because they have a constant value or because the port are unconnected.

You would need to check the signals one by one to see why the tool is removing it.

However, try a post-synthesis simulation. If if also just works fine, then you can ignore the warnings. It is just the tool telling you is doing optimizations. It is usually a good thing, it makes your design smaller.

If you have an issue in post-synthesis simulation, then the warnings are a good start for investigation the issue.

Kind Regards,

Florent

[hpoetzl]

Hey @taimur123,

I am port mapping 2 constants from that package as Generics. "WINDOW_LENGTH" and "ACQUASITION_LENGHT".

Double check that you are spelling those constants/generics correctly ...

The synthesis report says:

Parameter WINDOW_LENGTH_1 bound to: 7'b0101101
Parameter ACQUISITION_LENGTH_1 bound to: 7'b010001

Also note that depending on your design, it is normal that certain 'bits' become unused, because they are just not relevant to the design and thus get removed, for example if you access only the even elements of a buffer, the LSB of the buffer index will get removed because it is not used at all.

Hope this helps,

Herbert

[taimur123]

Actually the post synthesis simulation doesn't work properly because the tool removes the mentioned signals..

[taimur123]

Yes, that was the second way I tried to input these constant values, but the tool still removed the signals.

[florentw]

Hi @taimur123,

The usual mistake is that you have a port of you IPs which is unconnected. I would check in the synthesized design.

Could you share a test case?

[taimur123]

What should i Share?

[florentw]

Hi @taimur123,

The best would be your full project. This way we can check what happen during synthesis. What is broken.

[taimur123]

Dear @florentw , @hpoetzl

I was wondering, if is it possible to input constant generics at the input port of VHDL module? Will that code be synthesizable ?

[taimur123]

Dear @florentw 

I'm attaching a source file here, what i want in this file is to remove 
"s_axis_ctrl_tdata"

input port, and pass the concerned value as constant in my top module, what is the best possible way to do that?

[florentw]

Hi @taimur123,

I don't see why you couldn't have a constant value as input.

However, for this design if s_axis_ctrl_tdata has a constant value, what is the point of using a BRAM if all the addresses will have the same value?

[taimur123]

 Hi @florentw

Actually, the functionality of design requires huge memory, and multiple reads write operations, therefore, BRAM is used.

How i can map constant data at s_axi_ctrl_tdata signal i want to remove the input interface from this module.

[taimur123]

Hi @florentw

This is how I'm declaring generics.

generic(
WINDOW_LENGTH : in std_logic_vector(BW_MAX_WINDOW_LENGTH-1 downto 0) := ("1101101");
ACQUISITION_LENGTH : in std_logic_vector(BW_MAX_WINDOW_LENGTH-1 downto 0) := ("1101101")
);

Is it the right way?

[taimur123]

Hi @florentw

I have sent you the complete project, can you please have a look onto it?

[hpoetzl]

Hey @taimur123,

This is how I'm declaring generics.

No, that doesn't look right ...

First, a generic has no direction (in vs out) because it is a constant defined for the use in instances of an entity.

Secondly, the assignment of the 7 bit vector values to the logic_vector with BW_MAX_WINDOW_LENGTH bits looks suspicious, unless it is actually defined as '7' somewhere.

Maybe elaborate a little more what you're trying to do here ...

Best,

Herbert

[taimur123]

Hi @hpoetzl

Actually, I have seen somewhere, declaration of generics having direction "in".

If you open the file ram_ctrl.vhd,  Ialready attached here, I need to remove the "s_axi_ctrl_tdata" interface, and in place of that, map the values as constant, in top_module.

[markcurry]

I suggest NOT removing the port at all.  Just tie it off to the constant value from top_module.   Don't bother changing the source code at all to change it into a generic.

They synthesizer will take care of optimizing away the constants.  Although from the earlier comments you've made in this thread, you may be looking to inhibit the optimizations (for some unclear reason).

Regards,

Mark

[taimur123]

Dear @markcurry

I that possible to tie some constants in the top module? on the input port of a submodule in the project? I thought it's  not possibel ?Can I directly map the constants? without declaring the GENERICS?

[markcurry]

Yes, it's allowed to assign constants to sub-module pins within VHDL.  And the synthesizer will handle it just fine.

Since I'm a verilog user, I neglect showing how (as I'd probably mess up the syntax).  Perhaps another VHDL user will fill in those details here.  But it's quite possible, and common.

Regards,

Mark

[hpoetzl]

Hey @taimur123,

Actually, I have seen somewhere, declaration of generics having direction "in".

I've never seen a generic with a port mode like 'in' or 'out' and the standard (IEEE-1076-2008) doesn't mention any mode attributes in context with generics, so I presume those are 'accidents' which just happen to work (not sure they do for all synthesis tools).

If you open the file ram_ctrl.vhd,  Ialready attached here, I need to remove the "s_axi_ctrl_tdata" interface, and in place of that, map the values as constant, in top_module.

The ram_ctrl.vhd file does not contain s_axi_ctrl or s_axi_ctrl_tdata.

I presume you are talking about s_axis_ctrl_tdata.

This interface seems to be a 32bit vector split into two 16bit vectors specifying config.window_length and config.acquisition_length.

Replacing those with generics is rather simple, something like this should do ...

entity ram_ctrl is
    generic (
        CFG_WINDOW_LENGTH      : integer := 8;
        CFG_ACQUISITION_LENGTH : integer := 8
    );
    port (
    ...

... and in the configuration case ...

when CONFIGURE =>
    config.window_length <= 
        to_unsigned(CFG_WINDOW_LENGTH, config.window_length'length);
    config.acquisition_length <= 
        to_unsigned(CFG_ACQUISITION_LENGTH, config.acquisition_length'length);

Best,

Herbert

[taimur123]

Thanks @markcurry for your response, waiting for some VHDL guy to comment on this. Thanks

[taimur123]

Thanks a lot @hpoetzl for the reply, actually I'm a bit beginner in VHDL. Can you please let me know where i can declare 

CFG_WINDOW_LENGTH and CFG_ACQUISITION_LENGTH

values.  Can I declare them in parameter's package? or should I declare in the top module?

[florentw]

Hi @taimur123,

You generic values are correctly written in your second design

(WINDOW_LENGTH : std_logic_vector(BW_MAX_WINDOW_LENGTH-1 downto 0) := ("1101101");)

So I don't think this is a coding issue.

Could you give me more information about why you are saying that the simulation failed?

Regards,

Florent

[taimur123]

Hi @hpoetzl

I have a question regarding that Generics.

Is it possible to declare WINDOW_LENGTH and ACQUASITION_LENGTH as generic in Top-level module, without declaring their values?

I am declaring both as generics by just specifying the bit width, But Vivado isn't synthesizing it giving me the following error. Can you please have a look into it. Thanks

• [Synth 8-1031] window_length is not declared ["E:/Viterbi/decoder/sources/ram_ctrl.vhd":226]
• [Synth 8-1031] acquisition_length is not declared ["E:/Viterbi/decoder_V6/decoder_V6.srcs/sources/ram_ctrl.vhd":228]"

[hpoetzl]

Hey @taimur123,

Is it possible to declare WINDOW_LENGTH and ACQUASITION_LENGTH as generic in Top-level module, without declaring their values?

At some point before synthesis, you need to tie generics to a value, which might be a default value.

It's not possible to synthesize code with unknown constants :-)

If you need to change them at run-time, then a generic is not what you are looking for.

Best,

Herbert

[taimur123]

Hi @hpoetzl

Thanks for the quick reply,

so in order to change the values at run-time I have add an input port, right?

[hpoetzl]

@taimur123,

so in order to change the values at run-time I have add an input port, right?

Some kind of input yes, there are some options though ...

• Have a port for each value (optionally with control signals)
• Use a bus interface (Wishbone, AXI, Memory)
• Provide some kind of Dynamic Configuration Port (DRP)

Best,

Herbert