( ESNUG 251 Item 5 ) -------------------------------------------- [9/12/96]

Subject: (ESNUG 249 #6 250 #5) FSM Treatment Doesn't Seem Coherent

> To check Design Compiler, using an identical FSM coding, I swapped
> the columns of my state coding.  I was sure to get an identical result,
> where the synthesized flipflops (SIG_st_sm_next_reg[0][1][2][3]) just
> changed their order.
> 
>   attribute ENUM_ENCODING of sm_next_state_type : type is 
>   -- order ABCD
>   --   "0011 0010 0001 1010 0000 0100 0101 1101 1100 1011 1111 1001";
>   -- order ADBC
>        "0101 0001 0100 1001 0000 0010 0110 1110 1010 1101 1111 1100";
> 
> I am very unhappy to see that the IDENTICAL synthesis script on an
> IDENTICALLY coded state machine produces DIFFERENT results!


From: Victor Preis <Victor.Preis@zfe.siemens.de>

Hi John,

One possible explanation for the different results could be the handling of
unspecified states.  The example used 12 states.  Coding these states with 4 
bits gives 16 states.  There are diffrent ways of handling the functionality
of these states depending on the modeling style.

Using flatten, Synopsys can otimize the dont care description for these
states.  To generate equivalent results this user must specify equivalent
functionality for these unspecified states.  Otherwise the optimization by
Design Compiler is not predictable.

  - Viktor Preis
    Siemens R&D



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)