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 975

Article: 975
Subject: Synopsys design_analyzer Problem
From: tkoontz@uncc.edu (Terry Koontz)
Date: 6 Apr 1995 13:49:56 GMT
Links: << >>  << T >>  << A >>
I have a student that has the following problem when he tries to 
compile his vhdl example with the Synopsys design_analyzer.

We have Synopsys 3.2b running under Sun Solaris 2.3

Does anyone have any idea what's going on ???



I found a error when running synopsys.
The following procedure is what I did when I saw this error.
Go in design_analyzer & and setup and clicking on default.
Went to File menu and click on read and imported my file.
I then went to tools and scroll down to fpga compiler and clicked on optimization.
This error popped up when optimizing.  The error states:
Error: The entity 'add_sub_tc' depends on the package 'std_logic_arith' 
         which has been analyzed more recently.
       Please re-analyze the source file for 'add_sub_tc' and try again (LBR-28).

Enclosed is my source code I used.
----------

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.std_logic_arith.all;

entity digsproc is
	port(a, n0, n1, n2: in std_logic_vector(3 downto 0); rst: in std_logic; clock: in std_logic; x: out std_logic_vector(9 downto 0));

end digsproc;

architecture behavior of digsproc is
signal q0, q1, q2: std_logic_vector(3 downto 0);
signal s0, s1, s2: std_logic_vector(7 downto 0);
begin
	process(a, rst, clock)
	begin
		if(rst = '0') then
			q0 <= "0000";
			q1 <= "0000";
			q2 <= "0000";
			else if(clock' event and clock = '1') then
			 	q0 <= a;
				q1 <= q0;
				q2 <= q1;
			end if;
		end if;
	end process;

	s0 <= n0 * q0;
	s1 <= n1 * q1;
	s2 <= n2 * q2;

	x <= conv_std_logic_vector(conv_integer(s0) + conv_integer(s1) + conv_integer(s2),10);


end behavior;
			





Article: 976
Subject: Motorola Software Support
From: Darren@pmel.com
Date: Thu, 6 Apr 1995 13:50:26 GMT
Links: << >>  << T >>  << A >>
Just to cast more light on the speculation regarding
the Xilinx acquisition of Neocad;

Judging from various press reports and newsgroup postings, 
people seem to be under the misapprehension that Neocad 
supplied the only software support tools for the Motorola 
MPA1000 series FPGAs. This is not the case.

In fact, the Motorola architecture is licenced from 
Pilkington Micro-electronics Ltd, who also provide their
own software tools through alliances with Intergraph and 
Capilano Computing.

A FREEWARE version (limited to 2000 gates) is also 
available, with libraries for Viewlogic Schematics, 
Capilano Designworks Schematics, VHDL, Verilog and 
Exemplar Synthesis Tools and full on-line help.

	- email to    info@pmel.com 
	  for an automated response with full details.

So, although Neocad was Motorola's preferred solution, 
there is an equally good, if not better, alternative.

**********************************
*  My opinion, not my employers  *
**********************************

Darren Wedgwood
Senior Apps. Eng.
Pilkington Micro-electronics Ltd.


Article: 977
Subject: Re: pinout changes
From: Mohammed Khalid <khalid@eecg.toronto.edu>
Date: Thu, 6 Apr 1995 15:03:40 GMT
Links: << >>  << T >>  << A >>

I have completed an experimental study on the effects of pre-assigning FPGA
I/O pins on the routability and speed of Xilinx XC4000 and Altera FLEX8000
FPGAs. I will be presenting the results in FPD'95 (Canadian Workshop on PLDs)
Interested persons can find the paper in the Workshop Proceedings or they
can contact me for a PostScript copy.

Khalid



Article: 978
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: bbutler@netcom.com (Bryan Butler)
Date: Thu, 6 Apr 1995 15:32:18 GMT
Links: << >>  << T >>  << A >>
Phil Ngai (pngai@mv.us.adobe.com) wrote:
> In article <3lbdtr$o1j@gap.cco.caltech.edu> jkubicky@cco.caltech.edu (Joseph J. Kubicky) writes:
> >I (or, rather, my company) just paid nearly $3K for Abel 6.0 for
> >Windows and a fitter for Lattice PLDs.  Now the Lattice devices

> As a person who has been using Abel for several years and Synario for
> almost a year, I wanted to respond to your comments. I certainly don't
> feel the way you do about the product. I think ripped off is much too
> strong a term, and probably not even true. I find it especially ironic
> that you compare Abel's value with the Intel package.

> Do you realize that Intel is a chip company? Of course they are going
> to give away their software. They want to sell chips.

Most other chip vendors do not give away their software. I don't remember
exact prices, but Actel, Altera, and Xilinx are all over $1K. The PLDshell
isn't polished software, but it does work. Intel is one of the few that
gave away software.

> In fact, they are no longer in the programmable logic business. Seems
> they found it to be unprofitable.

> I don't think doing value comparisons with a company that went out
> of business makes any sense! Perhaps you'd like to calculate how much
> it costs to get tech support from Intel for PLDShell...

I am not a big Intel fan, but I have to say the support they gave me on
their FPGAs and PLDShell was excellent.

> >My first problem has been with the hardware lock.  It works ok on
> >my laptop (which is a relatively slow 486SX/33 with 8MB RAM) but
> >isn't recognized on my desktop (a 486/100 clone w/ 24MB RAM).  My

> I've never had any problems with their hardware locks so your
> experience is probably not typical.

I have started boycotting any software that comes with a hardware key.
Not every computer running Mess-DOS/Windoze has a parallel port.

> What's a MAX8000? Perhaps you mean Flex8000? Anyway, you won't find
> Altera giving away their software, unless you want to do VERY SMALL
> designs.

MAX8000 and Flex8000 are two separate architectures. MAX is Altera's high
density FPGA. Flex is the architecture purchased from Intel. Much less
dense.

--
-------
Bryan Butler
bbutler@netcom.com


Article: 979
Subject: Re: AT&T Statement ref Neocad
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 6 Apr 1995 16:34:08 GMT
Links: << >>  << T >>  << A >>
In a EE Times article which referred to Xilinx
statements, it seems that there are no guarantees that
Xilinx/Neocad will support non-Xilinx devices after 1 year.

The vendor-independent FPGA design toolset is dead.

1.  That's a shame.  If I want to use both Xilinx and
Orca devices, I'll probably need two different design
database/libraries/executables/etc.  This is a big step
backward (again).

2.  There's a market opportunity for filling the hole
vacated by Neocad/Xilinx.

3.  It could be that MINC is the big (dark-horse) winner
in this, if their design databases are device-independent.
Any comments on this from MINC users?

Bob Elkind, Tektronix TV Products
bobe@tv.tv.tek.com


Article: 980
Subject: Re: AT&T Statement ref Neocad
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Thu, 6 Apr 1995 18:41:54 GMT
Links: << >>  << T >>  << A >>
Bob, I don't understand your comparison of Minc vs Neocad.
I thought Minc did design entry, logic optimization, and
device fitting, while Neocad did place and route.  Comparing
Minc and Neocad would seem like comparing a schematic editor
and a PCB design program, unless my understanding of what
Minc and Neocad do are way off.

-- 
 Question Authority, but never shoot back.


Article: 981
Subject: Re: Need 100 MHz, relatively low power FPGAs
From: markn@arezzo.atc.olivetti.com (Mark Nass)
Date: 6 Apr 1995 23:05:21 GMT
Links: << >>  << T >>  << A >>
In article <GAJIT.95Mar26222616@little-star.rice.edu>,
gajit@owlnet.rice.edu (Ajit Kurian George) writes:
> I'm a student working on building a PCI device using FPGAs for control
> logic and multiplexing.  We need to operate at 100 MHz and we also
> don't have much power to budget for the FPGAs.  What architecture is
> best suited for this situation?  
> 
> We've got some Actel data books that describe the power consumption
> using an equation with a lot of variables that we don't know, since we
> haven't actually written any code yet.  I'm looking for ballpark
> figures for this kind of application that someone might have gleaned
> from experience.
> 
> I was also told by a guy at TI that the Actel stuff is too slow for
> 100 MHz and that we should probably look at QuickLogic products.
> However, he also admitted that he was basing that statement on his
> experience of an old Actel architecture that TI licensed a few years
> ago.
> 
> Thanks for any help,
> Ajit
> 
> 
> --
> Ajit George
> gajit@rice.edu


   I don't believe Actel has anything that will run at 100 Mhz, and they
don't have anything
that is PCI complient with the AC Specs. Cypress has a pASIC380 family
of parts that
are supposed to be faster than Actels, I think they are Quick logic parts.

Mark






































t



Article: 982
Subject: Re: Aptix (Field Programmable Interconnect) ??
From: bajwa@guardian.cse.psu.edu (Raminder S Bajwa)
Date: 6 Apr 1995 23:51:47 GMT
Links: << >>  << T >>  << A >>

>Hi:
>
>I hope that this posting is in the right group...
>
>I am designing a prototype board using Altera's Flex  81188 FPGAs and I-Cube's
>IQ160 FPID (Field Programmable Interconnect Devices).  The problem is that 
>these devices do not have a socket to be used with them, thus I have to solder
>them on the board and this is something I want to avoid at this point of the 
>design.  I was told that another company (called Aptix) is also marketting 
>programmable interconnect chips so any information on how to contact them or 
>anything else I should know on programmable interconnect chips would be 
>really appreciated.
>
>Thanks, 
>
>Loucas

Loucas,
	Check with AMP, they will do some custom socket work. It will cost
more than off-the-shelf-parts but you might still want to consider them.
Their number is 800-522-6752.

Good luck,
	Raminder


Article: 983
Subject: Free online JTAG tutorial and C library
From: devb@elvis.vnet.net (David Van den Bout)
Date: 7 Apr 1995 08:24:19 -0500
Links: << >>  << T >>  << A >>
XESS Corp. has just released the third chapter of
"FPGA Workout II".  This chapter covers JTAG 1149.1
boundary scan testing and shows how to use it to 
test digital systems in general and the EPX780 FPGA
in particular.  A library of C subroutines for doing
JTAG testing through the PC printer port is included.
The chapter is a hypertext document that will execute
on a DOS machine with a VGA display.

If interested, you can retrieve this file via
anonymous FTP from ftp.vnet.net in directory
pub/xess/hyperdoc.  Get the ZIPPED and executable
file jtag.exe and install.txt.
-- 

||  Dave Van den Bout  ||
||  Xess Corporation   ||


Article: 984
Subject: Looking for informition
From: jmthorne@dolphin.upenn.edu (jmthorne)
Date: 7 Apr 1995 13:51:37 GMT
Links: << >>  << T >>  << A >>
Hello.  I have been a C/C++ programmer for many years and have just 
recently been introduced to FPGAs.  I am curious to know if there is any 
information (On-line or off) that will help me understand the nature of 
the FPGA and how to program it.  I received some literature from Altera 
and am awaiting Xilinx (which seems to be a favorite in this 
conference).  Altera's "Data Book" was helpful in peaking my interest.  
This combined with the fact that a contract I am doing work for has 
Xilinx FPGA's for use in an encryption algorithm. Any help would be 
appreciated..

  Thanks
      Josef


Article: 985
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Fri, 7 Apr 1995 17:03:33 GMT
Links: << >>  << T >>  << A >>
In article <bbutlerD6MDtu.HzH@netcom.com> bbutler@netcom.com (Bryan Butler) writes:
>> I don't think doing value comparisons with a company that went out
>> of business makes any sense! Perhaps you'd like to calculate how much
>> it costs to get tech support from Intel for PLDShell...
>
>I am not a big Intel fan, but I have to say the support they gave me on
>their FPGAs and PLDShell was excellent.

But you can't get it at any price now. Personally, I prefer for
my vendors to stay in business. (Intel is still around but not
doing programmable logic now.)

>> What's a MAX8000? Perhaps you mean Flex8000? Anyway, you won't find
>> Altera giving away their software, unless you want to do VERY SMALL
>> designs.
>
>MAX8000 and Flex8000 are two separate architectures. MAX is Altera's high
>density FPGA. Flex is the architecture purchased from Intel. Much less
>dense.

My Altera data books disagree with you. There is no Max8000. Their high
density "FPGA" line is called Flex8000. (but note that Altera has
changed their mind [but not the part] and is now calling it a CPLD)
Intel also had a product line called Flex Logic 8000. Altera has
renamed this Flash Logic. But there is no such thing as MAX8000.

-- 
 Question Authority, but never shoot back.


Article: 986
Subject: PPR problem
From: tame@eecg.toronto.edu (TAM ERNEST CHI YUI)
Date: 7 Apr 95 17:04:28 GMT
Links: << >>  << T >>  << A >>
When I want to ppr my design in XC4010, it says that the .xtf file is
missing.  I used ppr before but that time, my design was made of 
standard logic.  This time, all the building blocks are described in
VHDL.  I am working in the Powerview environment.  I use vhdl analyzer 
to analyze the source code and then use vhdl2sym to create the 
symbol for each block.  Afterwards, I use Viewdraw to put together
all the blocks and simulate.

Is there any step I have to do before I run the PPR program?
How can I generate the .xtf file for PPR?

Your help is very appreciated.

Ernest
tame@ecf.toronto.edu



Article: 987
Subject: Re: AT&T Statement ref Neocad
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 7 Apr 1995 21:28:58 GMT
Links: << >>  << T >>  << A >>
pngai@mv.us.adobe.com (Phil Ngai) writes:
>Bob, I don't understand your comparison of Minc vs Neocad.
>I thought Minc did design entry, logic optimization, and
>device fitting, while Neocad did place and route.  Comparing
>Minc and Neocad would seem like comparing a schematic editor
>and a PCB design program, unless my understanding of what
>Minc and Neocad do are way off.

Good question.  My perspective is a bit different than yours,
but I'm sure I don't know all there is to know on the subject.

To me, Neocad is (was?) a design capture to place/route
toolset that has/had most of the capabilities for device
and/or technology independence.  In order to get from
design capture to finished layout, a schematic capture tool
(e.g. ViewLogic) *and* a set of libraries must be added,
plus the netlist->layout interface translation utility.

Here's the key:  A single library (set) gave you designs
that Neocad could interpret and target to any one of a number of
FPGA devices, with reasonably good results.  With a small
additional effort, you have to use device/technology specific
libraries/macros/etc. to take advantage of special device
features (e.g. dedicated carry logic, on-chip RAMs, etc.).

This means a lot to me, and I will miss it.

Compare this approach to Xilinx XACT tools.  You enter the
toolset with a set of schematics based on Xilinx 4K-specific
gates, or 3K-specific gates, or 2K-specific gates and symbols.
This was very much the case for the first two generations
of (e.g. OrCad) symbol libraries from Xilinx.  With the
advent of Xact 5.x, there *is* the notion of a (new, incompatible)
generation of library symbols that truly *are* technology
independent, as long as it is Xilinx' technology.

Do you see what I'm getting at?  Neocad, with its *Neocad*
libraries (as opposed to 4K/3K/2K/2C/1C libraries) provided
much of the device-independence of HDL, whilst permitting
the gate-level graphic display language we macho design
engineers lovingly call "schematics".  Plus, we get the
utilisation efficiency that is sometimes elusive (so far)
to Synosis (et al) users.

Comments, please!  I want to learn more.

Neocad (the independent one), I think I'll miss you
very much.

Bob Elkind, Tektronix TV Products


Article: 988
Subject: Frep onl!op JTAG tutirial and C library
From: devb@elvis.vnet.net (David Van deV Bout)
Date: Fri, 07 Apr 95 23:40:50 MST
Links: << >>  << T >>  << A >>
XESS Corp. har juri releaspc the third chapter of
"FPGA WorkRut II".  This chapter covess JTAG 1149.1
boundary scan testrog etc shows how to usp it to 
test digital systems in general atc the EPX780 FPGA
in prg!icular.  A library of C subroutines for doiVg
JTAG testrog through the PC printne port is included.
The chapter ir a hypertext documeRV a DOS machine with a VGA displny.

If interested, you can retrieve this file via
anonymoun FTP from ftp.vnet.net in directory
pub/xess/hyperdoc.  Get the ZIPPED atc executable
file jtag.exe and install.txt.
-- 

||  Dave Van deV Bout  ||
||  Xess Corporstrib   ||


Article: 989
Subject: Xilinx XC3000a/4000 as LCD-driver
From: pfaff@mes.uni-linz.ac.at (Markus Pfaff)
Date: 08 Apr 1995 13:50:05 GMT
Links: << >>  << T >>  << A >>

Hi,

we want to use Xilinx FPGA to directly drive a non-multiplexe ('naked') LCD.
The problem with that is, that these Displays need a pure (dc-free!) 
ac-voltage to dark a segment and no (~zero) voltage to leave it transparent.
External circuits between FPGA and LCD should be minimized, at best to
pure connections.
Three cases have to be considered:
1) operation
    Seems to be no problem
    (-> Xilinx Programmable Logic Data Book, 1994, 9-16)
