Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 32275

Article: 32275
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Ray Andraka <ray@andraka.com>
Date: Thu, 21 Jun 2001 20:58:47 GMT
Links: << >>  << T >>  << A >>
In my case, the xorcy's and muxcy's stayed, but the logic in the LUT (which was
fmapped using the XC_LUT attribute) was dissolved and redistributed between the
LUT and a new lut inserted between the xorcy and the FDE.  In this case it is an
adder with one input gated.  In the process of trying to develop a test case I
discovered that it only does this if synplicity thinks that you won't meet
timing otherwise.  If the gate signal is local only or the cycle time is set low
enough, it leaves the instantiation alone.  If it thinks it won't meet it
though, it apparently goes in and diddles the design to something it thinks is
better.  In this case, I had a control on the gate that comes from a fairly high
fanout, timing doesn't matter control bit that was not called out in the
synplicity timing constraints.

In order to reproduce the problem for the synplicity folks, I had to put an
artificial long delay on the adder's gate input by using a big combinatorial
function.

In my opinion, If I instantiate something, there is a reason I am doing it, and
I don't want the tools changing it on me, especially without a warning or an
easy way of disabling such 'optimizations'.

BTW, I don't believe 5.3.1 did this, as I didn't have problems with the same
design before.

John_H wrote:

> I've seen logic tossed in between my XORCY and the flop, but my primitives
> never got synthesized out.  When I manually enter the carry chain, I still
> have my MUXCY and XORCY elements but sometimes other stuff gums up the
> works.  In my case, a synchronous reset ended up as LUTs between the XORCY
> and the flop but - the really weird thing - I couldn't reproduce the problem
> for the synplify apps folks.  The problem "went away."  Maybe I missed a
> subtle coding change.
>
> Check to make sure the ins/outs are what you expect with your primitives and
> that certain primitives with valid outputs really do disappear;  in all the
> hand-coding I've done to force the efficiencies, I haven't come across an
> "illegitimate" optimization of my primitives.
>
> Isn't coding in primitives such fun ?!
> - John
>
> Ray Andraka wrote:
>
> > Synplicity 6.2 is "optimizing" an instantiated design.  In particular, I
> >
> > have a design with instantiated Xilinx primitives including a carry
> > chain.  The synthesis is apparently flattening the xilinx primitives and
> >
> > doing its own optimization on them, which results in a multiplexer
> > placed between the xorcy and the flip-flop.  When I instantiate
> > primitives, I don't expect to see them remapped.  I didn't see this
> > happening in 5.3.1.  The instantiated primitives have a syn_black_box
> > attribute on them.   This new 'feature' makes Synplicity useless for the
> >
> > designs I am doing, and actually does damage for the large base I have
> > already fielded.
> >
> > Has anyone else seen this?  Any fixes?
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32276
Subject: Re: FFT limited size input
From: Ray Andraka <ray@andraka.com>
Date: Thu, 21 Jun 2001 21:03:40 GMT
Links: << >>  << T >>  << A >>
Our 16 point core occupies a 20x25 CLB rectangle in SpartanII/Virtex/VirtexE
devices.  A single instance will run at 150 Megasamples/sec in Virtex-4, and
at 250 MS/s in a VirtexE-8.  Note that it is small enough to fit in a V100.

Tom Dillon wrote:

> We have a parametric FFT core available that can be configured for any
> (power of 2) length. FFT.
>
> The VHDL or Verilog code to be synthesized is auto-generated from our
> Parametric System Builder tools so that the FFT can run as fast as you
> need, only limited by available logic in the target device.
>
> How fast does your 16 point FFT need to operate?
>
> Regards,
>
> Tom Dillon
> Dillon Engineering, Inc.
> http://www.dilloneng.com
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 6/21/2001, 7:05:04 AM, finishf@yahoo.com (finish) wrote regarding FFT
> limited size input:
>
> > hello,
>
> > From my modest background, i know that for performing the FFT
> > transform on an input signal, i have to extend it, if required, by
> > zeros to 2^n.
> > FFT is a global transform,i.e the whole input sequence should be
> > available.
>
> > In practise, most often we take 1024 or 512, but i see some commercial
> > hardware implementation for just 16 input data.
>
> > How far will this limited input size transform affect the overall
> > performance ?
>
> > thanks
>
> > H.S

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32277
Subject: Re: Synplify register replication
From: "qlyus" <qlyus@yahoo.com>
Date: Thu, 21 Jun 2001 21:32:49 GMT
Links: << >>  << T >>  << A >>
Keep the copies of Synplify v6.13 and v6.20.  Never try v6.24

