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
2017JanFebMarApr2017

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 36625

Article: 36625
Subject: Re: 'Timing' simulation in ModelSIM
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Tue, 13 Nov 2001 11:43:26 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------BAF896A7A4F3694A75CA2732
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Kris,

   I saw your previous post as well, Xilinx port warnings, and these seemed to
be a related issue.  The problem appears to be that you have defined ports in
your top-level entity declaration that are either not connected, or not fully
defined and are being optimized out by the synthesis tool.  Optimized ports
are not defaultly replaced in back-end siulation so the simulator is not able
to bind the declaration in the testbench to this entity because of the missing
ports.  If you are not aware of any unused ports, follow the logic of these
optimized ports to see if you can find the cause of the warning.  It is
generally best to fix the problem rather than ignore it.  If things truely
"work fine" and you do not wish to modify the code, you have a few options to
make timing simulation work.

Probably the easiest and best way to circumvent this error is to run the
ngd2vhdl netlister using the -a switch.  I am not sure how to enable this in
the ISE GUI but if you see a switch that says something to the degree of
"Generate Architecture Only" that is what you are looking for.  What this does
is tells the Xilinx tools to generate the architecture portion of the
simulation netlist only and to not re-create the entity declaration.  After
doing this, re-run you functional simulation so that the RTL entity
declaration is re-compiled.  Then you can run the timing simulation.  This
should allow the simulator to re-use the entity declaration from your RTL code
and link it to the timing simulation architecture.  If all goes well, you
should be able to get around the binding issues you see and perform your
simulation.

Another option you can try is to enable the "Corelate Simulation Data to
Origional Design" switch.  Again not sure where it is in the ISE GUI but if
you are running from command-line, it means run ngdanno using the ngm file.
In many cases, this will replace the optimized ports in the timing simulation
netlist entity declaration and thus eliminate the binding issues you are
seeing.  Does not work in all cases but I have seen it work for some.

Hope this helps,


--  Brian




Kris Nichols wrote:

> Hey there,
>     It seems I have another challange to overcome in attempting 'timing'
> simulations in ModelSIM.  Please recall that my environment is the
> following:
> ModelSIM SE 5.5c
> Xilinx Foundation ISE 3.3i (ELITE)
> Windows NT (SP6)
>
> I get the following reported errors from ModelSIM when running a testbench
> (i.e. activ_func_sigmoid_tb.vhd) on an entity called 'activ_func_sigmoid':
> --------------------------------------------------
> ###### activ_func_sigmoid_tb.vhd(50): );
> # WARNING[1]: activ_func_sigmoid_tb.vhd(50): No default binding for
> component: "activ_func_sigmoid". (Port "input_value" is not on the entity)
> # -- Compiling configuration activ_func_sigmoid_cfg
> # -- Loading entity testbench
> # -- Loading architecture testbench_arch of testbench
> # vsim -lib work -sdfmax /UUT=activ_func_sigmoid_ppar.sdf testbench
> # //  ModelSim SE 5.5c Jun 22 2001
> # //
> # //  Copyright (c) Mentor Graphics Corporation, 1982-2001, All Rights
> Reserved.
> # //                       UNPUBLISHED, LICENSED SOFTWARE.
> # //            CONFIDENTIAL AND PROPRIETARY INFORMATION WHICH IS THE
> # //          PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS.
> # //
> # //  Copyright (c) Model Technology Incorporated 1990-2001, All Rights
> Reserved.
> # //
> # Loading E:/Modeltech_5.5c/win32/../std.standard
> # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_1164(body)
> # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_arith(body)
> # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_unsigned(body)
> # Loading uog.uog_fp_exp(body)
> # Loading uog.uog_fp_arith(body)
> # Loading E:/Modeltech_5.5c/win32/../std.textio(body)
> # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_textio(body)
> # Loading work.testbench(testbench_arch)
> # ** Warning: Component uut is not bound.
> #    Time: 0 ns  Iteration: 0  Region: /testbench
> # ERROR: activ_func_sigmoid_ppar.sdf: The design does not have an instance
> named '/UUT'.
> # Error loading design
> # Error: Error loading design
> #        Pausing macro execution
> # MACRO ./activ_func_sigmoid_tb.tdo PAUSED at line 8
> --------------------------------------------------
>
> It seems that ModelSIM doesn't believe that a input port called
> 'input_value' doesn't exist in the entity, when in fact this port does
> exist.  Do you have any suggestions on how I can overcome this problem??
> I just wanted to point out that a 'functional' simulation works
> successfully with the same 'activ_func_sigmoid' VHDL source file and its
> respective testbench.  Perhaps there's problems with the SDF (Standard
> Delay Format) file that's produced by the Xilinx environment, which the
> 'timing' simulation depends on.  I did notice that Xilinx produced some
> warnings during implementation that were as follows:
>
> ---------------------------------------------------
> Synthesizing Unit <activ_func_sigmoid>.
>     WARNING : (ADVISOR__0001). Extracting 32-bit latch for signal
> <output>.
> WARNING : (HDL__0005). Signal <intermediate_mult2<31>> is assigned but
> never used.
> WARNING : (HDL__0005). Signal <intermediate_mult2<30>> is assigned but
> never used.
> :
> etc.
> ----------------------------------------------------
>
> I'll be checking with the fellas at Xilinx to see if these warnings lead
> to the incorrect implementation of ports.  However, any input you have on
> this problem would be much appreciated.  Thanks for your time.
>
> Kris Nichols

