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 21175

Article: 21175
Subject: Re: antifuse fpga's replacing xilinx
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 09 Mar 2000 09:19:44 +0100
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> writes:

> Magnus Homann wrote:
> 
> > I tried to floorplan (a first), so I put the clock pad on the top and
> > the 10 data pads surrounding it. I still got some negative hold time....
> 

> Negative hold time is good. Positive hold time is what you should be
> afraid of.

Of course. Exchange negative/postive, and my original question still
stands. I was tired, and not at work when I wrote it. Thanks.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 21176
Subject: Re: antifuse fpga's replacing xilinx
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 09 Mar 2000 09:46:15 GMT
Links: << >>  << T >>  << A >>
On 08 Mar 2000 22:13:46 +0100, Magnus Homann
<d0asta@mis.dtek.chalmers.se> wrote:

>Peter Alfke <peter@xilinx.com> writes:

>> That "Xilinx party line" ( I formulated it ) means just that, and it assumes
>> that you use a global clock net. In local routing you might create long clock
>> distribution delays that would generate hold time problems.
>
>Interesting you mentioned that. There's a couple (two dozen) lines
>aimed for local clock routing in the Vitrex family. I tried to use
>them, but I couldn't figure out if there are any applicable timing
>constraint to keep the setup and hold times within bounds.

I think 'secondary clock net' is an unfortunate choice of words in the
datasheet, for this reason. There aren't any constraints to guarantee
use of these nets for clock lines, and a timing sim isn't much use
either (you have to simulate with minimum clk->q and routing, and
maximum clock net delay, to find a hold time problem). This can't be
done with the tools that we have - it has to be done as part of the
clock net extraction process during the original ASIC design (which is
how Xilinx guarantees zero hold time when using global clock nets).
Given this, I think guidelines for using the secondary nets should be
(perhaps Peter could comment?):

1)  You can use a secondary net for a clock when you know that the
signal to be latched has a 'long' hold time beyond the clock edge,
where 'long' is, in principle, 2ns (for example, latching data from an
external bus)

2) You may be able to use a secondary clock net for a clock if you
route manually, keep everything local, make sure that any data lines
don't themselves go on secondary clock nets, and if you're happy to
'guarantee' worst-case operation yourself

3) Otherwise, you should keep the secondary clock nets for clock
enables and synchronous resets.

Fortunately, this isn't a problem, since the vast majority of designs
aren't going to require more than 4 unrelated clocks. It's also
impractical to fill up a device with (very) expensive clock nets, and
a balance has to be struck somewhere - 4 seems pretty good to me.

Evan


Article: 21177
Subject: I need parallel processor SIMULATOR
From: Juan Antonio =?iso-8859-1?Q?G=F3mez?= Pulido <jangomez@unex.es>
Date: Thu, 09 Mar 2000 10:50:40 +0100
Links: << >>  << T >>  << A >>
Hi,
Please, can anybody tell me if exits a PC simulator of parallel
processors?
Thanks a lot. Best regards.
--
-----------------------------------------------------
|             Juan Antonio Gomez Pulido             |
|                                                   |
| Dep. de Informatica   | Dep. of Computer Sciences |
| Escuela Politecnica   | Escuela Politecnica       |
| Univ. de Extremadura  | University of Extremadura |
| 10071 Caceres. España | 10071 Caceres. Spain.     |
| Tel: (927)257264      | Vox: +34-927-257264       |
| Fax: (927)257202      | Fax: +34-927-257202       |
|            Email: jangomez@unex.es                |
|            http://atc.unex.es/jangomez            |
-----------------------------------------------------


Article: 21178
Subject: Xilinx Foundation 2.1:Functional simulation
From: Steven Sanders <sanders@imec.be>
Date: Thu, 09 Mar 2000 10:53:41 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7FB8148D9B465E51001FD2FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

I have 2 problems concerning functional simulation:

1) How do I simulate  a simple VHDL file, viewing ALL its ports, signals
and variables?
(with the functional simulator, no testbench)

2) When I create a macro from a VHDL file, many ports are missing on the
macro (in the schematic), although they are
definitely used in the HDL code! Is this an optimization and can it be
turnerd off?

