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 5825

Article: 5825
Subject: Re: PLC
From: jpjcet@mindspring.com (Paul Jones)
Date: Tue, 18 Mar 1997 22:55:53 GMT
Links: << >>  << T >>  << A >>
"Apolonio B. Sanches" <paulsan@asti.dost.gov.ph> wrote:


>To all


>I'm making a survey regarding the limitations in features of PLCs.

I am assuming you are talking about Programable Logic Controllers
typically used in industrial controls

>I would like to have your comments on what improvements or added
features 
>should be added or improved in today PLC.

The line betweeen PLCs and Personal Computers has become very grey in
the past couple of years.  PLCs have had more complex algorithms added
to them since the '80s.  The capabilities of PLCs have approached that
of the PC, but the PC is more suitable for data aquitsition and
control (something industrial engineers and managers want).

I see PLCs going the way of the panel-box-full of relays.  A PC with a
Controller Area Network doing the work of a PLC as well as data
aquisition will be the standard in the future.

>What are the important things you look for in choosing a PLCs?

I look for a PLC that will match the job at hand, reliabilty and if
necessary,  expandabilty.


Lisa Jones
Fit by Design. . .

Article: 5826
Subject: EDA tools
From: Dirk Brandis <brandis@dlcc.com>
Date: Tue, 18 Mar 1997 14:57:30 -0800
Links: << >>  << T >>  << A >>
Anybody have thoughts/recommendations on the following tools for
FPGA/ASIC design:

1) VeriBest (currently reselling Synopsys FPGA Express)
2) Synplicity
3) Exemplar
4) Synario
5) Viewlogic

Thanks!
Article: 5827
Subject: Re: Xilinx 4002 RAM Question
From: gjhurlbu@beirdo.uplink.on.ca (Gavin Hurlbut)
Date: Wed, 19 Mar 1997 04:29:13 GMT
Links: << >>  << T >>  << A >>
Peter Alfke (peter@xilinx.com) wrote:
> In article <L3ZHANG.18.3324A6E7@ELECOM2.watstar.uwaterloo.ca>,
> L3ZHANG@ELECOM2.watstar.uwaterloo.ca (Louis Zhang) wrote:
> 
> 
> > Unfortunately, unlike the discrete RAM and RAM cell in ASIC, the RAM cell in 
> > Xilinx 4000 has address and data setup/hold time requirements. 
> 
> Whenever I read "hold time" my blood pressure goes up 10 mm.
> The XC4000E data sheet lists hold time as 0, i.e. ZERO.
> So, don't worry about hold time. And EVERY clocked device has a set-up time.

Unfortunately, the prototype board (BORG board) that Louis (and myself -- in
the same class) is required to use in his project contains (interconnected
to each other and interfaced to a PC via an ISA card connected to one of
the 4002 chips):

	2 x 4002APC-6
	2 x 4003APC-6

At least that is what we were told.  So the specs of the 4000E series
unfortunately do not apply.  :)

Unforunately again, our lab group is having a real painful time of trying
to get our design to work on the BORG board.  It simulates perfectly in
Compass-DA (both the VHDL synthesized and backannotated versions), but
does not operate AT all on the hardware...  We are going to talk to the
lab tech for the course tomorrow.  But I am rambling as usual :)  Sorry.
I shall go to bed now.  G'night.

-- 
	Gavin J. Hurlbut		  gjhurlbu@beirdo.uplink.on.ca
   4B Electrical Engineering		---------------------------------
     University of Waterloo			School sucks.
	 My Homepage:  http://amprgate.uwaterloo.ca/~gjhurlbu/
Article: 5828
Subject: Re: Multiple clocks in Xilinx
From: Brad Taylor <blt@emf.net>
Date: Tue, 18 Mar 1997 21:45:18 -0800
Links: << >>  << T >>  << A >>
David Gesswein wrote:
> 
> Has anybody found any documentation on using multiple clocks in a xilinx
> 4000/5200 part?  The question I have is how to transfer signals between the two
> clock domains.  Can you use a low skew external clock generator and the internal
> clock distribution including the two global clock buffers skew will be small
> enough that the hold time when a register feeds a register will be met or
> do I have to treat the clocks as asynchronous or use different edges or
> other methods to ensure that the signal will be transfered reliably?
> 
> The reason for the two clocks is that most of the design should run at a slower
> clock but a little bit needs to run faster so using the clock enable to
> simulate the slower clock seems excessive.
> 
> I talked to the hotline but they didn't have any application information on the
> use of multiple clocks.
> 
>

This all relates to the clock skew spec. Lets see, if you look in the
book it's ...
hmmm .. it isn't there. But there is a FF hold spec of 0 ns. If we
assume a min delay for any clock to input path of 0 ns, that would imply
a clock skew of 0.000 ns. Note the fine precision of my calculation. So
how do we ge skew of 0.000 ns?

In my experience it is impossible to deliver 2 matched clocks to a chip
with a guaranteed skew of less than .5 ns.  That skew would violate the
skew spec of 0.000 ns, but lets assume they are 'identical', (because
you measure them).