--------------BAF896A7A4F3694A75CA2732
Content-Type: text/x-vcard; charset=us-ascii;
 name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brian.philofsky.vcf"

begin:vcard 
n:Philofsky;Brian
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
fn:Brian Philofsky
end:vcard

--------------BAF896A7A4F3694A75CA2732--


Article: 36626
Subject: Re: Reassemble a BGA560 device
From: arast@inficom.com (Alex Rast)
Date: Tue, 13 Nov 2001 19:03:01 GMT
Links: << >>  << T >>  << A >>
In article <3BC8037B.1A8840F6@algor.co.uk>, Rick Filipkiewicz <rick@algor.co.uk> wrote:
>
>
>Mike Treseler wrote:
>
>> Juergen Otterbach wrote:
..
>> > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
>> > (means to take of the 1000E and resolder the 2000E).
>>
>> Removing and replacing a BGA device is not
>> a problem for any manufacturing facility
>> with a BGA rework station.
>>
..
>
>We had a case some years ago where our assemblers...had a re-work station and did
>manage to get the parts off *but* they lost some of the pads doing it. 
>
>The real issue is that a BGA re-work station uses a metal box which is placed
>over the BGA to form a mini-oven but, unlike the main re-flow oven, the whole
>board doesn't go through the preheat, temperature profiling process.
>
>Things may have got better since then ...
>
We've got a rework station (from PACE) that will do full BGA rework including 
top and bottom-side preheat. Indeed, for our boards the preheat is mandatory, 
what with up to 4 plane layers and 8 routing layers. These stations make 
removal a snap, without lifting any pads, provided you've done some profiling 
in advance. We had some test boards and dummy components we played around with 
to get the profiles right.

In theory, the station can do install as well, and it's actually quite easy, 
but I still wouldn't trust the results without X-ray inspection. All it takes 
is one bridge between a VCC and GND to smoke your expensive chip. So 
notwithstanding the ability to install, it's probably just as well to ship out 
the board for installation because you're going to have to take it down to 
your local C/M's for inspection anyway, and if they actually do the 
installation they'll do the inspection automatically.

Alex Rast
arast@inficom.com
arast@qwest.net 

Article: 36627
Subject: Re: Hex numbers in VHDL
From: David Rogoff <drogoff@broadcom.com>
Date: 13 Nov 2001 11:04:23 -0800
Links: << >>  << T >>  << A >>
Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de> writes:

> How about using integers:
> 
> 
>     case to_integer(unsigned(addr)) is
>    	when 16#3ac# => ...;
>    	when others => null;
>     end case;
> 

What about if it's more than 32 bits???
 
    David

Article: 36628
Subject: Re: Interleaver and Reed Solomon Encoder example
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Tue, 13 Nov 2001 19:11:51 GMT
Links: << >>  << T >>  << A >>
Or you can get the whole DVB core with randomizer, interleaver, (208,188) RS
coder, trellis coder, puncturer, mapper, and interpolating FIR, at <plug>
Insight Design Services.

"FredInAShed" <FredInAShed@blueyonder.co.uk> wrote in message
news:3BF04D56.C857BBF3@blueyonder.co.uk...
> You could just get them off the shelf at
> http://www.xilinx.com/ipcenter/fec_index.htm
>
>
>
> srinas wrote:
>
> > Dear All,
> >  I have to implement a Reed Solomon Encoder and a convolutional
> > Interleaver.
> > Could anybody send me some examples for a (208,188)or DVB standard RS
> > coder (only the encoder) and the Interleaver.
> >
> > Note:
> > The link
> > http://www.fokus.gmd.de/research/cc/mobra/products/fec/content.html
> >
> > is unavailable now.
> > Does anybody know where it is know?
> >
> > Thanks
>
>



Article: 36629
Subject: Re: Hex numbers in VHDL
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 13 Nov 2001 11:53:57 -0800
Links: << >>  << T >>  << A >>
David Rogoff wrote:
> 
> Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de> writes:
> 
> > How about using integers:
> >
> >
> >     case to_integer(unsigned(addr)) is
> >       when 16#3ac# => ...;
> >       when others => null;
> >     end case;
> >
> 
> What about if it's more than 32 bits???
> 

Then back to vectors, or segment the address.

 --Mike Treseler