Thanx in advance!!!!

Steven.


--------------7FB8148D9B465E51001FD2FB
Content-Type: text/x-vcard; charset=us-ascii;
 name="sanders.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Steven Sanders
Content-Disposition: attachment;
 filename="sanders.vcf"

begin:vcard 
n:Sanders;Steven 
x-mozilla-html:FALSE
org:imec ;DTS
adr:;;Flanders Language Valley 44;Ieper;;8900;
version:2.1
email;internet:sanders@imec.be
fn:Steven Sanders
end:vcard

--------------7FB8148D9B465E51001FD2FB--

Article: 21179
Subject: Re: Synplicity for sale
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 09 Mar 2000 13:22:09 +0000
Links: << >>  << T >>  << A >>


Stuart Clubb wrote:

> Hmmm.
>
> I have heard no rumours, malicious or otherwise, but things in general
> must be very bad for Synplicity not to IPO. Almost everyone wants to
> invest in sexy high-tech stock these days so it makes you wonder how
> bad things have gotten if the assertion is true.
>
> I suspect it is not true.
>
> As for Mentor buying them, why bother? A private sale in todays
> climate would be indicative (IMHO) of an exercise in loss-limitation
> on the part of the private investors. It may be that they might figure
> on playing the big three off against each other, but I suspect neither
> Mentor nor Synopsys would be particularly interested (except for some
> small tid-bits of technology). That leaves Cadence in "Borg mode"
> again.
>
> Cheers
> Stuart

I was thinking more of Mentor buying Synplicity as a way of reducing the
competition!

Article: 21180
Subject: Re: ModelSim 2.1i ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 09 Mar 2000 13:33:01 +0000
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Bzzzzt.  Nope, it's March, the Service Pack of the month this month is.... You
> guessed it, Number 5.  And they still don't have my show-stopper bugs from SP2
> fixed.
>
> --
> -

Have they even put them on the answers database yet ?

Article: 21181
Subject: Re: SpartanXL route and place
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 09 Mar 2000 13:50:52 +0000
Links: << >>  << T >>  << A >>


Utku Ozcan wrote:

> > [snip[
> > o Have you tried setting the Synplify ``max fanout'' parameter to something
> > lower than the Xilinx default of 100 ? My normal setting is 32 and in some
> > circumstances I take it down as far as 8.
>
> why do you choose this value always a power of 2?
>

Probably & sadly I've been in this world too long to remember any other numbers. My
excuse here is that all the data paths are 32 bits wide [or 36 if I turn parity on]
so my Tcl script generator sets this value to 32 or 36 by default.

> > o Have you checked the parameters that Foundation passes to MAP/PAR ? Some of
> > these are really for non-HDL designs & should be switched off.
>
> would you please give an example?
>

Example: -o, optimisation, flag. I *think* this is off by default but here may be
others. Its definitely worth reading the manual MAP/PAR sections.

>
> > o You have tripped over some subtle and brand new bug in the Xilinx tools. If
> > so join the club.
> >
> > In order to really find out what's going on I think you'll have to make your
> > move out of the GUI playground sooner than you expected.
>
> I find Template Manager difficult to handle, so I think I would switch to
> command line. With a Perl script it would be easy to generate iterations
> and more abstract statistic reporting among a parameter region of the tools,
> by individually handling log files.
>
> Utku

Go for it as soon as possible, you'll not regret it. One nice thing about the
Xilinx tools is the command line documenation is excellent. I could at least get
you started with the PERL script I use to generate a Tcl control file for Synplify.

Article: 21182
Subject: Re: antifuse fpga's replacing xilinx
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 09 Mar 2000 16:24:24 +0100
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM writes:

> On 08 Mar 2000 22:13:46 +0100, Magnus Homann
> <d0asta@mis.dtek.chalmers.se> wrote:
> 
> >Peter Alfke <peter@xilinx.com> writes:
> 
> >> That "Xilinx party line" ( I formulated it ) means just that, and it assumes
> >> that you use a global clock net. In local routing you might create long clock
> >> distribution delays that would generate hold time problems.
> >
> >Interesting you mentioned that. There's a couple (two dozen) lines
> >aimed for local clock routing in the Vitrex family. I tried to use
> >them, but I couldn't figure out if there are any applicable timing
> >constraint to keep the setup and hold times within bounds.
> 
> I think 'secondary clock net' is an unfortunate choice of words in the
> datasheet, for this reason. There aren't any constraints to guarantee
> use of these nets for clock lines, and a timing sim isn't much use
> either (you have to simulate with minimum clk->q and routing, and
> maximum clock net delay, to find a hold time problem). This can't be
> done with the tools that we have - it has to be done as part of the
> clock net extraction process during the original ASIC design (which is
> how Xilinx guarantees zero hold time when using global clock nets).
> Given this, I think guidelines for using the secondary nets should be
> (perhaps Peter could comment?):
>
> 1)  You can use a secondary net for a clock when you know that the
> signal to be latched has a 'long' hold time beyond the clock edge,
> where 'long' is, in principle, 2ns (for example, latching data from an
> external bus)

But the tools _do_ report setup and hold on IOBs that are clocked by
these secondary (better word anyone?) clock lines. The problem is not
reporting, it's constraining hold times.

Alternatively, the reported hold times can be totally bogus, and you
would be right in that case. But as they are said to be able to use as
clock lines...
 
> 2) You may be able to use a secondary clock net for a clock if you
> route manually, keep everything local, make sure that any data lines
> don't themselves go on secondary clock nets, and if you're happy to
> 'guarantee' worst-case operation yourself