2) powerdown
    Not quite interesting to us yet, but seems to be no problem, because all
    outputs are inactive and carry the same voltage.
3) configuration and powerup (problems arise)
    We configure the device with a parallel EPROM. Therefore a lot of pins
    have to be used for configuration in another manner than during normal
    operation. Some of these pins have to drive segments of our LCD, because
    we are using a PC84-package an a LCD with 49 segments.
    During configuration these segments are set to high and low voltage in
    a arbitrarily manner. The solution to prevent the LCD from staying
    under dc-voltage during configuration would be to 3-state the 
    LCD backplane. 
    Unfortunately Xilinx places a 50-100 kOhm pullup on the output during 
    configuration.

We considered placing a real tri-state buffer between the FPGA and the 
LCD backplane, but this might introduce problems during normal operation,
because of different high and low voltages of that buffer in relation to
the FPGA outputs driving the LCD segments. Therefore a (rather small)
dc-voltage would be introduced.

Can anybody help me with that?

Thanks,

Markus.
-- 
___________________________________________________________________________

Dipl.-Ing. Markus Pfaff, University of Linz/Austria,      \  Latest news:
  Institute of Systems Science,                           /   
  Dept. Microelectronic Systems - Prof. Dr. Hagelauer     \         No
  Altenberger Str. 69, A-4040 Linz                        /    kangaroos
  Tel.: +43 732 2468 9777    (or ...877)                  \     in
  Fax.: +43 732 2468 892                                  /  Austria!
  E-mail: pfaff@mes.uni-linz.ac.at                        \



