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 60325

Article: 60325
Subject: Re: ABEL help needed
From: Bertram Geiger <list_geiger@aon.at>
Date: Wed, 10 Sep 2003 20:46:43 +0200
Links: << >>  << T >>  << A >>
Tim schrieb:
> Hi there
> 
> I like to realize a counter, which has an UP and DOWN (and others).
> I know, I need a clock for realizing asynchronious reset.
> UP and DOWN are triggered by user switches. But I just found a
> possiblity for realisation by using an extra Clock-Button - that's a
> pretty bad solution!
> 
> Can somebody help me and tell me what to change in my ABEL-Code, so I
> don't need the Clock-Button??
> 
> I use this code
> 
> MODULE unicnt
> 
> 
> title '6 bit universal counter with parallel load' ;
> 	"constants
> 	X,C,Z = .X., .C., .Z. ;
> 	
> 
> 	"inputs
> 	D5..D0 pin ; "Data inputs, 4 bits wide
> 	clk pin ; "Clock input
> 	rst pin ; "Asynchronous reset
> 	cnten pin ; "Count enable
> 	ld pin ; "Load counter with input data value
> 	up pin ; "Up/Down selector: HIGH selects up
> 	down pin;
> 
> 	"outputs
> 	q5..q0 pin istype 'reg'; "Counter outputs
> 
> 	"sets
> 	data = [D5..D0]; "Data set
> 	count = [q5..q0]; "Counter set
> 	
> "mode equations
> 	MODE = [cnten,ld,up,down]; "Mode set composed of control pins.
> 	LOAD = (MODE == [ X , 1, X, X ]);"Various modes are defined by
> 	HOLD = (MODE == [ 0 , 0, X, X ]);"values applied to control pins.
> 	UP = (MODE ==   [ 1 , 0, 1, 0 ]);"Symbolic name may be defined as
> 	DOWN = (MODE == [ 1 , 0, 0, 1 ]);"a set equated to a value.
> 
> equations
> 	when LOAD then count := data "Load counter with data
> 	else when UP then count := count + 1 "Count up
> 	else when DOWN then count := count - 1 "Count down
> 	else when HOLD then count := count  "Hold count
> 	else count := count;
> 	
> 	count.clk = clk;
> 	 "Counter clock input
> 	count.ar = rst; "Counter reset input
> 
> END 
> 

