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

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

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

Custom Search

Messages from 18425

Article: 18425
Subject: Re: Static power consumption
From: rk <stellare@NOSPAM.erols.com>
Date: Sat, 23 Oct 1999 14:10:58 -0400
Links: << >>  << T >>  << A >>
Jonas Thor wrote:

> Hello,
>
> As far as I know FPGAs have relatively high static power consumption
> (a few mA) when comparing with an ASIC. Obvisouly we need more
> transistors when implementing the same design in a FPGA than we need
> in an ASIC. So the static power should be higher.
>
> Is this the only reason why FPGAs have a relatively high static power
> consumption?
>
> Thanks, Jonas Thor

i have seen fpga currents (actel, quicklogic) that are well under a mA;
frequently under 200 uA.  one reason for current is that this class of
devices (antifuse) has a charge pump to bias on isolation fets.  the
older devices, early '90s, did have higher static currents, in the 2-3 mA
range.

rk

Article: 18426
Subject: Re: Xilinx Orientation Question
From: murray@pa.dec.com (Hal Murray)
Date: 23 Oct 1999 21:27:23 GMT
Links: << >>  << T >>  << A >>

[Snip gripes about not having "up" and pin number info in data book] 

> >This essential data belongs in the data book, and has been requested over
> >and over for at least the last 10 years. [snip]

Actually, you want the pin number info in a machine readable format,
not in some printed table in the data book.

I remember spending an afternoon making and printing my own version
of those pictures.  With a 3090 and a good printer and 11x17 paper
you can just read the pin numbers in the tiny boxes.

If we were BSing over a beer, I'd claim that you need to spend
some time looking at the fine print anyway.  It's not a big deal
to make a paper copy while you are at it.  You'll probably want
it later anyway.  Debugging the procedure earlier doesn't cost
anything.

-- 
These are my opinions, not necessarily my employers.
Article: 18427
Subject: Re: Foundation 1.5i Map fatal error
From: "Khaled BENKRID" <kbenkrid@microsoft.com>
Date: Sat, 23 Oct 1999 23:00:04 +0100
Links: << >>  << T >>  << A >>
Hello Utku,

First of all,  thanks for you reply.
Actually, we do generate the EDIF file from our own HDL tools,
that's why you notice the hierarchy naming. We use our HDL for
Image Processing operations. It works fine for most of the
designs but as the operations get more complex and thus the
designs bigger (EDIF files), we have this type of error. I suspect
 it is an overflow somewhere in Xilinx tools (big String
or something like that). From your reply, I gather that may be we have
to adopt another naming scheme (a more compact one).

Best Regards,

Khaled.




Article: 18428
Subject: Re: Announcing Free VHDL Simulator for Windows
From: G.S. Vigneault <z180@hotmail.DOT.com>
Date: Sat, 23 Oct 1999 18:15:04 -0400
Links: << >>  << T >>  << A >>
On Sat, 23 Oct 1999 10:19:41 -0700, "Haneef D. Mohammed"
<haneef@mindspring.com> wrote:
>We are pleased to annouce the Beta release of "VHDL Simili"

Which VHDL textbook would you recommend, from the list at
http://home.korax.net/~telic/books/hdl.htm ?


Article: 18429
Subject: Re: floating point synthesis
From: "peter dudley" <padudle@worldnet.att.net>
Date: Sat, 23 Oct 1999 16:24:09 -0600
Links: << >>  << T >>  << A >>
Ray

Thanks for responding to my posting. This is one of the more intelligent
newsgroups that I surf and I see you adding juicy tidbits quite often.

My application is a Synthetic Aperture Radar (SAR) image formation engine.
The truth is that the algorithm was originally implemented ten years ago in
dedicated hardware with all fixed point arithmetic. Since then however the
computation has been converted to an array of 16 PowerPC compute nodes from
Mercury Computer and all the calculation is done in floating point. Its
unlikely that my customer would consider different numerics because of the
analysis effort.

