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 35275

Article: 35275
Subject: Re: Xilinx implementation problem
From: "santosh shreinivasan" <sshreiniv@hotmail.com>
Date: Thu, 27 Sep 2001 09:50:59 -0700
Links: << >>  << T >>  << A >>
hi,
    I am trying to implement a 16 bit RISc processor in XC4005xl FPGA.i have written a structural code for the RISC processor. but when i try to synthesize, it gives me an error where a window pops up saying "synopsys internal error".this error occurs when the software tries to "map combinational logic".i am not sure if it is an error in the software or if i have done some mistake.please reply asap.

santosh

Article: 35276
Subject: Re: Logical constraints of LUT
From: Ray Andraka <ray@andraka.com>
Date: Thu, 27 Sep 2001 17:15:50 GMT
Links: << >>  << T >>  << A >>
I'm with Noddy on this one.  The Block Rams are, in most cases anyway, remotely
located with respect to the logic you want to use them with.  In order to get any
respectable performance out of them, the signals to and from them have to be
pipelined too.  Additionally, the Block RAMs are pretty much the slowest thing in
the FPGA...at least I find that in 90% of the designs I do that use Block RAM, the
block RAM is by far the limiting factor on clock rate.  If you count up the CLBs
needed for pipelining the signals to/from the block RAM, then many times using just
CLBs doesn't look so expensive, especially if you start having to clock the BRAM at
1/2 the clock and accessing 2 words at a time.  Sounds like what he has is a limited
set multiplier (see my web page) with the encoded phase angle as one input, and the
input signal as the other.  In practice this isn't much different than the partial
products multiplier except it uses less luts and less adders than a full parallel
multiplier.  BRAMs are not the way to do that in most cases.

Peter Alfke wrote:

> There is one think I forgot to tell you:
> The CLB-LUT is a combinatorial device: You give it a new address input, and you
> get the new output "immediately", i.e. within a nanosecond or two.
> The BlockRAM ( or BlockROM) is a clocked device, even in its read operation. You
> get the new output after applying the next clock edge (You decide on rising or
> falling). This sequential behavior has its advantages and disadvantages, but in
> any case, you must be aware of it.
> Sorry for not telling you before.
> "Better placement" is puzzling. If you have an unused BlockRAM, it takes no
> extra space at all, while your CLB implementation takes a fair number of CLBs
> and routing resources.
>
> Peter Alfke, Xilinx Applications.
> ========================
> Noddy wrote:
>
> > Thanks for the suggestion... did it, but it appears I get better placer
> > scores using the distrbted arithmetic instead. Also, (I'm using the LUT's in
> > a digital mixer), I get timing problems using the Block RAM, but not using
> > the DA.
> >
> > adrian
> >
> > > I would suggest putting this big LUT in one of the available BlockRAMs,
> > each of
> > > which is 4096 bits, organized any way you want ( and dual-ported, although
> > that
> > > feature may not be any advantage in your case).
> > > Saves area and routing, and will most likely be faster.
> > >
> > > Remember, you can obviously use any Virtex/SpartanII 4096 bit dual-ported
> > RAM or
> > > ROM=LUT also as two totally independent single-port 2048 bit RAMs or ROMs.
> > >
> > > Peter Alfke, Xilinx Applications

--
--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: 35277
Subject: Re: sensitivity list
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Thu, 27 Sep 2001 18:38:12 +0100
Links: << >>  << T >>  << A >>
In article <3BB349B2.712D1072@gmx.de>, Falk Brunner
<Falk.Brunner@gmx.de> writes
>yaohan schrieb:
>> 
>> However, when I simulate using MAX+PLUS II, the results show that Y is
>> update to A input values after short delay. As if the sensitivity list does
>> not have any effect .. ( Or may be the compiler has included all the signal
>> into sensivity list ...)..
>
>yes. From my point of view, the sensitivity list is just some kind of
>dinosaur from the good, old days when VHDL was defined and the guys
>wantet to make the language designed according to theoretical standards.
>Nowaday (and even in the good old days) a compiler should have no
>problem to find the input signals of a process (clocks, data) by itself.
>