What I had to do was to floorplan so that the clock and the clockee
were on the same top row, fairly close to eachother. The routing was
automatic.

> 3) Otherwise, you should keep the secondary clock nets for clock
> enables and synchronous resets.

> Fortunately, this isn't a problem, since the vast majority of designs
> aren't going to require more than 4 unrelated clocks. It's also
> impractical to fill up a device with (very) expensive clock nets, and
> a balance has to be struck somewhere - 4 seems pretty good to me.

So? Doesn't help in my case. I'm not complaining that they only have 4
global clocks, I'm only noting that the secondary clocks Xilinx _has_
provided does not seem to be able to handle a constarint on the hold
time.

As my design is now, I'm set at 0.7 ns (<2ns required) hold time,
after running "trce -skew -dfs". If the numbers reported there are
untrue, please tell me so that I can through my Virtex part out the
window.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 21183
Subject: Re: Microprocessor architecture (6800, 4004? PA-RISC, PPC, MIPS, x86,
From: Jerry English <jenglish_no_spam_@planetc.com>
Date: Thu, 09 Mar 2000 10:25:12 -0500
Links: << >>  << T >>  << A >>
www.opencores.org

Looks like they will have a 32 bit processor posted in the next few days.
Thats the good thing, the bad thing is  it will be written in VHDL. (:>)

Anybody up to the task of moving it over to verilog?

regards
Jerry

Volker Urban wrote:

> In comp.arch.fpga Norm Ebsary <norm@dtinetworks.com> wrote:
> > Hey, why are you not looking at www.open-cores.org?
>
> DNS Domain 'www.open-cores.org' is invalid: Host not found (authoritative).
>
> +volker-

Article: 21184
Subject: Re: SpartanXL route and place
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 09 Mar 2000 15:36:34 +0000
Links: << >>  << T >>  << A >>
"Keith R. Williams" wrote:
<snip> 
> I am rather surprised that P&R is so coupled to processor
> performance. 

Why?  P&R is about the only thing that people do on PCs
that's nearly 100% compute bound :-)

Jonathan Bromley
Article: 21185
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Thu, 09 Mar 2000 15:52:32 GMT
Links: << >>  << T >>  << A >>
Its not in the data book because it's not supported by the software.  XC4000XL
and XLA parts have the tristate register, but it is unknown to the software and
therefore essentially unusable.  I don't know if it is in the Spartan part or
not.  The earlier 4K parts do not have it.

Allan Herriman wrote:

> On Wed, 8 Mar 2000 09:40:24 -0700, "Andy Peters"
> <apeters.Nospam@nospam.noao.edu.nospam> wrote:
>
> >Ray Andraka wrote in message <38C64FE0.13682CCB@ids.net>...
> >
> >>AFAIK, the xilinx software still doesn't support the tristate register for
> >4K
> >>parts.
> >
> >And it won't be.  One of the Xilinx apps guys sent me a private note about
> >that.  He said a Change Request was reported in September of last year, and
> >it was "closed as Never Fix."
> >
> >'tis a shame, because (IMHO) it's a damn useful feature.
>
> Am I missing something here?  My '99 databook shows that the
> 4000/Spartan parts do not have a register on the tristate control in
> the IOB.  Only the Virtex/Spartan2 parts have the register.
>
> Ta,
> Allan.

--
-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: 21186
Subject: Virtex and Virtex E package availability
From: "Don McCarley" <mccarley@fast.net>
Date: Thu, 9 Mar 2000 11:07:54 -0500
Links: << >>  << T >>  << A >>
Has anyone been able to actually obtain the larger packages for Virtex and
Virtex E devices?  Like the FG456, FG676, and FG680 for the 2.5V Virtex or
the FG456, FG676, FG680, FG860, FG900, and FG1156 for the 1.8V Virtex-E.
I'm interested in the lower io-count package availability experiences also.
Thanks, DM



Article: 21187
Subject: Re: I need parallel processor SIMULATOR
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 09 Mar 2000 18:15:53 +0200
Links: << >>  << T >>  << A >>
Juan Antonio Gómez Pulido wrote:

> Hi,
> Please, can anybody tell me if exits a PC simulator of parallel
> processors?
> Thanks a lot. Best regards.

IKOS has a special computer called Accelerator, which has
a board made up of 8 processors that are running in parallel
and are connected in hyber-cube architecture. It speeds up
the RTL, gate-level and postroute simulations by a factor of
200. http://www.ikos.com

Utku


Article: 21188
Subject: Re: Xilinx Foundation 2.1:Functional simulation
From: channing-wen@usa.net
Date: Thu, 09 Mar 2000 16:41:31 GMT
Links: << >>  << T >>  << A >>
In article <38C774A5.22DC009@imec.be>,
  Steven Sanders <sanders@imec.be> wrote:
>
> Hello,
>
> I have 2 problems concerning functional simulation:
>
> 1) How do I simulate  a simple VHDL file, viewing ALL its ports,
signals
> and variables?
> (with the functional simulator, no testbench)
>
> 2) When I create a macro from a VHDL file, many ports are missing on
the
> macro (in the schematic), although they are
> definitely used in the HDL code! Is this an optimization and can it be
> turnerd off?
>
> Thanx in advance!!!!
>
> Steven.
>
>
>

