Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Strange warning in Synplify PRO

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello,

While using Synplify Pro to compile a design, I encountered a "CDC272" warning .
Comparison (=) of different length arrays is always false!
Click to expand...
The warning points to the following line in which I use a string generic inside a generate statement:
Code: 
synchronous_or_asynchronous : if STRING_CONFIGURATION_1 = "asynchronous" generate
...
Any idea what that means?
 

I guess you get the warning when STRING_CONFIGURATION_1 is set to "synchronous"? So it's just reporting an obvious fact.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
I guess you get the warning when STRING_CONFIGURATION_1 is set to "synchronous"?
Click to expand...
Yes,
But why warn about that?
 

because you're doing a compare with 2 strings that are different lengths. It's warning you about this, as you would usually expect to compare strings of the same length..
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
I didn't define the length of the string...
In the top entity, I initialized defined it and initialized it as follows:
Code: 
STRING_CONFIGURATION_1 : string := "asynchronous" ;

In my code, I have 2 logic generation paths:
Code: 
if STRING_CONFIGURATION_1 = "asynchronous" generate
...  
end generate ;

if STRING_CONFIGURATION_1 = "synchronous" generate
...  
end generate ;

Before compilation, I want to set "STRING_CONFIGURATION_1" to either "synchronous" or "asynchronous" to generate the required logic accordingly.

The thing is that: "synchronous" is one character shorter then "asynchronous".

Will that cause a problem?
 

You declare the length implicitly when you assign the value. Assuming this is a constant or genetic it doesn't really matter.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
So,
the logic will be generated when "STRING_CONFIGURATION_1" is either "asynchronous" or "synchronous" - regardless of the character length mismatch between the words?
 

shaiko said:
So,
the logic will be generated when "STRING_CONFIGURATION_1" is either "asynchronous" or "synchronous" - regardless of the character length mismatch between the words?
Click to expand...
It will probably work as you want, but you should only get the warning when the generic is different from the compare string.

The compiler is only trying to help you. Strings in VHDL have a fixed length, so it's normally meaningless to compare strings of different length.
You can try to compare only a number of characters at the beginning of the strings. That should get rid of the warning.

Something like this:
Code: 
synchronous_or_asynchronous : if STRING_CONFIGURATION_1(1 to 4) = "asyn" generate
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Quartus also generates a lot of unwanted warnings in parameterized designs (e.g. various constant expressions, undriven signals), but no unmatched string length in if generate expressions. Of cause each of this warnings has a purpose in some context, but they are disturbing me though and I usually disable it with a message_off synthesis attribute.

VHDL has no preprocessor as Verilog and this makes constructs like constant IF expressions necessary for parameterized designs. So you have to life with the warnings.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Question: why use a string as a configuration item? Or more generally put: why use a specific type of your choice in a language as a configuration item (where you have to do comparisons) when this specific type of your choice has poor comparison operators?

I mean: strings can be done in your favorite HDL, but as you noticed the string compare operation can be done but is not super user friendly for this sort of thing.

Why not use an enumeration, or parameter or whatever you VHDL people use? And if you absolutely must strings, then maybe use a function that abstracts away the dirty business.

So sortof what std_match wrote, only this compare_config_string(str1, str2) function does something like:
- compare lengths of str1 and str2. Different length? ==> not the same string
- if same length, then compare the two strings like you used to, and return result

Or maybe you could hash the string and compare hashes.

Anyways, doesn't VHDL have a clean way of doing this?

In verilog I'd probably just use parameters as enumerations with meaningful names. But maybe VHDL has a nice way of doing this with strings? If not, maybe go with enumerated items of a type with known-to-work easy comparison operators?
 

Presumed the vendor IP already uses string generics for many configuration parameters and you want to set these parameters pepending on entity generics. Why shouldn't you use the same parameters for other related configuration purposes in your design instead of creating numerical alias parameters?

Of course you can go the opposite way, define an enumeration type, define a string array type of this enumeration, define constant strings to supply the vendor IP generics. Quite elegant but also rather verbose.
 

FvM said:
Presumed the vendor IP already uses string generics for many configuration parameters and you want to set these parameters pepending on entity generics. Why shouldn't you use the same parameters for other related configuration purposes in your design instead of creating numerical alias parameters?
Click to expand...
If that is the case I'd use the provided strings as well. No need to duplicate things with all the drawbacks this duplication would entail. I think I would however try to make the string comparisons (configuration token comparisons) as robust as possible. So either use a vhdl language construct that does this out of the box, or use a small function that does this for you.