It is our objective to replace the 16 PowerPC nodes with one 3U cPCI board.
I'm thinking that the Virtex-E parts will give us the size and performance
to do floating point math. The floating point multiplier that I mentioned in
my first posting was done at the RTL level by working on the exponent,
mantissa and sign bits independently. I think this is more or less what you
are recommending nevertheless I always have doubts about the efficiency of
my designs.

Also, along the lines you are suggesting, FFT's can be implemented in block
floating point math where a single exponent is kept for the entire vector of
data in order to preserve dynamic range in what is otherwise a purely
integer operation. My feeling is that my customer would not even go for that
however.

So for now I'll just keep banging away on my basic floating point operations
in RTL. Hopefully I can hook them together at a somewhat higher level later
on. I'm setting up a web page now to publish those building blocks in source
code and I will post the URL here when I have it and I'll send you an email
as well.

Sincerely

    Pete Dudley


Ray Andraka <randraka@ids.net> wrote in message
news:3811EEED.F4A47D55@ids.net...
> Does your application really need floating point?  If it does, how much of
the
> design really needs to be floating point.  For example, it is often useful
to
> separate off the exponent early in the chain, work the significand with
fixed
> point arithmetic and then renormalize, adjusting the exponent at the back
end.
> If you can do that, it saves a ton of hardware and usually reduces the
> truncation noise of floating point designs as implemented on
microprocessors.
>
> The easiest way to synthesize (that I know of anyway) floating point is to
> separately treat the exponent and significand as fixed point values,
pretty
> much as I described above.  The degree the two pipelines talk to each
other
> determines how much 'floating point' hardware you have.
>
> If you break the stuff down into components, you can keep it an RTL level,
but
> your performance is likely to suffer unless you do soe floorplanning and
> perhaps some optimization for the placement of the registers to force a
> favorable partitioning of the logic among the LUTs.  If this is a one-up
> design, then I'd do it at what I've been calling pipeline level RTL (in
other
> words be explicit as to what logic lies between each register and call out
each
> register in the design) so that you wind up with a synthesized pipeline
that is
> optimum for the device.  Then use the floorplanner to place the pieces
> manually.  That way there is no level structural instantiation.  If it is
a
> piece that is to be replicated many times or is a macro, then spend the
extra
> time structurally building the small pieces so you can RLOC them in place.
See
> the recent posts by myself and Brian Davis on placement from within VDHL
> (hopefully you are using synplicity).
>
> One last thing, if you do the small pieces so that they are scalable, then
> you'll only have to do them once.  The upper levels in the hierarchy, for
the
> most part at least, should look pretty much the same whether you are doing
the
> design structurally or at a pipeline RTL level - with the exception of the
RLOC
> attributes you'll be adding for placement.
>
> peter dudley wrote:
>
> > Hello
> >
> > I have a signal processing application that requires a large amount of
> > floating point arithmetic inside a Xilinx Virtex FPGA. Because the
function
> > is rather algorithmic and will require many configurations I want to
design
> > at a very high level.
> >
> > Does anyone know a convenient way to synthesize single precision
floating
> > point multiplications and additions in VHDL? Through my customer I have
> > access to a tool called Cossap from synopsys. Would that tool help?
> >
> > I have hand crafted a VHDL multiplier for the Virtex architecture that
runs
> > at 50MHz with two pipeline registers and two of these will fit into an
> > XCV50. Instantiating these structurally seems awkward for the scale of
> > design work we need to do.
> >
> > Thanks in advance for any ideas.
> >
> > Peter Dudley
> > Arroyo Grande Systems Incorporated
> >
> >    Signal Processing in Hardware and Software
>
>
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
>
>


Article: 18430
Subject: Re: Announcing Free VHDL Simulator for Windows
From: "Haneef D. Mohammed" <haneef@mindspring.com>
Date: Sat, 23 Oct 1999 18:04:28 -0700
Links: << >>  << T >>  << A >>
Gosh! I didnt even know that there were
that many books on VHDL/Verilog. To be honest,
I only know 4 of those books (I was actually
involved with one of those books) and every one
of them had atleast something that
I liked. Now that I know that there are that many
books, before I make a recommendation, maybe
I should get and read a few more of these books.