Article: 36630
Subject: Re: searchin for High density non bga packages something like PGA.
From: arast@inficom.com (Alex Rast)
Date: Tue, 13 Nov 2001 19:54:01 GMT
Links: << >>  << T >>  << A >>
In article <3BDFC791.CA95D40D@quest-innovations.com>, Richard Meester <rme@quest-innovations.com> wrote:
>Hello all,
>
>I am searching for a high density non bga package FPGA. I don't want to
>use BGA since the high prototyping costs involved. My estimation is that
>PGA packages are cheaper to produce. Are there any SPartanII Virtex/II/E
>devices in this package?
>
PGA's are likely to be *more* expensive, not less, than BGA's for similar 
density, partly because of the low demand, partly because the manufacturing 
process for BGA's is more efficient. OTOH, PGA's are easier to proto since you 
can easily socket them (note: for BGA socketing look to 
http://www.wellscti.com) and it's far easier to probe the device pins. 

In any case, if you're still interested in PGA parts, looks like the densest 
is Altera's EP20K400 (1 M system gates, 1664 macrocells) which is available in 
a 655-pin PGA.

However, it's probably best to stay with BGA unless you have *specific* 
reasons for using a PGA (e.g all through-hole parts in the production board, 
so you want to have it go through wave solder for the whole process)

Alex Rast
arast@inficom.com
arast@qwest.net

Article: 36631
Subject: Re: 'Timing' simulation in ModelSIM
From: "Kris Nichols" <kris@nichols.com>
Date: Tue, 13 Nov 2001 16:00:17 -0500
Links: << >>  << T >>  << A >>
Brian,

It turns out that when implementing my design in Xilinx environment, the XST
synthesizer would attempt to reduce logic for optimization purposes.  The
synthesizer thought that some of my pins were never used, and indirectly
removed all logic related to my 'input_value' port (without explicitly
stating it had done this).  The SDF file produced by Xilinx wouldn't have
any reference to the 'input_value' port pins, so a 'timing' simulation in
ModelSIM would think that this port doesn't exist.  So is it safe to say
that the following messages indicate which pins are not implemented:
WARNING : (HDL__0002). Input <name_of_pin> is never used.
WARNING : (HDL__0005). Signal <name_of_pin> is assigned but never used.
Is there any way (workarounds, etc.) I can use prevent the XST synthesizer
from doing this?  Thanks.

Kris Nichols

"Brian Philofsky" <brian.philofsky@xilinx.com> wrote in message
news:3BF169CE.BA778033@xilinx.com...
>
> Kris,
>
>    I saw your previous post as well, Xilinx port warnings, and these
seemed to
> be a related issue.  The problem appears to be that you have defined ports
in
> your top-level entity declaration that are either not connected, or not
fully
> defined and are being optimized out by the synthesis tool.  Optimized
ports
> are not defaultly replaced in back-end siulation so the simulator is not
able
> to bind the declaration in the testbench to this entity because of the
missing
> ports.  If you are not aware of any unused ports, follow the logic of
these
> optimized ports to see if you can find the cause of the warning.  It is
> generally best to fix the problem rather than ignore it.  If things truely
> "work fine" and you do not wish to modify the code, you have a few options
to
> make timing simulation work.
>
> Probably the easiest and best way to circumvent this error is to run the
> ngd2vhdl netlister using the -a switch.  I am not sure how to enable this
in
> the ISE GUI but if you see a switch that says something to the degree of
> "Generate Architecture Only" that is what you are looking for.  What this
does
> is tells the Xilinx tools to generate the architecture portion of the
> simulation netlist only and to not re-create the entity declaration.
After
> doing this, re-run you functional simulation so that the RTL entity
> declaration is re-compiled.  Then you can run the timing simulation.  This
> should allow the simulator to re-use the entity declaration from your RTL
code
> and link it to the timing simulation architecture.  If all goes well, you
> should be able to get around the binding issues you see and perform your
> simulation.
>
> Another option you can try is to enable the "Corelate Simulation Data to
> Origional Design" switch.  Again not sure where it is in the ISE GUI but
if
> you are running from command-line, it means run ngdanno using the ngm
file.
> In many cases, this will replace the optimized ports in the timing
simulation
> netlist entity declaration and thus eliminate the binding issues you are
> seeing.  Does not work in all cases but I have seen it work for some.
>
> Hope this helps,
>
>
> --  Brian
>
>
>
>
> Kris Nichols wrote:
>
> > Hey there,
> >     It seems I have another challange to overcome in attempting 'timing'
> > simulations in ModelSIM.  Please recall that my environment is the
> > following:
> > ModelSIM SE 5.5c
> > Xilinx Foundation ISE 3.3i (ELITE)
> > Windows NT (SP6)
> >
> > I get the following reported errors from ModelSIM when running a
testbench
> > (i.e. activ_func_sigmoid_tb.vhd) on an entity called
'activ_func_sigmoid':
> > --------------------------------------------------
> > ###### activ_func_sigmoid_tb.vhd(50): );
> > # WARNING[1]: activ_func_sigmoid_tb.vhd(50): No default binding for
> > component: "activ_func_sigmoid". (Port "input_value" is not on the
entity)
> > # -- Compiling configuration activ_func_sigmoid_cfg
> > # -- Loading entity testbench
> > # -- Loading architecture testbench_arch of testbench
> > # vsim -lib work -sdfmax /UUT=activ_func_sigmoid_ppar.sdf testbench
> > # //  ModelSim SE 5.5c Jun 22 2001
> > # //
> > # //  Copyright (c) Mentor Graphics Corporation, 1982-2001, All Rights
> > Reserved.
> > # //                       UNPUBLISHED, LICENSED SOFTWARE.
> > # //            CONFIDENTIAL AND PROPRIETARY INFORMATION WHICH IS THE
> > # //          PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS.
> > # //
> > # //  Copyright (c) Model Technology Incorporated 1990-2001, All Rights
> > Reserved.
> > # //
> > # Loading E:/Modeltech_5.5c/win32/../std.standard
> > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_1164(body)
> > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_arith(body)
> > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_unsigned(body)
> > # Loading uog.uog_fp_exp(body)
> > # Loading uog.uog_fp_arith(body)
> > # Loading E:/Modeltech_5.5c/win32/../std.textio(body)
> > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_textio(body)
> > # Loading work.testbench(testbench_arch)
> > # ** Warning: Component uut is not bound.
> > #    Time: 0 ns  Iteration: 0  Region: /testbench
> > # ERROR: activ_func_sigmoid_ppar.sdf: The design does not have an
instance
> > named '/UUT'.
> > # Error loading design
> > # Error: Error loading design
> > #        Pausing macro execution
> > # MACRO ./activ_func_sigmoid_tb.tdo PAUSED at line 8
> > --------------------------------------------------
> >
> > It seems that ModelSIM doesn't believe that a input port called
> > 'input_value' doesn't exist in the entity, when in fact this port does
> > exist.  Do you have any suggestions on how I can overcome this problem??
> > I just wanted to point out that a 'functional' simulation works
> > successfully with the same 'activ_func_sigmoid' VHDL source file and its
> > respective testbench.  Perhaps there's problems with the SDF (Standard
> > Delay Format) file that's produced by the Xilinx environment, which the
> > 'timing' simulation depends on.  I did notice that Xilinx produced some
> > warnings during implementation that were as follows:
> >
> > ---------------------------------------------------
> > Synthesizing Unit <activ_func_sigmoid>.
> >     WARNING : (ADVISOR__0001). Extracting 32-bit latch for signal
> > <output>.
> > WARNING : (HDL__0005). Signal <intermediate_mult2<31>> is assigned but
> > never used.
> > WARNING : (HDL__0005). Signal <intermediate_mult2<30>> is assigned but
> > never used.
> > :
> > etc.
> > ----------------------------------------------------
> >
> > I'll be checking with the fellas at Xilinx to see if these warnings lead
> > to the incorrect implementation of ports.  However, any input you have
on
> > this problem would be much appreciated.  Thanks for your time.
> >
> > Kris Nichols
>



