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
2017JanFebMarApr2017

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 1200

Article: 1200
Subject: Re: Overheating (was Re: Compression algo's for FPGA's)
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 12 May 1995 17:18:16 GMT
Links: << >>  << T >>  << A >>
In article <3ouo9b$bsu@calum.csclub.uwaterloo.ca> pchong@calum.csclub.uwaterloo.ca (Phil Chong) writes:
>
>This brings up a concern I have...As I understand it, turning the CRC on
>for the Xilinx 4000 series simply sets a few bits in the bitstream, so that
>when the 4000 reads it, it says, "Aha!  I have to check the CRC!" and if
>the following bitstream fails the CRC check, it resets.  Otherwise,
>the default is not to verify the CRC and accept the bitstream completely.
>
>Now, say a corrupted bitstream did *not* have the CRC "check on" bits set;
>i.e. the corruption mangled these bits.  The FPGA would then ignore the
>CRC and download the bad bitstream.
>
>Is this correct?  Doesn't it seem a bit silly to have a disabled CRC as
>a default?  (Or for that matter, any sort of disabled CRC option at all?
>I mean, the various framing bits in the bitstream are fairly useless
>anyways, why not use them for some sort of CRC/checksum?)
>
>
>Phil

The default for the software is to include the CRC in the bitstream,
4 bits per frame, 13 bits in the last frame. When the chip detects a
CRC error, it stops configuring, and asserts the error line. If you
disable the CRC (a bit that occurs early in the bitstream ), then
the position in the bitstream that would normally contain the CRC, must
instead contain a constant ( I think it is 0110 ). Because of the need
(and checking) of this constant, if the CRC on/off bit happened to get
flipped, you would still catch the error as the CRC is unlikely to always
be this constant for every frame :-)

Ref: " Patent 5321704, Error detection structure and method using
       partial polynomial check. C. Erickson & P. Freidin"

All the best
	Philip Freidin  