I have had an outstanding case with Synplify v6.24 since it was released.
After I installed it over v6.20, my Xilinx-e design stopped working.  It
took me hours to figure out it was the newly installed Synplify v6.24
causing the problems.  I sent Synplicity my design files and was promised to
have answer or fix soon.  Instead, they told me to try v7.0 beta-1 3 weeks
later when I asked about the case again.  It seems to me that they would
never fix the problem.  I will not try any new version until they find the
problem and fix it.

Another experience with Synplicity was about no 50% duty cycle clock with
dual edges in design.  It never take no 50% duty cycle information specified
in sdc file and outputs it into .ncf file.  The tech support finally
admitted it is a problem.  But I still do not know if they are going to fix
it in newer version.  I have to manually delete the .ncf file every time I
move to back-end place & route.

I have been thinking to switch back to Synopsys because I have full version
of Xilinx Foundation.   Synopsys is slower in synthesis, its schematic view
is not really viewable.  But it at least synthesizes correctly and you only
focus on your RTL code whenever there is problem, instead of chasing the
ghost as I did with Synplicity.




"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3B30DE80.F8170AF2@algor.co.uk...
>
> Has anybody else found that register replication seems to be at least
> partly broken for Synplify 6.x.y ? At least for Xilinx devices. I have a
> case outstanding and a bug report has been filed that shows some FF
> primitives get replicated while others don't.
>
> <flame on>
>
> Its a bit sad that Synplicity's support has suffered the usual post-IPO
> syndrome:
>
> o Pre-IPO company is hungry for fame & fortune and will really sweat it
> to get a good reputation among us geeks.
>
> o IPO happens and all those engineers who made it happen suddenly
> realise the joys that can be theirs when they combine stock opts with
> Pacific islands and go for the ``No unit of time less than a season''
> option.
>
> o To placate all their new NASDAQ investors a road-map to taking over
> the universe is promoted.
>
> o Universe capture requires so much effort/money/time that the
> conditions on planet earth start to deteriorate.
>
> o Unrecognised the geek world starts looking for new lean & hungry
> startups and drifting in their direction.
>
> o Too late the company finds that (a) somebody already owns the universe
> and (b) the customer base has now been hollowed out.
>
> Synplify as a tool is still in the v. good to great range but the signs
> of post-IPO megalomania are clearly there.
>
> <flame off, or at least turned down a bit>
>
>



Article: 32278
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 21 Jun 2001 22:45:33 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> In my case, the xorcy's and muxcy's stayed, but the logic in the LUT (which was
> fmapped using the XC_LUT attribute) was dissolved and redistributed between the
> LUT and a new lut inserted between the xorcy and the FDE.  In this case it is an
> adder with one input gated.  In the process of trying to develop a test case I
> discovered that it only does this if synplicity thinks that you won't meet
> timing otherwise.  If the gate signal is local only or the cycle time is set low
> enough, it leaves the instantiation alone.  If it thinks it won't meet it
> though, it apparently goes in and diddles the design to something it thinks is
> better.  In this case, I had a control on the gate that comes from a fairly high
> fanout, timing doesn't matter control bit that was not called out in the
> synplicity timing constraints.
>
> In order to reproduce the problem for the synplicity folks, I had to put an
> artificial long delay on the adder's gate input by using a big combinatorial
> function.
>
> In my opinion, If I instantiate something, there is a reason I am doing it, and
> I don't want the tools changing it on me, especially without a warning or an
> easy way of disabling such 'optimizations'.
>
> BTW, I don't believe 5.3.1 did this, as I didn't have problems with the same
> design before.
>

Combining this with my much more minor quibble about register replication its
beginning to look like some screw-ups have happened in 6.x.x. And it happens just
after Synplicity support seems to have been born again as Trappists.