Sorry Falk, I can't agree with you about that.  There are plenty
of situations in test benches where I really NEED to control what's
going on by means of a sensitivity list.  There is no "a priori" way
of inferring, from the process code, what should be in the sensitivity
list.

Of course, if you are restricted to the standard synthesisable 
subset, then it IS quite easy to infer the sensitivity list from the
procedural code;  many synthesis tools do exactly that, and some
(to their great shame IMHO) don't even report it as a warning if
their inferred list differs from your explicit one.  But it seems
to me to be very important that we keep as much control as possible
in our simulations, and that synthesis should agree with simulation
behaviour in a "correct by construction" way.  To achieve that
requires that synthesis and simulation interpret sensitivity lists
in the same way.

Just my opinion, of course.
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 35278
Subject: Re: Logical constraints of LUT
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Thu, 27 Sep 2001 20:24:42 +0200
Links: << >>  << T >>  << A >>
> 1/2 the clock and accessing 2 words at a time.  Sounds like what he has is
a limited
> set multiplier (see my web page) with the encoded phase angle as one
input, and the
> input signal as the other.  In practice this isn't much different than the
partial
> products multiplier except it uses less luts and less adders than a full
parallel
> multiplier.  BRAMs are not the way to do that in most cases.

Thanks for the advice. This is pretty much what I am doing, with I/Q signals
going in different LUT's, followed by bus multiplexers which are driven by
the phasor angle input. ( got the 90 degree rotation working fine, but can
you give any advice as to the optimal configuration for a 45 degree
rotation. Having one large LUT seems very inefficient - I tried splitting
into two LUTs, followed by two adders to sort out the real and imaginary
terms.

Thanks
Adrian






Article: 35279
Subject: Re: how to dublicate logic?
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Thu, 27 Sep 2001 18:47:30 GMT
Links: << >>  << T >>  << A >>
Which synthesis tool?

Synplify has no problem duplicating signals like you need, and the P+R
tools do not seem to merge them back...

--a

Jens-Christian Lache wrote:
> 
> John_H wrote:
> 
> > Please let us know
> >   1) synthesis tool,
> >   2) coding language
> >
> > Jens-Christian Lache wrote:
> >
> > > Hi!
> > > To reduce the fanout of a tristate signal leading to 64 iobs I
> > > tried dublicate this signal. How do I tell
> > > the synthesis tool now not to remove my dublicated logic?
> > > ( I tried to use a BUFG as well, but that didn't work at all)
> > > thanks for your help,
> > > -jc-
> 
> Hi!
> 1) foundation 3.1i
> 2) vhdl
> 
> In the "Libraries Guide 3.3.06i -- Online" under Design Elements,
> BUF is a comment about this problem:
> 
> .. the buffer is preserved by attaching an X (explicit) attribute to
> both the input and output nets of the BUF."
> 
> I tried it, but it didn't work.
> 
> This is the code:
> http://d6.design.chalmers.se/jctmp/jctmp/specache.vhd
> 
> I would like to tell the synthesis tool a max fanout for the
> 
> readBuffer0Pipeline1: FDCE  FF and to have
> it generate several nets with smaller fan out
> automatically.
> 
> Thanks a lot!!!!!!!!!!!!!
> 
> -jc-

Article: 35280
Subject: System DSP Generator on Xilinx
From: tony_kirke@yahoo.com (Tony Kirke)
Date: 27 Sep 2001 11:47:47 -0700
Links: << >>  << T >>  << A >>
Has anyone had success using Xilinx's System Generator for FPGA DSP design?
Is the tool relatively stable and mature?
Thanks.

Article: 35281
Subject: Re: Programming flash connected to CPLD via JTAG
From: "Ulf Samuelsson" <ulf@atmel.dot.com>
Date: Thu, 27 Sep 2001 21:01:45 +0200
Links: << >>  << T >>  << A >>

"Mike R." <mrandelzhofer@uumail.de> skrev i meddelandet
news:3bb334e7$0$192$4d4ebb8e@read.news.de.uu.net...
> Hi Matthias,
>
> The only big disadvantage of SRAM fpgas is:
> there is no single chip solution.You always need a configuration memory on
> startup.
>