may be i not really understand what you want to do, but any action of
your counter (except reset) can only take place, if there is an counter
clock present. Therefore you need clock for LOAD too    :-(

You could synchronize your input signal with a higher frequency clock
or use asynchronous set and preset to load the counter


this line is redundant:
> 	else when HOLD then count := count  "Hold count

regards,  Bertram


-- 
Bertram Geiger,  Graz - Austria


Article: 60326
Subject: Online Troubleshooters
From: gregs@altera.com (Greg Steinke)
Date: 10 Sep 2003 13:34:30 -0700
Links: << >>  << T >>  << A >>
We see a variety of configuration issues on comp.arch.fpga, and we
also see these in Altera's support center. To make it easier to debug
these issues, Altera has created an online troubleshooter for
configuration. This troubleshooter works by asking you various
questions about your setup and what you are seeing on the board, then
suggests various actions to take to solve the problem. I encourage
designers to check it out if seeing configuration problems. The URL is
here:

http://www.altera.com/cgi-bin/ts.pl?fn=configuration

Altera also has other online troubleshooters for PCI and licensing
issues, found here:
http://www.altera.com/support/kdb/troubleshooter/ts-index.html

These tools will be useful for designers as you debug your systems.
Enjoy!

Sincerely,
Greg Steinke
gregs@altera.com

Article: 60327
Subject: Re: pipelined divider
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Wed, 10 Sep 2003 21:28:07 GMT
Links: << >>  << T >>  << A >>

"ykagarwal" <yog_aga@yahoo.co.in> wrote in message
news:4d05e2c6.0309092246.2ead33f0@posting.google.com...

(snip regarding pipelined divider)

> well my requirement is too for double precision .. would u like to
> suggest me a pipelined
> comp arch book for this purpose.. anyway what is the best way, that's
> what i want to explore first.

The one I have here is "The Architecture of Pipelined Computers" by Kogge.

> Xilinx coregen divider core doesn't offer that much width in its
> pipelined divider .. don't know why
> may be xilinx gurus can justify .. anybody knows which algorithm they
> are using ?

I don't know that, either.  It might be because they didn't imagine anyone
wanting to put something like that into an FPGA.  They are likely pretty
big, but in some cases it might be worth the size.

-- glen



Article: 60328
Subject: What clock domain is a Xilinx DCM LOCK signal in?
From: johnp3+nospam@probo.com (John Providenza)
Date: 10 Sep 2003 14:49:25 -0700
Links: << >>  << T >>  << A >>
I don't see in the Xilinx documentation in what clock domain
the LOCK signal coming from a DCM is produced.  Do I need to
synchronize it into the CLK0 domain to avoid metastability?

Thanks!


John Providenza

Article: 60329
Subject: Re: Embedded/Microcontroller FPGA and Software Defined Radio
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 10 Sep 2003 18:10:34 -0400
Links: << >>  << T >>  << A >>
You don't ask for much, do you?  ;) 

Tom Hawkins wrote:
> 
> I need a single chip solution for a control system and DSP
> application.

The only hard part of your request is the single chip requirement.  You
can get a lot of peripherals and memory embedded into an MCU, either
small and cheap or some fairly large and powerful.  But not many (if
any) FPGAs have anything other than digital circuits.  One exception is
the PSOC from Cypress.  This is an MCU (don't remember the type, it is
either an 8051 derivative or a custom, 8 bit RISC chip) with
programmable peripheral blocks and memory.  The peripherals can be
digital like a UART or analog like an ADC.  If you only need 50 Hz and
not simultaneous, you can mux a single ADC.  The programmable digital
blocks may be enough for your needs if combined with MCU code.  

> The primary consideration is board area.  The second, cost.
> Here's what I'm looking for:
>   - 5V supply and I/O.
>   - Embedded ADC (at least 1, preferably 8).  Slow rate (50 Hz).
>   - Small FPGA fabric.  About the size of a small spartan.
>   - Embedded block ram (4 KBytes).
>   - Flash FPGA.  Would like not to have separate config prom.
>   - Low I/O count.  I only need about 30 pins.
> 
> Does anything like this exist?  If 5V I/O is not possible, what's
> needed to translate about 12 pins from 3.3/1.2 to 5V?

I don't remember if the PSOC has 5 volt tolerant IOs.  These have
largely disappeared from newer families of logic.  There are several
ways to interface 3.3 volt IOs to 5 volt logic.  It partly depends on
the nature of your 5 volt interface.  If it is just TTL, then you likely
need to do nothing unless there is a chance the TTL levels will exceed
3.5 volts.  Or you can use a bus switch driven from about 4 volt Vcc as
a voltage limiter.  Or you can use a level shifter bus chip.  The bus
chips come in 8 and 16 bit widths and some are very small packages.  

If the PSOC does not float your boat, you will likely need a two chip
design, one for analog and one for FPGA.  You can get an MCU in either
chip along with the analog or FPGA.  There are Flash FPGAs such as the
Lattice XPLD devices.  You didn't give a price target, but I got a quote
once on the 512 macrocell part under $20, IIRC.  

Or if you get an MCU with analog IO, it will likely have enough Flash to
program one of the smaller FPGAs.  May be cheaper than the Flash FPGA.  

You didn't say anything about power.  Most FPGAs are pretty power
hungry.  The CPLDs can be *very* low power.  Both the Lattice parts and
the Xilinx Coolrunner parts can get way below 1 mA if not clocked at a
high rate.  


> Also, what's envolved for FPGA based software defined radio?  I'd like
> to build an RC (as in radio control airplane) receiver.  Most FM
> radios hop between 2 frequencies to encode pulse widths which in turn
> drive the RC servos.  So nothing digital.  It just needs to extract
> the pulse train from the FM.  I would consider trading an FM receiver
> chip for an external high-speed ADC and a larger FPGA if it buys
> enough flexibility.

It has been awhile since I have looked at digital radios, but if I am
still current, the term "software defined radio" implies the final
demodulation stage being done in software.  The processing required for
a digital radio means a high speed ADC at the IF stage and dedicated
hardware for conversion to baseband.  This can be done in an FPGA, but
you are looking at a lot of power to make it work.  This is likely way
overkill for your application.  You would still need the RF part of the
receiver.  Since an analog FM receiver is pretty much one chip, I don't
see how this would help you.  I expect you will find digital receivers
are an advantage when you can share the IF stage between a lot of
downconverters and demodulators such as in a cell phone base station or
similar application.  

-- 

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: 60330
Subject: Duty cycle constraints and internal pulse shaping
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Wed, 10 Sep 2003 22:12:03 GMT
Links: << >>  << T >>  << A >>
In Xilinx ISE/Webpack, among the clock constraints you can also define
the clock duty cycle. Why? I believed that all flip-flops were
edge-sensitive. Is the placer&router somehow influenced by these
constraints? If yes, how?

My question comes from a practical problem I'm having. I need to use a
short pulse (around 4-5 ns) as a clock in a Spartan2 (the frequency is
around 100 MHz, but the problem persists at frequencies a lot lower).
Apparently, even if the FF should be edge-sensitive, there are a lot of
problems with short pulses, sometimes the edges are ignored or
"doubled". My first idea was to "enlarge" the pulses by using a FDC with
CLK connected to pulse, D connected to VCC and Q connected to CLR
through some "delay" logic (buffers, inverters and so on), in order to
have some propagation delay added to the pulse width. This solution
worked poorly: sometimes I compile the project and the FPGA works
nicely, but if I just add a flip-flop or move a signal and recompile the
project, the result is totally unknown. Since I need to change the
firmware often, and I can't test it every single time, this is bad.

Now I have found a way that seems to work always, the schematic is like
this:

http://www.enetsystems.com/~lorenzo/temp/pulse.gif

But I don't think it's very orthodox. :) So I remembered the duty cycle
constraint. Could it help? Actually I need an input stage able to accept
either negative and positive pulses, so the duty cycle would vary from
nearly 0% to nearly 100%.