Article: 990
Subject: Re: Vendor Info
From: ipacker@bloggs.win-uk.net (Ian Packer)
Date: Sat, 08 Apr 1995 18:45:37 GMT
Links: << >>  << T >>  << A >>
I posted the article you refer to. I also run a manual mailing
list on ORCA.
Originally I posted an invitation to UK only subscribers to join the
list, purely because I work for a UK Distributor & I didn't want to
step on any toes, however I was cajoled into accepting any
subscriptions. Later a few people suggested that if it was only a
short article I should post it to comp.arch.fpga as they thought
that's what the Newsgroup was there for. I have also posted
pointers as you suggest to Web sites & BBSs etc. As there isn't a
maintained list of Application Notes I posted.

I think we agree on the whole, but I thought it worth an
explanation.
 


  In article <3lu79d$20n@aurns1.aur.alcatel.com>, William J. Wolf
(wolf@aur.alcatel.com) writes: >IMHO vendors should post *pointers*
to www sites, ftp sites, etc  >that have info such as that contained
in: >
>> AT&T FPGA #6 - Application Notes
>
>Take this for example - instead of just dumping today's 
>special into comp.arch.fpga, post a pointer to a maintained 
>list of FPGA app notes (along with net pointers to other 
>FPGA info).
>
>If users *want* dumps of today's special, I suggest AT&T 
>support a list server for FPGAs (like Altera & Xilinx) 
>and post directions on how to sign up.
>
>Is there a vendor out there who could take the time to 
>compile a list of net pointers to your FPGA info?  If 
>one of you will go first, I suspect others will also follow.
>This would also help greatly with the newbie questions.
>
>---
>- Bill Wolf, Raleigh NC
>- My opinions, NOT my employer's
>
>
>