Article: 36632
Subject: Re: Reassemble a BGA560 device
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 13 Nov 2001 13:32:38 -0800
Links: << >>  << T >>  << A >>
arast@inficom.com (Alex Rast) writes:
> All it takes is one bridge between a VCC and GND to smoke your expensive
> chip.

A bridge shorting an output pad to VCC or GND is much more likely to
damage the chip.  In my experience a short between VCC and GND is more
likely to damage traces on the board, since that's where the high current
flow will be.

Article: 36633
Subject: Re: Clock Skew
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 13 Nov 2001 22:48:13 +0100
Links: << >>  << T >>  << A >>


"#BASUKI ENDAH PRIYANTO#" <PH892987@ntu.edu.sg> schrieb im Newsbeitrag
news:8D5C8824989A21458FFF1C3CE9902036058AF146@mail12.main.ntu.edu.sg...
>
> When I synthesize my VHDL code, I have warning message that clock skew
> may be happened in my design.
> How to prevent clock skew ?

This warning usually occurs when using non-clock nets for clock
distribution, e.g. when you have more than 4 clock in a Spartan-II. Since
the non-clock nets are not that strong, fast and well balanced, they are no
good for distributing such a high-fan-out signal like a clock with low skew.

> Do I need additional circuit / block diagram ?

Hmm, first, try to use the global clock nets (Spartan(XL) has 8,
Spartan-II/Virtex(E) has 4, Virtex-II has 16). If you are still out of clock
nets, you have to use other routing ressources. Uses the following statement
in your ucf file (ucf file is a little bit stupid, because ucf already means
User Constraints File ;-)

NET myclocknet uselowskewlines;

This will tell the software to take care of your clock signal on non-clock
routing ressources. Try to use these secondary clock nets only for small
parts of the design (lets say a maximum fanout of 50..100 ??).

--
MfG
Falk





Article: 36634
Subject: Xilinx problems using constants in the input ports of entities
From: "Kris Nichols" <knichols@uoguelph.ca>
Date: Tue, 13 Nov 2001 16:53:12 -0500
Links: << >>  << T >>  << A >>
Hey Everyone,
                     It turns out that I get the following warning whenever