The AT94Sxx Secure FPSLIC contains the FPGA and Configurator in the same
package.
Should be OK for anyone.

--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden




Article: 35282
Subject: Re: Logical constraints of LUT
From: Ray Andraka <ray@andraka.com>
Date: Thu, 27 Sep 2001 19:29:37 GMT
Links: << >>  << T >>  << A >>
It depends on how many angles you wish to have in your rotation table, and on
the sample rate desired. If it is only a few angles, then the partial product
multiplies work fine, especially if augmented with two's complementers so that
the mixer works in one quadrant only and the other quadrants are obtained by
selected negation.

Rather than using LUTs, however, I often use a CORDIC rotator as described in my
article in the Xilinx XCELL journal last december (there is a link to the
article on my website under the publications page).  This is especially true
when you are dealing with complex signals, as the CORDIC often winds up being
less logic, and is capable of arbitrarily fine phase resolution, and done right
has less error than a multiplier solution.

Noddy wrote:

> > 1/2 the clock and accessing 2 words at a time.  Sounds like what he has is
> a limited
> > set multiplier (see my web page) with the encoded phase angle as one
> input, and the
> > input signal as the other.  In practice this isn't much different than the
> partial
> > products multiplier except it uses less luts and less adders than a full
> parallel
> > multiplier.  BRAMs are not the way to do that in most cases.
>
> Thanks for the advice. This is pretty much what I am doing, with I/Q signals
> going in different LUT's, followed by bus multiplexers which are driven by
> the phasor angle input. ( got the 90 degree rotation working fine, but can
> you give any advice as to the optimal configuration for a 45 degree
> rotation. Having one large LUT seems very inefficient - I tried splitting
> into two LUTs, followed by two adders to sort out the real and imaginary
> terms.
>
> Thanks
> Adrian

--
--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: 35283
Subject: Re: Opinions on cypress warp 6.1 and devices?
From: Jon Parker <jparker@dnaent.com>
Date: Thu, 27 Sep 2001 14:34:12 -0500
Links: << >>  << T >>  << A >>


Russell Shaw wrote:

> Hi all,
>
> How's the cypress warp 6.1 ($99) compare to other cheap/free
> VHDL editors/synthesizers?
>
> I'm interested in the delta39k devices which have internal ram.
>
> A particularly attractive feature of the delta39k parts (which
> seem to be in a similar area to the altera acex 1k parts), is
> that they have internal flash and internal (as well as external)
> boot option. The acex 1k parts don't have flash, so you always
> need an external configuration device, which takes up space,
> inventory, and is more exposed to copying...
>
> http://www.cypress.com/pld/warp.html?homeadwarp
>
> --
>    ___                                           ___
>   /  /\                                         /  /\
>  /  /__\                                       /  /\/\
> /__/   / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
> \  \  /  Victoria, Australia, Down-Under      \  \/\/
>  \__\/                                         \__\/

I don't have experience using the actual Cypress PARTS but I've been
using Warp for about 4 years.  I find it to give better error messages
than most VHDL compilers, but some things that I synthesize fairly
easily using Synplify I don't synthesize quite so easily in Cypress.
One frustrating error message you will get however is the mysterious
"Can't handle xxxx in final equations".    I usually find that it is
some way I've coded something and Cypress doesn't like the way I did it.

In general, however, I am pleased with my investment and look forward to
actually using the PARTS in a design.   What is holding me back is the
expensive cable for programming the devices...




Article: 35284
Subject: Re: sensitivity list
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 27 Sep 2001 21:38:24 +0200
Links: << >>  << T >>  << A >>
Jonathan Bromley schrieb:
> 

> Sorry Falk, I can't agree with you about that.  There are plenty
> of situations in test benches where I really NEED to control what's
> going on by means of a sensitivity list.  There is no "a priori" way

Hmm. Can you explain this more detail or give a simple example? I dont
get it at all.
I dont have much expirience with VHDL testbenches (we only use ......
;-)

> of inferring, from the process code, what should be in the sensitivity
> list.
 
> Of course, if you are restricted to the standard synthesisable

I do ;-)

