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 16525

Article: 16525
Subject: Re: High Speed Reconfigurability
From: Tim Tyler <tt@cryogen.com>
Date: Wed, 26 May 1999 19:01:01 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga Roland Paterson-Jones <rpjones@hursley.ibm.com> wrote:
: brian_n_miller@yahoo.com wrote:
:> rolandpj@bigfoot.com wrote:

:> > I like to to view the problem as an extension of HotSpot/JIT.
:> > ... Why not do the same thing, but right down to the hardware?
:>
:> Reliability.  If an FPGA fails to reconfigure itself properly,
:> then how to recover?

: Forgive my innocence, but why is this perceived to be a problem?

Component reliability is a general problem with all parallel computers;
the main idea is that there are more components: if each has a fixed
probability of failure then the chances of failure occurring in a
parallel computer are greater than in a serial one - due to there
being more components to fail.

: It might be the case that reconfigurability is flaky at the moment but
: this just has to be fixed to make dynamic reconfigurability viable.

Well, perfect reliability is not practically attainable, and the
more components the computer has the more likely failures become.

FPGAs generally have high component counts, though x86 processors
aren't exactly low...

Pesonally I think the problem is best dealt with by mainly through the use
of fault-tolerant software, though attempts to make the hardware more
resilient obviously have a role to play.


What appears to be needed to trigger the long-awaited programmable logic
revolution, is the proverbial 'killer application' - where people are
prepared to buy programmable logic components in order to run particular
software.

Current the nearest thing to this is circuit design and prototyping -
which will probably remain something of a minority activity.

The application can't be too specialised; people buy purpose-build
graphics and sound cards, rather than a component which is capable of
being programmed to do anything.

At one point I wondered if speech recognition would provide such an
application.  These days I think any vendors who offered a hardware
solution (and these appear to be uncommon these days) would offer
specialised DSP hardware, rather than an FPGA-based solution.

I am still not sure whether Java will be terribly pivotal in this area.
It /may/ be good, because it's fairly general purpose.

Would a partly FPGA-based approach be the best way to achieve maximum
speed?  I'm not yet convinced - it may be that a vaguely conventional
design oriented towards Java bytecodes would be faster, at least on your
'average' Java application.

Reconfigurability will probably always have a certain performance cost
associated with it - and I'm not sure whether running Java is a
general-purpose enough application for it to be able to make use of
that reconfigurability fully enough to justify its costs.  If much of
the programmed circuitry winds up being the same old "execute bytecode"
program, then having this in programmable logic will only slow things
down.

The best way of using FPGAs to accelerate Java /may/ be to use them to
prototype chips specifically designed to run Java bytecode.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Where there's a will, I want to be in it.
Article: 16526
Subject: Re: DSP Board for PC/104 Bus
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 May 1999 15:42:16 -0400
Links: << >>  << T >>  << A >>
rrohatgi@kendra.com wrote:
> 
> In article <3744ADBA.9E5F4A96@yahoo.com>,
> In my experience, product limitations are analog or power supply
> related more than something I can put into an FPGA.

I plan to deal with the analog limitation by making the analog I/O a
daughter board. There will be diffferent add ons for different needs.
With two daughter board sites, that should provide a lot of flexibility. 

I don't understand what you mean about power supply limitations. Do you
mean the board requires too much current from the supply or too many
voltages?

 
> > it. That is why I am building this board. I think there will be a
> number
> > of people who would like to use the DSP in conjunction with a good
> FPGA.
> 
> Sounds like you've already made up your mind :-)

Acutally, I am building the board because a customer is paying me to
build it. But I am trying to put in useful extra features so that I can
sell it generally. So the tradeoff depends on how useful a feature is. I
can shave a good $50 to $100 off the price of the board if I leave off
the big FPGA. I am sure that $100 cheaper price is a useful feature. So
the choice is based on whether the big FPGA will be more useful than
$100. 

 
> > using a Lucent ORCA part instead of a Xilinx part. It would appear
> that
> 
> Altera, last I checked, had free software for entry-level parts like
> EPF8282A.  Plus their software works and is easy to use.

Right now the choice is between the Lucent OR3T or the Xilinx Spartan,
XC4000XLA, or Virtex. The Lucent gives me the best trade off between
price, performance and I/O pins. The Xilinx is certainly a more familiar
name. But the Lucent software is only $100 (or free if you beg) for a
package that supports up to 30K gates and VHDL. 

So I haven't made up my mind. But I am looking for compelling arguments
on either side. 