(of course: no, I can't add external circuits)

-- 
Lorenzo



Article: 60331
Subject: Re: Metatstable Modeling
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 11 Sep 2003 10:29:05 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Let me try to repair the damage I did with my impatience:
> 
> When capturing data that is asynchronous with the clock, the flip-flop
> will inevitably go metastable sooner or later.
> Metastability manifests itself in unpredictable additional clock-to-out delay.
> The user knows the clock frequency, probably knows the data freqiuency
> at least roughly, and should know the amount of tolerable extra delay,
> or the acceptable Mean-Time-Between-Failure.
> 
> Then one can consult the app note and table and see the connection.
> MTBF is always inverse proportional to the product of the clock and data frequencies.
> 
> Last October I published a XilinxTechXclusives paper which shows that at
> a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond
> for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a
> million times for every additional half nanosecond available as extra delay.
> At 3 ns, the MTBF is over a billion years.
> All MTBF values must be scaled by the product of the two frequencies:
> At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times
> longer.

 Is this correct ?
Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5
lots of 'a million times' scalings ?

 Of do you mean the time to trigger a Event, not fail due to one ?

 What about this issue:
  With a CLK.Data stream, the CLK pulses that are not
adjacent to the DATA edges, cannot have metastable events, so 
should not enter the scaling ?



 The best model would seem to be a Data.Aperture AND a Clock.Aperture, 
(both very small, but I don't think they HAVE to be equal )  and
when they overlap/come closer than a critical time threshold, 
the metatstable dice rolls. What happens after the roll, depends on
how far away the next clock is (call this the settling tail) 

 Prediction stats would be an area-overlap basis, and assuming
async signals ( non zero phase velocity ) the area product would
be proportional to 
(Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT)

Typically, Data.EdgeT = Data H or L time 
Clock.EdgeT = ClkPeriod

 This is average trigger/dice roll prediction, but the 
actual 'metastable dice roll profile' will depend on the 
phase velocity, and will have peaks much higher than the average.

 What if your system hits/moves very slowly over this 'phase jackpot' ?

 Here, area-mitigation stats are not much use, and you have to rely 
mainly on the settling tail to next clock ( and maybe a small amount on
the natural system jitter )
IIRC Peter quoted 0.05fs virtual aperture time, and 
natural jitter is likely to be some few ps - certainly large relative to
the aperture ?

 An experimental setup designed to focus on this phase jackpot, 
would give interesting results, and allow peak estimates, as well as a
higher
occurance for more usefull Tail stats gathering.
 
 
 Summary : Best predictor model would have Data.Aperture, Clock.Aperture
and a Settling Tail. 
 Exact nature of the settling tail is system measurable over a range 
of a few decades, but extrapolation is dangerous.  


> So, in short:
> Metastability is unavoidable. All attempts to avoid it are inherently
> doomed, but the quantitative impact of metastability is quite tolerable.
> 
> That's it.

Agreed. I still think from an 'average user' perspective, that a 
specific 'design cell' approach would help.

 Also, from a technical detail viewpoint, implementing a
'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop]
in a single local space, removes routing delays from one metastable
tail.

 It does NOT 'fix' metastable behaviour, but it does encapsulate it,
and move it to the best the silicon can provide, and eliminates 
the potentially variable routing delays.
 It also allows for future technical research and improvements to 
reduce the apertures, and the settling tail.

- jg


> Peter Alfke, Xilinx Applications
> ===================
> Jim Granville wrote:
> >
> > Austin Lesea wrote:
> > >
> > > So what is wrong with telling folks that fixing
> > > metastability is a myth and waste of time?
> >
> > Nothing.
> >
> > > It is similar to the patent office not considering perpetual motion
> > > machines.
> > >
> > > The basic physics of it is well understood, and that is that.....
> >
> >  Perhaps not a ideal choice of words :)
> >
> >  The practical reality and impact of metastability are (hopefully)
> > well understood.
> >  As to basic physics, or even models, well - that seemed to be pretty
> > much up in the air :)
> >
> >  From all of this, I think there emerges a case for
> > a 'Metastable Block' or cell, which can be used in the tools,
> > and that the tools can model, and sdvise-the-use-of.
> >
> >  This could have variants of Fall/Rise edge dual Flip Flips, or
> > a Latch+FF ( effectively the same thing, but may be a better hardware
> > fit on some target devices )
> >  ( Tsu = half clock),
> > or
> > Rise/Rise dual Flip Flop
> > ( Tsu = full clock, but longer metastable settling time )
> >
> >  This would help those who have yet to encounter WHY they
> > need to address metastable events.
> >
> > - jg

