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
Hi Anybody is using JTAG/BIST in boards.I'm new to this and want to know how to use it.Any material/example other than Mic.Smith(ASIC).Article: 53226
Ray Andraka <ray@andraka.com> wrote in message news:<3E67A40F.CC97176B@andraka.com>... > My biggest gripe about the Annapolis stuff is the closed architecture ala microsoft. > Where they don't exactly have a microsoft sized customer base, you would think they would > be a bit more accommodating, especially seeing you already dropped a sizable sum for the > board in the first place. Oh well, I can't vouch for their business model (nor do I > understand it, if this is how they are doing it). Didn't the board also come with NT > drivers? Perhaps those may work out a bit better > > ABloke wrote: > > > Hi Ray, > > > > Thanks for the reply - I forget to check back on this thread. > > > > You would think that they would give them to me. I bought the card a > > couple of years ago, but it only came with Windows 98 drivers, which > > are useless to me. It has been lying around for ages, so I thought I'd > > put it to some use. Unfortunately, Annapolis want to charge nearly > > $700 for the privelege of using it again, so it will just sit around > > here doing nothing because the price is ludicrous. > > Consider where they come from and who their best customers are and for that price you can buy a mil grade hammer! I wonder how many other FPGA boards end up sitting around for lack of suitable open tools that can be used across different vendors. More than a few I bet. We are still at the S100/Cromenco days of FPGA, wonder who the next RC Apple will be?Article: 53227
Hi I would like to know there are any FPGA's where it is possible to controll the current consumption upon the output lines. E.g. to limit the current in some "pins"? -- Best Regards Henrik Douglas Green B.Sc.E.E. R&D, Stage, Studio and Event Lighting Martin Professional A/S Olof Palmes Allé 18 DK-8200 Aarhus N E-mail: Henrik.Green@martin.dk Phone: + 45 87 40 00 00 Direct: + 45 72 15 02 06 Fax.: + 45 87 40 00 10 URL.: http://www.martin.dk/Article: 53228
"Brazil" <a.solinasNOSPAM@tiscali.it> wrote in news:b44hqc$1s0tkk$1@ID-132949.news.dfncis.de: > Dear all, > I would connect an hard-drive to the PCMCIA interface of my board. > Is there anybody that can suggest how to do with a simple fpga? > I know that a Fpga is too much but we would use to do other interfaces > for the board. > Thanks in Advance > Regards Brazil > > > take a look at the compact flash specification: Compact flash support a 'true ide' interface. The main difference between the pcmcia modes and the ide mode is in the data-bus. Ide expects 16 bit data on address 0x0, 8 bits data on the lowest byte lane for address 0x1-0x7. In Pcmcia the two Cs signals are used as byte-enable signals. for the odd addresses, data is usually placed at the upper byte-lane. Regards, JoArticle: 53229
>A latch is transparent during one half cycle of the clock. Now you must >pay attention to signals that might be racing through the latch. >On the other hand, latches can make your system faster, since you can >avoid the worst-case delay in every pipeline stage. There was a style of building hardware that was popular 10-15 years ago. It used latches rather than edge triggered FFs. I never worked with any of that gear so I can't explain it. I think it made sense with the available technology. Probably went faster but took more effort/skill to get right. The magic phrase was two-phase non-overlapping clocks. Are today's tools reasonably good with latches? A while ago I would have said to avoid them because the tools don't really support them. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 53230
Henrik, Xilinx FPGA's has a DRIVE_STRENGTH attribute on most IO standards. This control the drive on e.g. LVTTL from 2mA to 24mA. Hakon "Henrik Douglas Green" <Henrik.Green@martin.dk> wrote in message news:rRX9a.13$mN2.12@news.get2net.dk... > Hi > > I would like to know there are any FPGA's where it is possible to controll > the current consumption upon the output lines. E.g. to limit the current in > some "pins"? > > > -- > Best Regards > > Henrik Douglas Green > B.Sc.E.E. > > R&D, Stage, Studio and Event Lighting > > Martin Professional A/S > Olof Palmes Allé 18 > DK-8200 Aarhus N > > E-mail: Henrik.Green@martin.dk > Phone: + 45 87 40 00 00 > Direct: + 45 72 15 02 06 > Fax.: + 45 87 40 00 10 > URL.: http://www.martin.dk/ > >Article: 53231
If you want to program FPGAs via JTAG, you would need download cable and software from FPGA vendors. If you want to do PCB interconnection test via JTAG, you would probably have to get test SW and HW from JTAG test equipment vendors. Jim Wu jimwu88NOOOOOSPAM@yahoo.com (remove capital letters) "Prakash" <isro@ureach.com> wrote in message news:790976aa.0303062246.4092c707@posting.google.com... > Hi > Anybody is using JTAG/BIST in > boards.I'm new to this and want to > know how to use it.Any material/example > other than Mic.Smith(ASIC).Article: 53232
.
C A L L F O R P A P E R S
2003 NASA/DoD Conference on Evolvable Hardware
July 9 - 11, 2003
The Westin Michigan Avenue, Chicago, IL
http://ic.arc.nasa.gov/~eh2003
*** Note: deadline extended to March 17 ***
Sponsored by:
National Aeronautics and Space Administration (NASA)
Defense Advanced Research Projects Agency (DARPA)
Supported By:
Information Sciences and Technology Directorate, NASA Ames Research
Center
Computing, Information and Communications Technology Program, NASA
Ames Research Center
Life Detection Science and Technology Program, Jet Propulsion
Laboratory
Space Exploration Technology Program, Jet Propulsion Laboratory
Navy Center for Applied Research in Artificial Intelligence, Naval
Research Laboratory
The 2003 NASA/DoD Conference on Evolvable Hardware (EH-2003) will
be held in Chicago, Illinois. The Conference builds upon the
tradition of the successful series of NASA/DoD Workshops on
Evolvable Hardware (the first Workshop hosted by JPL in Pasadena,
1999; the second Workshop hosted by NASA Ames in Palo Alto, 2000;
the third hosted by JPL in Long Beach in 2001; and the fourth
hosted by NASA Goddard in Washington DC).
Evolvable Hardware is an emerging field that applies evolutionary and
related algorithms to automate design and adaptation of physical,
reconfigurable, and morphable structures such as electronic systems,
antennas, MEMS and robots. The purpose of this conference is to bring
together leading researchers from the evolvable hardware community,
representatives of the automated design and
programmable/reconfigurable hardware communities, technology
developers and end-users from the aerospace, military and commercial
sectors.
Evolvable hardware techniques enable self-reconfigurability,
adaptability and learning by programmable devices and thus have the
potential to significantly increase the functionality of deployable
hardware systems. Evolvable Hardware is expected to have major
impact on deployable systems for space systems and defense
applications that need to survive and perform at optimal
functionality during long duration in unknown, harsh and/or
changing environments. It is also expected to greatly enhance the
capability of systems that need modification, upgrade and learning
without interrupting their operation.
The focus of this year's conference will be evolvable hardware for
reliability. Reliability issues range from fault-recovery and
survivable NASA/DoD systems operating in extreme environments to
intelligent adaptive and learning systems for protection of areas
and security of communications.
Topics to be covered include, but are not limited to:
Evolutionary hardware design
Co-evolution of hybrid systems, such as wetware, chemical, mechanical,
and electronic components, etc.
Intrinsic/on-line and extrinsic/off-line evolution
Hardware/software co-evolution
Self-repairing, reconfiguring, and fault tolerant hardware
Embryonic hardware
Novel devices, testbeds and tools supporting evolvable hardware
Adaptive computing and adaptive hardware
Real-world applications of evolvable hardware, such as:
-Security and watermarking of digital data
-Radiation hardening
-Biometrics
-Detection and identification of biological agents and
extraterrestrial
lifeforms (astrobiology)
-Ultra-safe systems
SUBMISSION OF PAPERS
Prospective authors are invited to submit their work by email in
PDF, PS, or MSWord formats to eh2003@email.arc.nasa.gov. Papers
are limited to 10 pages and should be submitted in
single-spaced, 10 point type on a 8.5" X 11" or equivalent paper
with 1" margins on all sides. Each submission should contain the
following items: (1) title of paper, (2) author name(s), (3) first
author physical address, (4) first author e-mail address, (5) first
author phone number, (6) a maximum 200 words abstract. Accepted
papers will be published in the Conference proceedings.
The conference will maintain its single-track forma and will include
posters sessions and panel discussions. Research groups are invited
to
prepare a poster describing their research. A one-page abstract of
the poster should be submitted following the same procedures as the
paper.
For further information please contact:
Jason Lohn
EH-2003 Conference Chair
NASA Ames Research Center, MS 269-1
Mountain View, CA 94035, USA
eh2003@email.arc.nasa.gov
Tel: +1 (650) 604-5138
Fax: +1 (650) 604-3594
IMPORTANT DATES
Submission deadline: March 17, 2003
Author notification: April 18, 2003
Camera ready manuscript deadline: May 7, 2003
Conference: July 9-11, 2003
Conference Venue:
The Westin Michigan Avenue, http://www.westinmichiganave.com/
Organizing Committee
Jason Lohn NASA Ames Research Center (Chair)
Ricardo Zebulum Jet Propulsion Laboratory (Co-Chair)
James Steincamp Marshall Space Flight Center (Co-Chair)
Program Chair:
Didier Keymeulen Jet Propulsion Laboratory (Co-Chair)
Adrian Stoica Jet Propulsion Laboratory (Co-Chair)
Local Chair:
Michael I Ferguson Jet Propulsion Laboratory (Chair)
Program Committee:
Tughrul Arslan, University of Edinburgh (UK)
Peter Athanas, Virginia Polytechnic Institute and State University
(USA)
Forrest H. Bennett III, Pharmix Corporation (USA)
Neil Bergmann, Queensland University of Technology (Australia)
Silvano P. Colombano, NASA Ames Research Center (USA)
Rolf Drechsler, Univeristy of Bremen (Germany)
Tim Edwards, Johns Hopkins University (USA)
Hugo de Garis, Utah State University (USA)
Stuart J. Flockton, Royal Holloway, University of London (UK)
Dario Floreano, Swiss Federal Institute of Technology (Switzerland)
Terry Fogarty, South Bank University (UK)
David B. Fogel, Natural Selection, Inc. (USA)
Manfred Glesner, Darmstadt University of Technology (Germany)
Al Globus, NASA Ames Research Center (USA)
Takashi Gomi, Applied AI Systems Inc (Canada)
Garrison Greenwood, Portland State University (USA)
Steven Guccione, Xilinx Corporation (USA)
Pauline Haddow, Norwegian University of Science and Technology
(Norway)
Inman Harvey, University of Sussex (UK)
Tetsuya Higuchi, Electrotechnical Laboratory (Japan)
Gregory Hornby, NASA Ames Research Center (USA)
Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
John Koza, Stanford University (USA)
Gregory Larchev, NASA Ames Research Center (USA)
Derek Linden, Linden Innovation Research (USA)
Daniel Mange, Swiss Federal Institute of Technology (Switzerland)
Pierre Marchal, Centre Suisse d'Electronique et de Microtechnique SA
(Switzerland)
Trent McConaghy, Analog Design Automation (Canada)
Bob McKay, University of New South Wales @ ADFA (Australia)
Karlheinz Meier, University of Heidelberg (Germany)
Julian Miller, University of Birmingham (UK)
J. M. Moreno, Technical University of Catalunya (Spain)
Masahiro Murakawa, Electrotechnical Laboratory (Japan)
Viktor Prasanna, University of Southern California (USA)
Justinian Rosca, Siemens Corporate Research (USA)
Rob Rutenbar, Carnegie Mellon University (USA)
Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland)
John Schewel, Virtual Computer Corporation (USA)
Hajime Shibata, Tokyo Institute of Technology (Japan)
Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
Stephen Smith, Quicksilver Technology (USA),
Andre Stauffer, Swiss Federal Institute of Technology (Switzerland)
Christof Teuscher, Swiss Federal Institute of Technology (Switzerland)
Stephen Trimberger, Xilinx (USA)
Adrian Thompson, University of Sussex (UK)
Benny Toomarian, Jet Propulsion Laboratory (USA)
Jim Torresen, University of Oslo (Norway)
Andy Tyrrell, University of York (UK)
Xin Yao, The University of Birmingham (UK)
Tina Yu, Chevron Information Technology Company (USA)
NASA/DoD Advisory Committee:
David Alfano, NASA Ames Research Center
Leon Alkalai, Jet Propulsion Laboratory
Scott Hubbard, NASA Ames Research Center
Alan Hunsberger, National Security Agency
Jose Munoz, Department of Energy
Alan C. Schultz, Naval Research Laboratory
Rich Terrile, Jet Propulsion Laboratory
Anil Thakoor, Jet Propulsion Laboratory
Steven Zornetzer, NASA Ames Research
Article: 53233
TI wrote:
>
> Hello
> we are an ASIC/FPGA company currently understaffed but with a very
> limited budget; so I wonder under what circumstances and what type of
> projects(non crucial?) we could consider outsourcing to some(which?)
> developing country team?
> Thanks
> MA
Look at your development process from this point of view: which parts
of your product development can you bundle up and have someone
accomplish
with limited communications with your staff? Are those functions
something that you would consider to be a part of your businesses
core competence? In order to perform those functions, how much
strategic knowledge would be needed to perform them? In other words,
would you have to divulge any trade secrets or knowledge not generally
shared in your industry with your subcontractor.
Keep one thing in mind when considering your proprietary knowledge:
some countries only pay lip service to intellectual property laws.
Hand them too much information and pretty soon they'll be knocking
off your designs and there won't be much that our legal system can do
about it. Of course, this isn't solely a characteristic of foreign
suppliers. I've seen U.S. companies do the same thing. Your only
advantage is that you can take them to court. Unless they have enough
cash to drag that process out until you go bankrupt, that is.
--
Paul Hovnanian P.E. | (here) mailto:hovnania@bcstec.ca.boeing.com
Software Conflagration | (there) mailto:Paul@Hovnanian.com
Control | (spam) mailto:postmaster@mouse-potato.com
-----------------------+---------------------------------------------
Fingerprint: 52:98:95:EA:E3:4F:D9:14:42:E8:E3:E4:EC:E1:A6:22
Expired (10/24/2002): D7:8B:E3:BF:61:AF:37:B1:4B:47:19:CE:90:09:CC:A3
---------------------------------------------------------------------
Life is like an analogy.
Article: 53234Hello > > For any serious work your best choice is Linux. The Mac has never been > supported by EDA vendors and it's unlikely that they will start now. Most > of the major EDA tools are available on Linux. Altera's tools are available > as native Linux tools, Xilinx's tools still have to be run under wine but > the important ones work fine and Xilinx is planning to have native Linux > support in their next major release. The only real use for Mac is as an X > server and for documentation. Right now, I would say that any serious job requires Solaris (and this is the platform we are using). We do have an experimental linux box but using wine is not as straightforward as one would like (Wine over NFS is simply awful). Mac has never been supported by EDA vendors simply because Mac OS 9 was an ancient operating system. But I am talking now of Mac OS X, i.e. BSD Unix. Linux is by definition an unstable platform. Look at all the distributions: Red Hat, SuSE, Mandrake... EDA vendors support basically Red Hat. There has been a new release of Red Hat every 5-6 months. Compare to Solaris. Mac OS X is here to stay for a while. It's supported. Its interface is solid. The machines are not more expensive than Intel boxes. They have blade servers. I really think that Apple is going to be one of the big players in the unix world in the future. In this case, why should not we have EDA tools for this platform as well?? Just my friday thoughts. Regards, TomasArticle: 53235
On Fri, 07 Mar 2003 13:59:09 GMT, Jim Wu <jimwu88NOOOSPAM@yahoo.com> wrote:
>If you want to program FPGAs via JTAG, you would need download cable and
>software from FPGA vendors.
False. There are plenty of vendor-free ways to program FPGAs by JTAG.
People who are in the habit of using decent paid-for, supported, time-saving,
flexible and relevant commercial software/hardware are, of course, free
to continue doing so. Everyone also needs to understand that this approach
is not the only path, and in many cases it doesn't exist. Actual knowledge
of how to solve the problem is sometimes essesntial, and such knowledge is
not the exclusive province of large companies.
- Larry
Article: 53236Hi all, I'd like to know which multiplication schemes (among Wallace, Booth, shift-add, etc) are used on Xilinx CoreGen modules, taking in account the speed vs area tradeoff. Or if those generated modules use more technology specific features like fast-carry chains, RPM, LUT, etc. Thank you in advance, JDSArticle: 53237
I've built a board with the Cyclone from Altera. First board was ok, but on some of the following there was a problem with startup of the Cyclon. For the core voltage (1.5V) I use a drop-down regulator from Linear Technology (LTC3405) as described in the app. note (AN257). But the core voltage did not reach the 1.5V. The regulator stopped at 0.5 - 0.8 V. I examined the problem by building an extern regulator. Starting the regulator without load and than attaching the VCCINT pins from the FPGA leads to a successfull start. The output capacitor (4u7) supplies enough initial current. Measuring the current during startup yields to following results: First few us the Cyclone needs about 0.7A! Falling down to 200 mA and staying there for about 15 us (I think for internal startup). After that it dropps to a few mA. The LCT3405 is a 300 mA regulator with a peak current of about 650 mA. It can not deliver this peak current during it's own start. Just wanted to tell this story (of hidden problems of a new family) for others who want to work with this new (still exciting) FPGAs to not run into the same troubles. Martin SchoeberlArticle: 53238
Martin Schoeberl <martin.schoeberl@chello.at> wrote: : I've built a board with the Cyclone from Altera. First board was ok, but on : some of the following there was a problem with startup of the Cyclon. : For the core voltage (1.5V) I use a drop-down regulator from Linear : Technology (LTC3405) as described in the app. note (AN257). But the core : voltage did not reach the 1.5V. The regulator stopped at 0.5 - 0.8 V. I : examined the problem by building an extern regulator. : Starting the regulator without load and than attaching the VCCINT pins from : the FPGA leads to a successfull start. The output capacitor (4u7) supplies : enough initial current. : Measuring the current during startup yields to following results: : First few us the Cyclone needs about 0.7A! Falling down to 200 mA and : staying there for about 15 us (I think for internal startup). After that it : dropps to a few mA. : The LCT3405 is a 300 mA regulator with a peak current of about 650 mA. It : can not deliver this peak current during it's own start. : Just wanted to tell this story (of hidden problems of a new family) for : others who want to work with this new (still exciting) FPGAs to not run into : the same troubles. Is your Cyclone and Engineering sample or from a normal production run? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 53239
> : Just wanted to tell this story (of hidden problems of a new family) for > : others who want to work with this new (still exciting) FPGAs to not run into > : the same troubles. > > Is your Cyclone and Engineering sample or from a normal production run? > Its a EP1C6Q240C8 from the production run. First shipped Cyclones (in Austria) where marked as production. MartinArticle: 53240
Peter Alfke wrote:
> Registers really isolate the input side from the output side. If you
> have tight clock distribution and pay attention to set-up times, you can
> analyze each part of the circuitry in its own clock period, and you
> never get any strange race-condition effects, Something like the
> revolving door at the hotel entrance, there is never any blast of wind
> through it.
>
> A latch is transparent during one half cycle of the clock. Now you must
> pay attention to signals that might be racing through the latch.
> On the other hand, latches can make your system faster, since you can
> avoid the worst-case delay in every pipeline stage.
>
> Peter Alfke
> =========
Peter,
That was what I thought, but now I know for sure.
Thanks,
Theron
>
> Nimrod Mesika wrote:
> >
> > Peter Alfke <peter@xilinx.com> wrote in message news:<3E654FF4.B03BCACE@xilinx.com>...
> > > Here is what I say in seminars:
> > > Latches are only used by very inexperienced designers, and by very
> > > experienced designers.
> > > The inexperienced ones don't realize the pitfalls ( and get themselves
> > > into bad trouble), the really experienced ones appreciated the
> > > advantages ( and know how to stay out of trouble).
> > > The average designer is much better off with only flip-flops.
> >
> > Can you elaborate a little about the advantages of using latches (or
> > point us at some paper)?
> >
> > The only advantage I know of is that latches may sometimes give better
> > performance if your pipeline isn't well balanced (i.e., you may get a
> > higher maximum clock).
> >
> > From what I recall disadvantages are difficult testability and
> > sensitivity to clock duty cycle. Both of these shouldn't be an issue
> > for FPGA design, I assume.
> >
> > Just an interesting discussion.
> >
> > Nimrod.
Article: 53241"Theron Hicks (Terry)" <hicksthe@egr.msu.edu> wrote in message news:<3E67F34A.16F64A6E@egr.msu.edu>... > Peter Alfke wrote: > > > Here is what I say in seminars: > > Latches are only used by very inexperienced designers, and by very > > experienced designers. > > The inexperienced ones don't realize the pitfalls ( and get themselves > > into bad trouble), the really experienced ones appreciated the > > advantages ( and know how to stay out of trouble). > > The average designer is much better off with only flip-flops. > > > > Peter Alfke > > ================== > Nicely summed up warning! > Peter, > I don't seem to have been bitten by this problem yet, but I would rather > not be bitten either so could I get a few clarifications please.... > > 1. How do you define a flipflop vs a latch? > Is a latch a register with a level sensitive strobe? > What is a flip-flop then? To me a Flip-flop is, for example, a pair of > cross-coupled nand or nor gates (R-S flip-flop), or else a J-K, toggle, or > D-type (edge sensitive.) Is the definition here different? > > 2. Why are latches bad? Is it due to timing of clock distribution? > > 3. Can you point me at some examples of pitfalls and advantages? (Really I > would like to just find them here, but I am not that lazy.) > > 4. How does one stay out of trouble with latches? > > 5. Are you saying, "Stick with edge sensitive devices, not level sensitive > devices"? If I understand correctly, you really want us to stick with one > clock domain and thus one clock frequency throughout the device, if at all > possible, right? > > Thanks, > Theron > > > > this is for the newbies, or people with way too much time on their hands like me The word flip flop is perhaps one of the most abused words in the EE dictionary. Somewhere along the road the terms flipflop, & even register became ambiguous. A flipflop can be level sensitive or edge sensitive. A level sensitive flop is usually to be avoided in most situations, but see below. Also known as bistables, latches, slaves, SRAM memory cell or even register or pipeline. I refer to them usually as latches even if they are used as SW registers or RTL pipelines. The design is usually a crosscoupled circuit, a bistable. Even a single node design is possible with varacters or devices with hysteresis (MRAM, even DRAM with refresh). How & when it is written is what usually separates the newbie from the experienced circuit designer. An edge sensitive flop is to be desired in most situations, but see below. These can be called DFlop, a master slave [register], an edge triggered|sensitive latch|flop or just register or pipeline. I refer to these as DFlops or registers/pipelines in the RTL sense. How & when it is written is what usually separates the newbie from the experienced logic designer. When written by a clock edge, it is almost always safe given enough cycle time, but written by a user created signal, almost as bad as a latch unless such signal is made glitch free. So many names to confuse the novice, even the same name is often used for both, but the design context usually resolves which type is meant. Verilog doesn't help by having register as a reserved word to mean something else. Personally I never use Verilog always @ to infer clocking of latches or Dflops. I always instance DFFs directly hiding the always @ inside a few lib files. Level context In some situations, like in ECL of ancient days, or even in the fastest CMOS cpus, most registers/flops are just latches written with a short pulse, either an asymetric clock pulse or derived from a clock edge locally. If all the logic paths in an x ns design are longer than the set up & hold of a latch, then only latches are needed for the pipelines. If a pipe stage has no path delay then enough delay is added. Without the extra delay, a clock could propagate a signal through >1 pipe since they are momentarily all transparent. This use of latches along with extraordinary short logic paths gives fastest clock frequency and less circuit power. This style of design is rarely used except by cpu and memory designers and can only be used safely when the layout is precisely controlled and included in the design calculations. This means that in FPGA it is almost impossible to use since very few can manually place every LUT, flop, and wire. Since FPGA pathas tend to be 1 or 2 orders of magnitude longer than in cpus, the savings from use of latch over DFlop are zere. Edge context In most synchronous designs, registers/flops are edge triggered. A register usually implies 2 latches back to back on opposing clocks, ie a DFlop, a master slave, an edge triggered/sensitive latch/flop, a 2 phase register etc. It is also possible to design edge triggered Dflops with only one storage circuit with more complex circuit design that schemes or races a short pulse event from an edge, often used by TTL DFlops and SRAM sense amplifiers. In a typical datapath pipeline, if the master slave latches were instead written with skinny pulses at the clock edges, the design would essentially do the same. Further, many of the master latches could then be safely removed from those longer paths, leaving out the master latch delay. Then you have the latch based pipeline scheme above. The remaining masters left in the short paths are the blocks that prevent clock tunneling, same effect as just adding enough delay. This sort of optimization is hardly justified (except for cpus) as the savings in removal of master flops is minimal. Memory context In the memory context, all memory cells are the simplest smallest erea, lowest power, least leakage bistable latches. The memory may appear to be edge clocked, but the early side of the clock masters the data into a front latch, and the other side transfers it to the selected memory slave latch. 1 master, many slaves. In asychronous SRAM design, the master latch is missing, so the selected memory latch/cell can be exposed to outside world if WE is asserted long enough. These asynchronous memories are harder to use since they require detailed attention to timing, ie address must be stable long before & during WE. In ASIC design, even a logic designer can safely build small memories from std cell latches to save area, but requires careful logic design & hand placement. Delay context Latches can be used to extend a signal out by remaining mostly open and closing to freeze a signal. These can be safe when used with clocks or safe glitch free LE. Usually better to design reason out and use Dflop & mux. Synthesis context Any reader of synthesis texts will learn that synthesis algorithms have a hard time with latches esp when used poorely or unconstrained. Synthesis SW is so much easier to write for Dflops, even ordinary users can write basic synthesis tools that are safe by construction, since these are often mathematical transform tools. As soon as general latches are allowed, they become something else. When HDL is used to create what synthesis can only assume is a latch, it is usually a mistake on the coders part. In a schematic flow, use of latches is usually more deliberate since the Dflop & latch have quite different symbols. Personally I would ban all use of latches unless deliberately instanced, & never inferred. Layout context In FPGAs and all high performance VLSIs/ASICs the clock signal nets get extraordinary attention to detail to assure that the clock signals are uniformly available over whole chip with minimal skew, and plenty of drive strength. No such attention can be guaranteed for any other signal when used as a clock, esp FPGAs. Using signals to write latches undermines the work done to make chip design as easy as possible. Use of latches forces one to know chip internals that are not usually available. Asynchonous logic context Some are of the opinion that synchronous logic design has had its day in the sun, and that asynchronous design could produce faster lower power design as all clocks become locally produced. They are probably right, but FPGAs make that scheme mostly irrelevant. Here latches become the circuit of choice as global clocks are discarded, but thats another story, and it applies only to custom ASIC design with carefull layout. Multiple clock domain context Use of latches is even worse in multiple clock domain. Multiple clock domains that involve multiple blocks of logic at different frequencies invites problems. Best if the clocks are locked together so that edge events in one domain occur in fixed points in time in another domain where two domains communicate. When the domains are locked, then the system is equivalent to a system with much faster clock, each sub domain simply choosing to use a fraction of the available edges. In an unlocked system, then the communication between domains invites asynchronous behaviour requiring resynchronizing logic which can be a back door to metastability. Unfortunately multi clock domains are with us because different domains are locked to systems that cannot always be unified. One example is hard disk controller, where analog front end even varies its domain depending on track position. I could go onArticle: 53242
Is there a standard ISP Header for Xilinx CPLDs. I want to use a 10 pin header, but i am not sure which signals should be at which pins ... Is there a standard pinout ? Is there a standard isp header i should put on my board ? (maybe not 10 pin ...) TigerMoleArticle: 53243
TigerMole <none@nowhere.de> wrote: : Is there a standard ISP Header for : Xilinx CPLDs. I want to use a 10 pin : header, but i am not sure which : signals should be at which pins ... : Is there a standard pinout ? : Is there a standard isp header : i should put on my board ? (maybe : not 10 pin ...) I use now the Altera Bteblaster pinout for the JTAG header, even with the XILINX parallel cable. At least a little bit of interoperability. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 53244
>I use now the Altera Bteblaster pinout for the JTAG header, even with the >XILINX parallel cable. At least a little bit of interoperability. I have seen 4 different pinouts for a 10 pin headers now. So it is true that there is no standard ? Isn't it strange, that Xilinx does not make a suggestion ? Some are using the Atmel header: MISO->TDO SCK->TCK /RESET->TMS MOSI->TDI how about that ? TigerMoleArticle: 53247
See my comments: "Theron Hicks (Terry)" wrote: > > Peter, > I don't seem to have been bitten by this problem yet, but I would rather > not be bitten either so could I get a few clarifications please.... > > 1. How do you define a flipflop vs a latch? > Is a latch a register with a level sensitive strobe? > What is a flip-flop then? To me a Flip-flop is, for example, a pair of > cross-coupled nand or nor gates (R-S flip-flop), or else a J-K, toggle, or > D-type (edge sensitive.) Is the definition here different? I beg to differ. In my book A latch is a single-rank device, e.g. two cross-coupled gates, where the output change is directly affected by an input change while the latch is transparent. A flip-flop changes it output only as a result of the clock edge. Data input changes never change the output directly, a flip-flop is never transparent. (This ignores the asynchronous preset and clear inputs). > > 2. Why are latches bad? Is it due to timing of clock distribution? Because they are transparent. You can send a race condition through the latch, and you should not feed the latch output back to its input. "Toggle latch" would be a contradiction in terms. > > 3. Can you point me at some examples of pitfalls and advantages? (Really I > would like to just find them here, but I am not that lazy.) > > 4. How does one stay out of trouble with latches? > > 5. Are you saying, "Stick with edge sensitive devices, not level sensitive > devices"? If I understand correctly, you really want us to stick with one > clock domain and thus one clock frequency throughout the device, if at all > possible, right? Well, that is the safe way, everything else is more risky. BTW, all "registers" and "flip-flops" (in my book) are edge sensitive. Level-sensitive "ones-catching" flip-flops died in the early seventies. Peter Alfke > >Article: 53248
Look at the DCI option in XilinxVirtex-II outputs. You can define the output source and sink impedances ( source and sink independently) for any bank (half-side) of outputs. Typical values are 50 to 100 Ohm. Peter Alfke, Xilinx Applications ========================= Henrik Douglas Green wrote: > > Hi > > I would like to know there are any FPGA's where it is possible to controll > the current consumption upon the output lines. E.g. to limit the current in > some "pins"? > > -- > Best Regards > > Henrik Douglas Green > B.Sc.E.E. > > R&D, Stage, Studio and Event Lighting > > Martin Professional A/S > Olof Palmes Allé 18 > DK-8200 Aarhus N > > E-mail: Henrik.Green@martin.dk > Phone: + 45 87 40 00 00 > Direct: + 45 72 15 02 06 > Fax.: + 45 87 40 00 10 > URL.: http://www.martin.dk/Article: 53249
Hi, I'm trying to figure out if there's a bit of IP out there that can solve my problem before write my own solution: I'd like to put together a design with a block RAM, initializing it from a ASCII file. At the end of simulation (or possibly several times during simulation), I'd like to be able to write out the contents of the memory to a text file (in the same format that I read them in, ideally). I already know I can easily put a COE file into the VHDL that Xilinx COREGEN produces, but I'm having trouble finding the bit to handle writing out the file. My reason for doing this is that I'd like to demonstrate that the significant part of my design works before I try to interface the other half of of the DP memory to Ethernet via a Microblaze processor. I'd appreciate any help. Thanks, -michael
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