> Good luck,
> -rajeev-

Thanks. I'll let you know when it is done. 


-- 

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: 16527
Subject: Re: Virtex based PCI cards
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 May 1999 15:54:08 -0400
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > Austin Franklin wrote:
> > >
> > > I just thought of one SMALL problem... I don not believe Virtex
> supports 5V
> > > PCI???
> >
> > XAPP 133 (dated Oct 21, 1998) claims so.  Is it incorrect?
> 
> They may claim it does....but....  They don't provide a VCCIO pin, which is
> to be used for the clamp diodes...and it can't technically meet spec if
> they don't.  PLX has the same problem with the 9054...it's a 3.3V part,
> with no VCCIO pin...
> 
> Any PCI interface that is NOT 5V powered, and is used in a 5V environment,
> has to have VCCIO...and same is true for any other voltage variants...
> 
> Austin

I get email from the PCI SIG. They were discussing just this aspect of
the PLX9054 chip. I believe that the consensus was that you are not
required to clamp in a 5 volt environment, while you are in a 3.3 volt
environment. 

The issue was whether you had to clamp in a 3.3 volt environment. One
poster quoted the spec saying you had to clamp. A PLX representative
posted a quote that said you didn't. A third poster claimed that the PLX
quote refered only to 5 volt operation. In any case, PLX seems to think
their chip is fully compliant with the spec. 

I haven't verified any of this. So perhaps you can tell me who is right.


-- 

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: 16528
Subject: Re: Synthesis problem
From: Elder V Costa <elder@dixtal.com.br>
Date: Wed, 26 May 1999 17:22:19 -0300
Links: << >>  << T >>  << A >>
Try using a guide file. Look for a file with extension .gyd. Edit it
with your pinout and save it on a different directory. Then go to Design
Manager menu Design->Implement->Options and choose custom guide file and
browse your new gyd file (I am using F1.4M but I think 1.5 must be
similar.)

Tximo wrote:
> 
> Hi all,
> 
> I am trying to synthsise a design with Xilinx Foundations F1.5, with
> some inputs and outputs.  I have a constraint file to locate every
> signal in a pin, but I get the error message:
> 
> ERROR:baste:263 - The LOC constraint "P68" (a IOB location) is not valid
> for
>    symbol "linea_lect.PAD" (pad signal=linea_lect), which is being
> mapped to the
>    following site types:
>     CLKIOB
> 
> My signal is fixed at PIN 68, a normal IOB, but the synthesis tool map
> the signal to a clock, and I don't know why.
> 
> Anyone has any idea?
> 
> Thanks to all for reading my message and sorry for my english.
Article: 16529
Subject: Re: High Speed Reconfigurability
From: brian_n_miller@yahoo.com
Date: Wed, 26 May 1999 21:02:39 GMT
Links: << >>  << T >>  << A >>
tt@cryogen.com wrote:
>
> What appears to be needed to trigger the long-awaited
> programmable logic revolution, is the proverbial 'killer
> application' - where people are prepared to buy
> programmable logic components in order to run particular
> software.

Pure fantasy.  There won't ever be such an application.

> These days I think any vendors who offered a hardware
> solution (and these appear to be uncommon these days) would offer
> specialised DSP hardware, rather than an FPGA-based solution.

Exactly.  And DSPs sequentially execute software instruction
streams like any other processor.

> Would a partly FPGA-based approach be the best way to
> achieve maximum speed?

Which part?


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16530
Subject: Re: High Speed Reconfigurability
From: Ray Andraka <randraka@ids.net>
Date: Wed, 26 May 1999 17:28:37 -0400
Links: << >>  << T >>  << A >>
I've been using FPGAs for several years now in applications where a rack
of DSP processors is outperformed by a single board with a couple
FPGAs.  Some examples:
    A doppler weather radar demodulator and pulse pair processor - was a
rack of DSP cards (approx 20), couldn't keep up with data in real-time.
Replaced by one annapolis board with 4 4013's.  Operates in real time
    A radar simulation system.  Impossible to do with just DSP
processors due to 40 MHz data rate and complicated processing
requirement.  System implemented in 8 4025's, runs in real time
    QAM demodulator.  DSP TMS320C50 barely capable of baseband half
duplex.  FPGA (4020) simultaneously handles both modulation and
demodulation, has better filtering and does downconversion from IF.