The pad to clock delay will be 0 ns to Tcin, where Tcin is the value
found by using 'xdelay syntax' FROM:PADS(clk_in):TO:FFS(*).  Typical
delays will be 5-10 ns.  If you assume max delay for one clock and min
delay for the another, the clock skew could be 5-10 ns. This is of
course greater than the spec of 0.000 ns so it won't work. 

However the value is dependent on clock loading and the delays will
track to some degree.  In general they will be within 1 or two ns. So
lets assume they were identical because you adjusted the number of clock
loads to make them match. If you apply the "not-guaranteed" tracking
ratio of 70% you will have a skew of .3*8 ns=2.4 ns. This is greater
than the spec time of 0.000 ns, so we are still illegal.

But lets assume full tracking because you actually XOR the two clocks
together on the FPGA and adjust the phase of one of the clocks with an
off chip PLL.  Now our skew is say 0.1ns. Maybe this will work?  Nope it
still violate the spec of 0.000 ns. 

So lets abandon the whole concept of two clocks and just see if we can
just clock data from one register to another with the same clock. 
Typically, Xdelay spews out the following skew:

"
Source clock net : "mem0_clk" (Rising edge)
From: Blk em0_data<7>_p  CLOCK to P121.I1            :    2.8ns ( 
2.8ns) 
Thru: Net mem0_data<7>_1       to CLB_R11C13.F4      :    5.7ns ( 
8.5ns) 
Thru: Blk _write_ptrs4_xor<6>  to CLB_R11C13.X       :    2.0ns (
10.5ns) 
Thru: Net _write_ptrs4_xor<6>  to CLB_R10C13.F3      :    1.4ns (
11.9ns) 
Thru: Blk ip_write_ptrs4_equ1  to CLB_R10C13.X       :    2.0ns (
13.9ns) 
Thru: Net ip_write_ptrs4_equ1  to CLB_R13C12.F3      :    1.4ns (
15.3ns) 
Thru: Blk ip_write_ptrs4_equ   to CLB_R13C12.X       :    2.0ns (
17.3ns) 
Thru: Net ip_write_ptrs4_equ   to CLB_R14C12.F4      :    1.1ns (
18.4ns) 
Thru: Blk ip_write_ptrs4_lop   to CLB_R14C12.X       :    2.0ns (
20.4ns) 
Thru: Net ip_write_ptrs4_lop   to CLB_R12C11.F1      :    1.7ns (
22.1ns) 
Thru: Blk ip_write_ptrs4_i1    to CLB_R12C11.X       :    2.0ns (
24.1ns) 
Thru: Net ip_write_ptrs4_i1_1  to CLB_R11C20.F2      :    3.2ns (
27.3ns) 
Thru: Blk sram0_write          to CLB_R11C20.X       :    2.0ns (
29.3ns) 
Thru: Net sram0_write          to CLB_R1C20.G1       :    2.3ns (
31.6ns) 
  To: FF Setup (D), Blk mem0_ose                     :    3.0ns (
34.6ns) 
Target FFX drives output net "mem0_sram"
Dest clock net : "mem0_clk" (Rising edge)
 Clock delay to Source clock pin : 1.7 ns
 Clock delay to Dest clock pin   : 1.5 ns
 Clock net "mem0_clk", delta clock delay [skew] : -0.3 ns

"

Well Xdelay might not be too good on math, but lets assume the skew
really is -0.3 ns. 
Of course -0.3 ns violates the derived legal spec of 0.000 ns. I guess
we have to conclude that we can't clock from one register to another
even using the same clock.  

OK, what the hell. If Xilinx can cheat its own spec, I guess you can.
But I might try the following instead:

Assume a 2x clock ratio. Advance the slow clock by say 5ns from the fast
clock.  This ought to cover any distribution skew.  You can legally
clock from the slow clock edge to the fast clock, and visa versa. Just
avoid latching slow data on the odd fast clock cycles.


Cyc        :     0     :     1     :     2     :     3     :     4     :
CLK1
______/-----\_____/-----\_____/-----\_____/-----\_____/-----\_____/-----\
CLK2
___/-----------\___________/-----------\___________/-----------\___________/
C1data
-X=======================X=======================X=======================X
C2data
-===X===========X===========X===========X===========X===========X===========X
        |<>| 5ns
        |<------------>| Tsu_c2_c1
                       |<------>| Tsu_c1_c2      

Hope this helps.
-
Brad
Article: 5829
Subject: Re: Multiple clocks in Xilinx
From: Brad Taylor <blt@emf.net>
Date: Tue, 18 Mar 1997 22:06:42 -0800
Links: << >>  << T >>  << A >>
Brad Taylor wrote:

> Typically, Xdelay spews out the following skew:
> 
> "
> Source clock net : "mem0_clk" (Rising edge)
> From: Blk em0_data<7>_p  CLOCK to P121.I1            :    2.8ns (
> 2.8ns)
> Thru: Net mem0_data<7>_1       to CLB_R11C13.F4      :    5.7ns (
> 8.5ns)
> Thru: Blk _write_ptrs4_xor<6>  to CLB_R11C13.X       :    2.0ns (
> 10.5ns)
> Thru: Net _write_ptrs4_xor<6>  to CLB_R10C13.F3      :    1.4ns (
> 11.9ns)
> Thru: Blk ip_write_ptrs4_equ1  to CLB_R10C13.X       :    2.0ns (
> 13.9ns)
> Thru: Net ip_write_ptrs4_equ1  to CLB_R13C12.F3      :    1.4ns (
> 15.3ns)
> Thru: Blk ip_write_ptrs4_equ   to CLB_R13C12.X       :    2.0ns (
> 17.3ns)
> Thru: Net ip_write_ptrs4_equ   to CLB_R14C12.F4      :    1.1ns (
> 18.4ns)
> Thru: Blk ip_write_ptrs4_lop   to CLB_R14C12.X       :    2.0ns (
> 20.4ns)
> Thru: Net ip_write_ptrs4_lop   to CLB_R12C11.F1      :    1.7ns (
> 22.1ns)
> Thru: Blk ip_write_ptrs4_i1    to CLB_R12C11.X       :    2.0ns (
> 24.1ns)
> Thru: Net ip_write_ptrs4_i1_1  to CLB_R11C20.F2      :    3.2ns (
> 27.3ns)
> Thru: Blk sram0_write          to CLB_R11C20.X       :    2.0ns (
> 29.3ns)
> Thru: Net sram0_write          to CLB_R1C20.G1       :    2.3ns (
> 31.6ns)
>   To: FF Setup (D), Blk mem0_ose                     :    3.0ns (
> 34.6ns)
> Target FFX drives output net "mem0_sram"
> Dest clock net : "mem0_clk" (Rising edge)
>  Clock delay to Source clock pin : 1.7 ns

>  Clock delay to Dest clock pin   : 1.5 ns
>  Clock net "mem0_clk", delta clock delay [skew] : -0.3 ns
>                                                   ^^^^ 
> "
> 
> Well Xdelay might not be too good on math, but lets assume the skew
> really is -0.3 ns.
> Of course -0.3 ns violates the derived legal spec of 0.000 ns.
            ^^^^^ 

Well, you probably noticed, this case is totally legal as the source
clock is delayed from the destination.  So here is an example of the
other direction.  In this case the source will 
change .2ns before the destination clock arrives.  Also notice that
XDelay assume 100% tracking. 

It should also be noted these FPGAs actually work fine. I'm just trying
to point out that Xdelay
makes assumptions that we (as users) must assume to be illegal.

 
 Logical Path                                             Delay
Cumulative
 ------------                                             -----
----------
Source clock net : "mem0_clk" (Rising edge)
From: Blk nw_ctr<2>      CLOCK to CLB_R3C14.XQ       :    2.8ns ( 
2.8ns) 
Thru: Net nw_ctr<2>            to CLB_R5C7.F3        :    3.7ns ( 
6.5ns) 
Thru: Blk wmem_add<2>          to CLB_R5C7.X         :    2.0ns ( 
8.5ns) 
Thru: Net wmem_add<2>          to CLB_R4C8.F3        :    4.4ns (
12.9ns) 
Thru: Blk wmem<4>              to CLB_R4C8.X         :    2.0ns (
14.9ns) 
Thru: Net wmem<4>              to CLB_R4C5.F2        :    1.5ns (
16.4ns) 
Thru: Blk mem1_wdata<4>        to CLB_R4C5.X         :    4.3ns (
20.7ns) 
Thru: Net mem1_wdata<4>        to P39.O              :    5.0ns (
25.7ns) 
  To: FF Setup (D), Blk mem1_data<4>_p               :    4.6ns (
30.3ns) 
Target FF drives PAD "mem1_data<4>_p" (P39)
Dest clock net : "mem0_clk" (Rising edge)
 Clock delay to Source clock pin : 1.5 ns
 Clock delay to Dest clock pin   : 1.7 ns
 Clock net "mem0_clk", delta clock delay [skew] : 0.2 ns

Sorry for the confusion,
-
Brad
Article: 5830
Subject: Sole source
From: hakk@cent.com (Garnet Brace)
Date: 19 Mar 1997 06:27:34 GMT
Links: << >>  << T >>  << A >>
I don't know about the rest of you guys but personally, I hate
being confined to a single source for any part. It  causes too
much turbulence, upset, stress, disturbance etc. in my life
All of a sudden, the sole source decides to
	- raise the price
	- discontinue the part
	- "improve" the part by supplying only a new, smaller
		higher speed version that causes more noise, glitches
		ground bounce and all of those other things that
		higher speed does
	- move to anothe fab that doesn't work any more
All of these things cause my chain to be pulled and I have to drop
whatever I'm doing - that my boss thinks is a good thing - and address
the problem created by these changes.

These changes are a LOT less severe if there is another supplier that hasn't 
done them.

That's some of the reasons that I, personally HATE being confined to a 
single source.


Wouldn't you think that with many suppliers now rushing into the
FPGA field, one or two of them that are not yet market dominant
would see the marketing advantage of forming alliances with
others and do more second sourcing?

Hint Hint

What do you think?
					... Garnet

-- 
 return address is fake to try to reduce junk mail
 if you wish to send e-mail to me please send to cgbi@ionsys.com