Article: 1201
Subject: Re: Overheating (was Re: Compression algo's for FPGA's)
From: hutch@timp.byu.edu (Brad Hutchings)
Date: 12 May 95 14:23:57
Links: << >>  << T >>  << A >>
>>>>> On 12 May 1995 16:27:34 GMT, billms@corp.mot.com (Bill Mangione-Smith) said:
BS> The second issue is on chip faults.  It would be nice if a device could 
BS> not be configured in a way that would burn it up, under the condition that
BS> it isn't connected to anything but power, ground, and the configuration 
BS> system.  From the discussion, I was assuming this does in fact show up as
BS> a problem.  So is my error in reading the posts (i.e. it doesn't happen)
BS> or in misunderstanding the flexibility needed on chip, which requires you
BS> to have the ability to toast your parts.

Well, I'm sure that others will probably see other possible failure
modes, and maybe I missed the point, but here goes anyway.  Lets
consider the example where there is just the FPGA, some electrons and
the configuration system. It seems to me that there is always the
potential for damage if multiple sources can drive a given *internal*
wire.  For example, given the way that some FPGAs currently implement
tri-state busses, there is always a possibility of more than one
tri-state buffer driving a given wire. That is, the FPGA device
itself cannot guard against this happening and it is up the designer
to guarantee that his circuit does not ever simultaneously enable
two or more tri-state drivers that are connected to the same wire.
It is possible to implement a tri-state bus system on the chip
that will not allow bus contention but I suspect that it would be
too inflexible.

However, if there is no wire sharing going on, then it is possible to
guarantee that a design does not have any wire conflicts. For example,
a multiplexer-based architecture cannot have wire conflicts and it
should be possible to guarantee that the design is safe just by
looking at the bitstream. At the last FCCM, the folks from HP
presented the Teramac (which is a very interesting system, BTW).
Teramac is a very large, one-of-a-kind system that the HP people
wanted to make sure and protect. So, in conjuction with their system,
they wrote a piece of software called TMID . I quote from their paper:
"This program TMID (pronounced timid) short for Three Mile Island
Defense, ensures that bugs in a user design will not physically damage
the hardware.  TMID verifies consistency between chips as well as
within chips." HP refers to this as meltdown protection. I am pretty
sure that the HP chip is multiplexer-based. When I saw pictures of the
Teramac, I could see why they wrote TMID. I could see no possible way
to get your fingers in there :-). TMID also makes it possible to use
both hands when you are typing (I couldn't resist :-).

So to answer Bill's question regarding a reasonable level of
flexibility versus the ability to toast your parts, if you don't need
to share wires, then you can potentially verify the design at the
bitstream level. No doubt there are other considerations, but you get
the idea.

BS>    general systems, though.  GigaOp's approach does not add that much in
BS>    the way of cost, given the cost of everything else. 

BS> Thats the worlds apart issue.  I'm used to embedded systems where $7
BS> dollars in parts and 1/2 sq inch on the board is incredibly expensive.
BS> We'd like to apply FPGA technology to a few problems in this market, and
BS> the cost of that functionality is likely to drop sufficiently to make
BS> this possible sometime in the near future.

I certainly agree with Bill when it comes to embedded systems.
However, the cost of the heat sensing capability is barely noise
compared to the cost of everything else in the GigaOps board. In
embedded applications, I would assume that all of the configurations
would be pre-determined and the operation of the system could be
pretty much verified before shipping. Here, heat sensing may be
overkill.  Now, if your embedded application will be generating
bitstreams internally (now, that is some embedded application :-),
then you will want to be much more careful. However, in this scenario,
you still are much safer, because the only source of bitstreams is
completely under your control.  The meltdown problems discussed here
become significant when the bitstreams come from an external source,
say a customer.



--
            Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu 
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
                       Reconfigurable Logic Laboratory



Article: 1202
Subject: Re: Overheating (was Re: Compression algo's for FPGA's)
From: hutch@timp.byu.edu (Brad Hutchings)
Date: 12 May 95 17:24:05
Links: << >>  << T >>  << A >>
>>>>> On 12 May 1995 16:27:34 GMT, billms@corp.mot.com (Bill Mangione-Smith) said:
BS> The second issue is on chip faults.  It would be nice if a device could 
BS> not be configured in a way that would burn it up, under the condition that
BS> it isn't connected to anything but power, ground, and the configuration 
BS> system.  From the discussion, I was assuming this does in fact show up as
BS> a problem.  So is my error in reading the posts (i.e. it doesn't happen)
BS> or in misunderstanding the flexibility needed on chip, which requires you
BS> to have the ability to toast your parts.

Well, I'm sure that others will probably see other possible failure
modes, and maybe I missed the point, but here goes anyway.  Lets
consider the example where there is just the FPGA, some electrons and
the configuration system. It seems to me that there is always the
potential for damage if multiple sources can drive a given *internal*
wire.  For example, given the way that some FPGAs currently implement
tri-state busses, there is always a possibility of more than one
tri-state buffer driving a given wire. That is, the FPGA device
itself cannot guard against this happening and it is up the designer
to guarantee that his circuit does not ever simultaneously enable
two or more tri-state drivers that are connected to the same wire.
It is possible to implement a tri-state bus system on the chip
that will not allow bus contention but I suspect that it would be
too inflexible.

However, if there is no wire sharing going on, then it is possible to
guarantee that a design does not have any wire conflicts. For example,
a multiplexer-based architecture cannot have wire conflicts and it
should be possible to guarantee that the design is safe just by
looking at the bitstream. At the last FCCM, the folks from HP
presented the Teramac (which is a very interesting system, BTW).
Teramac is a very large, one-of-a-kind system that the HP people
wanted to make sure and protect. So, in conjuction with their system,
they wrote a piece of software called TMID . I quote from their paper:
"This program TMID (pronounced timid) short for Three Mile Island
Defense, ensures that bugs in a user design will not physically damage
the hardware.  TMID verifies consistency between chips as well as
within chips." HP refers to this as meltdown protection. I am pretty
sure that the HP chip is multiplexer-based. When I saw pictures of the
Teramac, I could see why they wrote TMID. I could see no possible way
to get your fingers in there :-). TMID also makes it possible to use
both hands when you are typing (I couldn't resist :-).

So to answer Bill's question regarding a reasonable level of
flexibility versus the ability to toast your parts, if you don't need
to share wires, then you can potentially verify the design at the
bitstream level. No doubt there are other considerations, but you get
the idea.

BS>    general systems, though.  GigaOp's approach does not add that much in
BS>    the way of cost, given the cost of everything else. 

BS> Thats the worlds apart issue.  I'm used to embedded systems where $7
BS> dollars in parts and 1/2 sq inch on the board is incredibly expensive.
BS> We'd like to apply FPGA technology to a few problems in this market, and
BS> the cost of that functionality is likely to drop sufficiently to make
BS> this possible sometime in the near future.

I certainly agree with Bill when it comes to embedded systems.
However, the cost of the heat sensing capability is barely noise
compared to the cost of everything else in the GigaOps board. In
embedded applications, I would assume that all of the configurations
would be pre-determined and the operation of the system could be
pretty much verified before shipping. Here, heat sensing may be
overkill.  Now, if your embedded application will be generating
bitstreams internally (now, that is some embedded application :-),
then you will want to be much more careful. However, in this scenario,
you still are much safer, because the only source of bitstreams is
completely under your control.  The meltdown problems discussed here
become significant when the bitstreams come from an external source,
say a customer.



--
            Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu 
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
                       Reconfigurable Logic Laboratory



Article: 1203
Subject: GateField 100K FPGA
From: dann@netcom.com (Dan Nenni)
Date: Sat, 13 May 1995 04:38:39 GMT
Links: << >>  << T >>  << A >>

Does anybody have information on the new high density FPGA's announced
by GateField????????

Any opinions??????

D.A.N.






Article: 1204
Subject: Re: Overheating (was Re: Compression algo's for FPGA's)
From: mtmason@ix.netcom.com (martin mason)
Date: 13 May 1995 07:07:07 GMT
Links: << >>  << T >>  << A >>
See comments attached:

In <HUTCH.95May12172405@timp.byu.edu> hutch@timp.byu.edu (Brad
Hutchings) writes: 

Stuff deleted...

>
>Well, I'm sure that others will probably see other possible failure
>modes, and maybe I missed the point, but here goes anyway.  Lets
>consider the example where there is just the FPGA, some electrons and
>the configuration system. It seems to me that there is always the
>potential for damage if multiple sources can drive a given *internal*
>wire.  For example, given the way that some FPGAs currently implement
>tri-state busses, there is always a possibility of more than one
>tri-state buffer driving a given wire. That is, the FPGA device
>itself cannot guard against this happening and it is up the designer
>to guarantee that his circuit does not ever simultaneously enable
>two or more tri-state drivers that are connected to the same wire.
>It is possible to implement a tri-state bus system on the chip
>that will not allow bus contention but I suspect that it would be
>too inflexible.

This is absolutely true - The onnus is on the system designer to ensure
(just as in an ASIC) that the design is 'correct' - particularly if
tri-states are being used on chip.


>
>However, if there is no wire sharing going on, then it is possible to
>guarantee that a design does not have any wire conflicts. For example,
>a multiplexer-based architecture cannot have wire conflicts and it
>should be possible to guarantee that the design is safe just by
>looking at the bitstream.

Atmel FPGA bitstream generation s/w checks for just such situations and
will error if an illegal bitstream state is detected.  This is an
additional check beyond the 'correct by construction' design
methodology.

Stuff about HP deleted...
>
>So to answer Bill's question regarding a reasonable level of
>flexibility versus the ability to toast your parts, if you don't need
>to share wires, then you can potentially verify the design at the
>bitstream level. No doubt there are other considerations, but you get
>the idea.

Bitstreams are checked for 'checkable' electrical design violations in
the Atmel s/w system but as you point out that doesn't stop a design
engineer from causing tri-state related contentions in the part or
system related bus contentions.

This thread origionally started with a question about 'compressing'
FPGA bitstreams.  In order to safely compress a bitstream you need to
either 

1. Know the bitstream format for the part you are writing to and expand
the bitstream during download using a uP - difficult to do.

2.  Use a partially reconfigurable FPGA (such as the AT6000 series from
Atmel) that allows you to directly address core cell locations.  Atmel
has s/w support in their development system for bitstream compression
which can lead to greatly reduced bitstream download files.  This has
several benifits :
    a) Its a must for partialy reconfigurable systems to allow existing
logic to continue working unhindered.
    b) It reduces the non-volatile memory requirement for storing the
bitstream file dramatically (as much as 80% in some cases).
    c) It dramatically speed up configuration time (200ns per core cell
in the AT6000 series architechture).
    d) It makes in-system partial re-configuration viable.

In a seperate thread there have been questions regarding multipliers :

       Atmel s/w tools have a parameterizable Macro Generator that
creates a hard layout (optimised for the architechture), schematic,
symbol, simulation model, and VHDL/Verilog place holder for various
multiplier structures as well as 30+ other commonly used bit-sliced
system macros such as adders/comparators/counters/rom/ram/shift
registers etc. etc..  Each component is automatically generated in
about 5 mins. via an easy to use 'windows like' selection page and
works with most common PC and workstation CAE front ends.

    To get further details on partial reconfiguration (CacheLogic FPGAs
(tm)) or macro generators -  E-mail me at martin@atmel.com including
your snail mail address.

 