In each of these cases, an ASIC would have also worked, but the volumes
did not support the cost of an ASIC solution.  Now, I'm not sure a
'killer' app is going to fall on us, but the fact is that FPGAs are
finding their way into products as DSP processors more and more.  This
is mostly because there are more and more applications that a DSP
microprocessor can't hack the processing throughput requirements.  A
killer app would necessarily be one with large volumes, which would make
an ASIC solution attractive unless there was a need for the
reconfigurability that could not be satisfied more economically by an
ASIC capable of handling multiple operational modes.  Personally, I find
the 'killer app' to be the scores of onesy-twosy DSP applications that
are pushing the envelope of DSP microprocessor capability.  There's lots
of those out there (look how many players there are in the DSP micro
board market), and each one has a different algorithm, a different
application or a different set of requirements.

brian_n_miller@yahoo.com wrote:

> tt@cryogen.com wrote:
> >
> > What appears to be needed to trigger the long-awaited
> > programmable logic revolution, is the proverbial 'killer
> > application' - where people are prepared to buy
> > programmable logic components in order to run particular
> > software.
>
> Pure fantasy.  There won't ever be such an application.
>
> > These days I think any vendors who offered a hardware
> > solution (and these appear to be uncommon these days) would offer
> > specialised DSP hardware, rather than an FPGA-based solution.
>
> Exactly.  And DSPs sequentially execute software instruction
> streams like any other processor.
>
> > Would a partly FPGA-based approach be the best way to
> > achieve maximum speed?
>
> Which part?
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---



--
-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: 16531
Subject: C to EDIF translator??Anyone?
From: prastogi@my-dejanews.com
Date: Thu, 27 May 1999 00:38:28 GMT
Links: << >>  << T >>  << A >>
Hi,

I am working on the translation of C to EDIF file
format for synthesis to FPGAs/ASICS. In this
respect I need to write a Translator from a subset
of C (say only mathematical operations) to EDIF.

Please do let me know EVEN if you have a hint or
know something vaguely. Any references will be of
great use. ALso If there are any commercial tools
in the industry/research community , I am
interested . Price is not a constraint.

Thank you all,

Pranav R.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16532
Subject: Re: Xilinx M1.5 Crash
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 May 1999 20:57:36 -0400
Links: << >>  << T >>  << A >>
Zoltan Kocsi wrote:
> Rickman <spamgoeshere4@yahoo.com> writes:
> 
> > Perhaps there is a third choice which simply has to do with marketing
> > and cost. If I had the choice of selling one system to say 40% of the
> > market or increasing my market share to, say 45%, by selling two systems
> > and doubling my development costs, I think I would choose the one
> > platform approach.
> 
> Well, this explains why would a company go Windows only and ask good money
> for the Windows SW. However, when you have a Windows version *and* a
> unix version (that is, dev. cost is doubled) then what's the business
> behind giving away the Windows version (which costed you a lot) and
> not doing the same with unix ? If you want increased chip sales, then
> you would give away the unix one too - every chip sold creates money.
> In fact, you would port the unix version to Linux (this would cost you
> virtually nothing), put on your web site with big red letters screaming
> NO SUPPORT - AS IS or YOU CAN PURCHASE SUPPORT FOR LOTS OF $$$ (which is
> already the case with the downloadable Windows version anyway) thus
> selling even more chips (Linux die-hards will all buy *your* chips for
> you are the only one supporting them). It ain't happening, somehow.

A chip vendor has to put TONS of money into every variation of the
software they produce. When we talk about Unix versions, that is not one
version of the software that runs on every machine. A new version is
required for each variant of Unix and a new binary is required for each
type of CPU. And most EDA under UNIX is done for the big buck, high
speed platforms. That is why the Unix versions cost more. And all that
is on top of the fact that the vendor most likely sells more Windows
copies than the Unix copies. 

 
> > My guess is that in the last 3 years or so, the vendors are seeing that
> > customers who at one time were Unit die-hards, are now willing to use
> > Windows.
> 
> Because they have to. Vendors (IMHO) don't *see* the situation, they
> *create* it. Last year on DAC on the Linux vs. NT shootout (which turned
> to a unix vs. NT one) the audioence seemed to very much favour unix over
> NT - of course they may have been a very biased audience.