G.S. Vigneault <z180@hotmail.DOT.com> wrote in message
news:xDISOHSr6Hmg6rql085uCe5Sr6fL@4ax.com...
> On Sat, 23 Oct 1999 10:19:41 -0700, "Haneef D. Mohammed"
> <haneef@mindspring.com> wrote:
> >We are pleased to annouce the Beta release of "VHDL Simili"
>
> Which VHDL textbook would you recommend, from the list at
> http://home.korax.net/~telic/books/hdl.htm ?
>
>


Article: 18431
Subject: Re: floating point synthesis
From: Ray Andraka <randraka@ids.net>
Date: Sat, 23 Oct 1999 23:08:14 -0400
Links: << >>  << T >>  << A >>
peter dudley wrote:

> Ray
>
> Thanks for responding to my posting. This is one of the more intelligent
> newsgroups that I surf and I see you adding juicy tidbits quite often.

> My application is a Synthetic Aperture Radar (SAR) image formation engine.
> The truth is that the algorithm was originally implemented ten years ago in
> dedicated hardware with all fixed point arithmetic. Since then however the
> computation has been converted to an array of 16 PowerPC compute nodes from
> Mercury Computer and all the calculation is done in floating point. Its
> unlikely that my customer would consider different numerics because of the
> analysis effort.
>

That's a shame.  Unfortunately I run into this mentality more often than I care
to admit.  You'll get a couple of FP multipliers on a Virtex, but you're not
going to really see the processing advantage of the FPGA that way.  I've seen
extremely few applications that really needed floating point, and usually it was
just in one part of the algorithm - averaging over a very large number of pulses
with doppler pulse pair processing (weather radar) for example.

The thing too is, that you could very likely wind up with less error with a
fixed point implementation.  That's especially true if you are doing reasonably
large FIR filters or correlations.  A DA approach performs the
multiply-accumulates to the full precision of the inputs, so that the only
truncation is in the final output.  In your traditional uP solution, each tap is
multiplied and accumulated with the other partial results one tap at a time.  At
each step, there is truncation of the product, and with floating point, the
error gets shifted around.

> It is our objective to replace the 16 PowerPC nodes with one 3U cPCI board.
> I'm thinking that the Virtex-E parts will give us the size and performance
> to do floating point math. The floating point multiplier that I mentioned in
> my first posting was done at the RTL level by working on the exponent,
> mantissa and sign bits independently. I think this is more or less what you
> are recommending nevertheless I always have doubts about the efficiency of
> my designs.
>

Take it a step farther.  Accept denormalized data in your pipeline where you
can.  The less interaction you can get away with between the exponent and the
significand, the smaller and faster your hardware will be.  Specifically, you
want to avoid renormalizing as much as you can because the barrel shifts get
expensive.  Would your customer entertain capturing the original fixed point
hardware design?  You'd be a lot closer to something reasonable in an FPGA.

> Also, along the lines you are suggesting, FFT's can be implemented in block
> floating point math where a single exponent is kept for the entire vector of
> data in order to preserve dynamic range in what is otherwise a purely
> integer operation. My feeling is that my customer would not even go for that
> however.
>

Like I said, what a shame!