There are two step to solve your 1st problem.

First, you have to synthesize your VHDL source in your HDL Editor or
FPGA Express or other synthesis tools, and you can get the XNF netlist
file.

Secondary, open the Logic Simulator in Foundation Project Manager,
choose "Load netlist..." from the File menu, load your XNF netlist
which you got in the first step, now you can simulate your VHDL designs
just like to simulate the schematic design. (Use "select component"
select the signals/ports, draw the waveform..., and more)

For your 2nd problem, do you click the "Marco" checkbox in synthesis
option? If you use FPGA Express, please check the "Don't insert IO pad"
checkbox.

Good luck.



Channing


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21189
Subject: Re: ModelSim 2.1i ?
From: Ray Andraka <randraka@ids.net>
Date: Thu, 09 Mar 2000 16:48:36 GMT
Links: << >>  << T >>  << A >>
Not that I've seen.  Probably because they don't have a workaround either.

Rick Filipkiewicz wrote:

> Ray Andraka wrote:
>
> > Bzzzzt.  Nope, it's March, the Service Pack of the month this month is.... You
> > guessed it, Number 5.  And they still don't have my show-stopper bugs from SP2
> > fixed.
> >
> > --
> > -
>
> Have they even put them on the answers database yet ?

--
-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: 21190
Subject: Re: SpartanXL route and place
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 9 Mar 2000 10:31:01 -0700
Links: << >>  << T >>  << A >>
Allan Herriman wrote in message
<38c74aed.16256074@newshost.fujitsu.com.au>...
>On Wed, 8 Mar 2000 09:40:24 -0700, "Andy Peters"
><apeters.Nospam@nospam.noao.edu.nospam> wrote:
>
>>Ray Andraka wrote in message <38C64FE0.13682CCB@ids.net>...
>>
>>>AFAIK, the xilinx software still doesn't support the tristate register
for
>>4K
>>>parts.
>>
>>And it won't be.  One of the Xilinx apps guys sent me a private note about
>>that.  He said a Change Request was reported in September of last year,
and
>>it was "closed as Never Fix."
>>
>>'tis a shame, because (IMHO) it's a damn useful feature.
>
>Am I missing something here?  My '99 databook shows that the
>4000/Spartan parts do not have a register on the tristate control in
>the IOB.  Only the Virtex/Spartan2 parts have the register.