I don't agree with that. If the vendors told you they were only going to
sell systems that you had to use standing on your head, you would say...
NO THANKS! They would sell a lot less and they would very quickly change
the software back. I can't say anything about the audience, but I know
you can still buy most any EDA tool you wish to run under Unix. So
competition will determine which system is "better". 

 
> > I would also expect that a lot of potential Windows customers
> > would not be willing to go to Unix.
> 
> This is probably true.
> 
> > Whenever the vendors are asked about Linux versions of their software,
> > they say they will do it when the customer demand is there. The bottom
> > line is that they will sell what customers are most likely to buy.
> 
> Well, if they are asked about it, then there must be some demand ?
> Customers buy what they are sold.
> You want to buy a gray hat. You ring the vendor, they say they do not
> make gray ones, you should buy a blue one. You *need* that hat, so you
> buy the blue one. The hat vendor can see that hat sales is not hurt by
> selling blue ones only (all in all, everybodey buys a hat) so they will
> tell everyone who rings them about gray (or green or red) hats, that the
> customer demand is blue, buy that one. They will because they have no
> choice. If they are very desperate, they can go to the other hatshop,
> which would sell them the same blue hat with an albeit not grey, but
> yellow or brown overcoat, for 3 times as much.

A few engineers asking about Linux is not a bunch of companies saying
they want to buy copieS of Linux software. No you can't buy what they
don't sell, but if enough people go to several stores asking about gray
hats, the guy who has the dullest shade of blue will get most of the
sales. I don't need to explain how this will get everyone into making
the gray hat if that is what people really want to BUY. 
 

> > I would also point out that Unix development is more expensive. The
> > machines cost more, the software costs more, and perhaps the developers
> > cost more (not sure about this last one).
> 
> Well, not necessarily true. A PC running unix costs the same as a PC
> running NT, an Alpha costs the same running either. Machines which
> cost more may not run NT (for Microsoft does not supply NT for them) but
> it is not the problem with the machine, it's a problem with NT.

Refer to the first paragraph. Not many EDA vendors are pumping out Unix
to run on a Wintel type platform. The main excuse for going Unix is the
power of the hardware. That is what drives the cost. 

 
> The development software cost is a non-issue. On one hand, you have
> a plethora of free tools for the unix world, (which, incidently, have been
> ported to Windows) but even if you didn't, a multi-billion dollar company
> would not choke on the one-off cost of buying the devtools. Whether a
> compiler is more expensive for unix than it is for Windows, I don't know,
> maybe. Still, I don't think that price differences would be so high that
> a big EDA company couldn't fork it out.