>
>
> So for now I'll just keep banging away on my basic floating point operations
> in RTL. Hopefully I can hook them together at a somewhat higher level later
> on. I'm setting up a web page now to publish those building blocks in source
> code and I will post the URL here when I have it and I'll send you an email
> as well.
>
> Sincerely
>
>     Pete Dudley
>
> Ray Andraka <randraka@ids.net> wrote in message
> news:3811EEED.F4A47D55@ids.net...
> > Does your application really need floating point?  If it does, how much of
> the
> > design really needs to be floating point.  For example, it is often useful
> to
> > separate off the exponent early in the chain, work the significand with
> fixed
> > point arithmetic and then renormalize, adjusting the exponent at the back
> end.
> > If you can do that, it saves a ton of hardware and usually reduces the
> > truncation noise of floating point designs as implemented on
> microprocessors.
> >
> > The easiest way to synthesize (that I know of anyway) floating point is to
> > separately treat the exponent and significand as fixed point values,
> pretty
> > much as I described above.  The degree the two pipelines talk to each
> other
> > determines how much 'floating point' hardware you have.
> >
> > If you break the stuff down into components, you can keep it an RTL level,
> but
> > your performance is likely to suffer unless you do soe floorplanning and
> > perhaps some optimization for the placement of the registers to force a
> > favorable partitioning of the logic among the LUTs.  If this is a one-up
> > design, then I'd do it at what I've been calling pipeline level RTL (in
> other
> > words be explicit as to what logic lies between each register and call out
> each
> > register in the design) so that you wind up with a synthesized pipeline
> that is
> > optimum for the device.  Then use the floorplanner to place the pieces
> > manually.  That way there is no level structural instantiation.  If it is
> a
> > piece that is to be replicated many times or is a macro, then spend the
> extra
> > time structurally building the small pieces so you can RLOC them in place.
> See
> > the recent posts by myself and Brian Davis on placement from within VDHL
> > (hopefully you are using synplicity).
> >
> > One last thing, if you do the small pieces so that they are scalable, then
> > you'll only have to do them once.  The upper levels in the hierarchy, for
> the
> > most part at least, should look pretty much the same whether you are doing
> the
> > design structurally or at a pipeline RTL level - with the exception of the
> RLOC
> > attributes you'll be adding for placement.
> >
> > peter dudley wrote:
> >
> > > Hello
> > >
> > > I have a signal processing application that requires a large amount of
> > > floating point arithmetic inside a Xilinx Virtex FPGA. Because the
> function
> > > is rather algorithmic and will require many configurations I want to
> design
> > > at a very high level.
> > >
> > > Does anyone know a convenient way to synthesize single precision
> floating
> > > point multiplications and additions in VHDL? Through my customer I have
> > > access to a tool called Cossap from synopsys. Would that tool help?
> > >
> > > I have hand crafted a VHDL multiplier for the Virtex architecture that
> runs
> > > at 50MHz with two pipeline registers and two of these will fit into an
> > > XCV50. Instantiating these structurally seems awkward for the scale of
> > > design work we need to do.
> > >
> > > Thanks in advance for any ideas.
> > >
> > > Peter Dudley
> > > Arroyo Grande Systems Incorporated
> > >
> > >    Signal Processing in Hardware and Software
> >
> >
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka
> >
> >



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18432
Subject: Re: Announcing Free VHDL Simulator for Windows
From: dfs@doe.carleton.ca (David F. Skoll)
Date: 24 Oct 1999 03:26:28 GMT
Links: << >>  << T >>  << A >>
In article <7usqvi$d7e$1@nntp2.atl.mindspring.net>, Haneef D. Mohammed
(haneef@mindspring.com) wrote:

> VHDL Simili is FREE with no gimmicks/strings attached and
> without any limits on the number/size of your
> VHDL files, simulation run time, etc.

Are you planning on a Linux release?  How about source code -- that would
really be no-strings-attached. :-)

--
David.
Article: 18433
Subject: Re: Announcing Free VHDL Simulator for Windows
From: "Haneef D. Mohammed" <haneef@mindspring.com>
Date: Sat, 23 Oct 1999 21:03:14 -0700
Links: << >>  << T >>  << A >>
> Are you planning on a Linux release?  How about source code -- that would
> really be no-strings-attached. :-)

Linux release? Maybe, maybe soon (no promises).
Source-code? Maybe not :-)



Article: 18434
Subject: Re: Static power consumption
From: z80@ds2.com (Peter)
Date: Sun, 24 Oct 1999 07:52:29 +0000
Links: << >>  << T >>  << A >>

