Synopsys DC: Trouble with FSMs
Volker Schuetz
Hi,
I have a problem with the Design Compiler from Synopsys. I'm working
with Version v3.4a.
I have a bunch of small FSMs in state-table format and I want to compile
them with Synopsys. But some FSMs make trouble. The Design_Compiler
vanishes just after beginning the compiling. The whole job is gone and I
get no error message. The last words are:
"Processing FSMs"
My compile_script ist simpel:
----------cut----------
/* counter ist set some lines above */
while (counter < 10100)
{
/* filename is "fsm_counter", that is fsm_00001, fsm_00002... */
read -format st filename
set_max_area 0.0
set_fsm_minimize true
set_fsm_encoding_style auto
compile
/* filename_report is defined like fsm_counter */
report_fsm > filename_report
report_reference >> filename_report
report_area >> filename_report
report_timing >> filename_report
remove_design find(design, "*")
}
quit
----------cut----------
And here is one of the FSMs which causes the whole job to vanish:
All FSMs are Moore-Machines.
.design fsm_10065
.inputnames clk reset e0 e1
.outputnames a0 a1 a2
.clock clk rising_edge
.asynchronous_reset reset rising q0
01 q0 q2 ~~~
00 q0 q1 ~~~
-- q0 ~ 110
00 q1 q3 ~~~
-- q1 ~ 100
10 q2 q1 ~~~
-- q2 ~ 001
01 q3 q0 ~~~
-- q3 ~ 011
Is this a known problem? Have I done something wrong?
My problem is, that the script stops, when I encounter such a FSM.
--
Bye,
Volker
Celia C.
In article <33BA36...@stud.uni-frankfurt.de>,
Volker Schuetz <vsch...@stud.uni-frankfurt.de> wrote:
>Hi,
>
>I have a problem with the Design Compiler from Synopsys. I'm working
>with Version v3.4a.
>
>I have a bunch of small FSMs in state-table format and I want to compile
>them with Synopsys. But some FSMs make trouble. The Design_Compiler
>vanishes just after beginning the compiling. The whole job is gone and I
>get no error message. The last words are:
>
>"Processing FSMs"
>
>
>My compile_script ist simpel:
>
>----------cut----------
>/* counter ist set some lines above */
>
>All FSMs are Moore-Machines.
>
>.design fsm_10065
>.inputnames clk reset e0 e1
>.outputnames a0 a1 a2
>.clock clk rising_edge
>.asynchronous_reset reset rising q0
>
>01 q0 q2 ~~~
>00 q0 q1 ~~~
>-- q0 ~ 110
>00 q1 q3 ~~~
>-- q1 ~ 100
>10 q2 q1 ~~~
>-- q2 ~ 001
>01 q3 q0 ~~~
>-- q3 ~ 011
>
>Is this a known problem? Have I done something wrong?
>My problem is, that the script stops, when I encounter such a FSM.
>
Hmm.. I don't ever try to input FSMs in state table format. (I don't
really know anyone who does, but it may just be I haven't asked around.)
Generally, I use the following script:
read -format verilog design_name + ".v"
/* Set your constraints here */
compile -no_map
set_fsm_minimize true
/* If you want to change the encoding style, use set_fsm_encoding_style
and set_fsm_encoding {} */
set_fsm_encoding_style one_hot
set_fsm_encoding {}
/* You may need to group the fsm, if there is non-fsm logic in the
module. (Synopsys doesn't always do this correctly, so use at your
own risk) */
group -fsm -design MY_FSM
extract
reduce_fsm
report_fsm > design_name + ".fsm"
write -f st -o design_name + ".st"
/* The fsm must be compiled after extraction. Before recompiling, all you
have is a state table */
compile -map_effort medium
write -format verilog -hier -output design_name + ".vs" design_name
write -format db -hier -output design_name + ".db" design_name
Notice that the FSM encoding is set before Synopsys turns the design into
a state table. (The input design is in Verilog.) Could this be the
problem? Maybe DC needs the netlist to be in db format to change the state
encodings.
You also might want to double check what is legal input in the state
tables. Synopsys may have special constraints on this format. Is there a
reason that you aren't using Verilog or VHDL?
--
-----------------------------------------------------------------------------
--Celia Clause Celia's Verilog/EDA web page:
cel...@teleport.com http://www.teleport.com/~celiac/ver_eda.html
Volker Schuetz
Hi Celia,
> Notice that the FSM encoding is set before Synopsys turns the design into
> a state table. (The input design is in Verilog.) Could this be the
> problem? Maybe DC needs the netlist to be in db format to change the state
> encodings.
Hmm, I don't think, this is a real problem. I can compile enough FSMs
which I
have read in the st-format. I can set the state encoding before
compiling.
> You also might want to double check what is legal input in the state
> tables. Synopsys may have special constraints on this format. Is there a
> reason that you aren't using Verilog or VHDL?
I use the state-table format, because I have only FSMs without non-fsm
logic. My FSMs are generated randomly. So I don't have a behaviour to
write down in verilog or VHDL. I have only the set of transitions and
outputs.
To emphasize my main problem. It is not the compiling of an FSM in
st-format. Most FSMs work fine, but some FSMs kill my DC. Just after
beginning the compiling (regardless if -no_map is set or not), my whole
job disappears. I can live with an error message, because my script
continues with the other FSMs. But actually my script stops if I
encounter such a troublemaking FSM.
I don't understand, why DC can be killed by such a simple FSM.
--
Bye,
Volker
Celia C.
In article <33BCCF...@stud.uni-frankfurt.de>,
Volker Schuetz <vsch...@stud.uni-frankfurt.de> wrote:
>
>To emphasize my main problem. It is not the compiling of an FSM in
>st-format. Most FSMs work fine, but some FSMs kill my DC. Just after
>beginning the compiling (regardless if -no_map is set or not), my whole
>job disappears. I can live with an error message, because my script
>continues with the other FSMs. But actually my script stops if I
>encounter such a troublemaking FSM.
>I don't understand, why DC can be killed by such a simple FSM.
>
Well, it sounds like you will need to send your test case to Synopsys and
have them test the code to get any further with this. It might be a bug in
the tool. It might have some sort of work around.
I wouldn't be too surprised to find out that there is a bug with reading
in some types of FSM in the st format, since there aren't that many people
who use the st format as an input to DC. It may be that no one has run
into this particular bug before.