You seem to think that once you buy the software, you are done paying.
Even the free software has support costs. Isn't that how companies stay
in business giving away software? I know from experience that most every
tool costs MUCH more on a non-Wintel platform. I was once quoted $1500
for ABEL (I'm showing my age) on a Unix machine vs. $500 on a PC. 
 

> Since Linux came up: well, I don't want to go into a Linux vs. NT argument,
> USENET is full of it anyway. However, it is a fact that Linux supports all
> architectures NT does plus a lot more, the system comes for free, all the
> dev. tools come for free and even some commercial unix vendors support
> (or anounced that they will support) running Linux binaries on their
> native version of unix. These all mean that doing Linux development is
> actually cheaper than Windows.

Maybe I am showing my ignorance, but how do you run a non-native binary?
If this is done via emulation, like running PC software on a MAC (or
vice versa) I don't think that would be very workable for most tools.
But I am not sure what you mean here. But again, the cost of the
software is not the cost of business. Support and hardware is what
costs, and costs, and costs. 

If you are talking about running your tools on a PC under Linux, then
you most likely could get by cheaply. But that is not how they are doing
it for now I as far as I know. They run the large expensive platforms
with high dollar software. 

Perhaps you might want to give this a try yourself. I am a beliver in
the Ayn Rann philosophy that if you can do something better than the
other guy, you should be rewarded. That is why I am consulting now
instead of working for a paycheck. 


> In addition, I fail to understand why a C programmer who can program say
> a synthesis engine under windows would be much cheaper than one which
> can crank out the same C code under unix. GUI-wise I doubt that X would
> be inherently harder to work with than the Windows GUI or that it would
> be less supported by GUI-generators and stuff. I might be wrong, of course.

If you check the want ads, you will find that a company is hiring either
Windows programmers (under many other fancy names), or Unix programmers.
They are not interchangable. I am neither type of programmer, to much of
an extent, so I won't try to explain the difference. I just know that
maybe you could be both perhaps, but the two are not interchangable. But
like I said, I don't know if the programmers cost more. I have never
done a salary survey.


-- 

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: 16533
Subject: Re: FPGA express : Schematic viewing options w/o Vista?
From: Phil Hays <spampostmaster@sprynet.com>
Date: Wed, 26 May 1999 18:20:54 -0700
Links: << >>  << T >>  << A >>
micheal_thompson@my-dejanews.com wrote:

> Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA
> environment, or can seasoned designers dispense with it?

The answer to this question depends on what result you need.  If you
want correct logic and are not pushing the tool set for smaller and/or
faster, it is not at all essential.  If you need to push the tool set
for smaller and/or faster you may need to understand a lot about what
the synthesis tool is doing, a lot about how the map/placement/routing
works, a lot about the details of the FPGA in question, and a fair
amount of time needs to be spent to make it all work well.  Time being
money, it is also important not to do more of this detail work than what
is really needed.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 16534
Subject: Re: High Speed Reconfigurability
From: Jonathan Feifarek <feifarek@removethis.ieee.org>
Date: Wed, 26 May 1999 19:54:35 -0600
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> A killer app would necessarily be one with large volumes, which would make
> an ASIC solution attractive unless there was a need for the
> reconfigurability that could not be satisfied more economically by an
> ASIC capable of handling multiple operational modes.

One such need would be packet switching in the rapidly changing
telecommunications industry.  Upcoming protocols will allow for
dynamically routed switches whose subsequent actions will be changed by
the content of the packets themselves.  Such a scheme seems like a
natural fit for a reconfigurable computer. If the design were placed in
an ASIC, a new ASIC would need to be produced as soon as additions were
made to the protocol to eke out the last bit of throughput.  A lot of
new modems can be reconfigured for this very reason.
This is not an example of a 'killer app' but rather another benefit of
using a reconfigurable computer.
Jonathan
-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16535
Subject: Re: C to EDIF translator??Anyone?
From: "Gene N" <nenortas@home.com>
Date: Thu, 27 May 1999 01:58:47 GMT
Links: << >>  << T >>  << A >>
Since price is no object ....

CLevel Design has two tools C2Verilog and C2VHDL (it's Verilog or VHDL out
not EDIF).
These tools are bundled and sell for $125K US.

Get yourself a synthesis tool to get your EDIF out.

Regards.

Gene


Article: 16536
Subject: Re: floating points to fixed points on a FPGA
From: "Martin Filteau" <filteaum@francomedia.qc.ca>
Date: Wed, 26 May 1999 22:05:55 -0400
Links: << >>  << T >>  << A >>

Peter Sels wrote in message <374AD7E5.D7A8493E@easics.be>...
>Jean-Francois Richard wrote:
>>


I missed the original posting.  Are you Jean-Francois Richard from Montréal,
Canada?

Martin Filteau



Article: 16537
Subject: Re: Instantiate Clocks
From: zule <zule@home.net>
Date: Thu, 27 May 1999 02:50:14 GMT
Links: << >>  << T >>  << A >>
Hi Tximo,

If you are using the foundation tools open the file using the HDL
editor.  Look under TOOLS > Language Assistant > Synthesis Templates >
Global Clock Buffer in the menu bar.  There you will find the following
cut and paste Bufg instantiation.

-- Shown Below

--Instantiating BUFGP on Input Port
--   INPUT_PORT:  std_logic;
--   CLK_SIG:  std_logic;

--**Insert the following between the
--  'architecture' and 'begin' keywords**
   
   component BUFGP
         port (I: in std_logic; O: out std_logic);
   end component;	
   
--**Insert the following after the 'begin' keyword**   

   signal CLK_SIG:  std_logic;
   U1:  BUFGP port map (I => INPUT_PORT,
   			O => CLK_SIG);

I hope this helps.

Best Regards
Terry

Tximo wrote:
> 
> Hi all,
> 
> I am trying to synthesize a VHDL design in the Xilinx Demonstration
> Board using Xilinx Foundations F1.5.  This board has a XC3020A-PC68 and
> a XC4010E-PC84, although I am only using the XC4010E-PC84.
> 
> In my design, I have a clock line, and my problem is that I want to
> assign this clock line to a Global Buffer (GCLK), but I don't know how.
> 
> Anyone can help me?
> 
> Thanks in advance.
Article: 16538
Subject: Re: FPGA express : Schematic viewing options w/o Vista?
From: zule <zule@home.net>
Date: Thu, 27 May 1999 02:54:53 GMT
Links: << >>  << T >>  << A >>
Hi Michael,

FPGA Express 3.1 has a schematic viewer in it.  Can you upgrade to this?

Best Regards
Terry

micheal_thompson@my-dejanews.com wrote:
> 
> Hi,
> I'm using Viewlogic's FPGA express (V3.00) for VHDL synthesis and I'd
> really like to see the synthesised result in schematic form, at least
> at the pre-fitted stage, so that I can develop a VHDL coding style
> appropriate for synthesis - I'm neither a VHDL or FPGA guru.
> 
> I don't have Viewlogics VISTA tool, which might be just the ticket, so
> instead I'm wondering can I do it with Viewlogic's EDIF converter (EDIF
> -> WIR)  and its VIEWGEN utility ( WIR -> SCH)?
> 
> Alternatively, do any of the FPGA vendor's fitting tools (Maxplus 11
> etc) provide a schematic view of the input EDIF file?
> 
> Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA
> environment, or can seasoned designers dispense with it?
> 
> regds
> Mike
> 
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
Article: 16539
Subject: Re: Dual Port mem
From: scottwinick@compuserve.com (Scott Winick)
Date: Wed, 26 May 1999 18:57:58 -0800
Links: << >>  << T >>  << A >>
The code in your example also synthesizes correctly to a dual port RAMwith Exemplar Logic's Spectrum synthesis tool. I might suggest that amore compact way to write the line :>      if CLK_IN'event and CLK_IN = '1' thenmight be to write it as :>      if RISING_EDGE (CLK_IN) thenThis takes into account the the things you'd like to exclude fromtriggering this "if" clause, like transitions from X->1, for example.



   -**** Posted from RemarQ, http://www.remarq.com/?a ****-
 Search and Read Usenet Discussions in your Browser - FREE -