Article: 5831
Subject: Re: EDA tools
From: timolmst@cyberramp.net
Date: Wed, 19 Mar 1997 14:17:28 GMT
Links: << >>  << T >>  << A >>
Dirk Brandis <brandis@dlcc.com> wrote:

>Anybody have thoughts/recommendations on the following tools for
>FPGA/ASIC design:

>1) VeriBest (currently reselling Synopsys FPGA Express)
>2) Synplicity
>3) Exemplar
>4) Synario
>5) Viewlogic

>Thanks!

I have ben using Synario for awhile now and I like it pretty well.

I was part of the beta test program for a new FPGA design system by
Orcad called Express. I believe that it is due to be released this
month. It features schematic entry and VHDL support for all of the
major players in the FPGA world. You would still need the place and
route compiler for the FPGA of your choice as Express is just a
fornt-end. I donlt know what their final decision will be on pricing,
but this package deserves a check-out.



Article: 5832
Subject: Re: Development board with multiple FPGAs
From: Laurent Moll <Laurent.Moll@devinci.fr>
Date: Wed, 19 Mar 1997 16:02:06 +0100
Links: << >>  << T >>  << A >>
Hari Shankar wrote:
> 
> Is it possible to purchase a development board with multiple XILINX 4000
> series FPGAs so that large designs can be accomodated?  If so, can I
> have the address/phone# of the company?
> 
> Thanks in advance,
> 
> Hari Shankar

Try the PCI Pamette board. It's got a reconfigurable PCI interface and 4
4010E for user applications (can go to 4 4020E I guess). It's got
drivers for Digital unix and Windows NT.

I find it great.

You can find more information about it at:
http://www.research.digital.com/SRC/pamette/

Laurent
Article: 5833
Subject: Re: FCCM'97 Preliminary Program
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 19 Mar 1997 11:22:44 -0700
Links: << >>  << T >>  << A >>
Some of the math here is getting out of hand. A mathematical "proof" 
that one cannot even build a shift register with a common clock just
shows that the assumptions are wrong, since such designs are working by
the millions. 
Some of these subtleties are impossible to capture in a data sheet.
Any absolute min delay can be quite short, but it cannot coexist with a
max delay....etc.
Now to the original question: Skew between two clocks.

XC4000 ( and its brothers ) first:
Each clock is run to the center of the chip and drives its own
horizontal "spine". The clock tree then "grows" vertical clock lines
wherever they are needed 
( Clock power thus depends on the number of vertical CLB columns that
are clocked, remember that for low-power applications )

"Normal" clock skew between different destinations of the same clock is
within 2 ns, which has created the data sheet statement that clock skew
is always less than the sum of set-up time, clock-to-Q, plus shortest
routing, thus guarateeing that there is no on-chip hold-time issue or
potential race condition. If the part is ultra-fast, cold and with high
Vcc, then the clock skew is also less. So: Don't worry, be happy.

"Normal" clock skew between two clocks is similarily very small.

"Normal" means that the clocks are loaded in a non-extreme way.
We are right now measuring "abnormal" clock loading conditions:
One clock loaded with every branch and every flip-flop on the chip, the
other one driving only one single flip-flop in the most favorable
position. And of course testing this for rising as well as falling-edge
conditions. I will report on this later.

XC5200 is optimized for cost, not for speed and fancy features.
Its clock has more skew since the four clocks each drive a spine along
their respective edge, then drive into the device. For any single clock,
the above-mentioned guarantee still holds, but don't apply it to the
relationship between two clocks.
In XC5200 you might, at worst, have the case where two close-by flip
flops see significant clock skew if they are clocked from separate clock
inputs. The skew might be as much as 5 ns worst case. Note that this
only applies to skew between different clocks. A single-clock skew of
such magnitude could only be between opposite corners of the chip, and
the routing delays would then inherently get rid of all race-condition
problems.

It looks like I am signing up for an app note on this subject.
But I don't want to belabor the difference between 
0 ns, 0.0 ns, 0.00 ns and 0.000 ns.

Peter Alfke, Xilinx Applications
Article: 5834
Subject: Re: Complexity of standards
From: Greg Smith <gregs@uniquesys.com>
Date: Wed, 19 Mar 1997 16:02:23 EST
Links: << >>  << T >>  << A >>
>>...Could it be that the consortium
>>members want no challenges from those who are not big enough to do hardwired
>>gate arrays? 

>In fairness, while complex, hard-to-meet standards certainly do serve the
>interests of large, established companies by making it difficult for little
>startups to compete, one need not assume actual malice.  There is always a
>tradeoff between performance and easy implementation, and big companies can
>cope with implementation difficulties relatively easily, so naturally their
>design ideas are biased strongly toward maximum performance. 

Yes. We are now in an era where standards (and I am referring to actual, not
ad hoc, standards) are being designed with the assumption that ASICs,
and other technologies such as connectors, will be developed specifically
for the standard. PCI is definitely one of them. USB, Fire-wire and SSA are
also good examples. The standards specify the connector, the electricals,
and several layers of protocol, and often a single ASIC can be built to
handle the electricals and some of the layers. You could do it with PALs
and PGAs, but you probably won't be competitive.
An advantage of this, is that we all have longer to prepare for the standard's
emergence (if we can guess which ones will succeed and when)-- because it takes
so long to work out all  the details. And yes, the technology will have
higher performance.