Article: 60332
Subject: Re: VGA display
From: "PO Laprise" <plapri@cim.mcgill.ca>
Date: Wed, 10 Sep 2003 15:32:13 -0700
Links: << >>  << T >>  << A >>
You should be careful to try to get as close as you can to the 
exact timing values. We had a lab-full of students implementing 
VGA controllers as part of their end-of-semester project, and 
they managed to burn out quite a few monitors before they got 
the kinks worked out (luckily, they were old monitors just 
laying around the lab, but the lab techs still weren't too 
happy with them ;). I suggest you find up a beat-up old 
monitor that someone is throwing out to use for your tests... 

Have fun, 
Pierre-Olivier 


Article: 60333
Subject: Re: 200MHz ucf constraints for Xilinx DA Decimation by 2
From: "PO Laprise" <plapri@cim.mcgill.ca>
Date: Wed, 10 Sep 2003 15:44:27 -0700
Links: << >>  << T >>  << A >>
Hi Ken, 
When I was working on a part of my project that had a 
clk and a clk2x, I didn't even need to specify the 2x 
period, as my signal was comming from the DCM, and ISE 
found that one itself. However, I did need to insert a 
timing ignore constraint (TIG) on the path that crossed 
my clock domain boundary. I'm always queasy about doing 
such things, and I haven't tested it out physically yet, 
so take it for what it's worth, but it got rid of my error 
messages, at least. 
Pierre-Olivier 



Article: 60334
Subject: Re: Embedded/Microcontroller FPGA and Software Defined Radio
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 11 Sep 2003 10:51:06 +1200
Links: << >>  << T >>  << A >>
Tom Hawkins wrote:
> 
> I need a single chip solution for a control system and DSP
> application.
> The primary consideration is board area.  The second, cost.
> Here's what I'm looking for:
>   - 5V supply and I/O.
>   - Embedded ADC (at least 1, preferably 8).  Slow rate (50 Hz).
>   - Small FPGA fabric.  About the size of a small spartan.
>   - Embedded block ram (4 KBytes).
>   - Flash FPGA.  Would like not to have separate config prom.
>   - Low I/O count.  I only need about 30 pins.
> 
> Does anything like this exist?  

 All in one package ? No.

 Triscend do a 80C51 + FPGA -> needs external loader, no ADC
 SoftCores + Std FPGA       -> needs external loader, No ADC
 ActelProASIC               -> Is FLASH, but needs Core + ADC
 STm uPSD family            -> Has CPLD to 32 MCells Q42003
 Cygnal                     -> FLASH.ADC, needs external FPGA
 Generic DSP devices        -> needs external FPGA

 You need to nail down just how much DSP or control maths you 
need, and then find out how much of the small FPGA cannot be
done in SW, or in the case of uPSD, in the Timer/Counter 
Peripherals assisted by the CPLD.

 - jg

Article: 60335
Subject: Re: Crystal Input to FPGA
From: panteltje@yahoo.com (Jan Panteltje)
Date: 10 Sep 2003 16:16:33 -0700
Links: << >>  << T >>  << A >>
nagaraj_c_s@yahoo.com (Nagaraj) wrote in message news:<91710219.0309100448.6e8ab050@posting.google.com>...
> Hi,
>    I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
> devices like XC2000 series had crystal input provision which is not
> there in Spartan 30K gate device which I am using for my design.
>    I want to know how to build an oscillator circuit (amplifier) for
> the crystal in FPGA.
>    Any references?
> 
> Regards,
> Nagaraj


>Hi,
>   I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
>devices like XC2000 series had crystal input provision which is not
>there in Spartan 30K gate device which I am using for my design.
>   I want to know how to build an oscillator circuit (amplifier) for
>the crystal in FPGA.
>   Any references?
>
>Regards,
>Nagaraj
>
mmm many people are paranoid about xtal oscillators it seems.
Still I agree the small integrated DIL ones are cheap and easy,
but for the ones who MUST use an xtal when all shops are closed,
this solution has always worked for me:


                               +5V
                               | drain
                          |---- 
  ----------------------->|       BF245 B
 |      |        |        |----
 |      |       === C          |-----------0 to TTL level input
 |      |        |-------------|
 |      |        |             |
---    | |       |            | |
 =     | |       |            | |
---    | |100k   |            | | 1k5
 |XTAL  |       === 2 C        |
 |      |        |             |
  -----------------------------------------0

It can drive a HCT7404 or such directly.
Stability is very very good.
The caps ratio is 1 to 2 C, values like 22 and 44 pF (2 22 in parallel)
I use.

If the drawing looks distorted use a fixed spacing font perhaps.
I have uses this at 20MHz, 8.8MHz, 6 MHz, 100kHz, etc...
Always works.
Decauple the +5.
The output looks like a sine wave, bit flatted, but very clean.
If you want total separation, you can use a drain resistor and take
the signal from there.
Add a varicap with a small series cap parallel to the XTAL to make a voltage
controlled oscillator for a PLL etc..
(For example color subcarrier lock).
JP

Article: 60336
Subject: Re: What clock domain is a Xilinx DCM LOCK signal in?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 10 Sep 2003 16:21:25 -0700
Links: << >>  << T >>  << A >>
You can phase align feedback using either the CLK0 or CLK2X DCM outputs.

