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 99375

Article: 99375
Subject: Re: OpenSPARC released
From: "J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces)">
Date: Thu, 23 Mar 2006 10:06:31 -0800
Links: << >>  << T >>  << A >>
Jason Zheng wrote:
> J o h n _ E a t o n (at) hp . com (no spaces) wrote:
> 
>> Michael wrote:
>>
>>> Weng Tianxiang wrote:
>>>
>>>> Hi Pablo,
>>>> Thank you for your useful information.
>>>>
>>>> Weng
>>>
>>>
>>>
>>>
>>> The problem is "System Requirements": "SPARC CPU based system"
>>>
>>
>> Is that for the software development environment?. Seems like the
>> verilog rtl code should be pretty generic. From the description it
>> sounds more like a big compute farm engine rather than something
>> you would put in a fpga for an embedded system.
>>
>>
>>
>> John Eaton
> 
> 
> Why not? This would be a great teaching tool for fpga design and/or 
> computer system design courses at college level.
> 
> ~jz


Only if it can fit into an FPGA. Anybody have a gatecount?

John Eaton

Article: 99376
Subject: Re: Number of taps for a FIR
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 23 Mar 2006 10:58:13 -0800
Links: << >>  << T >>  << A >>
Symon wrote:

> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:4422e0f2$0$15787$14726298@news.sunsite.dk...
> 
>>"Roger Bourne" <rover8898@hotmail.com> wrote in message 
>>news:1143136101.823610.180860@u72g2000cwu.googlegroups.com...
>>
>>>Hello all,
>>>
>>>I am planning to introduce a decimation filter in my FPGA design in
>>>order to reduce the sample frequency by 8. This has resulted in a 61
>>>tap FIR filter. -It seems awfully large. Basically, I am asking , for
>>>an FPGA implementation, what is a REASONNABLE number of taps for a FIR
>>>filter?
>>>
>>
>>Roger,
>>Look at making your filter as a series of half-band FIR filters. These are 
>>efficient in that every other tap is zero. (Nice and easy to multiply by 
>>zero!) Use three, decimating by two at each stage. Your implementation 
>>should be a lot more compact. The later stages will probably have more 
>>taps, but the sample rate will be reduced, possibly allowing you to use 
>>distributed arithmetic.
>>Cheers, Syms.
>>
> 
> Also, check out CIC (cascaded integrator comb) filters? Although 8 may not 
> be a high enough decimation factor to make this method worthwhile.
> Cheers, Syms 
> 
> 
And keep in mind that when you decimate you don't need anti-aliasing at 
Nyquist (1/4 samples), you only need it at those frequencies where the 
energy is going to get through your IIR filters -- I see needing a 
3-stage CIC filter to do this, which with a boneheaded implementation 
only requires 24 taps.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Article: 99377
Subject: Re: Lattice FPGA
From: John_H <johnhandwork@mail.com>
Date: Thu, 23 Mar 2006 19:14:32 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Looks nice, but...
> 
> If you could only get them (ST2GX or SC).
> 
> At least we have shipped all our backlog on xc4vFX devices.
> 
> Austin

Are the MGTs up and running?  I'd love to prototype with the FX20.

Article: 99378
Subject: Re: Lattice FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 11:39:59 -0800
Links: << >>  << T >>  << A >>
John, Antti,

I will say that if you place an order now, you will get a real delivery 
date, and the parts will be shipped (we are not supply constrained for 
the part numbers).

For details, you really need to contact your FAE.

There are more than one sample part number for the FX20, FX60, and I 
believe now the FX100, that are available.

The FXs with MGTs are rolling out now, so that train is back on its tracks.

In all honesty, there is a lot of characterization left to do, that was 
delayed because of the changes, so we still very busy with MGTs here.

I have been lately working with some universities and schools in the XUP 
program to expedite FX parts for them (as they were the last on the 
list, so if we are getting some MGTs for them, things must be better!).

Austin

John_H wrote:

> Austin Lesea wrote:
> 
>> Looks nice, but...
>>
>> If you could only get them (ST2GX or SC).
>>
>> At least we have shipped all our backlog on xc4vFX devices.
>>
>> Austin
> 
> 
> Are the MGTs up and running?  I'd love to prototype with the FX20.

Article: 99379
Subject: Re: OpenSPARC released
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 23 Mar 2006 11:49:35 -0800
Links: << >>  << T >>  << A >>
Personally I think the best textbook on logic design is AMD
PAL Device Handbook. All my logic training was based on the book, read
by myself, not taught at any classes.

I bought 5 VHDL books, but only the AMD book really teaches me how to
program in logic.

The open CPU source code is an excellent contributions to the
generations of logic designers by Sun Microsystem.