Article: 1205
Subject: Re: How to choose an FPGA vendor
From: sevans@svpal.svpal.org (Scott C. Evans)
Date: 13 May 1995 15:22:21 GMT
Links: << >>  << T >>  << A >>
RHPerez (rhperez@aol.com) wrote:
: On the multipliers: Can you use bit-serial, and use a high-speed clock?

: That's the only way I think you can get multipliers into an FPGA, without
: using up all your real-estate.

The Atmel FPGA can do a 8x8 multiplier which uses up an area of 24x15 
cells.  On the 5000 gate part 56x56 you still have plenty of real-estate 
for many useful functions.  It runs about 10 MHz.  If you want to speed 
things up you can take advantage of the registers on the part to add in 
pipelining.  The same multiplier then uses an area of 38x27, still 
leaving room for useful functions but now runs at about 45 MHz.

The 10,000 gate part is an array of 80x80 cells.  You can fit a 16x16 
pipelined multiplier on that with some room (not a lot) as its dimensions 
are 79x55 and it runs at about 30 MHz.

The above functions and any combination of number of inputs can be easily 
created and the user provided with the above statistics on them using the 
macro generators that are a part of the basic layout system.

I do work for Atmel so I am advertising here as well as providing the 
information requested.  You may also want to look at our other arithmetic 
functions which are quite efficient on the array.

Scott Evans
scott@atmel.com


Article: 1206
Subject: Re: Looking for a few good web sites.
From: ninapint@ix.netcom.com (Nina Pinto)
Date: 13 May 1995 16:32:05 GMT
Links: << >>  << T >>  << A >>
In <3o8srb$45r@newshound.uidaho.edu> lharold@mrc.uidaho.edu (Len Harold) 
writes: 

>
>It has been a while since I have posted and I know more Web Sites have
>appeared, so...
>
>I have put together a collection of links to VLSI related WWW Servers 
at:
>
>  <URL:http://www.mrc.uidaho.edu/vlsi/vlsi.html>
>
>an I am looking for Web Servers that are directly related to VLSI to 
add
>to the list.  There is also a FPGA page at:
>
>  <URL:http://www.mrc.uidaho.edu/fpga/fpga.html>
>
>So if you know of any sites that I am missing on these lists, let me 
know.
>
>Thanks,
>Len Harold
>--
> 
_______________________________________________________________________ 
>|      __    ___    ___  _______    _____                              
 | 
>|    /|  |  /\  \  /|  \|\   _   \/\   __\       Len Harold            
 | 
>|   | |  |  \ \   - |   \ \  \_\ /_ \  \_/                             
 | 
>|   | |   \  \ \  \ _|\  \ \   _   \ \  \___     Phone: 208-885-7034   
 |
>|   | |    \  \ \__\/\ \__\ \__\ \__\ \_____\    Fax:   208-885-6840   
 | 
>|   | |*    |  \/__/  \/__/\/__/\/__/\/_____/    Internet: 	        
| 
>|   |/\     |/\                                    lharold@uidaho.edu  
 | 
>|    \/        \_/\     University of Idaho                            
 |
>|    /|            |    Microelectronics Research Center               
 |
>|   | |            |    NASA Space Engineering Research                
 |
>|   | |____________|    Center for VLSI System Design                  
 |
>|   |/____________/     WWW[URL]: http://www.mrc.uidaho.edu/           
 |
>|______________________________________________________________________
_| 
>

Here's our updates to our list of WWW sites relating to embedded design,
CPU's, real-time, software-engineering and the like:

--FAQ Roadmap: Embedded Systems Internet (v. 3.1)--
Free Internet Resource -- Info on IC's, WWW sites,
real-time, robotics, software engineering, etc. --
----Info On How To Obtain Full Version At End ----

  ===============  ============
  Excerpts of new WWW resources
  ===============  ============

-- 8031 Information
http://www.panix.com/stimpson/micro.html
---:Brief information on 8031/8051.

-- Artificial Intelligence -- Virtual Library
http://www.comlab.ox.ac.uk/archive/comp/ai.html
---:Virtual Library, Artificial Intelligence.

-- Communications and Telecommunications -- Virtual Library
http://www.analysys.co.uk/commslib.htm
---:Virtual Library, Communications and Telecommunications.
Categories, hot links, etc.

-- Compilers List, Free -- By Categories
http://cuiwww.unige.ch/~scg/FreeComp.new/fc/categorie.list.h
tml
---:Excellent list by category such as language as well as a
list of assemblers, by architecture (8051, 68K, etc.).

-- CPU Information -- WWW Personal Computing and Emulation
Home Page
http://www.cs.umd.edu/users/fms/comp
---:Excellent WWW page of chip information, PC information
with links to relevant FAQ's at Ohio State, ftp.funet.fi as
well as some text-based reports such as a brief history of
CPU's.

-- CPU Information -- Aad Offermann's Chip List
http://einstein.et.tudelft.nl/
---:Aad Offermann's chip list comparing different CPU's.

-- CPU Information -- Actual Size Processor Page
http://www.contrib.andrew.cmu.edu/usr/cs7z/PowerPC2.html
---:Pictures of microcontrollers and microprocessors, actual
size.

-- CPU Information -- Chip Directory
http://www.xs4all.nl/~ganswijk/chipdir
---:Chip directory, sorted by numerical device number, plus
index of chip manufacturers.

-- CPU Information -- University of Wisconsin's Computer
Architecture Page
http://www.cs.wisc.edu/~arch/www
---:Computer architecture page, lots of links to University
projects in computer architecture.

-- Engineering Virtual Library
http://epims1.gsfc.nasa.gov/engineering/engineering.html
---:Sections on electrical engineering, control engineering,
software engineering, etc.

-- Engineering, Virtual Library - Industrial
http://isye.gatech.edu/www-ie/
---:Very sparse listing of resources and information.

-- Institutions -- Association for Computing Machinery
http://info.acm.org
---:

-- Institutions -- Center for Compound Semiconductor
Microelectronics
http://www.ccsm.uiuc.edu/ccsm/
---:CCSM research focuses on science and technology
necessary to fabricate optoelectronic integrated circuits.

-- Institutions -- Institute for System Design Technology
http:borneo.gmd.de
---:The Institute specializes in the design of complex
embedded systems.

-- Internet Connections for Engineering
http://www.englib.cornell.edu/ice/ice-index.html
---:Links, category index, etc., to engineering sites around
the Net.

-- Lexicon of Semiconductor Terms -- Harris Corp.
http://rel.semi.harris.com/docs/lexicon/preface.html
---:Harris has provided a large glossary of terms and
definitions.

