using VHDL "if generate" with an input port

In case an input port to an entity has a constant value, can we use the "if generate" command using on it ?

for exampe:
suppose x is an input to our entity and is defined as type string - will the following synthesize:


surely it would work if x was a generic - but if x is an input port to an entity, is this still considered correct syntax ?

shaiko said:

In case an input port to an entity has a constant value, can we use the "if generate" command using on it ?

for exampe:
suppose x is an input to our entity and is defined as type string - will the following synthesize:

Code:

if x = "correct_condition"  generate

surely it would work if x was a generic - but if x is an input port to an entity, is this still considered correct syntax ?

Click to expand...

No, the if..generate condition needs to be constant at elaboration time, not at runtime. So you can use constant expressions like x'length but not x itself. Because the value of x is only known at runtime.

Sure,
But I always assumed that the elaboration ends at the top entity.
The fact that 'x' is an input port at some component, doesn't mean it's dynamic at runtime. My question - doesn't the synthesis tool always "wait teel it sees the whole pricture" (visible only when it reaches the top hirechrchy) ?

Re: using VHDL "if generate" with an input port

elaboration runs through the entire hierarchy, doing syntax checks on all the files, making sure all the connections are valid etc without applying any values to ports. because time does not exist yet.

- - - Updated - - -

basically it sets up all the connections without applying any values.

So, the answer to my original question is..."yes"?

The Answer is NO.
It connects all the pipes, but it doesnt know whats in those pipes.

Very well,
What about this case?


Will the above code ALWAYS be synthesized with flip flops? Consider the case when IN_RESET is assigned a CONSTANT '0' from the higher hirerchy. Then the code simplifies to:
Which is the behaviour of RAM !

If I understand the example right, you mean that the synthesis tool is intelligent enough to remove logic which is driven by constant signals. In return you ask why it doesn't allow constant signals used in place of generics?

I think, the tool won't be strictly required to flag an error, but according to VHDL specification, there's no reason why it should allow constant signals as generics.

In other words, you are discussion tool behaviour beyond specifications. It don't see a reasonable purpose to do so.

If I understand the example right, you mean that the synthesis tool is intelligent enough to remove logic which is driven by constant signals.

Click to expand...

YES...
In the above example, you're saying that according to VHDL specs, the synthesis tool is "allowed" to proceed and synthesize a flip flop without evaluating the whole picture first?

shaiko said:

Code:

process ( IN_CLOCK ) is 
begin 
  if rising_edge ( IN_CLOCK ) then
        if IN_WRITE = '1' then 
	 OUT_DATA <= IN_DATA ;
        end if ;
   end if ;
end process ;

Which is the behaviour of RAM !

Click to expand...

No, this is a flip flop with synchronous enable and the asyc input set to '0' (usually unconnected).

The synthesisor will do boolean reduction after everything is connected. Hence why you cannot use a generate on a constant signal as it doesnt know the signal is constant yet (and another time, that signal may not be constant).

The synthesisor will do boolean reduction after everything is connected

Click to expand...

Is the following correct?

1. During the elaboration process, the synthesizer makes up its mind about the exact logic to use for the job (DFF/RAM/MUX/etc..) and how to connect it.

2. During optimization, the synthesizer evaluates what of the elaborated logic to implement and what to eliminate (based solely on Boolean reduction).

3. The optimization products aren't used to reevaluate the decisions made during elaboration.
In other words - it doesn't say: "Wow, after I optimized all this stuff away, I see that I should have use RAM instead of DFFs."

Do I understand the process correctly ?

shaiko;1346360 3. The optimization products [U said:

aren't[/U] used to reevaluate the decisions made during elaboration.
In other words - it doesn't say: "Wow, after I optimized all this stuff away, I see that I should have use RAM instead of DFFs."

Click to expand...

The synthesis will implement RAM if you code it according to the tools recognizable constructs that infer a RAM. Just having a clock and data with an enable doesn't result in a RAM it will usually end up a DFF. You also need an address and what you are writing to better be an array, only then you might get a RAM.

If something that is too complex for XST and Vivado, like a simple dual port RAM (Xilinx only supports inferred single port RAMs), the synthesis tool will make the "RAM array" from DFFs.

Regards

shaiko said:

In case an input port to an entity has a constant value, can we use the "if generate" command using on it ?

for example:
suppose x is an input to our entity and is defined as type string - will the following synthesize:

Code:

if x = "correct_condition"  generate

surely it would work if x was a generic - but if x is an input port to an entity, is this still considered correct syntax ?

Click to expand...

No it is not. According to the LRM "The discrete range in a generation scheme of the first form must be a static discrete range; similarly, the
condition in a generation scheme of the second form must be a static expression.". Neither an input port nor a signal can be a "static expression", therefore it is not allowed as the condition in a generate statement.

All the discussion about how a synthesizer can reduce Boolean logic and whether connecting the input port to a constant is in someway 'equivalent' to a generic is not applicable. The only condition that can be a generate condition is a 'static expression'. The only thing that can be a 'static expression' is a constant. Signals are not constants, therefore they cannot be used as a condition for a generate.

Kevin Jennings

Thanks Kevin.
Can you please address post #11?
Is what I wrote there correct ?

shaiko said:

Is the following correct?

1. During the elaboration process, the synthesizer makes up its mind about the exact logic to use for the job (DFF/RAM/MUX/etc..) and how to connect it.

Click to expand...

From my understanding, the elaboration will just work out the hierarchy of the design and do syntax checking. It is the synthesis step that will map code constructs to DFF/RAM etc.

2. During optimization, the synthesizer evaluates what of the elaborated logic to implement and what to eliminate (based solely on Boolean reduction).

Click to expand...

It is a lot cleverer than just boolean reduction. It will place rams in place of shift registers, do register retiming, combine parrallel registers and even combine memories that are separate in HDL code into the same M4/9/10Ks if they use the same address busses. The boolean reduction is just the easier bit.

3. The optimization products aren't used to reevaluate the decisions made during elaboration.
In other words - it doesn't say: "Wow, after I optimized all this stuff away, I see that I should have use RAM instead of DFFs."

Do I understand the process correctly ?

Click to expand...

It sounds like you're trying to get a positive answer to your question. The answer is a big NO, and it will never be true because it is against VHDL rules to set a generate based on a signal. So it will always fail at the elaboration stage. Thats what the rules are for.

The synthesis still has limitations. It can only pull out the more complicated structures (like rams) from specific templates. As the tools improve, it's recognition of rams that follow the templates but in different ways (like sticking them inside generate loops, or differet read and write sizes) also improve. If you dont follow the templates, it wont infer a ram.

Thanks for the elaborate response.

It sounds like you're trying to get a positive answer to your question

Click to expand...

I don't...I wrote the word "doesn't" at the third part of post #11.