It would be much wonderful If there is an retired engineer from Sun who
deeply invovled in the code making writes a book with the opened source
code. It would be more valuable than any Verilog books available in the
market.

Teaching by example is the best way to teach a language and related
technique.

Real design examples give you really deep insights on what the
designers were thinking about and how nicely they handle the difficult
situations.

I appreciate Sun's efforts to open its source code.

Thank you, Sun Microsystem.

Weng


Article: 99380
Subject: Re: this JTAG thing is a joke
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Thu, 23 Mar 2006 13:58:53 -0600
Links: << >>  << T >>  << A >>


Falk Brunner wrote:

>
> Theory: Nothing works but everone knows why.
> Practice: Everything works but nobody knows why.
> Theory + Practice : Nothing works and nobody knows why.
>
> ;-)

This is one of the best I've ever heard!

>
> P.S. One of the problems with JTAG is/was, that people underestimate 
> problems due to the low frequencies involved. And as far as I 
> remember, the are/were some nasty problems with FPGAs for brand . . . 
> because the JTAG inputs (especially the clock) was sensitive to 
> non-perfect transitions, which means you have to treat the almost DC 
> like JTAG like a GBit transmission line. Not nice at all. The 
> suggestion of Austin to do a simulation is in general right, but 
> sounds a little bit strange to me. Simulate a 5 MHz clock signal 
> ?(Yeah yeah, I know, its transition time that matters, not frequency). 
> So why is the JTAG (clock) not INTENTINALLY made slower (+ schmitt 
> trigger) to avoid this problems? Nobody needs a 100MHz++ capable JTAG 
> port (today).

On many FPGA's, especially Xilinx, the JTAG signals are on pins that can 
be used as
normal user I/O pins.  So, they would have to put special filters on the 
pins when used
for JTAG, and remove the filter for normal use.  Clearly could be done, 
but it gets
complicated.  And, you never know how fast any specific user might run 
their JTAG.
In some cases, a user might rig an FPGA and a local memory to do very 
fast loading
or testing on their production line.

I had a similar problem with a 5 V Spartan FPGA.  It implemented a long 
serial chain
for configuration sensing/setup on a motherboard with up to 16 
daughterboards.   The
command/control was via LVDS, which had WAY more bandwidth than needed, but
they fit the other requirements.  We had some reflections on the LVDS 
lines that caused
double pulses on the serial clock.  So, I had to implement an external 
filter with an RC
and a Schmitt trigger before feeding the clock to the FPGA.  It was hard 
to track down,
it was one of those "only works with the scope probe on the pin" 
conditions.  Once
I knew what was going on, it was easy to fix.

Jon


Article: 99381
Subject: Re: this JTAG thing is a joke
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 08:04:25 +1200
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
<snip>> P.S. One of the problems with JTAG is/was, that people 
underestimate
> problems due to the low frequencies involved. And as far as I remember, 
> the are/were some nasty problems with FPGAs for brand . . . because the 
> JTAG inputs (especially the clock) was sensitive to non-perfect 
> transitions, which means you have to treat the almost DC like JTAG like 
> a GBit transmission line. Not nice at all. The suggestion of Austin to 
> do a simulation is in general right, but sounds a little bit strange to 
> me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition 
> time that matters, not frequency). So why is the JTAG (clock) not 
> INTENTINALLY made slower (+ schmitt trigger) to avoid this problems? 
> Nobody needs a 100MHz++ capable JTAG port (today).

  The latest Serial memories from Winbond can stream at 150Mbd, from an
8 pin package !

  That makes even 100MHz look sluggish.

  There is talk of USB-JTAG, which is sensible, and that should be
high speed USB, in that case, FPGA suppliers SHOULD be working on
~400MBd capable JTAG streaming.

-jg


Article: 99382
Subject: Re: help on RISC controller developed mikej
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 23 Mar 2006 20:27:11 GMT
Links: << >>  << T >>  << A >>
If you had read the (admittedly sparse) documentation you would have noticed 
it is targeted by default to Xilinx architecture and instantiates directly 
some Xilinx primitives. In each file there is a second architecture 
(surrounded by --pragma translate_off / --pragma translate_on) statements 
which is a generic RTL version for the simulator. If you remove these 
pragmas, the synthesis tool will then see the generic version.

I cannot help you more as you do not say which tool is generating the 
warnings, or what you are trying to do.
/MikeJ