Consider that SCSI-1 was drafted at a time when it was assumed
that all SCSI interface circuits would be built with 74XX TTL - there's
a standard which has turned out to have very long legs.

Greg





Article: 5835
Subject: Re: FCCM'97 Preliminary Program
From: peter@xilinx.com (Peter Alfke)
Date: Wed, 19 Mar 1997 15:25:07 -0700
Links: << >>  << T >>  << A >>
In article <33302EEA.6907@xilinx.com>, peter@xilinx.com wrote:

> Some of the math here is getting out of hand.

Please disregard the previous "reply". 
I accidentally posted it here, it was meant to go with a different thread,
discussing issues with multiple clocks in Xilinx FPGAs. 
One wrong click... :-(
Again, sorry for the confusion

Peter Alfke
Article: 5836
Subject: Re: Multiple clocks in Xilinx
From: peter@xilinx.com (Peter Alfke)
Date: Wed, 19 Mar 1997 15:27:54 -0700
Links: << >>  << T >>  << A >>
Some of the math here is getting out of hand. A mathematical "proof" 
that one cannot even build a shift register with a common clock just
shows that the assumptions are wrong, since such designs are working by
the millions. 
Some of these subtleties are impossible to capture in a data sheet.
Any absolute min delay can be quite short, but it cannot coexist with a
max delay....etc.
Now to the original question: Skew between two clocks.

XC4000 ( and its brothers ) first:
Each clock is run to the center of the chip and drives its own
horizontal "spine". The clock tree then "grows" vertical clock lines
wherever they are needed 
( Clock power thus depends on the number of vertical CLB columns that
are clocked, remember that for low-power applications )

"Normal" clock skew between different destinations of the same clock is
within 2 ns, which has created the data sheet statement that clock skew
is always less than the sum of shortest set-up time, shortest clock-to-Q,
plus shortest routing, thus guarateeing that there is no on-chip hold-time
issue or
potential race condition. If the part is ultra-fast, cold and with high
Vcc, then the clock skew is also less. So: Don't worry, be happy.

"Normal" clock skew between two clocks is similarily very small.

"Normal" means that the clocks are loaded in a non-extreme way.
We are right now measuring "abnormal" clock loading conditions:
One clock loaded with every branch and every flip-flop on the chip, the
other one driving only one single flip-flop in the most favorable
position. And of course testing this for rising as well as falling-edge
conditions. I will report on this later.

XC5200 is optimized for cost, not for speed and fancy features.
Its clock has more skew since the four clocks each drive a spine along
their respective edge, then drive into the device. For any single clock,
the above-mentioned guarantee still holds, but don't apply it to the
relationship between two clocks.
In XC5200 you might, at worst, have the case where two close-by flip
flops see significant clock skew if they are clocked from separate clock
inputs. The skew might be as much as 5 ns worst case. Note that this
only applies to skew between different clocks. A single-clock skew of
such magnitude could only be between opposite corners of the chip, and
the routing delays would then inherently get rid of all race-condition
problems.

It looks like I am signing up for an app note on this subject.
But I don't want to belabor the difference between 
0 ns, 0.0 ns, 0.00 ns and 0.000 ns.

Peter Alfke, Xilinx Applications
Article: 5837
Subject: Re: Sole source
From: peter@xilinx.com (Peter Alfke)
Date: Wed, 19 Mar 1997 15:55:49 -0700
Links: << >>  << T >>  << A >>
In article <5go10m$3c4@maggie.ionsys.com>, hakk@cent.com (Garnet Brace) wrote:

> I don't know about the rest of you guys but personally, I hate
> being confined to a single source for any part.

The days of second-sourcing state-of-the-art devices are over. The major
manufacturers see no benefit in it.

When this industry was young and small, and when the military demanded
second sourcing, it was common practice to ordain a second source.
The manufacturers even then realized that it was somewhat perverse to give
away the crown jewels to a competitor, but they did it because it was
supposed to grow the market acceptance. The good aspects overcompensated
the bad ones.

Now that most of the manufacturers are reasonably big and considered
viable even by their customers, the negative aspects of putting a
competitor into the saddle outweigh the marginal positive ones.

If you don't believe me, read Andy Grove. He says the same thing.

Intel needed AMD as a second source when Intel was a small company and
many designers refused to design in a single-sourced vital part. Times
have changed. Everybody knows that Intel can and will produce, and
designers have learned to cope with the less pleasant commercial aspects
of single-sourcing. 
And AMD et.al. second sourced or copied or re-engineered or re-invented
the Intel microprocessors anyhow, although with lots of work and pain and
lawyers' fees.

A single source must and will use multiple fab lines ( to protect against
accidents ) and must be forthcoming in price reductions. I think we in the
FPGA world have done that, and will continue to do it, even without direct
pressure from a second source.
Lowering prices and improving performance is in our selfish interest,
because it allows us to grow into an almost limitless market. We don't
need a second source to push us, we are pulled by the market
opportunities. Much nicer feeling.

Peter Alfke, Xilinx Applicationss
Article: 5838
Subject: Re: PLC
From: peb@transcontech.co.uk ("Paul E. Bennett")
Date: Wed, 19 Mar 97 23:47:48 GMT
Links: << >>  << T >>  << A >>
In article <5gn6gs$5sp@camel2.mindspring.com>
           jpjcet@mindspring.com "Paul Jones" writes:

> The line betweeen PLCs and Personal Computers has become very grey in
> the past couple of years.  PLCs have had more complex algorithms added
> to them since the '80s.  The capabilities of PLCs have approached that
> of the PC, but the PC is more suitable for data aquitsition and
> control (something industrial engineers and managers want).

Whilst I might agree that the PC, suitably protected from the industrial 
nastiesand given the right interfaces, makes a very good data aquisition 
device, I would not countenance it's use for control of anything but 
measurement valves or relays. The control of "real machinery" or other 
Safety Related control applications is better left to PLC's and computer 
control systems that are designed specifically for the environment they 
will work in. Most PC's, even the industrialised ones, would find it too 
demanding to cope with some of the control tasks in Nuclear Power Plant, 
Petrocemical Process Plant or Railway Signalling at the required level of 
dependability for such applications.
 
> I see PLCs going the way of the panel-box-full of relays.  A PC with a
> Controller Area Network doing the work of a PLC as well as data
> aquisition will be the standard in the future.

I think the PLC, as we know it now, will fade into obscurity. However, 
there is a new breed of PLC type controllers around which can perform 
the data aquisition and control tasks in the harshest of environments. 
They are also very networkable and designed to autonomously maintain Safety 
Integrity Levels on the equipment they control. At present such systems are 
still somewhat bespoke solutions but that is changing slowly.
 
-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Article: 5839
Subject: Is this really possible?
From: "Kent" <address_withheld@my.discression>
Date: 20 Mar 1997 00:55:02 GMT
Links: << >>  << T >>  << A >>
I just read about this in a back issue of EDN magazine (online- December
19, 1996).

[ snip ]

Metalithic aims Digital Wings for Audio at "prosumers"--professional and
private musicians who cannot afford a studio, according to Gilson. The
system features 64-voice synthesis (with only two voices currently
implemented); software; and an optional, $300 professional breakout box.
The company based the system on the "Wingware" reconfigurable-computing
system, which comprises an operating system; a tool set; an assembler; a
function library that enables reconfigurable computing on FPGAs; and a
"nanoprocessor," a Metalithic-patented configurable RISC processor. The
nanoprocessor motors through simple operations and uses instruction-set
extensions to perform complex processing operations that would otherwise
slow a system. 

Two Xilinx 3090s, each having 320 configurable logic blocks (CLBs), form
the processing engine. The basic nanoprocessor takes 28 CLBs, or less than
10%, to instantiate the basic core processor at 50 MIPS, leaving 160 CLBs
for Musical Instrument Digital Interface (MIDI), UART, I/O, ISAbus,
synthesizer, telephone, and crystal-codec interfaces, along with about 15
instructions. The other 3090 uses a little more than 200 CLBs to provide
the vector processor that performs the multiply accumulates, linear
interpolation, and table look-up for the synthesizer engine. 

[ snip ]

I am curious to know if anyone else has been able to instantiate a basic 50
Mips processor in less than 10% of a 3090, or a "vector processor" in a
little more than 200 CLBs. Is there some big secret about the 3090 you
guys have been keeping quite, or is there something I am missing here?

Article: 5840
Subject: Lattice software
From: "Gregory M. Haskins" <bruman@wpi.edu>
Date: Wed, 19 Mar 1997 20:32:28 -0500
Links: << >>  << T >>  << A >>
Hi,
	I am currently doing some research into the efficiency of
cryptographic algorithms in reconfigurable hardware and need some
libraries to do so.  I am currently working with Xilinx XC4020E using
WorkView 7.2/XACT 6.0.1 and Altera EPF10K30 using MaxPlusII 7.1.  I would
like to be able to synthesize my designs into a Lattice architecture, but
the libraries that (I thought) were supposed to come with PDS+ for
WorkView aren't on the ISP CD-ROM that I received (Or are they?)  I have
placed a question to Lattice Semiconductor directly but they havn't
replied and I'm in a rather urgent need.  I need to finish my thesis by
May :(.  If anybody can clue me in as to whether these libraries are
available somewhere, I would be most appreciative.

Thanks in advance!
-gmh

--
Gregory M. Haskins              Research Assistant 
bruman@wpi.wpi.edu    		CAIS Laboratory
ECE Dept Grad Student 		Worcester Ma
Worcester Polytechnic Inst.     (508)831-5757
http://leonie.wpi.edu/bruman	http://ece.wpi.edu/Research/crypt

Article: 5841
Subject: Re: Sole source
From: jimmiew@sprynet.com (James West)
Date: Thu, 20 Mar 1997 02:48:14 GMT
Links: << >>  << T >>  << A >>
hakk@cent.com (Garnet Brace) wrote:

>I don't know about the rest of you guys but personally, I hate
>being confined to a single source for any part.

Amen. I can see why the manufacturers avoid it. But it causes lots of
problems where I work. We design large machines for a relativly low
volume market. It takes a long time to get a payback on a design. We
are accustom to a product life cycle of 10 to 15 years. Meaning that
we can't afford to continously re-engineer our product.  On the other
hand, the technical requirements of the new products require that we
use some leading edge (and sole sourced) parts. Talk about being
caught between a rock and a hard place...

A practical solution may be for semiconductor companies to place a
design in escrow. If company X would drop the part,  burn down, etc.,
company Y could then begin manufacturing the part.  This would make my
life simpler. And we would use more of the newer parts. A win-win
situation???

Article: 5842
Subject: Re: Xilinx 4002 RAM Question
From: gjhurlbu@beirdo.uplink.on.ca (Gavin Hurlbut)
Date: Thu, 20 Mar 1997 03:54:04 GMT
Links: << >>  << T >>  << A >>
Gavin Hurlbut (gjhurlbu@beirdo.uplink.on.ca) wrote:
> Unforunately again, our lab group is having a real painful time of trying
> to get our design to work on the BORG board.  It simulates perfectly in
> Compass-DA (both the VHDL synthesized and backannotated versions), but
> does not operate AT all on the hardware...  We are going to talk to the
> lab tech for the course tomorrow.  But I am rambling as usual :)  Sorry.
> I shall go to bed now.  G'night.

We found the problem at long last.  The BUFGP buffers we were using were
not being used correctly.  We removed them and just used the combinational
signals, and it works great.  The max clock the BORG board is capable of
(in our lab setup at least) is 8 MHz, and our design worked perfectly at
that speed after removing the BUFGPs.

So on to making our design more sleek :)