Ray: Are you seeing this in Syn or SynPRO or both ?


Article: 32279
Subject: Re: LFSR Taps for 64 bit registers?
From: "Subbu Meiyappan" <msubbu@cisco.com>
Date: Thu, 21 Jun 2001 15:05:49 -0700
Links: << >>  << T >>  << A >>
Pick up any Error Control Coding / Algebraic coding book (for example Lin
and Costello or Wicker) and their
appendices usually have the minimal polynomials for different lengths.

HTH,
Subbu
"Dave Feustel" <dfeustel@mindspring.com> wrote in message
news:9ec4nt$ipc$1@slb6.atl.mindspring.net...
> I'm looking for taps for 64-bit linear feedback shift registers.
> Can someone post either values for such taps or a source
> of information for generating the taps?
>
> Thanks,
>
> Dave Feustel
> Fort Wayne, Indiana
>
>



Article: 32280
Subject: Re: Synplify register replication
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 21 Jun 2001 23:16:34 +0100
Links: << >>  << T >>  << A >>


qlyus wrote:

> Keep the copies of Synplify v6.13 and v6.20.  Never try v6.24
>

<snip>

Just reverted to 6.13 & the replication problem is still there. I don't have an
installed version of 6.2.0.

I'm not really complaining about the bug(s), they're tedious but that's life
when using binary EDA tools. What is getting to me is the lack of response.

I'm beginning to wonder if some legislation enforcing a Xilinx-style publicly
accessible answers database [bug list] on all EDA & chip suppliers is becoming
necessary. A car maker couldn't get away with putting the steering wheel in the
trunk and the spare in front of the driver so why can EDA vendors get away with
the equivalent and then hide behind NDAs or a support system with the reflexes
of a stoned dinosaur ?


Article: 32281
Subject: Xilinx: Download times with Parallel/Multilinx cable
From: andrewkrenz@hotmail.com (Andrew Krenz)
Date: 21 Jun 2001 15:26:09 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm currently using the Xilinx Parallel Cable III to download a
Virtex-E bitstream using the JTAG chain.  It takes about 10 minutes to
complete the download (four V3200Es and a V1000E).  Two questions:

1) Would the download time be any faster if I used the standard
configuration chain (DIN/DOUT/CCLK/etc) vs. using the JTAG chain?

2) Would the download time be any faster if I used the USB-based
Multilinx cable instead of the Parallel Cable?

Thanks,
Andrew

Article: 32282
Subject: Re: NT vs W2K (WAS Re: Pin locking in Maxplus2)
From: Keith R. Williams <krw@attglobal.net>
Date: Thu, 21 Jun 2001 18:52:50 -0400
Links: << >>  << T >>  << A >>
In article <3B32288B.FE618E6C@andraka.com>, ray@andraka.com says...
> I realize the benefits of win2k, but it doesn't do me any good if the design tools are not
> stable running under 2k.  Last year when I tried running win2k, I had numerous problems with
> xilinx alliance, synplicity, modelsim and others.  If I can't run those reliably, then I can't
> migrate to the new OS.
> 
> So my question still remains.  Are these applications  now stable under 2K?

I've been running this tool-chain (SynplifyPro, Amplify, ModelSimPE, 
and Alliance 3,3i) on this ThinkPad A21p with vanilla Win2K since early 
January.  The only real problem I've had was with the Synplify license 
manager. Synplify would lose contact with the dongle and crash, 
requiring a reboot to restart Synplify.  This was fixed with an update 
in March(IIRC that's when they figured out the problem - though the 
driver was available long before).  

The only other problem I've had was with one release of ModelSim (I 
believe it was 5.4C).  It would crash as soon as I tried to rewind for 
another sim run. I simply skipped 5.4C and went on to 5.4d, which fixed 
the problem (ModelSim seems to have had a lot of memory leak problems).

Other than these problems the tool chain has been extremely stable 
under Win2K, at least for me. ...so much so that I'm afraid to put on 
the Win2K fixpacks.  I'm sure you hit the tools a lot harder than I  
though.


----
  Keith R. Williams
  PowerPC Development
  IBM Microelectronics
  Burlington Vermont