"sel" <selva991@gmail.com> wrote in message 
news:1143128217.112200.175140@j33g2000cwa.googlegroups.com...
> now i have the complete correct code ( i got that from open cores.org)
> and i could pin point the errors im uploading the whole code
>  fist let me tell the errors when i compiled the code
> 1.in mux8 file im getting
> Warning: ELAB1_0026: mux8.vhd : (87, 0): There is no default binding
> for component "lut4".(No entity named "lut4" was found).
> Error: COMP96_0078: mux8.vhd : (84, 22): Unknown identifier
> "mux8_lut4".
> Error: COMP96_0133: mux8.vhd : (84, 22): Cannot find object
> declaration.
> Error: COMP96_0078: mux8.vhd : (83, 22): Unknown identifier
> "mux8_lut3".
> Error: COMP96_0133: mux8.vhd : (83, 22): Cannot find object
> declaration.
> Error: COMP96_0078: mux8.vhd : (82, 22): Unknown identifier
> "mux8_lut2".
> Error: COMP96_0133: mux8.vhd : (82, 22): Cannot find object
> declaration.
>
> 2.in mux4 file im geting
> Warning: ELAB1_0026: mux4.vhd : (75, 0): There is no default binding
> for component "lut4".(No entity named "lut4" was found).
> Error: COMP96_0078: mux4.vhd : (72, 22): Unknown identifier
> "mux8_lut2".
> Error: COMP96_0133: mux4.vhd : (72, 22): Cannot find object
> declaration.
> Compile Architecture "RTL" of Entity "MUX4"
> Compile failure 2 Errors 1 Warnings  Analysis time :  0.1 [s]
>
> 3.in risc5x_xil as
> warning: ELAB1_0026: risc5x_xil.vhd : (189, 0): There is no default
> binding for component "ramb4_s2_s2".(No entity named "ramb4_s2_s2" was
> found).
>
> 4.in add_sub
> Warning: ELAB1_0026: add_sub.vhd : (76, 0): There is no default binding
> for component "lut4".(No entity named "lut4" was found).
> Warning: ELAB1_0026: add_sub.vhd : (90, 0): There is no default binding
> for component "mult_and".(No entity named "mult_and" was found).
> Warning: ELAB1_0026: add_sub.vhd : (97, 0): There is no default binding
> for component "muxcy".(No entity named "muxcy" was found).
> Warning: ELAB1_0026: add_sub.vhd : (105, 0): There is no default
> binding for component "xorcy".(No entity named "xorcy" was found).
> better the whole proram is here u ca run urself and u could debug the
> errors
> "  http://www.opencores.net/cvsweb.shtml/risc5x/"
>
> pls pls pls pls reply
> 



Article: 99383
Subject: Digital filter design software?
From: "Bubb" <bubb@telia.se>
Date: Thu, 23 Mar 2006 21:28:41 +0100
Links: << >>  << T >>  << A >>
Hello



Iím wondering if there is any filter design software that can handle all
required calculations in designing decimating or interpolating filters or
iir and fir filters?

Thanks



Article: 99384
Subject: Re: this JTAG thing is a joke
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 23 Mar 2006 21:41:20 +0100
Links: << >>  << T >>  << A >>
Jim Granville schrieb:

>  The latest Serial memories from Winbond can stream at 150Mbd, from an
> 8 pin package !

Uuups!

>  That makes even 100MHz look sluggish.
> 
>  There is talk of USB-JTAG, which is sensible, and that should be
> high speed USB, in that case, FPGA suppliers SHOULD be working on
> ~400MBd capable JTAG streaming.

Really? But would this kick out the basic concept of JTAG being simple 
and low efford? I mean a normal JTAG chain runs just TMS/TCK as a single 
line from chip to chip and TDI/TDO in a daisy chain. Done. 400 Mbit/s 
would require diffent I/Os than plain LVCMOS etc. Hmmm.
Maybe for some memories, but for all other ICs??

Regards
Falk

Article: 99385
Subject: Timing Diagram software recommendations?
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Thu, 23 Mar 2006 21:00:04 -0000
Links: << >>  << T >>  << A >>
When working on the low level design of FPGA modules I usually
draw out a data path timing diagram showing what's happening
on each sucessive clock cycle.

I have a word 'template' I've been using to do this for years, but
I often think it might be quicker/more permanent/better for
documentation if I used a custom Timing Diagram drawing program.

A very quick search shows these seem to be the options....

1) Chronology's Timing Designer
http://www.timingdesigner.com/

2) Synapticad's Timing Diagrammer Pro
http://www.syncad.com/ttd_main.htm

Top of the range all singing all dancing design tools for complex
board design/analysis. Quite complex to use (?) with a reasonable
learning curve. Cost ~ $1500 for 1 node locked license.

3) Timing Tool
http://www.timingtool.com/

This seems to be an interim solution, although it looks reasonably
powerful. Probably not as difficult to pick up as 1) and 2).
Cost - $795

3a) Timing Tool Lite - a web based lower featured version of timing tool.

I'd rather be working directly on my PC, although this is free.


4) Timing Gen
http://www.xfusionsoftware.com/