Ciao.
-- 
	Gavin J. Hurlbut		  gjhurlbu@beirdo.uplink.on.ca
   4B Electrical Engineering		---------------------------------
     University of Waterloo			School sucks.
	 My Homepage:  http://amprgate.uwaterloo.ca/~gjhurlbu/
Article: 5843
Subject: Re: Is this really possible?
From: nweaver@hum.cs.Berkeley.EDU (Nicholas C. Weaver)
Date: 20 Mar 1997 04:34:09 GMT
Links: << >>  << T >>  << A >>
In article <01bc34c8$a1e53d30$0a2e36ce@infinity>,
Kent <address_withheld@my.discression> wrote:
>I am curious to know if anyone else has been able to instantiate a basic 50
>Mips processor in less than 10% of a 3090, or a "vector processor" in a
>little more than 200 CLBs. Is there some big secret about the 3090 you
>guys have been keeping quite, or is there something I am missing here?

	Well, if the processor is only some simple control logic and
no more (likely), it could easily run at 50MHz.  Similarly, I could
envision some filters (with fixed multiplies and adds) for 8 or 16 bit
quantities fitting fairly well.  It is designed for signal processing,
and might have been good at it except for two major problems: WAAAY
too much hype, and NO I/O bandwidth.

	The hype is obvious, the bigger problem is that it is an ISA