It's in the 4KX, 4KXL, 4KXLA, 4KXV and Spartan XL.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens



Article: 21191
Subject: Re: SpartanXL route and place
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 9 Mar 2000 10:35:43 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote in message <38C729AB.7C045357@ids.net>...
>Yeah,  the unofficial rumors I've heard have all been that they are doing
>nothing more on the 4K/spartan part of the software.  That means we're
stuck
>with the relatively broken floorplanner etc (relative to what we had in
>Xact6).  Looks to me like the 4K architecture is slowly being led out to
>pasture.

I believe that, too.  I inquired about the PCI core for the XLA parts
(mainly because I didn't want to deal with adding the 2.5V or 1.8V
regulators for virtex) and was told by the rep that "Xilinx probably won't
be supporting that core for too long..."

I haven't really looked at the differences between Spartan XL and 4KXLA.
guess I'm gonna have to.

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens



Article: 21192
Subject: Re: Microprocessor architecture (6800, 4004? PA-RISC, PPC, MIPS, x86,
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 9 Mar 2000 18:17:46 GMT
Links: << >>  << T >>  << A >>
In article <38C7C258.F0B7631C@planetc.com>,
Jerry English  <jenglish_no_spam_@planetc.com> wrote:
>www.opencores.org

>Looks like they will have a 32 bit processor posted in the next few days.
>Thats the good thing, the bad thing is  it will be written in VHDL. (:>)

>Anybody up to the task of moving it over to verilog?

I'm working on porting my TE16 CPU to Verilog.  It should be done some time
this month.  This is a tiny 16-bit CPU, not a 32-bit MIPS clone though.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 21193
Subject: FPGA board
From: "Yvon Hache" <hachey@concept-plus.com>
Date: Thu, 9 Mar 2000 16:49:34 -0400
Links: << >>  << T >>  << A >>
Hi,
We are working on an intensive calculation application.  We want to use the
parallel capability of FPGAs to accelerate the calculation.  Does anyone
know where we can find a PCI compatible board with large FPGAs that we can
download our VHDL code to do the calculation?  Or, is there such thing as
huge logic array available through the internet that we can download our
compiled VHDL, execute and get back the answer in no time?

Yvon H.


Article: 21194
Subject: Re: SpartanXL route and place
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 09 Mar 2000 15:10:15 -0800
Links: << >>  << T >>  << A >>


Allan Herriman wrote:

>
> Am I missing something here?  My '99 databook shows that the
> 4000/Spartan parts do not have a register on the tristate control in
> the IOB.  Only the Virtex/Spartan2 parts have the register.

Allan, you are not missing anything.
Since the software doesn't support it in XC4000XL and SpartanXL, it effectively
doesn't exist (sigh!), and is not documented.
Use Virtex and Spartan2 for registered control of Output Enable.

Peter Alfke


Article: 21195
Subject: Re: pal design using GAL22V10 and PROTEL
From: mikeandmax@aol.com (Mikeandmax)
Date: 10 Mar 2000 00:42:52 GMT
Links: << >>  << T >>  << A >>
steve wonders?>Most seem
>to be generated by the fact that not all the internal logic outputs are
>being used (i.e. using only 9 bits of a 16 bit counter).  I have tried
>placing no connects on the

Steve - a 16 bit counter will require 16 macrocells- no matter how many outputs
are 'unused'  
if you can make the design a 10bit counter, it should fit a 22v10 - 
can't comment on use of protel and the cupl wizard - have never seen it used.

If 16 bits is required - use a larger device - 
lattice/vantis makes a 29m16 with 16 macrocells, a gal6002 with 32 registers,
and CPLD devices starting at 32 macrocells, on up to 1080 macrocells.

good luck with the design - and give our local sales rep or FAE a call!

Michael Thomas
LSC SFAE
516-874-4968 fax 516-874-4977
michael.thomas@latticesemi.com
for the latest info on Lattice/Vantis -
www.latticesemi.com

Article: 21196
Subject: Re: SpartanXL route & place, Corrected
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 09 Mar 2000 17:12:09 -0800
Links: << >>  << T >>  << A >>
Please let me correct the misleading information I posted a few hours ago. I was
misinformed, and the truth is much nicer than what I had said.
Here are the facts:

XC4000, XC4000E, XC4000EX and even XC4000XL do NOT have a flip-flop driving OE,
they never had, and never will.

But the newer families, XC4000XV, XC4000XLA and SpartanXL DO have this feature. It
IS supported in epic/fpga_editor. That is how we recommend that it be accessed. A
macro is created in the editor and instantiated in the user's design. Bitgen fully
supports the programming of this feature.

As we all know, it is also in Virtex and Spartan2

Nice to know !

Peter Alfke,   Xilinx Applications





Article: 21197
Subject: Re: FPGA board
From: Dave Vanden Bout <devb@xess.com>
Date: Thu, 09 Mar 2000 20:29:05 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F1741D80BC8BCAA69860A22D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Yvon Hache wrote:

> Hi,
> We are working on an intensive calculation application.  We want to use the
> parallel capability of FPGAs to accelerate the calculation.  Does anyone
> know where we can find a PCI compatible board with large FPGAs that we can
> download our VHDL code to do the calculation?  Or, is there such thing as
> huge logic array available through the internet that we can download our
> compiled VHDL, execute and get back the answer in no time?

If your main goal is to speed up the calculation of your application, you may want to check one of the sites that specializes in farming out calculations to massive numbers of CPUs across the internet.

But if your main goal is to port the application to FPGAs and assess the speed-up, then the only place I know is Quickturn's QuickCycles program (http://www.quickturn.com).  They will let you submit and run designs on their systems over the internet.  I don't know the charges, but be prepared to pay $$$.  I would assume there is also a significant learning curve to become familiar with their system.

>
>
> Yvon H.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------F1741D80BC8BCAA69860A22D
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------F1741D80BC8BCAA69860A22D--

Article: 21198
Subject: Re: Extremely fault tolerant strategies
From: eee@netcom.com (Mark Thorson)
Date: 10 Mar 2000 01:43:52 GMT
Links: << >>  << T >>  << A >>
In article <8a3tbssp0dj8m2h0m03mf7g5shelhilesp@4ax.com>,
Brian Drummond  <brian@shapes.demon.co.uk> wrote:
>
>I wonder if it's worth trawling for information from the vacuum-tube and
>mercury delay line days (ACE, EDSAC, LEO etc), the late 40's and very
>early 50's. They faced these problems and usually, certainly LEO (Lyons
>Electronic Office) did, developed strategies to deal with them ... e.g.
>regular checkpointing, running test patterns with over/under voltage to
>catch marginal performance, etc.

I vaguely recall a paper with a title something like
"On Building A Reliable System From Unreliable Nodes"
by von Neumann.  Does anyone remember that more clearly?



Article: 21199
Subject: Re: SpartanXL route and place
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Mar 2000 22:08:50 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Its not in the data book because it's not supported by the software.  XC4000XL
> and XLA parts have the tristate register, but it is unknown to the software and
> therefore essentially unusable.  I don't know if it is in the Spartan part or
> not.  The earlier 4K parts do not have it.

Now this really doesn't make sense to me. They put a feature in the
chips that they never supported in software??? Why would they do that? I
am sure that the cost in real estate was not large, but I can't believe
they would fail to support such a simple feature. If you told me that it
was not supported in VHDL or some other means, then that would make
sense. But if they didn't even make an effort to support it in the
schematic form, then why put it in the chip? 


-- 

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


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