Low end diagram drawing tool, this seems to be fairly new and doesn't
include any analysis features. I'm not sure how flexible this is, they
suggest importing things into Word to aid annotation etc.
Cost - $129.95



I think what I'm lookign for is something between 3) and 4). This isn't
essential so I don't want to spend $800 on it, but I think I'd like
something a bit more capable than Timing Gen although I haven't
experimented with it much, and it would be hard to beat for the cost.


Can anyone offer opinions on the packages above or and other suggestions?

Thanks in advance for any feedback,


Nial Stewart




----------------------------------------------------------
Nial Stewart Developments Ltd        Tel: +44 131 561 6291
42/2 Hardengreen Business Park       Fax: +44 131 561 6327
Dalkeith, Midlothian
EH22 3NU
www.nialstewartdevelopments.co.uk










Article: 99386
Subject: Re: for all those who believe in ASICs....
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 09:23:09 +1200
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:

> http://www.fpgajournal.com/articles_2006/20060321_bell.htm
> 

and also this one :
http://www.eet.com/news/design/showArticle.jhtml?articleID=183702216

Here, AMIS claim 3000+ (rolling sum) FPGA->ASIC conversions.

Atmel also have a ULC conversion program.

-jg


Article: 99387
Subject: Re: Lattice FPGA
From: "Tim" <tim@rockylogiccom.noooospam.com>
Date: Thu, 23 Mar 2006 21:29:21 -0000
Links: << >>  << T >>  << A >>

Austin Lesea wrote

> John, Antti,
>
> I will say that if you place an order now, you will get a real delivery 
> date, and the parts will be shipped (we are not supply constrained for the 
> part numbers).

Hmmm.  I think John and Antti should be careful here.

We were stuffed with XC3S200 parts because Xilinx' distribution gave us 
exactly the line Austin suggests. So we ordered a thousand or so thinking we 
would get a delivery date, and then go ahead or reschedule or cancel 
depending on the date. What happened was an immediate delivery, and they 
would not take the parts back. They will finally be used in RockyLogic's 
next product but one ;-)

So be very careful if Xilinx' outriders in distribution give you the story: 
"we cannot give a delivery date until you place an order". We have hard 
evidence that you could end up warehousing Xilinx parts until your project 
is ready for volume manufacturing. And woe betide you if your requirements 
change during development - not that ours ever do!

Not good. 



Article: 99388
Subject: Re: Going from CLK1X to CLK2X.. really safe?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 23 Mar 2006 16:38:44 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Bob,
> 
> We designed the PMCD so that the outputs all all matched within tens of 
> picoseconds across P-V-T.  From there, you get onto the BUFGs, and you 
> end up with the usual +/-100ps rule for match between BUFgs.
> 
>

Austin,  That is basically what I was told when Virtex I came out too, 
but it turned out that jitter on the DLL input could cause a spread 
between the 1x and 2x clocks (IIRC, I had specifically asked both here 
on the NG and through the hotline about the alignment of the 1x and 2x 
clocks and whether it was safe to cross clock bounds without extra logic 
and was told it was fine.  I don't think anyone realized then what 
effect jitter would have on the relative phases of the 1x and 2x outputs.

So my question is, I realize you've designed the PMCDs for tight 
tolerances, but how well does that stand up to jitter on the clock input?

Article: 99389
Subject: Re: Timing Diagram software recommendations?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 23 Mar 2006 13:50:55 -0800
Links: << >>  << T >>  << A >>
Hi - 

I'm pretty happy with Synapticad.  I can't comment on the latest
version, as I dropped maintenance a while back: the verion of the tool
I have (7.9-something) is plenty good enough.

Doing timing diagrams with Synapticad is *so* much better than with
conventional drawing tools.  I'm convinced that I wouldn't do nearly
as many timing diagrams if I didn't have Synapticad.

Bob Perlman
Cambrian Design Works

On Thu, 23 Mar 2006 21:00:04 -0000, "Nial Stewart"
<nial@nialstewartdevelopments.co.uk> wrote:

>When working on the low level design of FPGA modules I usually
>draw out a data path timing diagram showing what's happening
>on each sucessive clock cycle.
>
>I have a word 'template' I've been using to do this for years, but
>I often think it might be quicker/more permanent/better for
>documentation if I used a custom Timing Diagram drawing program.
>
>A very quick search shows these seem to be the options....
>
>1) Chronology's Timing Designer
>http://www.timingdesigner.com/
>
>2) Synapticad's Timing Diagrammer Pro
>http://www.syncad.com/ttd_main.htm
>
>Top of the range all singing all dancing design tools for complex
>board design/analysis. Quite complex to use (?) with a reasonable
>learning curve. Cost ~ $1500 for 1 node locked license.
>
>3) Timing Tool
>http://www.timingtool.com/
>
>This seems to be an interim solution, although it looks reasonably
>powerful. Probably not as difficult to pick up as 1) and 2).
>Cost - $795
>
>3a) Timing Tool Lite - a web based lower featured version of timing tool.
>
>I'd rather be working directly on my PC, although this is free.
>
>
>4) Timing Gen
>http://www.xfusionsoftware.com/
>
>Low end diagram drawing tool, this seems to be fairly new and doesn't
>include any analysis features. I'm not sure how flexible this is, they
>suggest importing things into Word to aid annotation etc.
>Cost - $129.95
>
>
>
>I think what I'm lookign for is something between 3) and 4). This isn't
>essential so I don't want to spend $800 on it, but I think I'd like
>something a bit more capable than Timing Gen although I haven't
>experimented with it much, and it would be hard to beat for the cost.
>
>
>Can anyone offer opinions on the packages above or and other suggestions?
>
>Thanks in advance for any feedback,
>
>
>Nial Stewart
>
>
>
>
>----------------------------------------------------------
>Nial Stewart Developments Ltd        Tel: +44 131 561 6291
>42/2 Hardengreen Business Park       Fax: +44 131 561 6327
>Dalkeith, Midlothian
>EH22 3NU
>www.nialstewartdevelopments.co.uk
>
>
>
>
>
>
>
>

