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
yuryws@banet.net wrote: > Side note: > uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) > not 133 MB/sec. > > -- Yury > > R UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = 133MBytes/sec.Article: 29626
"Juan M. Rivas" wrote: > Hi everyone! > > What's the difference in the speed-grade between devices? > > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which > speed grade should I use? -4, -5, -6. > > Thanks all > > -Juan First: Don't buy Virtex buy Virtex-E they're not only faster but an awful lot cheaper. Second: It depends on your logic. You shouldn't really decide until you've done enough of the design to get a realistic +/- 20% STA except ... Third: The true answer is to buy the ones you stand a chance of getting before you retire.Article: 29627
On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: >yuryws@banet.net wrote: > >> Side note: >> uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) >> not 133 MB/sec. >> >> -- Yury >> >> R > >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = >133MBytes/sec. I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both edges so it has a 66.67 MB/s transfer rate. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29628
Excellent benefits and Flex hours available For more info Contact: -- Jackie Linich Senior Staffing Consultant (510)865-7849 (510)499-4558 Senior Hardware Design Engineers - Board level and FPGA Design We are looking for three (3) Digital Hardware Design Engineers. Engineering candidates should have 5-7 years design experience with three+ years in telecom design preferrably in either ATM or DSL. Candidates should have knowledge of design specifications governing some of the following areas: T1, E1, ADSL, HDSL2, ADSL, ATM, etc. Experience with digital design from the product specification stage to manufacturing release stage is a plus. You will have the opportunity to design the next generation of Integrated Access Devices. These devices will utilize the latest xDSL chipsets, networking chipsets (copper and optical), and communication processors. Furthermore, these designs incorporate the latest voice communication standards. Requirements BSEE (MSEE a plus) with a minimum of 5 years HW board design experience. Experience with Motorola MPC8XX, PPC7XX and Intel x86 processors.Article: 29629
See, http://www.orlin.com for Hardware supporting the Microchip application note AN731 on PIC-based Embedded Webservers/Clients. Orlin Technology Ltd.Article: 29630
If you need a Qrel part, then you are forced to use a Virtex-4 :-( Provided your design is carefully executed to limit the number of logic levels and floorplanned, 100 MHz can be hit even by the virtex -4. Normally, the carry chain or the block RAM access is the limiting factor. The Virtex -4 block RAM is good to about 125 MHz if it is registered near the block RAM, and a 16 bit -4 carry chain can be run at >150 MHz provided the driving logic is located in an adjacent CLB and the fanout is kept small. As Rick mentioned, if you are not constrained to a QREL application, use the Virtex E, they are faster, cheaper, and have more block RAM. Alternatively, use the Spartan II, which gets you approximately the same speeds as a Virtex for a whole lot less money (check the supply first though). Rick Filipkiewicz wrote: > > "Juan M. Rivas" wrote: > > > Hi everyone! > > > > What's the difference in the speed-grade between devices? > > > > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which > > speed grade should I use? -4, -5, -6. > > > > Thanks all > > > > -Juan > > First: Don't buy Virtex buy Virtex-E they're not only faster but an > awful lot cheaper. > > Second: It depends on your logic. You shouldn't really decide until > you've done enough of the design to get a realistic +/- 20% STA except > ... > > Third: The true answer is to buy the ones you stand a chance of getting > before you retire. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 29631
Rick, The XCV200 is stock in many packages. The XCV200E is 1 -2 weeks leadtime. Is your 65 th birthday next month? Austin Rick Filipkiewicz wrote: > "Juan M. Rivas" wrote: > > > Hi everyone! > > > > What's the difference in the speed-grade between devices? > > > > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which > > speed grade should I use? -4, -5, -6. > > > > Thanks all > > > > -Juan > > First: Don't buy Virtex buy Virtex-E they're not only faster but an > awful lot cheaper. > > Second: It depends on your logic. You shouldn't really decide until > you've done enough of the design to get a realistic +/- 20% STA except > ... > > Third: The true answer is to buy the ones you stand a chance of getting > before you retire.Article: 29632
Sir,
Can netlist generated from Webpack ISE be loaded in Foundation Series 2.1 simulator. Is the netlist compatible. Iam synthesysing VHDL designs in Webpack and when i load the netlist in Foundation series simulator i am getting lot of warnings. should i make any settings in the environment settings.help me please.
thanks in advance,stm.
Article: 29633On Fri, 2 Mar 2001, Ray Andraka wrote: > If you need a Qrel part, then you are forced to use a Virtex-4 :-( Qrel?Article: 29634
Hello there, I was wondering if anyone could shed some light on the differences in the way you write VHDL for a FPGA and a CPLD, in particular Xilinx Devices. Lets say I did a small design in Virtex FPGA, but I would want to implement that in a CPLD. Does any one have examples of VHDL code that were written for both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate any input. Thank You ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.netArticle: 29635
QML high reliability parts. Basically qualified for military/space applications that demand high reliability. Luke Roth wrote: > > On Fri, 2 Mar 2001, Ray Andraka wrote: > > > If you need a Qrel part, then you are forced to use a Virtex-4 :-( > > Qrel? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 29636
Muzaffer Kal wrote: > On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz > <rick@algor.co.uk> wrote: > > >yuryws@banet.net wrote: > > > >> Side note: > >> uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) > >> not 133 MB/sec. > >> > >> -- Yury > >> > >> R > > > >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = > >133MBytes/sec. > > I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s > not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both > edges so it has a 66.67 MB/s transfer rate. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.com I've *built* a UDMA33 interface and that clock runs at 16.66 ergo the UDMA66 interface I'm about to build will have a 33.33MHz clock. Note that the clock frequency is really the read clock sent by the disk on IORDY. The write clock is under my own control.Article: 29637
kode@bridgeport.edu wrote: > Hello there, > > I was wondering if anyone could shed some light on the differences in the way > you write VHDL for a FPGA and a CPLD, in particular Xilinx Devices. > > Lets say I did a small design in Virtex FPGA, but I would want to implement > that in a CPLD. Does any one have examples of VHDL code that were written for > both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code > for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate > any input. > > Thank You Off the top of my head I can think of 1 important thing. For FPGAs state machines should be one-hot encoded but for CPLDs they should be binary. Most HDL synth tools default to the FPGA case/setting but have some way of overriding this. Interestingly I've recently come across a situation where HDL - Verilog - code for a CPLD just would not fit [synth tool = Synplify] but re-writing it in old-fashioned ABEL worked easily. Looking further it seemed that the grown-up synth tool was not doing a full and/or reduction and implemented the logic with large swathes of 2/3 input gates. It was relying on the not 100% efficient ``multi-level'' logic optimisation in the Xilinx CPLD fitter.Article: 29638
kode@bridgeport.edu wrote: > Lets say I did a small design in Virtex FPGA, but I would want to implement > that in a CPLD. Does any one have examples of VHDL code that were written for > both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code > for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate > any input. If you can avoid instantiating device specific components, your code will be very portable. With the right synthesis software, things like RAM, ROM, counters etc can be inferred from a line of code rather than selected from a vendor component library. Of course the vendors want you to stick with their chip so they use more ink on app notes that lock you in than those that let you loose. -- mike.treseler at flukenetworks dot comArticle: 29639
Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Muzaffer Kal wrote: > >> On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz >> <rick@algor.co.uk> wrote: >> >> >yuryws@banet.net wrote: >> > >> >> Side note: >> >> uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) >> >> not 133 MB/sec. >> >> >> >> -- Yury >> >> >> >> R >> > >> >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = >> >133MBytes/sec. >> >> I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s >> not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both >> edges so it has a 66.67 MB/s transfer rate. >> >> Muzaffer >> >> FPGA DSP Consulting >> http://www.dspia.com > >I've *built* a UDMA33 interface and that clock runs at 16.66 ergo the UDMA66 >interface I'm about to build will have a 33.33MHz clock. Note that the clock >frequency is really the read clock sent by the disk on IORDY. The write clock is >under my own control. I am looking at this document http://www.t13.org/project/d1410r1a.pdf specifically table 57, figure 50 and figure 55 (on pages 361, 365 and 370 respectively). I'd appreciate if you could tell me how one gets 133 MB/s with a design compliant to this document. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29640
2 bytes every 30 ns (approximately 27 ns/ 32 ns), not 4 bytes every 30 ns. This is where your error is. Rick Filipkiewicz wrote: > yuryws@banet.net wrote: > > > Side note: > > uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) > > not 133 MB/sec. > > > > -- Yury > > > > R > > UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = > 133MBytes/sec.Article: 29641
Joel, I am very sorry about your mishap, and I have inserted my comments in the appropriate places in your story. The gist is: Virtex parts do check for CRC errors, but not for formatting errors. And you sent a legitimately CRC-protected file, just the wrong format... Horrendous amount of internal contention. Joel Kolstad wrote: > We have some PCI cards at work that we recently upgraded -- for both price > and performance reasons -- to use Xilinx XCV600E parts instead of the XCV400 > parts that the old board used. We've found out the hard way that Very Bad > Things happen if you attempt to load the old bitstream for the XCV400 onto > the XCV600E board. In particular: > > -- <snip> > > Now what I want to know is... I had always thought that there was some CRC > checking in the FPGA bitstream files, and that you could pretty much feed > the FPGA random gibberish and be very unlikely to actually get the thing to > accept the bitstream Correct. If there were a CRC error, the part would recognize this. But there was no CRC error... > and go through power-on initialization. No, no. power-on initialization is done much earlier, right after you applied Vcc. This has nothing to do with CCLK. The parts use their own internal oscillator for that purpose. > In fact, we're > manually bit-banging the CClk line on the FPGA (we're using serial slave > mode), so there aren't even enough clock pulses provided to the 600E to make > it think it should even _consider_ going through power-on initiailization, see above. It has done this sucessfully long before. > > since the 600E requires about two hundred thousand extra bits (and CClks) > than what the 400 file would provide it with (we stop generating CClk when > we're out of configuration data bits). > > With our current setup it's difficult to probe around on the board and try > to figure out exactly _when_ the overcurrent condition starts. Loading the > 400 file takes a couple of seconds, and the 145W PC will power down within a > couple of seconds after that. My suspicion is that the overcurrent > condition has already started long before we're gotten anywhere near to > finishing the transmission of the 400's bitstream. Yes. The internal logic becomes active as you feed in the data. ( I may stand corrected here. I carry too much XC4000 bagage in my head, and I am at home, no access to other experts. But Austin can jump in, while I am gone for the coming week. Seminars in Europe) > > So... does anybody have any experience with this? The possibility that > feeding a 600E a 400 bitstream causes it to draw massive currents seems > awfully remote to me. No, it's ugly, but not surprising. The part considers this a garbage bitstream , but with legitimate CRC. I know this is not ideal, but that's the way it is. > The LT1575/dual FET power supply can put out 2A all > day long (this was its design goal -- we're dissipating 1.5V*2A=3W or > 1.5W/FET in this case), I would wager it can put out 4A for many minutes, > and to physically blow up both FETs I would have to think that it's passing > at least 10A for a little while. Strange, very strange. Not so strange. Consider the very large number of internal nodes, let's say over 50,000. Let's assume that, through nonsense configuration, 10% are driven by contending levels on both sides of the wire. And let's assume a realistic 5 mA per contention: 5000 times 5 mA = 25 A ! This distributed nature of the current also shows why the Virtex part ( most likely ?) survived. The current is more or less evenly spread over the whole die, which is more than a square centimeter in area. I am not making excuses, just describe the phenomenon, which is quite rational, albeit not desirable. Ask Austin whether Virtex-II is protected against this kind of mishap. Peter Alfke, Xilinx Applications (Friday-night emergency services)Article: 29642
Hey all. I've seen the metastability issue come up a few times, and I've read Peter Alfke's app note on crossing clock domains, but I'm still unsure about how to handle some particular issues. Incidentally, someone should archive those great 1-2 page articles with gems of circuits(i.e not be buried under corporate website with millions of layers)... I was recently doing a design where I was interfacing an FPGA/CPLD to the parallel port, using EPP(1.9) protocol. This mode uses nAddressActive/nDataActive and a RDY signal in the "standard" four-phase asynchronous communication scheme. The nAddrActive/nDataActive are signals from the PC port to the peripheral hardware and RDY is a signal from the peripheral to the PC. When the PC wants data transaction to start, it checks to seeing if RDY is low, if so, one of the xActive signals goes low. If the RDY signal is raised, this is considered acknowledgement and data transaction starts, etc. Transaction is finished when RDY drops low, then the xActive signal, hence the four-phases. However with EPP mode, there is no clock or strobe signal for the peripheral to synchronize to/from the host. As a result, one has to take into account the asynchronous nature of the xActive signals. For my design, to take care of the asynchronous signals and taking into consideration the metastability issue, I used two D flip-flops hooked in series (i.e. standard synchronizer) and then the output of the 2nd DFF was used by my state machines, etc. I was curious if this is an "acceptable" method for reducing metastability, or whether the second flip-flop was needed or if I should have used asynchronous feedback loops instead? So I did some investigating; in one of my digital logic books, by Peterson and Hill, it was suggested that since the D-type flip-flop has only one "input"(D) that the worst that could happen is that the incoming signal is synchronized one-clock cycle later. Someone else pointed out that an oscillation(not just a delayed recognition) on the output might occur for a J-K flip-flop, but not for the DFF/DFFE. Fundamentally I understand that the asynchronous signal could/might violate the setup time on the DFF and hence cause metastability. However I'm unsure if the metastability in this case (synchronizer circuit) can be ignored as a result of todays advanced FPGAs & CPLDs. This particular designed would be implemented in both an Altera MAX 7128AE & a Xilinx 4000E/XL. How accurate are Peterson and Hill's statements? I don't have the book right now, otherwise I would quote them. As I understand them, since the flip-flop is clocking the data high or low based on VminHigh and VhighLow, the incoming signal will be one or the other and will be recognized correctly on the next clock cycle. Then I also started pondering if I should have used an asynchronous feedback loop(combinatorial "state machine") and then used the output of this as maybe the enable on a DFFE. I don't mind using schematics (I have my issues with VHDL, maybe I'll jive better with Verilog) so I know I can implement the circuit correctly, but I'm also unsure how advanced the synthesizer's algorithms are for asynchronous "fundamental mode" designs and what it might actually produce. I guess that brings up another interesting question, 99% of the designers I know that use FPGAs & CPLDs pretty much synchronize anything asynchronous (outputs of a decoder, etc) but how prevalent is asynchronous design (fundamental mode with feedbacks, not 2-level AND/OR) in programmable logic? I read a paper from 1994 that mentioned the then current FPGA technology was not suitable for advanced asynchronous design. Have the tools/hardware changed in any manner that makes this method of design more attractive, or is the mentality still synchronize it all? Finally, regarding the four-phase asynchronous circuits, in ASICs/commercial ICs, how do the designers there handle this? Do they use asynchronous circuits or synchronize the asynchronous signals? No one I've asked has known the answer (including several VLSI people), but someone must know, after all we have Multi-I/O parts and even the chipsets know EPP... Thanks! (and sorry for the longish post), VR.Article: 29643
Virtex-E Equivalent Power/Ground Pairs We are designing using Virtex-E XCV600E with a FG900 package. Can someone please tell me the number of Equivalent Power/Ground Pairs for this particular package ? Page 62, Table 27 (Novemebr 2000) of the data sheet has a blank entry for this package. [Ref: VirtexT-E 1.8 V Field Programmable Gate Arrays, DS022 (v1.8) November 20, 2000] Thanks in advance, EdiArticle: 29644
"BriMDavis" <brimdavis@aol.com> wrote in message news:20010228225100.14681.00000083@ng-fx1.aol.com... > >module dff16_s1(clk, ce, d, q) /* synthesis syn_hier="hard" */; > > "Stupid FPGA Trick" of the day for Verilog users: > > Make sure you put that semicolon AFTER the meta-comment, or > your attribute will be silently ignored by the synthesizer... Thanks a million. I hope DejaGoogle remembers that one.Article: 29645
Peter (and Austin and Phil), Here is my take (*please* correct me where I'm mistaken): It sounds like there are two weaknesses in (at least) some of the Xilinx device families that can lead to catastrophic failures: 1. Devices don't check the programming data stream for a "match" of target device. Thus, you can try to program a Virtex 600E device with a Virtex 400E configuration data stream, and the configuration data will be accepted. This "hole" allows the designer to make a mistake, and be burned by it. The workaround is, simply, to make sure that your configuration files were compiled for the correct target device; you screw up at your own peril. 2. More ominous is that drivers for internal multi-source busses are not disabled (tri-stated, if you will) before and during the configuration and powerup sequence, when the internal state of the device cannot be controlled or specified by the designer. I'm not sure there is *any* workaround to this, short of a re-design of the FPGA die. We need to understand the breadth of this problem (if the above assessments are basically correct): which device families are affected (afflicted), etc. etc. I'm not posting this to cause alarm, but to distill the issues at hand as clearly as possible, and avoid any FUD. Rather than get excited, it would be good for all concerned to await Xilinx's response which, if history is a guide, will be an honest and open discussion of the facts, and which will provide essential guidance to the design community. Bob Elkind, eteam@aracnet.comArticle: 29646
Thanks for the explanation, Peter. I'm thinking we'll add something to the board so that the PC's software will be able to detect what type of FPGA the board has loaded on it, and not feed it incorrect bitstreams. The FPGA itself survived just fine, as far as I can tell. :-) ---JoelArticle: 29647
I've seen experts and textbooks botch the metastability issue.
One book I trust and like is:
High Speed Digital Design: A handbook of Black Magic,
by Howard W.Johnsson and Martin Graham
It covers things more at the board level, wires between chips
rather than routing inside an FPGA. It has a very good section
on metastability.
> For my design, to take care of the asynchronous signals and taking into
> consideration the metastability issue, I used two D flip-flops hooked in
> series (i.e. standard synchronizer) and then the output of the 2nd DFF was
> used by my state machines, etc. I was curious if this is an "acceptable"
> method for reducing metastability, or whether the second flip-flop was
> needed or if I should have used asynchronous feedback loops instead?
Two FFs in series is the standard way to avoid metastability. But
you didn't mention the key idea - time, excess time. Settling time
is the only way to avoid metastability troubles. If you wait long
enough you can make the probability of troubles low enough but
you can never make it go to zero.
Metastability recovery is exponentail with time. If 1 extra ns
drops the probability by a factor of 1000, 2 extra ns will drop it
by a factor of 1000000.
Using two FFs normally (almost) forces you to do the right thing.
The idea is that you are running at the same clock speed as the
rest of the circuit but you don't have any logic in there so the
time that logic would use is excess time for any metastability to
settle.
You can screw that up if you put the FFs on opposite sides of
the board/chip and thus use up all the excess time in routing.
You can screw it up if you try to cheat and clock the first
FF on the other edge of the clock. That might be good enough,
but it does reduce the settling time by a 1/2 cycle.
If you have a heavily pipelined FPGA design, you may not have
much excess time even without any logic between the FFs. (The LUT
tables are almost free so you don't save much be not haveing any
logic.)
If your state machine is running slowly (relative to the technology)
then you may not need the first FF - you already have lots of excess
time.
> So I did some investigating; in one of my digital logic books, by Peterson
> and Hill, it was suggested that since the D-type flip-flop has only one
> "input"(D) that the worst that could happen is that the incoming signal is
> synchronized one-clock cycle later. Someone else pointed out that an
> oscillation(not just a delayed recognition) on the output might occur for
> a J-K flip-flop, but not for the DFF/DFFE.
That all seems fishy to me.
> Then I also started pondering if I should have used an asynchronous
> feedback loop(combinatorial "state machine") and then used the output of
> this as maybe the enable on a DFFE. I don't mind using schematics (I have
...
You can't get away from metastability. Anybody who claims they
have "solved" the problem is confused or lying.
You can make it "good enough" (probability of error low enough)
if you wait long enough.
There are two reasons I would avoid anything other than the standard
two-FFs approach.
First, two FFs is a well understood area. You can analyze the
problem and will probably get it right. If you use some complicated
kludgy curcuit you may overlook an important area and you probably
won't get any data from vendors.
Second, the metastability settling time is determined by the
loop bandwidth. That will be much higher inside a tiny FF than it
will be if you build your own circuit using FPGA parts and routing.
(Especially if the people designing the FF considered metastability.)
> Finally, regarding the four-phase asynchronous circuits, in
> ASICs/commercial ICs, how do the designers there handle this? Do they use
> asynchronous circuits or synchronize the asynchronous signals? No one I've
> asked has known the answer (including several VLSI people), but someone
> must know, after all we have Multi-I/O parts and even the chipsets know
> EPP...
If somebody doesn't think about the issue carefully, they are asking
for troubles, nasty troubles.
The simple/clean way is to run all external signals through a pair of
FFs to synchronize them. That costs a cycle.
There is probably a good/simple/clean way to avoid that cycle
on a standard four-phase handshake by pushing a bit of logic
in front of the synchronizer. I can't work one out on the fly.
You have a round trip time to get ready for your next action so
it shouldn't be too tough.
One trick is to use a FIFO to help cross clock boundaries. The
idea is that you only have to synchronize the (almost) full/empty flags
and they change less often than the data so an extra clock of settling
time can often be pushed to someplace where it won't hurt much.
This is part of the reason FIFOs get discussed here so often.
One general measure of goodness is to draw a line on the schematics
(or block diagram) between the clock domains and count the number
of signals crossing that line - more is less good.
--
These are my opinions, not necessarily my employeers. I hate spam.
Article: 29648
Mixed Signal Engineer
Will work as a member of our Test Engineering team to design, test and
troubleshoot our next generation of test equipment. We are a rapidly
expanding, progressive company with excellent benefits and friendly
atmosphere.
Qualifications
BSEE (required)
2+ years experience in C/C++ and VHDL or FPGA (required)
2+ years experience with analog hardware (required)
Schematic design software experience (required)
DSP experience preferred
Send or Fax resume to:
"Mixed Signal Engineer Web"
3629 Vista Mercado
Camarillo, CA 93012
FAX: (805) 383-1838
EMAIL: humanresources@a-m-c.com
begin 666 BULLET_P.gif
M1TE&.#EA'P`.`/<``````( ```" `(" ````@( `@ " @,# P ````````0$
M! @(" P,#!$1$186%AP<'"(B(BDI*55554U-34)"0CDY.?]\@/]04-8`D\SL
M_^_6QN?GUJVID#,``&8``)D``,P````S`#,S`&8S`)DS`,PS`/\S``!F`#-F
M`&9F`)EF`,QF`/]F``"9`#.9`&:9`)F9`,R9`/^9``#,`#/,`&;,`)G,`,S,
M`/_,`&;_`)G_`,S_````,S,`,V8`,YD`,\P`,_\`,P`S,S,S,V8S,YDS,\PS
M,_\S,P!F,S-F,V9F,YEF,\QF,_]F,P"9,S.9,V:9,YF9,\R9,_^9,P#,,S/,
M,V;,,YG,,\S,,__,,S/_,V;_,YG_,\S_,___,P``9C,`9F8`9ID`9LP`9O\`
M9@`S9C,S9F8S9IDS9LPS9O\S9@!F9C-F9F9F9IEF9LQF9@"99C.99F:99IF9
M9LR99O^99@#,9C/,9IG,9LS,9O_,9@#_9C/_9IG_9LS_9O\`S,P`_P"9F9DS
MF9D`F<P`F0``F3,SF68`F<PSF?\`F0!FF3-FF68SF9EFF<QFF?\SF3.9F6:9
MF9F9F<R9F?^9F0#,F3/,F6;,9IG,F<S,F?_,F0#_F3/_F6;,F9G_F<S_F?__
MF0``S#,`F68`S)D`S,P`S `SF3,SS&8SS)DSS,PSS/\SS !FS#-FS&9FF9EF
MS,QFS/]FF0"9S#.9S&:9S)F9S,R9S/^9S #,S#/,S&;,S)G,S,S,S/_,S #_
MS#/_S&;_F9G_S,S_S/__S#,`S&8`_YD`_P`SS#,S_V8S_YDS_\PS__\S_P!F
M_S-F_V9FS)EF_\QF__]FS "9_S.9_V:9_YF9_\R9__^9_P#,_S/,_V;,_YG,
M_\S,___,_S/__V;_S)G__\S___]F9F;_9O__9F9F__]F_V;__Z4`(5]?7W=W
M=X:&AI:6ELO+R[*RLM?7U]W=W>/CX^KJZO'Q\?CX^ ```*"@I(" @/\```#_
M`/__````__\`_P#______R'Y! $``/(`+ `````?``X`0 BO`.4)'$B0X+M:
MKYZALE:PH4.#H@@8,@.FP0(``-;=>_>PH[Q7M;K%JZ7PE*$'"SAZ['C@W;U[
MDF)*VKC2HS5KW;H=>/;L%(%VO&HZ1$64Z"EB%0&D/""TX(&7%"XNB,".G225
M30O>O/G*)+NL#=_AI#>O%BJ3/"(P!2N0)T*CHLPT`"!I+=B>)@U-?( 1`DVV
A[QKUX/%@+D8)[>[9!>M24M6J[69B92OPG<N7ECT&! `[
`
end
Article: 29649
> For my design, to take care of the asynchronous signals and taking into
> consideration the metastability issue, I used two D flip-flops hooked in
> series (i.e. standard synchronizer) and then the output of the 2nd DFF was
> used by my state machines, etc. I was curious if this is an "acceptable"
> method for reducing metastability, or whether the second flip-flop was
> needed or if I should have used asynchronous feedback loops instead?
It is true that you need two flip flops. The first one is to
synchronize the asynchronous signal to the using clock domain. The second
one is to reject the metastability of the first flip flop. If you are
testing an asynchronous signal (note I said signal, not signals) that is
feeding a state machine, then the state machine flip flops will serve as the
"2nd flip flop,", i.e., they are the metastability rejectors. If you use
two fllip flops prior to the state machine, then the 2nd flip flop is the
metastability rejector, and you will incur an additional cycle of delay.
If you are doing this with multiple signals, then you run the risk of
testing multiple signals simultaneously with some of the signals changing
and some not when you sample them. This will give possible erroneous
results, and the only way to synchronize such a circuit is to test for one
synchronized signal at a time. In my world, testing for multiple
synchronized signals is called "using parallel synchronizers," and this is
one of the things I look for when "fixing" someone else's design. Note that
this is not always a bad thing, beacause there is also something else in my
world called "protocol stabilized signals," which means that although the
signals are asynchronous, by the time you test for them, they have
stabilized and are synchronous for all practical purposes. An example of
this is the VMEbus, where ALE is synchronous and tested. By the time ALE is
found activated, the rest of the signals are stabilized. FIFOs also serve a
very useful purpose, essentially shriveling the changing asynchronous
signals (data) down to a synchronized flag.
> Then I also started pondering if I should have used an asynchronous
> feedback loop(combinatorial "state machine") and then used the output of
> this as maybe the enable on a DFFE. I don't mind using schematics (I have
> my issues with VHDL, maybe I'll jive better with Verilog) so I know I can
> implement the circuit correctly, but I'm also unsure how advanced the
> synthesizer's algorithms are for asynchronous "fundamental mode" designs
> and what it might actually produce.
It doesn't matter whether you use VHDL, Verilog or schematics to do FPGA
design. All three will get you into BIG trouble by doing asynchronous
design. All three will keep you out of BIG trouble by doing synchronous
design.
> I guess that brings up another interesting question, 99% of the designers
> I know that use FPGAs & CPLDs pretty much synchronize anything
> asynchronous (outputs of a decoder, etc) but how prevalent is asynchronous
> design (fundamental mode with feedbacks, not 2-level AND/OR) in
> programmable logic? I read a paper from 1994 that mentioned the then
> current FPGA technology was not suitable for advanced asynchronous design.
> Have the tools/hardware changed in any manner that makes this method of
> design more attractive, or is the mentality still synchronize it all?
I have made some serious money in the past six years fixing problems created
by asynchronous designers. Their intent was noble, and some of them
actually pulled it off. But when the product was advanced a year later and
the circuitry was borrowed for the new design, new technology (faster FPGAs)
actually screwed up the parameters and caused severe problems. Redesigning
the circuits using synchronous techniques solved the problems. As FPGAs get
faster, this trend helps synchronous designs but hurts asynchronous designs.
If these designers had used synchronous techniques to design the circuitry
to begin with, the latter engineers wouldn't have had the problems they had.
My feeling is that a designer can do simple asynchronous designs in an FPGA
if (s)he is very careful and pays attention to many details, but advancing
technology or aging of the equipment will cause problems in the future.
Furthermore, detailed asynchronous designs require lots of time and can only
be done to siimple circuits. This may change if the right tools come along.
When I do synchronous designs, I sleep at night. When an engineer does
asynchronous designs, (s)he is still up at night with thoughts about signals
racing back and forth trying to beat each other to the next gate. As you
can read, I am very biased toward synchronous design. I wonder why!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
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