I try to (XST) synthesize entities with ports port-mapped to constants!!!
As a result the input port itself is not implemented during synthesis, and
XST produces the following warning:
WARNING:(HDL__0002). Signal <port_pin_name> is not used.

Has anyone else come across this problem before?  Any suggestions on how I
can rectify this problem (i.e. workarounds, etc.)?  Thanks :)

Kris Nichols



Article: 36635
Subject: Re: Xilinx s/w upgrade 4.1 problems
From: Jim Bittman <jmbj@bittware.com>
Date: Tue, 13 Nov 2001 16:54:41 -0500
Links: << >>  << T >>  << A >>
Indeed, the decision to upgrade was not taken lightly, but we had to choose
being able to run the CoreGen (because of the Pentium-4 bug), switching
machines and dealing with the associated licensing headaches, or upgrading.
Since we had just a single design in 3.1 and new designs in the queue, we
chose to upgrade.

Xilinx support has confirmed that there are numerous [unnecessary]
incompatibilities, and that there is not [yet] a summary.

Jim.

Falk Brunner wrote:

> "Jim Bittman" <jmbj@bittware.com> schrieb im Newsbeitrag
> news:3BF01451.5DD62639@bittware.com...
>
> [ Complaints about Xilinx Sotware update ]
>
> > I could go on, but here we have a seriously under-utilized device and a
> > LOT of work
> > to upgrade the software.  What gives - are we unique or is everyone just
> > accepting
>
> Hmmm, we did the upgrade too and had a LOT of trouble. Even with pure VHDL
> designs. The Xilinx Software guys will have a LOT of bugs to fix :-(
>
> > this as the necessary pain to upgrade???
>
> As always, never change a running system. If your old Software runs O.K.
> leave it this way, at least to the end of your current projects.
>
> --
> MfG
> Falk

--
 ********************************************************************
 * Jim Bittman                      * Tel: 603-226-0404             *
 * BittWare, Inc.                   * Fax: 603-226-6667             *
 * 33 North Main Street             * E-Mail: jmbj@bittware.com     *
 * Concord, NH 03301                * WWW: http://www.bittware.com  *
 ********************************************************************



Article: 36636
Subject: Re: Place your orders....
From: Tim Hubberstey <sendme@no.spam>
Date: Tue, 13 Nov 2001 22:56:16 GMT
Links: << >>  << T >>  << A >>
Petter Gustad wrote:
> 
> Austin Lesea <austin.lesea@xilinx.com> writes:
> 
> > Lies, lies, and damned lies,
> >
> > 2V6000's are yielding just fine.
> 
> I'm glad to hear that. My comment was not a confirmation on the rumor,
> just a technical question. Would it be possible to by cheap partially
> defective parts like I described, or would the logistics and support
> be way to expensive to make it worth it?

This was certainly done in the past. Way back in the dark ages (late
70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s)
with one address line tied off to exclude the non-working portion of the
die. Because they were windowed parts it was easy to visually confirm
that the 2758s were the same die as the 2716s. At the time 2716s were
selling for around $30 apiece, IIRC. 
-- 
Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot Engineering
Vancouver, BC, Canada  . . . . . Hardware/Software Consulting Engineer

Article: 36637
Subject: Re: Xilinx problems using constants in the input ports of entities
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Tue, 13 Nov 2001 16:12:15 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------46894D576FF6AC191D243FE0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit




How do you map an input port to a constant?  I can understand defining an
output port to be a constant but not exactly following what your problem is
with the input ports.  Can you include a small snip-it of code to better
explain what you are doing and what you are trying to accomplish?  Perhaps with
that, I can better help you.

--  Brian


Kris Nichols wrote:

> Hey Everyone,
>                      It turns out that I get the following warning whenever
> I try to (XST) synthesize entities with ports port-mapped to constants!!!
> As a result the input port itself is not implemented during synthesis, and
> XST produces the following warning:
> WARNING:(HDL__0002). Signal <port_pin_name> is not used.
>
> Has anyone else come across this problem before?  Any suggestions on how I
> can rectify this problem (i.e. workarounds, etc.)?  Thanks :)
>
> Kris Nichols

--------------46894D576FF6AC191D243FE0
Content-Type: text/x-vcard; charset=us-ascii;
 name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brian.philofsky.vcf"

begin:vcard 
n:Philofsky;Brian
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
fn:Brian Philofsky
end:vcard

--------------46894D576FF6AC191D243FE0--


Article: 36638
Subject: Re: Xilinx problems using constants in the input ports of entities
From: "Kris Nichols" <knichols@uoguelph.ca>
Date: Tue, 13 Nov 2001 18:32:27 -0500
Links: << >>  << T >>  << A >>
No problem.  Here's a simple example for you:

-------------------------------------------------------------------------
--COMPONENT uog_fp_div IS
-- PORT( reset,clock,start: IN std_logic;
-- mode : IN  std_logic_vector(1  DOWNTO 0);
-- x    : IN  std_logic_vector(31 DOWNTO 0);
-- y    : IN  std_logic_vector(31 DOWNTO 0);
-- z    : OUT std_logic_vector(31 DOWNTO 0);
-- busy : OUT std_logic);
-- END COMPONENT;