I.e: personally I would not want to have to do something like if STRING_CONFIGURATION_1(1 to 4) just because the token of the day has length 4. Because the next token of the next day will be something of different length and then you are boned. And you are boned because you are human and as such forget things every now and then. Copy/paste a bit of code, forget to change the hardcoded length, that sort of thing. See it all the time. Why introduce a possible cause of error (hardcoded string length) when you can avoid this?

Of course you can go the opposite way, define an enumeration type, define a string array type of this enumeration, define constant strings to supply the vendor IP generics. Quite elegant but also rather verbose.
Click to expand...
As you already suggested, if the provided IP is already using strings then it's probably better (read: less painful maintenance) to use those strings as well.

But if it's from scratch then maybe strings are not the way to go for configuration items. Or maybe they are, provided you have proper way to test the config tokens. I don't know how things are in VHDL but I always found the support for this in verilog somewhat underwhelming. Certainly less mature than in the software business.

- - - Updated - - -

FvM said:
Of course you can go the opposite way, define an enumeration type, define a string array type of this enumeration, define constant strings to supply the vendor IP generics. Quite elegant but also rather verbose.
Click to expand...
Mmmh, re-reading that bit. If the alternative was painful enough (prone to mistakes, annoying maintenance) I think it just might be worth it too. ;). Write small perl/python script to parse the vendor IP, extract string generics, spit out small package that neatly wraps the config tokens the way you want it. Then for new IP / updated versions you'd only need to rerun the script. And of course you version your generated package so you don't get mismatches.

But I'll shut up now. Back to shaiko.
 

Another option is to not use a string and instead make the configuration option the mode you want to select and then make the type boolean and check against true/false:

Code: 
SYNCHRONOUS : boolean := true;

if SYNCHRONOUS = false generate
...  asynchronous version of code
end generate;

if SYNCHRONOUS = true generate
...  synchronous version of code
end generate;

I use this with a SIMULATION boolean to shorten long counters, when I don't care about the duration of the count in simulation.
 

mrflibble said:
Question: why use a string as a configuration item? Or more generally put: why use a specific type of your choice in a language as a configuration item (where you have to do comparisons) when this specific type of your choice has poor comparison operators?

I mean: strings can be done in your favorite HDL, but as you noticed the string compare operation can be done but is not super user friendly for this sort of thing.

Why not use an enumeration, or parameter or whatever you VHDL people use? And if you absolutely must strings, then maybe use a function that abstracts away the dirty business.

So sortof what std_match wrote, only this compare_config_string(str1, str2) function does something like:
- compare lengths of str1 and str2. Different length? ==> not the same string
- if same length, then compare the two strings like you used to, and return result

Or maybe you could hash the string and compare hashes.

Anyways, doesn't VHDL have a clean way of doing this?

In verilog I'd probably just use parameters as enumerations with meaningful names. But maybe VHDL has a nice way of doing this with strings? If not, maybe go with enumerated items of a type with known-to-work easy comparison operators?
Click to expand...

VHDL has no useful string processing. You need to define your own processing things. There are the read/write procedures from textio, but its a bit rubbish just to process a few strings.

I have quite often seen IPs use strings as config items. Even Altera use them for almost everything, eg. the altsyncram generics:

Code: 
clkrega => "clock0"/"clock1"/"none"
ramstyle => "m4k"/"m9k"/"mram"/"m144k" 

--etc etc

its quite a neat way to wrap up human redible configuration when there are more than 2 options (true/false) and you dont need to define an enumerated type in a package. In adition, Quartus and Modelsim can then override them easily from the command line or setup. Enumerated types cant be set like this:

vsim my_design -GMY_GENERIC="This is a generic forced from the VSIM options"
 
TrickyDicky said:
its quite a neat way to wrap up human redible configuration when there are more than 2 options (true/false) and you dont need to define an enumerated type in a package. In adition, Quartus and Modelsim can then override them easily from the command line or setup. Enumerated types cant be set like this:

vsim my_design -GMY_GENERIC="This is a generic forced from the VSIM options"
Click to expand...

Thanks. That bit partially answers the question of why use a string (a type with poor comparison operator/other useful processing) for your config tokens. So paraphrasing a little, the config token (string) processing support is less than stellar but to make up for it you CAN override them from the command line. And I can readily see why that last part -GPANCAKE_TYPE="bananas" is a big plus. If I'm not mistaken in that way it's similar to specifying verilog parameters on the command line.
 

I think the lack of string processing is more the fact that VHDL is used primarily as a synthesis language, and hence strings have little use, and other than textio there are no more processing options.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top