( ESNUG 276 Item 2 ) ----------------------------------------------- [1/7/97]
Subject: (ESNUG 275 #2) FSM Extraction/Synthesis with Synopsys FSM Compiler
> I get much better timing results in both ASICs and FPGAs when I extract
> the FSM and use one-hot encoding. Of course, the area grows.
>
> - Frederick K. Best
> Lockheed Martin Electronics and Missiles
From: cgregory@hns.com (Chris Gregory)
John,
I have recently played with the fsm extraction tool in the FPGA
compiler. I cannot stress enough that, in my experience, writing good HDL
in the beginning is more valuable than letting the compiler do any
automatic optimization. I experienced virtually no improvement when
extracting fsms. I had a couple cases where the extracted and recompiled
fsm turned out to be significantly larger and did not improve the
performance.
I think if I had very rigerously constrained my design I could have
gotten good results from extraction but in my situation I didn't need
terribly tight timing constraints. It should be noted that mine was a
special case because I was trying to reduce AREA not speed of my fsm in
order to fit into an FPGA. Since Synopsys is primarily an ASIC tool I
don't think it tries terribly hard to optimize logic such that it fits into
the smallest number of FPGA cells. It seems to do mostly boolean
optimization and then it quits as soon as the timing is met -- even when I
set_max_area to zero.
(I know a lot of you are saying "why the hell would anyone go to so
much trouble to fit into an FPGA when you could just get a bigger part".
In my situation this was a board that was designed 5 years ago and I had to
make an FPGA modification without changing the existing artwork and there
weren't any pin compatible solutions that were anywhere close in price.)
By experimenting with different state encoding patterns in my HDL, I
was able to reduce the combo logic and subsequently the number of FPGA
LUTs. Strangely enough, when I used the exact same encoding patterns with
the set_fsm_encoding command in Synopsys, my results were not as good.
One last comment about the fsm tools, the state table format is
incredibly difficult to use with even a moderately sized fsm. I attempted
at one point to write my fsm from scratch in state table format ....... I
shot that idea down PDQ.
- Chris Gregory
Hitachi Network Systems
---- ---- ---- ---- ---- ---- ----
From: [ I Am Paranoid ]
Hi, John,
No name please. I am paranoid.
I tried several things with FSM compiler in the past, and I'd like to put
my two cents into this matter.
My experience tells me that the best coding style follows the guidelines
described in Synopsys manuals (Design Compiler Reference, HDL Compiler
for Verilog, etc). Basically, the FSM should be in a module by itself,
the only flip-flops there should be those containing state info, and
all necessary directives (enum state_info, state_vector, etc) are used.
When the guidelines are followed, the extraction is very simple; otherwise,
the result depending on how much effort one spends on seperating the
FSM logic from other codes.
After extraction things get a little tricky. In general I observe these
three problems: undefined output can limit DC, large FSM can become
worse, and DC can't find an optimal state encoding.
Sometimes I leave an output X to give DC more freedom in optimization, but
this always requires extra work after extraction. The reason is during
compile the X is used to optimized the original state encoding, which is
often binary. Since compile and extract turn all X into 0 and 1, DC has
less freedom when choosing new state encoding. To work around this one
must write out the FSM into a state table, edit the table, and read it
back in. Not an easy task.
I don't know how hard DC tries to optimize the FSM, but my guess is not
very hard. I had a FSM with 40+ states once. It basically controlls the
CAS and RAS and bursts data from DRAM. It has very few outputs, and
there are no branches. Just out of curiosity I tried one-hot encoding,
gray-code encoding, binary encoding, and whatevery DC chooses. I found
that binary encoding and gray-code encoding yield approximately the same
result, but the encoding DC chose had about the same area as one-hot
encoding (and slower). After some more experiments I found that DC
can't do a good job starting around 20 states. Some FSM got bigger, some
had less-than-optimal encoding, and some did both.
From these observations I concluded that there is not a significant
advantage using FSM compiler. For now, I follow the guidelines when
coding, but I don't modify existing codes to meet the guidelines. When
a state machine is large, I select an encoding method rather than let
DC decide. And if I have lots of x, I run simulations to extract a
state table, and use the table instead of compile-extract.
And finally, if easy-to-read code is the top priority, then by all means
follow the guidelines. They make the codes a lot easier to understand.
- [ I Am Paranoid ]
|
|