Article: 99390
Subject: Re: FPGA : Spartan-3e configuration failure
From: "Gabor" <gabor@alacron.com>
Date: 23 Mar 2006 13:54:59 -0800
Links: << >>  << T >>  << A >>

bijoy wrote:
> Hi
>
> I have a board with Spartan-3e-100VQFP FPGA mounted on it.
>
> I am using SPI flash (M25p20 ) from ST, to store the configuration bit map.
>
> After power-on, the FPGA's starts configuring (INIT-B goes high), then it comes to low. and DONE pin does not go high.

Generally INIT going low means you have a bitstream error that is
caught by
the CRC detection logic.  I would check that the data in the SPI flash
is
correct for the part you're using and that the bit order within bytes
is correct
for the stored format.

How did you generate the data for the SPI?  Did you make a "serial
PROM"
image using promgen (or impact)?

>
> All power suplly is correct.
>
> CCLK is coming but about 1.3 MHz and other signals like CSO_B,DIN some data is coming.
>
> But i am not able to trace why the configuration fails.
>
> May I get any help from you guys..
> 
> Thanks in advance...
> 
> bijoy


Article: 99391
Subject: Re: Lattice FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 13:57:02 -0800
Links: << >>  << T >>  << A >>
Tim,

If you order them, they will arrive.  I think that is how it is supposed 
to work?

Sometimes sooner, sometimes on time (and the objective is to never be late).

So don't blame us that we delivered an order, please!

If you did not want early delivery, then you have to change the terms, 
and get the distributor to agree to that.

I didn't say (in my previous post) "place an order," I said to contact 
your FAE for exact details on the part you want.

Unless, of course, you do want a part, then please do place an order.

Austin

Tim wrote:

> Austin Lesea wrote
> 
> 
>>John, Antti,
>>
>>I will say that if you place an order now, you will get a real delivery 
>>date, and the parts will be shipped (we are not supply constrained for the 
>>part numbers).
> 
> 
> Hmmm.  I think John and Antti should be careful here.
> 
> We were stuffed with XC3S200 parts because Xilinx' distribution gave us 
> exactly the line Austin suggests. So we ordered a thousand or so thinking we 
> would get a delivery date, and then go ahead or reschedule or cancel 
> depending on the date. What happened was an immediate delivery, and they 
> would not take the parts back. They will finally be used in RockyLogic's 
> next product but one ;-)
> 
> So be very careful if Xilinx' outriders in distribution give you the story: 
> "we cannot give a delivery date until you place an order". We have hard 
> evidence that you could end up warehousing Xilinx parts until your project 
> is ready for volume manufacturing. And woe betide you if your requirements 
> change during development - not that ours ever do!
> 
> Not good. 
> 
> 

Article: 99392
Subject: Re: Number of taps for a FIR
From: Ray Andraka <ray@andraka.com>
Date: Thu, 23 Mar 2006 17:00:05 -0500
Links: << >>  << T >>  << A >>
As Symon indicated, you should look into multi-rate filtering. 
Basically, decimate by 2 in 3 stages.  Each subsequent stage works at 
half the data rate, and the length of the earlier filters needn't be as 
long as the later filters.