There is a relatively new application note on DCMs in Spartan-3 that may be
useful to your question.

XAPP462:  Using Digital Clock Managers (DCMs) in Spartan-3 FPGAs
http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf

Phase alignment is optional for the Digital Frequency Synthesizer function
in a DCM.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC


"John Providenza" <johnp3+nospam@probo.com> wrote in message
news:349ef8f4.0309101349.2cbe675a@posting.google.com...
> I don't see in the Xilinx documentation in what clock domain
> the LOCK signal coming from a DCM is produced.  Do I need to
> synchronize it into the CLK0 domain to avoid metastability?
>
> Thanks!
>
>
> John Providenza



Article: 60337
Subject: Re: Original (5V) Xilinx Spartan ?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 10 Sep 2003 16:34:33 -0700
Links: << >>  << T >>  << A >>
I checked with  Spartan marketing  ( I will never quote specific prices
without their blessing ), and they confirmed my numbers:

The price per LUT/flip-flop is not constant.
At the small end, the package cost drives it up,
 and at the high end, it is the yield loss that drives it up.

The sweet spot is around the 3S1000 with 15 360 LUTs/FFs. 
It will sell in late 2004, slowest speed grade in large quantities for
$20. 
That's 0.13 cents per LUT/FF.

The number for the 2S400 is $10 for 3840 LUTs/FFs = 0.26 cents per LUT
For the top-end 3S5000 it is $150 for 66 560 LUTs/FFs = 0.23 cents per LUT.

That means I was pretty close with my 0.2 cents.

Peter Alfke

===================================
rickman wrote:
>
> Peter,
> 
> I would like to know how you came to this number for the Spartan3
> parts.  If I use this number for the XC3S400, I get 7168 x $0.002 =
> $14.336.  For the XC3S5000 I get 66,560 x $.002 = $133.12.  Are these
> realistic prices at all?  What assumptions did you use?
> 
> I understand that your .2 cents figure is only a rough rule of thumb,
> but to be at all useful an understanding of the basis is needed.
> 
> BTW, the discussion on metastability may appear to be a waste of
> "bandwidth", but it is an important discussion since most people seem to
> learn about it here rather than in school or elsewhere.  I know there
> were a great many things that were never even mentioned in school that
> turned out to be essential to designing good circuits in the "real
> world".
> 
> --
> 
> 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: 60338
Subject: Newbee question? Schematic entry
From: "juice28" <arcadexpo@mchsi.com>
Date: Wed, 10 Sep 2003 23:50:33 GMT
Links: << >>  << T >>  << A >>
Maybe a dumb question, but can a schematic built and tested in circuit maker
2000 be imported to Xilinx webpack and fitted to cpld rather then using
webpacks schematic entry.

Thanks,

Fred




Article: 60339
Subject: Re: Crystal Input to FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 10 Sep 2003 16:59:32 -0700
Links: << >>  << T >>  << A >>
This is a classical circuit that always works. Note that there is only a
single stage of amplification, a single transistor. So no weird
phase/gain characteristi, just a single stage with a 6dB per octave roll-off.
Unfortunately you cannot implement this between two FPGA pins. 
We added too much stuff (for a good reason, to serve normal applications ).
Peter Alfke
============
Jan Panteltje wrote:
> >
> mmm many people are paranoid about xtal oscillators it seems.
> Still I agree the small integrated DIL ones are cheap and easy,
> but for the ones who MUST use an xtal when all shops are closed,
> this solution has always worked for me:
> 
>                                +5V
>                                | drain
>                           |----
>   ----------------------->|       BF245 B
>  |      |        |        |----
>  |      |       === C          |-----------0 to TTL level input
>  |      |        |-------------|
>  |      |        |             |
> ---    | |       |            | |
>  =     | |       |            | |
> ---    | |100k   |            | | 1k5
>  |XTAL  |       === 2 C        |
>  |      |        |             |
>   -----------------------------------------0
> 
> It can drive a HCT7404 or such directly.
> Stability is very very good.
> The caps ratio is 1 to 2 C, values like 22 and 44 pF (2 22 in parallel)
> I use.
> 
> If the drawing looks distorted use a fixed spacing font perhaps.
> I have uses this at 20MHz, 8.8MHz, 6 MHz, 100kHz, etc...
> Always works.
> Decauple the +5.
> The output looks like a sine wave, bit flatted, but very clean.
> If you want total separation, you can use a drain resistor and take
> the signal from there.
> Add a varicap with a small series cap parallel to the XTAL to make a voltage
> controlled oscillator for a PLL etc..
> (For example color subcarrier lock).
> JP

Article: 60340
Subject: Re: Spartan-3 3S50 in Web ISE 5.2i = no block RAM, no multiplier?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 10 Sep 2003 17:06:41 -0700
Links: << >>  << T >>  << A >>
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> writes:
> WebPack ISE 5.2i only supports the device called the XC3S50J (note the 'J'),
> which has no block RAM or multipliers.
> 
> WebPack ISE 6.1i, due out at the end of September, supports the XC3S50 (no
> 'J'),  which has four 18Kbit block RAMs, four 18x18 hardware multipliers,
> and two Digital Clock Managers (DCMs).