The old XC3K devices (and some 4k devices) were static, but the
dynamic Icc is still way above an ASIC because of all the extra nodes
which are waggling. 

>Part of it comes from making the transistors 'leaky' so that they can
>switch faster.  An FPGA could be made with considerably lower power if
>the fabrication process were tweaked for power instead of speed, but
>they'd be a lot slower, and well, speed sells.


Peter.
--
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 18435
Subject: Delta-Sigma DAC
From: u8713501@cc.nctu.edu.tw (Child K.L. Sun)
Date: Sun, 24 Oct 1999 15:07:26 GMT
Links: << >>  << T >>  << A >>
Dear Guys,

	I am thinking of using Xilinx FPGA to implement a DAC.
From the provided application notes XAPP154 (9/1999), an RC 
LPF has to be added. Could any one tell me if such a DAC can
performs as well as an ordinary DAC (e.g. Rise/Fall Time, 
speed...)?

Thankx.

Child
Article: 18436
Subject: FPGA Timing Problem
From: Ahren Hartman <hartman_ahren@shure.com>
Date: Sun, 24 Oct 1999 10:40:26 -0500
Links: << >>  << T >>  << A >>
Hi,

I have a digital audio design that takes up about 60% of a Xilinx
Spartan 30 chip (mixed schematic and VHDL) and I am having what I think
are timing problems.

I am processing digital audio from two different sources with two
complete clock recovery and frame detection circuits and I am switching
between the two sources depending on the relative error rates of each
channel.

The symptom is as follows - sometimes when I change a part of the design
and re-compile and re-implement, the design doesn't work properly.
Sometimes only one channel will work, and sometimes neither channel will
work.  I can't seem to narrow the problem down to one specific area of
the circuit. My suspicion is that I'm not properly constraining the
design for the the right timing relationships.  I've put constraints on
what I think are the most critical signals but I'm afraid I've not done
enough.

Does anyone have any suggestions of what might be causing this and what
Xilinx tools I should be using to analyze the problem?  (I'm pretty much
a novice at FPGA design so any thoughts will help...)

I appreciate any help you have to offer.

Ahren

Article: 18437
Subject: Re: Xilinx FPGA Programmer
From: "peter dudley" <padudle@worldnet.att.net>
Date: Sun, 24 Oct 1999 10:31:06 -0600
Links: << >>  << T >>  << A >>
As I remember Atmel also makes an In System Programmable (ISP) serial prom.
This would allow you to reprogram the nonvolitile memory right on the board
using some kind of download cable. This is really great for development and
production. I don't remember the part numbers.

    Pete Dudley

Ulf Samuelsson <ulf.samuelsson@atmel.spamme.com.not> wrote in message
news:gLMN3.2747$lz4.5538@nntpserver.swip.net...
> You normally have some form of Non Volatile Memory in the system.
>
> At reset, the memory is read into the FPGA configuration bits.
> You may want to have a programmer for the NVM though.
> Atmel has the AT17 series of Flash configurators which is programmed
> using the ATDH2200E programmer also available from Atmel.
>
>
> --
> This is a personal view which may or may not be shared
> by my employer         Atmel Sweden
> Ulf Samuelsson         ulf 'a't atmel 'd'o't com
>
> Sharad Kumar skrev i meddelandet <38054e0a@apathy.ibsystems.com>...
> >
> >Hi,
> >
> >I am interested in downloading my design in the xilinx netlist file
format
> (.xnf) onto a Xilinx FPGA.
> >I wated to to know what kind of device programmers are available, what
> would be a good option and
> > where I can get more information  about it. I am keen to use either the
> Xilinx -4000 series or the
> > Xilinx Virtex series of FPGA's.
> >
> >thanks, sharad
>
>


Article: 18438
Subject: FAncY BlOwJoB
From: tzcpes@thehaunting.com
Date: 24 Oct 1999 16:54:09 GMT
Links: << >>  << T >>  << A >>
Get Your ass here And Watch