-- Logic Programming -- Virtual Library
http://www.comlab.ox.ac.uk/archive/logic-prog.html
---:Lists of resources, information on the subject.

-- Microprocessor Instruction Set Cards
http://www.comlab.ox.ac.uk/archive/cards.html
---:List of microprocessor, assembler, programming cards.

-- Mobile and Wireless Computing
http://snapple.cs.washington.edu:600/mobile/mobile_www.html
---:Conferences, projects, labs, groups, hotlinks to
resources on the subject.

-- Real-Time -- Harmony Realtime Operating System Project
http://wwwsel.iit.nrc.ca/harmony.html
---:

-- Real-Time -- IEEE-CS Technical Committee on Real-Time
Systems
http://cs-www.bu.edu/pub/ieee-rts/Home.html
---:Excellent pointers to real-time information at
Universities, archives, etc.

-- Real-Time -- IPTES, Incremental Prototyping Technology
for Embedded real-time Systems
http://hermes.ifad.dk/projects/iptes.htm/
---:

-- Real-Time -- Real-Time Computing, Univ. of Maryland
http://www.cs.umd.edu/projects/realtime/index.html
---:TimeWare Project on real-time software.

-- Real-Time -- Real-Time Systems, Univ. of Massachusetts
http://era.cs-umass.edu/
---:The Spring Project

-- Real-Time -- Real-Time Computing, Univ. of Michigan
http://www.eecs.umich.edu/RTCL/
---:

-- Real-Time -- Selected Papers
http://www.cs.unc.edu/dirt/real-time.html
---:Excellent bibliography with summaries of Real-time
papers and full text in postscript format.

-- Robotics -- Archives of USENET comp.robotics
FTP: wilma.cs.brown.edu
---: /pub/comp.robotics

-- Software Engineering -- Virtual Library
http://rbsc.fsc.nasa.gov/virt-lib/soft-eng.html
http://ricis.cl.uh.edu/virt-lib/soft-eng.html
---:Virtual Library, Software Engineering.  Category-
oriented index to resources both on the Net and off.

-- Software Engineering -- STING, Software Technology
Interest Group
http://dxsting.cern.ch/sting/intro.html
---:Software engineering resources from CERN.

===============================================
--Available from CERA Research
--WWW: http://www.cera.com
--FTP: ftp.best.com /pub/cera as embedded_
--FTP: ftp.netcom.com /pub/ce/cera as embedded_
--EMAIL: cera@netcom.com SEND EMBFAQ in SUBJECT LINE



Article: 1207
Subject: FLEXlogic opinions?
From: roger@coelacanth.com (Roger Williams)
Date: 14 May 1995 17:44:42 GMT
Links: << >>  << T >>  << A >>
>From anyone who's used 'em, opinions on (was Intel, now Altera)
FLEXlogic parts?