Will 6.1i and future versions continue to support the XC3S50J?  Or do we
need to keep the 5.2i release around for those?

What does the "i" at the end of the software version mean, anyhow?

Article: 60341
Subject: Re: Original (5V) Xilinx Spartan ?
From: "Pete Fraser" <pete@rgb.com>
Date: Wed, 10 Sep 2003 17:49:34 -0700
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F5FB508.CC525671@xilinx.com...
> I checked with  Spartan marketing  ( I will never quote specific prices
> without their blessing ), and they confirmed my numbers:
>
> The price per LUT/flip-flop is not constant.
> At the small end, the package cost drives it up,
>  and at the high end, it is the yield loss that drives it up.
>
> The sweet spot is around the 3S1000 with 15 360 LUTs/FFs.
> It will sell in late 2004, slowest speed grade in large quantities for
> $20.
> That's 0.13 cents per LUT/FF.
>

I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities.

(This was a recent Xilinx quote.)

I also assume that the $20 figure is for seriously large quanities,
but I'm still surprised there's that much of a difference.



Article: 60342
(removed)


Article: 60343
Subject: Re: Crystal Input to FPGA
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Thu, 11 Sep 2003 01:14:55 GMT
Links: << >>  << T >>  << A >>

"Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message
news:91710219.0309100448.6e8ab050@posting.google.com...
> Hi,
>    I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
> devices like XC2000 series had crystal input provision which is not
> there in Spartan 30K gate device which I am using for my design.
>    I want to know how to build an oscillator circuit (amplifier) for
> the crystal in FPGA.
>    Any references?

The oscillator that I used to know used three CMOS inverting gates in series
with the crystal wrapped around them.  Possibly some resistors, too.
Usually one more gate to buffer and shape the result.

Though I remember people having a hard time sometimes with the 32kHz
crystals, it worked well for everything else.

-- glen



Article: 60344
Subject: Re: CMOS camera w/ USB2 -- crazy?
From: Andrew Paule <lsboogy@qwest.net>
Date: Wed, 10 Sep 2003 20:57:32 -0500
Links: << >>  << T >>  << A >>


Use the micro to set up the packets in an FGPA/ASIC under isocronous 
control, and stream them out from there, if you can deal with the low 
data/frame rates - I used to build large format (4 x 5 and hasseblad) 
camera digital inserts using big CCD's - USB (even at 12Mbs is too slow 
for this stuff  ( a 1Mpixel at 8 bit will require 2/3 sec + overhead to 
empty one frame) - tell you boss it sounds cool, but you need 1394 
(firewire) or SCSI to do this worth a DS.  If you simply want to capture 
one frame and empty it - consider dumping it to RAM and then out  from 
there.  Leaving stuff on a sensor - CCD or CMOS (yes CCD's are CMOS, 
both n and p  type are built)  results in large dark currents that make 
them unusable.  At 2/3 second, well depth will be a large consideration 
here - electrons like to move around.

Andrew

james wrote:

>On Sun, 07 Sep 2003 15:03:39 GMT, "GB" <donotspam_grantbt@jps.net>
>wrote:
>
>  
>
>>Hi,
>>
>>I'm a firmware guy pulled into a project well out of my area of
>>expertise.  My boss wants to build (essentially) a digital camera
>>using an image sensor chip (1600x1200) and output it's data
>>"as fast as possible" using USB2.0.  His initial concept, being
>>that I'm a firmware guy, was to use a "really fast micro."
>>Normally the company is involved with small 8-bitter micro
>>projects, so you can see I'm well out of my normal bounds.
>>
>>Now this seems like a pretty big stretch to me... and I don't see
>>how it can be done without the speed of hardware (the image
>>chips all seem to have clock speeds in the tens of MHz and the
>>USB2 transfer rate is 480Mbps (theor.).  Do aspects of this
>>project require an FPGA to keep the data "as fast as possible?"
>>If we use and FPGA for camera-to-RAM and then use a
>>micro for the USB2 part, what kind of fast micros can
>>move data at that rate?
>>
>>Also, this is something that I am sure we will have to contract
>>out, so if you have any past experience with this, please let
>>me know your thoughts (and if you are available).
>>
>>Thanks!
>>
>>    
>>
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>1600x 1200 is essentially a 2 megapixel camera!
>
>1) First step is to determine what the camera is going to be used for!
>
>Terrestial or astronomical or video photography  
>
>2) Pick an imager! Either Sony, TI, Kodak, or Panasonic to name a few.
>
>3) From the Imager specs you can derive how fast the data can be
>clocked out of the imager. Most imagers will transfer the image area
>into a serial register one line at a time. How fast this is depends on
>how fast you can clock the serial register. Transfer speeds differ
>from vendor to vendor. 
>
>4) Then build the circuitry around the imager based on its ability to
>transfer the full image as fast as you want and that meet your cost
>goals.  
>
>Again depending on what you determine as reasonably fast will effect
>the cost of the imager along with its size. Another consideration will
>be the speed of the ADC. That can slow things down also. Even if you
>can clock the serial register of the imager out at 20Mhz rate, if the
>ADC sasmple rate is 10 MHz  that is as fast as you can get the pixel
>data out. 
>
>IF your imager's max clock frequency for the serial register is 20
>MHz., you can clock a 1600 pixel row out in about 80 uS. Or the whole
>image area out of the chip in about 100 mS.  So your microC or FPGA
>will have to read the ADC once every 50 nS or so during the readout
>period. 
>
>There are some CPU cores as well as USB cores that can drop into an
>FPGA. You can build a large FIFO or add onboard flash to store the
>picture. 
>
>It is not crazy at all in fact it is quite doable. The two key items
>in a digital camera is the imager and the ADC. All the rest is digital
>hardware that is well suited for an ASIC or FPGA.  
>
>
>james
>
>  
>




