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 3500

Article: 3500
Subject: %% Trolling For DAC Dirt... From Users & The "Dark Side" %%
From: jcooley@world.std.com (John Cooley)
Date: Tue, 11 Jun 1996 16:27:59 GMT
Links: << >>  << T >>  << A >>

  TROLLING FOR USER DAC DIRT!
  ---------------------------

    It's once again that time of year, folks!   For those of you who went
  to last week's DAC in Las Vegas, I'd like to ask you for your impressions
  for the Forth Annual ESNUG/DAC Awards.  Please write me what you thought
  (and, yes, you'll be anonymous!)  What did you think was the best/worst/
  whatever DAC party, and why?  Technically what was the most interesting EDA
  product/tool you saw on the DAC floor and why?  The worst?  The <make your
  own category> product?  What was the biggest lie you heard from an EDA
  salesman and why?  What was the best freebie?  The worst freebie?  The
  <make your own category> freebie?  (And why?)  What was the best personal
  quote?  The best/worst/whatever DAC panel/paper/talk and why?  Which
  vendor had the best DAC booth and/or floor show?  The worst?  The
  stupidest?  The most content-free?  Ever watch a product crash right in
  the middle of its demo?  Whose?


  ....  AND CALLING ON THE DARK SIDE, TOO!
  ----------------------------------------

    Since turnabout is fair play, this year I'd like to add some voices from
  the "Dark Side" (the EDA vendors themselves) about what *they* saw in the
  customers at this year's DAC.  Of course, you'll also be anonymous, too!
  What is your most troublesome customer story?  What was the most outrageous
  customer request you got at DAC?  Did the customer get it?  Whose products
  do you wish you were selling?  Whose are glad you're not selling?  What
  was the most ridiculous claim you saw an EDA vendor try to make at DAC?

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 4258 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 3501
Subject: Re: Double Port Ram - Xact Libs
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 11 Jun 1996 16:58:31 GMT
Links: << >>  << T >>  << A >>
In article <4pjmjs$5tm@fstgal00.tu-graz.ac.at> maigner@sbox.tu-graz.ac.at (Manfred Aigner) writes:
>I can't find double port RAMS in thr XACT 4000 libary.
>How can I use this CLB facility if there is no symbol in the Libary ?
>Thanks in advance
>Manfred Aigner alias maigner@sbox.tu-graz.ac.at

The dual port RAM and Synchronous RAM symbols are not in the XC4000 
library, they are in the XC4000E library. If you don't have this
library, then you don't have the Xilinx CD for the XC4000E, which is
labeled XC4000E Pre-Release V1.0.0 and came out around the same time
as the XACT 5.2/6.0 release (escape). 

The XC4000E software including libraries was supplied on a request
only basis, initially with an NDA, but I don't think so any more.
You should just need to ask your local salesman or FAE for a copy,
assuming that you have a paid up license and maintainance contract.

I've been using this stuff for about a year, and both the sync RAM
and the dual-port stuff is great.

All the best,
	Philip Freidin.



Article: 3502
Subject: Re: Schematic compare
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 11 Jun 1996 17:06:54 GMT
Links: << >>  << T >>  << A >>
In article <1996Jun10.103315.11836@super.org> hubert.pujol@matra-transport.fr (Hubert Pujol) writes:
>Hello,
>I have an hold schematic (8 sheets) on DASH for a Xilinx 3064. I have files such as ".xnf", ".lca", ".rpt" ...
>I want to get a new one for update purpose. 
>We reentry the schematic on compass and reroute the 3064. But net are rename and file differ from the hold ones.
>
>My problem is the following : 
>How can I be sure that the new design is equivalent to the first one ? 
>
>The matter is not to do formal proof but to be able to get a same checksum for both designs. 

If you are running APR again on a netlist with different signal names,
there is almost no way that you will get identical checksums for the
resultant bitstream, as the device will be routed differently.

To get the software to generate IDENTICAL output, you need to give it
IDENTICAL input, and you need to force the simulated anealing seed value
on the second run to whatever was either chosen or forced on the first
run.

If your two sets of schematics represent the same design, gate for gate
(your goal, I believe), then you can at least compare the chip usage
report and check that they indicate the same number of CLBs. You might
want to try and compare the trimming reports.

If you can get all the signal names to be the same, you might try and
run the APR on the second schematic/netlist with the first design's .LCA
file as a guide. this might get you very close to identical results.

Good luck,
	Philip Freidin
>
>Does anybody get experiences for this problem ? 
>Thank you for your help.
>Hubert Pujol
>D. R. M.
>Matra - Transport - International
>48 - 56 rue Barbes
>BP 531
>92542 Montrouge Cedex
>
>Tel 33 1 49 65 71 65
>Fax 33 1 49 65 72 39
>e-mail hubert.pujol@matra-transport.fr
>---------------------------
>




Article: 3503
Subject: Re: Xtal Osc. at XC31xxA
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 11 Jun 1996 17:15:52 GMT
Links: << >>  << T >>  << A >>
In article <Pine.SUN.3.91.960611101320.18662A-100000@sushi> Rainer Scharnow <amigo@bintec.de> writes:
>Is there anyone who had experience in constructing a crystal oscillator 
>(1...10 MHz) at a XC31xxA similar to the description in the Xilinx 
>Programmable Logic Data Book? My very special problem is I cannot use the 
>dedicated IOs XTAL1/2 for that purpose.
>
>E-regards
>
>---------------------------
>Rainer Scharnow
>(amigo@bintec.de)
>BinTec Commmunications GmbH
>---------------------------

The XTAL1/2 pins have a special buffer designed specifically for driving 
a crystal as described in the data book. I have successfully built 
oscillators with the XC4000 (which doesn't have these pins) by configuring
an inverter between two general purpose pins, and connecting the crystal
to these two pins. There is a 2.2 M Ohm resistor in parallel with the
crystal, and there are two capacitors to ground, one from each pin of
the crystal, The values are 120 pF and 18 pF for a 2.4576 MHz crystal.
Sorry, cant tell you which way round the two caps are. you will have to
experiment with the cap and resistor values, depending on the crystal
frequency.

I seem to remember that you can leave the crystal out, and the circuit
will oscillate anyway. you adjust the components till the RC oscillator
is operating near the desired frequency, then add the crystal to lock it.

Good luck,
	Philip Freidin




Article: 3504
Subject: Re: FPGA Companies
From: "John L. Smith, Principal Engineer" <univis@univision.com>
Date: Tue, 11 Jun 1996 11:40:21 -0700
Links: << >>  << T >>  << A >>
> I have for a long time wondered if anyone will make FLASH-based FPGAs.

Altera's (formerly Intel's) FLEX family is flash based.


Article: 3505
Subject: Re: %% Trolling For DAC Dirt... From Users & The "Dark Side" %%
From: meric@orac.mti.sgi.com (Eric McCaughrin)
Date: 11 Jun 1996 19:34:29 GMT
Links: << >>  << T >>  << A >>
In article <DsuGEo.1pA@world.std.com>,
John Cooley <jcooley@world.std.com> wrote:
>
>  TROLLING FOR USER DAC DIRT!
>  ---------------------------
>
>  What was the best freebie?  The worst freebie?  
>  <make your own category> freebie?  (And why?)  

Nomination for the worst freebie:

I got a free water bottle (the bicycling kind) in exchange for
listening to a Veritools salesperson. After the conference, I drove to
the Grand Canyon with a friend for 3 days of camping.

The first day we went on a 6 hour hike. With temperatures reaching 110
degrees in the valley, it is critical to bring lots of water.  Many
people die each year from dehydration, including one unlucky hiker just
the day before.

I brought three water bottles on that hike, including the Veritools one
I got at DAC. Two hours into the hike, I discovered most of the water
in the Veritools water bottle had leaked out. The damn thing was
defective. Fortunately, I didn't die of dehydration, but it did soak
everything in my backpack.

I guess the moral is, don't entrust your life to a CAD vendor.

-- 
Eric McCaughrin					"There's no such thing as
meric@mti.sgi.com				 bad weather -- just bad
http://reality.sgi.com/employees/meric_mti	 clothing."


Article: 3506
Subject: Re: UART for Actel FPGA
From: peter@xilinx.com (Peter Alfke)
Date: 11 Jun 1996 20:19:32 GMT
Links: << >>  << T >>  << A >>
In article <4pi8ro$48hc@news-s01.ny.us.ibm.net>, 100410.763@compuserve.com
wrote:

> I need to build a UART into an Actel 1010.
> 
> Ideally this should be 16450 or 16550A compatible.
> 
Let me give you a general comment about implementing a standard peripheral
in an FPGA:
When Intel, National or Motorola designed dedicated peripherals, they
tried to make these deices as versatile as possible, so that one standard
device can serve a multitude of different applications. So they put in
some mode control registers to define: Number of bits in the word, number
of stop bits, parity,etc.

When you implement such a UART function in an FPGA you have two choices:

Build an exact replica of the general purpose device, which will then take
up a surprising amount of space ( = cost ) because all that cheap
dedicated flexibility designed into the original standard part must be
implemented with relatively expensive programmable logic.

Or you make your choices up front and implement a UART with exactly your
desired features, e.g. 7 data bits, 1.5 stop bits, odd parity, etc and
forget all the unnecessary flexibility, because you don't relly need it.
That solution can be quite efficient.

Think about this carefully, and don't be surprised or disgusted when the
"complete" UART implementation in an FPGA or CPLD is unacceptably
expensive. There is always another way to do it more cheaply.

Peter Alfke, Xilinx Applications


Article: 3507
Subject: Re: Xilinx 4013E and PCI
From: "Richard Gregg" <rr_gregg@cs.utas.edu.au>
Date: Wed, 12 Jun 1996 09:29:00 +1000
Links: << >>  << T >>  << A >>
> erik@blender (Erik de Castro Lopo) wrote in article
<4pjblc$tqn@reader1.reader.news.ozemail.net.ozemail.com.au>...
> Hi,
> [stuff deleted]
> Thanks in advance,
> 
> Erik.

Erik, what is your email address? erik@blender bounces.

Richard Gregg
-- 
Richard Gregg
Computer Science Department
University of Tasmania
Email: rr_gregg@cs.utas.edu.au


Article: 3508
Subject: Xilinx 4013E and PCI
From: erik@blender (Andrew Cannon)
Date: 12 Jun 1996 01:44:24 GMT
Links: << >>  << T >>  << A >>
Hi,

I'd like to hear from anyone who is using the Xilinn LogiCore PCI target
Interface for the Xilinx XC4000E series FPGAs. I'd be particularly interested
in finding out how easy the package is to use and how easy it is to add
application specific logic with out destroying the routablility and the 
PCI timing constaints.

I also got a quote from the Australian distributor of Xilinx on the
XC4013E-3, of US$318 in 100 off quanities. This is considerably more than 
I would have expected after using the XC3000 and XC3100 series. Does this
price seem reasonable?

Thanks in advance,

Erik.

PS : Please reply to the newsgroup as I don't have a proper return
     email address.



Article: 3509
Subject: Re: Double Port Ram - Xact Libs
From: Phil Roberts <phil@cri-dsp.com>
Date: Tue, 11 Jun 1996 20:39:58 -0600
Links: << >>  << T >>  << A >>
Manfred Aigner wrote:
> 
> --
> I can't find double port RAMS in thr XACT 4000 libary.
> How can I use this CLB facility if there is no symbol in the Libary ?
> Thanks in advance
> 
> Manfred Aigner alias maigner@sbox.tu-graz.ac.at

You need to use the 4000E libraries since dual port ram's are only
implemented in the 4000E and 4000EX family

Phil Roberts
phil@cri-dsp.com
http://cri-dsp.com


Article: 3510
Subject: Re: Xtal Osc. at XC31xxA
From: Rainer Scharnow <amigo@bintec.de>
Date: Wed, 12 Jun 1996 12:12:15 +0200
Links: << >>  << T >>  << A >>
On Tue, 11 Jun 1996, Philip Freidin wrote:

> In article <Pine.SUN.3.91.960611101320.18662A-100000@sushi> Rainer Scharnow <amigo@bintec.de> writes:
> >Is there anyone who had experience in constructing a crystal oscillator 
> >(1...10 MHz) at a XC31xxA similar to the description in the Xilinx 
> >Programmable Logic Data Book? My very special problem is I cannot use the 
> >dedicated IOs XTAL1/2 for that purpose.
> >
> >E-regards
> >
> >---------------------------
> >Rainer Scharnow
> >(amigo@bintec.de)
> >BinTec Commmunications GmbH
> >---------------------------
> 
> The XTAL1/2 pins have a special buffer designed specifically for driving 
> a crystal as described in the data book. I have successfully built 
> oscillators with the XC4000 (which doesn't have these pins) by configuring
> an inverter between two general purpose pins, and connecting the crystal
> to these two pins. There is a 2.2 M Ohm resistor in parallel with the
> crystal, and there are two capacitors to ground, one from each pin of
> the crystal, The values are 120 pF and 18 pF for a 2.4576 MHz crystal.
> Sorry, cant tell you which way round the two caps are. you will have to
> experiment with the cap and resistor values, depending on the crystal
> frequency.
> 
> I seem to remember that you can leave the crystal out, and the circuit
> will oscillate anyway. you adjust the components till the RC oscillator
> is operating near the desired frequency, then add the crystal to lock it.
> 
> Good luck,
> 	Philip Freidin
> 
> 
> 
> 

OK, I haven't been lazy for the last time... :-)
Thanks very much and here is my working result (variations will be welcome):

 <--------o-------------------------------------+
          |                                     |
          |                                     |
          |                                 ____O____
         / \                                \       /
        /   \                                \     /
       /     \   IBUF                         \   /   OBUF (inv.)
      /       \                                \ /
      ----+----                                 Y
          |                                     |
         / \                                   / \
 = = = = | | = = = = = = = = = = = = = = = = = | | = = = =
         \ / PIN A                             \ / PIN B
          |                                     |
          |                860 k                |
          |              +--------+             |
          o--------------+        +-------------o
          |              +--------+             |
          |   4...8 MHz                         |
          |         +-+           560           |
          |       I | | I      +--------+       |
          o-------+ | | +------+        +-------o
          |       I | | I      +--------+       |
          |         +-+                         |
          |                                     |
       ---+---                               ---+---
               56 p                                  56 p
       ---+---                               ---+---
          |                                     |
          |                                     |
          |                                     |
        --+--                                 --+--

E-regards

---------------------------
Rainer Scharnow
(amigo@bintec.de)
BinTec Commmunications GmbH
---------------------------


Article: 3511
Subject: Wanted Info on faults in FPGAs
From: gbhullar@doe.carleton.ca (Gurpreet S. Bhullar)
Date: 12 Jun 1996 13:15:24 GMT
Links: << >>  << T >>  << A >>
Hi,	
	I'm looking for information on types of faults that occur in
SRAM based FPGAs such as XC3K/4K and AT&T ORCA. The type of
information I'm looking for is 1. which resources fail most often (
local lines/CLBs/IOBs/pips/switch matrices) 2. What faults are most
common (metal migration/ bridging etc). 
	It would be helpful if there was some info on how closely do
FPGA failures resemble those of PLAs or static RAMs. Pointers to books
/papers/data sheets etc would be appreciated. Thanks for your  time.
regards,
Gurpreet.



Article: 3512
Subject: Re: Xilinx 4013E and PCI
From: David Holmes <david@highgatedesign.com>
Date: 12 Jun 1996 16:02:33 GMT
Links: << >>  << T >>  << A >>
> Hi,
> 
> I'd like to hear from anyone who is using the Xilinn LogiCore PCI target
> Interface for the Xilinx XC4000E series FPGAs. I'd be particularly interested
> in finding out how easy the package is to use and how easy it is to add
> application specific logic with out destroying the routablility and the 
> PCI timing constaints.

The design is such that the PCI logic is in the right half of the array leaving 
the right half for the application. If the application does not crowd 
the PCI half timing should be OK.
> 
> I also got a quote from the Australian distributor of Xilinx on the
> XC4013E-3, of US$318 in 100 off quanities. This is considerably more than 
> I would have expected after using the XC3000 and XC3100 series. Does this
> price seem reasonable?

The price is similar to prices I have seen in California.

If price is a concern and the application is small the PCI can be
moved to a 4010E.

> 
> Thanks in advance,
> 
> Erik.



Article: 3513
Subject: Re: Xtal Osc. at XC31xxA
From: peter@xilinx.com (Peter Alfke)
Date: 12 Jun 1996 16:28:39 GMT
Links: << >>  << T >>  << A >>
In article <Pine.SUN.3.91.960611101320.18662A-100000@sushi>, Rainer
Scharnow <amigo@bintec.de> wrote:

> Is there anyone who had experience in constructing a crystal oscillator 
> (1...10 MHz) at a XC31xxA similar to the description in the Xilinx 
> Programmable Logic Data Book? My very special problem is I cannot use the 
> dedicated IOs XTAL1/2 for that purpose.
> 
There is a simple, fast one-stage inverting buffer between XTAL2 and XTAL
1 without any input hysteresis, input pull-up.
If you use other pins by configuring an inverter between them, you get
more gain, an odd number of inverters, input hysteresis and other "stuff"
that gets in the way of a simple oscillator function. But it can work.
Consider using a canned oscillator. You can buy them for the same price as
a crystal ( <$1 here in the US in a retail store, single quantity ) and
they use less power and take insignificantly more space. That's the reason
we deleted the crystal oscillator function from the XC4000 and later
families.
Peter Alfke, Xilinx Applications


Article: 3514
Subject: Re: FPGA Companies
From: jmarden@ggx.com (Jeffrey C. Marden)
Date: Wed, 12 Jun 1996 21:08:07 GMT
Links: << >>  << T >>  << A >>
ft63@dial.pipex.com (Peter) wrote:



>>I believe Zycad makes flash based FPGAs, though I've never heard of anyone
>>actually using them.
>I have for a long time wondered if anyone will make FLASH-based FPGAs.
>This would be the ideal thing: the easy in-place multiple
>reprogrammability of Xilinx, with the facility to *not* have to do it
>at every power-up.

>Peter.

Xilinx now advertises the XC9500 family of FPGAs that are FLASH-based
("Fast-Flash").

jm




Article: 3515
Subject: Re: Double Port Ram - Xact Libs
From: Roberta Fulton <roberta.fulton@xilinx.com>
Date: Wed, 12 Jun 1996 16:41:03 -0700
Links: << >>  << T >>  << A >>
Just thought I'd let you know Xilinx will be shipping 
XACTStep v5.2.1/v6.0.1 software this month (June).

This release will be a production release that fully supports the
XC4000E (for the dual port rams required) and the XC9500 FLASH CPLD
family. Also be sure to ask for the various application notes on the
family and the rams. You can also browse www.xilinx.com.

Hope this helps, good luck (or is that "good engineering"!)


Article: 3516
Subject: Re: Double Port Ram - Xact Libs
From: Andy Gulliver <andy.gulliver@crossprod.co.uk>
Date: Thu, 13 Jun 1996 09:21:28 +0100
Links: << >>  << T >>  << A >>
Roberta Fulton wrote:
> 
> Just thought I'd let you know Xilinx will be shipping
> XACTStep v5.2.1/v6.0.1 software this month (June).

[cut]

Is this the release that runs under Windows95 (originally planned for 
April)??

-- 
Regards

AndyG


Article: 3517
Subject: External SRAM, XC4000 and clock hackery
From: shand@src.dec.com (Mark Shand)
Date: 13 Jun 1996 14:15:21 GMT
Links: << >>  << T >>  << A >>
Ever wondered how fast you can read external SRAM from a xilinx?

In the process of testing my PCI-based FPGA coprocessor
board (http://www.research.digital.com/SRC/pamette/), I
wanted to know how fast I could run the external SRAM.

My board contains XC4010E-3 parts and Motorola MCM6206D
32kx8 SRAM organized in two banks 64k x 16 bits.  Currently
I'm using the 15ns grade.  the SRAM address/data
bits are interleaved to allow efficient pointer chasing.  To
test read speed I devised the following setup.  The SRAM
is filled with a known value, say 0xDEAD.  Starting from two
designated locations, two randomly selected sequences
of addresses (each address different) are constructed which loop
back on themselves with some short period, say 8.  Perhaps
this is clearer as follows, if r is the SRAM, then for any
value x in the loops:

	x = r[r[r[r[r[r[r[r[x]]]]]]]];

and for any value y out of the loops:

	0xDEAD = r[y];
	
(of course 0xDEAD can not be a value in the loop).

I then constructed the following circuit:


		   +----> check
                   |
	   +-----+ | +-----+         +-----------+
	   | IOB | | | IOB |         |    SRAM   |
	+--+ in  +-+-+ out +---------+addr   data+----+
	|  | REG |   | REG |         |           |    |
	|  +-----+   +-----+         +-----------+    |
	|                                             |
	+---------------------------------------------+

The IOB registers were arranged to initialize to the two known
values in the loops (I used 0x8000 and 0xffff).

I then ran the circuit at differing clock speeds.  Whenever I
saw 0xDEAD on the "check" output I knew the circuit had failed.

If I connected both IOB REGs to the global clock the circuit
worked up to 55MHz.  Configuring the "in" REG in NODELAY mode got
me to about 60MHz.  In principle the SRAM should be able to be
cycled at 66MHz, its all just a matter of adjusting the clocks,
which is after all what NODELAY does.  My clock comes it on a
BUFGP (dedicated primary global buffer input pin).  I routed the
input from of non-dedicated IOB associated with that input pin
to the neighbouring BUFGS (secondary global buffer) and used this
as the clock for the IOB "in" REG.  Because both clocks come from
global buffers I don't need to worry about skew within the clocks
and the added delay to the BUFGS varies little from ppr to ppr.
It just redues the time the value has to propagate inside the
Xilinx -- fine on deeply pipelined designs -- so the trick seems
a good one.  With it the SRAM read test starts to fail at around 71MHz.

Nevertheless I think I'll put 12ns SRAM on my next batch of boards.
that way 66MHz will work reliably and maybe speed freaks who like
to live dangerously can push out to 80MHz!

Mark Shand
shand@pa.dec.com


Article: 3518
Subject: Re: Xilinx 4013E and PCI
From: "Steven C. Gerson" <steve@cri-dsp.com>
Date: Thu, 13 Jun 1996 09:18:43 -0600
Links: << >>  << T >>  << A >>
Erik de Castro Lopo wrote:

Dear Erik,

I too am looking into the Logicore PCI design and have found some very 
interesting material on www.xilinx.com describing distributed material 
with there product.  Also, I have, in house a loner design (hierarchical) 
in viewlogic schematics.  This design is targeted at the xc4013e-3 device 
and incorperates a burst fifo with the target design. The 4013e has ~ 50% 
of its resources left over for user defined applications.  The xilinx 
site has lots of information concerning the Logicore design and they will 
send you some free into by contaction pci@xilinx.com subject:pci packet

HOpe this helps:

Steve Gerson
steve@cri-dsp.com



Article: 3519
Subject: >Received: from mailserv.esat.kuleuven.ac.be by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
From: jma@gotham.super.org
Date: Thu, 13 Jun 1996 16:01:19 GMT
Links: << >>  << T >>  << A >>

                              SMACD'96

                           CALL for PAPERS                                 
                           ---------------

                     4th International Workshop on
            Symbolic Methods and Applications to Circuit Design
            ---------------------------------------------------

                      Leuven, October 10-11, 1996

                   Dept. Elektrotechniek, ESAT-MICAS
                    Katholieke Universiteit Leuven
                         Leuven, Belgium


General scope of the Workshop
- - - - - - - - - - - - - - -
Symbolic methods for the analysis and design of electronic circuits have been
the subject of steadily growing interest over the past years. Progress in
methodologies and new algorithms, and increasing efforts in computer
implementation have led to more usable software. On the other hand, the fast
evolution of the CAD domain, and the renewed interest in analog circuit design
and design automation, has put new light on the symbolic approaches.

In Europe, a growing number of teams are involved in research on symbolic
simulation and applications to circuit design.  Since 1991 the bi-annual
International Workshop on Symbolic Methods and Applications to Circuit Design
(SMACD) has been organized as a forum for exchange of new ideas and advances
in the field of symbolic circuit analysis and its applications. Following 
successful workshops in Bagneux (France - 1991),  Firenze (Italy - 1992), and
Sevilla (Spain - 1994), the 4th edition will be organized in Leuven (Belgium)
on October 10-11, 1996.

The workshop is endorsed by IEEE and ECS.
In addition, a selection of papers will be considered for a special issue
of the IEEE Transactions on Circuits and Systems, part II.


Topics of interest
- - - - - - - - - -
Papers on all aspects of symbolic analysis techniques and their applications
in circuit design are welcomed. Topics of interest include, but are not
limited to:
- recent advances in symbolic analysis techniques, design tools, and methods
- algorithms from computer algebra and graph theory applicable to symbolic
  circuit analysis
- realizations of symbolic simulators for analog and digital circuits,
  including demonstrations
- new methods of circuit design and design automation that make use of
  symbolic techniques
- innovative applications of symbolic analysis

The program also includes an invited speaker and several other technical and
social events.


Author schedule
- - - - - - - -

Prospective authors are invited to submit a 2-page summary of their
contributions to:

	Danielle Vermetten, SMACD'96 Secretariat
	Department Elektrotechniek, ESAT-MICAS
	Katholieke Universiteit Leuven
	Kardinaal Mercierlaan 94
	B-3001 Heverlee
	Belgium

	Tel : ++32-16-321077
	Fax : ++32-16-321975
	E-mail: smacd96@esat.kuleuven.ac.be


Author schedule

Submission of summaries .............................. June 24, 1996 
Notification of acceptance........................... August 5, 1996
Submission of final papers....................... September 27, 1996



ORGANIZING COMMITTEE
- - - - - - - - - - -
Prof. G. Gielen
Prof. W. Sansen
Dr. P. Wambacq
Katholieke Universiteit Leuven, Belgium


SCIENTIFIC COMMITTEE
- - - - - - - - - - -
Dr. M. Berger, Bosch, Germany
Prof. F. Fernández, CNM - Sevilla, Spain
Prof. G. Gielen, Katholieke Universiteit Leuven, Belgium
Prof. M Hassoun, Iowa State University, U.S.A.
Prof. E.-H. Horneber, University of Braunschweig, Germany
Dr. A. Konczykowska, CNET, France
Prof. A. Liberatore, University of Firenze, Italy
Prof. S. Manetti, University of Firenze, Italy
Dr. R. Sommer, University of Kaiserslautern, Germany
Dr. P. Wambacq, Katholieke Universiteit Leuven, Belgium
Dr. Q. Yu, Crystal Semiconductors, U.S.A.


=============================================================================

PRELIMINARY REGISTRATION FORM

I wish to attend the SMACD'96 Workshop. Please, send program and application
form when available.

Name:

Mailing address:



Phone: 

Fax: 

E-mail:



Please complete and return to

	SMACD'96 Secretariat (attn Danielle Vermetten)
	Department Elektrotechniek, ESAT-MICAS
	Katholieke Universiteit Leuven
	Kardinaal Mercierlaan 94
	B-3001 Heverlee
	Belgium

or by e-mail to : smacd96@esat.kuleuven.ac.be






Article: 3520
Subject: Re: Double Port Ram - Xact Libs
From: Roberta Fulton <roberta.fulton@xilinx.com>
Date: Thu, 13 Jun 1996 10:32:57 -0700
Links: << >>  << T >>  << A >>
Just thought I'd let you know Xilinx will be shipping 
XACTStep v5.2.1/v6.0.1 software this month (June).

This release will be a production release that fully supports the
XC4000E (for the dual port rams required) and the XC9500 FLASH CPLD
family. Also be sure to ask for the various application notes on the
family and the rams. You can also browse www.xilinx.com.

Hope this helps, good luck (or is that "good engineering"!)


Article: 3521
Subject: Re: UART for Actel FPGA
From: arnim@atlantis.actrix.gen.nz (Arnim Littek)
Date: 14 Jun 1996 09:54:38 +1200
Links: << >>  << T >>  << A >>
In article <peter-1106961320340001@appsmac-1.xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:
>When you implement such a UART function in an FPGA you have two choices:
>
>Build an exact replica of the general purpose device, which will then take
>up a surprising amount of space ( = cost ) because all that cheap
>dedicated flexibility designed into the original standard part must be
>implemented with relatively expensive programmable logic.
>
>Or you make your choices up front and implement a UART with exactly your
>desired features, e.g. 7 data bits, 1.5 stop bits, odd parity, etc and
>forget all the unnecessary flexibility, because you don't relly need it.
>That solution can be quite efficient.
>
>Think about this carefully, and don't be surprised or disgusted when the
>"complete" UART implementation in an FPGA or CPLD is unacceptably
>expensive. There is always another way to do it more cheaply.


What Peter didn't say here, and kudos for not blowing your own horn, is 
that one of the other ways is to use a reprogrammable FPGA (which does
not suit the Actel application at all!), and store a number of useful
configurations off-board, loading up only the necessary one at the time
of invocation.

This is possibly not useful for an application with a 16450, but for 
a serial port that functions as async 5 bits, async 8 bits, sync HDLC
etc. this is a viable and very useful attribute of FPGA-based UARTs.

Another thing Peter didn't say was that Xilinx has an app note on
building a 16450 in their parts.  I cannot comment on how much work
is involved in making it go on an Actel part, but the version I implemented
in XC5200 was not quite flawless, and required a little helping hand...

There are other sources around on the Net as well, if you poke around on
some of the HDL repositories, for instance.

FWIW.

Arnim

-- 
Arnim Littek                                    arnim@actrix.gen.nz
Actrix Networks Ltd.                            fax +64-4-499-1130
uucp/PPP/SLIP/BBS accounts                      tel +64-4-499-1122


Article: 3522
Subject: Fintronic USA Inc. Announcement
From: Alexandru Seibulescu <alex@fintronic.com>
Date: Fri, 14 Jun 1996 00:10:06 GMT
Links: << >>  << T >>  << A >>
ANNOUNCEMENT

Menlo Park, CA (June 13, 1996) In order to  thank  its  customers
for  their continuous support, Fintronic USA Inc. announces today
that for a limited time it will offer two copies of its most suc-
cessful  products for the price of one. Starting today until Sep-
tember 15th 1996, this promotion will be  available  for  FinSim-
ECS,  the full Verilog simulator with the integrated Enhanced Cy-
cle Simulation (ECS) Technology which has  recently  finished  on
top in an independent benchmark performed by DA Solutions (please
see the June 3rd edition of the EE Times,  article  titled  ``HDL
simulators  rated'',  page  16). The list price for FinSim-ECS is
$20,000, or $24,250 if bundled with Signalscan, the debugging en-
vironment  from  Design Acceleration. The same two for one promo-
tion is available for FinSim-Developer, a full Verilog  simulator
with  complete support for PLI and SDF and which has a list price
of only $5,000 (or $6,000 if bundled with Signalscan). Both  pro-
ducts  run on most popular platforms including SUN, HP, SGI, DEC,
Sony NEWS, PowerPC with Windows NT, Intel x86  with  Windows  NT,
Windows 95, Windows 3.1 or Linux.

Also today, Fintronic USA is introducing a new  product,  FinSim-
Station,  which  we  feel will provide its users with the fastest
simulation environment at the lowest price available in  the  in-
dustry.  It  includes a Pentium Pro 200 Mhz, 64MB RAM (expandable
to 512MB for only $9,000 extra), 2GB HD, 8x CD-ROM drive, 3D  ac-
celerated  graphic  adapter,  ViewSonic  17PS monitor and our top
performance Verilog simulator FinSim-ECS.  ``The  performance  of
our software on the Pentium Pro 200 Mhz platform is significantly
better than on an UltraSparc 167 Mhz and this  performance  comes
for  only  a fraction of the cost. Furthermore, we have seen many
designers worrying about the memory requirements  for  tomorrow's
million gates designs but few realize that half a Gigabyte of RAM
for the Pentium Pro costs under $10K. Many  people  have  yet  to
discover the tremendous potential of the Pentium Pro platform for
EDA, and FinSim-Station is our attempt to prove this  potential''
says  Dr.  Alec  Stanculescu,  president of Fintronic USA.  Until
September 15th 1996, FinSim-Station will have a promotional  list
price  of  $17,000  for  Linux  and  $20,000  for Windows-NT. The
Windows-NT version comes bundled with Signalscan.

For more detailed and up to date information as  well  as  online
ordering    forms,    please    consult    our    Web   page   at
http://www.fintronic.com, call  Dr.  Alec  Stanculescu  at  (415)
325-4474 x105 or fax us at (415) 325-4908.


Article: 3523
Subject: Reconfigurable Computing
From: sc@einstein.vcc.com (Steve Casselman)
Date: Fri, 14 Jun 1996 02:01:16 GMT
Links: << >>  << T >>  << A >>
There hasn't been much reconfigurable computing discussion
lately so...

Many of you might have heard Bob Parker talk about the 
"rule of thumb" performance numbers for FPGAs. The number
was how many 8-bit adders you can fit in an FPGA times the
frequency at which they can be clocked. This came from me
and the thought behind it was most operators in a high
level languages are simular to adds: adds, subtracts, compares,
increments .. So if an FPGA can hold X number of 8 bit adders
then that times the freqency is kind of like the number of
8-bit ops it can do. Although You can't get 100% utillization
if you think about 50% utillization and then consider that
all the data has to move (and this is an operation) then you 
start to come back to "I should just count the adders" type of
thought. I think one of the reasons reconfigurable computing
works is that the data flow is in the hardware. As opposed to
a CPU that emulates the data flow of an algorithm in a set of
registers.

So if you don't think my "rule of thumb" is very good then
what would be a good one? "Its different for every
problem/algorithm" is not a good answer! 


Steve Casselman

(I guess I havn't had a good flame for a while:)


Article: 3524
Subject: Re: Double Port Ram - Xact Libs
From: Richard Lomas <76244.667@CompuServe.COM>
Date: 14 Jun 1996 12:36:04 GMT
Links: << >>  << T >>  << A >>
xilinx supports dual port rams in their new 4000E architecture. 
You need to obtain an update from Xilinx. Some time I was given 
the following part number for the 4ke update
PR-VL-STD-PC1-4E-C
This was for the ViewLogic PC package

Rich Lomas




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