On a new digitiser design for one of our larger clients, the PC AT
(perhaps PCI on the next rev) interface requirements also include a
small amount (512 bytes or so) of FIFO.  For the interface, these
parts look like a good alternative to the FLEX 8000s we're using for
our timing generators, etc., with SRAM so easy to configure.  For this
customer, we're stuck with Altera, and we need in-circuit
programmability (we can't socket the parts).

How bad are their routing problems?  Is development in an HDL
feasible?  Any criticisms welcome!

-- 
Roger Williams
Coelacanth Engineering  |  Numeric stability is probably not all
Middleborough, Mass     |  that important when you're guessing...


Article: 1208
Subject: affordable fpga design tools?
From: stephens@nic.cerf.net (Robert Stephens)
Date: 14 May 1995 19:51:55 GMT
Links: << >>  << T >>  << A >>
I am interested in migrating some of my 22v10 level
pld designs to fpgas. Is there a public domain, shareware
or *cheap* commercial compiler/fitter available? Even'
a full featured demo would be a help. I hate to spend
Kbucks just to evaluate the potential benifits of consolidation.
                                         ^e
Cypress is offering a great deal on Warp2, but it only
supports plds and cplds. The Warp3 (which does support fpgas)
pricing isn't mentioned so I assume it is exorbitant.

                          TIA
                              Bob S.


-- 
Bob Stephens                           
stephens@cerf.net   | "Just machines that make big decisions
310-540-3525 vox    |  programmed by fellas with compassion and vision"
310-540-8380 fax    |                           - Donald Fagen


Article: 1209
Subject: Re: FLEXlogic opinions?
From: crm182c@bmers245.bnr.ca (Hing-Fai Lee)
Date: 14 May 1995 20:27:14 GMT
Links: << >>  << T >>  << A >>
In article <3p5c3u$5aq@bighorn.terra.net>,
Roger Williams <roger@coelacanth.com> wrote:
>
>How bad are their routing problems?  Is development in an HDL
>feasible?  Any criticisms welcome!
>
I am using Flex (now Flash) EPF81188A-3 in our design. The path I
picked is Verilog hdl, Synopsys and finally Maxplus2. The main clock
frequency is 84 MHz and there are also 38 and 2 MHz. The chip is at 70%
utilization and uses just over 60 I/Os.

Verilog hdl is feasible but you'll have to describe the design as if
you are entering schematic. Synopsys doesn't play a big role in
determining how fast the circuit will run since the hdl is really NOT
modelling the circuit's behavior.

The router in Maxplus2 is fairly capable of giving you the highest
speed if you set synthesis style to FAST. When designing at high speed,
don't try to fix your pin out. I notice a variation in delay of about
3ns when the pin out is fixed. If you don't have 3 ns of margin
everywhere, you'll have to let Maxplus2 determine the pinout for you.

The tool comes with a static timing analyzer which you can use to
determine your circuit's timing performance. Unless you have a fully
synchronous design, you'll have to analyze you circuit section by
section to avoid false paths.  I didn't do much timing simulation since
the static timing analyzer told me all I wanted to know.

A lot of the features in Maxplus2 are not obvious. I used to call the
hotline several times a day. The application engineers are very good but
those behind the scene are even better, ie if you know who to call.

Finally, unless you really have to follow the Flex design with a gate
array upgrade, you'll live longer and happier if use the good ole
schematic entry method. Good luck in your design. Hing-Fai

-------------------------------------------------------------
- Name:  Hing-Fai Lee   Address: Bell-Northern Research     -
- Phone: 613-765-2097            Dept 1D15, Mail Stop 170   -
- FAX:   613-763-2108            P.O. Box 3511, Station C   -
- Email: crm182c@bnr.ca          Ottawa, Canada, K1Y 4H7    -
-------------------------------------------------------------
- Disclaimer: I do not speak for BNR nor BNR speaks for me. -
-------------------------------------------------------------


Article: 1210
Subject: Re: FLEXlogic opinions?
From: north@netcom.com (Don North)
Date: Sun, 14 May 1995 22:33:51 GMT
Links: << >>  << T >>  << A >>
In article <3p5c3u$5aq@bighorn.terra.net> roger@coelacanth.com (Roger Williams) writes:
>From anyone who's used 'em, opinions on (was Intel, now Altera)
>FLEXlogic parts?
>
>On a new digitiser design for one of our larger clients, the PC AT
>(perhaps PCI on the next rev) interface requirements also include a
>small amount (512 bytes or so) of FIFO.  For the interface, these
>parts look like a good alternative to the FLEX 8000s we're using for
>our timing generators, etc., with SRAM so easy to configure.  For this
>customer, we're stuck with Altera, and we need in-circuit
>programmability (we can't socket the parts).
>
>How bad are their routing problems?  Is development in an HDL
>feasible?  Any criticisms welcome!

We've used the Verilog+Synopsys+MaxPlusII route for a fair number of Altera
based designs, both on the MAX7K and FLEX8K architectures. In general the
design path works very well, getting reasonably good speed and density out
of the various parts we have targeted. The significant issue with the Altera
architecture(s) is the more limited internal interconnect (the PIA of the 7K
and the LAB/row/cols of the 8K) - depending upon pin assignment, you may not
be able to achieve a 'fit' (ie, placement) that routes because of local
routing resource congestion. If you have a pin assignment that is cast in
concrete for a design this can sometimes cause a problem. When the MaxPlus2
tool is free to choose a pinout, a fit usually be achieved. The problem arises
when you do a design, set the pinout, build the board, and then decide to
change/enhance/etc the logic, and you can't achieve a fit with the current
pinout. You then need to dive into the bowels of the layout tool and/or
rewrite the logic to reduce the local routing congestion; this is not always
easy (or possible) to do. This has nothing to do with HDL-based design per-se,
but is just a characteristic of the Altera routing architectures.
-- 

            -------------------------------------------------
            --- Don North --- north@netcom.com --- KD6JTT ---
 ------------------------------------------------------------------------
{ When  not  hanging  out  here  I'm  working at Apple, and any opinions }
{ expressed  are  my  own  personal view, and should not be construed to }
{ represent the position, official or otherwise, of Apple Computer, Inc. }
 ------------------------------------------------------------------------


Article: 1211
Subject: Re: FLEXlogic opinions?
From: devb@elvis.vnet.net (David Van den Bout)
Date: 15 May 1995 09:12:10 -0500
Links: << >>  << T >>  << A >>
In article <3p5c3u$5aq@bighorn.terra.net>,
Roger Williams <roger@coelacanth.com> wrote:
>From anyone who's used 'em, opinions on (was Intel, now Altera)
>FLEXlogic parts?
>
>On a new digitiser design for one of our larger clients, the PC AT
>(perhaps PCI on the next rev) interface requirements also include a
>small amount (512 bytes or so) of FIFO.  For the interface, these
>parts look like a good alternative to the FLEX 8000s we're using for
>our timing generators, etc., with SRAM so easy to configure.  For this
>customer, we're stuck with Altera, and we need in-circuit
>programmability (we can't socket the parts).
>
>How bad are their routing problems?  Is development in an HDL
>feasible?  Any criticisms welcome!

Roger:
The FLEXlogic parts should work well for your interface.  The RAMs
are useful for FIFOs and they can be programmed in circuit using their
JTAG interface.  Routing problems are not very common since they use
a large global interconnection matrix to route between 22V10 blocks
of macrocells.  The main problem you get is having enough product
terms feeding your macrocells.  This is also rare unless your logic
gets pretty complex and you have to also fix pins.  I develop using the
free PLDshell tool which lets you enter logic equations, truth-tables,
and state-transition descriptions.  ALTERA is going to
put support for the FLEXlogic series in their MAXPLUS tools, but I
haven't seen it so far (haven't really looked).  I can provide complete
design examples for things like FIFOs or a 4-bit microcomputer if you
need them.  Good luck!


-- 

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


Article: 1212
Subject: Re: FLEXlogic opinions?
From: roger@coelacanth.com (Roger Williams)
Date: 16 May 1995 04:11:08 GMT
Links: << >>  << T >>  << A >>
   I am using Flex (now Flash) EPF81188A-3 in our design...

Is the FLASHlogic family (the EPX740/780/8160) *really* related to the
FLEX 8K series?  My Intel information doesn't say anything about
Altera (although Intel *did* make some of the Classic parts).  The
FLASHlogic parts are more CPLD-like, with 4/8/16 configurable function
blocks connected by a global interconnect matrix.  (The unique feature
is that each CFB can be either 24V10 logic or an 128x10 SRAM block--
potentially useful for my FIFO requirements).  I'm using the EPF8282A
elsewhere in this design, and it's finer-grained.

   ... The application engineers are very good but
   those behind the scene are even better, ie if you know who to call.

Well, now that I have your address, I know how to find out... ;-)

   Finally, unless you really have to follow the Flex design with a gate
   array upgrade, you'll live longer and happier if use the good ole
   schematic entry method...

Thanks for the advice!  Guess I'll have to get the Viewlogic
libraries, as the MaxPlus-II schematic editor is pretty Byzantine.
(I *do* wish that Altera would decide if they're in the chip business,
or the software business.)

-- 
Roger Williams
Coelacanth Engineering  |  Numeric stability is probably not all
Middleborough, Mass     |  that important when you're guessing...


Article: 1213
Subject: Re: FLEXlogic opinions?
From: roger@coelacanth.com (Roger Williams)
Date: 16 May 1995 04:12:08 GMT
Links: << >>  << T >>  << A >>
   We've used the Verilog+Synopsys+MaxPlusII route for a fair number of Altera
   based designs, both on the MAX7K and FLEX8K architectures...
   ... The significant issue with the Altera
   architecture(s) is the more limited internal interconnect...

Yeah, this is our experience with the 7K and 8K series, too.  We're
looking at the Verilog/Synopsys tools tools, although we still have to
pin down our long-term in-house tool set strategy...

The FLEXlogic family (the EPX740/780/8160) was acquired from Intel
(don't know if Altera was involved with the design), and is a
FLASH-ROM backed CPLD architecture that looks more like the 7K
(i.e. 4/8/16 configurable function blocks connected by a global
interconnection matrix), except that any of the CFBs can be defined
either as a 24V10 logic block or as 128x10 SRAM.

The SRAM option seems attractive, but this kind of architecture has
the potential for routing problems...  It's also not clear if Altera
regards these parts as orphans--I might end up designing the whole
thing with PALASM (the Intel approach) with no simulation :(

-- 
Roger Williams
Coelacanth Engineering  |  Numeric stability is probably not all
Middleborough, Mass     |  that important when you're guessing...


Article: 1214
Subject: 1000 pin fpga's ?
From: cburns@crl.com (Charlie Burns)
Date: 15 May 1995 21:32:59 -0700
Links: << >>  << T >>  << A >>
At a recent conference I got chance to hold a Aptiv programmable
interconnect chip that had a 32 x 32 pin grid array. I guess
they have a big cross-bar/switch matrix, sram based.

I didn't think much of it then, but now I have a pin-limited
FPGA design that needs lots of i/o's and relatively little
logic (it's a very wide pipeline design with lots of memory
(SRAM) accesses in the stages, hence I would be going on and off
chip all the time).

I wondering if any FPGA vendors have considered building an FPGA
with as many pins and io's as they could fit and filling whatever die
space was left with logic blocks.

I don't know what the pad/bonding diagram would look like for such 
a beast, but the Aptiv people have 1024 pins, why can't we have a
FPGA with 1024 pins?

I suppose I'm just wondering if anyone else feels these constraints
(not logic bound, but io bound) or if my design is really that out
of the ordinary.

Comments?

Charlie


Article: 1215
Subject: PLDShell Plus
From: msnook@armltd.co.uk (Mark Snook)
Date: 16 May 1995 11:57:03 GMT
Links: << >>  << T >>  << A >>
Does anyone know where I can download a copy of PLDShell Plus software
fro Altera FlashLogic parts. This used to be distributed by Intel for
their FlexLogic parts, which were renamed when Altera aquired the
business. I have tried http://www.altera.com but cannot find a
reference to the software, only it's existance.

Mark


Article: 1216
Subject: ---- Re: "Verilog Won & VHDL Lost?" ----
From: jcooley@world.std.com (John Cooley)
Date: Tue, 16 May 1995 17:19:52 GMT
Links: << >>  << T >>  << A >>

 If you need to be totally anonymous when replying to my article of four
 days ago "Verilog Won & VHDL Lost? -- You Be The Judge!" (Friday, May 12th)
 PLEASE still indicate your job, your company, whether you use Verilog or
 VHDL, why, for how long plus whatever opinions/impressions you have of the
 contest or the Verilog/VHDL wars.  I WON'T PUBLISH THIS INFORMATION but will
 use it for statistical reporting of opinions.  That is, you'll see in the
 follow-up article in "Integrated System Design" all sorts of reporting like:

  "X of the ABC based designers and Y of the JKL based designers reported:

     'blah, blah, most adamently blah!   Flimming-flam-flam and for
      blah I think blah.   Flamm  flim flop flooo blah goo blah blah
      flam.  Blah blah floo blah."

 (Please don't take replying anonymously lightly; it's far more powerful to
 reply publically.  So far with every opinion seen, I've found multiple
 people who will publically voice it.  There's just something about having
 engineers silenced by company politics and/or paranoid bosses' dictates that
 bothers me; hence I encourage these people to speak out statistically and
 with anonymity.  But, if you *can* reply openly, *please* do so.)

 To quote the original jury instructions: "in 150 words or less, send your
 thoughts to "jcooley@world.std.com".  Please don't send me "VHDL sucks." or
 "Verilog must die!!!" -- but personal experiences and/or observations that
 add to the discussion.  It's OK to have strong/violent opinions, just back
 them with something more than hot air.  (Since I don't want to be in the
 business of chasing down permissions, my *default* setting is *whatever* you
 send me is completely publishable.  If you wish to send me letters with a
 mix of publishable and non-publishable material CLEARLY indicate which is
 which.)"
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

 P.S.  As always, please DO NOT copy any article back to me -- I *know* why
       you're replying!  :^)

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3349 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: 1217
Subject: Re: 1000 pin fpga's ?
From: mbutts@netcom.com (Mike Butts)
Date: Tue, 16 May 1995 19:58:47 GMT
Links: << >>  << T >>  << A >>
cburns@crl.com (Charlie Burns) writes:

>At a recent conference I got chance to hold a Aptiv programmable
>interconnect chip that had a 32 x 32 pin grid array. I guess
>they have a big cross-bar/switch matrix, sram based.

Actually their name is Aptix, and the FPIC is not actually a
full crossbar, but is an array of I/O pads, each of which has some
metal interconnecting with horizontal and vertical metal lines of
various lengths.  In practice with real designs it may be nearly 100%
routable, but it's not guaranteed non-blocking like a full crossbar
is, and a router must be run.

>I wondering if any FPGA vendors have considered building an FPGA
>with as many pins and io's as they could fit and filling whatever die
>space was left with logic blocks.

>I don't know what the pad/bonding diagram would look like for such 
>a beast, but the Aptiv people have 1024 pins, why can't we have a
>FPGA with 1024 pins?

The Aptix FPIC has a 32-by-32 array of pads on a 40-mil grid.

>I suppose I'm just wondering if anyone else feels these constraints
>(not logic bound, but io bound) or if my design is really that out
>of the ordinary.

In fact, logic emulation applications of FPGAs, or any applications
that involve partitioning a pre-existing design into multiple FPGAs,
frequently run into pin limitations sooner than logic limitations.

Trouble is, the pins are what cost all the money in an FPGA.  The
logic may as well be free.  <Yes, that's a gross generalization, but
at least for any given technology that's basically the case.  In other
words the I/O count is locked to the square of the logic capacity in
most FPGA architectures by the simple fact of perimeter I/O pads.>

A 2-D pad array requires flipchip bonding to the package instead
of the usual wirebonds, which requires an expensive ceramic package with
an exotic socket, and may pose some real challenges to the router
of the PCB it's part of.  So the per-pin cost may be much higher than
an ordinary perimeter-pad wirebonded device.  

Maybe as higher pincounts become more mainstream, flipchip
packaging with BGA pad arrays will become cheaper and more practical
and we'll see FPGAs with more I/Os.

        --Mike Butts, Quickturn (mbutts@qcktrn.com)


-- 
Mike Butts, Portland, Oregon   mbutts@netcom.com



Article: 1218
Subject: Re: Price/Performance
From: sc@vcc.com (Steve Casselman)
Date: Wed, 17 May 1995 01:30:25 GMT
Links: << >>  << T >>  << A >>
I would like to comment on price performance of reconfigurable
computing platforms. One of our customers did some work on our
EVC with 2meg static ram module (~$5500) that I think is well
worth the price. What do you all think?

Steve Casselman

>My current application is aimed mainly at demonstrating the
>applicability of reconfigurable hardware. The target is communication
>applications involving other parts of xxxxxxxx (name removed sc).
>
>The demonstrator is a VHDL compatible eventqueue handler, essintially a
>priority queue with lots of constraints complying to the VHDL
>definition. We run it in a test bench at the moment getting a speedup
>of 6-10 times compared to our fairly simple software version.  In a
>true simulator it will run in parallel with the software virtually
>eliminating event queue handling which can take anything from 50-95% of
>simulation time depending on the logic level of the simulation object
>and the smartness of the simulator programmer.
>
>We will try it out on a swedish simulator MINT and are talking to the
>Cadence people about testing it on one of their simulators. xxxxxxxx is
>a Cadence technology partner.
>


Article: 1219
Subject: Can the X4010 replace a X4003 ?
From: jca@picasso.inescn.pt (Jose Carlos Alves)
Date: Wed, 17 May 1995 13:10:47 GMT
Links: << >>  << T >>  << A >>

Hi,

I've made a card for the PC-AT bus with one X4003 and one
X4010 in daisy chain configuration (the 4003 is first in the chain).
The bitstream is downloaded from the PC bus,
through some logic to decode i/o addrs and generate the
clock and data from the PC port. It worked fine till
I replaced the 4003 by one 4010D. Now the PC crashes when my program
starts sending the configuration bits. I'm using a bit stream generated
for a 4010 (without the 'D'), but as far as i've seen, it is identical
to the 4010D (but what happens to any RAM cell, if they are in the
configuration bitstream ?).

Any ideas about this ?

Thanks for any help

jose'


Article: 1220
Subject: Altera Flex Logic & Other Problems
From: morph@io.org (Ryan Raz)
Date: Wed, 17 May 1995 09:18:11 -0400
Links: << >>  << T >>  << A >>
I am using the Altera flash logic parts which they acquired from
Intel (EPX780QC132-15 Lot L3512294).

I have been trying to use the Intel download software (PENGN) to
configure these parts without any success. The software is unable
to read the proper ID from these parts.

I have checked the signals on the JTAG port when the download software
starts up and found the following sequence.

Reset          - 5 clocks with TMS high.
Run Test/Idle  - 1 clock with TMS low.
Select DR-Scan - 1 clock with TMS high.
Capture-DR     - 1 clock with TMS low.
Shift-DR  - TMS remains low with TDI high.

This results in TDO following TDI.

Has anyone tried using the Intel cable and software with both
Intel and Altera parts?

I have also tried writing my own programming software but didn't
get far since I haven't been able to get a full programming
specification from Altera. Any help Altera?

We have had Altera Flexlogic Download Cable on order for 1.5 months and
still no sign of it.


Here is  list of problems with Altera's development from our VHDL specialist
Gabriel Neufeld.

Re:	Altera development tools

In February 1995, we have purchased MAX+PlusII development 
tool from Altera. The version received was 5.11. 

I have encountered some limitations with this version when 
developing VHDL models, mostly in the area of arithmetical
 operations. Many of these limitations are documented as 
"unsupported features" which were supposed to be
 supported in later versions.

In late april, 1995 we have received an update to
MAX+PlusII - version 5.2, dated February14!!
Why did it take so long to ship it?

Trying to recompile designs which were built and simulated
 with version 5.11, I found out that 5.2 does not support
 tri-state busses. This major bug was acknowledged by Altera
 after discussing the problem with their Technical Support.

Though some of the unsupported features were fixed 
(like aggregates and array aggregates), most of them were not. 
On top of that, I have discovered that some features that are 
claimed as being supported, in fact are not . Here is a list
(refer to Section 3, pages 73-82 of the Altera VHDL book):

1. 	Miscellaneous Operators (7.2.5) : 
    "Supported, except for exponentiation(**)." 
    The only other misc. operator is ABS (absolute value), 
    but in fact this is not supported either.

2. 	Type Conversions (7.3.5) are not supported
   (would be very useful) though it is claimed as being supported.

3.	Exit Statement (8.10). What is the usefulness of this 
	statement if it is not supported in a conditional loop?

4.	Return Statement(8.11).
    "Supported. Return Statements are not allowed within
    Procedure Bodies (functions with multiple outputs - my note)
    or LOOP Statements". 
    In fact they are not supported within IF and CASE Statements as well.

5.	Signal Declarations (4.3.1.2) : 
   "Supported. Array elements must be arrays or single bits." 	
   Multidimensional arrays (e.g. a 2 dimensional array of vectors) 
   are not supported - this is not clear from the above statement.


Anyone know where we can get some other Altera parts? Our suppliers
give two month deliveries. Altera just says go to your suppliers.

   Quant            Part
       10      EPF 8282 ATC 100-4
         2     EPF 81188 ARC 240-4

Where is Altera's support for developers? Lack of support and lack of chips 
has put a very important development program  behind by at least a month
(that is, important to us but evidently not important to Altera)!! Get it 
together Altera,  new development projects by companies like us are your 
future. 

----------------------------------------------------------------- 
 Ryan S. Raz     
 Morphometrix, 120 Adelaide St. E., Unit 2, 
 Toronto, Ontario, Canada M5C 1K9
 Tel: (416)361-6239   Fax: (416)361-3162   Email: morph@io.org
-----------------------------------------------------------------


Article: 1221
Subject: Re: Altera Flex Logic & Other Problems
From: Scott Bierly <bierly@era.com>
Date: Wed, 17 May 1995 17:10:59 GMT
Links: << >>  << T >>  << A >>
In article <TefuvYMQzvkY083yn@io.org> Ryan Raz, morph@io.org writes:

>>I am using the Altera flash logic parts which they acquired from
>Intel (EPX780QC132-15 Lot L3512294).
>
>I have been trying to use the Intel download software (PENGN) to
>configure these parts without any success. The software is unable
>to read the proper ID from these parts.
>
>Has anyone tried using the Intel cable and software with both
>Intel and Altera parts?
>
Yes, I have done this successfully, but with the '8160 parts.  I
currently have 3 Intel parts and 1 Altera part on my board, all daisy
chained and connected back to the cable.

>I have also tried writing my own programming software but didn't
>get far since I haven't been able to get a full programming
>specification from Altera. Any help Altera?

This design also allows programming over a VME bus, by switching in
control signals from a state machine (in place of the cable signals) for
TDI, TMS, and TCK, and essentially just shifting in the TDI and TMS bits
directly from the .BIN file created by jed2jtag.  The clock is generated
locally at about 8 MHz.  My point is, programming is
easily achieved without the download cable through alternate means,
without having to know the intimate details of the JTAG stream.

However, I too would like to know more about the JTAG stream format, so
that we could do more sophistocated things like FLASH reprogramming, JTAG
reset, SRAM readback and other testability/BIT features.  After all,
these are some of the strengths of this product, and Altera should do a
better job of promoting and supporting them.


Article: 1222
Subject: Re: 1000 pin fpga's ?
From: postmaster@lsantist.dfrf.nasa.gov
Date: Wed, 17 May 1995 18:00:58 GMT
Links: << >>  << T >>  << A >>

In article <3p99tr$rp7@crl4.crl.com>, <cburns@crl.com> writes:
> Path: 
cs2.dfrc.nasa.gov!elroy.jpl.nasa.gov!swrinde!gatech!news.sprintlink.net!howland
> From: cburns@crl.com (Charlie Burns)
>
> [clip]
>
> I don't know what the pad/bonding diagram would look like for such 
> a beast, but the Aptiv people have 1024 pins, why can't we have a
> FPGA with 1024 pins?
> 
> I suppose I'm just wondering if anyone else feels these constraints
> (not logic bound, but io bound) or if my design is really that out
> of the ordinary.
> 
> Comments?
> 
> Charlie
> 
Charlie, I'm not sure I understand your concern but I'm curious.
Although I'm not familiar with your design, I have always been able
to partition the larger designs into multiple FPGAs.  If timing 
between multiple FPGAs is an issue, one can duplicate some of the 
logic to run in parallel.

What is it that I'm missing?

--
Lou Santisteban - lsantist@lsantist.dfrf.nasa.gov 




Article: 1223
Subject: Re: Can the X4010 replace a X4003 ?
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 18 May 1995 04:37:12 GMT
Links: << >>  << T >>  << A >>
In article <D8q4M1.2ro@animal.inescn.pt> jca@picasso.inescn.pt (Jose Carlos Alves) writes:
>
>Hi,
>
>I've made a card for the PC-AT bus with one X4003 and one
>X4010 in daisy chain configuration (the 4003 is first in the chain).
>The bitstream is downloaded from the PC bus,
>through some logic to decode i/o addrs and generate the
>clock and data from the PC port. It worked fine till
>I replaced the 4003 by one 4010D. Now the PC crashes when my program
>starts sending the configuration bits. I'm using a bit stream generated
>for a 4010 (without the 'D'), but as far as i've seen, it is identical
>to the 4010D (but what happens to any RAM cell, if they are in the
>configuration bitstream ?).
>
>Any ideas about this ?
>
>Thanks for any help
>
>jose'

More info would help... but if your 4003 -> now a 4010D connects to the PC 
bus for transfering data etc, after it is configured, my guess is that 
you have an error in your design, and the 4010D is configuring, going 
live, and then steps on the bus, killing your system.
It would help to know how far into config you got before your system
crashed. my guess is the chip goes done, and 100 nS later your system
crashes. A simple test would be to change your design so it does nothing 
complex (flash a LED?), but specifically does not use any pins that 
connect to the PC bus. Then load that and scope around. If it doesn't 
crash your system, then my first guess is probably right. I have designed
PC-AT boards that directly talk to the PC bus, and they work fine.
Also: what package was the 4003 and 4010D. The only common footprint
is the PC84 package.

All the best,
		Philip Freidin



Article: 1224
Subject: Re: Altera Flex Logic & Other Problems
From: Sami Sallinen <sjs@varian.fi>
Date: 18 May 1995 06:58:58 GMT
Links: << >>  << T >>  << A >>
I have also used the Intel download cable (actually the schematic that 
was posted to sci.electronics a wile ago) successfully 
with the 780 chips. I have had both altera and intel marked parts but it 
appears to me that at least the 'Altera' parts I have, are exactly the 
same things that just have the Altera logo and other stuff printed / 
painted over the Intel logo. 

It appears to me that your problems might be due to one or both of the 
same problems that I had. 

First I used a portable computer which had a parallel port that was no 
good for this use. This I found out pretty quickly. Later on I spent a 
lot of time because the clock (and other) lines from the cable were not 
properly terminated on the circuit board I was using. Due to excessive 
ringing, the poor 780's were seeing each clock pulse as one or two, and 
the pengn software could not read the id:s of the devices.

When you said that you have been trying to write your own programming 
software, you did not mention whether you wanted to configure the SRAM or 
the EPROM of the devices. The SRAM configuration is pretty easy. You just 
produce a .BIN file with the jed2jtag program, and then feed it out to 
the printer port with the following C-program...

#define PRN_PRT 0x378

#include <stdio.h>
#include <conio.h>

long int vector = 0;


void outdata (int data) { 
  // bits 2 = tck, 1 = tms, 0 = tdo
  // d0 = tck
  // d1 = tms
  // d6 = tdo
  vector++;
  _outp(PRN_PRT, (((data & 1) << 6) | (data & 2)));
  printf("vector ");
  _outp(PRN_PRT, (((data & 1) << 6) | (data & 2) | 1));
  printf("number");  
  _outp(PRN_PRT, (((data & 1) << 6) | (data & 2)));
  printf("  %ld  %d     \r", vector, _inp(0x379));
}

int main (void) {
  int c;
  printf("VDT Framegrabber boot loader v.2.0\n");
  FILE *infile =  fopen("fraemu.bin", "rb");
  if (!infile) {
    printf("\n Could not open FRAEMU.BIN\n");
  }
  while ( (c = fgetc(infile)) != EOF) {
    for (int i = 0; i < 4; i++) {
      outdata(((c >> (i * 2)) & 3));
    }  
  }
  printf("\nFinished.\n");
  fclose(infile);
  return 0;
}

If you want to do the reconfiguration with an embedded processor, its 
pretty easy to implement the same functionality there. The EPROM 
/ EEPROM (8160) configuration is a bit more tricky, and I suggest that 
for that you use the pengn program.

Other than the little programming problems I mentioned above I have found 
the intel / altera parts nice and robust in many ways: The timing is 
pretty predictable. The PLDShell software is robust and easy to use (I 
have had some problems with the simulator when using the CLB:s as SRAM, 
though). The parts are really  impossible to toast by incorrectly 
reconfiguring them. I've misconfigured them in almost all possible ways:
the clock has been ringing, I've had the JTAG pins cross connected, I've 
fed in the wrong .BIN file and other things. Sometimes the chips have got 
too hot to touch after such accidents. I've even placed two chips 
wrong-way in their 84-pin PLCC sockets. (Yes, this is doable with no 
thinking and a little force.) Still I havent burned a single one of them.

Sami Sallinen

System Engineer, Varian-Dosetek

#include <disclaimers.h>





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
2017JanFebMarApr2017

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