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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 60775

Article: 60775
Subject: Re: Xilinx Parallel Cable 4 (PC4) and Platform Flash JTAG
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Mon, 22 Sep 2003 09:45:21 -0600
Links: << >>  << T >>  << A >>
Antti,

iMPACT does allow user to download, verify, get device ID via JTAG. For 
other functions such as EXTEST, INTEST, etc, you can shift in such 
instructions with iMPACT's Debug Chain functionality. This feature 
allows you to move through the 16 TAP controller states and shift in TDI 
data.

With 6.1i iMPACT you'll be able to genrate and program the Xilinx part 
with SVF (via inbuild XSVF player function).

If iMPACT isn't detecting the Parallel Cable for you, please see Xilinx 
solution 15742 for debugging tips and contact the Xilinx hotline support 
for further issues.

Regards, Wei
Xilinx Applications

Antti Lukats wrote:

> Aurelian Lazarut <aurash@xilinx.com> wrote in message news:<3F6B1811.FD334DE@xilinx.com>...
> 
>>Antti Lukats wrote:
>>
>>Antti,
>>why are you saying that the boundary scan is not supported with PAR cable
>>IV ?? - or it's a wild guess... 
>>Aurash
>> __
>>/ /\/\ Aurelian Lazarut
>>\ \  / System Verification Engineer
>>/ /  \ Xilinx Ireland
>>\_\/\/
>>
>>phone: 353 01 4032639
>>fax: 353 01 4640324
> 
> 
> Dear Xilinx Verification Engineer,
> 
> No it is not a wild guess. Sure Cable IV hardware support all JTAG
> (inclusive boundary scan of course) but 99% of Xilinx customers who
> own Cable IV can not use it for boundary scan because there are no
> software available for that purpose.
> 
> Cable IV: 
>  hardware is boundary scan capable
>  can not be used for boundary scan because no software or API is available.
> 
> I had a pretty urgent need to use boundary during development of on board
> with Xilinx FPGA, I have Cable IV (only because it was bundled with
> ML300 kit), but I could not use Cable IV, because the lack of software.
> 
> Cable IV hardware description and software driver API are all kept Xilinx
> confidential and secret, so 3rd party software can not use Cable IV.
> 
> If the API (or register level description of the hardware interface)
> would be public it would be real simple to modify STAPL player to support
> Cable IV. Unfortunatly this is not possible and STAPL player hardware support
> ends with Cable III (i.e. simple LPT download cable).
> Xilinx provided XSVF player also does not support Cable IV.
> 
> 
> There is only one wacked way to use Cable IV for boundary scan, but that
> really not an option - SystemACE files may contain SVF so if you have systemACE
> that you program using Cable IV then you could optionally create a SVF that 
> does the needed boundary scan, program the systemACE and let systemACE to
> perform the JTAG boundary scan.
> 
> Except that I am not aware of any means of using Cable IV for boundary scan.
> Correct me if I am wrong. There might be some JTAG software that cost some
> thousands of $$$ and support Cable IV, but an regular Xilinx customer who
> has to deal with Xilinx FPGAs and owns Cable IV can not use it boundary scan.
> 
> PLEASE, PLEASE SAY I am wrong. (I dont think I am)
> 
> antti
> who does not work for xilinx but in most cases knows more than those who do.


Article: 60776
Subject: Re: show-ahead FIFOs
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 08:47:21 -0700
Links: << >>  << T >>  << A >>
Bertrik, you are right in stating that the Xilinx solutions do not offer
"fall-through" as an option. We might offer that in the future.
But let's be realistic: 
The only value of this option is when you write the first word into a
previously empty FIFO. Then the word appears at the output without any
Read Enable action. Once beyond this, there is no difference between
this and the conventional mode.
So it all depends whether you intend to often empty the FIFO completely.
If this is rare, the fall-through is of dubious value.

Peter Alfke
====================
Bertrik Sikken wrote:
> 
> Hi all,
> 
> I worked on a project using an Altera FPGA and I noticed that
> their FIFOs have a 'show-ahead' feature. Currently I'm working
> with an FPGA from Xilinx and I could not find a similar feature
> on their FIFO's.
> 
> It seems to me such a feature can be very useful since it
> allows you to get at the data one clock earlier.
> 
> Why don't the Xilinx FIFOs have such a feature?
> (Or am I perhaps overlooking something some crucial
> drawback of show-ahead FIFOs?)
> 
> Regards,
> Bertrik Sikken

