Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
>>>>> 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
>>>>> 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: 1203Does anybody have information on the new high density FPGA's announced by GateField???????? Any opinions?????? D.A.N.Article: 1204
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: 1205RHPerez (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.comArticle: 1206
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 LINEArticle: 1207
>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
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: 1209In 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
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: 1211In 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
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
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
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? CharlieArticle: 1215
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. MarkArticle: 1216
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
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: 1218I 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
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
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: 1221In 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
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.govArticle: 1223
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 FreidinArticle: 1224
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:
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