> subset, then it IS quite easy to infer the sensitivity list from the
> procedural code;  many synthesis tools do exactly that, and some
> (to their great shame IMHO) don't even report it as a warning if
> their inferred list differs from your explicit one.  But it seems
> to me to be very important that we keep as much control as possible
> in our simulations, and that synthesis should agree with simulation
> behaviour in a "correct by construction" way.  To achieve that
> requires that synthesis and simulation interpret sensitivity lists
> in the same way.

Yes. 100% ACK.

-- 
MFG
Falk


Article: 35285
Subject: Re: Programming flash connected to CPLD via JTAG
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 27 Sep 2001 21:04:08 +0100
Links: << >>  << T >>  << A >>


"Mike R." wrote:

> Hi Matthias,
>
> The only big disadvantage of SRAM fpgas is:
> there is no single chip solution.You always need a configuration memory on
> startup.
>
> The ideal configuration memory is available from XILINX:
> The XC18V00 series of jtag in system programmable fpga proms - see
> http://www.xilinx.com/partinfo/ds026.pdf
> They work well, but are difficult to get and expensive.
>
> There is often a byte or word wide flash memory in the system which could be
> used for the fpga configuration.
> You can built your own cpld prom loader with a jtag interface, but you must
> use a separate jtag chain for the cpld and the prom loader.
> The jtag interface is well documented and simple, but the spi interface
> needs less logic to implement.
>
> The spi interface is a simple 4 wire interface for data transfer from a
> master to a slave device:

Mike,

I've often thought of doing this and, as you say, the h/w is relatively
straightforward. What's always put me off is figuring out how to do an NT driver
to run the parallel port in raw mode. Do you have any advice where I could at
least find the low level IO stubs. With that I might grit my teeth and figure
out how to use MS VC/C++.



Article: 35286
Subject: Re: System DSP Generator on Xilinx
From: Ray Andraka <ray@andraka.com>
Date: Thu, 27 Sep 2001 20:04:17 GMT
Links: << >>  << T >>  << A >>
The tool is stable, and works well as long as your design can be done entirely
using the xilinx coregen components.  If you want to do your own DSP element,
say a CORDIC rotator for example, there is no easy way to get it into the sytem
generator tool.  If it is not in there, it becomes more or less useless as a
system simulation tool, so in that case it is not much different than a block
editor similar to renoir or Aldec.  You'll also find that doing control logic,
state machines and other "random" stuff is exceedingly difficult.  That said,
the tool is a big step in the right direction, it just needs some more time to
grow up to be truly useful for many designs.

Tony Kirke wrote:

> Has anyone had success using Xilinx's System Generator for FPGA DSP design?
> Is the tool relatively stable and mature?
> Thanks.

--
--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: 35287
Subject: Re: Orcad symbol for a Virtex II
From: "Tim Hart" <thart@verilink.com>
Date: Thu, 27 Sep 2001 13:35:40 -0700
Links: << >>  << T >>  << A >>
I have a basic question. Where can I get a .pin, .pad ro .xnf file to create the part? I am using OrCAD 9.2 and I do have the create part option. I will gladly share the symbol if I can get the necessary file.

Article: 35288
Subject: Re: Programming flash connected to CPLD via JTAG
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Thu, 27 Sep 2001 14:09:34 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote:

>> The spi interface is a simple 4 wire interface for data transfer from a
>> master to a slave device:
>
>Mike,
>
>I've often thought of doing this and, as you say, the h/w is relatively
>straightforward. What's always put me off is figuring out how to do an NT driver
>to run the parallel port in raw mode. Do you have any advice where I could at
>least find the low level IO stubs. With that I might grit my teeth and figure
>out how to use MS VC/C++.
>

I have an NT kernel driver which I have developed for this purpose. I
can license it to interested people. I also have a user level program
to drive it. It would cost less than a week of your time.

Muzaffer
DSP implementations using FPGA
http://www.dspia.com