Article: 32283
Subject: Re: what tools run OK on windows 2000?
From: Keith R. Williams <krw@attglobal.net>
Date: Thu, 21 Jun 2001 18:52:52 -0400
Links: << >>  << T >>  << A >>
In article <3B3231B9.7DCFBCF6@aracnet.com>, eteam@aracnet.com says...
> Your friends and colleagues need you!
> 
> Time for an ad-hoc poll of the audience:
> 
> Please reply if you have *first-hand* experience (go or no-go) running design tool XXXX
> [simulater | synthesiser | fpga-back-end-design | schematic capture | version control system | etc. ]
> on a windows 2000 professional sytsem.
> 
> Please reply (to the newsgroup) with :  tool name, GO - NO-GO result, tool SW version.

OrCadCapture     GO   9.10.157 (used for boards only)
SynplifyPro      GO   6.1.3
Amplify          GO   2.1.3
ModelSimPE       GO   5.4D
Alliance         GO   3.3.07i

...and no, I'm *not* going to WinXP (at least until I start a new 
project).

----
  Keith R. Williams
  PowerPC Development
  IBM Microelectronics
  Burlington Vermont


Article: 32284
Subject: Re: Xilinx: Download times with Parallel/Multilinx cable
From: "qlyus" <qlyus@yahoo.com>
Date: Fri, 22 Jun 2001 00:39:08 GMT
Links: << >>  << T >>  << A >>

"Andrew Krenz" <andrewkrenz@hotmail.com> wrote in message
news:58dc9734.0106211426.5e263ad6@posting.google.com...
> Hi,
>
> I'm currently using the Xilinx Parallel Cable III to download a
> Virtex-E bitstream using the JTAG chain.  It takes about 10 minutes to
> complete the download (four V3200Es and a V1000E).  Two questions:
>

For four V3200Es and a V1000E, 10min is normal for Parallel Cable III, as I
figure.  I did not record the time for our 4 V2000Es.  But I think it is
close to about 5min.

> 1) Would the download time be any faster if I used the standard
> configuration chain (DIN/DOUT/CCLK/etc) vs. using the JTAG chain?

I do not know, but one thing is sure, it would be much faster if the devices
are loading from EEPROMs, even in serial mode with default 4MHz.

>
> 2) Would the download time be any faster if I used the USB-based
> Multilinx cable instead of the Parallel Cable?

It would be 10 times slower than Parallel Cable III.

BTW, does anybody notice XIlinx SP8 slows down Parallel Cable III quite a
bit?

>
> Thanks,
> Andrew



Article: 32285
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Ray Andraka <ray@andraka.com>
Date: Fri, 22 Jun 2001 01:10:13 GMT
Links: << >>  << T >>  << A >>
I'm using the Synplicity 'amateur' (as opposed to pro) version.  The extra features of
the Pro did not justify the costs for me.  I wouldn't be surprised to see Pro doing
the same thing though.

Synplicity was able to duplicate the problem with my test case, and they acknowledged
that it is a problem.  No official workaround, however in my playing with it I came up
with the following possibilities:

1) put a timing constraint in the synplicity constraints that allows more time for the
non critical control
2) register the input immediately before the adder
3) compile the macro separately then instantiate it as a black box
4) reduce the clock frequency constraint for synplicity, then put it at what you want
for the xilinx tools

Still, it is a pain in the but thing that should be fixed.  Like I said before, if I
go through the trouble of instantiating something, I don't expect the tools to go in
and diddle with my masterpiece.


Rick Filipkiewicz wrote:

> Ray Andraka wrote:
>
> > In my case, the xorcy's and muxcy's stayed, but the logic in the LUT (which was
> > fmapped using the XC_LUT attribute) was dissolved and redistributed between the
> > LUT and a new lut inserted between the xorcy and the FDE.  In this case it is an
> > adder with one input gated.  In the process of trying to develop a test case I
> > discovered that it only does this if synplicity thinks that you won't meet
> > timing otherwise.  If the gate signal is local only or the cycle time is set low
> > enough, it leaves the instantiation alone.  If it thinks it won't meet it
> > though, it apparently goes in and diddles the design to something it thinks is
> > better.  In this case, I had a control on the gate that comes from a fairly high
> > fanout, timing doesn't matter control bit that was not called out in the
> > synplicity timing constraints.
> >
> > In order to reproduce the problem for the synplicity folks, I had to put an
> > artificial long delay on the adder's gate input by using a big combinatorial
> > function.
> >
> > In my opinion, If I instantiate something, there is a reason I am doing it, and
> > I don't want the tools changing it on me, especially without a warning or an
> > easy way of disabling such 'optimizations'.
> >
> > BTW, I don't believe 5.3.1 did this, as I didn't have problems with the same
> > design before.
> >
>
> Combining this with my much more minor quibble about register replication its
> beginning to look like some screw-ups have happened in 6.x.x. And it happens just
> after Synplicity support seems to have been born again as Trappists.
>
> Ray: Are you seeing this in Syn or SynPRO or both ?

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32286
Subject: Re: LFSR Taps for 64 bit registers?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 22 Jun 2001 01:19:28 GMT
Links: << >>  << T >>  << A >>
If you need just one feedback combination, one of the xilinx app notes lists
the feedback taps for LFSRs from 3 bits to 168 bits.  I think it is XAPP052,
but my memory might not be accurate.  I do have a link directly to the app
note on the links page of my website.

Subbu Meiyappan wrote:

> Pick up any Error Control Coding / Algebraic coding book (for example Lin
> and Costello or Wicker) and their
> appendices usually have the minimal polynomials for different lengths.
>
> HTH,
> Subbu
> "Dave Feustel" <dfeustel@mindspring.com> wrote in message
> news:9ec4nt$ipc$1@slb6.atl.mindspring.net...
> > I'm looking for taps for 64-bit linear feedback shift registers.
> > Can someone post either values for such taps or a source
> > of information for generating the taps?
> >
> > Thanks,
> >
> > Dave Feustel
> > Fort Wayne, Indiana
> >
> >

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32287
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 22 Jun 2001 02:43:17 GMT
Links: << >>  << T >>  << A >>
On Fri, 22 Jun 2001 01:10:13 GMT, Ray Andraka <ray@andraka.com> wrote:

>I'm using the Synplicity 'amateur' (as opposed to pro) version.  The extra features of
>the Pro did not justify the costs for me.  I wouldn't be surprised to see Pro doing
>the same thing though.
>
>Synplicity was able to duplicate the problem with my test case, and they acknowledged
>that it is a problem.  No official workaround, however in my playing with it I came up
>with the following possibilities:
>
>1) put a timing constraint in the synplicity constraints that allows more time for the
>non critical control
>2) register the input immediately before the adder
>3) compile the macro separately then instantiate it as a black box
>4) reduce the clock frequency constraint for synplicity, then put it at what you want
>for the xilinx tools
>
>Still, it is a pain in the but thing that should be fixed.  Like I said before, if I
>go through the trouble of instantiating something, I don't expect the tools to go in
>and diddle with my masterpiece.

Hey Ray,

I assume you are using Virtex, Virtex-E or Virtex-2.

Did you use the unisim library, or the Synplify specific "virtex"
library?

In the past I've had problems (with 6.0.0 pro) getting the tool to
correctly "black box" entities if I was using the virtex library.  It
seems that the names of the primitives are "special-cased" inside the
tool.  My fix was to change over to using the unisim library, which
then forced synplify to treat the xilinx primitives as true black
boxes, i.e. it doesn't mess with them.

Regards,
Allan.

Article: 32288
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Ray Andraka <ray@andraka.com>
Date: Fri, 22 Jun 2001 03:44:50 GMT
Links: << >>  << T >>  << A >>
It is using the Unisims.  I had the same trouble with the synplicity virtex library.  Using
the unisims also makes simulation easier.  All the components are black-boxed and the
unisims library declaration is removed for synthesis using the pragmas.  A snippet of the
code follows.  This had worked until now (I just installed 6.2.4 before starting this
design, and the offending adder is part of an existing library I've been using for close to
2 years).  Previously, the synthesizer left the black-boxed unisims alone, but now it
doesn't.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
--synthesis translate_off
library unisim;
use unisim.all;
--synthesis translate_on
library work;
use work.rlocs.all;