-- one example where I use a constant of X"3F800000" as one of the inputs
divider_1: uog_fp_div PORT MAP(reset, system_clock, chip_enable,
truncate_mode, incoming, X"3F800000", div_output1, busy_flag1);

-- another example where I indirectly use a constant of X"3F800000"
-- as one of the inputs
positive_one <= X"3F800000";

divider_2 : uog_fp_div PORT MAP(reset, system_clock, chip_enable,
truncate_mode, incoming, postive_one, div_output2, busy_flag2);
-------------------------------------------------------------------------

In both cases, the XST synthesizer would give me the following:

WARNING:(HDL__0002). Signal y<31> is not used.
WARNING:(HDL__0002). Signal y<30> is not used.
:
WARNING:(HDL__0002). Signal y<0> is not used.

When I don't use constants these warnings go away, and everything gets
implemented properly.  Let me know if you need any more clarification.
Much appreciated.

Kris N.

"Brian Philofsky" <brian.philofsky@xilinx.com> wrote in message
news:3BF1A8CF.96163E5@xilinx.com...
>
>
>
> How do you map an input port to a constant?  I can understand defining an
> output port to be a constant but not exactly following what your problem
is
> with the input ports.  Can you include a small snip-it of code to better
> explain what you are doing and what you are trying to accomplish?  Perhaps
with
> that, I can better help you.
>
> --  Brian
>
>
> Kris Nichols wrote:
>
> > Hey Everyone,
> >                      It turns out that I get the following warning
whenever
> > I try to (XST) synthesize entities with ports port-mapped to
constants!!!
> > As a result the input port itself is not implemented during synthesis,
and
> > XST produces the following warning:
> > WARNING:(HDL__0002). Signal <port_pin_name> is not used.
> >
> > Has anyone else come across this problem before?  Any suggestions on how
I
> > can rectify this problem (i.e. workarounds, etc.)?  Thanks :)
> >
> > Kris Nichols
>



Article: 36639
Subject: Re: Place your orders....
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 13 Nov 2001 16:10:52 -0800
Links: << >>  << T >>  << A >>

--------------7959175E83AE16AE4FEFF0A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

Selling partial functionality parts is definitely a way to stay in business
if there is no yield, or yields are poor.

We do not have that problem, as we have plenty of 100% working parts.

If you then offer reduced functionality parts at the same time you have full
functionality parts, you create a support nightmare.

I was so upset to see the lie in print, I missed the question, I apologize.

Austin

Tim Hubberstey wrote:

> Petter Gustad wrote:
> >
> > Austin Lesea <austin.lesea@xilinx.com> writes:
> >
> > > Lies, lies, and damned lies,
> > >
> > > 2V6000's are yielding just fine.
> >
> > I'm glad to hear that. My comment was not a confirmation on the rumor,
> > just a technical question. Would it be possible to by cheap partially
> > defective parts like I described, or would the logistics and support
> > be way to expensive to make it worth it?
>
> This was certainly done in the past. Way back in the dark ages (late
> 70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s)
> with one address line tied off to exclude the non-working portion of the
> die. Because they were windowed parts it was easy to visually confirm
> that the 2758s were the same die as the 2716s. At the time 2716s were
> selling for around $30 apiece, IIRC.
> --
> Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot Engineering
> Vancouver, BC, Canada  . . . . . Hardware/Software Consulting Engineer

--------------7959175E83AE16AE4FEFF0A3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tim,
<p>Selling partial functionality parts is definitely a way to stay in business
<b>if </b>there is no yield, or yields are poor.
<p>We do not have that problem, as we have plenty of 100% working parts.
<p>If you then offer reduced functionality parts at the same time you have
full functionality parts, you create a support nightmare.
<p>I was so upset to see the lie in print, I missed the question, I apologize.
<p>Austin
<p>Tim Hubberstey wrote:
<blockquote TYPE=CITE>Petter Gustad wrote:
<br>>
<br>> Austin Lesea &lt;austin.lesea@xilinx.com> writes:
<br>>
<br>> > Lies, lies, and damned lies,
<br>> >
<br>> > 2V6000's are yielding just fine.
<br>>
<br>> I'm glad to hear that. My comment was not a confirmation on the rumor,
<br>> just a technical question. Would it be possible to by cheap partially
<br>> defective parts like I described, or would the logistics and support
<br>> be way to expensive to make it worth it?
<p>This was certainly done in the past. Way back in the dark ages (late
<br>70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s)
<br>with one address line tied off to exclude the non-working portion of
the
<br>die. Because they were windowed parts it was easy to visually confirm
<br>that the 2758s were the same die as the 2716s. At the time 2716s were
<br>selling for around $30 apiece, IIRC.
<br>--
<br>Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .&nbsp; Marmot Engineering
<br>Vancouver, BC, Canada&nbsp; . . . . . Hardware/Software Consulting
Engineer</blockquote>
</html>

--------------7959175E83AE16AE4FEFF0A3--


