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
oded@asp.co.il wrote: > anyone know of a solution for this problem - some high pinout device which > is not the biggest and most expensive in it's family? I hate to keep sounding like a salesman for AT&T, but the ORCA chips have pretty high I/O capability. The 1C07 has 224 pins and sells for about $150. The 2C08 also has 224 pins and goes for about $180. (I've estimated these prices from some notes that I have from an AT&T salesman. They are close, but check with AT&T for actual prices.) Also check out a company called I-cube which makes crossbar chips.Article: 1701
In article <40cv0k$5o7@btmpjg.god.bel.alcatel.be> Yuce Beser, yuce@sh.bel.alcatel.be writes: >If you have critical time constraints that are difficult to be achieved, then >it is better to specify these time constraints and leave the placement of IOs >to the router. For some designs, it is not possible to satisfy both the time > I know this is a standard argument, but I have serious doubts as to its usefulness for Xilinx designs. Quite simply, there is a high chance that the physical board (and thus the pin allocation) already exists. For what it is worth, my experience is that the time to route is affected by fixed pin placement rather than the performance - at least, if general performance constraints are given. If the design is to be routed frequently, it seems worth keeping data bus lines in rough order. I appreciate the argument also put forward in this thread regarding ensuring the chip can be floorplaned. One caution to this is that you may wish to use another Xilinx with compatible footprint on the same board, and although the pins will have similar functions the positioning of the pads need not be the same. [or does someone know differently] Similarly if you change package, the linked pins may differ. What is worth fixing in some designs is to allocate clocks etc to global buffers - which cuts down skew. _____________________________________________________________ Dr John Forrest Tel: +44-161-200-3315 Dept of Computation Fax: +44-161-200-3321 UMIST E-mail: jf@ap.co.umist.ac.uk MANCHESTER M60 1QD UKArticle: 1702
Actel is introducing a new line that has ram built in. The first part will not be available till next year. The family name is 3200DX. The amount of dual ported sram ranges from 2kbits to 4kbits. -- __________________________________________________ | | | homebrew is the elixir of the gods | | | --------------------------------------------------Article: 1703
chjintag@sydney.DIALix.oz.au (Chris Jones) writes:
>I am developing some VHDL source code. By contract I must pass on
>a copy of said code to another company, but I do not want to make it
>easy for them to understand the concepts and I wish to hide the
>intellectual property which is behind the code. The easy way of
>doing this is to remove all the comments, relabel all variables and
>signals, and if I got more adventorous , rework the architecture.
Jeff Nicoll <jnicoll@netrix.com> wrote:
>Now, I may be new to VHDL and I may be naive, but if I
>contracted with someone to do some work and that work
>included the delivery of source code and I got some
>undecipherable crap in place of real source code, I would
>not be a happy customer and I probably wouldn't do business
>with that someone again. I certainly wouldn't think much
>of your ability to write intelligible code. This customer
>apparently wants the knowledge, not just the code. The
>source code is how the knowledge is transferred. I might
>even go so far as to consider your actions in bad faith.
Jeff, I think you're bang on that the client company will be damned
pissed if they were expecting readable source code and instead get
executable-but-incomprehensable source Verilog/VHDL! But, if Chris
set this expectation with the customer beforehand then he's being a
clever boy in protecting his intellectual property. Remember:
Consultants are seen as disposable employees -- the moment they stop
providing value their contract can be cancelled in a heartbeat!
- 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 3443 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: 1704I have a question about XILINX FPGA's. I have done 3 previous designs using the 4010 and 4013-5 devices but now I am running into a problem where my simulations do not indicate any problems with the design as far as timing, however in the lab I have some boards (using 4013) that seem to have race problems. What i mean is that some of the state machines go to the wrong states on some of the FPGA's where as on others they are very robust. I have had some fail at room temperature and others could not be made to fail at all over the specified 0-70C range. Looking at the report file all of the timing spec have been met (with margin), XDELAY does not indicate any delay problems and simulation of the back annotated file using ViewSim does not show and problems. The device is running at 10 Mhz. Also as side note, 95% of my design is implemented with VHDL. The packed CLB usage is 60% and the utilized CLB's are 85%. One thing that I have tried on the problem state machines is to have Synopsys synthesize them using gray code rather than binary and this has seemed to solve the problem. Also all flops are using a global buffer and I have looked at the lca file with the floorplanner to see if the clock bus is doing anything crazy and all looks ok.. Any suggestions on how I can detect these types of problems in simulation? has anyone else experienced this? Thanks for any help Tony pn@anuxt.att.com :Article: 1705
In article <1995Aug16.203135.24706@super.org>, <GCAT@dorval.mpbtech.qc.ca> writes: > Hello, > > My current FPGA application uses Actel FPGAs with small external look- > up tables using about 2kbits to 8kbits of RAM. I am now considering > options for my second generation and am looking at FPGA families with > on-board RAM. > > As far as I can determine, my options are AT&T and Xilinx, whose > PLCs and CLBs can be used as small RAM blocks. I have also read that > Altera is cooking up a new family with embedded diffused SRAM blocks. > > Does anyone know if this new family is out? As anyone used it? > > Does anybody have any experiences to share regarding the use of RAM > in Xilinx and AT&T? Any problems with routability, timing? Does > it impact on percentage utilization in the logic portion of the > design? How do the tools handle RAM? > > Any input welcome.... Thanks > > > Catherine Gyselinck ---------------------------- > MPB Technologies | Speak softly but carry | > gcat@dorval.mpbtech.qc.ca | a +6 two-handed sword | > tel: (514) 683-1490 ---------------------------- > fax: (514) 683-1727 Also check the INtel FLexLOGIC parts - the cells in these can be 128x8 RAM, I believe.Article: 1706
John Cooley (jcooley@world.std.com) wrote: : chjintag@sydney.DIALix.oz.au (Chris Jones) writes: : >I am developing some VHDL source code. By contract I must pass on : >a copy of said code to another company, but I do not want to make it : >easy for them to understand the concepts and I wish to hide the : >intellectual property which is behind the code. The easy way of : >doing this is to remove all the comments, relabel all variables and : >signals, and if I got more adventorous , rework the architecture. : Jeff Nicoll <jnicoll@netrix.com> wrote: : >Now, I may be new to VHDL and I may be naive, but if I : >contracted with someone to do some work and that work : >included the delivery of source code and I got some : >undecipherable crap in place of real source code, I would : >not be a happy customer and I probably wouldn't do business : >with that someone again. I certainly wouldn't think much : >of your ability to write intelligible code. This customer : >apparently wants the knowledge, not just the code. The : >source code is how the knowledge is transferred. I might : >even go so far as to consider your actions in bad faith. : Jeff, I think you're bang on that the client company will be damned : pissed if they were expecting readable source code and instead get : executable-but-incomprehensable source Verilog/VHDL! But, if Chris : set this expectation with the customer beforehand then he's being a : clever boy in protecting his intellectual property. Remember: : Consultants are seen as disposable employees -- the moment they stop : providing value their contract can be cancelled in a heartbeat! This is clearly a CYA tactic. Legally speaking, it will work okay. But I would not do it unless I were desperate, or unless I hit a Eureka jackpot! True, consultants are often considered disposable: that's the nature of consulting contracts. But in bad times, so are employees. In good times, there isn't a whole lot to worry about it... : - John Cooley : Part Time EDA Consumer Advocate : Full Time ASIC, FPGA & EDA Design Consultant -ShankarArticle: 1707
Don Husby (husby@fnal.gov) wrote:
[snip]
: Also check out a company called I-cube which makes crossbar chips.
If you plan on contacting I-Cube, an address might come in handy:
I-Cube Inc. Phone: (408) 986-1077
2328-C Walsh Avenue FAX: (408) 986-1629
Santa Clara, CA 95051 Email: marketing@icube.com
--
Kind regards,
Jo Depreitere
====================================================================
- Many dead animals of the past changed to fossils, others
preferred to be oil.
====================================================================
e-mail : jdp@elis.rug.ac.be
URL : http://www.elis.rug.ac.be
Phone : ++32+9/264 34 09
Fax : ++32+9/264 35 94
Address: University of Ghent
Electronics and Information Systems Dept.
Sint-Pietersnieuwstraat 41
B-9000 Ghent
Belgium
====================================================================
Article: 1708nickg@hpqt0220.sqf.hp.com (Nick Gent) writes: >Martin Curran-Gray (marting@hpqt0219.sqf.hp.com) wrote: >: Nick Gent (nickg@hpqt0220.sqf.hp.com) wrote: >: : I'll try again - my last posting got chopped in half (why?)... [snipped the great saga] >: From a .xnf file generated from a Mentor schematic with TIMESPEC and >: TIMEGROUP properties: >This is rapidly becoming a farce. >John, I've mailed you the file that was meant to be appended to these >messages - handle with care :-) >Nick As a reader who would love to see this listing, I wonder is there something (a non-printing character perhaps) turning up in those Mentor files, which upsents the news programs? Just a thought FWIW... -- David R. Brooks <daveb@perth.DIALix.oz.au> Tel/fax. +61 9 434 4280 PGP public key via finger or keyservers Public key fingerprint: 20 8F 95 22 96 D6 1C 0B 3D 4D C3 D4 50 A1 C4 34Article: 1709
In article <DDGG36.LtG@asp.co.il> oded@asp.co.il writes: >hello, >we are designing a latched crossbar switch for digital video, which is >part of an image processor board. >it's general profile is a device very high in IO - around 200 pins - but relatively low >in core logic. the conventional FPGAs that we know of are limited in user >IO, and when they have enough user IO (>200) they are the biggest and most expensive >devices. >anyone know of a solution for this problem - some high pinout device which is not >the biggest and most expensive in it's family? > >thanks > >oded Xilinx has 2 devices designed just for you :-) The XC4003H (160 I/O and 3K gates), and the XC4005H (192 I/O and 5K gates). Both are at the low end of the XC4000 family in terms of gate count, so may meet your needs. They also have a very nice I/O driver section that goes a long way to reducing ground bounce for high I/O devices. See page 2-90 and 2-91 in their data book for some scope pics of I/O transitions, page 8-6 thru 8-9 for other I/O characteristics. The author looks like he might know what he is writing about :-). Other Xilinx chips you may want to look at include the XC3195A (176 I/O in PQ208 package, 6.5K gates), and XC5210 (196 I/O and 10K gates) and XC5215 (244 I/O and 15K gates). In the category of interconnect with NO logic there are two companies products you should look at, I-Cube and Aptix. Both these companies make FPIC (field programmable interconnect chips) devices. The I-Cube parts are full cross bars, and the Aptix devices use segmented routing channels to implement the programmable interconnect. Altera makes the 81188 (184 I/O and 12K gates) and the 81500 (208 I/O and 16000 gates) To build arbitrary shaped switches you can combine lots of QuickSwitch (tm) devices from Quality Semiconductor but the largest thing they have currently that I know of is an 8 to 1 mux type device, but at 250pS through time it is way faster than anything above, but clearly does not meet your high I/O requirement. In the "insane products with no home" category, Latice have an EEPROM based parts with 14 or 18 or 22 I/O pins and 7.5nS thru time. Atmel has the AT6010 with 204 I/O and 10K gates, but as you noted, it falls (like the XC3195A and 81500 ) into the category of highest I/O on devices with the most gates. All data above taken from my most current data book for each manufacturer. If I didn't represent your product in the most glowing light possible, it's your own fault for not giving me the most upto date data books. Your milage will vary. Not responsible for typagrophical errors. All opinions are the responsibility of Bill Clinton. The author wishes you luck. Philip Freidin.Article: 1710
In article <DDHAFM.1E2@world.std.com> jcooley@world.std.com (John Cooley) writes: >chjintag@sydney.DIALix.oz.au (Chris Jones) writes: >> Chris writes about developing VHDL code which he is contractually bound >> to pass on the source code, and asks how to minimize is re-useability >Jeff Nicoll <jnicoll@netrix.com> wrote: >> Jeff Nicoll comments that this is probably not what the customer is >> expecting, and will not be happy. He suggests that this may be >> counter productive if a follow on contract is ever available. > John Cooley, farmer at large writes: >Jeff, I think you're bang on that the client company will be damned >pissed if they were expecting readable source code and instead get >executable-but-incomprehensable source Verilog/VHDL! But, if Chris >set this expectation with the customer beforehand then he's being a >clever boy in protecting his intellectual property. Remember: >Consultants are seen as disposable employees -- the moment they stop >providing value their contract can be cancelled in a heartbeat! > Philip Freidin writes: I also agree strongly with Jeff. Given the context, it seems unlikely that John's suggestion that expectations may have been set this way, and this is ok and clever. John's comments about consultants being disposable, is irrelevant. Consultants are paid the big bucks because they deliver unique expierence and skills, and because they are disposable. Being disposable is not a justification for un-ethical behaviour. If the consulting contract calls for delivery of source code (schematics, VHDL, C,... ) then it is clear that the company wants to be able to work with the material that was contracted for, and may in the future want to debug, or enhance or otherwise change the delivered material. If you don't like the conditions, don't do the contract. If you want to do the contract but don't like the conditions, negotiate conditions that you do like: i.e. License or royalties for re-use of the deliverables might be appropriate for this case. Philip Freidin.Article: 1711
The problem you are having may be related to the source of signals that control transition terms in your state machines. If there are any asynchronous inputs to your state machine, then they MUST be passed thru at least 1 synchronizing FF, and if at all possible, a two stage synchronizer. The observation that gray coded state encoding help points at this, but if you really have async inputs, the gray coding will reduce the probability of errors, but will not eliminate them. Philip Freidin. In article <DDHF6s.9rM@nntpa.cb.att.com> pn@anuxt.mv.att.com (a.palmieri) writes: > > I have a question about XILINX FPGA's. I have done 3 previous >designs using the 4010 and 4013-5 devices but now I am running >into a problem where my simulations do not indicate any >problems with the design as far as timing, however in the lab >I have some boards (using 4013) that seem to have race problems. >What i mean is that some of the state machines go to the wrong >states on some of the FPGA's where as on others they are very >robust. I have had some fail at room temperature and others >could not be made to fail at all over the specified 0-70C >range. Looking at the report file all of the timing spec >have been met (with margin), XDELAY does not indicate any >delay problems and simulation of the back annotated file >using ViewSim does not show and problems. The device is >running at 10 Mhz. Also as side note, 95% of my design is >implemented with VHDL. The packed CLB usage is 60% and the >utilized CLB's are 85%. > >One thing that I have tried on the problem state machines is >to have Synopsys synthesize them using gray code rather >than binary and this has seemed to solve the problem. Also >all flops are using a global buffer and I have looked at the >lca file with the floorplanner to see if the clock bus is >doing anything crazy and all looks ok.. > >Any suggestions on how I can detect these types of problems >in simulation? has anyone else experienced this? > >Thanks for any help > >Tony >pn@anuxt.att.comArticle: 1712
In article <40npo6$jsj@yama.mcc.ac.uk> John Forrest <jf@ap.co.umist.ac.uk> writes: >Does anyone know the format of timespecs in Xilinx XNF v5. I want to >include >some in a handwritten xnf file. > >Even an example would help. > >John > >_____________________________________________________________ >Dr John Forrest Tel: +44-161-200-3315 >Dept of Computation Fax: +44-161-200-3321 >UMIST E-mail: jf@ap.co.umist.ac.uk >MANCHESTER M60 1QD >UK Here is some XNF for you... (snip-snip-snip) (the three lines folling the 'SYM' line are all supposed to be on the one line. i.e. the following is only 2 lines long, a SYM line and the END line. The long line is probably what has been screwing up other posters) SYM, $1I390, TIMESPEC, LIBVER=2.0.0, TS_MSDC_2=FROM:MSDC_ID_PAD:TO:PADS=100.0, TS_MSDC_1=FROM:MSDC_ID_PAD:TO:PIPE_FF=100.0, TS_DSP_010=FROM:DSP_CE_PAD:TO:DSP_DATA_IN_PAD=40.0 END ( here is how a flipflop is added to the group of PIPE_FF, that is used in the above TIMESPEC) SYM, MSDC_IN/$1I17/$1I37, INFF, HIERG=83, TNM=PIPE_FF, INIT=R, LIBVER=2.0.0 PIN, C, I, CLK PIN, D, I, MSDC_IN/EXT_SEG_0_3 PIN, Q, O, SEG_0_P_3 END ( here is how an I/O pad is added to a group) EXT, DSP_IF/EXT_MSDC_ID, I, , LOC=P31, TNM=MSDC_ID_PAD All the best Philip FreidinArticle: 1713
In article <1995Aug16.203135.24706@super.org> <GCAT@dorval.mpbtech.qc.ca> writes: >Hello, > >My current FPGA application uses Actel FPGAs with small external look- >up tables using about 2kbits to 8kbits of RAM. I am now considering >options for my second generation and am looking at FPGA families with >on-board RAM. > >As far as I can determine, my options are AT&T and Xilinx, whose >PLCs and CLBs can be used as small RAM blocks. I have also read that >Altera is cooking up a new family with embedded diffused SRAM blocks. > >Does anyone know if this new family is out? As anyone used it? I believe that these parts will be available around the end of the year. They will have a block of ram that can be configured as by 1,2,4, or 8 bits wide, and in the by 8 config, the block is 256 bytes. There will be 1 block per logic row, so on an 81188 type device, there would be 6 such blocks Altera recently swallowed the Intel FlexLogic (tm) product line. These are like a small bunch (8) of 24v10 style pals in one package (the iFX780). Alternatively, any of the 8 blocks can be used as a 128 by 10 bit SRAM. > >Does anybody have any experiences to share regarding the use of RAM >in Xilinx and AT&T? Any problems with routability, timing? Does >it impact on percentage utilization in the logic portion of the >design? How do the tools handle RAM? > >Any input welcome.... Thanks > > >Catherine Gyselinck ---------------------------- I have been using the Xilinx devices with RAM for more than 5 years, so I think that counts as expierence :-). The routing has never been a problem for me, but I am certain that is because I always floor plan the memory structures. (I have posted an article recently on how I do floor planning of datapath structures). The timing associated with reading the RAMS is just like the timing around combinatorial logic. Not really a serious issue. Writing is another story. The XC4000 and the ATT ORCA products both create some interesting challenges for writing, because the routing delays are unpredictable, and minimum times are never guaranteed (except for min 0nS). The problem is that the address must get to the RAM before the WE, and the data and address must be still stable after WE goes away. The way to achieve this is to build a state machine that cycles thru a setup, write and hold phase. This can limit system performance. Xilinx presents detailed explanation of the issues and possible design solutions in their data book from page 8-127 thru 8-147. The latest familly from Xilinx, the XC4000E solves this problem in a much better way: The write interface is synchronous. You have to meet setup specifications just like a flip flop, and all the details of write timing are handled for you. Basically, you need to get address, data and WE to the RAM before a clock edge, and like a FF with CE, the RAM will take a snap shot of address and data on the clock edge and if the WE was high, it will write it. Like CLB FFs, hold times are not an issue. From a performance standpoint, you can probably achieve real RAM write cycle times of 15nS, including routing. Another nice feature of the XC400E parts is the RAM can be placed into a dual port mode, with independent read and write addresses. This is great for register files, and FIFOs. In the last week or two I have done designs for clients with the following memory structures. None have had routing or timing problems in the RAM section (because of floor planning) XC4010 1 RAM, 256 words by 12 bits XC4008E 16 RAMs, each 32 words by 9 bits XC4008E 2 FIFOs, each 16 words by 24 bits wide XC4010 1 RAM, 64 words by 32 bits, and 1 RAM 16 words by 16 bits All the best, Philip FreidinArticle: 1714
John Cooley (jcooley@world.std.com) wrote: > Jeff, I think you're bang on that the client company will be damned > pissed if they were expecting readable source code and instead get > executable-but-incomprehensable source Verilog/VHDL! But, if Chris > set this expectation with the customer beforehand then he's being a > clever boy in protecting his intellectual property. Remember: > Consultants are seen as disposable employees -- the moment they stop > providing value their contract can be cancelled in a heartbeat! Shankar Hemmady <hemmady@professionals.com> wrote: >This is clearly a CYA tactic. Legally speaking, it will work okay. >But I would not do it unless I were desperate, or unless I hit a Eureka >jackpot! > >True, consultants are often considered disposable: that's >the nature of consulting contracts. But in bad times, so are employees. >In good times, there isn't a whole lot to worry about it... Shankar, I think you might be missing my point. Chris might be the world's expert on ATM's and PC busses. His customer may have contracted him to develop some hot part of their new video chip. Chris's value-add *is* his ATM/PC bus experience -- the source Verilog/VHDL he provides to implement this is just a vehicle for getting Chris's clever ideas in silicon. What Chris would have done is cut a contract that explicitly said he was going to provide executables that were nicely functional but encrypted. This is not desperation but protecting ideas that Chris brought to the table that he developed on his own time. Here it makes sense for Chris to do encryption. Big (and little) corporations do this all the time! Just because you're a consultant doesn't mean the contracting company owns everything you ever invented just because they gave you a 3 week contract. But, in contrast, if the client has all the design ideas and just wants help implementing it and hires one as a consultant, it would be unthinkable to surprize the customer with functional-but-encrypted source Verilog/VHDL. The foolish, soon to be ex-consultant will be dealing with a rightfully pissed client. Here the consultant is just making a grab for false job security. The key here is whether, as a consultant, you're applying your *own* special intellectual property (like a better/faster ATM design or video compressor or bizarre divide-by-0 function) to solve a customer problem versus trying to implement *their* ideas for them. - john cooley ----------------------------------------------------------------------------- __)) "Glass ceilings? Name ANY goat farmer who's made it into management!" /_ oo (_ \ Holliston Poor Farm - John Cooley %// \" Holliston, MA 01746-6222 part time Sheep & Goat Farmer %%% $ jcooley@world.std.com full time contract ASIC & FPGA DesignerArticle: 1715
>John Cooley (jcooley@world.std.com) wrote: >> Jeff, I think you're bang on that the client company will be damned >> pissed if they were expecting readable source code and instead get >> executable-but-incomprehensable source Verilog/VHDL! But, if Chris >> set this expectation with the customer beforehand then he's being a >> clever boy in protecting his intellectual property. >Shankar Hemmady <hemmady@professionals.com> wrote: >>This is clearly a CYA tactic. Legally speaking, it will work okay. >>But I would not do it unless I were desperate, or unless I hit a Eureka >>jackpot! jcooley@world.std.com (John Cooley) writes: >His customer may have contracted >him to develop some hot part of their new video chip. Chris's value-add *is* >his ATM/PC bus experience -- the source Verilog/VHDL he provides to implement >this is just a vehicle for getting Chris's clever ideas in silicon. What >Chris would have done is cut a contract that explicitly said he was going >to provide executables that were nicely functional but encrypted. (sorry for the long context quote, but the thread was getting vague) Let's ask Chris: Were you explicit in the contract that they would not be able to modify the HDL source? Was your deliverable silicon, or simulation? Is there a design review or delivery milestones that allow the company to find out what you did, or will it be a surprise when their in-house staff comes back to look at it later? Would you feel good about telling your key technical contact at the company what you did? I lean toward delivering too much rather than too little. If you stiff a company, you damage all consultants in the future (who will labor under the cloud of your legal but questionable tactics). On the other hand, if you write a good contract that states the source will be compilable but is not required to be human readable, you've protected yourself ethically. -- SRE * * * - - - - - - - - - - - - - - - * * * * Eckert Enterprises Steve Eckert eckert@netcom.com * * * * - - - - - - - - - - - - - - - * * * * ftp: 192.100.81.1 415-508-0500 fax: 415-508-0501 * * * * - - - - - - - - - - - - - - - * * * TRY THIS: echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dcArticle: 1716
Philip Freidin <fliptron@netcom.com> wrote: >I also agree strongly with Jeff. Given the context, it seems unlikely >that John's suggestion that expectations may have been set this way, and >this is ok and clever. John's comments about consultants being disposable, >is irrelevant. Consultants are paid the big bucks because they deliver >unique expierence and skills, and because they are disposable. Being >disposable is not a justification for un-ethical behaviour. If the Whoa! Whoa! I AM NOT ADVOCATING SURPRIZE ENCRYPTING ON CLIENTS!!!! What I'm saying is IF Chris was contracted to put in some special thingy that Chris and only Chris knows about because Chris invented it on his own time, etc. -- it would be wise for him to do that. Companies do this all the time! Why should Chris be different just because he's a one man show? That is, if he has some special circuit that can predict lottery numbers successfully 80% of the time two hours before they're drawn, Chris *should* protect it! He'll probably get zillions of offers from companies interested in his circuit. If he's wise, he'll give it to them in encrypted form. I mean, shit, ASIC foundries do this all the time with rather uninteresting libraries and macros; if Chris has something of value, why should he be different? If Chris was a fool, he'd give the lotto predictor circuit unencrypted to his clients.... BUT, IF Chris was working on an everyday contract where not much new whiz bang inventing is going on -or- it's whiz bang inventing with *someone* *else's* (i.e. the client company's) intellectual property, then he had better not try a fast one by encrypting Verilog/VHDL source delivered to customers. For what it's worth, I've never done any encrpyting on customers. But, I have been asked by customers to encrypt something that they were going to give to another company! - john ----------------------------------------------------------------------------- __)) "Glass ceilings? Name ANY goat farmer who's made it into management!" /_ oo (_ \ Holliston Poor Farm - John Cooley %// \" Holliston, MA 01746-6222 part time Sheep & Goat Farmer %%% $ jcooley@world.std.com full time contract ASIC & FPGA DesignerArticle: 1717
We have found the same problem in some 4010-4 designs that we are doing that are running at 30 Mhz. What we have concluded is that the delay model the XDELAY uses for the clock distribution is very inaccurate with the real clock delay from the global clock buffer to any flop being much more load dependent. The end result is that there is a much greater clock skew between flops than XDELAY tells you. With low device utilization this doesn't appear to be a problem. We never got a real answer out of Xilinx as to what the actually delays are but our local apps guys have admitted that the clock model is not very good. Our only proof of this was to measure clock to output delays on different signals and noticing that there is a much wider variation in actual delays than one would expect. Nick WarcholArticle: 1718
Emanuel Fontes (efontes@telepac.pt) wrote: : Hello. : Does anyone can help find and Email address where i can place some doubts : to Xilinx about Viewlogic version of their development system ? : Emanuel Fontes join the xilinx users mailing list, send a request to xilinx-users-request@sandia.gov with the following in the body of the mail list:add your_email_address -- cheers, yadav email: yadav@cse.iitb.ernet.inArticle: 1719
Are you using the state registers in an asynchronous manner? For example, if you are decoding the state registers and using the results in a cct which is part of another clock domain, the glitches that you will get because the state flip-flops don't all change at the same time may be considered as valid if they happen near the clock of the other domain. Also, if you are using the state registers to perform some kind of async reset, not using gray coding will definitely screw things up. Note: I'm sure you know this but just in case, gray coding only has one bit which changes from one count to the next. When decoding a gray-coded counter, you won't see any glitches. I won't go on about this since you probably are aware of the concept. Hope this helps, Allan Isfan Bell Northern ResearchArticle: 1720
> Subject: Re: Obscuring Code For Customers I would like to introduce another angle to the subject of obscuring code..... > > John Cooley (jcooley@world.std.com) wrote: > : chjintag@sydney.DIALix.oz.au (Chris Jones) writes: > : >I am developing some VHDL source code. By contract I must pass on > : >a copy of said code to another company, but I do not want to make it > : >easy for them to understand the concepts and I wish to hide the > : >intellectual property which is behind the code. > With the coming of reconfigurable computing, it is quite possible that designs will come from individual creativity and not a contract. It is this case I wish to explore. With the introduction of Hardware Objects(HO) (digital designs to be included in an application program for 'hardwiried acceleration') used on reconfigurable computing systems, we anticipate many individuals designing useful functions to be used like 'c' libraries. In these cases, the 'customer' would not be interested in 'source code' but rather useability. At the same time the designer should have the opportunity of marketing these HO's in a secure format. There will be in the coming year(s) a new opportunity for reusable functions to have general market value. To protect the intellectual property one can certainly place a copyright label within the design, but it would seem that some form of incryption would be useful. I am not only speaking of VHDL, but verilog, schematic etc. designs. Are there any comments on this ? Thanks, John Schewel, Virtual Computer CorporationArticle: 1721
Hot Summer, 1995
Digital Scope.FAQ - Version 1.10
:::::::::::::::::::::::::::::::::::::
::Date/Time | O O ::
:: /\ | ::
:: / \ | O O ::
:: / \ /\ | ::
::__/ \ / \ /`| O O ::
:: \ / \/ | ::
:: \ / | O O ::
::1 GHz BW \/ 2 GS/s |________::
::________________________|A B C D ::
:: rise 1.5 ns | x x x ::
:: fall 4.9 ns | x x x ::
::_________________________________::
::(*) (*) (*) (*) (*) (*) ::
:::::::::::::::::::::::::::::::::::::
::: :::
Dear Technologists:
This Digital Scope.FAQ file contains many (but not all) of your answers to the
more "Frequently Asked Questions" re: Digital Storage Oscilloscopes (DSOs).
Key Issues reviewed in this file include:
* DSO INDUSTRY TRENDS (Whats happening in DSO technology in 1995?)
* DSO FORM FACTORS (What types of DSOs are there?)
* PRIMARY DSO FUNCTIONS (What can DSOs actually do?)
* APPLICATIONS (What are the most common DSO applications?)
* ADCs (What speed do I really need on each channel?)
* BANDWIDTH & TRIGGER (What numbers and functions are right?)
* ARCHIVAL & MEMORY (How fast, how deep, and can I get more?)
* DISPLAYS (What am I really looking at?)
* MEASUREMENTS (How much is my signal changing over time?)
* DIGITAL SIGNAL PROCESSING (How can I obtain more useful information?)
* DEMOS & PURCHASING (How can I see and get the DSO I really need?)
The answers and suggestions come from > that a decade of my experience as a
DSO sales engineer in Boston, MA. The opinions are mine and represent no
company or service - they are meant simply to be helpful, generic, and easy
to understand.
Feel free to contact me anytime (john@wd1v.mv.com) if you have additional
questions or comments.
*If you want the latest version of this file sent to you automatically, send an
EMAIL where the subject field contains the text "subscribe scope.faq".
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DSO INDUSTRY TRENDS 1995
MORE DSOs ARE NOW SOLD THAN ANALOG SCOPES. Expect most new scope models to be
DIGITAL and have faster sampling, higher bandwidths, deeper memories, and lower
costs than in 1994. COMPARABLE MODELS HAVE FALLEN IN PRICE BY ABOUT 50% IN THE
LAST 4 YEARS. The DSO market is very competitive - thats good news for buyers.
DSOs STILL VARY IN PERFORMANCE IN A VARIETY OF WAYS. Each manufacturer provides
a certain degree of standard features, but their different design schemes
produce unique performance strengths and weaknesses. Compare and evaluate.
Specifications: Model X Model Y Model Z
============================= ======= ======= =======
Max Transient Sample Rate
Max Repetitive Sample Rate
Analog BW
Timebase Range Max
Timebase Range Minimum
Volts/Div (Range)
Cust. Vertical Rescaling (Y/N)
Vertical Resolution (# of bits)
Number of Channels
Max Samples on all Channels
Max Samples on 1 Channel
Display Size (Diagonal)
Display Resolution
Display Type
CPU (Type and Clock Speed)
Math Co-Processer (Y/N)
Maximum FFT Record Size
Multiple Zooms per Trace (Y/N if Y, #?)
Multiple Grids for full 8 bits
Multiple Cursors per Screen (Y/N if Y, #?)
Pulse Parameters (#Total/#Viewable)
External Trigger Input (Y/N)
Time Stamps on Segments (Y/N)
Timing on Peak Detects (Y/N)
Statistics on Parameters (Y/N)
Roll Mode Acquisitions (Y/N)
Pass/Fail Masks & Parameters (Y/N)
Chained Math Operations (Y/N if Y, #?)
Free Firmware Upgrades (Y/N if Y, #?)
Memory Upgrades (Y/N)
Video Trigger (Y/N)
High Density DOS Disk (Y/N)
Hard Disk (Y/N)
High Speed Built-In Printer (Y/N)
FFT (Y/N)
Histogramming (Y/N)
Advanced Mathematics (Y/N)
Standard Warranty (Number of Years)
Prices w/ all options ($)
SMART CHOOSERS typically let their S I G N A L S determine the primary
specifications (Sample Rate, BW, Memory Depth, Trigger BW, etc.) and let
their A P P L I C A T I O N determine secondary specifications (I/O,
Measurement, DSP, etc.).
MAINFRAME POWER IS NOW IN THE NEWEST PORTABLES. DSOs now can include memory
depths > 1M samples per channel and offer processing options such as
HISTOGRAMMING or FFTs on up to 6M samples.
DSOs ARE GETTING EXTREMELY COMPUTATION INTENSIVE. Deeper memories, multiple
channels, high resolution displays, and enhanced DSP routines tax the
fastest CPUs and smartest firmware. Latest designs use multi-processor
architectures. SMART CHOOSERS must know the CPU specifications as well as the
key DSP benchmarks.
DSOs AREN'T JUST FOR TRANSIENT CAPTURE ANYMORE. Latest DSOs can now process
multiple sweeps and generate envelopes, compute statistics, do complex DSP
functions, conduct stand-alone tests, archive and print data, and even FAX DSO
screens with measurement and test results to/from remote sites.
DSOS ARE BEING OPERATED BY MORE COMPUTERS as redundant tests and measurements
are being automated. Most DSOs come with IEEE-488 and RS-232 interfaces and
offer remote programmability and data transfer. Most DSOs have free or low
cost device drivers for popular software packages.
DSOs ARE THE HIGHEST BW OSCILLOSCOPES AVAILABLE. The highest BW "ANALOG"
scope currently in production is only 400 MHz. while several DSOs go well
beyond 1 GHz. The future is clearly digital!
MAXIMUM REAL-TIME SAMPLE RATES (Single Shot) can now go to 10 Giga-samples in
1 new portable DSO model just announced.
ACQUISITION MEMORY DEPTHS are expanding from 10 K to 50 K (typical MINIMUMS)
and up to 8 Million samples (maximum).
CLOSENESS TO SOURCES IS ALSO GOOD NEWS FOR SMART CHOOSERS. The vast majority
of the DSOs that are sold in the United States are manufactured by US
Corporations making delivery, service, calibrations, and support most
convenient.
UPGRADE PATHS for firmware and hardware expansions are becoming common.
but not all models can be upgraded - another issue of concern for SMART
CHOOSERS.
DSOs ARE THE PRIMARY DEBUGGING TOOLS FOR HIGH SPEED DIGITAL CIRCUITS since
they can now sample so rapidly and trigger on so many different fault
conditions.
TRIGGER RATES are becoming an important specification with varying
amounts of information per trigger or sweep.
SOME DSO MANUFACTURERS ARE OFFERING COLOR DISPLAY OPTIONS. Some versions
utilize the colors cleverly with COLOR GRADED PERSISTENCE.
While many applications only require a single channel DSO, MOST USERS ARE NOW
PURCHASING 4 CHANNEL DSOs.
SOME manufacturers can INTERLEAVE the CHANNELS of their DSOs so that, for
example, in a 2 channel model, twice the sample rate is achieved when using
just 1 channel compared with both channels being used.
SOME manufacturers can INTERLEAVE the MEMORIES of their DSOs so that, for
example, in a 2 channel model, twice the memory depth is achieved when using
just 1 channel (and twice the recording time) compared with both channels
being used.
SOME manufacturers can INTERLEAVE CHANNELS and MEMORIES. *SOME
OFFER THIS FEATURE ONLY WITH THEIR DEEPEST MEMORY OPTIONS - be careful.
Functions are increasing so the USER INTERFACE IS GAINING INCREASING IMPORTANCE.
Features need to be extracted as needed - quickly and without a lot of button
pushing, knob twisting, or frequent trips to the user's manual.
DSOs WITH FLOPPY DISK DRIVES ARE THE RULE VS. THE EXCEPTION. Almost all new
units offer them - either as options or as standard features.
SOME MANUFACTURERS ARE NOW OFFERING BUILT IN HARD DISKS that are removable and
thus, transferable, (via PCMCIA interfaces) to laptops or PCs.
MOST DSO MANUFACTURERS OFFER A NUMBER OF FREE SERVICES:
o Full line catalogs and price sheets
o DSOs for evaluation on your signals with a "how to use it" demonstration
o Application Notes that relate how to take specific measurements or tests
o Seminars to teach basic DSO technology
o Seminars to teach application specific techniques
o Competitive DSO COMPARISONS
o TRAINING after delivery for most rapid return on investment
o TOLL-FREE TELEPHONE APPLICATIONS ASSISTANCE to support their platforms
o Drivers for third party SOFTWARE used for remote control and analysis.
The primary American manufacturers of DSOs are:
o Fluke Corporation 800 443-5853 in Everett, WA
o Hewlett-Packard 800 452-4844 in Palo Alto, CA
o LeCroy Corporation 800 553-2769 in Chestnut Ridge, NY
o Tektronix Corporation 800 426-2200 in Beaverton, OR
(If you are outside of the United States, contact a local sales office)
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DSO FORM FACTORS
DSOs are now available in 5 different form factors:
1) PC CARD - A to D on a card that uses a PC's CPU and memory - PCB Style
Interesting due to low cost. Look out for noise problems from some PC's
backplanes.
2) STAND ALONE CARD - DSO on a card for embedded systems - PCB Style
Interesting due to low cost, small size, fewer noise issues - greater
functionality.
3) HANDHELD - Portable capabilities - Portable Style Battery operated for
field measurements.
4) PORTABLE - with some amount of upgrade capabilities - Portable Style
Performance approaching mainframes and low cost due to high competition,
high volume, and large scale integrations.
5) MAINFRAME - typically with plug-ins that determine performance - Lab Style
Highest cost but highest performance and greatest versatility.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PRIMARY DSO FUNCTIONS
The 5 Primary Functions of a DSO are to:
1) CAPTURE.....the signal
2) VIEW........the signal
3) MEASURE.....the signal
4) ANALYZE.....the signal
5) DOCUMENT....the signal
CAPTURE = consider SAMPLE RATES, MEMORY DEPTH, BANDWIDTH, TRIGGER,
NUMBER OF CHANNELS, and PROBES.
(Here you should have a predetermined knowlege of the highest frequency
signal you need to digitize, what its full scale amplitudes are, and whether
or not you need to capture single shot or repetitive waveforms. If these issues
are unclear to you, review them with your sales engineer.)
VIEW = consider ADC resolution, DISPLAY resolution, Display size,
DSP results, and ZOOM EXPANSIONS.
MEASURE = consider PULSE PARAMETER requirements, CURSORS, and STATISTICS.
ANALYZE = consider DSP, PASS/FAIL Testing, MASK Comparisons, and EYE Diagrams.
DOCUMENT = consider PRINTING, SCREEN SHOTS to DISK, and DATA TRANSFERS.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
APPLICATIONS
DUE TO EXPANDING FUNCTIONS AND CAPABILITIES, DSOs lend themselves to a
wider variety of application areas. Like a computer, the more applications you
can use an instrument for, the more valuable it is and the easier it is to
justify. Here are a few for you to consider:
o The most obvious one is to use a DSO as an OSCILLOSCOPE. Typical
applications are electronic circuit design and debug and troubleshooting
faulty or intermittent circuits.
o Another common application is as the front end of a DATA ACQUISITION SYSTEM.
DSO's cost per channel has become very competitive. Many people find that the
triggering flexibility, deep memory, "live" view of waveforms, and fast
transfer rates make the DSO a great candidate. If your experiment is short
lived, it is nice to have a DSO when you are done vs. a black box that gets
shelved and forgotten. Typical applications are research experiments, process
monitoring, and flaw detections.
o DSOs lend themselves to being fully integrated into ATE SYSTEMS. In this
example, the DSO is under remote control from a host computer and conducts
its business by computer command. Typical applications are incoming Quality
Assurance of components, Manufacturing/Production Functional Test, Final
Test, and System Test.
o DSOs can be used (card level or portable rack mounted form factors) and can
be embedded into systems that require Analog to Digital conversion and data
analysis. Here the DSO is used as a SYSTEM COMPONENT and eliminates the need
and time of engineering custom devices.
o DSOs DISPLACE/REPLACE MANY DEDICATED INSTRUMENTS - i.e. DMMs, Spectrum
Analyzers, Impedance Analyzers, Time Interval Analyzers, Frequency Counters,
Pulse Counters, Power Meters, etc.
Some of the common DSO Application fields include:
o Aerospace
o Automotive Electronics
o Avionics
o Chemistry
o Computer Backplanes/Interfaces
o ElectricalComponents
o Electric Power
o EMP/EMI/EMC
o LASERS
o Lightning Studies
o Magnetic Media <Disks>
o MATE
o Medical
o NDT
o Networks/Communications <ATM, FDDI, Ethernet, AX.25,etc.>
o Noise/Acoustics
o Power Supply Design/Manufacturing
o Process Control
o RADAR
o Semiconductor Design/Manufacturing
o SONAR
o Telecomm (Switches, Cellular,Telemetry)
o Ultrasound Vibration/Mechanical Analysis
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ADCs
ADCs - SPEED
LOOK OUT for short record length DSOs that can only sample at maximum rates
for short periods of time. Ideally, the sample rate value should be
displayed on
screen all the time. BE CERTAIN YOU CAN SAMPLE FAST ENOUGH IN REAL TIME
(SINGLE SHOT) MODE ON ALL CHANNELS NEEDED FOR THE RECORDING TIME NEEDED SO AS
NOT TO ALIAS!
Another point of confusion are SAMPLE RATES specified for REPETITIVE vs.
SINGLE SHOT acquisitions. REAL-TIME refers to SINGLE SHOT and RIS refers to
Random Interleaved Sampling. RIS is sometimes called ET or EQUIVALENT
TIME sample mode.
The sample rate speed of the DSO's analog to digital converter is a very
important specification. It is the minimum time between each sample. For
instance, a 500 MS/sec. sample rate relates to 2 ns. per point resolution.
Multiply the number of sample points * the sample period to determine a
DSO's maximum recording time @ maximum sample rate.
Many people confuse the SAMPLE RATE speed with the BANDWIDTH. BANDWIDTH is
simply the analog front end performance (preamplifier and sample and
hold circuitry).
ADCS - RESOLUTION
This refers to full scale resolution. An 8 bit digitizer will divide full scale
input voltages by 255 counts. Thus the minimum discernible sampled value on a 1
volt full scale 8 bit DSO would be 1 / 256 or .00390 volts per step.
If you have repetitive waveforms, you can increase your vertical resolution
with AVERAGING.
If you have transient waveforms, you can increase your vertical resolution by
low-pass filtering each sweep <FIR> for ENHANCED RESOLUTION.
ADCS - ACCURACY
Not all ADCs are created equally. The most common figure of merit is
EFFECTIVE BITS that relate the number of correct bits of a given ADC's actual
measurements vs.ideal.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BANDWIDTH & TRIGGER
BANDWIDTH
BW is the amount your signal will be attenuated by the DSOs front end amplifier
- specified at the -3dB point - as a function of input frequency. Remember
that BW ratings are at the input to the amplifier and that your PROBES might
also attenuate your signals. If you are looking at signals > 50 MHz, try a
FET probe.
Remember that -3dB is down in amplitude by almost 30%. You probably DON'T want
a 30% error in your amplitude measurements. Consider the higher BW DSOs so your
measurements will be accurate.
LOOK OUT! Many DSOs have BW ratings that reflect their best performance but
only in certain voltage ranges.
LOOK OUT! Some DSOs reduce sample rates by the number of channels activated.
This could cause aliasing by changing the relationship of how fast the DSO is
sampling vs. the BW of the signals you are digitizing.
Many DSOs have analog BW specifications far greater than their SINGLE-SHOT
sample rate's Nyquist (.5 sample rate) frequency. This is so that when
repetitive waveforms are viewed, the maximum BW signals can be seen.
TRIGGER
If you can't TRIGGER on the waveforms you need to see, you have a real
problem! This should be center stage for your demo if you are looking at a new
DSO. There are various trigger capabilities and a combination of them that are
easy to use that capture your waveforms is the most desirable.
Know how frequently you need to trigger. The maximum trigger rate is a key
specification that isn't often published in manufacturer's specifications as
there can be many variables. Evaluate and compare!
Some DSOs have a MEMORY SEGMENTATION feature that lets you trigger very
rapidly and fill just a portion (1 segment out of #n segments) per
trigger.
Most DSOs will let you trigger on the width of pulses <GLITCH>, the INTERVALS
between pulses, the LOGICAL or PATTERN conditions between inputs, after
specific delays by events or time, drop out conditions, etc. Compare!
Look for TRIGGER ICONS that relate how the current trigger selection is
working. This is very helpful if you are looking at a screen dump later and
trying to reacquire with the same trigger conditions.
DSOs are valuable tools for looking at video signals but not all DSOs offer a
video trigger as a standard feature. Compare!
DSOs can almost always capture single shot events but not always with the
amount of pre or post trigger delay you might need. If your application
requires capturing a lot of transient waveforms, look into the span of trigger
delay as an important spec.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ARCHIVAL & MEMORY
ARCHIVAL
FLOPPY DISKS - They are nice - should be MS-DOS and should come with
file formatter so you can convert to ASCII and back then back to binary.
HARD DISKS - They are becoming available and offer the same kind of
convenience that is realized in PCs.
MEMORY CARDS - They are expensive but they are fast - up to 200 times faster
than a floppy. Require reader at PC to use the data.
PRINTERS/PLOTTERS - They are the best way of showing the world your waveforms
and your measurements. Plotters are great for elegant color - most impressive
for overheads.
ARCHIVAL DATA FILE TYPES:
WAVEFORM FILES - Binary but with conversions to ASCII for import into other
programs and from ASCII back to DSO's binary format.
SET UP FILES - Most DSOs have front panel setups that you can recall and store
either in nonvolatile memory in DSO or to disk.
SCREEN SHOTS - "Print to disk" graphics files that are screen dump imports
into your word processor.
MEMORY
Tricky! Manufactures specify their largest numbers. Look out for some
DSO's acquisition memory values that divide by the number of active channels.
Don't confuse acquisition memory with reference memory specifications.
Reference memory is used for copies of waveforms recorded earlier and made
available for comparison either by viewing or by mathematics. Some DSOs have
longer acquisition memories than reference memory. Compare!
Not all DSOs have the same number of reference memories. More are better. Make
sure they have the width to contain your processed data. You can't store 12
bit averaged waveform data in 8 bit reference memory. Compare.
Not all DSOs have the same number of memories for front panel set-up/storage
and recall. Compare.
Some manufacturers offer MEMORY CARDS for additional reference memory.
Some DSOs allow for MEMORY SEGMENTATION where you can acquire multiple trigger
events in a single sweep display. A few models will also record the time of
each trigger event that occurred.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DISPLAYS
NOT ALL DSOS ARE CREATED EQUALLY - ESPECIALLY THEIR DISPLAYS! The best
compact an entire sweep of acquisition memory onto a single screen with a
min/max algorithm. The benefit is that you don't have to page thru screens to
see the interesting details in your data. Min/max compaction makes faults
obvious.
IDEALLY, THE SCREEN WILL BE LARGE enough so that you can see the WAVEFORMS and
MEASUREMENTS clearly at the SAME TIME. Look out for small diagonal measurement
displays that put measurements on top of the waveform data.
DSO displays are typically specified in terms of resolution and diagonal size.
The higher the resolution, the easier it will be to see fine details and the
better your publications that have imported DSO screens will appear. The
larger the diagonal size, the greater the chance of being able to see critical
information on screen all at the same time vs. pages of menus.
IDEALLY, YOU SHOULD HAVE ALL THE INFORMATION ON SCREEN THAT YOU WANT IN YOUR
REPORT. Consider things like trigger parameters, ICONS, measurements, input
and timebase settings for each trace, sample rate, cursors and their
measurements for each trace, clock/calendar. That is a lot of information on
screen. How does it look?
IDEALLY, YOU SHOULD HAVE THE ABILITY TO EXPAND OR ZOOM in on DIFFERENT PARTS
of your waveforms to see details more clearly and to limit your measurements
to within a given region of data. This means MULTIPLE EXPANSION WINDOWS are
best.
Ideally, the graticule <grid> should be done in software and allow multiple
traces to be displayed, each within their own grid. This preserves the full
scale voltage input ranges for best accuracy.
Ideally, the DSO display should have a report of what the front panel status
is so that the entire setup of the DSO can be observed, verified,
replicated, and printed.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MEASUREMENTS
NO MORE FINGERPRINTS ON THE SCREEN FROM COUNTING GRID SQUARES! Modern DSOs
display precise measurements of any waveform you capture.
Measurements are either made with CURSORS or automatically with PULSE PARAMETERS
such as as RISE TIME, RMS, FREQUENCY, etc. seen right on the display.
Ideally, the PULSE PARAMETERS should include STATISTICS so you can see and
measure HOW MUCH YOUR WAVEFORMS ARE CHANGING with every new trigger or
acquisition.
Cursors should show:
ABSOLUTE AMPLITUDE at a given point
ABSOLUTE TIME <from trigger> at a given point
RELATIVE AMPLITUDE <difference in amplitude between any 2 points>
RELATIVE TIME <difference in time between any 2 points>
Ideally, EACH TRACE should have its own set of cursors for SIMULTANEOUS
measurements on all displayed traces.
You should be able to make measurements automatically on all displayed traces.
PAY CLOSE ATTENTION TO THE DSO'S ABILITY TO DETECT AND MEASURE SIGNALS THAT
ARE CHANGING. THIS IS OFTEN OVERLOOKED AND YET IT IS OFTEN THE MOST NEEDED
CAPABILITY.
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DIGITAL SIGNAL PROCESSING <DSP>
DSP is doing math on the waveforms so additional information can be obtained.
Some instruments really slow down when DSP is being performed. Ask for benchmark
specifications on the key functions you need. Don't waste your time looking at
DSOs that just aren't fast enough.
Another DSP concern is that some manufacturers don't process an ENTIRE
waveform because of poor CPU power. Make sure the data you need processed
is really being processed!
Another DSP concern is that you may wish to do a SERIES of functions. How many
functions can be chained varies from model to model. Compare!
Consider these potential DSP functions:
Arithmetic (Add, Subtract, Multiply, Divide any traces)
Averaging (Remove random noise, improve resolution)
Enhanced Resolution (Smoothing, improves resolution at reduced BW)
Functions (Integrate, Differentiate, Envelope, etc.)
FFT (Spectral analysis of any trace)
Histograms (Distributions of measured values)
Pass/Fail Testing (Comparisons of live waveforms to masks or measurements)
Trending (Time series of measured values)
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DEMOS & PURCHASING
BEFORE THE DEMO
BE IN TOUCH WITH YOUR BUSINESS NEEDS as they relate to your DSO needs. Are you
going to faster designs soon that might impact the banner specifications
you'll need in the near future?
WRITE DOWN EXACTLY WHAT YOU EXPECT THE NEW DSO TO DO. Make it your "Wish
List". Try to find out what the most popular DSO is for your application.
GET A SENSE OF HOW SOLID YOUR BUDGET IS and how soon you can place an order
once you make a decision. If it is more than 6 months away and your short term
needs are critical, consider rental or lease.
PLAN SEVERAL DIFFERENT DEMOS WITH DIFFERENT MANUFACTURERS. Let them know it is
a "competitive situation" and you want the best DSO you can get that meets
your needs. You'll get a lot of attention and the best of services.
SCHEDULE THE DEMOS IN YOUR LAB INSTEAD OF YOUR CONFERENCE ROOM. You'll be
closer to your signals and the real environment <what noise?> where the DSO
will have to work.
YOU SHOULD PLAN TO SEE A DEMO OF THE EXACT MODEL DSO YOU ARE THINKING OF USING
- with all the options you believe you'll need - conducted by a Sales Engineer
that knows the instrument and what you need it to do extremely well.
THE DSO MANUFACTURER's SALES ENGINEER SHOULD BE A GREAT RESOURCE TO YOU. By
reviewing your application and assisting you with a model selection that is
technically correct, your demo will be much less likely to disappoint you or
anyone else.
If you have never met the Sales Engineer, plan to start with a quick tour of
your facility. Explain why you need the DSO showing them the area that it will
be used in and what you expect it to do. The tour may let your Sales Engineer
see things that will help you that you hadn't thought about.
DURING THE DEMO
A quick overview of the DSO's banner specifications and key features is a good
place to start the demo. Focus quickly on how to drive the front panel and
how to extract the various functions. If it looks complex, save front panels
you'll need to recall. Ask questions.
You should see your signals on screen EARLY into the demo and plan to borrow
the DSO for at least a few days to evaluate it if the demo goes well.
THE DEMO SHOULD PROVE THAT THE DSO MODEL BEING DEMOED CAN DO YOUR SPECIFIC
APPLICATION(S). If the demo can't do that, you are probably wasting time by
evaluating it further AFTER the demo. If the DSO has to do a specific task,
see it happen at the demo and learn how to replicate the settings so you can
do it after the Sales Engineer leaves.
PAY ATTENTION TO THE NUMBER OF BUTTONS that have to get pushed to go from one
operation to the next. If the demo is really canned, force some hopping around
so you see typical vs. streamlined operation.
Find out how long the DSO model you are looking at has been on the market. Ask
for MTBF figures <Mean Time Between Failures>. Find out where the closest
service center is and how long a typical repair or calibration turnaround
might take.
If you are a LARGE company, find out who else in your company is using the
same/similar DSO from the Sales Engineer. Chat with the other users.
If you are a SMALL company, find out who else in your industry within your
area is using the same/similar DSO from the Sales Engineer. Chat with the
other users.
Take as much time as you like. Don't rush it. Ask questions. Record answers.
Enjoy the process. If you get saturated, take a break and return.
Check the demo DSO that will be left for evaluation to make sure:
o That it will accept your full scale voltages
o That it samples fast enough to capture your waveforms with high fidelity
o That it is not affected by other signals in your environment
o That it has the options necessary to take your measurements
o That it has a manual covering operations
o That you have the applications engineering telephone number for support
during your evaluation period
DURING THE EVALUATION
MAKE NOTES OF THE QUESTIONS YOU HAVE AND RECORD THE ANSWERS. It will keep you
focused.
CALL THE FACTORY'S APPLICATION'S GROUP AND TEST THEM to see how well they
answer your questions. Get application notes sent to you that address your
areas of interest. Is there ever a telephone or service charge for contacting
them?
DON'T BELIEVE THERE IS ONE DSO THAT DOES EVERYTHING. Most labs have a variety
of DSOs for various functions.
Try this experiment with the DSO you are considering. Connect a signal source
up to the DSO where you can vary the amplitude of the signal by very small
amounts. The waveform should have at least 3 or 4 complete cycles on screen
and be 90% of full scale. Once you have a stable trigger, store a copy of the
waveform into a reference memory. Then activate math so that all new waveforms
are being subtracted from the waveform in reference memory. See how little you
can change the amplitude level on the generator to see and measure the
difference with the DSO. Remember: A large part of the utility of a DSO is
verifying that things are exactly as they should be and seeing when they
aren't.
AFTER THE EVALUATION
IF THE DSO DIDN'T MEET YOUR EXPECTATIONS, MAKE SURE YOU KNOW WHY and include
the new things you've discovered in your Wish List that you've learned.
PURCHASING
Get a list of ALL OPTIONS available for the DSO so that you can
order the exact configuration that really addresses your needs. Make sure you
and your Sales Engineer determine issues that might include:
o Memory Expansion Options
o Waveform Processing Options
o Disk Drive Options
o Printer Options
o Hardware Options <External clock, video trigger, I/O, iso amps,etc.>
o Active Probes
o Probes with different attenuations than those supplied with the DSO
o Scope Cart
o Rack Mount
o Hard Shell Transit Case for safe shipping your DSO to remote sites
o Probes for all channels <Not all DSOs come with a probe/channel!>
You should also explore the manufacturer's policies and costs regarding:
o Applications Assistance
o Calibrations- NIST, MIL, Performance Checks, ISO-9000, At-Site Service
o Capabilities for Training Users
o DSO System Software/Firmware Upgrades
o Warranty Period - Extensions
You should GET A WRITTEN QUOTATION that relates the model, specifications,
options, all costs, delivery, and any discounts available. Most manufacturers
offer Educational, GSA, Quantity, and/or Demo discounts if you qualify.
You might also consider rental or leasing options. Most rental companies offer
equity rentals where rental/lease fees apply towards purchase. AT&T CAPITAL
CORPORATION is an excellent source of information concerning this
@ 800-874-7123.
-eof-
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
John D. Seney, WD1V Internet: john@wd1v.mv.com
144 Pepperidge Drive America On Line: jseney@aol.com
Manchester, NH 03103-6150 AX.25 Pkt: wd1v@wb1dsw.nh.usa.na
(H) 603-668-1096 Ampernet: wd1v@wd1v.ampr.org
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
LeCroy Sales Engineering - Maine, New Hampshire, and Northeastern
Massachusetts
(O) 800-553-2769 (F) 603-627-1623 (P) 800-SKYPAGE #5956779
Personal Opinion Source for Digital Storage Oscilloscope.FAQ
To obtain the latest copy automatically, simply send me an EMAIL
with "subscribe scope.faq" in the subject field.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Article: 1722Sounds like it would be a cinch to reverse engineer anyway. I'm not convinced it's a hot idea. If you have something that copyrighted and/or patented, you can collect royalties. You have to play the market and negotiate in good faith. If any contractor has been stiffed, please, please, tell us who did it! John WilliamsArticle: 1723
Hello. Do any of you know the new url for the list of FPGA Fased Computing Machines? The old url was 'http://bongo.cc.utexas.edu/~guccione/', but my web-client complains, and says that the server (bongo.cc.utexas.edu) doesn't have a DNS entry. Jon G. Solheim Department of Computer Science and Telematics Norwegian Institute of TechnologyArticle: 1724
randraka@ids.net wrote:
>
>
> [snip]
>
> >4. If you are using higher placer efforts, you might also want
> > to try different seeds. I guess the seeds does matter for
> > placer efforts > 4
> >
> The tool uses a new seed everytime it runs unless you specify a seed in the
> cst file. You can set the tool up to run multiple times (like if you leave it
> to route overnight) using different seeds. If you are getting the same
> unrouted nets each time regardless of your seed, this won't help. See item 7
> below. As far as manually assigning seeds, I see no value at all unless you
> are trying to duplicate an earlier route and you know the seed that was used.
> There is no way to predict whether a given seed is a good one or a bad one.
> The seed affects the placer regardless of the placer effort. It essentially
> gives a starting point for the placement algorithm. The results on two
> consecutive runs using the same design and a different seed can be markedly
> different at any placer effort level.
>
I would like to add a couple of comments to placement startng seeds.
1. Last time I talked to chaps at Xilinx, xc4000 default placement
algorithm (placer_effort=2 or even placer_effort=3) does not use
any derivations of the famous seed based algorithms. But xc3000(a)
uses this seed based algorithm. Note that this only for xact5.0 or
later software
By this I mean that varying the seeds at lower placer_efforts(2,3)
would continue to give you the same result [unless something
is screwed up in my version of the software :-( ]
2. Also you cannot vary the seeds using cst file.
You could use
command line : ppr <design> seed=<seed>
XACTINIT.DAT file : /ppr/seed = <seed>
paramfile : seed = <seed>
-JB
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