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
ram <rmcbain@dynavision.com> wrote:
>< snip>
>
>> The "friends" I mentioned are not the existing EDA tool suppliers.
>> The folk whose support we need are the software scientists who have for
>> decades been grappling with the problem of how to build large pieces
>> of software reliably; we hardware people are only just starting on
>> that road.
>
><snip>
>
>Your looking for guidance from software engineers makes me nervous :)
>
>Certainly, there's some merging of methodologies that makes sense, but
>let's make sure it's driven by hardware people who understand "big"
>software. In my experience, few software (computing science) people can
>learn or understand hardware (enough to be really useful to a hardware
>type, anyways). I've had too many bad experiences...
>
>On the software side, I see them still not having a concept on how to
>use pictures to describe a design. It's only in the last year or so
>that state machines became popular there; and they still haven't figured
>out how to link a high level data flow or object model diagram to the
>actual compilable software (at least not in any widely successful
>way).... which is something we've been doing in hardware for years.
>
>My vote (of course) is for more pictures to describe the high level
>design. Pictures that are actualy COMPILABLE. People work best with
>pictures; we have a huge portion of our brain allocated for them. And I
>guess that's why they're way more understandable - just compare the VHDL
>code for a complicated state machine vs. a state diagram (which you can
>compile into VHDL or Verilog or ABEL). With the VHDL, you end up trying
>to create the picture in your head.
>
>What I see in the software world is yet another language (Java). Such
>tunnel vision in linguistics doesn't help anybody. Yes, we want reusable
>objects (and if they'd started out emulating hardware "parts" a long
>time ago, this wouldn't be such an innovative concept). But what we're
>talking about is complexity. And listening to somebody telling you about
>some complicated object (in words) is nowhere near as good as giving you
>a combination of pictures AND words, where the pictures are forced
>(through compilation) to be accurate (seen any accurate software
>pictures lately?).
>
>Regards,
>Rick McBain
>Senior (Hardware and Software) Engineer
>Dynamic Control Systems
Rick, for personal financial reasons I have to disagree with your cautions
about using software engineers to design hardware. As an EDA consultant,
I've made an awful lot of money from projects that used software engineers
to design hardware using Verilog/VHDL to implement some algorthm they
knew which they later tried to just pump through Synopsys. These are
gravy consulting dollars -- please don't "dis" the project managers stupid
enough to slap together a team of mostly software designers to make hardware!
My bank account LOVES managers like these!!!! :^)
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 5459 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: 8326what is the average amount of gates needed per device? im looking for a ballpark estimate. *respond to z5c@hotmail.com --zArticle: 8327
I've done this with Synopsys FPGA Compiler & Mentor tools, all on a
workstation. If you use different schematic & simulation tools some details
will likely differ, but the principle may remain the same.
1) Synthesize your HDL module(s) in Synopsys, and save as <design>.sxnf
files in "xnf" format. If the top level schematic has timespecs, make sure
you "remove_constraint -all" in synopsys, otherwise the timing goals you set
in Synopsys will get passed into the sxnf file and may conflict with the
timespecs you set in your (higher level in the heirarchy) schematic.
2) run the syn2xnf conversion utility (use -help to see all the switches you
must set) to produce the <design>.xnf and <design>.xff files. Copy the
<design>.xff to <design>.xnf in the directory that has the main (schematic)
design. Make sure you have a symbol created for the HDL-based components (no
underlying schematic will exist, yet, for these symbols). Aside from the
usual attributes on these symbols, they should also have "FILE =
<design>.xnf" attributes, too. This associates the synthesis-generated .xnf
file with the symbol and keeps men2xnf from trying to generate an xnf
netlist from a schematic that doesn't exist.
3) From here, the xmake design flow continues as before. The Mentor-Xilinx
design flow does generate a schematic for the synthesis-based components,
but this is just to keep the simulator happy and this schematic is quite
un-readable.
I have complained about this before to Synopsys & Xilinx. Namely, that most
HDL tutorials show the flow for complete-HDL designs, yet HDL newbies start
off doing a little bit of HDL in an otherwise schematic design, and
tutorials should be written with this in mind. A Synopsys FAE wrote to agree
with me and take it to the powers that be at Synopsys. My response from
Xilinx was, of course, silence.
Rodrigo Cesar de M. Tavares wrote:
> Hello everybody,
>
> I'm having some problems with the XSI (Xilinx synopsys Interface). I
> have the Synopsys and XSI installed on a Sun Workstation but the XACT6 /
> Foundation Series is installed on a PC. As I don't have the license to
> use VHDL from Xilinx, I'm using the Synopsys tools to implement the
> "modules" of my design. The documentation describes the whole process of
> implementing designs in Synopsys and how to export the XNF file
> generated (using syn2xnf, etc...) to the Xilinx tools, so that one can
> place and route the design. But it assumes that the design is a
> top-level one, that is, it contains PADS and the signals are connected
> in some way to the external pins. In my case, I want to generate blocks
> (known as "macros") and place them in my schematic (Foundation Series)
> so that I can make the interconnections mannualy.
> I can successfully import the xnf generated by Synopsys and translated
> by the SYN2XNF from XSI into the schematic, but when I try to Place and
> Route something goes wrong and I receive dozens of warnings and PPR
> errors.
>
> Please, if someone can help me, do it !
>
> Thanks,
>
> --
> //////////////////////////////////////////////
> // Rodrigo Cesar de Moraes Tavares //
> // e-mail: (mtavares@dcc.ufmg.br) //
> // Belo Horizonte - MG - Brasil //
> // Universidade Federal de Minas Gerais //
> //////////////////////////////////////////////
--
=====================================================================
William Lenihan lenihan3we@earthlink.net
"The greatest barrier to communication is the delusion that
it has already occurred." -- Peter Cummings
=====================================================================
Article: 8328
Does anyone know of any cases, benchmarks, studies, etc., demonstrating
where the envelope is for FPGA designs done on state-of-the-art PCs vs.
state-of-the-art workstations? Has anyone had a case where a design
couldn't compile on a PC, but could when ported to a workstation? (or
vice-versa?)
Example: At time "A", Xilinx will strongly recommend that customers
design their biggest chips on workstations, not PCs. Yet, at time "A + 1
year" they give an official sanction that these chips can be designed on
PCs of X-memory, Y-hard disk space, and Z-CPU speed ...... but PCs with
XYZ specs were not extraordinary at time "A". Do FPGA companies just get
skittish with the PC and lean toward the conservative workstation when
it comes to their newer (and untested in the arena of real designs)
FPGAs? Is there much, or any, risk with sticking to a total-PC design
flow, even when using premium FPGAs?
--
=====================================================================
William Lenihan lenihan3we@earthlink.net
"The greatest barrier to communication is the delusion that
it has already occurred." -- Peter Cummings
=====================================================================
Article: 8329Peter wrote: > > May I also suggest that a tool which could very easily (I mean with > minimal up-front work) predict the dynamic Icc of an FPGA might > discourage some users from using them, and going to an ASIC instead? By all means suggest it, but I'd love to know why this should be so? Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 8330
> >The Antique PDS2XNF you are using is probably one of the worst ways to > >build state machines for Xilinx chips. I would highly recomend you look > >at schematic based, one hot state machines, for performance, density, and > >simultion with the rest of your design. > > > > I agree about using PDS2XNF for state machine designs. The XABEL product > included with the more modern Xilinx releases also builds state machines > using the one-hot method and uses standard ABEL language syntax. But it's so easy to encode them your self using XABEL...and you know they are going to be done correctly. I have had more problems with the first state generation with the Xilinx tools doing it for me...for some reason they just can't get it right! Austin Franklin darkroom@ix.netcom.comArticle: 8331
> As regards CUPL -> PDS2XNF -> XNF this is actually fine for state > machines. All one does is draw a top-level sheet in Viewlogic, dump a > block into the middle of the page (representing the state machine, > define all the pins and IOBs, add any other circuitry needed, generate > an XNF file, and thereafter all the state machine work is done in > CUPL. Later, if doing CUPL-only FPGA designs, the XNF file produced > from that top-level sheet can be re-used, without any need to revisit > Viewlogic. > > Simulation works fine, too. That's not completely true. In order to simulate it, you have to also run XNF2WIR to create a .wir file for the CUPL/XNF instantiation, or VSM will not be able (sic) to put any logic in for that symbol. Additionally, you can run VIEWGEN to create a sch file from the .wir file, so you can push down into the symbol. Also, the symbol must be of type COMPOSITE to use the .wir file if you just want to VSM the top level design....as opposed to MODULE which is what you use when you want the tools to use the .xnf file when being compiled, but doing it this way, requires you to compile and back annotate the design in order to simulate it. Austin Franklin darkroom@ix.netcom.comArticle: 8332
I've come across a strange phenomenon when going from ABEL source to an XC4005XL device & was wondering if anyone else had experienced it. I'm instantiating an ABEL derived macrocell in a bit of top level VHDL. Due to the blif2net problem I used the PALASM flow under the M1 tools so that the .ngd file was derived from the .abl via .pld - .xnf. Running the MAP & PAR tools I got a design that would run @ 83.3 MHz and used 63 CLBs. Since my hoped for target speed is 100MHz I thought I was on my way & decided to try the ABEL->EDIF route in the hope of getting a few more MHz. I was surprised to find that I went backwards! The speed dropped to below 56 MHz.(33% decrease), the number of CLBs went up to 97 (50% increase) and, finally, to achieve this degradation the PAR tool took 24 min. for 3 route passes instead of the previous 8 min.Article: 8333
A summary of the September 1997 Programmable News & Views newsletter has been posted to our web site. This issue contains a lenghty arcticle on the progress of the Virtual Socket Industry Alliance. http://www.plnv.com Murray DimsanArticle: 8334
In article <348AF661.3B243D2F@CatenaryScientific.com>, Chuck Parsons <chuck@CatenaryScientific.com> wrote: > > Surely, the noise on the power supply affects the recovery time. I would >think a noisy environment would help quit a bit. Do people spec these times >with noisy or clean power? It doesn't matter. By definition, noise is just as likely to bump the flipflop *into* metastability as to bump it *out*. Think about it. -- -- Jay Lessert jay_lessert@latticesemi.com Lattice Semiconductor Corp. (voice)1.503.681.0118 Hillsboro, OR, USA (fax)1.503.693.0540Article: 8335
On 5 Dec 1997 06:47:35 GMT, "Victor Levandovsky"
<vic@alpha.podol.khmelnitskiy.ua> wrote:
>Can you help me, please?
>I wish to simulate a project with external connections
>between pin in Altera`s MAX+Plus II.
Go to Assign/ConnectedPins menu, specify the first pin (i.e. SIGOUT)
and define a group (i.e."SIGNAL"). Click Add.
Then specify the second pin (i.e. SIGIN) and select the same group.
Click Add.
Yo have to see into the window something like this:
----------------------------------------------------------
Existing connected pin groups:
SIGNAL
INPUT > sigin
OUTPUT > sigout
----------------------------------------------------------
You cannot insert more than one output pin.
You can also define connections between phisical pins (using pin
numbers) but it is better using pin names.
Anyway you can find a GOOD SUPPORT writing to SOS@ALTERA.COM
Bye!
Gianpaolo
---
The TIVPC Sysop
Email: tivpc@geocities.com
Http://www.geocities.com/Yosemite/Trails/4936
Article: 8336
On 13 Oct 1997 19:49:21 GMT, "Austin Franklin"
<dar8kroom@ix.netcom.com> wrote:
>the meaning of 'Altera' in an Italian dictionary...and here's exactly what
>it read...
>Altera - v.t. alter; adulterate; falsify.
>Kind of a bummer for Altera....may be they should have done a bit more
>research into their name before choosing it.... They probably don't do
>much business in Italy, I would guess.
(Note: I am italian)
Fortunately the word is unused, so italians make no care of it... :-)
>They don't call the Mazda Miata the Miata in Portugal....you might want to
>look that one up too!
I don't explain you italian meaning of the word "SEGA", but anyway
"Sega Master Systems" are a best-seller in Italy, although the word is
considered a "bad word".
Bye.
Gianpaolo
---
The TIVPC Sysop
Email: tivpc@geocities.com
Http://www.geocities.com/Yosemite/Trails/4936
Article: 8337In article <348AFBFF.88B86500@CatenaryScientific.com>, Chuck Parsons <chuck@CatenaryScientific.com> wrote: > As an after thought, I would think that designing in an inverter or two into flip flop >after the clock to cause a short delay, and AC coupling these outputs over the flip-flop >transistors with the right area of metal, could guarantee pushing the flip-flop out >of the metastable region in only a few hundred pico-seconds. You just need to >make the coupling large enough to push a metastable state one way or the other, >but not large enough to transition a valid state, and delayed enough so that you avoid >a race condition. Now, instead of *random* noise (which is just as likely to cause metastability as prevent it), you've added *correlated* noise (which is just as likely to cause metastability as prevent it). > This should work except for those metastable events which start to recover just before >a noise pulse. Those pulses may be just large enough so that the noise pulse throws the >system back into metastability. A subsequent pulse takes care of that. ...and is just as likely to throw the system back into metastability! :-) There's no free lunch. Speed (faster flipflops) and time (waiting for metastability to decay) are the only defenses, along, of course, with a thorough understanding of the problem you're trying to solve. -- -- Jay Lessert jay_lessert@latticesemi.com Lattice Semiconductor Corp. (voice)1.503.681.0118 Hillsboro, OR, USA (fax)1.503.693.0540Article: 8338
About 42 In article <348CDAB1.4ECC@bignet.net> Roger Blincow <"Roger Blincow"@bignet.net> writes: >what is the average amount of gates needed per device? >im looking for a ballpark estimate. >*respond to z5c@hotmail.com > >--zArticle: 8339
I need a 12 bit analog to digital converter running at 33 Msamples/sec Do you know a manufacturer able to provide this? Thanks EmmanuelArticle: 8340
<spp@bob.eecs.berkeley.edu> wrote:
>John Cooley <jcooley@world.std.com> wrote:
>
>> Yea, I do have personal opinions about Verilog & VHDL. Most
>> engineers do. What I tried very hard to do was to suppress my
>> personal views and let the contest and subsequent user response
>> settle this issue.
>
>Now, just how do you expect us to believe you have
>suppressed your personal views when your write up
>makes continuous use of phrases such as 'VHDL bigots' ??
Steve, I guess you see what you want to see. In that article I used the
phrases "VHDL bigots" *and* "Verilog bigots" -- yet you seemed to only
see "VHDL bigots".... Hmmmm...
>Anyway. I like verilog too, just wish it had types, operator
>overloading, consistent treatment of reg's vs. nets, multidimensional
>arrays, a for-generate construct, and a better preprocessor.
>I think our best shot at a truly good HDL is to upgrade
>Verilog, rather than forcing unwilling users to use VHDL
>because it is has these features.
>
>Cheers,
>
>Steve
OK, now I understand. You're citing all sorts of VHDL-only features that
only someone knowlegable in VHDL would know. (I'm bi-lingual; I use
both Verilog and VHDL quite a bit in my consulting.) My gut tells me
your bias is towards VHDL. And that's OK, too. It's very hard to not
have an opinion on anything -- and that was my main point: I, too,
have a personal opinion about Verilog and VHDL, but, in that article
and in the follow-up to it, I tried my best to just to tell the whole story
as it happened (politics and all) without cleaning it up -- and let the
reader be the judge. I'm NOT claiming to be 100 percent neutral; just
that I tried to tell the story as it happened with it's own natural
conclusions instead of my interjecting my own personal conclusions. I
hope I succeeded in doing that reguardless of whether you agree or disagree
with what the facts of the story itself.
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 5459 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: 8341In article <SAM.97Dec5161742@colossus.stdavids.picker.com>, sam@stdavids.picker.com (Sam Goldwasser) writes: > There are always asynchronous (unclocked) systems! That doesn't solve the problem, just changes it. You get the dual of the synchronizer problem - the arbiter. Consider trying to decide which of two request signals comes first. You can build a circuit that will get a correct answer but there is no promise on when the answer will be available. It might take forever.Article: 8342
Analog devices do a AD9042 which works well to ~42 MSP They also have a pin compatible 65MSP part (AD6640) which I have an evaluation board and silicon but still no issued data sheets (a year since my pre-release one!) I think these are probably amongst the best if SFDR and wideband processing are your thing. (www.analog.com and search on the part numbers) Comlinear also do a 40MSP part (oops sorry.. now called National Semiconductor) Have a look in EDN magazine (www.ednmag.com), register - its free and an excellent magazine They ran two articles this year.. 'de-mystifying ADCs' and the ironic sequel 're-mystifying ADCs'. Both contain a lot of useful advice and discussions about fast 12 bit ADCs under test. If your interested, my company's currently beginning a 65MSP design with a backend Altera 10k70 to decimate and do processing. Won't be ready for 8/9 months but could be tailored to some sophisticated processing if that's what you're looking for. Regards Paul Baxter Paje Consultants Ltd. UK email: paje@globalnet.co.uk Emmanuel Monnerie <monnerie@oconee.em.slb.com> wrote in article <348DA803.AE798ED6@oconee.em.slb.com>... > I need a 12 bit analog to digital converter running at 33 Msamples/sec > Do you know a manufacturer able to provide this? > > Thanks > Emmanuel >Article: 8343
Hal Murray wrote: > > In article <SAM.97Dec5161742@colossus.stdavids.picker.com>, sam@stdavids.picker.com (Sam Goldwasser) writes: > > > There are always asynchronous (unclocked) systems! > > That doesn't solve the problem, just changes it. You get the dual > of the synchronizer problem - the arbiter. Consider trying to > decide which of two request signals comes first. > > You can build a circuit that will get a correct answer > but there is no promise on when the answer will be available. > It might take forever. Actually Phillips makes a metastable-free arbiter. 4bit, fully asynchronous and guaranteed to aribrate between the 4 requests with no conflicts. If there is a internal metastable condition, it lengthens the arbitration time slightly, but the outputs are always clean. I forget the part number, but I used it for several designs and it worked great. -JimArticle: 8344
They do sell "Creme Puff" in Germany, although Puff means whorehouse in German. They didn't name a new Rolls-Royce the "Silver Mist", since Mist in German means manure. International names can be tricky. By the way, Altera stands for "alterable", since they were the first ones with EPROM-based programmable logic. I am "pretty sure" that this statement is correct. But you never know, we're not really on speaking terms anymore... Why is Altera so conspicuously absent in this group ? Maybe because they don't call their parts FPGAs. But if it walks like a duck, and it sounds like a duck... Peter Alfke, XilinxArticle: 8345
In article <66kjdq$vp9@src-news.pa.dec.com> murray@pa.dec.com (Hal Murray) writes:
> In article <SAM.97Dec5161742@colossus.stdavids.picker.com>, sam@stdavids.picker.com (Sam Goldwasser) writes:
> > There are always asynchronous (unclocked) systems!
> That doesn't solve the problem, just changes it. You get the dual
> of the synchronizer problem - the arbiter. Consider trying to
> decide which of two request signals comes first.
> You can build a circuit that will get a correct answer
> but there is no promise on when the answer will be available.
> It might take forever.
Right, but some people would prefer to wait forever than get an incorrect
response. With the synchronizer, you get a response quickly, but it may
be incorrect! :-).
--- sam : Sci.Electronics.Repair FAQ: http://www.repairfaq.org/
Lasers: http://www.geocities.com/CapeCanaveral/Lab/3931/lasersam.htm
Usually latest (ASCII): http://www.pacwest.net/byron13/sammenu.htm
Article: 8346Hi, you can either 1) connect the pins together through Assign menu-> Connected Pins o 2) use inputc and outputc primitives in GDF and wire the third stub of the inputc and outputc primitives together. Ying In article <01bd0149$704bd420$c3be2cc2@oleg.podol.khmelnitskiy.ua>, Victor Levandovsky <vic@alpha.podol.khmelnitskiy.ua> wrote: > >Hi! > >Can you help me, please? >I wish to simulate a project with external connections >between pin in Altera`s MAX+Plus II. > > >-- >Sincerelly, >Victor >vic@alpha.PLDpodol.khmelnitskiy.ua > >Remove PLD in adress for e-mail me. -- ----------------------------------- http://www.csua.berkeley.edu/~yingArticle: 8347
Jay Lessert wrote:
> In article <348AF661.3B243D2F@CatenaryScientific.com>,
> Chuck Parsons <chuck@CatenaryScientific.com> wrote:
> >
> > Surely, the noise on the power supply affects the recovery time. I would
> >think a noisy environment would help quit a bit. Do people spec these times
> >with noisy or clean power?
>
> It doesn't matter. By definition, noise is just as likely to bump the
> flipflop *into* metastability as to bump it *out*. Think about it.
>
> --
> --
> Jay Lessert jay_lessert@latticesemi.com
> Lattice Semiconductor Corp. (voice)1.503.681.0118
> Hillsboro, OR, USA (fax)1.503.693.0540
O.K. Jay I note your credentials and I'm probably wrong but, I'm
not convinced. In fact, I'm quite sure of the opposite. Specifically,
I agree with your statement if you are calculating the number of
times a metastable event occurs. Or if you will, the integral of
P(t)dt were P(t) is the probability that a signal of fixed rise time
arriving at time t will cause a metastable event. Noise will increase
the width of P(t) by bumping early and late events into the metastable
region and decrease the amplitude of P(t) by bumping events out. For
small noise in a linear region the area will remain constant.
But if you consider the length of the metastable events the same is
not true. At least not for all forms of noise. Once the system as
been perturbed off of the metastable point _positive_ feedback drives
it farther from the metastable point, and for modern logic in very sub
nanosecond times to the point were the noise can't reach the metastable
region anymore. Metastable events stay around in the sensitive region
by definition, non metastable events do not. If you bounce a basketball
in a room full of bats the balanced ones fall over, but the ones lying
on the floor do not jump up and balance themselves.
Now for a incoming signal that transitions from low to high it will
always pass through the metastable region so there will be a time
when the noise can mover it from "near metastable" to metastable.
But 100ps later that is not true. The metastable events can still
be bumped to one direction or the other, but the non metastable
events are too far from the metastable point to be affected.
Consider AC coupling a 100mV 200ps positive square pulse into the system
200ps after the clock. For the sake of argument let us assume that the voltage
width of the metastable state is 1mV (or you state the width it doesn't matter
as long as it is small compared to the supply voltage and the pulse ).
Do this enough times so that you have a population of metastable events.
How many of the non metastable events will be made stable?
Answer: 0
How many of the metastable events will be knocked out of the metastable region?
Answer: All that haven't already decayed.
How many metastable events will have already decayed and moved out of the
metastable region at exactly the right time so that they are between 99 and 101
mV below
the metastable region and are made metastable again?
Answer: Far less than 1%
Let me put it a different way. Suppose we have a 100MHz clock and we logically
or
the asynchronous signal with 50MZ clock offset 2.5ns from the 100MHz clock
edges.
So that for every other 100MHz clock we _have_ to see a logic one.
Theoretically,
even with a 50ps mean metastable lifetime some of those metastable events could
live ten ns. Now they are guaranteed to disappear.
I know, I know, clocking data in a second time is resetting the problem. The
100mV
200ps pulse is doing a very similar thing, think about it. Basically, an
earthquake doesn't
make it harder to balance a bat for an instant, but it makes it much harder for
it to stay
balanced for an appreciable time. True the pulse I describe does not reduce the
probability
of a event remaining metastable, beyond 400ps to zero but it does greatly reduce
it
Chuck
Article: 8348you might want to look at signal processing technologies. they have some that are rated at 30 MHz. rk --------------- Paul Baxter <paje@globalnet.co.uk> wrote in article <01bd04fc$0c6d47c0$37091ba0@paje>... > Analog devices do a AD9042 which works well to ~42 MSP > > They also have a pin compatible 65MSP part (AD6640) which I have an > evaluation board and silicon but still no issued data sheets (a year since > my pre-release one!) > > I think these are probably amongst the best if SFDR and wideband processing > are your thing. (www.analog.com and search on the part numbers) > > Comlinear also do a 40MSP part (oops sorry.. now called National > Semiconductor) > > Have a look in EDN magazine (www.ednmag.com), register - its free and an > excellent magazine > > They ran two articles this year.. 'de-mystifying ADCs' and the ironic > sequel 're-mystifying ADCs'. > > Both contain a lot of useful advice and discussions about fast 12 bit ADCs > under test. > > If your interested, my company's currently beginning a 65MSP design with a > backend Altera 10k70 to decimate and do processing. Won't be ready for 8/9 > months but could be tailored to some sophisticated processing if that's > what you're looking for. > > Regards > > Paul Baxter > Paje Consultants Ltd. > UK > > email: paje@globalnet.co.uk > > > Emmanuel Monnerie <monnerie@oconee.em.slb.com> wrote in article > <348DA803.AE798ED6@oconee.em.slb.com>... > > I need a 12 bit analog to digital converter running at 33 Msamples/sec > > Do you know a manufacturer able to provide this? > > > > Thanks > > Emmanuel > > >Article: 8349
fliptron@netcom.com (Philip Freidin) wrote: >About 42 > >In article <348CDAB1.4ECC@bignet.net> Roger Blincow <"Roger Blincow"@bignet.net> writes: >>what is the average amount of gates needed per device? >>im looking for a ballpark estimate. >>*respond to z5c@hotmail.com >> >>--z > > Yes, Yes, I know. That's the answer to life, the universe, and everything! Too easy. But which color gates? That ought to keep you busy a little longer.
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