bus card.  So all the computing bandwidth in the world doesn't do any
good!  Who CARES how much processing they can get out of those two
3090s, when you cant get the data into the card?

	Redone with some bigger gate arrays on a PCI card with real
bandwidth, it might be an interesting product.

-- 
Nicholas C. Weaver            "Trouble will come in its own time.  It always
nweaver@cs.berkeley.edu                  does. But that's tomorrow.  Give me
http://www.cs.berkeley.edu/~nweaver/             today and I will be happy."
It is a tale, told by an idiot, full of sound and fury, .signifying nothing.
Article: 5844
Subject: PCI & Altera
From: Wolfram Seibold <seibold@ind.uni-stuttgart.de>
Date: Thu, 20 Mar 1997 09:00:55 +0100
Links: << >>  << T >>  << A >>
Hi,

a generic PCI controller is currently under development at our
institute.
Has somebody done this with ALTERA EPLDs/FPGAs and which chip
was used? Contains the design only the target or master and target?

Thanks for all hints

Wolfram Seibold
-- 
-----------------------------------------------------------------------------
!ACHTUNG ADRESSAENDERUNG!                                       !NEW
ADDRESS!
-----------------------------------------------------------------------------
Universitaet Stuttgart                   University of Stuttgart
Institut fuer Nachrichtenvermittlung     Institute of Communication
und Datenverarbeitung                    Networks and Computer
Engineering
Prof. Dr.-Ing. Dr. h. c. P. J. Kuehn     Prof. Dr.-Ing. Dr. h. c. P. J.
Kuehn

Pfaffenwaldring 47                       Pfaffenwaldring 47
70569 Stuttgart                          70569 Stuttgart
                                         Germany
                  Wolfram Seibold
                  Tel. : +49 711 685 7965
                  Fax  : +49 711 685 7983
                  EMail: seibold@ind.uni-stuttgart.de
                  WWW  : http://www.ind.uni-stuttgart.de/IND/MA/Se/
-----------------------------------------------------------------------------
Article: 5845
Subject: Re: Multiple clocks in Xilinx
From: z80@dserve.com (Peter)
Date: Thu, 20 Mar 1997 09:49:55 GMT
Links: << >>  << T >>  << A >>


>Some of the math here is getting out of hand. A mathematical "proof" 
>that one cannot even build a shift register with a common clock just
>shows that the assumptions are wrong, since such designs are working by
>the millions. 

