VHDL Synthesis Error for Synopsys but not for Synplicity!
SuSenSa08
I have the following VHDL codes:
-- FSM definition
type pre_statetype is (wait_high, wait_hold);
signal pre_state : pre_statetype;
-- one-hot FSM encoding
attribute enum_encoding : string;
attribute enum_encoding of pre_statetype : type is "000001 000010
000100 001000 010000 100000";
Synplify Pro 8.8 does not complain about it but Synopsys
design_compiler -xg mode 2007.03 does as shown below:
Information: Building the design 'prelaunch'. (HDL-193)
Error: prelaunch.vhd:37: The number of enum encodings given does not
match the number of literals. (ELAB-341)
*** Presto compilation terminated with 1 errors. ***
Warning: Unable to resolve reference 'prelaunch_pulse_gen' in
'decoder_asic'. (LINK-5)
1
Why are the tools different ? Is the error fatal, i.e. need a fix ?
Thanks,
Calvin
Mike Treseler
> Why are the tools different ?
Because you are using vendor-specific attributes.
Is the error fatal, i.e. need a fix ?
Leave out the attributes and
declare a type enumeration for the
the state variable (or signal) updates.
Let synthesis handle the encoding and decoding details.
-- Mike Treseler
SuSenSa08
I thought the error was due to a mismatch between 2 lists.
The Synopsys error went away when I changed the line to:
attribute enum_encoding of pre_statetype : type is "10 01";
Is that possible ?
Calvin
SuSenSa08
I thought the error was about a mismatch between 2 lists.
The synopsys error went away when I changed the line to:
Mike Treseler
> The synopsys error went away when I changed the line to:
> attribute enum_encoding of pre_statetype : type is "10 01";
> Is that possible ?
Yes but it's a vendor attribute, not part of the language.
If you want to do it that way, check with vendor docs.
-- Mike Treseler
Jim Lewis
>> attribute enum_encoding of pre_statetype : type is "10 01";
>> Is that possible ?
having more than 2 values specified (as in your previous example)
is wierd and the Synopsys' error is consistent with basic VHDL
philosophy - if a literal has too many values to be associated
with a target, it is a serious error and warrants immediate designer
attention.
> Yes but it's a vendor attribute, not part of the language.
> If you want to do it that way, check with vendor docs.
enum_encoding is a vendor created attribute that was
standardized in 1076.6-1999. So while it is not part of
the base standard (1076), it is part of the 1076.6 standard.
Even so, as Mike suggested, you still want to check your vendor
docs as may take enum_encoding as THE encoding to use and while
some may take it only as a request or suggestion.
Cheers,
Jim
SynthWorks
sly
From IEEE 1076.6-1999 Standart:
"The value of this attribute shall specify the encoding of the
enumeration type literals. The attribute value
shall be made up of tokens separated by one or more spaces.
There shall be as many tokens as there are literals
in the enumeration type, with the first token corresponding to the first
enumeration literal, the second
token corresponding to the second enumeration literal, and so on."
SuSenSa08
>
> - Show quoted text -
It makes sense to have a one-to-one mapping between 2 lists.
However, I am still not sure why Synplicity synthesis does not
complain when there is a mismatch!
Alan Fitch
<snip>
>
> However, I am still not sure why Synplicity synthesis does not
> complain when there is a mismatch!
Synplify doesn't (as far as I know) support enum_encoding.
It uses two attributes,
syn_encoding
and
syn_enum_encoding
syn_enum_encoding is closest to your original example, i.e. it takes
a comma separated list of string literals.
However note that syn_enum_encoding is ignored if the FSM Compiler is
enabled.
regards
Alan