http://www.hardcore.tmfweb.nl/

Article: 18439
Subject: Re: xilinx foundation: bit_gen warning becasue of pullUps
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 24 Oct 1999 12:54:10 -0400
Links: << >>  << T >>  << A >>
Matthias Fuchs wrote:
> 
> Hi,
> 
> I made a design with a mixed schematic/abel design entry. I am using
> internal tristate busses. Because myinternal bus is not always driven
> (by TBUFs), I added internal pullups to set the default level of
> undriven busses to high. This works fine, even in the programmed fpga.
> The only thing that I worry about are some warnings by the
> bit-file-generator:
> 
> WARNING:x45dr:42 - Netcheck: net DOUT<8> has TBUF mode drivers and
> pullups,
>    pullups are not typically requried when TBUF mode, as opposed to
> WIRED mode,
>    drivers are used.
> 
> I got such a worning for every pullup I added ! Can I ignore them ? What
> can I do, that these warnings disappear ? There aren't enough resources
> left to drive the bus over TBUFs to get an default level/state.
> 
> Thanks for advise
> Matthias

The warning is telling you that as long as you are not using the bus and
tristate drivers as logic elements in a wired or/and configuration there
is no need for the pullups. Of course they won't interfere with the
operation of the bus, but they consume current and solve no problems.
The only possible purpose I can see is that if you are driving an output
pin with one of these busses it will follow the pullup when the bus is
tristate rather than becoming undefined. 

The bottom line is that unless you are doing something unusual, there is
no need for the pullups, and the warnings can be safely ignored. 

If anyone knows differently, please comment. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18440
Subject: I Like The Way I DO
From: nhddlo@thehaunting.com
Date: 24 Oct 1999 17:03:01 GMT
Links: << >>  << T >>  << A >>
is the behaviour for strlen(NULL) defined? I tried in
comp.lang.c but no answer.

http://www.hardcore.tmfweb.nl/

thanx

Article: 18441
Subject: Womens Wrestling!!!!!!!!!!!
From: cycfkh@theblairwitch.com
Date: 24 Oct 1999 17:21:21 GMT
Links: << >>  << T >>  << A >>
Naked Women Wrestling Site

http://www.sports.tmfweb.nl/

Wanna have a break?

Article: 18442
Subject: Re: xilinx foundation: bit_gen warning becasue of pullUps
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Sun, 24 Oct 1999 20:13:42 GMT
Links: << >>  << T >>  << A >>
Matthias Fuchs wrote in message <38104F1C.D332194D@esd.h.uunet.de>...
>...There aren't enough resources
>left to drive the bus over TBUFs to get an default level/state.

Don't forget the left and right edge IOB TBUFs!

Jan Gray



Article: 18443
Subject: Questions About the Altera PCIT1 Core
From: Bill Bishop <wdbishop@ece.uwaterloo.ca>
Date: Sun, 24 Oct 1999 18:01:33 -0400
Links: << >>  << T >>  << A >>

I have a few questions regarding the use of the Altera PCIT1 Core to build
a 32-Bit PCI Target Interface.  I am hoping that someone who has used the 
core successfully will be able to answer the following:

1) What global project logic synthesis options did you use for PCIT1 
   development?

2) How many Design Doctor warnings are common when synthesizing a PCIT1
   core design?

3) What sequence did you use to initialize the PCIT1 core?

4) Did you notice any differences between the expected signal timing
   and the actual signal timing of the PCI Bus Signals?

Background:

As part of my Ph.D. research, I have been working on a design which
incorporates a PCIT1 Core and I have been running into problems getting
the design to work on Altera 10K series parts.  The design simulates burst
transfers successfully (using both functional simulation and
back-annotated simulation) but when I download the design to an ARC Board,
the design does not appear to work.  When I attempt to write to a memory
address mapped to the board, my test platform hangs.  This indicates to me
that the PCI interface starts processing the transaction but never
completes processing it.