That said, 61 taps is not outrageously long, (although by using 
multi-rate, you'll be able to at least reduce the sample rate of your 
longest filter).  There is a paper by Goodman and Cary from the 70's 
that details a set of small half-band FIR filters (half the coefficients 
are zero) for decimating in multi-rate systems.  Also, the decimating 
filter sections can be reduced using polyphase decomposition so that the 
filter sections run at the output sample rate rather than at the higher 
input sample rate.  That sample rate reduction also allows you to make 
the filter physically smaller by using more than one clock per sample. 
The Goodman-Cary F8 filter is a 15 tap filter that has 5 unique non-zero 
coefficients.  Through symmetry folding and polyphase decomposition, and 
using distributed arithmetic, filter breaks down into a 4 tap filter and 
a constant multiply added together, and it provides about 65db stopband 
attenuation and a reasonably steep transition.  You'll have to work 
through the chart for you application, but you'll probably find you can 
use something like and F3, F5 and F8  filter in cascade to get 
attenuation in the aliased part of the stopband and a flat response in 
your final passband.

A CIC filter would probably not buy you much here, as it basically takes 
the place of the F3 filters in the early part of a decimation chain as 
far as response curve goes.  Where your total decimation is only by 8, 
the CIC is probably not going to buy you anything.  CIC comes in really 
handy is where you have either a high decimation ratio, or a decimation 
ratio that has to be programmable.

Your stated sample rates are actually quite low for an FPGA.  You can 
easily run the FPGA clock at around 80 MHz without any special design 
considerations and do the whole filter serial, sequential or 
serial-sequential at a considerable area savings. (serial would be using 
distributed arithmetic, in which case you need a 16x clock, sequential 
uses one multiplier to multiply and accumulate several taps: basically 
timesharing the hardware).  You may also find a FIR filter 
implementation for your final filter may be easier to deal with than an 
IIR implementation because you can generally getr by with far fewer data 
bits and the response is not subject to limit cycles and instabilities 
caused by finite precision of a fixed point implementation.

Article: 99393
Subject: Xilinx hi-speed interconnect/routing question
From: "johnp" <johnp3+nospam@probo.com>
Date: 23 Mar 2006 14:10:41 -0800
Links: << >>  << T >>  << A >>
I'm working on a V2Pro design that needs to have a small
portion operate at over 400 MHz.  As I've looked into the
timing, I've noticed that similar routing between slices
seems to have different timing delays.  For example:

   Location             Delay type         Delay(ns)

    -------------------------------------------------
    SLICE_X34Y1.YQ       Tcko                  0.374

    SLICE_X34Y3.BY       net (fanout=1)        0.614
    SLICE_X34Y3.CLK      Tdick                 0.202

    -------------------------------------------------
    Total                                      1.190ns

**************************************************

    Location             Delay type         Delay(ns)

    -------------------------------------------------
    SLICE_X66Y42.YQ      Tcko                  0.374

    SLICE_X66Y44.BY      net (fanout=1)        0.407
    SLICE_X66Y44.CLK     Tdick                 0.202

    -------------------------------------------------
    Total                                      0.983ns

Note that both circuites route from a YQ output, jump two slices,
then go to a BY input.  Yet, the net delays vary by 200 psec.

Ideally, I'd pack the 2 flip-flops in one slice, but in my design they
are clocked by opposite clock edges as I convert a DDR signal from
the negedge into the posedge domain.

Can anyone explain the difference in interconnect delay?  Does
Xilinx publish anything that really explains how to get the
shortest routing delay?

Thanks!

John Providenza


Article: 99394
Subject: Re: for all those who believe in (structured) ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 14:27:07 -0800
Links: << >>  << T >>  << A >>
All,

For "burger counts":

http://www.xilinx.com/prs_rls/silicon_vir/0397v10mil.htm
(July 7, 2003)
http://www.xilinx.com/prs_rls/silicon_spart/0471spartanleadership.htm
(June 17, 2004)
http://www.xilinx.com/prs_rls/silicon_spart/04105_1mil_s3.htm
(September 21, 2004)
http://www.xilinx.com/prs_rls/silicon_vir/0413790nmmilestone.htm
(December 27, 2004)
http://www.xilinx.com/prs_rls/silicon_spart/05118_90nm10mil.htm
(December 20, 2005)
http://www.xilinx.com/prs_rls/2006/xil_corp/0629_v4b.htm
(February 28, 2006)


And now, AMI...


AMIS:

FY 2001  2002  2003  2004  2005
$$ 326M  345M  454M  517M  504M
SA   0     0   96.7M 119M  110.4M

So, let me get this right, in 20 years, they have converted 3,000 FPGA 
designs to ASICs.

And, in the last three years they have redefined part of their business 
segment, and called it 'Structured ASICs', and revenues were down this 
year from last.

Anyway you cut it, it doesn't look pretty.

The gross margins also look rough (anyone out there ever worked for a 
company with ~ 40% GM? not fun at all...bring your own hand towels time).

That makes structures ASICs flat to down for 2004 to 2005 for AMI.