Article: 16540
Subject: Re: Xilinx M1.5 Crash
From: Zoltan Kocsi <root@127.0.0.1>
Date: 27 May 1999 12:59:35 +1000
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> writes:

I got your arguments. I have to admit, they sound plausible, which, 
of course, does not change the fact that I'm pissed off for the unix
tools being more expensive and Linux tools not being available.
I am still not convinced about the business advantage of giving
away the Windows tool for free - do they want to make money or not ?

> Maybe I am showing my ignorance, but how do you run a non-native binary?
> If this is done via emulation, like running PC software on a MAC (or
> vice versa) I don't think that would be very workable for most tools.

No, it's different. You have say Linux running on some Intel box.
Then you get a SCO (Intel) binary. The actual userland code is the 
same, the system calls are different. You install iBCS and then 
Linux will serve SCO calls -> you can run SCO binaries under Linux 
without significant speed penalty. What I referred to was that AFAIK 
Sun stated that they'll support Linux binaries under Solaris. I don't
know if it's only for Intel or they'll run Linux-SPARC binaries on
Solaris-SPARC machines too. I've heard the same about SGI.

> If you are talking about running your tools on a PC under Linux, then
> you most likely could get by cheaply. But that is not how they are doing
> it for now I as far as I know. They run the large expensive platforms
> with high dollar software. 

Yes, the big boys do that. Little boys have to run Windows on Intel. 
My eternal problem is that I'm a little boy but I don't want to run 
Windows. I'd be happy with Linux on a higher-end Pentium box - all in 
all, I don't design multi-million transistor ASICs, I'm here in the sand
playing with FPGAs. I bought an old Sun machine so that at least I
can run tools under unix but you see a 7-year old MicroSPARC is just 
not in the same league as a Pentium-II or III. 

By the way, if you take a look at the Altera tool under Solaris SPARC
or the Actel P&R under the same platform, you will see that these tools
are actually Windows tools (they didn't even bother to change the 
'for Windows' in the About box), coming full with Windows help and alike.
So then what's exactly which makes these so expensive ? The fact that
unix users are suckers, they got used to pay big bucks ?

> Perhaps you might want to give this a try yourself. I am a beliver in
> the Ayn Rann philosophy that if you can do something better than the
> other guy, you should be rewarded. That is why I am consulting now
> instead of working for a paycheck. 

I do have my own company, for the same reason. However, I know that I
lack the knowledge necessary to crank out a high-quality FPGA synthesis
tool therefore I don't try to be a EDA vendor. Not to mention the
P&R, which I couldn't do even if I was the One and Only for obvious 
reasons. I am just a poor user who would like to use unix rather than
Windows and not pay for extra hardware nor to pay too much extra for 
the software. I might very well be the only pervert who wants to
design chips and run Linux in the same time, though. 

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 16541
Subject: Re: JTAG: Altera & Xilinx
From: zule <zule@home.net>
Date: Thu, 27 May 1999 03:06:10 GMT
Links: << >>  << T >>  << A >>
Xilinx made a press release which said they will support STAPL