Quite. In fact a shift reg merely assumes that the clock skew is less
than the clock-Q propagation delay. 

This is easily achieved when using global clock nets, but very hard
when the clock is routed through switches. It actually used to be easy
to achieve with e.g. the old 3064 but not with the 3064A.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 5846
Subject: Re: Sole source
From: andym@trend.demon.co.uk (Andrew Morley)
Date: Thu, 20 Mar 97 10:32:43 GMT
Links: << >>  << T >>  << A >>
In article <peter-1903971555490001@appsmac-1.xilinx.com>
           peter@xilinx.com "Peter Alfke" writes:

> In article <5go10m$3c4@maggie.ionsys.com>, hakk@cent.com (Garnet Brace) wrote:
> 
> > I don't know about the rest of you guys but personally, I hate
> > being confined to a single source for any part.
> 
> The days of second-sourcing state-of-the-art devices are over. The major
> manufacturers see no benefit in it.
> 

Well, where possible we _do_ favour parts with second source available - for 
example where we could we used XC3000 series because of the second source (AT&T 
- whoops I mean Lucent).  Even now we still get a stern talking-to by the 
buyers when we design-in single-source parts.  Of course we still do, as many 
parts are not second sourced these days, but if one is it tends to be favoured 
(all other things being equal!).

-- 
 -----------------------------------------------------------------------------
| Andrew Morley, Design & Development, Trend Communications Ltd, High Wycombe.|
| email: andrew.morley@trendcomms.com  Phone +44 1628-524977        Bucks, UK.|
 -----------------------------------------------------------------------------

Article: 5847
Subject: Re: A viewlogic story
From: "Scott D. Miller" <scottydm@aol.com>
Date: Thu, 20 Mar 1997 03:53:36 -0800
Links: << >>  << T >>  << A >>
Thomas D. Tessier wrote:
> 
> Check out Veribest at http://www.veribest.com
> 
> They are currently OEMing FPGA Express and have a very good PCB tool.
> 
> Have fun.
> 

    I am currently using VeriBest Designer for Windows NT.  At this time
I have only the design capture and simulation parts (well, ok, design
management part too, but I don't use it much).  I am looking forward to
trying the synthesis pieces soon.  Currently I let the client or the
vendor do the synthesis using Synopsis.
    At the time I decided on VeriBest I compared it to View Logic's ASIC
Archetect package for Work View (early '95).  A couple of things turned
me off; lack of a static timing checker and database incompatibility
with Pro View.  I really didn't look at Cadence or Synopsis because
these packages cost more than my house!

-- 
IMPORTANT NOTE:  reply to scottydm@codenet.net NOT aol.com
     ___
   /////\\        Digitally Enhanced Portrait of:
  {|-0-0-|}              Scott D. Miller,
   |  %  |              Silicon Mercinary
    \===/            Freelance Chip Designer
      
always #5 FOO = ~FOO;  // the sound of a beating heart
Article: 5848
Subject: Re: Accolade
From: ees1ht@ee.surrey.ac.uk (Hans Tiggeler)
Date: 20 Mar 1997 12:40:00 GMT
Links: << >>  << T >>  << A >>
In article <5gd0vp$4cp@mtinsc03.worldnet.att.net>, c-d-symes@worldnet.att.net 
says...
>
>In article <01bc30ac$e2c746b0$0307e38f@zimbo>,
>   "Joel Kolstad" <Joel.Kolstad@Techne-Sys.com> wrote:
>>> any experience with Accolade-Tools (VHDL-Simulation and FPGA-Synthesis) ?
>>
>>I downloaded their demo and it died a horrible death under NT 4.0.
>>
>And it's REAL unstable under W95
My 3.06b none limited evaluation copy works fine under Win95. It does have 
some problem, like sometimes you get multiple minimize/maximize close buttons, 
and its got some other "features",  but it never crashed my machine. Under NT 
3.51 the screen is not updated correctly when running PeakSIM. To solve this 
problem you have to minimize/maximize your screen or zoom in/zoom out. 
Accolade is bringing out updated quite regularly. Sure it can not compete with 
V-Systems but than again V-Systems has been around a lot longer than Accolade 
and is not in the same price range. If you do have a problem, send them to 
Accolade Technical support and if they ignore you than you know were to 
complain :-)

Hans.
SSTL
UK
 

Article: 5849
Subject: Research Posts Available at Oxford
From: Ian.Page@comlab.ox.ac.uk (Ian Page)
Date: Thu, 20 Mar 1997 14:46:22 +0000
Links: << >>  << T >>  << A >>

Two posts for Research Assistants are available at Oxford University
to work on the the project "Rapid Implementation of
Fieldbus-Compliant, Standalone Self-Validating Instruments".

This is a collaboration between the Hardware Compilation Group in the
Computing Laboratory and the Sensor Validation Group in the Department
of Engineering Science. This work continues a previous successful
collaboration which used Hardware Compilation techniques for building
complex Self Validation Sensors.

Further details are available at:
http://www.comlab.ox.ac.uk/oucl/users/ian.page/hwcomp/valcard2/advert.html



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