Article: 36640
Subject: Displaying Verilog variables when simulating in Max+Plus II
From: mkoepnick@anritsu.com (Matt Koepnick)
Date: 13 Nov 2001 16:47:15 -0800
Links: << >>  << T >>  << A >>
Hello all, 

I have a Verilog design and would like to simulate it in Altera's
Max+Plus II. When I insert nodes into the simulator channel file,
(SCF) from my compiled netlist, I do not see all of my variables
available.  (I see all input and output ports, but only one of my five
registers).

I know that with an Altera graphic design file, one can specify the
parameter "LCELL" on a node, which will keep it visible.  However, as
this is a Verilog file, I do not know how to keep the variables
around.

If you have an idea, please respond by email.  If there seems to be
any significant interest in this topic, I will compile a summary of
responses and post it to this group.

Thank you and regards,
Matt
mkoepnick@anritsu.com

Article: 36641
Subject: Re: ZX81 production run, is there any interest?
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Wed, 14 Nov 2001 02:12:12 -0000
Links: << >>  << T >>  << A >>
The '3042 is getting on a bit as Xilinx have advanced several generations.
I'm looking at porting the design to this board:

http://www.howell1964.freeserve.co.uk/logic/burched/fpga_devkit_b5.htm

There is a lot more logic and I/O available in the chip,
so room to use this board for future projects.

I should point out that these chips involve a lot of very sensitive gates
toggling like crazy, so they do need a good quality PCB design with decent
power decoupling and dedicated power and ground planes. Four-layer boards
are significantly dearer to produce than two layer boards of course. It's
not really economically feasible to make a small production run for a
low-value product.

What might be worth doing is making a 2-layer board to mate with the B5
board.
That would have the relatively simple application specific circuitry.
A Z80, a 32K RAM and a ROM (5V flash?).








Article: 36642
Subject: SDRAM Module vs. SDRAM
From: s9323090@cc.ncu.edu.tw (Arguo)
Date: 13 Nov 2001 18:27:44 -0800
Links: << >>  << T >>  << A >>
Hi,
  I am try to design sdram controller. I think the sdram module interface is
  similar sdram. Can I treat the sdram module as a larger sdram?

Best Regards,
Arguo

Article: 36643
Subject: Re: Place your orders....
From: Ray Andraka <ray@andraka.com>
Date: Wed, 14 Nov 2001 02:54:09 GMT
Links: << >>  << T >>  << A >>
I'm glad Xilinx doesn't sell partially functional units.  It would wreak
havoc on floorplanned designs.  It may be invisible in the Altera
architecture, but that is because the routing architecture permits
hanging extra units on with no noticible effect for extra units added to
improve yield.  In the Xilinx routing architecture, this would be a
disaster.  That said, I do not mean to imply that the Altera routing is
superior, it is not for data flow designs.

Austin Lesea wrote:

> Tim,
>
> Selling partial functionality parts is definitely a way to stay in
> business if there is no yield, or yields are poor.
>
> We do not have that problem, as we have plenty of 100% working parts.
>
> If you then offer reduced functionality parts at the same time you
> have full functionality parts, you create a support nightmare.
>
> I was so upset to see the lie in print, I missed the question, I
> apologize.
>
> Austin
>
> Tim Hubberstey wrote:
>
>> Petter Gustad wrote:
>> >
>> > Austin Lesea <austin.lesea@xilinx.com> writes:
>> >
>> > > Lies, lies, and damned lies,
>> > >
>> > > 2V6000's are yielding just fine.
>> >
>> > I'm glad to hear that. My comment was not a confirmation on the
>> rumor,
>> > just a technical question. Would it be possible to by cheap
>> partially
>> > defective parts like I described, or would the logistics and
>> support
>> > be way to expensive to make it worth it?
>>
>> This was certainly done in the past. Way back in the dark ages (late
>>
>> 70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts
>> (2716s)
>> with one address line tied off to exclude the non-working portion of
>> the
>> die. Because they were windowed parts it was easy to visually
>> confirm
>> that the 2758s were the same die as the 2716s. At the time 2716s
>> were
>> selling for around $30 apiece, IIRC.
>> --
>> Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot
>> Engineering
>> Vancouver, BC, Canada  . . . . . Hardware/Software Consulting
>> Engineer
>
--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 36644
Subject: Re: SDRAM Module vs. SDRAM
From: Keith R. Williams <krw@attglobal.net>
Date: Tue, 13 Nov 2001 22:07:43 -0500
Links: << >>  << T >>  << A >>
In article <52758910.0111131827.4f26d43f@posting.google.com>, 
s9323090@cc.ncu.edu.tw says...
> Hi,
>   I am try to design sdram controller. I think the sdram module interface is
>   similar sdram. Can I treat the sdram module as a larger sdram?

Depending on the SDRAM, perhaps.  You might want to look at the 
timings for the DIMMs and the system-level stuff.  Note that 
registered DIMMs will have to have the registration accounted for 
in the state machine and modern DIMMs will have information in 
the serial EEPROM that you may care to support. 

----
  Keith 


Article: 36645
Subject: Re: Incrementing counter from state-machine
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Wed, 14 Nov 2001 18:58:11 +1100
Links: << >>  << T >>  << A >>


Jerry wrote:
> 
> Russell Shaw <rjshaw@iprimus.com.au> wrote in message news:<3BF064BA.D3841344@iprimus.com.au>...
> > > the process. Mixing both styles like your process creates latches.
> >
> > But with synthesis, i think *everything* that gets assigned a value
> > within a process, has to be in the sensitivity list or leonardo gives
> > warnings. Only with a "wait until" line, does the process not have a
> > sensitivity list.
> >
> 
> Russell,
> 
> Please note that VHDL synthesizers generate stupid warnings about signals
> missing from the sensitivity list during initial syntax check of the code.
> Those warnings are justified only for processes describing COMBINATORIAL
> logic. In that case all signals _used_on_the_right-hand_side_ of assignments
> should be in the sensitivity list. For clocked processes, such requirements
> are clear violation of common sense and basic VHDL rules.

I can't remember, but leonardo might only emit a warning for
variables/signals being read in the *asynchronous* part of
a flip-flop process.

> Issuing those
> warnings is even more ridiculous if you consider that VHDL synthesizers
> usually do not check sensitivity list while infering logic...
> I do hope that somebody will kick synthesis tool vendors in the ass to remove
> those stupid warnings - it worked (with loooong waiting time) to force
> FPGA Express to support rising_edge/falling_edge functions...

Article: 36646
Subject: Re: Incrementing counter from state-machine
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Wed, 14 Nov 2001 19:11:21 +1100
Links: << >>  << T >>  << A >>


Nial Stewart wrote:
> 
> Jim wrote:
> >
> >  If for any reason, the synthesis tool doesn't
> > pick the global clock buffer for your clock, you can always add a global
> > buffer marco in your code to force the tool to use one. Or try to use a
> > better synthesis tool.
> 
> Jim,
> 
> With Altera's Acex devices (and all others I'm aware of) you're tied to
> using dedicated GClk pins. If you don't use them for your clocks you're
> stuffed.