http://www.xilinx.com/prs_rls/staplspt.htm

Best Regards
Terry
Article: 16542
Subject: Re: High Speed Reconfigurability
From: Roland Paterson-Jones <rpjones@hursley.ibm.com>
Date: Thu, 27 May 1999 08:42:09 +0100
Links: << >>  << T >>  << A >>
brian_n_miller@yahoo.com wrote:

> rolandpj@bigfoot.com wrote:
> >
> > (The aim is) performance, of course. JVM is just an example.
>
> *yawn*

Indeed.

> But which functions or aspects of JVM operation would
> clearly benefit from reconfigurability.

As stated above, the JVM is merely an example. (IMHO from here onwards)
The applicability of reconfigurable hardware to standard programming
languages lies in its ability to maximally implement the inherent
parallelism in every piece of code. Also, I suspect that you can fit
more action into a single clock-cycle when you know exactly what you're
going to do.

The real question is how much inherent parallelism there is to exploit.
As Tim Tyler has pointed out, JVM bytecode is not an ideal target, since
fine-grained parallelism is not part of the architecture. However,
empirical research seems to suggest that there is a large amount of
inherent parallelism in serial programs (SPEC C benchmarks in that case
- see a previous posting). This study ignores the speculative
parallelisation (e.g. execute both branches of a conditional at the same
time as evaluating a condition, then ignore one) that is possible with
massively parallel hardware.

Moreover, I believe it only makes sense to use this approach on
computational performance bottlenecks (aka 'hotspots'). These tend to be
inner loops, where parallelisation often inheres.

> Time spent pondering reconfigurable
> bytecode execution is likely wasted while the mainstream
> continues to advance the speed and capacity of static chips.

In the short-term, yes, and as you've guessed already, I just don't
care. I'd prefer to waste time on an interesting project, even if it
turns out to be an evolutionary dead-end, than to pore over the Pentium
III circuit diagram looking for path optimisations.

The proof is in the pudding. Let's cook.

Roland

Article: 16543
Subject: Re: Xilinx M1.5 Crash
From: "Daniel K. Elftmann" <elftmann@ix.netcom.com>
Date: Thu, 27 May 1999 04:39:13 -0400
Links: << >>  << T >>  << A >>
----- Original Message -----
From: Zoltan Kocsi <root@127.0.0.1>
Newsgroups: comp.arch.fpga
Sent: Wednesday, May 26, 1999 10:59 PM
Subject: Re: Xilinx M1.5 Crash


>
> By the way, if you take a look at the Altera tool under Solaris SPARC
> or the Actel P&R under the same platform, you will see that these tools
> are actually Windows tools (they didn't even bother to change the
> 'for Windows' in the About box), coming full with Windows help and alike.
> So then what's exactly which makes these so expensive ? The fact that
> unix users are suckers, they got used to pay big bucks ?

Ah yes the text in the 'about box' is a very definitive method of
determining the native platform a tool was developed on.  Unfortunately, at
least for the Actel P&R I know for fact (I get to visit with the developers
quite
regularly) that the tools are all developed on Solaris first then ported to
the PC environment.  Sorry, but just could'nt let that go without a
correction.

Daniel K. Elftmann
Actel Field Applications Engineer




Article: 16544
Subject: CFI (CAD Framework Initiative) webpage - DR documentation
From: username@dso.org.sg
Date: Thu, 27 May 1999 16:39:44 +0800
Links: << >>  << T >>  << A >>
Hello,

I have been looking for the CFI webpage but unfortunately most web
sites that point to is  www.cfi.org  which is "College Foundation,Inc"
instead.  Does anyone knows the correct web page or where I can get a
full documentation of the CFI - DR (Design representation). 
Thanks in advance.

email: csoolan@dso.org.sg
Article: 16545
Subject: Re: Virtex based PCI cards
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 27 May 1999 12:25:56 +0200
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> writes:

> Austin Franklin wrote:
> > They may claim it does....but....  They don't provide a VCCIO pin, which is
> > to be used for the clamp diodes...and it can't technically meet spec if
> > they don't.  PLX has the same problem with the 9054...it's a 3.3V part,
> > with no VCCIO pin...
> > 
> > Any PCI interface that is NOT 5V powered, and is used in a 5V environment,
> > has to have VCCIO...and same is true for any other voltage variants...

I always thought the clamp to 5V is optional?
 