entity addlqe is
 port (
  clk: in STD_LOGIC;
  ce: in STD_LOGIC;
  cin: in STD_LOGIC;
  a: in STD_LOGIC_VECTOR;
  b: in STD_LOGIC_VECTOR;
  agate_n: in STD_LOGIC;
  co: out STD_LOGIC;
  q: out STD_LOGIC_VECTOR
 );
 constant width: natural:= q'length;
end  addlqe;

architecture Virtex_struct of  addlqe is
  attribute syn_black_box:boolean;
 -- Component declaration of the "fmap_and2_and2_xor2(rtl)" unit
 -- File name contains "fmap_and2_and2_xor2" entity: .\src\fmap_logic.vhd
 component fmap_andb1_xor2
 port(
  a0_n : in std_logic;
  a1 : in std_logic;
  b : in std_logic;
  z : out std_logic);
 end component;

 component mult_and
 port(
  LO : out std_ulogic;
  I1 : in std_ulogic;
  I0 : in std_ulogic);
 end component;
  attribute syn_black_box of MULT_AND : component is true;

 component MUXCY
  port (CI,DI,S : in std_logic;
    O : out std_logic);
 end component;
  attribute syn_black_box of MUXCY : component is true;



Allan Herriman wrote:

> On Fri, 22 Jun 2001 01:10:13 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >I'm using the Synplicity 'amateur' (as opposed to pro) version.  The extra features of
> >the Pro did not justify the costs for me.  I wouldn't be surprised to see Pro doing
> >the same thing though.
> >
> >Synplicity was able to duplicate the problem with my test case, and they acknowledged
> >that it is a problem.  No official workaround, however in my playing with it I came up
> >with the following possibilities:
> >
> >1) put a timing constraint in the synplicity constraints that allows more time for the
> >non critical control
> >2) register the input immediately before the adder
> >3) compile the macro separately then instantiate it as a black box
> >4) reduce the clock frequency constraint for synplicity, then put it at what you want
> >for the xilinx tools
> >
> >Still, it is a pain in the but thing that should be fixed.  Like I said before, if I
> >go through the trouble of instantiating something, I don't expect the tools to go in
> >and diddle with my masterpiece.
>
> Hey Ray,
>
> I assume you are using Virtex, Virtex-E or Virtex-2.
>
> Did you use the unisim library, or the Synplify specific "virtex"
> library?
>
> In the past I've had problems (with 6.0.0 pro) getting the tool to
> correctly "black box" entities if I was using the virtex library.  It
> seems that the names of the primitives are "special-cased" inside the
> tool.  My fix was to change over to using the unisim library, which
> then forced synplify to treat the xilinx primitives as true black
> boxes, i.e. it doesn't mess with them.
>
> Regards,
> Allan.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32289
Subject: Re: Xilinx Software free
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Fri, 22 Jun 2001 08:57:58 +0200
Links: << >>  << T >>  << A >>
Hi Antonio,

you should try the Xilinx WebPack Software. It's free and it supports
all Xilinx CPLDs and SpartanII FPGAs. It comes with full VHDL and
Verilog support. You can also use a special version of ModelSim.

The software is nearly identical to the Xilinx Foundation ISE software,
but with less supported devices !

Matthias
-- 
-------------------------------------------------
\ Matthias Fuchs                                 \
 \ esd electronic system design Gmbh              \
  \ Vahrenwalder Straße 205                        \
   \ D-30165 Hannover                               \
    \ email: matthias.fuchs@esd-electronics.com      \
     \ phone: +49-511-37298-0                         \
      \ fax:   +49-511-37298-68                        \
       --------------------------------------------------

Article: 32290
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 22 Jun 2001 08:21:29 +0100
Links: << >>  << T >>  << A >>


Allan Herriman wrote:

> Hey Ray,
>
> I assume you are using Virtex, Virtex-E or Virtex-2.
>
> Did you use the unisim library, or the Synplify specific "virtex"
> library?
>
> In the past I've had problems (with 6.0.0 pro) getting the tool to
> correctly "black box" entities if I was using the virtex library.  It
> seems that the names of the primitives are "special-cased" inside the
> tool.  My fix was to change over to using the unisim library, which
> then forced synplify to treat the xilinx primitives as true black
> boxes, i.e. it doesn't mess with them.
>
> Regards,
> Allan.