Article: 60777
Subject: Re: Configuration Options:
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 08:49:42 -0700
Links: << >>  << T >>  << A >>


Lorenzo Lutti wrote:
> 
> 
> Yes! But be afraid of iMPACT user interface, which is the worst
> nightmare ever invented. I've lost more than ten minutes to understand
> how to use a PROM with iMPACT...

Lorenzo, you must be pretty smart if you can solve the "worst nightmare
ever invented" in a mere ten minutes...  :-)
Peter Alfke

Article: 60778
Subject: Cheapest programmer for a ICT 7572J Peel device
From: bsd_mike@hotmail.com (Mike)
Date: 22 Sep 2003 08:51:53 -0700
Links: << >>  << T >>  << A >>
What is the most inexpensive programmer available for the ICT 7572J Peel device?
Thanks, Mike

Article: 60779
Subject: Re: Regarding XC6216
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 09:00:01 -0700
Links: << >>  << T >>  << A >>
My first answer is: look it up on google. You get 747 hits!
Question: Do you need any more?
The parts do not exist anymore, so why do you need the data sheet?

Peter Alfke, Xilinx

"H.Azmi" wrote:
> 
> Hi guyes ,
>          Does any body have datasheet for XC6216 ?

Article: 60780
Subject: Re: Moderator of comp.arch.fpga
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 09:01:24 -0700
Links: << >>  << T >>  << A >>
There is none. That's the beauty of it. But it also means that we must
be self-policing. Which we usually are...
Peter Alfke
=================
Stephan Neuhold wrote:
> 
> Hi,
> 
> Can somebody please tell me who the moderator of this newsgroup is?
> 
> Thanks,
> Stephan Neuhold