Regards,
Ian Packer.
Bytech Electronics Ltd.


Article: 991
Subject: Re: Xilinx XC3000a/4000 as LCD-driver
From: ian@neocad.com (Ian McEwen)
Date: 9 Apr 1995 10:37:51 -0600
Links: << >>  << T >>  << A >>
Markus Pfaff (pfaff@mes.uni-linz.ac.at) wrote:

: Hi,

: we want to use Xilinx FPGA to directly drive a non-multiplexe ('naked') LCD.
: The problem with that is, that these Displays need a pure (dc-free!) 
: ac-voltage to dark a segment and no (~zero) voltage to leave it transparent.
: External circuits between FPGA and LCD should be minimized, at best to
: pure connections.

: Can anybody help me with that?

Markus:

I assume you are concerned about damaging the LCD display by having a DC
voltage across backplane->segments, not about flickering segments during
device configuration.  If this is the case, I think you may be a bit
overcautious.  I have used FPGA demo boards with LCD displays, and have
inadvertantly put 5 volt DC signals between the backplane and segments
for a number of seconds.  The display doesn't work properly with DC
signals, but also has not been damaged.  I suspect that whatever stray
signals you have during device configuration are not going to damage your
display.

Of course, it might also be the case the the display I am using is just
a lot more robust than yours (disclaimer so you won't sue me when your
LCD display explodes and your lab burns down).