Did you have to hack the unisims lib in any way e.g. by adding ``syn_black_box'' or will
the `celldefine/`endcelldefine (or VHDL equivalent) get picked up by the synthesiser ?


Article: 32291
Subject: Re: Verilog or VHDL?
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Fri, 22 Jun 2001 00:31:42 -0700
Links: << >>  << T >>  << A >>
Brian_Sullivan wrote:
> 
> Hi,
> 
snip
> Second, Verilog has just (within the past year) allowed for double
> indexing on arrays.  So the RAM arrays can now be ram[255:0][7:0].
> VHDL has allowed this for years (actually you could pretty much always
> do it with user defined types).  In the past, that same RAM in Verilog
> would have to be ram[2047:0] and you would have to keep the slices
> straight in your head.

what's wrong with,  reg [7:0] ram[255:0]; ?

-Lasse
-- Lasse Langwadt Christensen, 
-- A Dane in Phoenix, Arizona

Article: 32292
Subject: Re: what tools run OK on windows 2000?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 22 Jun 2001 08:32:58 +0100
Links: << >>  << T >>  << A >>


"Keith R. Williams" wrote:

<snip>

> ...and no, I'm *not* going to WinXP (at least until I start a new
> project).
>

... aren't you concerned that your XP system would be open to any hacker from age 10-100 ?

Looking at the reports on XP I think it should be renamed, in the spirit of 56-bit DES, Win-NSA. They no
longer need to fight against strong encryption since they can just come on over & help themselves to your
keys.

Why not go Linux instead ?



Article: 32293
(removed)


Article: 32294
Subject: Re: Two's Complement conversion for FIR coefficients
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Fri, 22 Jun 2001 10:03:57 +0200
Links: << >>  << T >>  << A >>
Hi

If you're working with fixed point in FPGA, the best way to
perform 2's complement is simply invert the coefficient bits and add 1,
IMHO.

This is the same result
as the definition 2sC(x) = 2^n - x, being x binary rep. for the coefficient
and n the number of bits.

Given your coefficient uses fixed point means you can perform operations
using integer arithmetic, even for 2sC. Only have to take into account
the decimal point position when mixing with non-fixed point numbers
or translating from/to decimal.

Hope this help you Antonio.

Regards
    Francisco
============================================================================
========
Francisco Rodriguez Ballester   e-mail:  prodrig@disca.upv.es
Dept. DISCA,     tlf:  +(34) 96 387 75 77
Univ. Politecnica de Valencia   fax:  +(34) 96 387 75 79
c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN)
============================================================================
========



"Antonio" <dottavio@ised.it> escribió en el mensaje
news:fb35ea96.0106210435.738ae496@posting.google.com...
> I've the coefficient 0.102546681502 that I want to translate in
> 2'complement fixed point binary number having 1 bit for the sign, 1
> bit before the point and 10 bit after, what I have to do ?? Is there
> any software to make this automatically also for the opposite
> conversion ???
> Thanks you a lot
>
> Antonio D'Ottavio
>
> Post a follow-up to this



Article: 32295
Subject: Re: Searching any 144 pin SO-DIMM module
From: Richard Meester <rme@quest-innovations.com>
Date: Fri, 22 Jun 2001 10:37:45 +0200
Links: << >>  << T >>  << A >>
Dear Laurent,

We have an SO-DIMM 144 32-bit Java CPU with on board flash, and SRAM.
Secondly we have a VirtexII SO-DIMM connector in development. look at
www.quest-innovations.com.

Richard

Laurent Gauch wrote:

> Dear all,
>
> I'm searching any board in 144 pin SO-DIMM format:
> --> flash module
> --> ram module
> --> fpga module
> --> dsp module
> --> MCU / MPU module
> --> ethernet module
> --> ...
> --> any module in 144 pin SO-DIMM format.
>
> Thank you for giving me the references of the modules you know.
> (Please send me a email to laurent.gauch@amontec.com)
>
> Reagards
> Laurent
> www.amontec.com

