Stats

Locked Locked
Replies 5
Subscribers 92
Views 17715
Members are here 0

This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

gray code

Hi,

I would like to know if the type of code for the state machines is configurable in encounter, in particular gray code. Thanks.

Parents

Sporadic Crash over 12 years ago

Hi gh-,
RTL Compiler has no support to control FSM coding style. I vaguely remember even Synplify had a pragma for this (binary, one-hot, gray or Johnson coding).
I have done an experiment: Synthesized 9-bit binary counter, and then synthesized 9-bit Gray counter (using CW_cntr_gray) using following coding style:
CW_cntr_gray #(
.width          ( WIDTH )
) my_gray_cntr (
.clk            ( clk   ),
.rst_n          ( ~rst ),
.init_n         ( 1'b1 ),
.load_n         ( 1'b1 ),
.data           ( {WIDTH{1'b1}} ),
.cen            ( 1'b1 ),
.count          ( gray_cntr )
After the elaboration, before the synthesis I have flattened this logic and run synthesis with highest effort.
Area of 9-bit binary counter is 492.831, power consumption is 45.752 uW.
Area of 9-bit Gray counter (from CW) is 684.196 and power consumption is 51.934 uW.
For the power measurements I have run gate-level simulations, generated VCD file and I have run another RTL Compiler session in which netlist is read and VCD is annotated on that. This is the flow/setup which gives most accurate power measurements in front end.
As you see above, Gray coding from CW is not efficient as binary coding.
Another observation is the tool behaviour of RTL Compiler during elaboration of CW.
            Reading Verilog file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'
Info    : Building ChipWare component. [CDFG-359]
        : Design 'CW__CW_cntr_gray__builtin' from library 'CW' (instantiated from 'dummy dfg') with the parameter(s) width=9 in file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' on line 1.
    Elaborating block 'CW__CW_cntr_gray__builtin_width9' from file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Warning : Unreachable statements for case item. [CDFG-472]
        : Case item 'default' in module 'CW__CW_cntr_gray__builtin_width9' in file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' on line 1.
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' (priority 1)}
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' (priority 1)}
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/add_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'ADD_UNS_OP' (pin widths: A=9 B=1 Z=9) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'ADD_UNS_OP' (pin widths: A=9 B=1 Z=9) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/add_unsigned/implementations/very_fast' (priority 1), '/hdl_libraries/GB/components/add_unsigned/implementations/medium' (priority 1), '/hdl_libraries/GB/components/add_unsigned/implementations/slow' (priority 1)}
Done elaborating 'gray_WIDTH9'.
As you see, none of the synthetic operators BIN2GRAY_STD_LOGIC_OP, GRAY2BIN_STD_LOGIC_OP, INC_GRAY_STD_LOGIC_OP is inferred. Instead the ones with bold were inferred, which means that RTL Compiler produces not efficient hardware. I have the feeling that this CW is using a binary counter with Gray-code wrapper around it.
Anyone who can elaborate this is appreciated.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

Sporadic Crash over 12 years ago

Hi gh-,
RTL Compiler has no support to control FSM coding style. I vaguely remember even Synplify had a pragma for this (binary, one-hot, gray or Johnson coding).
I have done an experiment: Synthesized 9-bit binary counter, and then synthesized 9-bit Gray counter (using CW_cntr_gray) using following coding style:
CW_cntr_gray #(
.width          ( WIDTH )
) my_gray_cntr (
.clk            ( clk   ),
.rst_n          ( ~rst ),
.init_n         ( 1'b1 ),
.load_n         ( 1'b1 ),
.data           ( {WIDTH{1'b1}} ),
.cen            ( 1'b1 ),
.count          ( gray_cntr )
After the elaboration, before the synthesis I have flattened this logic and run synthesis with highest effort.
Area of 9-bit binary counter is 492.831, power consumption is 45.752 uW.
Area of 9-bit Gray counter (from CW) is 684.196 and power consumption is 51.934 uW.
For the power measurements I have run gate-level simulations, generated VCD file and I have run another RTL Compiler session in which netlist is read and VCD is annotated on that. This is the flow/setup which gives most accurate power measurements in front end.
As you see above, Gray coding from CW is not efficient as binary coding.
Another observation is the tool behaviour of RTL Compiler during elaboration of CW.
            Reading Verilog file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'
Info    : Building ChipWare component. [CDFG-359]
        : Design 'CW__CW_cntr_gray__builtin' from library 'CW' (instantiated from 'dummy dfg') with the parameter(s) width=9 in file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' on line 1.
    Elaborating block 'CW__CW_cntr_gray__builtin_width9' from file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Warning : Unreachable statements for case item. [CDFG-472]
        : Case item 'default' in module 'CW__CW_cntr_gray__builtin_width9' in file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' on line 1.
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' (priority 1)}
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'EQ_UNS_OP' (pin widths: A=1 B=1 Z=1) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/equal_unsigned/implementations/very_fast' (priority 1)}
Info    : An implementation was inferred. [CWD-19]
        : The implementation '/hdl_libraries/GB/components/add_unsigned/implementations/very_fast' was inferred through the binding 'b1' for the call to synthetic operator 'ADD_UNS_OP' (pin widths: A=9 B=1 Z=9) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v'.
Info    : Sorted the set of valid implementations for synthetic operator. [CWD-36]
        : The implementations for the call to synthetic operator 'ADD_UNS_OP' (pin widths: A=9 B=1 Z=9) at line 1 in the file '.../tools.lnx86/lib/chipware/syn/CW/CW_cntr_gray.v' will be considered in the following order: {'/hdl_libraries/GB/components/add_unsigned/implementations/very_fast' (priority 1), '/hdl_libraries/GB/components/add_unsigned/implementations/medium' (priority 1), '/hdl_libraries/GB/components/add_unsigned/implementations/slow' (priority 1)}
Done elaborating 'gray_WIDTH9'.
As you see, none of the synthetic operators BIN2GRAY_STD_LOGIC_OP, GRAY2BIN_STD_LOGIC_OP, INC_GRAY_STD_LOGIC_OP is inferred. Instead the ones with bold were inferred, which means that RTL Compiler produces not efficient hardware. I have the feeling that this CW is using a binary counter with Gray-code wrapper around it.
Anyone who can elaborate this is appreciated.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.