Article: 35289
Subject: Re: Altera Quartus II: Ouput skew ;-(
From: Henning Trispel <henning.trispel@kielnet.net>
Date: Thu, 27 Sep 2001 23:14:15 +0200
Links: << >>  << T >>  << A >>
rafael plonka wrote:
> 
[...]
> I'm using the Quartus II 1.1 for designing with a APEX 20KE. The VHDL
> code (i.e. State-Machines) I generated with Mentor Graphics HDL Designer
> Series Pro. Now I tried to simulate my target device within the Quartus
> Software. The result was kind of frustrating: Signals I asserted in the
> same state of a state machine clocked with 133MHz had an output skew of
> more than 3ns (and these signals should have a setup and hold
> relationship to the corresponding clock signal of 1 ns as they are the
> command bits of a DDR SDRAM). After looking at the (in my opinion quite
> poor) online documentation, I know that there are different ways of
> "grouping" signals or logic together to reduce such skew or to
> accelerate the whole design, but so far I tried and had no real success.
> Does anyone know how to correct these problems? Also I detected strange
> flickerings at some signals with a frequency of more than 1.1GHz and a
> duty cycle of 25%. Where do these come from? I use signal frequencies of
> 33MHz and multiples of 2x, 4x and 8x (only on internal signals), but I
> don't think they have a relation to these flickering. Or can I ignore
> that problem? But it seems to me as if the simulation is quite exactly
> and the problems would occur in the chip also.

Hello Rafael,

i am working on a EP20K300E design myself right now, although "only" 100
MHz system clock. I also found some problematic timing behaviour, making
all setup times hard to meet. I tried to switch to the new copper parts.
These simulation results where even worse. When I phoned Altera
application, they told me that the simulation timing parameters were not
"finalized" yet and are rather pessimistic. When you look at the data
sheets (at least when I started the design a couple months ago) most
(all?) timing parameters   still showed an tbd (better tbm). By the way,
I am also using Quartus II, 1.1. 

I find a 100+ MHz design which does some "real" work is quite hard to
implement. At cycles of 10ns or less all the delays are quite nasty.
Anyway, try to group logic which belongs together. Use timing
constraints where neccesary.

Best Regards + good luck,

Henning Trispel

Article: 35290
Subject: Re: fir filter on ASIC
From: nimrodm@email.com (Nimrod Mesika)
Date: 27 Sep 2001 14:53:30 -0700
Links: << >>  << T >>  << A >>
You have two options:

1. If the asic clock rate is much higher than the sample rate, just
use a few wide enough multiply-accumulate in a time-sharing
architechture. I.e. if you ran the ASIC at 4 times the sample rate you
could use the same multiplier for 4 coefficients.

2. The other option is to use adders and shifters instead of a real
multiplier. Find a set of coefficients that approximates your desired
set and minimze the number of adders. CSD representation (cannonic
signed digit) is a good representation for coefficients in this case
(something like x000111100000 can be handled using just two adders).

Of course, if the filter is symmetric you can use that to your
advantage. If it is an interpolation or decimation filter - that will
help too.

-- Nimrod.

kkdeep@mailcity.com (kuldeep) wrote in message news:<a0f016a9.0109252112.767f04b1@posting.google.com>...
> thanx robert but unfortunately i cannot change the coefficients to
> suit this method :-( so i have to look for some other method. any more
> pointers will be appriciated.
> --kuldeep
> 
> 
> "RM" <yeren@gmx.de> wrote in message news:<9oq2pu$i9q$1@f40-3.zfn.uni-bremen.de>...
> > the following reference (you can get more by google'ing with FIR BIT SERIAL
> > ftp://ftp.ittc.ukans.edu/pub/projects/DSP/FPGA/Bit_Serial.pdf
> > is intended for FPGA use, but it _might_ be suitable for asic, too, because
> > it
> > is on designs that only include bit shift operations and additions instead
> > of
> > multiplications. Bad side effect: you will have to calculate a new filter
> > that
> > meets the restrictions of the method..
> > robert
> > 
> > "kuldeep" <kkdeep@mailcity.com> schrieb im Newsbeitrag
> > news:a0f016a9.0109250458.7bb874f1@posting.google.com...
> > > i have to implement a 64 tap FIR filter with fixed coefficients in
> > > hardware. I have found some architecture suitable for fpga (using LUTs
> > > of fpga) which don't use multipliers. can somebody point me to
> > > architecture suitable for ASIC?. Since the coefficients are fixed, i
> > > want to optimize or avoid the multipliers.The input sample rate is 16
> > > MHz with 12 bits (in 2s complement).
> > > thanx
> > > kuldeep

Article: 35291
Subject: Re: sensitivity list
From: Bill McDermith <bill_mcdermith@mentor.com>
Date: Thu, 27 Sep 2001 16:28:11 -0600
Links: << >>  << T >>  << A >>
Every VHDL simulator I've used respects the sensitivity list 
for a process; if a simulator didn't do this, it wouldn't be
VHDL compliant. And it's a subtle simulation bug to figure out
when you've inadvertanly left something important 
off the sensitivity list, and I've dealt with this
a couple of times...

In a sense, this is exactly what you want in the "usual"
model for an edge-triggered DFF:

process(clk,rst)
begin
   if rst = '1' then
      q <= '0';
   elsif clk'event and clk = '1' then
      q <= d;
   endif
end process;

In this case, d is not part of the sensitivy list on purpose --
when it changes it won't change the register value. This 
speeds up simulation somewhat.

Bill

Falk Brunner wrote:
> 
> yaohan schrieb:
> >
> > However, when I simulate using MAX+PLUS II, the results show that Y is
> > update to A input values after short delay. As if the sensitivity list does
> > not have any effect .. ( Or may be the compiler has included all the signal
> > into sensivity list ...)..
> 
> yes. From my point of view, the sensitivity list is just some kind of
> dinosaur from the good, old days when VHDL was defined and the guys
> wantet to make the language designed according to theoretical standards.
> Nowaday (and even in the good old days) a compiler should have no
> problem to find the input signals of a process (clocks, data) by itself.
> 
> --
> MFG
> Falk

-- 
Bill McDermith                 Staff Engineer 
Mentor Graphics Corp           (719) 265-9827
4920 Sapphire Drive            Fax: 719-593-1653
Colorado Springs, CO 80918     e-mail: bill_mcdermith@mentor.com

Article: 35292
Subject: Fastest way to become a Verilog samurai?
From: M <mac@culver.net>
Date: Thu, 27 Sep 2001 16:12:21 -0700
Links: << >>  << T >>  << A >>
Hi, I'd developing a design for a 2V6000 using Xilinx 4.1i and Synplicity.

I have much experience in s/w at all levels, as well as digital and analog h/w,
and even fpga design years ago using schematics.  

What is the fastest way to become a Verilog expert these days?  Classic books
like the Thomas/Moorby "The Verilog Hardware Description Language" seem dated,
and Smith's "HDL Chip Design" is cluttered (IMHO) with VHDL, which we can't use
here.

Anyway, advice appreciated!

Thanks -Mike

Article: 35293
Subject: Re: Programming flash connected to CPLD via JTAG
From: "Mike R." <mrandelzhofer@uumail.de>
Date: Fri, 28 Sep 2001 01:39:00 +0200
Links: << >>  << T >>  << A >>
Hi Rick,

see:
Programming Tools for Port I/O and Interrupts in
http://www.lvr.com/parport.htm

or
download port95nt.exe from www.xess.com

Mike



"Rick Filipkiewicz" <rick@algor.co.uk> schrieb im Newsbeitrag
news:3BB38638.700F93CB@algor.co.uk...
>
>
> "Mike R." wrote:
>
> > Hi Matthias,
> >
> > The only big disadvantage of SRAM fpgas is:
> > there is no single chip solution.You always need a configuration memory
on
> > startup.
> >
> > The ideal configuration memory is available from XILINX:
> > The XC18V00 series of jtag in system programmable fpga proms - see
> > http://www.xilinx.com/partinfo/ds026.pdf
> > They work well, but are difficult to get and expensive.
> >
> > There is often a byte or word wide flash memory in the system which
could be
> > used for the fpga configuration.
> > You can built your own cpld prom loader with a jtag interface, but you
must
> > use a separate jtag chain for the cpld and the prom loader.
> > The jtag interface is well documented and simple, but the spi interface
> > needs less logic to implement.
> >
> > The spi interface is a simple 4 wire interface for data transfer from a
> > master to a slave device:
>
> Mike,
>
> I've often thought of doing this and, as you say, the h/w is relatively
> straightforward. What's always put me off is figuring out how to do an NT
driver
> to run the parallel port in raw mode. Do you have any advice where I could
at
> least find the low level IO stubs. With that I might grit my teeth and
figure
> out how to use MS VC/C++.
>
>



Article: 35294
Subject: Re: sensitivity list
From: "yaohan" <engp1590@nus.edu.sg>
Date: Fri, 28 Sep 2001 08:04:10 +0800
Links: << >>  << T >>  << A >>
Thank you guys.....

"yaohan" <engp1590@nus.edu.sg> wrote in message
news:191C91BDFE8ED411B84400805FBE794C1884252F@pfs21.ex.nus.edu.sg...
> hi,
> I have a problem which I feel difficult to explain.
>
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity test is
>  port(
>       A: in integer range 0 to 127;
>       Y: out integer range 0 to 127
>  );
> end test;
>
> architecture test_bev of test is
>      signal B: integer range 0 to 127;
> begin
>      process (A)          --process A
>     begin
>        B <= A;
>        Y <= B;
>  end if;
>  end process;
> end test_bev;
>
> As for my understanding, the process A will only execute when change on
> signal A. So Let say, I only change the value A for once, this value
should
> be assigned to B; Mean while Y is assigned with OLD B value. As long as no
> change on signal A, this process will be suspended, i.e Y == value of OLD
B.
>
> However, when I simulate using MAX+PLUS II, the results show that Y is
> update to A input values after short delay. As if the sensitivity list
does
> not have any effect .. ( Or may be the compiler has included all the
signal
> into sensivity list ...)..
>



Article: 35295
Subject: Re: Spartan-IIE?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 27 Sep 2001 17:29:28 -0700
Links: << >>  << T >>  << A >>
I wrote about Spartan II-E:
> Is it just a cheaper Virtex-E
       
Austin Lesea <austin.lesea@xilinx.com> writes:
> Less expensive, or cost reduced, or low cost specific application
> targeted, or ASIC/ASSP replacement device I believe are the politically
> correct descriptors.

Sorry, I should have been more precise and said "less expensive".  I
was only using "cheap" in the sense of inexpensive, without any intended
negative connotation.

Article: 35296
Subject: Re: Opinions on cypress warp 6.1 and devices?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 27 Sep 2001 17:31:19 -0700
Links: << >>  << T >>  << A >>
Jon Parker <jparker@dnaent.com> writes about Cypress Warp:
> In general, however, I am pleased with my investment and look forward to
> actually using the PARTS in a design.   What is holding me back is the
> expensive cable for programming the devices...

You can build the cable yourself.  It is nearly trivial, and the
schematics are readily available.  I'm pretty sure they are in one of
the apnotes on the Cypress web site.

Article: 35297
Subject: Re: Fastest way to become a Verilog samurai?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 01:13:29 GMT
Links: << >>  << T >>  << A >>
Use it.

M wrote:

> Hi, I'd developing a design for a 2V6000 using Xilinx 4.1i and Synplicity.
>
> I have much experience in s/w at all levels, as well as digital and analog h/w,
> and even fpga design years ago using schematics.
>
> What is the fastest way to become a Verilog expert these days?  Classic books
> like the Thomas/Moorby "The Verilog Hardware Description Language" seem dated,
> and Smith's "HDL Chip Design" is cluttered (IMHO) with VHDL, which we can't use
> here.
>
> Anyway, advice appreciated!
>
> Thanks -Mike

--
--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: 35298
Subject: Re: fir filter
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 02:28:02 GMT
Links: << >>  << T >>  << A >>
If it were for an FPGA, I'd immediately say use distributed arithmetic.
For an ASIC, the answer is less certain, especially if you don't have many
clocks per sample to work with.  Distributed arithmetic can be paralleled
up to handle more than one bit at a time, and in the extreme it is all
bits in parallel.  It maps nicely to FPGAs because it efficiently uses the
4 input look-up tables the FPGA is constructed from.  In an ASIC, these
LUTs would have to be implemented as small ROM (for fixed coefficients),
or RAM if the coefficients had to be programmable.   In the case a a full
parallel distributed arithmetic, the savings over a more conventioal set
of multiply accumulators is greatly diminished, and if you include the
gate complexity of the small ROMs may actually exceed that of a more
conventional multiplier-accumulator approach.  Now to answer your doubts:

1)  This referred to folding the filter if the coefficients are symmetric
(a common occurence for FIR filters).  It uses less hardware to wrap the
tapped delay back on itself, adding the samples that get multiplied by the
same (symmetric) coefficients before the multiply.  That reduces the
number of multiplies that need to be done by a factor of 2.

2) Assuming your filter is symmetric by your earlier questions, then you
have 33 unique coefficients.  If your LUTs are 4 LUTs, then you have 8
with 4 taps, and 1  with 1 tap for a bit serial implementation.  For digit
serial (more than 1 bit per clock) implementation, you have 33 taps per
bit.  There is nothing stopping you from combining taps for different
bits, provided you scale the addends for the partial sums with the
appropriate weighting for the bit, as all the partial products are
eventually summed anyway.  So for a 2 bit digit serial, you have 2 bits
times 33 unique coefficients.  Using 4 LUTs, you need a total of 66/4 or
18 LUTs.  The last one has zeros associated with the unused inputs.  In
the case you mention below, where there is only 1 tap attached to the LUT,
the LUT can be replaced with just an and gate, which can generally be
absorbed into the adder tree.

kuldeep wrote:

> Hi jacky ,
>    Thanx for reply. This seems to be good architecture as i can
> tradeoff throughput with hardware . Fully serial approach will not
> work for me as my input data is coming at 16Mhz, 12-bit wide. That
> means i need clock of 192MHz (16x12) which i can't afford .correct me
> ..so i will go for some mix of serial -parllel approach.
>   i have two doubts:
>  quoting a line from ur reply :
> 1."you better add coefficient before feeding the partial products
> table"
> Here do u mean adding inputs (for which coeffcient happen to be same)
> before feeding the partial product table? Plese elaborate further how
> can i take advantage of symmetrical coeffcients.
> 2. i have odd number (65) coeffcients. Each LUT take 4 coeff. so where
> will the last coeff go?? should i use 1 LUT for this single coeff.
>
> thanx and regds
> Kuldeep

--
--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: 35299
Subject: Re: verification problems please help
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 02:31:04 GMT
Links: << >>  << T >>  << A >>
Are you sure you have all the signals you need connected.  At first blush, it
sounds like something you need is unconnected and causing much of the logic to
be optimized out by the mapper.  You could try disabling the trim unconnected
logic to see if it works then, it might at least help you pinpoint why it is
getting stripped out.

timnicolson wrote:

> Help
>
> Can anyone experienced with fpga design suggest what I maybe doing wrong.
>
> I have quite a large design for an 8-bit space vector motor controller, for
> implementation on a SpartanII device.
>
> I have design the system using Xilinx's foundation software.
>
> I have used a mixture of coregen modules and VHDL macros stuck together in
> the schematic editor.
>
> The design simulates as intended.
>
> Problems arise when implementing, I get some warnings because some of my
> coregen signals do not connect to anything (do I need them too?), and I get
> some other warnings saying 100% back annotation not possible for some of the
> blocks.  It finishes and says its implemented OK.
>
> Now I go to verify the design.  It doesn't work as intended, I've searched
> around, and found the problem, a CoreGen "pipelined divider" module is
> producing rubbish, not remotely what it should do.... but only when I verify
> the whole design!  if I enter verification and then select "verify single
> component" from the file menu, and select the next hierarchy down, which
> contains the divider, the module verifies correctly.
>
> This problem is really beyond me at the moment, can someone give me any
> pointers to what the problem maybe.
> Thanks for your time/effort
>
> Tim Nicolson
> University of Sheffield
> UK

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





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