--
Quest Innovations
tel: +31 (0) 227 604046
http://www.quest-innovations.com



Article: 32296
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: koch@ultra4.eis.cs.tu-bs.de (Andreas Koch)
Date: 22 Jun 2001 08:49:37 GMT
Links: << >>  << T >>  << A >>
We have also seen this effect (with regard to carry-chains).  We
simply gave up on optimizing that part of our designs.  Speaking of
Synplify 6.x.x, we consistently get incorrectly synthesized designs
using 6.2.4 when leaving the `Share Ressources' option enabled.  The
errors (e.g., messing up clock enables when mapping RTL to Virtex
technology level) go away when disabling the option.

In article <3B32271D.7B7A6B17@andraka.com>,
Ray Andraka  <ray@andraka.com> wrote:
>Synplicity 6.2 is "optimizing" an instantiated design.  In particular, I
>
>have a design with instantiated Xilinx primitives including a carry
>chain.  The synthesis is apparently flattening the xilinx primitives and
>
>doing its own optimization on them, which results in a multiplexer
>placed between the xorcy and the flip-flop.  When I instantiate
>primitives, I don't expect to see them remapped.  I didn't see this
>happening in 5.3.1.  The instantiated primitives have a syn_black_box
>attribute on them.   This new 'feature' makes Synplicity useless for the
>
>designs I am doing, and actually does damage for the large base I have
>already fielded.
>
>Has anyone else seen this?  Any fixes?
-- 
Andreas Koch                                  Email  : koch@eis.cs.tu-bs.de
Technische Universit"at Braunschweig          Phone  : x49-531-391-2384
Abteilung Entwurf integrierter Schaltungen    Phax   : x49-531-391-5840
Gaussstr. 11, D-38106 Braunschweig, Germany   * PGP key available on request *

Article: 32297
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Tom Dillon <tdillon@dilloneng.com>
Date: Fri, 22 Jun 2001 11:39:45 GMT
Links: << >>  << T >>  << A >>
> We have also seen this effect (with regard to carry-chains).  We
> simply gave up on optimizing that part of our designs.  Speaking of
> Synplify 6.x.x, we consistently get incorrectly synthesized designs
> using 6.2.4 when leaving the `Share Ressources' option enabled.  The
> errors (e.g., messing up clock enables when mapping RTL to Virtex
> technology level) go away when disabling the option.

I saw a very similar problem to this with the reset input to registers i=
n=20
Virtex. It turned out the Xilinx tools were combining registers into the=
=20
same CLB that didn't have common reset inputs.

As far as I know, this is fixed in the most recent Xilinx tools.

Regards,

Tom Dillon
Dillon Engineering, Inc.
http://www.dilloneng.com


Article: 32298
Subject: Xilinx WebPack schematic capture - OBUFE8 fault
From: "Mykola Kyrylenko" <m.kyrylenko@computer.org>
Date: Fri, 22 Jun 2001 12:14:09 GMT
Links: << >>  << T >>  << A >>
Hi,

Has anyone else experienced a fault with OBUFE4 and OBUFE8 (maybe others)
when trying to implement a bi-directional bus?
During the implementation (translation) process, the bi-directional pin says
it is driving multiple inputs.
The individual OBUFE works, but the packaged/macroed versions do not.

If so, is there a way to fix the macros?

regards,
Mykola



Article: 32299
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: hamish@cloud.net.au
Date: Fri, 22 Jun 2001 12:31:12 GMT
Links: << >>  << T >>  << A >>
Andreas Koch <koch@ultra4.eis.cs.tu-bs.de> wrote:
> We have also seen this effect (with regard to carry-chains).  We
> simply gave up on optimizing that part of our designs.  Speaking of
> Synplify 6.x.x, we consistently get incorrectly synthesized designs
> using 6.2.4 when leaving the `Share Ressources' option enabled.  The
> errors (e.g., messing up clock enables when mapping RTL to Virtex
> technology level) go away when disabling the option.

Hmm. I saw faulty output from 6.2.3 too when doing some upgrade work
an older design. 6.1.3 was used originally. I went back and the problem
went away. Scarey.. I've done quite a bit on 6.2.0/3 without issue though.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search