I have not use XST, but it is becoming more
attractive.  I have been using
Synplify for many years now, and it works pretty well.  XST has come a long
way, especially now that it appears to have an RTL viewer as well as a
"implementation" (gate level) viewer, which are two features I liked about
Synplify (please correct me if I'm wrong about these features...I believe I
read about them in XCell).  I only do Xilinx work, and I pretty much stick
to Verilog.  I am considering dropping Synplicity and using XST.

What have people's experiences been between XST and Synplify?  Is Synplify
still that much better than the competition, or is XST %95 as good (or
better) than Synplify?

Any comments appreciated.

Regards,

Austin

On Sat, 11 Jun 2005 15:39:11 -0400, Austin
Franklin wrote:

> I have not use XST, but it is becoming more attractive.  I have been using
> Synplify for many years now, and it works pretty well.  XST has come a long
> way, especially now that it appears to have an RTL viewer as well as a
> "implementation" (gate level) viewer, which are two features I liked about
> Synplify (please correct me if I'm wrong about these features...I believe I
> read about them in XCell).  I only do Xilinx work, and I pretty much stick
> to Verilog.  I am considering dropping Synplicity and using XST.
> 
> What have people's experiences been between XST and Synplify?  Is Synplify
> still that much better than the competition, or is XST %95 as good (or
> better) than Synplify?
> 
> Any comments appreciated.
> 
> Regards,
> 
> Austin

I used Synplify for many years but I haven't used it recently. I
switched to XST about a year ago when it got to the good enough
level. XST improves with each release, my gut says that it's pretty close
to Synplify's level at this point.

> I used Synplify for many years but I haven't
used it recently. I
> switched to XST about a year ago when it got to the good enough
> level. XST improves with each release, my gut says that it's pretty close
> to Synplify's level at this point.

Hi Josh,

Thanks for the feedback.  That's pretty much along the lines of my
belief...and the high maintenance cost for Synplify is quite a deterrent to
continuing using it IMO.  I have one design that is running at 280MHz in a
V2, and makes timing with Synplify, and a PCI-X core that makes 100MHz (I'd
like to get it to make 133 though) with Synplify.  I should benchmark these
two and see how XST compares.

Regards,

Austin

"Austin Franklin"
<a...@dark99room.com> schrieb im Newsbeitrag
news:911re.4452$U...@fe06.lga...

> > I used Synplify for many years but I haven't used it recently. I
> > switched to XST about a year ago when it got to the good enough
> > level. XST improves with each release, my gut says that it's pretty
close
> > to Synplify's level at this point.

Recently, I had a design, not really a big deal. Running at 36 and 72 MHz.
XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600 LUTs
to ~ 1200 LUTs). Speed was not the problem, both implementation where fast
enough. But Synplify was more area efficient.
We are using XST only, this was just a test with a real case.

Regards
Falk

Hi Falk,

> Recently, I had a design, not really a big deal. Running at 36 and 72 MHz.
> XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600
LUTs
> to ~ 1200 LUTs). Speed was not the problem, both implementation where fast
> enough. But Synplify was more area efficient.

Interesting.  What versions of the tools were you running?  I'll check the
area use on the current designs I have and see how they compare.

Regards,

Austin

"Austin Franklin" <a...@dark99room.com> schrieb im Newsbeitrag
news:nn3re.2140$e...@fe04.lga...
> Hi Falk,
>
> > Recently, I had a design, not really a big deal. Running at 36 and 72
MHz.
> > XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600
> LUTs
> > to ~ 1200 LUTs). Speed was not the problem, both implementation where
fast
> > enough. But Synplify was more area efficient.
>
> Interesting.  What versions of the tools were you running?  I'll check the
> area use on the current designs I have and see how they compare.

XST 6.2 (Service Pack 3 AFAIK)
SynplifyPRO (Demo licence) 7.1 AFAIK.

Regards
Falk

Austin Franklin (a...@dark99room.com) wrote:
: I have not use XST, but it is becoming more attractive.  I have been using
: Synplify for many years now, and it works pretty well.  XST has come a long
: way, especially now that it appears to have an RTL viewer as well as a
: "implementation" (gate level) viewer, which are two features I liked about

<snip>

Austin,
	The only area where I have any experience of Symplify is looking 
at autogenerated RTL schematics, and unlike my experience with ISE 6.1.xi 
they are correct - ISE 6.1 often misses out entire busses etc that 
actually exist (First time I found that I wasted half an hour thinking 
that synthesis was optimisng the bus away for some reason.) when 
displaying RTL schematics.

