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 29625

Article: 29625
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 02 Mar 2001 00:36:06 +0000
Links: << >>  << T >>  << A >>


yuryws@banet.net wrote:

> Side note:
>  uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
> not 133 MB/sec.
>
> -- Yury
>
> R

UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec =
133MBytes/sec.


Article: 29626
Subject: Re: What about speed-grade?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 02 Mar 2001 00:45:29 +0000
Links: << >>  << T >>  << A >>


"Juan M. Rivas" wrote:

> Hi everyone!
>
> What's the difference in the speed-grade between devices?
>
> I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which
> speed grade should I use?  -4, -5, -6.
>
> Thanks all
>
> -Juan

First: Don't buy Virtex buy Virtex-E they're not only faster but an
awful lot cheaper.

Second: It depends on your logic. You shouldn't really decide until
you've done enough of the design to get a realistic +/- 20% STA except
...

Third: The true answer is to buy the ones you stand a chance of getting
before you retire.



Article: 29627
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Fri, 02 Mar 2001 06:11:35 GMT
Links: << >>  << T >>  << A >>
On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>yuryws@banet.net wrote:
>
>> Side note:
>>  uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
>> not 133 MB/sec.
>>
>> -- Yury
>>
>> R
>
>UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec =
>133MBytes/sec.

I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s
not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both
edges so it has a 66.67 MB/s transfer rate.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 29628
Subject: San Francisco bay Hardware engineers
From: "Jacqueline Linich" <jlinich@home.com>
Date: Fri, 02 Mar 2001 06:27:16 GMT
Links: << >>  << T >>  << A >>


Excellent benefits and Flex hours available

For more info Contact:
--
Jackie Linich
Senior Staffing Consultant
(510)865-7849
(510)499-4558
Senior Hardware Design Engineers - Board level and FPGA Design
We are looking for three (3) Digital Hardware Design Engineers. Engineering
candidates should have 5-7 years design experience with three+ years in
telecom design preferrably in either ATM or DSL. Candidates should have
knowledge of design specifications governing some of the following areas:
T1, E1, ADSL, HDSL2, ADSL, ATM, etc. Experience with digital design from the
product specification stage to manufacturing release stage is a plus.
You will have the opportunity to design the next generation of Integrated
Access Devices. These devices will utilize the latest xDSL chipsets,
networking chipsets (copper and optical), and communication processors.
Furthermore, these designs incorporate the latest voice communication
standards.
Requirements
BSEE (MSEE a plus) with a minimum of 5 years HW board design experience.
Experience with Motorola MPC8XX, PPC7XX and Intel x86 processors.



Article: 29629
Subject: [AD]: PIC-based Embedded Webserver/Webclient available.
From: "Richard Rooney" <richard@orlin.com>
Date: Fri, 2 Mar 2001 10:53:32 -0000
Links: << >>  << T >>  << A >>

See,
http://www.orlin.com

for Hardware supporting the Microchip application note AN731 on PIC-based
Embedded Webservers/Clients.

Orlin Technology Ltd.



