Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 1700

Article: 1700
Subject: Re: high pinout - low logic devices
From: husby@fnal.gov (Don Husby)
Date: 17 Aug 1995 17:51:44 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: external connections for efficient internal routing
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 17 Aug 1995 19:47:15 GMT
Links: << >>  << T >>  << A >>
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
UK


Article: 1702
Subject: Re: FPGAs with embedded RAM
From: scott@momus.gordian.com (Scott Murphy)
Date: Thu, 17 Aug 1995 21:43:31 GMT
Links: << >>  << T >>  << A >>
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
Subject: Obscuring Code For Customers (was VHDL Obfuscators)
From: jcooley@world.std.com (John Cooley)
Date: Thu, 17 Aug 1995 23:26:10 GMT
Links: << >>  << T >>  << A >>
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: 1704
Subject: Simulation not matching lab results
From: pn@anuxt.mv.att.com (a.palmieri)
Date: Fri, 18 Aug 1995 01:08:51 GMT
Links: << >>  << T >>  << A >>

 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.com

:


Article: 1705
Subject: Re: FPGAs with embedded RAM
From: granville@decus.org.nz
Date: 18 Aug 95 18:29:26 +1200
Links: << >>  << T >>  << A >>
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
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: hemmady@professionals.com (Shankar Hemmady)
Date: 18 Aug 1995 00:11:24 -0700
Links: << >>  << T >>  << A >>
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

-Shankar


Article: 1707
Subject: Re: high pinout - low logic devices
From: jdp@elis.rug.ac.be (Jo Depreitere)
Date: 18 Aug 1995 07:14:51 GMT
Links: << >>  << T >>  << A >>
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: 1708
Subject: Re: Timespecs in XNF format
From: daveb@perth.DIALix.oz.au (David Brooks)
Date: 18 Aug 1995 16:38:28 +0800
Links: << >>  << T >>  << A >>
nickg@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 34 


Article: 1709
Subject: Re: high pinout - low logic devices
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Aug 1995 10:40:45 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Aug 1995 11:03:36 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Simulation not matching lab results
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Aug 1995 11:10:22 GMT
Links: << >>  << T >>  << A >>
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.com




Article: 1712
Subject: Re: Timespecs in XNF format
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Aug 1995 11:21:17 GMT
Links: << >>  << T >>  << A >>
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 Freidin



Article: 1713
Subject: Re: FPGAs with embedded RAM
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Aug 1995 11:52:23 GMT
Links: << >>  << T >>  << A >>
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 Freidin




Article: 1714
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: jcooley@world.std.com (John Cooley)
Date: Fri, 18 Aug 1995 14:13:38 GMT
Links: << >>  << T >>  << A >>
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 Designer


Article: 1715
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: eckert@netcom.com (Steven R. Eckert)
Date: Fri, 18 Aug 1995 15:11:44 GMT
Links: << >>  << T >>  << A >>
>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'|dc


Article: 1716
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: jcooley@world.std.com (John Cooley)
Date: Fri, 18 Aug 1995 17:31:33 GMT
Links: << >>  << T >>  << A >>
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 Designer


Article: 1717
Subject: Re: Simulation not matching lab results
From: warchol@cloud.enet.dec.com ()
Date: 18 Aug 1995 17:34:34 GMT
Links: << >>  << T >>  << A >>

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 Warchol


Article: 1718
Subject: Re: Email Address of Xilinx
From: yadav@bhishma.cse.iitb.ernet.in (Navneet S Yadav)
Date: Fri, 18 Aug 1995 17:41:03 GMT
Links: << >>  << T >>  << A >>
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.in			


Article: 1719
Subject: Re: Simulation not matching lab results
From: Allan Isfan <aisfan@bnr.ca>
Date: 18 Aug 1995 21:50:51 GMT
Links: << >>  << T >>  << A >>
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 Research



Article: 1720
Subject: Design protection
From: john@vcc.com (John Schewel)
Date: Fri, 18 Aug 1995 21:51:19 GMT
Links: << >>  << T >>  << A >>
> 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 Corporation



Article: 1721
Subject: Digital Scope.FAQ
From: john@wd1v.mv.com (John Seney)
Date: Sat, 19 Aug 1995 00:01:15 GMT
Links: << >>  << T >>  << A >>
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: 1722
Subject: Re: Obscuring Code For Customers (was VHDL Obfuscators)
From: jwill@netcom11.netcom.com (John Williams)
Date: Sat, 19 Aug 1995 05:11:19 GMT
Links: << >>  << T >>  << A >>
Sounds 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 Williams


Article: 1723
Subject: List of FPGA Based Computing Machines
From: jon@idt.unit.no (Jon Gunnar Solheim)
Date: 20 Aug 1995 15:34:29 +0200
Links: << >>  << T >>  << A >>

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 Technology



Article: 1724
Subject: Re: Xilinx xc4013 routing problems ??
From: "Bond , James" <bond@rahul.net>
Date: 20 Aug 1995 19:19:12 GMT
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search