> I get email from the PCI SIG. They were discussing just this aspect of
> the PLX9054 chip. I believe that the consensus was that you are not
> required to clamp in a 5 volt environment, while you are in a 3.3 volt
> environment. 
> 
> The issue was whether you had to clamp in a 3.3 volt environment. One
> poster quoted the spec saying you had to clamp. A PLX representative
> posted a quote that said you didn't. A third poster claimed that the PLX
> quote refered only to 5 volt operation. In any case, PLX seems to think
> their chip is fully compliant with the spec. 
> 
> I haven't verified any of this. So perhaps you can tell me who is right.

Good Question.

I've slways thought you neede diodes to 3.3V/VCCIO in a 3.3V
signalling environment. Looking through the spec again, I see now that
it some parts open to interpretation.

Anyway, I haven't seen a 3.3V universal part yet that has more than
ONE VCCIO pin.Its supposed to be used for clamping only. The output
buffers are still driven by the 3.3V only, even in the 5V
environment.

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 16546
Subject: High speed with VHDL
From: Heinrich Fonfara <fonfarah@ibmt.fhg.de>
Date: Thu, 27 May 1999 14:32:49 +0200
Links: << >>  << T >>  << A >>
Hi,

Because of the high speed requirements to the designs I have implemented
in FPGAs
I mostly used schematic entry for sequential parts.  I recognized  the
benefits of  VHDL
only for coders or state machines (maybe also some other parts) that had
after
compilation the same performance as schematic solutions.

My question is: How can I constrain the compiler to make the results
most similar to that I found with schematic ?


Thanks

Heinrich Fonfara

 fonfarah@ibmt.fhg.de
 http://www.ibmt.fhg.de/

Article: 16547
Subject: Re: DSP Board for PC/104 Bus
From: rrohatgi@kendra.com
Date: Thu, 27 May 1999 13:44:59 GMT
Links: << >>  << T >>  << A >>
In article <374C4E98.F6525DBD@yahoo.com>,
  Rickman <spamgoeshere4@yahoo.com> wrote:
<...>

> I don't understand what you mean about power supply limitations. Do
you
> mean the board requires too much current from the supply or too many
> voltages?

Too much current.

<...>

-rajeev-


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16548
Subject: Re: High Speed Reconfigurability
From: Tim Tyler <tt@cryogen.com>
Date: Thu, 27 May 1999 16:29:11 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga brian_n_miller@yahoo.com wrote:
: tt@cryogen.com wrote:

:> What appears to be needed to trigger the long-awaited
:> programmable logic revolution, is the proverbial 'killer
:> application' - where people are prepared to buy
:> programmable logic components in order to run particular
:> software.

: Pure fantasy.  There won't ever be such an application.

Well, there /already/ are applications for which people are prepared to
purcahse FPGA boards: prototyping circuit design and evolutionary
computation spring to mind.

Running the s/w associated with these applicatoins /without/ hardware
acceleration is *possible*, but somewhat tiresome.  However, these are
niche applications - something with more consumer volume would be good...

:> These days I think any vendors who offered a hardware
:> solution (and these appear to be uncommon these days) would offer
:> specialised DSP hardware, rather than an FPGA-based solution.

: Exactly.  And DSPs sequentially execute software instruction
: streams like any other processor.

True, although I associate more parallelism with DSPs than conventional
general-purpose processors.  Graphics-oriented hardware has more
parallelism still - while even a conventional processor generally has a
pipeline and is decoding one instruction, while predicting a branch on
another, while executing a third.

:> Would a partly FPGA-based approach be the best way to
:> achieve maximum speed?

: Which part?

/* Parallelisable parts - like this, for example */
Widget[] array;

for (int i=0; i++ < MAX; ) {
  array[i] = new Widget();
}
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

May all your PUSHes be POPped.
Article: 16549
Subject: Re: High Speed Reconfigurability
From: brian_n_miller@yahoo.com
Date: Thu, 27 May 1999 17:45:41 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <randraka@ids.net> wrote:
>
> I've been using FPGAs for several years.

But probably not ones which reconfigure during operation,
which is what this discussion is about.

> A rack of DSP processors is outperformed by a single board
> with a couple FPGAs.  Some examples:
> A doppler weather radar demodulator, ...a radar simulation
> system, ...QAM demodulator.

Those are freakish niche applications.  I thought we were
talking about the applicability of reconfigurable hardware
to mainstrean software systems.

> I find the 'killer app' to be the scores of onesy-twosy DSP
> applications that are pushing the envelope of DSP microprocessor
> capability.  There's lots of those out there.

But you're not arguing for on-the-fly reconfigurability, are
you?


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


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