Also the visual presentation of the Symplify RTL schematics far suparsed 
that of the Xilinx tools, but then ECS (The schemtic capture/viewer tool 
in the Xilins ISE package(s)) is pretty grotty.  (I'm being polite here)

Maybe things have got better with ISE 7.1.xi?

hth,
cds

Hi C.D.,

I have Synplify 8.1, and have been using Synplify for many years.  I just
loaded the latest 7.1 ISE tools last night (w/ updates), and ran some tests.
I found the RTL/technology viewers in ISE to be pretty decent, though I
hardly tested it out much.  But, from what I saw it is decent enough to
strongly consider not paying $5800 for renewal of my Synplify maintenance.

I'll take a closer look and compare the two side by side.  The RTL and
Technology viewers of Synplify were the biggest festures I liked about the
tool.

Regards,

Austin

"c d saunter" <c...@durham.ac.uk> wrote in message
news:d8kk7d$vp8$1...@heffalump.dur.ac.uk...
> Austin Franklin (a...@dark99room.com) wrote:
> : I have not use XST, but it is becoming more attractive.  I have been
using
> : Synplify for many years now, and it works pretty well.  XST has come a
long
> : way, especially now that it appears to have an RTL viewer as well as a
> : "implementation" (gate level) viewer, which are two features I liked
about
>
> <snip>
>
> Austin,
> The only area where I have any experience of Symplify is looking
> at autogenerated RTL schematics, and unlike my experience with ISE 6.1.xi
> they are correct - ISE 6.1 often misses out entire busses etc that
> actually exist (First time I found that I wasted half an hour thinking
> that synthesis was optimisng the bus away for some reason.) when
> displaying RTL schematics.
>
> Also the visual presentation of the Symplify RTL schematics far suparsed
> that of the Xilinx tools, but then ECS (The schemtic capture/viewer tool
> in the Xilins ISE package(s)) is pretty grotty.  (I'm being polite here)
>
> Maybe things have got better with ISE 7.1.xi?
>
> hth,
> cds
>
>

In article
<3...@individual.net>,
Falk Brunner <F...@gmx.de> wrote:
>"Austin Franklin" <a...@dark99room.com> schrieb im Newsbeitrag
>news:911re.4452$U...@fe06.lga...

>> > I used Synplify for many years but I haven't used it recently. I
>> > switched to XST about a year ago when it got to the good enough level.
>> > XST improves with each release, my gut says that it's pretty close to
>> > Synplify's level at this point.

>Recently, I had a design, not really a big deal. Running at 36 and 72 MHz.
>XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600 LUTs
>to ~ 1200 LUTs). Speed was not the problem, both implementation where fast
>enough. But Synplify was more area efficient.
>We are using XST only, this was just a test with a real case.

I'm having the same experience: Synplify_pro 8.1 uses 97% (map with -tx on)
of an XC2V6000 (which "map" with "-tx on -timing" actually can close
timing
on), whereas XST 5.2 uses 102% (no -tx on).  I think Synplify's CSE (or
"resource sharing") is better.  The difference in price between an XC2V8000
and an XC2V6000 more than covers Synplicity's fee.  On the other hand, XST
and Synplicity seem to be on par as far as the resulting design's speed. 

One big annoyance: attributes use a completely different concept between the
two tools: Synplicity, following verilog tradition, associates attributes by
position within a comment before the ; of an instantiation.  XST follow VHDL
and associates them by name: the comment can be anywhere in the file.  But
now that I have my conversion script, this is no big deal.  XST uses
data_bus<1> and Synplicity uses data_bus[1].  XST flattens the hierarchy,
Synplicity doesn't (earlier versions used to).  All of this makes the .ucf
file fun.

We are not using later versions of XST due to answer record #16808 (casex
doesn't always make correct code)- I'd like to try 7.1i, but it wont work on
RedHat 7.3.  Synplify 8.1 (their latest) does work in RedHat 7.3. Also code
errors which XST 5.2 allows cause XST 6.1 - 6.3 to core dump- which makes it
difficult to find the error.  Note that we have to run XST 5.2i in wine (but
we then run place & route with 6.2isp3).

Other issues: synplicity runs about 33% faster, but sometimes for larger
designs it is much faster.  I think we are hitting some exponential time
algorithm in XST.

The error reporting from Synplify is much better than XST:

// XST gives no error
output [5:0] foo;
reg [4:0] foo;

// XST gives no error: two always blocks writing to the same signal when the
// signal gets optimized out because nobody is readying it.
reg x;