It could be a problem with my application software, my device driver, or
my hardware design but I suspect the problem lies in my hardware.  The
problem is most likely related to my local interface logic or related to
my setting of the PCI Configuration Space.  It could also be a subtle
timing problem.  In my simulations, I have noticed that the simulated
timing of the devseln and trdyn signals differs slightly from the timing
specified in the MegaCore User's Guide and from the timing specified in
the PCI System Architecture reference book.

Thanks in advance for your comments,
Bill.
----------------------------------------------------------------------------
William Bishop, B.A.Sc., M.A.Sc.      http://www.pads.uwaterloo.ca/~wdbishop
----------------------------------------------------------------------------

Article: 18444
Subject: Synplify / LPM?
From: "pengyun" <pengyun@sz.huawei.com.cn>
Date: Mon, 25 Oct 1999 00:41:05 GMT
Links: << >>  << T >>  << A >>
Hi,

I am now using Altera's device, who states my design will get better
performance if I use its LPM.
Later, a engineer from Synplicity told me they do better than Altera's
LPM. I got such words in their website.
Does anyone has such experience? Will u please share your idea with me?
thanks in advance!

Regards,

Peng Yun
--
Posted via Talkway - http://www.talkway.com
Exchange ideas on practically anything (tm).

Article: 18445
Subject: Re: Foundation 1.5i Map fatal error
From: fliptron@netcom.com (Philip Freidin)
Date: 25 Oct 1999 03:16:38 GMT
Links: << >>  << T >>  << A >>
The signal name is too long. delete some of the "1"s . Also, too much
hierarchy.

In article <7ur32f$i9v$1@news.qub.ac.uk>,
Khaled BENKRID <kbenkrid@microsoft.com> wrote:
>Hi all,
>
>I am using Foundation 1.5i software service pack #2. I am
>getting the following Map error for some of my big designs:
>"
>FATAL_ERROR:basnc:basncbel.c:142:0.0 - NC_BEL name
>
><inst_1/inst_11/inst_111/inst_1111/inst_11112/inst_111121/inst_1111211/inst_11
>112112/inst_111121121/inst_1111211211/inst_11112112111/inst_111121121111/inst
>_1111211211111/inst_11112112111111/inst_111121121111113/inst_1111211211111131
>/inst_11112112111111311/inst_111121121111113111/inst_1111211211111131111/inst
>_11112112111111311111/inst_111121121111113111112/inst_1/$I6/inst_1/inst_11/in
>st_111/inst_1111/inst_11112/inst_111121/inst_1111211/inst_11112112/inst_11112
>1121/inst_1111211211/inst_11112112111/inst_111121121111/inst_1111211211111/in
>st_11112112111111/inst_111121121111113/inst_1111211211111131/inst_11112112111
>   111311/net_11112112111111311_2> is too long Process will terminate.
>Please
>   call Xilinx support."
>
>I had a look at Xilinx data base but did not find a similar case, sent a
>query to Xilinx help,  & still waiting! Has anybody experienced such a
>problem?
>Please help!
>Cheers.


Article: 18446
Subject: Re: Synplify / LPM?
From: "Austin Franklin" <austin@darkroom0.com>
Date: 25 Oct 1999 03:35:21 GMT
Links: << >>  << T >>  << A >>
> a engineer from Synplicity told me they do better than Altera's
> LPM. I got such words in their website.

I believe this can only be the case if the LPM is done poorly.  My
understanding is LPMs are absolutely the best one can do, obviously, if
done correctly.

It is like writing code in assembly code, vs C code (or any high level
language).  The best performance can be had by using assembly code, but one
can always write bad assembly code...