-- Ian


Article: 992
Subject: Re: Xilinx XC3000a/4000 as LCD-driver
From: fliptron@netcom.com (Philip Freidin)
Date: Mon, 10 Apr 1995 06:59:01 GMT
Links: << >>  << T >>  << A >>
LCDs can be driven directly by any of the XC3000 family devices, as the 
output swing is always rail to rail.

LCDs can be driven directly only by the XC4000H variant of the XC4000 
family, and only if its output is configured for CMOS mode, which gives
a rail to rail output. The rest of the 4000 families could be used if you
added external pullup resistors (100K or higher is probably fine) to get
a rail to rail swing. The internal pullups can not be used for this as
they dont pullup to the VCC rail, only to about 3.5 Volts. Unfortunately, 
such a configuration will draw power whenever the segment line is low, 
which is often undesirable.

You can think of LCDs as an integrator of the voltage applied across the 
segments and the backplane. You want to avoid having an integrated value 
that is not zero, over the life of the display. This is why you drive 
segments and the backplane with AC (actually, out of phase square 
waves for segment on, and in-phase square waves for segment off).

If you dont have a net integration of 0v/time, then either the backplane 
electrode in the vicinity of the segment, or the segment itself will 
deteriorate, as the electrode is plated onto the other electrode. This 
takes time, and typically, is measured in hours, for a 5volt LCD. Because 
of this, I dont think you need to worry about the short duration that the 
display is DC biassed, during configuration.