This is similar to MacDonalds giving the bizillionth customer who orders 
a prize -- it tells you nothing, other than someone got lucky.  Now a 
history of increasing 'burger counts', that at least tells you something.

In this case, the 3,000th conversion customer got lucky:  they got a 
working part!


In all fairness, more power to AMI:  they have been in this business for 
a very long time, and they obviously know how to make money in it.

The other link for the FPGA journal is much more interesting (Kevin is 
pretty sharp!): (from his article)

(when asked 'is structured dead...')

"Our answer to these questions is an emphatic "no." The reasons behind 
LSI's strategy shift are complex and somewhat company-specific. No 
company can do everything at once and do it well, and smart executives 
know how and when to focus their company's energies on the projects that 
will bring the most return and growth and that capitalize on the 
organization's unique strengths. LSI had good momentum and competence in 
the storage and consumer markets, and those made sense as a place to 
focus the company's remaining resources in a difficult business situation."

I call this the 'apologia' as it is the restatement of the company line 
why they left the business (even though they were #1).  LSI found the 
business did not fit.  It happens.

"The part of the situation that isn't company specific is the orthogonal 
trend toward domain-specific optimization of silicon platforms. This 
specialization can be seen across industries and across silicon 
technologies. With the exception of full-blown ASIC, every customizable 
silicon technology makes some serious technical compromises. For FPGAs, 
these compromises are obvious in the LUT fabric which gives away an 
order of magnitude or so in speed, density, and power consumption for 
the privilege of reprogrammability. In structured ASIC and in 
non-volatile FPGA technologies like antifuse, the configurable fabric 
penalty is smaller, but still significant. Every vendor's solution to 
this problem is the same Ė create ASIC-like hard IP blocks for critical 
functions."

Here Kevin answers the reasons why (that he artfully dodged earlier), 
without saying that LSI realized it was failing.  He basically says: 
this business is really tough!  You never have the right mix of IP, etc. 
  Back to Kevin:

"Hard IP can take large, performance-critical hardware, like 
multipliers, memory, and high-speed I/O standards, and implement them 
much more efficiently than a designer attempting to put that same 
capability in the programmable or customizable part. This gain comes at 
a cost, however. Every customer that doesn't use a particular function 
that is hard-wired on the chip is essentially paying for wasted silicon. 
The juggling act for semiconductor companies, therefore, is to decide 
which functions (and how many) should be hardened in order to give the 
best mix of performance and cost optimization. For example, if your 
customers are doing high-speed digital signal processing (DSP), it 
probably pays to put a number of hard-wired multipliers on your chip. 
Even then, however, the question of "how many" poses a challenge. Do you 
need ten? A hundred? A thousand? The particular application area 
determines the answer."

So, the 'trick' is to know the customer, and know what 'works'.  The way 
to tell if a company knows these things is to keep track of their 
financials.

Austin

Article: 99395
Subject: Re: this JTAG thing is a joke
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 10:36:55 +1200
Links: << >>  << T >>  << A >>
Falk Brunner wrote:

> Jim Granville schrieb:
> 
>>  The latest Serial memories from Winbond can stream at 150Mbd, from an
>> 8 pin package !
> 
> 
> Uuups!
> 
>>  That makes even 100MHz look sluggish.
>>
>>  There is talk of USB-JTAG, which is sensible, and that should be
>> high speed USB, in that case, FPGA suppliers SHOULD be working on
>> ~400MBd capable JTAG streaming.
> 
> 
> Really? But would this kick out the basic concept of JTAG being simple 
> and low efford? I mean a normal JTAG chain runs just TMS/TCK as a single 
> line from chip to chip and TDI/TDO in a daisy chain. Done. 400 Mbit/s 
> would require diffent I/Os than plain LVCMOS etc. Hmmm.
> Maybe for some memories, but for all other ICs??

  The other postings have shown that the long lengths of JTAG chains
still can cause problems, even at 5MHz.

  Maybe if it was called a 50MHz bus, more care would be taken :)

66-75MHz is now pretty standard for SPI devices, so it's about time the
JTAG caught up a little...

  I'd suggest a Std Schmitt on the TCK, and then use the FPGA IO features
for the rest - so it does not have any real additional cost.

  ie you go to whatever the FPGA and PCB allow, and do not limit to 5-10MHz.

  Clearly one would not chain at 400Mhz, but there is a case for fast 
loading to one device, or a star network, to load many, at very high
speeds.

  Anyone got numbers on how fast the JTAG can clock, on the new 65nm 
Xilinx FPGAs, curently in the Labs  ?

-jg


Article: 99396
Subject: Re: Xilinx hi-speed interconnect/routing question
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 14:45:12 -0800
Links: << >>  << T >>  << A >>
Johnp,