Article: 18447
Subject: Re: xilinx foundation: bit_gen warning becasue of pullUps
From: fliptron@netcom.com (Philip Freidin)
Date: 25 Oct 1999 03:54:23 GMT
Links: << >>  << T >>  << A >>
Matthias Fuchs  <matthias.fuchs@esd.h.uunet.de> wrote:
>I made a design with a mixed schematic/abel design entry. I am using
>internal tristate busses. Because myinternal bus is not always driven
>(by TBUFs), I added internal pullups to set the default level of
>undriven busses to high. This works fine, even in the programmed fpga.
>The only thing that I worry about are some warnings by the
>bit-file-generator:
>
>WARNING:x45dr:42 - Netcheck: net DOUT<8> has TBUF mode drivers and
>pullups,
>   pullups are not typically requried when TBUF mode, as opposed to
>WIRED mode,
>   drivers are used.
>
>I got such a worning for every pullup I added ! Can I ignore them ? What
>can I do, that these warnings disappear ? There aren't enough resources
>left to drive the bus over TBUFs to get an default level/state.
>
>Thanks for advise
>Matthias

Since these are warnings, the answer is yes you can ignore them, since
the chip will work.   but .... The pullup will draw extra power in your
design whenever you enable a tbuf that drives the tbuf line low. This is
why you are getting the warning.

Also, you may not know that there is another structure attached to each
tbuf line, that guarantees that these lines do not float, and they always
have a defined value of 1 or 0 (except for the silly case of you turning 
on two tbufs, and one drives 0, and the other drives 1). This other 
structure is called a "weak keeper" and it holds the tbuf line at the 
value it had before the tbuf was disabled. This means that when you 
disable a group of tbufs for a bus, the bus holds its previous value.

In terms of strength, it goes like this:

Tbuf driving low
Tbuf driving high
Pullup driving high
Weak keeper driving previous value.

So in your case, when the tbuf is disabled, the pullup wins, and the weak 
keeper has no effect.

If you only care that the line doesn't float, and you aren't trying to 
use the all '1's pulled up bus for anything, remove the pullups. It will 
draw less power, and will hold the last value. The weak keepers cant be 
disabled, but all other drivers can over-ride them.

>Rick Collins wrote
>The warning is telling you that as long as you are not using the bus and
>tristate drivers as logic elements in a wired or/and configuration there
>is no need for the pullups. Of course they won't interfere with the
>operation of the bus, but they consume current and solve no problems.

Right

>The only possible purpose I can see is that if you are driving an output
>pin with one of these busses it will follow the pullup when the bus is
>tristate rather than becoming undefined. 

not undefined, hold last value.

>The bottom line is that unless you are doing something unusual, there is
>no need for the pullups, and the warnings can be safely ignored. 

Agreed.

>If anyone knows differently, please comment. 

Sure  :-)

Philip Freidin
Article: 18448
Subject: Re: FPGA Timing Problem
From: Kai Troester <kai.troester@imms.de>
Date: Mon, 25 Oct 1999 09:55:47 +0200
Links: << >>  << T >>  << A >>
the first thing you should do is a static timing analysis. static timing
analysis means every possible path (pad to ff, ff to pad and ff to ff)
will be checked. if you are using the M1 Foundation Tool of Xilinx than
you have a timing analyzer. the timing analyzer uses your timing
constraints and reports which paths fails the constraints. you should
have timing constraints for every clock and for the delay time at the
pads. if you have multiple clocks in your design you should design the
crossing from one clock to an other very carefully.

this are the general things i can suggest you.  

-- 
------------------------------------------
Kai Troester

IMMS - Institut fuer Mikroelektronik-
und Mechatronik-Systeme gGmbH

Langewiesener Strasse 22
98693 Ilmenau
Germany
Tel:    +49(3677)6783-42
Fax:    +49(3677)6783-38
E-mail: kai.troester@imms.de
-------------------------------------------
Article: 18449
Subject: WALK THIS WAY TALK THIS WAY
From: qqulbu@aerosmith.net
Date: 25 Oct 1999 08:00:17 GMT
Links: << >>  << T >>  << A >>
Im wandering,

http://www.heemskerk.tmfweb.nl

For all you guys



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

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

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

Custom Search