always @(posedge clk or negedge reset_l)
  if (!reset_l)
    x <= 0;

always @(posedge clk or negedge reset_l)
  if (!reset_l)
    x <= 0;
  else
    x <= y;

-- 
/*  j...@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n","
#"[!a[q-1]]);}

On Mon, 13 Jun 2005 20:51:55 +0000, Joseph H
Allen wrote:

> In article <3...@individual.net>,
> Falk Brunner <F...@gmx.de> wrote:
>>"Austin Franklin" <a...@dark99room.com> schrieb im Newsbeitrag
>>news:911re.4452$U...@fe06.lga...
> 
>>> > I used Synplify for many years but I haven't used it recently. I
>>> > switched to XST about a year ago when it got to the good enough level.
>>> > XST improves with each release, my gut says that it's pretty close to
>>> > Synplify's level at this point.
> 
>>Recently, I had a design, not really a big deal. Running at 36 and 72 MHz.
>>XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600 LUTs
>>to ~ 1200 LUTs). Speed was not the problem, both implementation where fast
>>enough. But Synplify was more area efficient.
>>We are using XST only, this was just a test with a real case.
> 
> I'm having the same experience: Synplify_pro 8.1 uses 97% (map with -tx on)
> of an XC2V6000 (which "map" with "-tx on -timing" actually can
close timing
> on), whereas XST 5.2 uses 102% (no -tx on).  I think Synplify's CSE (or
> "resource sharing") is better.  The difference in price between an
XC2V8000
> and an XC2V6000 more than covers Synplicity's fee.  On the other hand, XST
> and Synplicity seem to be on par as far as the resulting design's speed. 
> 
> One big annoyance: attributes use a completely different concept between the
> two tools: Synplicity, following verilog tradition, associates attributes by
> position within a comment before the ; of an instantiation.  XST follow VHDL
> and associates them by name: the comment can be anywhere in the file.  But
> now that I have my conversion script, this is no big deal.  XST uses
> data_bus<1> and Synplicity uses data_bus[1].  XST flattens the hierarchy,
> Synplicity doesn't (earlier versions used to).  All of this makes the .ucf
> file fun.
> 
> We are not using later versions of XST due to answer record #16808 (casex
> doesn't always make correct code)- I'd like to try 7.1i, but it wont work on
> RedHat 7.3.  Synplify 8.1 (their latest) does work in RedHat 7.3. Also code
> errors which XST 5.2 allows cause XST 6.1 - 6.3 to core dump- which makes it
> difficult to find the error.  Note that we have to run XST 5.2i in wine (but
> we then run place & route with 6.2isp3).
> 
> Other issues: synplicity runs about 33% faster, but sometimes for larger
> designs it is much faster.  I think we are hitting some exponential time
> algorithm in XST.
> 
> The error reporting from Synplify is much better than XST:
> 
> // XST gives no error
> output [5:0] foo;
> reg [4:0] foo;
> 
> // XST gives no error: two always blocks writing to the same signal when the
> // signal gets optimized out because nobody is readying it.
> reg x;
> 
> always @(posedge clk or negedge reset_l)
>   if (!reset_l)
>     x <= 0;
> 
> always @(posedge clk or negedge reset_l)
>   if (!reset_l)
>     x <= 0;
>   else
>     x <= y;

There are switches in the XST script for controlling things like hierarchy
flattening and bus delimiters. There is an issue with case statements
doing something unexpected if you don't have a default, the solution is to
always have a default: in every case statement, this is the correct thing
to do anyway.

I played around with XST's switches until I was happy with the results.
XST's switches can make a big difference in the size and speed of the
final results. Here are the switches from one of my scripts,


run
-ifn loopback_m325_sma.xprj
-ifmt Verilog
-ofn loopback_m325_sma.ngc
-top loopback_m325_sma
-ofmt NGC
-p xc2vp70-6-ff1704
-opt_mode SPEED
-opt_level 1
-max_fanout 32
-keep_hierarchy no
-register_duplication YES
-equivalent_register_removal no
-hierarchy_separator /
-bus_delimiter <>
-mux_extract YES
-mux_style MUXF
-ram_extract YES
-ram_style Auto
-rom_extract YES
-rom_style Distributed
-verilog2001 NO
-vlgcase Full-Parallel
-decoder_extract YES
-priority_extract YES
-shreg_extract YES
-shift_extract YES
-xor_collapse YES
-resource_sharing YES
-iobuf NO
-register_balancing no
-slice_packing Yes
-glob_opt max_delay
-fsm_encoding Compact