Article: 60781
Subject: Re: show-ahead FIFOs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 22 Sep 2003 12:01:44 -0400
Links: << >>  << T >>  << A >>
Andrew Paule wrote:
> 
> Hi Philip -
> 
> you're right on all cases - only thing is that you are going to be
> either a half or full clock behind.  FWFT Fifo's are done with
> transparent latches (that's the limiter) - you have to be cautious in
> use of them.  I've done fifo's using the transparent latch trick that
> are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA,
> unless you pay attention to how you're routing the thing, you can have a
> nightmare (One of the reasons I like Actels) - the true FWFT types have
> the flags updated on the rising edge of the incoming clock and have the
> synched flops (look at a Cypress or IDT design) done with the same flop
> that's used for the empty flag.  What you are doing is great for
> avoiding problems in designs that are not well followed through, and
> should be a design standard.  What goes on in the newsgroups is that
> some folks out there will take a quick look at things and then try to
> implement them without understanding the real problems in post route
> timing (especially over temperature).

Unless I am all wet, these are not true FIFOs, but are only RAM blocks
with address counters.  

I am not sure you are correct about the need for transparent latches.  I
don't see how you would even use a transparent latch in this application
to any advantage.  I expect the RAM block is simply leaving out the
output latch on the read data.  The Altera RAMs work in a way that the
output data is not available for half a clock cycle after it is written
(internal falling edge write strobe perhaps?).  This may look like a
transparent latch, but it is not.  In this case I don't see how you
could use a transparent latch on the output and get it to do anything
useful.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60782
Subject: Re: Synchronous counter enable pulse length
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 09:10:11 -0700
Links: << >>  << T >>  << A >>
If you design synchronously and use a common global clock, you "have
nothing to fear but fear itself" (to quote FDR).
Instead of decoding TC of the big counter, you could waste a flip-flop
and build a digital differentiator of the MSB. Just an idea for simplification.

When you use Global Clocks, you can forget about any hild-time issues.
But it's good that you are not nave ! Taht's worth at leaast an A- ( in
US notation)
Peter Alfke


Tom Derham wrote:
> 
> I am using one counter to trigger a second counter.
> The first counter is loadable but typically runs for a long time ('count' is
> 28 bit).
> This counter keeps running, and each time it terminates, produces a pulse.
> This pulse is used to trigger the second counter, which typically runs for
> much less time ('count' is 8 bit).  This counter produces output 1 while it
> is counting, then returns to 0 until it is retriggered by the pulse from the
> first counter.
> The whole design is synchronous (running of a single clock at 100 MHz),
> using Webpack on Spartan IIE.
> 
> Question: how long must the pulse from the first clock be, to ensure that it
> triggers the second clock?  As I see it, if it is one clock cycle long, then
> the second clock should trigger on the next clock rising edge (providing the
> sum of clock propagation and the 2nd clock flip-flop setup is less than one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe?  Does the pulse need to be longer?  Will the simulation tools
> realise if there is a problem here?
> 
> Many thanks
> 
> Tom Derham

Article: 60783
Subject: Re: Transistor count
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 22 Sep 2003 16:13:58 -0000
Links: << >>  << T >>  << A >>
>I think that's because one of the standards counts transistors in its MTBF..
>so a PAL is more reliable than an FPGA but less reliable than an HC00.

Many years ago, somebody told me that system reliability was
roughly:
  connectors
  solder joints
  bond wires
  on chip problems

I think the handwave was a factor of 10 each step.  (Big handwave.)

Is that still a good rough cut?  Any obvious overview article I
should scan for a modern view?

Is on-chip failure rate anything anybody should worry about these days?
What fraction of real-world failures are caused by ESD or running too
hot?  (or ...?)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 60784
Subject: Re: Transistor count
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 22 Sep 2003 09:59:32 -0700
Links: << >>  << T >>  << A >>
Hal,

That is still true.

If you look at the calculation of reliability methods used by the telecom
business, the NEBS (new equipment building standards) from Telcordia (aka
Bellcore), you will find all of these items with their listed FIT rate (failures
per billion hours).

Things like fuses (100 fits), and diodes (7 fits), or connectors (10 fits per
mating pin-pair), are listed from their historical data, which can be tossed out
and replaced with your own data, or data from the manufacturer.

Austin

Hal Murray wrote:

> >I think that's because one of the standards counts transistors in its MTBF..
> >so a PAL is more reliable than an FPGA but less reliable than an HC00.
>
> Many years ago, somebody told me that system reliability was
> roughly:
>   connectors
>   solder joints
>   bond wires
>   on chip problems
>
> I think the handwave was a factor of 10 each step.  (Big handwave.)
>
> Is that still a good rough cut?  Any obvious overview article I
> should scan for a modern view?
>
> Is on-chip failure rate anything anybody should worry about these days?
> What fraction of real-world failures are caused by ESD or running too
> hot?  (or ...?)
>
> --
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
> commercial e-mail to my suespammers.org address or any of my other addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.


Article: 60785
Subject: Re: FPGA implementation in (V)HDL
From: "Andras Tantos" <andras_tantos@tantos.yahoo.com>
Date: Mon, 22 Sep 2003 10:44:14 -0700
Links: << >>  << T >>  << A >>
Also take a look at: http://www.opencores.org/projects/fpga/

Regrads,
Andras Tantos

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:ksutmv8keob45q149tk04kb040lu6l8bl5@4ax.com...
> On 22 Sep 2003 06:26:07 -0700, Sebastian_Lange@gmx.de (Sebastian Lange)
wrote:
> >This post may seem a bit awkward, but has anyone ever come across a
> >VHDL or
> >Verilog implementation of an FPGA? It would be very instructional to
> >have a
> >look at it. IMHO, it should be at any rate possible to implement a
> >small FPGA as a bit file sitting on top of another FPGA. Our group is
> >currently working on some ideas for minimizing the reconfiguration
> >data in dynamically reconfigurable FPGA applications.
> >It would be very kind if anyone could point me to any resources...
> >Thank you so much in advance...
> >
> >Sebastian
>
> Eric Crabill's course at SJSU covers this as Lab 5
>
>    http://www.engr.sjsu.edu/crabill/
>
>
>
>
>
> Philip Freidin
> Fliptronics



Article: 60786
Subject: Re: Italy is out of FPGA world?
From: kempaj@yahoo.com (Jesse Kempa)
Date: 22 Sep 2003 11:17:24 -0700
Links: << >>  << T >>  << A >>
> > Some days ago Xilinx did workshops in many european states.
> > Why Italy was excluded?
> 
> No workshops in UK either :(

Gentlemen,

Altera is offering a summer workshop series for designers as well. The
current schedule (for Europe) includes sessions in Milan on October
30, and in Bedfordshire on November 20. You can view the program and
enroll to attend online:
http://www.altera.com/education/events/europe/sopc03/evt-index.jsp?xy=sopc_algh

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 60787
Subject: Re: FPGA implementation in (V)HDL
From: jetmarc@hotmail.com (jetmarc)
Date: 22 Sep 2003 12:15:59 -0700
Links: << >>  << T >>  << A >>
> a VHDL or Verilog implementation of an FPGA?

I know that somebody started one about 2 years ago, but I can't find
the bookmark anymore.  The main problem was that the custom FPGA
needs a custom toolchain, and that makes it a really huge project.

Marc

Article: 60788
Subject: Re: Parallel JTAG cable on a USB-only W2K laptop?
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Mon, 22 Sep 2003 12:17:34 -0700
Links: << >>  << T >>  << A >>
On Mon, 22 Sep 2003 00:12:54 -0700, Simon Peacock wrote:

> Now this sounds like a plan.. I would be interested in more info.. as
> would a few around here..
> 
> Simon
> 
> "Peter Wallace" <pcw@karpy.com> wrote in message
> news:pan.2003.09.21.22.57.55.531717.20522@karpy.com...
>> On Sat, 20 Sep 2003 23:19:37 -0700, Simon Peacock wrote:
>>
>> > I have a feeling you might be pushing it .. but I'd like to hear the
>> > outcome.. The parallel port is treated as a bit bashed I/O port by
>> > the downloader's where as the USB to parallel port is a printer
>> > port.. or an EPP port..
>> >
>> > Xilinx do a USB to FPGA downloader box for about US$500.. that would
>> > be my best thought.. or there's a few USB - JTAG boxes that might
>> > also work. Altera have a similar device similar price..
>> >
>> > I have often thought an EZ-USB would make a great FPGA downloader and
>> > at the same price as the parallel port downloader's.
>> >
>> > Simon
>> >
>> >
>> > "CF" <carl@notsoform.com> wrote in message
>> > news:_e4bb.2249$YO5.1748748@news3.news.adelphia.net...
>> >> Thank you for confirming my suspicion that I cannot accomplish this
>> >> task with a USB adapter.
>> >> I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter. I
>> >> believe it will install as an LPT device properly and do the job.
>> >> Thank you again.
>> >> Carl
>> >>
>> >>
>> >>
>> A little early to announce but we have a simple USB/JTAG downloader.
>> The downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP
>> controller. The XC2S50 is first downloaded in bit-bang mode via the
>> FTDI chip and then acts as a smart TAP controller. This is an open
>> project with all design information (software, stiffware, schenmatics,
>> gerbers) freely available.
>>
>> The downloader supports 2.5V, 3.3V and 5V JTAG I/O and programmable
>> clock rates up to 48 MHz. The programmer is USB powered (no adapter
>> needed). Connector pinout is 26 pin superst of EJTAG pinout.
>>
>> The current software allows downloading Xilinx Bit files and SVF files
>> (Thanks Jim!) If you dont want to build it yourself, The programmer
>> hardware is available from my company for $99.00
>>
>>
>> Peter Wallace
>>
>>


Here is a link to the programmer

www.mesanet.com/parallelcardinfo.html  

(at the bottom)

The support software link is to a zipped file of schematics and current
software/stiffware...


Peter Wallace

>>
>>
>> >>

Article: 60789
Subject: Re: Xilinx S3 I/O robustness question
From: symon_brewer@hotmail.com (Symon)
Date: 22 Sep 2003 12:18:58 -0700
Links: << >>  << T >>  << A >>
Hi Peter,
      If the pin has 10 Ohms of drive impedance the initial sent pulse
will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
Ohms driver drives a 50 Ohm line. The reflected signal from the
unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
then increases the voltage at the pin to 3.667, as it's driven from 50
Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
absolute maximum rating of 3.75V. Hooray!
      As you say, this calculation disregards the attenuation due to
the trace propagation function, which will further reduce the
amplitude of the pulse as it travels back and forth down the
transmission line(pcb trace). This is caused by skin effect and stuff.
I guess you could also reduce the drive strength of the pin from the
default 12mA, to increase the source impedance.
       The receiver pin is the one that gets the big hit.
        cheers, Symon.


Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...
> Let me help you, and rephrase your original question:
> If a 3.3 V output on Spartan3, going active Low to active High, drives a
> transmission line of arbitrary length that is open ended at the far end,
> there will be a return signal that wants to pull the 3S pin higher than
> Vcco = 3.3 V.
> Can this cause do damage to the Spartan3 pin?
> 
> My answer would be: NO.
> The returning 3.3V wave wants to pull the pin to 6.6 V, but the
> transmission line impedanec is roughly 50 Ohm, and the chip pull-up
> impedance is roughly 10 Ohm, so you have a voltage divider that raises
> the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
> resulting theoretical 3.85 voltage is really a bit lower since the
> reflection is not perfect, and there are losses on the line.
> Also, this spike will only last a few nanoseconds.
> I would say that this poses no problem. But I have copied Steve Knapp,
> who handles Spartan applications. He may add his opinion to this.
> 
> Peter Alfke, Xilinx
> =============================
> lecroy wrote:
> > I am still looking for an answer to my question.
> > 
> > 

Article: 60790
Subject: Re: Synchronous counter enable pulse length
From: Rene Tschaggelar <some@know.me>
Date: Mon, 22 Sep 2003 20:27:40 GMT
Links: << >>  << T >>  << A >>
Tom Derham wrote:
> [snip]
> Question: how long must the pulse from the first clock be, to ensure that it
> triggers the second clock?  As I see it, if it is one clock cycle long, then
> the second clock should trigger on the next clock rising edge (providing the
> sum of clock propagation and the 2nd clock flip-flop setup is less than one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe?  Does the pulse need to be longer?  Will the simulation tools
> realise if there is a problem here?

You can delay the output signal with another FF and 'OR' its input and output.
That gives you another clock cycle in length.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 60791
Subject: Re: Xilinx S3 I/O robustness question
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 22 Sep 2003 13:28:45 -0700
Links: << >>  << T >>  << A >>
Symon,

As if often the case, if you do not run a simulation, you will not get results that are
even close to the truth (by guessing at what is happening).

With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back
at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx).

Why does this not scale exactly as you state?  Because the ON resistance of the
transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground.

So, unless you simulate the actual circuit, you will not get the actual result.

Austin

Symon wrote:

> Hi Peter,
>       If the pin has 10 Ohms of drive impedance the initial sent pulse
> will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
> Ohms driver drives a 50 Ohm line. The reflected signal from the
> unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
> then increases the voltage at the pin to 3.667, as it's driven from 50
> Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
> absolute maximum rating of 3.75V. Hooray!
>       As you say, this calculation disregards the attenuation due to
> the trace propagation function, which will further reduce the
> amplitude of the pulse as it travels back and forth down the
> transmission line(pcb trace). This is caused by skin effect and stuff.
> I guess you could also reduce the drive strength of the pin from the
> default 12mA, to increase the source impedance.
>        The receiver pin is the one that gets the big hit.
>         cheers, Symon.
>
> Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...
> > Let me help you, and rephrase your original question:
> > If a 3.3 V output on Spartan3, going active Low to active High, drives a
> > transmission line of arbitrary length that is open ended at the far end,
> > there will be a return signal that wants to pull the 3S pin higher than
> > Vcco = 3.3 V.
> > Can this cause do damage to the Spartan3 pin?
> >
> > My answer would be: NO.
> > The returning 3.3V wave wants to pull the pin to 6.6 V, but the
> > transmission line impedanec is roughly 50 Ohm, and the chip pull-up
> > impedance is roughly 10 Ohm, so you have a voltage divider that raises
> > the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
> > resulting theoretical 3.85 voltage is really a bit lower since the
> > reflection is not perfect, and there are losses on the line.
> > Also, this spike will only last a few nanoseconds.
> > I would say that this poses no problem. But I have copied Steve Knapp,
> > who handles Spartan applications. He may add his opinion to this.
> >
> > Peter Alfke, Xilinx
> > =============================
> > lecroy wrote:
> > > I am still looking for an answer to my question.
> > >
> > > 


Article: 60792
Subject: Re: Synchronous counter enable pulse length
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 22 Sep 2003 21:07:37 GMT
Links: << >>  << T >>  << A >>
"Rene Tschaggelar" <some@know.me> wrote in message
news:da916fbbcc79413230e067ade436a0d4@news.teranews.com...
> Tom Derham wrote:
> > [snip]
> > Question: how long must the pulse from the first clock be, to ensure
that it
> > triggers the second clock?  As I see it, if it is one clock cycle long,
then
> > the second clock should trigger on the next clock rising edge (providing
the
> > sum of clock propagation and the 2nd clock flip-flop setup is less than
one
> > clock cycle)... but functionally the pulse will fall back at the moment
it
> > is triggered (one cycle later), so will only work if the hold time of
the
> > flip-flop is less than the clock propagation.
> > Is this safe?  Does the pulse need to be longer?  Will the simulation
tools
> > realise if there is a problem here?
>
> You can delay the output signal with another FF and 'OR' its input and
output.
> That gives you another clock cycle in length.

Rene, wouldn't this enable the second counter twice?



Article: 60793
Subject: LUT and Registers in Xilinx Virtex 2
From: Julien Eyries <NOeyries.SPAMjulien@wanadooPLEASE.fr>
Date: Mon, 22 Sep 2003 21:54:16 +0000
Links: << >>  << T >>  << A >>
Hello all,

     I have one question about usage of LUT and Registers in Xilinx 
Virtex 2 FPGA:

     if, inside a slice, the LUT is consumed by some logic product, but 
not the corresponding register, is this register available for other use
(for example, registering signal coming from an other slice) ?  or is it
disabled for the whole design ? does it depend on the compilation tool ?

thanks,
Julien Eyries


Article: 60794
Subject: Re: Transistor count
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Mon, 22 Sep 2003 22:09:21 GMT
Links: << >>  << T >>  << A >>

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F6F09E4.5865169E@xilinx.com...
> Simon,
>
> That is for the lazy folks:  if you know the reliability (from studies,
> manufacturers data, etc.) you can choose to replace the "count method"
with the
> real data (wow, what a concept!).
>
> The "count method" is there as a last resort, if there is no other way to
gauge
> reliability.  Once you see the count method numbers, it should send you
> screaming to get the real data.  The standards bodies know this, and
understand
> this, it is just that lazy engineers just keep filling out the forms as if
they
> were still designing in 1968 ....

There is a story I heard some years ago, related to statistical physics, but
it should work for any statistics problem.  A person was told that the
probability of a bomb being on an airplane was 1 in 1000, but the
probability of two bombs was 1 in 1000000.  To be safe, he always brought
his own bomb on the plane.   (I think those are the numbers in the story,
which has no relation to any real planes or real bombs.)

The important thing in a large number of problems is statistical
independence.   When all the transistors on a single chip are made at the
same time, using the same process, the probability of one failing is not
statistically independent of another failing.   A bad batch of any of the
chemicals that go into the processing, various mechanical problems that
could occur, or any number of other events tend to affect all the
transistors on a chip equally.  Without statistical independence any count
based method will fail, just like in the bomb story.

-- glen



Article: 60795
Subject: Re: Synchronous counter enable pulse length
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Mon, 22 Sep 2003 22:24:57 GMT
Links: << >>  << T >>  << A >>

"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> I am using one counter to trigger a second counter.
> The first counter is loadable but typically runs for a long time ('count'
is
> 28 bit).
> This counter keeps running, and each time it terminates, produces a pulse.
> This pulse is used to trigger the second counter, which typically runs for
> much less time ('count' is 8 bit).  This counter produces output 1 while
it
> is counting, then returns to 0 until it is retriggered by the pulse from
the
> first counter.
> The whole design is synchronous (running of a single clock at 100 MHz),
> using Webpack on Spartan IIE.
>
> Question: how long must the pulse from the first clock be, to ensure that
it
> triggers the second clock?  As I see it, if it is one clock cycle long,
then
> the second clock should trigger on the next clock rising edge (providing
the
> sum of clock propagation and the 2nd clock flip-flop setup is less than
one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe?  Does the pulse need to be longer?  Will the simulation
tools
> realise if there is a problem here?

The problem should be exactly the same as that in building the synchronous
counter in the first place.

I still remember from many years ago, that the 74LS74 has 0 hold time, but
the 7474 has a positive hold time.  You can make T flip-flops by connecting
Qbar to D on a 74LS74, but not (reliably) on a 7474.  Most likely even one
level of logic in between would be enough, though.

The LSB of a synchronous counter would normally have the shortest feedback
path.   That would be the first place to look.

As I understand it, FPGA's are usually designed so that in a synchronous
design you don't have to worry about hold time, though possibly setup time.
It might be that it is not possible to make a feedback path short enough,
even if the FF itself has a positive hold time.

Now, some people might design a synchronous counter with a clock input from
the TC pulse of another synchronous counter.  That would not qualify as
synchronous logic, and could cause timing problems.

-- glen





Article: 60796
Subject: Re: show-ahead FIFOs
From: Andrew Paule <lsboogy@qwest.net>
Date: Mon, 22 Sep 2003 17:52:23 -0500
Links: << >>  << T >>  << A >>
If your external clocking is fast enough to allow use of the timing 
delays inherant in the internals of your FGPA, then using a D and 
running the output to a pad will allow you to get a good Tpd as the 
delay - that's really all a transparent does for you in this case - 
gives a one gate + one (or more pad delays).  if you use the supplied 
macromodels, they will do away with any use for this - roll your own 
means just that, no RAM blocks.  There are other architectures out there 
besides Altera and Xilinx, but most of this newsgroup seems to forget 
this.  They all have their uses, and obviously they all have some good 
points to be considered when choosing your architecture.  just like the 
processor people (I still like MIPs and SHARCs), but that's another 
thread entirely.

Andrew

rickman wrote:

>Andrew Paule wrote:
>  
>
>>Hi Philip -
>>
>>you're right on all cases - only thing is that you are going to be
>>either a half or full clock behind.  FWFT Fifo's are done with
>>transparent latches (that's the limiter) - you have to be cautious in
>>use of them.  I've done fifo's using the transparent latch trick that
>>are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA,
>>unless you pay attention to how you're routing the thing, you can have a
>>nightmare (One of the reasons I like Actels) - the true FWFT types have
>>the flags updated on the rising edge of the incoming clock and have the
>>synched flops (look at a Cypress or IDT design) done with the same flop
>>that's used for the empty flag.  What you are doing is great for
>>avoiding problems in designs that are not well followed through, and
>>should be a design standard.  What goes on in the newsgroups is that
>>some folks out there will take a quick look at things and then try to
>>implement them without understanding the real problems in post route
>>timing (especially over temperature).
>>    
>>
>
>Unless I am all wet, these are not true FIFOs, but are only RAM blocks
>with address counters.  
>
>I am not sure you are correct about the need for transparent latches.  I
>don't see how you would even use a transparent latch in this application
>to any advantage.  I expect the RAM block is simply leaving out the
>output latch on the read data.  The Altera RAMs work in a way that the
>output data is not available for half a clock cycle after it is written
>(internal falling edge write strobe perhaps?).  This may look like a
>transparent latch, but it is not.  In this case I don't see how you
>could use a transparent latch on the output and get it to do anything
>useful.  
>
>  
>


Article: 60797
Subject: Re: Synchronous counter enable pulse length
From: Andrew Paule <lsboogy@qwest.net>
Date: Mon, 22 Sep 2003 17:56:07 -0500
Links: << >>  << T >>  << A >>
Hold time is a quantum statistical thing - thermal trip of a balanced 
pair.  Been through this in this newgroup before. 

Andrew

Glen Herrmannsfeldt wrote:

>"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
>news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
>  
>
>>I am using one counter to trigger a second counter.
>>The first counter is loadable but typically runs for a long time ('count'
>>    
>>
>is
>  
>
>>28 bit).
>>This counter keeps running, and each time it terminates, produces a pulse.
>>This pulse is used to trigger the second counter, which typically runs for
>>much less time ('count' is 8 bit).  This counter produces output 1 while
>>    
>>
>it
>  
>
>>is counting, then returns to 0 until it is retriggered by the pulse from
>>    
>>
>the
>  
>
>>first counter.
>>The whole design is synchronous (running of a single clock at 100 MHz),
>>using Webpack on Spartan IIE.
>>
>>Question: how long must the pulse from the first clock be, to ensure that
>>    
>>
>it
>  
>
>>triggers the second clock?  As I see it, if it is one clock cycle long,
>>    
>>
>then
>  
>
>>the second clock should trigger on the next clock rising edge (providing
>>    
>>
>the
>  
>
>>sum of clock propagation and the 2nd clock flip-flop setup is less than
>>    
>>
>one
>  
>
>>clock cycle)... but functionally the pulse will fall back at the moment it
>>is triggered (one cycle later), so will only work if the hold time of the
>>flip-flop is less than the clock propagation.
>>Is this safe?  Does the pulse need to be longer?  Will the simulation
>>    
>>
>tools
>  
>
>>realise if there is a problem here?
>>    
>>
>
>The problem should be exactly the same as that in building the synchronous
>counter in the first place.
>
>I still remember from many years ago, that the 74LS74 has 0 hold time, but
>the 7474 has a positive hold time.  You can make T flip-flops by connecting
>Qbar to D on a 74LS74, but not (reliably) on a 7474.  Most likely even one
>level of logic in between would be enough, though.
>
>The LSB of a synchronous counter would normally have the shortest feedback
>path.   That would be the first place to look.
>
>As I understand it, FPGA's are usually designed so that in a synchronous
>design you don't have to worry about hold time, though possibly setup time.
>It might be that it is not possible to make a feedback path short enough,
>even if the FF itself has a positive hold time.
>
>Now, some people might design a synchronous counter with a clock input from
>the TC pulse of another synchronous counter.  That would not qualify as
>synchronous logic, and could cause timing problems.
>
>-- glen
>
>
>
>
>  
>


Article: 60798
Subject: Re: Parallel JTAG cable on a USB-only W2K laptop?
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Mon, 22 Sep 2003 17:20:08 -0700
Links: << >>  << T >>  << A >>
On Mon, 22 Sep 2003 12:54:14 -0700, emanuel stiebler wrote:

> Peter Wallace wrote:
>> A little early to announce but we have a simple USB/JTAG downloader.
>> The downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP
>> controller. The XC2S50 is first downloaded in bit-bang mode via the
>> FTDI chip and then acts as a smart TAP controller. This is an open
>> project with all design information (software, stiffware, schenmatics,
>> gerbers) freely available.
> 
> You should have told us before ;-)
> I'm sitting on a layout for something like this, but with the cypress
> fx2 as USB2 chip ...
> 
> cheers
 
I looked at that chip for a newer design but it draws so much power that
it looks troublesome to stay under the 500 mA limit, at least for a simple
low cost card with linear regulators.

I've got a low cost USBScope (2 channels ~30 MHz (100 Ms/S)) design using the
FTDI245 and a XC2S100E as well, I would have liked to have used the Cypress
part there but there is no hope even with switching regulators of staying
below 500 mA with Cypress.

Peter Wallace

Article: 60799
Subject: Re: Synchronous counter enable pulse length
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 17:22:24 -0700
Links: << >>  << T >>  << A >>
Here are some practical points.
For all but the most extremely fast applications ( say up to 200 MHz),
synchronous counters are built using a global clock, and the bult-in
free ripple carry structure, which of course determines a max frequency
(where the ripple carry can still meet the set-up time requirements of
the MSB.) Decoding TC can be quite tricky, that's why I suggested the
digital differentiator which actually detects TC+1.

Peter Alfke
=============

Glen Herrmannsfeldt wrote:
> 
> "Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
> news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> > I am using one counter to trigger a second counter.
> > The first counter is loadable but typically runs for a long time ('count'
> is
> > 28 bit).
> > This counter keeps running, and each time it terminates, produces a pulse.
> > This pulse is used to trigger the second counter, which typically runs for
> > much less time ('count' is 8 bit).  This counter produces output 1 while
> it
> > is counting, then returns to 0 until it is retriggered by the pulse from
> the
> > first counter.
> > The whole design is synchronous (running of a single clock at 100 MHz),
> > using Webpack on Spartan IIE.
> >
> > Question: how long must the pulse from the first clock be, to ensure that
> it
> > triggers the second clock?  As I see it, if it is one clock cycle long,
> then
> > the second clock should trigger on the next clock rising edge (providing
> the
> > sum of clock propagation and the 2nd clock flip-flop setup is less than
> one
> > clock cycle)... but functionally the pulse will fall back at the moment it
> > is triggered (one cycle later), so will only work if the hold time of the
> > flip-flop is less than the clock propagation.
> > Is this safe?  Does the pulse need to be longer?  Will the simulation
> tools
> > realise if there is a problem here?
> 
> The problem should be exactly the same as that in building the synchronous
> counter in the first place.
> 
> I still remember from many years ago, that the 74LS74 has 0 hold time, but
> the 7474 has a positive hold time.  You can make T flip-flops by connecting
> Qbar to D on a 74LS74, but not (reliably) on a 7474.  Most likely even one
> level of logic in between would be enough, though.
> 
> The LSB of a synchronous counter would normally have the shortest feedback
> path.   That would be the first place to look.
> 
> As I understand it, FPGA's are usually designed so that in a synchronous
> design you don't have to worry about hold time, though possibly setup time.
> It might be that it is not possible to make a feedback path short enough,
> even if the FF itself has a positive hold time.
> 
> Now, some people might design a synchronous counter with a clock input from
> the TC pulse of another synchronous counter.  That would not qualify as
> synchronous logic, and could cause timing problems.
> 
> -- glen



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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