Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.comArticle: 32276
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.comArticle: 32277
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
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
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
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
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, AndrewArticle: 32282
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 VermontArticle: 32283
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 VermontArticle: 32284
"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, > AndrewArticle: 32285
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.comArticle: 32286
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.comArticle: 32287
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
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
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: 32290Allan 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
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, ArizonaArticle: 32292
"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
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: 32295Dear 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.comArticle: 32296
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
> 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.comArticle: 32298
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, MykolaArticle: 32299
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:
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