I fixed all my problems. I think it was caused by clock-skew/alignment
problems between the state-machine and counter.

I figured out how to trace signal paths using the maxplus2
floor-planner.
I traced from the clock input pin to the clock divider, and looked at
the fanout from the last flip-flop. I found there were a few counters
implemented as scattered logic, not being recognized as counter
templates. I found just one or two extra lines in a process can prevent
recognition by the compiler as a counter. With a slight modification to
match standard leonardo templates, they get recognized and implemented
as LPM library functions, showing compact grouping in LABs. The next
thing was to get that buried node from the clock-divider output onto
a global clock track. A simple resource assignment in the floor-planner
did that. The externally supplied clock just goes to an 'ordinary'
io pin.

Article: 36647
Subject: interleaver delay question
From: mehmetozcelebi@turk.net (mehmeto)
Date: 14 Nov 2001 00:35:26 -0800
Links: << >>  << T >>  << A >>
Hi,
 I have a similar problem like srinas has. 
The convolutional interleaver for ATSC has 52 lines and needs
(51x52)/2=1326 delay elements. If the input is 8 bit then 1326x8=10608
delay elements are required. The required number of Flip flops for a 4
symbol delay is 10608x4 = 42432. This is quite large.
The same complexity is also valid for DVB interleavers.
Is there any way to reduce the Flip Flop count? I know there are
megafunctions for altera and xilinx devices, but they are commercial.

Thanks

Article: 36648
Subject: ASRC (asynchronus sample rate conversion)
From: "Damir Danijel Zagar" <dzagar@srce.hr>
Date: Wed, 14 Nov 2001 10:12:56 +0100
Links: << >>  << T >>  << A >>
I'm in need of a pointer for a ASRC implementation
using DSP or FPGA. Any source (C-code or VHDL)
will be more than welcome. Regards,

Damir




Article: 36649
Subject: Re: interleaver delay question
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 14 Nov 2001 12:14:40 GMT
Links: << >>  << T >>  << A >>
On 14 Nov 2001 00:35:26 -0800, mehmetozcelebi@turk.net (mehmeto)
wrote:

>Hi,
> I have a similar problem like srinas has. 
>The convolutional interleaver for ATSC has 52 lines and needs
>(51x52)/2=1326 delay elements. If the input is 8 bit then 1326x8=10608
>delay elements are required. The required number of Flip flops for a 4
>symbol delay is 10608x4 = 42432. This is quite large.
>The same complexity is also valid for DVB interleavers.
>Is there any way to reduce the Flip Flop count? I know there are
>megafunctions for altera and xilinx devices, but they are commercial.

Yes, that's a lot of flip flops.  But I've never seen a large
interleaver use flip flops for storage.

Try RAM.  It's much cheaper per bit.  You could use an external ram,
or you could use ram inside an FPGA.
Your application would use less than 10% of the ram on one of the
larger FPGA devices.

Allan.



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
2017JanFebMarApr2017

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