Article: 60345
Subject: Re: Newbee question? Schematic entry
From: Andrew Paule <lsboogy@qwest.net>
Date: Wed, 10 Sep 2003 20:58:33 -0500
Links: << >>  << T >>  << A >>
turn it into an EDIF with no in/out buffers, and use it as a black box.

Andrew

juice28 wrote:

>Maybe a dumb question, but can a schematic built and tested in circuit maker
>2000 be imported to Xilinx webpack and fitted to cpld rather then using
>webpacks schematic entry.
>
>Thanks,
>
>Fred
>
>
>
>  
>


Article: 60346
Subject: Re: Metatstable Modeling
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 10 Sep 2003 22:00:32 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> Peter Alfke wrote:
> >
> > Let me try to repair the damage I did with my impatience:
> >
> > When capturing data that is asynchronous with the clock, the flip-flop
> > will inevitably go metastable sooner or later.
> > Metastability manifests itself in unpredictable additional clock-to-out delay.
> > The user knows the clock frequency, probably knows the data freqiuency
> > at least roughly, and should know the amount of tolerable extra delay,
> > or the acceptable Mean-Time-Between-Failure.
> >
> > Then one can consult the app note and table and see the connection.
> > MTBF is always inverse proportional to the product of the clock and data frequencies.
> >
> > Last October I published a XilinxTechXclusives paper which shows that at
> > a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond
> > for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a
> > million times for every additional half nanosecond available as extra delay.
> > At 3 ns, the MTBF is over a billion years.
> > All MTBF values must be scaled by the product of the two frequencies:
> > At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times
> > longer.
> 
>  Is this correct ?
> Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5
> lots of 'a million times' scalings ?

Jim,  I have seen your name here before, but I don't know what your
level of understanding of metastability is.  So forgive me if I sound
like I am talking down to you.  I don't know if you are trying to
discuss fine details of this topic or if you are new to the issues of
metastability.  

If you look up references about metastability you will find that the
MTBF time scales linearly with clock and data rate, but exponentially
with settling time.  There is a constant for each part of the equation. 
These two constants are what characterize a particular FF design and
process used to build it.  Peter's comment is saying that if you allow
just 3 ns settling time with his rates and parts, you will have an MTBF
of a billion years.  Certainly you can go longer and get MTBF times
longer than the age of the universe.  So yes, 10 ns would be way more
than enough.  


>  Of do you mean the time to trigger a Event, not fail due to one ?

No, a metastable event will happen with a much higher rate based only on
the rate of the clock and data.  But it will have no impact on your
circuit if you don't use the output until after the metastability has
settled out.  Given a time period this calculation determines how often
the metastable event will persist and cause an error.  


>  What about this issue:
>   With a CLK.Data stream, the CLK pulses that are not
> adjacent to the DATA edges, cannot have metastable events, so
> should not enter the scaling ?