The simple answer is, no, we don't publish the information you are 
asking for, as we have practically no reason to support 'hand crafted' 
designs (results in too many unhappy people -- been there, done that).

Does the path in question span a BRAM column?  That would be one reason 
for the difference.

Generally, differences are real, and we know they are there, and they 
are ususally there for a very good reason (that is the way it was in 
layout).

The "accepted" way of doing this, is to create a macro or block with its 
own contstraints, hard fixed or relatively fixed, and let the tools 
place it properly...but I admit that doing that is tough to fight the 
tools to squeeze ps out of a design.  Resorting to FPGA_Editor, and just 
placing it exactly where it belongs and works is easier.  It is just 
hell to support, and maintain.

There are many on this forum who know how to squeeze and navigate, and 
do what you need done, but I suspect they get paid for that knowledge...

Austin

johnp wrote:

> I'm working on a V2Pro design that needs to have a small
> portion operate at over 400 MHz.  As I've looked into the
> timing, I've noticed that similar routing between slices
> seems to have different timing delays.  For example:
> 
>    Location             Delay type         Delay(ns)
> 
>     -------------------------------------------------
>     SLICE_X34Y1.YQ       Tcko                  0.374
> 
>     SLICE_X34Y3.BY       net (fanout=1)        0.614
>     SLICE_X34Y3.CLK      Tdick                 0.202
> 
>     -------------------------------------------------
>     Total                                      1.190ns
> 
> **************************************************
> 
>     Location             Delay type         Delay(ns)
> 
>     -------------------------------------------------
>     SLICE_X66Y42.YQ      Tcko                  0.374
> 
>     SLICE_X66Y44.BY      net (fanout=1)        0.407
>     SLICE_X66Y44.CLK     Tdick                 0.202
> 
>     -------------------------------------------------
>     Total                                      0.983ns
> 
> Note that both circuites route from a YQ output, jump two slices,
> then go to a BY input.  Yet, the net delays vary by 200 psec.
> 
> Ideally, I'd pack the 2 flip-flops in one slice, but in my design they
> are clocked by opposite clock edges as I convert a DDR signal from
> the negedge into the posedge domain.
> 
> Can anyone explain the difference in interconnect delay?  Does
> Xilinx publish anything that really explains how to get the
> shortest routing delay?
> 
> Thanks!
> 
> John Providenza
> 

Article: 99397
Subject: Re: Digital filter design software?
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 23 Mar 2006 18:04:33 -0500
Links: << >>  << T >>  << A >>
Try posting this question to comp.dsp...


"Bubb" <bubb@telia.se> wrote in message
news:44230509$0$15784$14726298@news.sunsite.dk...
> Hello
>
>
>
> Iím wondering if there is any filter design software that can handle all
> required calculations in designing decimating or interpolating filters or
> iir and fir filters?
>
> Thanks
>
>



Article: 99398
Subject: Re: ACE Formatter for Linux (was Re: Parallel Cable IV...)
From: Stephen Williams <spamtrap@icarus.com>
Date: Thu, 23 Mar 2006 15:09:24 -0800
Links: << >>  << T >>  << A >>
Duane Clark wrote:
> Stephen Williams wrote:

>> What I would really like something that can write Xilinx .ACE files.
>> The impact from Foundation 6.2 is terribly slow, and from Webpack8.1
>> is pretty flakey. (It wrote ace files everywhere but where I wanted
>> them.)
>>
> 
> I'll agree that the interface is not particularly intuitive, but the
> main limitation I see is that the ace files must always be placed two
> directories deep. I've used Impact from ISE7.1 on Linux regularly, and
> had no problems at all. I haven't used the 8.1 version much, but a quick
> test seems to indicate that it works the same.

When I wave my hands over it just right, it does. But for a few days
I found it writing jtr/jtr/jtr.ace files in the most surprising
places, including in jtr/jtr/jtr/jtr/jtr/jtr.ace, $HOME/jtr/jtr/jtr.ace,
$(CWD)/jtr/jtr/jtr.ace, and a few other places I haven't thought of.
I'm still occasionally finding jtr.ace files here and there.

> Arrgg... I just noticed that the ipf project files have switched from
> plain text in version 7.1 to binary in version 8.1.
> 
> Hey Xilinx, please take a poll of your paying customers. We don't want
> binary project files!

And then there's that.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Article: 99399
Subject: Re: Xilinx hi-speed interconnect/routing question
From: "johnp" <johnp3+nospam@probo.com>
Date: 23 Mar 2006 15:12:24 -0800
Links: << >>  << T >>  << A >>
Austin -

Thanks for the comments.  I'm just frustrated because if I run
multi-pass P&R, the tools can find a solution that meets timing,
but I don't see any hints as to how to use RLOCs to force the
critical cells into magical alignments that produce the smaller
interconnect delay.

John Providenza




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