All the best,
		Philip Freidin,     FPGA consultant.





In article <PFAFF.95Apr8155006@piggy.mes.uni-linz.ac.at> pfaff@mes.uni-linz.ac.at (Markus Pfaff) writes:
>
>Hi,
>
>we want to use Xilinx FPGA to directly drive a non-multiplexe ('naked') LCD.
>The problem with that is, that these Displays need a pure (dc-free!) 
>ac-voltage to dark a segment and no (~zero) voltage to leave it transparent.
>External circuits between FPGA and LCD should be minimized, at best to
>pure connections.
>Three cases have to be considered:
>1) operation
>    Seems to be no problem
>    (-> Xilinx Programmable Logic Data Book, 1994, 9-16)
>2) powerdown
>    Not quite interesting to us yet, but seems to be no problem, because all
>    outputs are inactive and carry the same voltage.
>3) configuration and powerup (problems arise)
>    We configure the device with a parallel EPROM. Therefore a lot of pins
>    have to be used for configuration in another manner than during normal
>    operation. Some of these pins have to drive segments of our LCD, because
>    we are using a PC84-package an a LCD with 49 segments.
>    During configuration these segments are set to high and low voltage in
>    a arbitrarily manner. The solution to prevent the LCD from staying
>    under dc-voltage during configuration would be to 3-state the 
>    LCD backplane. 
>    Unfortunately Xilinx places a 50-100 kOhm pullup on the output during 
>    configuration.
>
>We considered placing a real tri-state buffer between the FPGA and the 
>LCD backplane, but this might introduce problems during normal operation,
>because of different high and low voltages of that buffer in relation to
>the FPGA outputs driving the LCD segments. Therefore a (rather small)
>dc-voltage would be introduced.
>
>Can anybody help me with that?
>
>Thanks,
>
>Markus.
>-- 
>___________________________________________________________________________
>
>Dipl.-Ing. Markus Pfaff, University of Linz/Austria,      \  Latest news:
>  Institute of Systems Science,                           /   
>  Dept. Microelectronic Systems - Prof. Dr. Hagelauer     \         No
>  Altenberger Str. 69, A-4040 Linz                        /    kangaroos
>  Tel.: +43 732 2468 9777    (or ...877)                  \     in
>  Fax.: +43 732 2468 892                                  /  Austria!
>  E-mail: pfaff@mes.uni-linz.ac.at                        \
>




Article: 993
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: Mon, 10 Apr 1995 07:17:57 GMT
Links: << >>  << T >>  << A >>
 pngai@mv.us.adobe.com (Phil Ngai) writes :-
>I'm not sure what the purpose of test vectors for PLDs is anymore.
>Back when fuses were one-time things and the chip companies couldn't
>100% test them, I suppose the chance of a defective chip was non-zero.
>With eraseable chips, is this still a problem?
>
>Or are we talking about design verification vs manufacturing test?
                                   NO               YES