This is already considered in the calculation.  That is why the
frequencies are multiplied.  The assumption is that the two rates are
truely asynchronous and are not correlated in any way.  The the chance
of them happening in just the right timing relation is a function of how
often each of them is occuring.  

 
>  The best model would seem to be a Data.Aperture AND a Clock.Aperture,
> (both very small, but I don't think they HAVE to be equal )  and
> when they overlap/come closer than a critical time threshold,
> the metatstable dice rolls. What happens after the roll, depends on
> how far away the next clock is (call this the settling tail)

This may sound good, but it no different than the current model and
would be much harder to measure.  It is best not to think too hard about
this, but rather to be a bit on the empirical side.  That seems to be
one way that Peter is very smart.  His measurements seem very good to me
and many others.  It is no good to rationalize about things you really
can't measure. 


>  Prediction stats would be an area-overlap basis, and assuming
> async signals ( non zero phase velocity ) the area product would
> be proportional to
> (Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT)
> 
> Typically, Data.EdgeT = Data H or L time
> Clock.EdgeT = ClkPeriod
> 
>  This is average trigger/dice roll prediction, but the
> actual 'metastable dice roll profile' will depend on the
> phase velocity, and will have peaks much higher than the average.

I think "phase velocity" is *way* over the top.  Before improving on the
current formula, it would be good to find something wrong with it.  Is
there anything about it that falls short?  


>  What if your system hits/moves very slowly over this 'phase jackpot' ?
> 
>  Here, area-mitigation stats are not much use, and you have to rely
> mainly on the settling tail to next clock ( and maybe a small amount on
> the natural system jitter )
> IIRC Peter quoted 0.05fs virtual aperture time, and
> natural jitter is likely to be some few ps - certainly large relative to
> the aperture ?

All of this is really just a way to relate what is happening.  Since the
noise in the circuit is relatively large, I would expect tons more
jitter in the "window" than the actual width.  So really the fs window
is just a concept, not a very real event.  


>  An experimental setup designed to focus on this phase jackpot,
> would give interesting results, and allow peak estimates, as well as a
> higher
> occurance for more usefull Tail stats gathering.
> 
> 
>  Summary : Best predictor model would have Data.Aperture, Clock.Aperture
> and a Settling Tail.
>  Exact nature of the settling tail is system measurable over a range
> of a few decades, but extrapolation is dangerous.

Can you explain how this would be better than the current model?  


> > So, in short:
> > Metastability is unavoidable. All attempts to avoid it are inherently
> > doomed, but the quantitative impact of metastability is quite tolerable.
> >
> > That's it.
> 
> Agreed. I still think from an 'average user' perspective, that a
> specific 'design cell' approach would help.
> 
>  Also, from a technical detail viewpoint, implementing a
> 'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop]
> in a single local space, removes routing delays from one metastable
> tail.
> 
>  It does NOT 'fix' metastable behaviour, but it does encapsulate it,
> and move it to the best the silicon can provide, and eliminates
> the potentially variable routing delays.
>  It also allows for future technical research and improvements to
> reduce the apertures, and the settling tail.

Or you can just use the double FF approach and require a routing time
for this path that is at least 3 ns less than the clock period.  Again,
simple, empirical and effective.  

-- 

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: 60347
Subject: Re: Original (5V) Xilinx Spartan ?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 10 Sep 2003 22:04:36 -0400
Links: << >>  << T >>  << A >>
Pete Fraser wrote:
> 
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3F5FB508.CC525671@xilinx.com...
> > I checked with  Spartan marketing  ( I will never quote specific prices
> > without their blessing ), and they confirmed my numbers:
> >
> > The price per LUT/flip-flop is not constant.
> > At the small end, the package cost drives it up,
> >  and at the high end, it is the yield loss that drives it up.
> >
> > The sweet spot is around the 3S1000 with 15 360 LUTs/FFs.
> > It will sell in late 2004, slowest speed grade in large quantities for
> > $20.
> > That's 0.13 cents per LUT/FF.
> >
> 
> I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities.
> 
> (This was a recent Xilinx quote.)
> 
> I also assume that the $20 figure is for seriously large quanities,
> but I'm still surprised there's that much of a difference.

I recommend that you find an alternative and go back to your supplier
for a better price.  I have not gotten a quote for this part, but based
on my experience you should be able to do better than $40 at your volume
and package.  You might be able to get below $30.  

-- 

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: 60348
Subject: Re: Crystal Input to FPGA
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 10 Sep 2003 22:06:21 -0400
Links: << >>  << T >>  << A >>
Glen Herrmannsfeldt wrote:
> 
> "Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message
> news:91710219.0309100448.6e8ab050@posting.google.com...
> > Hi,
> >    I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
> > devices like XC2000 series had crystal input provision which is not
> > there in Spartan 30K gate device which I am using for my design.
> >    I want to know how to build an oscillator circuit (amplifier) for
> > the crystal in FPGA.
> >    Any references?
> 
> The oscillator that I used to know used three CMOS inverting gates in series
> with the crystal wrapped around them.  Possibly some resistors, too.
> Usually one more gate to buffer and shape the result.
> 
> Though I remember people having a hard time sometimes with the 32kHz
> crystals, it worked well for everything else.

But what is the advantage over an oscillator unless you are trying to
squeze every penny out of the design?  The difference between an
oscillator and a crystal is less than $.50.  

-- 

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: 60349
Subject: test signals for testing of leaf level entities in a design
From: nachikap@yahoo.com (Nachiket Kapre)
Date: 10 Sep 2003 19:13:22 -0700
Links: << >>  << T >>  << A >>
Hi,
During hierarchical design we often break down the design into small
manageable parts. Now inter block communication specs are specified
for this design alongwith internal function requirements. To verify
the internal functioning and to simulate the external inputs to this
design, we usually write force files in Modelsim. Now if we create a
set of commmonly available stimuli like do-done handshake, random
pulses, random duration levels, etc in Tcl, we could directly apply
them to the signals on the interface we want to check. For response
type of interfaces we could add dummy "done" generators. Now once such
a suite of test inputs is available, we could easily test most of the
small entities in a zap. Is such a tool done already? and are there
some more types of communication behavious i am overlooking? I somehow
think Modelsim signal forcing interface and the do-file writing for
such a forcing is a dumb and painful way of testing things.

regards,
nachiket.



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