Article: 29630
Subject: Re: What about speed-grade?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 02 Mar 2001 14:40:02 GMT
Links: << >>  << T >>  << A >>
If you need a Qrel part, then you are forced to use a Virtex-4 :-(

Provided your design is carefully executed to limit the number of 
logic levels and floorplanned, 100 MHz can be hit even by the virtex -4.
Normally, the carry chain or the block RAM access is the limiting factor.
The Virtex -4 block RAM is good to about 125 MHz if it is registered near
the block RAM, and a 16 bit -4 carry chain can be run at >150 MHz provided
the driving logic is located in an adjacent CLB and the fanout is kept 
small.

As Rick mentioned, if you are not constrained to a QREL application, use
the Virtex E, they are faster, cheaper, and have more block RAM.  Alternatively,
use the Spartan II, which gets you approximately the same speeds as a 
Virtex for a whole lot less money (check the supply first though).


Rick Filipkiewicz wrote:
> 
> "Juan M. Rivas" wrote:
> 
> > Hi everyone!
> >
> > What's the difference in the speed-grade between devices?
> >
> > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which
> > speed grade should I use?  -4, -5, -6.
> >
> > Thanks all
> >
> > -Juan
> 
> First: Don't buy Virtex buy Virtex-E they're not only faster but an
> awful lot cheaper.
> 
> Second: It depends on your logic. You shouldn't really decide until
> you've done enough of the design to get a realistic +/- 20% STA except
> ...
> 
> Third: The true answer is to buy the ones you stand a chance of getting
> before you retire.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 29631
Subject: Re: What about speed-grade?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 02 Mar 2001 07:49:47 -0800
Links: << >>  << T >>  << A >>
Rick,

The XCV200 is stock in many packages.  The XCV200E is 1 -2 weeks leadtime.
Is your 65 th birthday next month?

Austin

Rick Filipkiewicz wrote:

> "Juan M. Rivas" wrote:
>
> > Hi everyone!
> >
> > What's the difference in the speed-grade between devices?
> >
> > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which
> > speed grade should I use?  -4, -5, -6.
> >
> > Thanks all
> >
> > -Juan
>
> First: Don't buy Virtex buy Virtex-E they're not only faster but an
> awful lot cheaper.
>
> Second: It depends on your logic. You shouldn't really decide until
> you've done enough of the design to get a realistic +/- 20% STA except
> ...
>
> Third: The true answer is to buy the ones you stand a chance of getting
> before you retire.


Article: 29632
Subject: Netlis : Webpack Vs Foundation
From: thirumurugan <sthru@yahoo.com>
Date: Fri, 2 Mar 2001 10:11:53 -0800
Links: << >>  << T >>  << A >>
Sir,
     Can netlist generated from Webpack ISE be loaded in Foundation Series 2.1 simulator. Is the netlist compatible. Iam synthesysing VHDL designs in Webpack and when i load the netlist in Foundation series simulator i am getting lot of warnings. should i make any settings in the environment settings.help me please.
thanks in advance,stm.

Article: 29633
Subject: Re: What about speed-grade?
From: Luke Roth <roth@narn.cse.psu.edu>
Date: Fri, 2 Mar 2001 16:40:36 -0500
Links: << >>  << T >>  << A >>
On Fri, 2 Mar 2001, Ray Andraka wrote:

> If you need a Qrel part, then you are forced to use a Virtex-4 :-(

Qrel?



Article: 29634
Subject: Differences in VHDL coding for FPGA & CPLD
From: kode@bridgeport.edu
Date: 2 Mar 2001 22:02:54 GMT
Links: << >>  << T >>  << A >>

Hello there,

I was wondering if anyone could shed some light on the differences in the way
you write VHDL for a FPGA and a CPLD, in particular Xilinx Devices.

Lets say I did a small design in Virtex FPGA, but I would want to implement
that in a CPLD. Does any one have examples of VHDL code that were written for
both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code
for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate
any input.

Thank You




 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Article: 29635
Subject: Re: What about speed-grade?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 02 Mar 2001 23:00:17 GMT
Links: << >>  << T >>  << A >>
QML high reliability parts.  Basically qualified for military/space applications
that demand high reliability.

Luke Roth wrote:
> 
> On Fri, 2 Mar 2001, Ray Andraka wrote:
> 
> > If you need a Qrel part, then you are forced to use a Virtex-4 :-(
> 
> Qrel?

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 29636
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 02 Mar 2001 23:31:23 +0000
Links: << >>  << T >>  << A >>


Muzaffer Kal wrote:

> On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>
> >yuryws@banet.net wrote:
> >
> >> Side note:
> >>  uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
> >> not 133 MB/sec.
> >>
> >> -- Yury
> >>
> >> R
> >
> >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec =
> >133MBytes/sec.
>
> I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s
> not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both
> edges so it has a 66.67 MB/s transfer rate.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com

I've *built* a UDMA33 interface and that clock runs at 16.66 ergo the UDMA66
interface I'm about to build will have a 33.33MHz clock. Note that the clock
frequency is really the read clock sent by the disk on IORDY. The write clock is
under my own control.


Article: 29637
Subject: Re: Differences in VHDL coding for FPGA & CPLD
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 02 Mar 2001 23:41:06 +0000
Links: << >>  << T >>  << A >>


kode@bridgeport.edu wrote:

> Hello there,
>
> I was wondering if anyone could shed some light on the differences in the way
> you write VHDL for a FPGA and a CPLD, in particular Xilinx Devices.
>
> Lets say I did a small design in Virtex FPGA, but I would want to implement
> that in a CPLD. Does any one have examples of VHDL code that were written for
> both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code
> for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate
> any input.
>
> Thank You

Off the top of my head I can think of 1 important thing. For FPGAs state machines
should be one-hot encoded but for CPLDs they should be binary. Most HDL synth tools
default to the FPGA case/setting but have some way of overriding this.

Interestingly I've recently come across a situation where HDL - Verilog - code for
a CPLD just would not fit [synth tool = Synplify] but re-writing it in
old-fashioned ABEL worked easily. Looking further it seemed that the grown-up synth
tool was not doing a full and/or reduction and implemented the logic with large
swathes of 2/3 input gates. It was relying on the not 100% efficient
``multi-level'' logic optimisation in the Xilinx CPLD fitter.


Article: 29638
Subject: Re: Differences in VHDL coding for FPGA & CPLD
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 02 Mar 2001 16:40:15 -0800
Links: << >>  << T >>  << A >>
kode@bridgeport.edu wrote:

> Lets say I did a small design in Virtex FPGA, but I would want to implement
> that in a CPLD. Does any one have examples of VHDL code that were written for
> both FPGA and a CPLD. I am basically looking at how to optmize my VHDL code
> for a FPGA, and modify it to optimize the VHDL for a CPLD. I would appreciate
> any input.

If you can avoid instantiating device specific components, your code
will be very portable. With the right synthesis software, things
like RAM, ROM, counters etc can be inferred from a line of
code rather than selected from a vendor component library.

Of course the vendors want you to stick with their chip
so they use more ink on app notes that lock you in than
those that let you loose.

--    mike.treseler at flukenetworks dot com

Article: 29639
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: muzaffer@dspia.com
Date: 03 Mar 2001 00:47:34 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote:

>
>
>Muzaffer Kal wrote:
>
>> On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz
>> <rick@algor.co.uk> wrote:
>>
>> >yuryws@banet.net wrote:
>> >
>> >> Side note:
>> >>  uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
>> >> not 133 MB/sec.
>> >>
>> >> -- Yury
>> >>
>> >> R
>> >
>> >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec =
>> >133MBytes/sec.
>>
>> I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s
>> not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both
>> edges so it has a 66.67 MB/s transfer rate.
>>
>> Muzaffer
>>
>> FPGA DSP Consulting
>> http://www.dspia.com
>
>I've *built* a UDMA33 interface and that clock runs at 16.66 ergo the UDMA66
>interface I'm about to build will have a 33.33MHz clock. Note that the clock
>frequency is really the read clock sent by the disk on IORDY. The write clock is
>under my own control.

I am looking at this document http://www.t13.org/project/d1410r1a.pdf
specifically table 57, figure 50 and figure 55 (on pages 361, 365 and
370 respectively). I'd appreciate if you could tell me how one gets
133 MB/s with a design compliant to this document.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 29640
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: yuryws@banet.net
Date: Sat, 03 Mar 2001 03:50:17 GMT
Links: << >>  << T >>  << A >>
2 bytes every 30 ns (approximately 27 ns/ 32 ns), not 4 bytes every 30 ns. This is
where your error is.

Rick Filipkiewicz wrote:

> yuryws@banet.net wrote:
>
> > Side note:
> >  uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
> > not 133 MB/sec.
> >
> > -- Yury
> >
> > R
>
> UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec =
> 133MBytes/sec.


Article: 29641
Subject: Re: Bad Xilinx bitstream=big bang?
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 03 Mar 2001 06:20:02 GMT
Links: << >>  << T >>  << A >>
Joel, I am very sorry about your mishap, and I have inserted my comments in the
appropriate places in your story.
The gist is:
Virtex parts do check for CRC errors, but not for formatting errors. And you
sent a legitimately CRC-protected file, just the wrong format... Horrendous
amount of internal contention.

Joel Kolstad wrote:

> We have some PCI cards at work that we recently upgraded -- for both price
> and performance reasons -- to use Xilinx XCV600E parts instead of the XCV400
> parts that the old board used.  We've found out the hard way that Very Bad
> Things happen if you attempt to load the old bitstream for the XCV400 onto
> the XCV600E board.  In particular:
>
> -- <snip>

>
> Now what I want to know is... I had always thought that there was some CRC
> checking in the FPGA bitstream files, and that you could pretty much feed
> the FPGA random gibberish and be very unlikely to actually get the thing to
> accept the bitstream

Correct. If there were a CRC error, the part would recognize this. But there
was no CRC error...

> and go through power-on initialization.

No, no. power-on initialization is done much earlier, right after you applied
Vcc. This has nothing to do with CCLK. The parts use their own internal
oscillator for that purpose.

> In fact, we're
> manually bit-banging the CClk line on the FPGA (we're using serial slave
> mode), so there aren't even enough clock pulses provided to the 600E to make
> it think it should even _consider_ going through power-on initiailization,

see above. It has done this sucessfully long before.

>
> since the 600E requires about two hundred thousand extra bits (and CClks)
> than what the 400 file would provide it with (we stop generating CClk when
> we're out of configuration data bits).
>
> With our current setup it's difficult to probe around on the board and try
> to figure out exactly _when_ the overcurrent condition starts.  Loading the
> 400 file takes a couple of seconds, and the 145W PC will power down within a
> couple of seconds after that.  My suspicion is that the overcurrent
> condition has already started long before we're gotten anywhere near to
> finishing the transmission of the 400's bitstream.

Yes. The internal logic becomes active as you feed in the data.
( I may stand corrected here. I carry too much XC4000 bagage in my head, and I
am at home, no access to other experts. But Austin can jump in, while I am gone
for the coming week. Seminars in Europe)

>
> So... does anybody have any experience with this?  The possibility that
> feeding a 600E a 400 bitstream causes it to draw massive currents seems
> awfully remote to me.

No, it's ugly, but not surprising. The part considers this a garbage bitstream
, but with legitimate CRC. I know this is not ideal, but that's the way it is.

> The LT1575/dual FET power supply can put out 2A all
> day long (this was its design goal -- we're dissipating 1.5V*2A=3W or
> 1.5W/FET in this case), I would wager it can put out 4A for many minutes,
> and to physically blow up both FETs I would have to think that it's passing
> at least 10A for a little while.  Strange, very strange.

Not so strange. Consider the very large number of internal nodes, let's say
over 50,000.
Let's assume that, through nonsense configuration, 10% are driven by contending
levels on both sides of the wire. And let's assume a realistic 5 mA per
contention: 5000 times 5 mA = 25 A !
This distributed nature of the current also shows why the Virtex part ( most
likely ?) survived. The current is more or less evenly spread over the whole
die, which is more than a square centimeter in area.

I am not making excuses, just describe the phenomenon, which is quite rational,
albeit not desirable.

Ask Austin whether Virtex-II is protected against this kind of mishap.

Peter Alfke, Xilinx Applications (Friday-night emergency services)



Article: 29642
Subject: Metastability, Asynchronous Signals, & Asynchronous design
From: V R <picklingfigsis@whatmrbournsdoesnotlike.com>
Date: Sat, 3 Mar 2001 06:55:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hey all.

I've seen the metastability issue come up a few times, and I've read Peter
Alfke's app note on crossing clock domains, but I'm still unsure about how
to handle some particular issues. Incidentally, someone should archive
those great 1-2 page articles with gems of circuits(i.e not be buried
under corporate website with millions of layers)...

I was recently doing a design where I was interfacing an FPGA/CPLD to the
parallel port, using EPP(1.9) protocol.  This mode uses
nAddressActive/nDataActive and a RDY signal in the "standard" four-phase
asynchronous communication scheme. The nAddrActive/nDataActive are signals
from the PC port to the peripheral hardware and RDY is a signal from the
peripheral to the PC.

When the PC wants data transaction to start, it checks to seeing if RDY is
low, if so, one of the xActive signals goes low. If the RDY signal is
raised, this is considered acknowledgement and data transaction starts,
etc. Transaction is finished when RDY drops low, then the xActive signal,
hence the four-phases. However with EPP mode, there is no clock or strobe
signal for the peripheral to synchronize to/from the host. As a result,
one has to take into account the asynchronous nature of the xActive
signals.

For my design, to take care of the asynchronous signals and taking into
consideration the metastability issue, I used two D flip-flops hooked in
series (i.e. standard synchronizer) and then the output of the 2nd DFF was
used by my state machines, etc. I was curious if this is an "acceptable"
method for reducing metastability, or whether the second flip-flop was
needed or if I should have used asynchronous feedback loops instead?

So I did some investigating; in one of my digital logic books, by Peterson
and Hill, it was suggested that since the D-type flip-flop has only one
"input"(D) that the worst that could happen is that the incoming signal is
synchronized one-clock cycle later. Someone else pointed out that an
oscillation(not just a delayed recognition) on the output might occur for
a J-K flip-flop, but not for the DFF/DFFE.

Fundamentally I understand that the asynchronous signal could/might
violate the setup time on the DFF and hence cause metastability. However
I'm unsure if the metastability in this case (synchronizer circuit) can be
ignored as a result of todays advanced FPGAs & CPLDs. This particular
designed would be implemented in both an Altera MAX 7128AE & a Xilinx
4000E/XL. How accurate are Peterson and Hill's statements? I don't have
the book right now, otherwise I would quote them. As I understand them,
since the flip-flop is clocking the data high or low based on VminHigh and
VhighLow, the incoming signal will be one or the other and will be
recognized correctly on the next clock cycle.

Then I also started pondering if I should have used an asynchronous
feedback loop(combinatorial "state machine") and then used the output of
this as maybe the enable on a DFFE. I don't mind using schematics (I have
my issues with VHDL, maybe I'll jive better with Verilog) so I know I can
implement the circuit correctly, but I'm also unsure how advanced the
synthesizer's algorithms are for asynchronous "fundamental mode" designs
and what it might actually produce.

I guess that brings up another interesting question, 99% of the designers
I know that use FPGAs & CPLDs pretty much synchronize anything
asynchronous (outputs of a decoder, etc) but how prevalent is asynchronous
design (fundamental mode with feedbacks, not 2-level AND/OR) in
programmable logic? I read a paper from 1994 that mentioned the then
current FPGA technology was not suitable for advanced asynchronous design.
Have the tools/hardware changed in any manner that makes this method of
design more attractive, or is the mentality still synchronize it all?

Finally, regarding the four-phase asynchronous circuits, in
ASICs/commercial ICs, how do the designers there handle this? Do they use
asynchronous circuits or synchronize the asynchronous signals? No one I've
asked has known the answer (including several VLSI people), but someone
must know, after all we have Multi-I/O parts and even the chipsets know
EPP...

Thanks! (and sorry for the longish post),
VR.

Article: 29643
Subject: Virtex-E Equivalent Power/Ground Pairs
From: "Edi" <edouard.mouchel@nospam.baesystems.com>
Date: Sat, 3 Mar 2001 12:07:54 -0000
Links: << >>  << T >>  << A >>
Virtex-E Equivalent Power/Ground Pairs

We are designing using Virtex-E XCV600E with a FG900 package.

Can someone please tell me the number of Equivalent Power/Ground Pairs for
this particular package ?

Page 62, Table 27 (Novemebr 2000) of the data sheet has a blank entry for
this package.
[Ref: VirtexT-E 1.8 V Field Programmable Gate Arrays, DS022 (v1.8) November
20, 2000]

Thanks in advance,

Edi



Article: 29644
Subject: Re: Xilinx tools: RLOC hierarchy with HDL design?
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Sat, 3 Mar 2001 17:01:05 -0000
Links: << >>  << T >>  << A >>

"BriMDavis" <brimdavis@aol.com> wrote in message
news:20010228225100.14681.00000083@ng-fx1.aol.com...

> >module dff16_s1(clk, ce, d, q) /* synthesis syn_hier="hard" */;
>
> "Stupid FPGA Trick" of the day for Verilog users:
>
>   Make sure you put that semicolon AFTER the meta-comment, or
>  your attribute will be silently ignored by the synthesizer...

Thanks a million.  I hope DejaGoogle remembers that one.




Article: 29645
Subject: Re: Bad Xilinx bitstream=big bang?
From: eteam <eteam@aracnet.com>
Date: Sat, 03 Mar 2001 10:01:46 -0800
Links: << >>  << T >>  << A >>
Peter (and Austin and Phil),

Here is my take (*please* correct me where I'm mistaken):

It sounds like there are two weaknesses in (at least)
some of the Xilinx device families that can lead to
catastrophic failures:

1.  Devices don't check the programming data stream
for a "match" of target device.  Thus, you can try to
program a Virtex 600E device with a Virtex 400E
configuration data stream, and the configuration data
will be accepted.

This "hole" allows the designer to make a mistake, and be
burned by it.  The workaround is, simply, to make sure that
your configuration files were compiled for the correct target
device; you screw up at your own peril.

2.  More ominous is that drivers for internal
multi-source busses are not disabled (tri-stated, if
you will) before and during the configuration and powerup
sequence, when the internal state of the device cannot be
controlled or specified by the designer.  I'm not sure there
is *any* workaround to this, short of a re-design of the FPGA die.

We need to understand the breadth of this problem (if the above
assessments are basically correct): which device families are
affected (afflicted), etc. etc.

I'm not posting this to cause alarm, but to distill the
issues at hand as clearly as possible, and avoid any FUD.

Rather than get excited, it would be good for all concerned
to await Xilinx's response which, if history is a guide, will be
an honest and open discussion of the facts, and which will provide
essential guidance to the design community.

Bob Elkind, eteam@aracnet.com

Article: 29646
Subject: Re: Bad Xilinx bitstream=big bang?
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Sat, 03 Mar 2001 18:26:17 GMT
Links: << >>  << T >>  << A >>
Thanks for the explanation, Peter.  I'm thinking we'll add something to the
board so that the PC's software will be able to detect what type of FPGA the
board has loaded on it, and not feed it incorrect bitstreams.

The FPGA itself survived just fine, as far as I can tell. :-)

---Joel




Article: 29647
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 03 Mar 2001 20:35:52 -0000
Links: << >>  << T >>  << A >>
I've seen experts and textbooks botch the metastability issue.
One book I trust and like is:
  High Speed Digital Design: A handbook of Black Magic,
    by Howard W.Johnsson and Martin Graham
It covers things more at the board level, wires between chips
rather than routing inside an FPGA.  It has a very good section
on metastability.


> For my design, to take care of the asynchronous signals and taking into
> consideration the metastability issue, I used two D flip-flops hooked in
> series (i.e. standard synchronizer) and then the output of the 2nd DFF was
> used by my state machines, etc. I was curious if this is an "acceptable"
> method for reducing metastability, or whether the second flip-flop was
> needed or if I should have used asynchronous feedback loops instead?

Two FFs in series is the standard way to avoid metastability.  But
you didn't mention the key idea - time, excess time.  Settling time
is the only way to avoid metastability troubles.  If you wait long
enough you can make the probability of troubles low enough but
you can never make it go to zero.

Metastability recovery is exponentail with time.  If 1 extra ns
drops the probability by a factor of 1000, 2 extra ns will drop it
by a factor of 1000000.

Using two FFs normally (almost) forces you to do the right thing.
The idea is that you are running at the same clock speed as the
rest of the circuit but you don't have any logic in there so the
time that logic would use is excess time for any metastability to
settle.

  You can screw that up if you put the FFs on opposite sides of
  the board/chip and thus use up all the excess time in routing.

  You can screw it up if you try to cheat and clock the first
  FF on the other edge of the clock.  That might be good enough,
  but it does reduce the settling time by a 1/2 cycle.

  If you have a heavily pipelined FPGA design, you may not have
  much excess time even without any logic between the FFs. (The LUT
  tables are almost free so you don't save much be not haveing any
  logic.)

  If your state machine is running slowly (relative to the technology)
  then you may not need the first FF - you already have lots of excess
  time.


> So I did some investigating; in one of my digital logic books, by Peterson
> and Hill, it was suggested that since the D-type flip-flop has only one
> "input"(D) that the worst that could happen is that the incoming signal is
> synchronized one-clock cycle later. Someone else pointed out that an
> oscillation(not just a delayed recognition) on the output might occur for
> a J-K flip-flop, but not for the DFF/DFFE.

That all seems fishy to me.


> Then I also started pondering if I should have used an asynchronous
> feedback loop(combinatorial "state machine") and then used the output of
> this as maybe the enable on a DFFE. I don't mind using schematics (I have
...

You can't get away from metastability.  Anybody who claims they
have "solved" the problem is confused or lying.

You can make it "good enough" (probability of error low enough)
if you wait long enough.

There are two reasons I would avoid anything other than the standard
two-FFs approach.

First, two FFs is a well understood area.  You can analyze the
problem and will probably get it right.  If you use some complicated
kludgy curcuit you may overlook an important area and you probably
won't get any data from vendors.

Second, the metastability settling time is determined by the
loop bandwidth.  That will be much higher inside a tiny FF than it
will be if you build your own circuit using FPGA parts and routing.
(Especially if the people designing the FF considered metastability.)


> Finally, regarding the four-phase asynchronous circuits, in
> ASICs/commercial ICs, how do the designers there handle this? Do they use
> asynchronous circuits or synchronize the asynchronous signals? No one I've
> asked has known the answer (including several VLSI people), but someone
> must know, after all we have Multi-I/O parts and even the chipsets know
> EPP...

If somebody doesn't think about the issue carefully, they are asking
for troubles, nasty troubles.

The simple/clean way is to run all external signals through a pair of
FFs to synchronize them.  That costs a cycle.

There is probably a good/simple/clean way to avoid that cycle
on a standard four-phase handshake by pushing a bit of logic
in front of the synchronizer.  I can't work one out on the fly.
You have a round trip time to get ready for your next action so
it shouldn't be too tough.

One trick is to use a FIFO to help cross clock boundaries.  The
idea is that you only have to synchronize the (almost) full/empty flags
and they change less often than the data so an extra clock of settling
time can often be pushed to someplace where it won't hurt much.
This is part of the reason FIFOs get discussed here so often.

One general measure of goodness is to draw a line on the schematics
(or block diagram) between the clock domains and count the number
of signals crossing that line - more is less good.

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 29648
Subject: Full Time - No contractors
From: "Embedded Head" <chilln@gte.net>
Date: Sat, 03 Mar 2001 20:46:38 GMT
Links: << >>  << T >>  << A >>
Mixed Signal Engineer

Will work as a member of our Test Engineering team to design, test and
troubleshoot our next generation of test equipment.  We are a rapidly
expanding, progressive company with excellent benefits and friendly
atmosphere.

Qualifications

BSEE (required)

2+ years experience in C/C++ and VHDL or  FPGA (required)

2+ years experience with analog hardware (required)

Schematic design software experience (required)

DSP experience preferred

Send or Fax resume to:

"Mixed Signal Engineer Web"
3629 Vista Mercado
Camarillo, CA 93012

FAX:      (805) 383-1838

EMAIL:   humanresources@a-m-c.com



begin 666 BULLET_P.gif
M1TE&.#EA'P`.`/<``````( ```" `(" ````@( `@ " @,# P ````````0$
M! @(" P,#!$1$186%AP<'"(B(BDI*55554U-34)"0CDY.?]\@/]04-8`D\SL
M_^_6QN?GUJVID#,``&8``)D``,P````S`#,S`&8S`)DS`,PS`/\S``!F`#-F
M`&9F`)EF`,QF`/]F``"9`#.9`&:9`)F9`,R9`/^9``#,`#/,`&;,`)G,`,S,
M`/_,`&;_`)G_`,S_````,S,`,V8`,YD`,\P`,_\`,P`S,S,S,V8S,YDS,\PS
M,_\S,P!F,S-F,V9F,YEF,\QF,_]F,P"9,S.9,V:9,YF9,\R9,_^9,P#,,S/,
M,V;,,YG,,\S,,__,,S/_,V;_,YG_,\S_,___,P``9C,`9F8`9ID`9LP`9O\`
M9@`S9C,S9F8S9IDS9LPS9O\S9@!F9C-F9F9F9IEF9LQF9@"99C.99F:99IF9
M9LR99O^99@#,9C/,9IG,9LS,9O_,9@#_9C/_9IG_9LS_9O\`S,P`_P"9F9DS
MF9D`F<P`F0``F3,SF68`F<PSF?\`F0!FF3-FF68SF9EFF<QFF?\SF3.9F6:9
MF9F9F<R9F?^9F0#,F3/,F6;,9IG,F<S,F?_,F0#_F3/_F6;,F9G_F<S_F?__
MF0``S#,`F68`S)D`S,P`S `SF3,SS&8SS)DSS,PSS/\SS !FS#-FS&9FF9EF
MS,QFS/]FF0"9S#.9S&:9S)F9S,R9S/^9S #,S#/,S&;,S)G,S,S,S/_,S #_
MS#/_S&;_F9G_S,S_S/__S#,`S&8`_YD`_P`SS#,S_V8S_YDS_\PS__\S_P!F
M_S-F_V9FS)EF_\QF__]FS "9_S.9_V:9_YF9_\R9__^9_P#,_S/,_V;,_YG,
M_\S,___,_S/__V;_S)G__\S___]F9F;_9O__9F9F__]F_V;__Z4`(5]?7W=W
M=X:&AI:6ELO+R[*RLM?7U]W=W>/CX^KJZO'Q\?CX^ ```*"@I(" @/\```#_
M`/__````__\`_P#______R'Y! $``/(`+ `````?``X`0 BO`.4)'$B0X+M:
MKYZALE:PH4.#H@@8,@.FP0(``-;=>_>PH[Q7M;K%JZ7PE*$'"SAZ['C@W;U[
MDF)*VKC2HS5KW;H=>/;L%(%VO&HZ1$64Z"EB%0&D/""TX(&7%"XNB,".G225
M30O>O/G*)+NL#=_AI#>O%BJ3/"(P!2N0)T*CHLPT`"!I+=B>)@U-?( 1`DVV
A[QKUX/%@+D8)[>[9!>M24M6J[69B92OPG<N7ECT&! `[
`
end


Article: 29649
Subject: Re: Metastability, Asynchronous Signals, & Asynchronous design
From: "S. Ramirez" <sramirez@deletethis.cfl.rr.com>
Date: Sat, 03 Mar 2001 21:16:17 GMT
Links: << >>  << T >>  << A >>
> For my design, to take care of the asynchronous signals and taking into
> consideration the metastability issue, I used two D flip-flops hooked in
> series (i.e. standard synchronizer) and then the output of the 2nd DFF was
> used by my state machines, etc. I was curious if this is an "acceptable"
> method for reducing metastability, or whether the second flip-flop was
> needed or if I should have used asynchronous feedback loops instead?

     It is true that you need two flip flops.  The first one is to
synchronize the asynchronous signal to the using clock domain.  The second
one is to reject the metastability of the first flip flop.  If you are
testing an asynchronous signal (note I said signal, not signals) that is
feeding a state machine, then the state machine flip flops will serve as the
"2nd flip flop,", i.e., they are the metastability rejectors.  If you use
two fllip flops prior to the state machine, then the 2nd flip flop is the
metastability rejector, and you will incur an additional cycle of delay.
     If you are doing this with multiple signals, then you run the risk of
testing multiple signals simultaneously with some of the signals changing
and some not when you sample them.  This will give possible erroneous
results, and the only way to synchronize such a circuit is to test for one
synchronized signal at a time.  In my world, testing for multiple
synchronized signals is called "using parallel synchronizers," and this is
one of the things I look for when "fixing" someone else's design.  Note that
this is not always a bad thing, beacause there is also something else in my
world called "protocol stabilized signals," which means that although the
signals are asynchronous, by the time you test for them, they have
stabilized and are synchronous for all practical purposes.  An example of
this is the VMEbus, where ALE is synchronous and tested.  By the time ALE is
found activated, the rest of the signals are stabilized.  FIFOs also serve a
very useful purpose, essentially shriveling the changing asynchronous
signals (data) down to a synchronized flag.


> Then I also started pondering if I should have used an asynchronous
> feedback loop(combinatorial "state machine") and then used the output of
> this as maybe the enable on a DFFE. I don't mind using schematics (I have
> my issues with VHDL, maybe I'll jive better with Verilog) so I know I can
> implement the circuit correctly, but I'm also unsure how advanced the
> synthesizer's algorithms are for asynchronous "fundamental mode" designs
> and what it might actually produce.

It doesn't matter whether you use VHDL, Verilog or schematics to do FPGA
design.  All three will get you into BIG trouble by doing asynchronous
design.  All three will keep you out of BIG trouble by doing synchronous
design.


> I guess that brings up another interesting question, 99% of the designers
> I know that use FPGAs & CPLDs pretty much synchronize anything
> asynchronous (outputs of a decoder, etc) but how prevalent is asynchronous
> design (fundamental mode with feedbacks, not 2-level AND/OR) in
> programmable logic? I read a paper from 1994 that mentioned the then
> current FPGA technology was not suitable for advanced asynchronous design.
> Have the tools/hardware changed in any manner that makes this method of
> design more attractive, or is the mentality still synchronize it all?

I have made some serious money in the past six years fixing problems created
by asynchronous designers.  Their intent was noble, and some of them
actually pulled it off.  But when the product was advanced a year later and
the circuitry was borrowed for the new design, new technology (faster FPGAs)
actually screwed up the parameters and caused severe problems.  Redesigning
the circuits using synchronous techniques solved the problems.  As FPGAs get
faster, this trend helps synchronous designs but hurts asynchronous designs.
If these designers had used synchronous techniques to design the circuitry
to begin with, the latter engineers wouldn't have had the problems they had.
My feeling is that a designer can do simple asynchronous designs in an FPGA
if (s)he is very careful and pays attention to many details, but advancing
technology or aging of the equipment will cause problems in the future.
Furthermore, detailed asynchronous designs require lots of time and can only
be done to siimple circuits.  This may change if the right tools come along.
When I do synchronous designs, I sleep at night.  When an engineer does
asynchronous designs, (s)he is still up at night with thoughts about signals
racing back and forth trying to beat each other to the next gate.  As you
can read, I am very biased toward synchronous design.  I wonder why!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA





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

Threads starting:
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