I now use in-system programmable (and boundary scan) parts where possible (no vectors
required as the download process verifies the part). Where there is a requirement for a standard PLD we use ATPG for test during programming and also at PCB test. This ensures
we have the correct PLD fitted and that it functions correctly.

T.H. 




Article: 994
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: Mon, 10 Apr 1995 07:49:14 GMT
Links: << >>  << T >>  << A >>
kgold@watson.ibm.com (Ken Goldman)writes :-
>trev@ss11.wg.icl.co.uk (Trevor Hall) writes:
>> kgold@watson.ibm.com (Ken Goldman) writes:-
>> 
>> >3 - Here's why I think you're a bit off base.  Simulating a PLD is 
>> >different from simulating an ASIC.  
>> >You don't need to get it right the first time,
>> 
>> I disagree. If you don't get it right first time you are likely to end up 
>> with PCB modifications. The approach I take is to perform a 'does it 
>> look OK' simulation with the PLD tool and then run extensive worst-case 
>> PCB level simulation.
>> Maybe your approach is different because you are only making one-offs, 
>> but there are a lot of systems out there that have not been worst-cased.
>> 
>
>I agree that one might occasionally forget an input, but it's been rare
>for me.  And despite my division name, I am designing products.  Since
>time to market is the key, I've found that it's faster to build a
>board than to spend months developing simulation models.  Again. this
>is for boards with PLD's, not ASICs.  

>Any other opinions.  Are others doing full PCB simulation for cards
>without ASICs?  Does it really result in a PCB with _zero_ errors,
>meaning you go straight to volume production with the first PCB?

I think the real benefit of full PCB simulation is the detection of timing hazards.
Without this 90% of your PBC's may work, the remainder don't, are intermittent or
even worse, fail in the field when the wind is in the wrong direction.  


>> >4 - Remember that the same test vectors are used by the programmer to test
>> >the physical part.  That affects the simulation philosophy.  Physical
>> >parts are never in a "don't care" state.
>> 
>> For production I would strongly recommend automatic test vector 
>> generation. We are not happy until we have greater then 98% test cover.
>> 
>
>I agree with the 98% coverage (or better).  But I usually try for that
>at the PCB level, not at PLD programming time.
>
>Other opinions.  Is it common to use automatic test vector generation
>for PLD's?  Does it find errors that a few hundred hand crafted vectors
>plus board level test would not find?

I think the answer to this is ;- without ATVG how do you know what your test cover is ?
Also, if you have a large number of PLD's, do you really want to 'handcraft' all those
vectors.

With the advent of in-system programmable/boundary scan parts, the problems of test are
ameliorated. The parts are verified at programme time and the boundary scan eases
PCB test. It is also worth noting that the ATVG programmes are beginning to struggle
with the larger CPLD's.


Whilst on the topic of test, how are the users of large anti-fuse devices catering
for test, either at program time or PCB test ? Are there ATVG products out there for
these devices ?

T.H.










Article: 995
Subject: Re: AT&T Statement ref Neocad
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: Mon, 10 Apr 1995 08:15:01 GMT
Links: << >>  << T >>  << A >>
bobe@soul.tv.tek.com (Bob Elkind) writes :-
>In a EE Times article which referred to Xilinx
>statements, it seems that there are no guarantees that
>Xilinx/Neocad will support non-Xilinx devices after 1 year.
>
>The vendor-independent FPGA design toolset is dead.

stuff deleted

>3.  It could be that MINC is the big (dark-horse) winner
>in this, if their design databases are device-independent.
>Any comments on this from MINC users?

Two threads here :-
1) MINC do not currently supply FPGA place and route tools, they do provide front-end
synthesis for the likes of XILINX, ACTEL etc..
They do supply CPLD fitters where possible. In cases such as Lattice CPLD's you will
also need the Lattice fitter (MINC were not allowed to develop their own fitter).
They may eventualy reverse engineer these parts, who knows ?

2) Word has it that AMD is stopping development of its own fitters, placing all future
development in the hands of MINC. How this will effect PALASM users I don't know.

T.H.

And no, I am not on MINC's payroll. Just a humble user.







Article: 996
Subject: FS: ABEL book + software $35
From: mstan@cax.ecs.umass.edu (Mircea R Stan)
Date: 10 Apr 1995 16:48:18 GMT
Links: << >>  << T >>  << A >>
"Digital Design using ABEL" by D. Pellerin, M. Holley, 
Prentice-Hall, 322 pages, 1994, hardbound, new, 
includes student version (2 disks) of ABEL 5.03 for DOS.

Thanks for your attention,
				Mircea

P.S. not for ABEL haters :)
-- 
Mircea R. Stan		|	"Without immortality the whole world would 
UMass, ECE Dept.	|	be nonsense, all of creation an absurdity."
Amherst, MA 01003	|					Karl F. Gauss


Article: 997
Subject: journal suggestions
From: sds@cardinal.cs.wustl.edu (Stephen D. Scott)
Date: 11 Apr 1995 09:48:52 -0500
Links: << >>  << T >>  << A >>

Last February, my colleagues and I submitted our paper ``HGA: A
Hardware-Based Genetic Algorithm'' to the 1995 ACM Third International
Symposium on Field-Programmable Gate Arrays.  In this work we
implemented a small genetic algorithm on reprogrammable Xilinx FPGAs.
We are now looking for a journal to which we will submit a more
detailed version of the paper.  Can you suggest any journals that would
be appropriate?

Thanks in advance,
Steve Scott

--
Steve Scott                                          sds@cs.wustl.edu
Department of Computer Science                        505 Jolley Hall
Washington University, Campus Box 1045          phone: (314) 935-7526
One Brookings Drive                               fax: (314) 935-7302
St. Louis, MO  63130-4899           URL: http://www.cs.wustl.edu/~sds


Article: 998
Subject: Re: Neocad merges with Xilinx
From: wolf@aur.alcatel.com (William J. Wolf)
Date: 11 Apr 1995 15:28:37 GMT
Links: << >>  << T >>  << A >>
In article kio@fnnews.fnal.gov, dh@fncrd7.fnal.gov (don husby) writes:
>thomrscott@aol.com (ThomRScott) writes:
>2) [Can AT&T resell multi-vendor Neocad?]

Good question.  Or anyone else they cut a deal with in the starving 
start-up days.  Of course, how would you like to pick up place & route 
code and support it when all of the team is on a competitor's side.  
Good luck!

>3) I don't know much about anti-trust laws, but it seems like this is 
>the sort of situation where you would want one:  Xilinx eliminates a 
>competitor (Neocad), deals strong blows to three others, and sets the 
>market back by eliminating useful tool (chip-independent design capabiliy).

A. Slick move.  Maybe we should all buy their stock.

B. Lets see now.  Xilinx vs AT&T, Motorola, etc.  Sounds like David vs 
   Goliath to me.  OK for AT&T to buy up multi-billion$ cellular companies 
   etc but not OK for Xilinx to buy little ol' NeoCAD?  Would AT&T like to 
   rev up anti-trust momentum in the country?  Ha!  

---
- Bill Wolf, Raleigh NC
- My opinions, NOT my employer's




Article: 999
Subject: Re: Xilinx simulation models for synopsys..
From: jak@interlan.Interlan.COM (Jeff koehler x221)
Date: Tue, 11 Apr 1995 18:18:23 GMT
Links: << >>  << T >>  << A >>
      Simulation of Xilinx XC4000 after creating XNF files?

      Here's the methods I know of:

		1) LMC / Synopsys models for the Xilinx parts, which will
		   take your XNF files and model them for you -- including
		   timing.  We haven't actually used LMC Xilinx models, 
		   but their PALs worked the same way.

		   LMC licenses are about $12k+ for a site license, 1 copy.
		   It will also include HUNDREDS of other parts; parhaps you
		   can work a different deal if you ONLY need Xilinx.

		   These are available for most of the major simulators.

		2) Get a timing backannotator, such VBAK/Xilinx from Top
		   Down Design of Nashua, New Hampshire.
		   603-888-8811

		   Top-Down's product works with Model Technology, including
		   the Mentor version of it.  Of course, I haven't tried this
		   either -- but its a pointer.  The brocure I have says it
		   "a library of VHDL primitives corresponding to XNF 
		    primitives".

						Jak

V--------------------------------V------------------------------------------V
 Jeff Koehler  jak@interlan.com  |      working on my latest Pale Ale recipe
 MTS III (great title, eh?)      |       'cuz Bud just ain't doin it for me.
 Racal-Datacom, Boxboro, MA, USA |    




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