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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 23825

Article: 23825
Subject: Re: MPEG audio questions...
From: "gary" <dont.spam@me.net>
Date: Tue, 11 Jul 2000 22:34:37 +0100
Links: << >>  << T >>  << A >>
Hi Bernhard,

thank you for your reply!

I shall have a good look.....

Gary.




Bernhard Josef Rieder <bernhard@ratte.tuwien.ac.at> wrote in message
news:8jufdf$38i$1@news.tuwien.ac.at...
> In article "gary" <dont.spam@me.net> wrote:
>
> > (1) How complex is the decoder, how much logic would I need?
>
> have a look at http://www.mpg123.de/ for the C source of a software
> decoder. It seems difficult ......
>
>
> > (2) Do you have to pay to use MPEG in your own codecs?
>
> I think you only have to pay if you use the algorithm published by
> frauenhofer institute*. If you are not living in the US or in Germany
> it is likely to be legally anyway :)
>
> * It seems to be almot impossible NOT to use it
>
>
> Bernhard


Article: 23826
Subject: Re: MPEG audio questions...
From: "gary" <dont.spam@me.net>
Date: Tue, 11 Jul 2000 22:36:24 +0100
Links: << >>  << T >>  << A >>
Savekar,

Thanks for replying!

I'll have a good look at tsec.com.

Gary.



Savekar Santosh <ssavekar@my-deja.com> wrote in message
news:8juuj3$sg2$1@nnrp1.deja.com...
> In article <M5P65.1136$HR.19533@news6-win.server.ntlworld.com>,
>   "gary" <dont.spam@me.net> wrote:
> > Dear all,
> >
> > I am considering implementing an MPEG layer 2 audio decoder in an
> fpga.
> > Around 128kbit/s.
> >
> > What I need to know is....
> >
> > (1) How complex is the decoder, how much logic would I need?
>
> I think with highly optimized design you should be able to do the audio
> decoder layer-I, not sure about layer-II, in around 8K gates or so. I am
> not thinking about the space to store constants here. See:
>
> http://www.tsec.com/p_audio.htm
>
> >
> > (2) Do you have to pay to use MPEG in your own codecs?
>
> You have to pay only if you buy the standards from ITU.
> which are priced at around $125. But you can get the know-how by some
> other means such as free sources on web.
>
> >
> > All help much appreciated.
> >
> > Gary.
> >
> >
>
> Good luck,
> Santosh
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 23827
Subject: Re: Xilinx Logic Cell counts and carry chains
From: "Steve Casselman" <sc@vcc.com>
Date: Tue, 11 Jul 2000 16:59:43 -0700
Links: << >>  << T >>  << A >>
There are four 4 LUTs and some other stuff per CLB.
Really though you can do any function of 6 inputs and it is really a 6 LUT.
If you just used 4 LUTs to do any function of 6 inputs you would need more
than four 4 LUTs. So 4.5 4 LUTs per CLB is a conservative  in my opinion.

Steve Casselman


"Rickman" <spamgoeshere4@yahoo.com> wrote in message
news:392AB1C4.556B80FC@yahoo.com...
> First let me say that I am not trying to pick on Xilinx by asking so
> many questions about their devices and practices. But I am looking at
> switching to their parts for my next design and want to discuss some of
> the things I don't understand.
>
> With that said, can anyone tell me how Xilinx comes up with their "Logic
> Cell" counts? In the XC4000 line of parts, they seem to have 2.375 Logic
> Cells per CLB. I can understand this since they have the two 4 input
> LUTs and a 3 input LUT which they must be counting as .375 Logic Cells.
>
> But in the Spartan II line they get 4.5 Logic Cells per CLB. But if I
> understand the architechture correctly, there is no extra 3 input LUT in
> these devices. Although they have extra logic to combine the outputs of
> the four LUTs in a CLB, this logic can not be used independantly as can
> the 3 input LUT in the XC4000 series. So the maximum number of logic
> outputs you can have is determined by the number of LUTs you have, not
> the number of "Logic Cells".
>
> So how can they count this as .5 Logic Cells per CLB? Is Logic Cell
> count the same as gate count and should be ignored?
>
> I guess this is not really a significant issue, but it does make their
> documentation a bit harder to interpret since I have to calculate the
> LUT count myself for every device I want to consider.
>
> On a more significant note, I can't say that I understand the carry
> chain description in the Spartan II datasheet. I can't seem to cut and
> paste from the document (odd, I can do that with most other PDF
> files...) but the text says, "The Spartan-II CLB supports two separate
> carry chains, one per Slice. The height of the carry chains is two bits
> per CLB." The Virtex carry chain is described the same way so that sheds
> no additional light on the matter.
>
> Is this saying that the two slices are separate and only one carry chain
> can be used at a time? Or are the two cascadable to produce a four bit
> slice of a counter/adder? I checked the timing data and there is no
> indication of a fast connect from Cout to Cin on the same CLB or to
> adjacent CLBs. Has this gone away with the Virtex/Spartan II parts?
>
>
> --
>
> Rick 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
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 23828
Subject: Re: Xilinx buys LavaLogic
From: Ray Andraka <ray@andraka.com>
Date: Wed, 12 Jul 2000 01:35:13 GMT
Links: << >>  << T >>  << A >>


Joel Kolstad wrote:

> ed, synthesizing hardware is a rather complex
> task, but so is building a C++ compiler, and the guys at Microsquish sure
> seem to end up with better quality programmers than Synopsys did.  (Or maybe
> they just have so many more...?)

Nah, just a lot more beta testers.. Oops I mean users :-)

>
>
>
> ---Joel Kolstad

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


Article: 23829
Subject: Re: FFT/IFFT for FPGA
From: jadey@my-deja.com
Date: Wed, 12 Jul 2000 02:10:20 GMT
Links: << >>  << T >>  << A >>
Thanks for your reply.
64 Point or 512 Point FFT/IFFT


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 23830
Subject: C++/Java generators vs. synthesizers
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 12 Jul 2000 04:12:14 GMT
Links: << >>  << T >>  << A >>
Whenever we have this discussion, which does recur, there is one important
distinction that needs to be made: in both C++ and Java, it is possible to
write both *generators* as well as *synthesis* systems. They are quite
different beasts.  Some examples:

1. Netlist generators (explicit hardware specification systems), such as
* C++: PamDC [1], PAM-Blox [2], CNets [3],
* Java: Chu et al (Berkeley) 'OO Circuit Generator in Java' [4], JHDL [5]
* Others: Lola/Trianus/Hades [6]

2. HLL synthesis (behavioral compilers / hardware inference systems), such
as
* C/C-like: Napa-C [7], Streams-C [8], Handel-C [9], Leong's lcc-VHDL system
[10], 'Tsukuba' C-HDL compiler [11]
* Java: Galadriel/Nenya [12], LavaLogic Forge [13]

(Apologies if I have miscategorized or overlooked your favorite.) And then
there's SystemC [14] and others, which I think support both paradigms.

Comparing generators to synthesizers is just like comparing schematics to
HDL synthesis. In the former, you have explicit control over what you get,
and in some cases, how it is technology mapped and placed.  But then you
*do* have to explicitly instantiate everything. In a synthesis system, you
have tools that do that for you, but tend to achieve inefficient results
quickly.

In my opinion, generators can have all the 'explicitness' advantages of
schematics, plus text representation, HLL integration and programmability,
with none of the disadvantages. There is just a critical mass adoption
issue -- in lieu of one dominant approach, there is no opportunity for reuse
across existing experimental systems and none have seemed to gain traction.

HLL synthesis, I'm ambivalent about. I hate wasting hardware, but I
understand others are more sanguine about that. I wonder just how much of an
improvement over HDLs they are, given you often don't get the full HLL
semantics, and apparently you often need to add pragmas and directives to
help synthesis make the right things parallel and/or sequential, put the
right data in registers or internal RAM or external RAM, etc.

Just as C compilers sometimes outperform assembly hackers, it is (remotely)
possible that someday these can generate designs that approach a careful
schematic design? Are they a revolutionary development that will make it
easy for your average C/Java programmer to design hardware? Will they let
you push a button and get hardware from a dusty deck C or Java library?  I
doubt it. Software design concerns are quite different from hardware design
concerns. Also, I believe that a good C programmer can pick up Verilog and
Verilog concepts about as easily as they can learn the additional keywords
and directives and restrictions necessary to infer comparable hardware with
an HLL synthesis system.

Perhaps someone who uses and prefers HLL synthesis can share their
experiences.

Jan Gray
Gray Research LLC

References

[1] http://www.research.digital.com/SRC/pamette/Software.html)
[2] http://umunhum.stanford.edu/PAM-Blox/
[3] http://www.fpgacpu.org/usenet/cnets_datapath.html
[4] http://brass.cs.berkeley.edu/documents/Generators_FCCM98.html
[5] http://www.jhdl.org/
[6] http://www.cs.inf.ethz.ch/projects/lola/trianus/
[7] FCCM98
[8] Gokhale et all, FCCM00, also e.g.
http://www.arpa.gov/ito/psum1998/F282-0.html
[9] http://www.embeddedsol.com/technology/info_sheets/info_sheet_01.htm
[10] "Automatic Floating to Fixed Point Translation and its Application to
Post-Rendering 3D Warping", FCCM99,
http://www.cse.cuhk.edu.hk/~phwl/papers/fccm99_fixed.ps.gz
[11] Maruyama, FCCM00
[12] http://www.acm.org/crossroads/xrds5-3/rcconcept.html
[13] http://www.lavalogic.com/product/wp_forge.html



Article: 23831
Subject: Re: C++/Java generators vs. synthesizers
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 12 Jul 2000 01:18:59 -0400
Links: << >>  << T >>  << A >>
Jan Gray wrote:
> 
> Whenever we have this discussion, which does recur, there is one important
> distinction that needs to be made: in both C++ and Java, it is possible to
> write both *generators* as well as *synthesis* systems. They are quite
> different beasts.  Some examples:
> 
> 1. Netlist generators (explicit hardware specification systems), such as
> * C++: PamDC [1], PAM-Blox [2], CNets [3],
> * Java: Chu et al (Berkeley) 'OO Circuit Generator in Java' [4], JHDL [5]
> * Others: Lola/Trianus/Hades [6]
> 
> 2. HLL synthesis (behavioral compilers / hardware inference systems), such
> as
> * C/C-like: Napa-C [7], Streams-C [8], Handel-C [9], Leong's lcc-VHDL system
> [10], 'Tsukuba' C-HDL compiler [11]
> * Java: Galadriel/Nenya [12], LavaLogic Forge [13]
...snip... 
> In my opinion, generators can have all the 'explicitness' advantages of
> schematics, plus text representation, HLL integration and programmability,
> with none of the disadvantages. There is just a critical mass adoption
> issue -- in lieu of one dominant approach, there is no opportunity for reuse
> across existing experimental systems and none have seemed to gain traction.

Can you be a little more specific about the advantages and
disadvantages? I think I understand the advantages of schematics, text
representation..., but what would the disadvantages of using an HLL be
for "generation"? Are you talking about the verboseness? 

In summary, you feel that using a HLL such as C or Java for synthesis is
not a good idea for now, but using them as a generator may work well?

 
> References
> 
> [1] http://www.research.digital.com/SRC/pamette/Software.html)
> [2] http://umunhum.stanford.edu/PAM-Blox/
> [3] http://www.fpgacpu.org/usenet/cnets_datapath.html
> [4] http://brass.cs.berkeley.edu/documents/Generators_FCCM98.html
> [5] http://www.jhdl.org/
> [6] http://www.cs.inf.ethz.ch/projects/lola/trianus/
> [7] FCCM98
> [8] Gokhale et all, FCCM00, also e.g.
> http://www.arpa.gov/ito/psum1998/F282-0.html
> [9] http://www.embeddedsol.com/technology/info_sheets/info_sheet_01.htm
> [10] "Automatic Floating to Fixed Point Translation and its Application to
> Post-Rendering 3D Warping", FCCM99,
> http://www.cse.cuhk.edu.hk/~phwl/papers/fccm99_fixed.ps.gz
> [11] Maruyama, FCCM00
> [12] http://www.acm.org/crossroads/xrds5-3/rcconcept.html
> [13] http://www.lavalogic.com/product/wp_forge.html

I will keep this list for use later. 


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23832
Subject: Re: Xilinx Logic Cell counts and carry chains
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 12 Jul 2000 01:28:30 -0400
Links: << >>  << T >>  << A >>
And what company's marketing department do you work for?  ;)


Steve Casselman wrote:
> 
> There are four 4 LUTs and some other stuff per CLB.
> Really though you can do any function of 6 inputs and it is really a 6 LUT.
> If you just used 4 LUTs to do any function of 6 inputs you would need more
> than four 4 LUTs. So 4.5 4 LUTs per CLB is a conservative  in my opinion.
> 
> Steve Casselman

-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23833
Subject: Re: Remedies after the Fathers' Day Massacre
From: murray@pa.dec.com (Hal Murray)
Date: 12 Jul 2000 06:59:51 GMT
Links: << >>  << T >>  << A >>

[context is my gripes about blinking/bouncing stuff.]

> I don't remember Xilinx having much of this on their web site, but it
> doesn't hurt to mention it. 

I use a hack to supress flashing junk, mostly from banner ads.
I was annoyed enough at two of the gifs on the Xilinx site that
I added them to my reject list.

Xilinx isn't bad when compared to many sites.  But check out their
main page.  The "ASIC Cost Estimator" blinks out and then fades back
in.  (Rats, now I have to go update my list.)

Note that the link behind that is javascript (jumpBillboard()) so
even if I click on it it nothing happens.


> >   And self decompressing exe files are out.  Please just give me the
> >   raw file set.  I'll take the space/time/bandwidth penalty.

> But in any case, please don't stop zipping these files. 

I'm happy with compressed files - it's the exe part that I don't like.
First, it won't run on my machine.  Second, even if it did, I would
have to trust it.  Why should I make that leap?  It might contain a virus
or trojan.  Or it might just install some junk that I don't want on
my machine.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 23834
Subject: Re: XC2018 development system xact5 or xact6 sale?
From: "Tony Burch" <tony@BurchED.com.au>
Date: Wed, 12 Jul 2000 17:27:55 +1000
Links: << >>  << T >>  << A >>
Rick, thanks reposting my announcement / ad.

Let me say that I am biassed, because my company
sells the mentioned FPGA kits, but I have to second
Rick's suggestion.   The kits are designed to
be a fast and easy way to try out circuits in the lab.
And low cost.
Check them out at www.BurchED.com.au

If you don't own any design tools, the Altera kit plus the free
Max+PlusII Baseline software downloadable from
www.altera.com are a low cost way to start.
Or if you prefer Xilinx, Actel, Atmel or Lucent, their "Base"
design tools can be had at low cost (ie. about US$99 for
the Xilinx tools, and similar costs for the other vendors).

rickman wrote in message <396A327C.6F6D7D2A@yahoo.com>...
>I saw this ad in comp.arch.embedded awhile back. I have no idea how good
>or bad the product is.

They are very good :)
BED-LUCENT-BASE+ are great for Lucent users :) :)

As I said, I am biassed.

Cheers
Tony Burch
www.BurchED.com.au

rickman wrote in message <396A327C.6F6D7D2A@yahoo.com>...
>I would make two recommendations to you. The first is to forget about
>using the XC2018 chip. This is not only no longer made, it has very
>little capability compared to the chips available today.
>
>Secondly, I would recommend that you not try to use a chip. Most of the
>FPGAs from Xilinx are only available in surface mount packages that are
>hard to work with compared to the other options available to a hobbiest.
>Instead, use a demo board available from many sources. There is a list
>available at http://www.optimagic.com/. See what you can find there.
>
>I saw this ad in comp.arch.embedded awhile back. I have no idea how good
>or bad the product is. Just make sure the chip on any board you buy is a
>recent one (Spartan, XC4000, Virtex, Spartan II). I recommend that you
>hold out for the new Spartan II which should be shipping in a month or
>two.
>
>******************************************
>Burch Electronic Designs FPGA Prototyping
>kits are now 25% cheaper.
>Xilinx kits are now US$66 !
>
>The price rollback is due to the abolition
>of the crippling "Wholesale Sales Tax"
>in Australia, plus the recent streamlining
>of our production process.
>
>Xilinx, Altera, Atmel, Lucent and Actel kits
>are available.
>
>For product details, secure online shop and
>subscription to our free online newsletter
>please go to
>www.BurchED.com.au
>
>International orders are very welcome.
>
>Best regards
>Tony Burch
>www.BurchED.com.au
>******************************************
>
>
>
>Ottwald Holler wrote:
>>
>> I got some pcs of XC2018-fpga's. I'm hamradio operator and would like to
>> realize some ideas with this fpgas. The only one problem is that the
>> current versions of xilinx software doesnt support the xc2018.
>> I'm therefore hardly looking for a working version of XACT5 (DOS&UNIX)
>> or XACT6 (Windows) to buy!
>> Anybody on the forum who could help me?
>> Thanks a lot for thinkig about!
>>
>> Ottwald J.Holler
>> Callsign OE2OHA, ex.5B4EC, ex VK4ZOH
>> Liechtensteinklammstrasse 78
>> A-5600 ST.JOHANN/PG
>> AUSTRIA - EUROPE
>>
>> oe20ha@eunet.at
>>
>> www.members.eunet.at/oe20ha/index.html
>
>--
>
>Rick 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
>
>Arius
>4 King Ave
>Frederick, MD 21701-3110
>301-682-7772 Voice
>301-682-7666 FAX
>
>Internet URL http://www.arius.com


Article: 23835
Subject: Re: C++/Java generators vs. synthesizers
From: murray@pa.dec.com (Hal Murray)
Date: 12 Jul 2000 07:31:14 GMT
Links: << >>  << T >>  << A >>

> Can you be a little more specific about the advantages and
> disadvantages? I think I understand the advantages of schematics, text
> representation..., but what would the disadvantages of using an HLL be
> for "generation"? Are you talking about the verboseness? 
> 
> In summary, you feel that using a HLL such as C or Java for synthesis is
> not a good idea for now, but using them as a generator may work well?

If you are a programmer, then using a library package from c or Java
as a generator feels just like schematics - each box on a schematic
turns into a subroutine call.  You call a subroutine to make a gate
or flip-flop.  The library provides a collection of primitives - just
like the schematic package does.  You can easily extend what the system
provides by writing your own code.  The library remembers each call
in an internal data structure.  At the end, you call a cleanup routine
which writes out the net list.

If you have that internal data structure, it's pretty easy to
add a simulator to the package.

The advantages and disadvantages are just like schematics.  You can
do whatever you want.  You have to do everything, or at least everything
you want to end up in the wire list.

If you are a programmer, writing code in a familiar language may be
easier than using schematics.  You can use grep and friends on your
source text.

One potential disadvantage with text systems is that some technicians
don't like them.

I've never worked with a commercial schematic package.  I have looked
at a lot of drawings that I consider pretty ugly.  Why should I use
a schematic to describe the mapping from signal name to pin number?
Especially when the box is so tall that it wraps over several sheets.
It's just a pile of text.  I'd rather use my choice of text editor.


I don't understand the synthesis path yet.
-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 23836
Subject: Re: Xilinx XC4000E / Renoir
From: Chris Shenton <chriss@px.uk.com>
Date: Wed, 12 Jul 2000 09:54:28 +0100
Links: << >>  << T >>  << A >>
Jens,

It's easy just to instantiate the primitives in your code.

To keep it modular just make a wrapper architecture and instantiate into
that.

Cheers

Chris

Jens Popp wrote:

> Hi,
>
> is it possible to import the Xilinx Libraries for FPGA XC 4000E Series
> in Renoir as Blocks for the Block Diagrams?
>
> Regards
> --
>
> Jens Popp
> Institut fuer Rechnerstrukturen
> Universitaet Siegen
> Hoelderlinstr.3
> D-57068 Siegen
> Germany
>
> TEL  +49 271 740 2376
> FAX  +49 271 740 2473
> mailto:popp@rs.uni-siegen.de

Article: 23837
Subject: Boundary-Scan Tests with JTAG Technologies Tools
From: Franz Hollerer <hollerer@hephy.oeaw.ac.at>
Date: Wed, 12 Jul 2000 11:38:37 +0200
Links: << >>  << T >>  << A >>
Hi,

I have to automate board level tests with tools from JTAG technologies.
The documentation gives an overview. But I don't exactly know how to
start. I miss the "big idea".

Questions:
1) How can I test the test vectors. Is it possible to simulate the test
and
different failures?

2) JTAG Technologies uses a Boundary-scan Test Specification Language
(BTSL).
I believe that this is a proprietary solution, isn't it?

3) I would like to write the tests in VHDL and simulate them. Would it
be possible
to create BTSL files (application data file .apl, general data file
.gen, ...) for the
JTAG tools from this VHDL source?

Thx
Franz Hollerer

--
Institut fuer Hochenegiephysik
Nikolsdorfer Gasse 18
1050  Wien
Austria

Tel: (+43-1)5447328/50


Article: 23838
Subject: newbi question
From: Renzo Marcanzin <support@nospam.level-laser.it>
Date: Wed, 12 Jul 2000 12:45:01 +0200
Links: << >>  << T >>  << A >>
Hi all,

  I would like to learn something more about fpgas, from the hw and sw
poit of view. Can anyone suggest me a good book to study?

TIA

Renzo
Article: 23839
Subject: tutorial on configurable system-on-chip design is available
From: Dave Vanden Bout <devb@xess.com>
Date: Wed, 12 Jul 2000 08:05:42 -0400
Links: << >>  << T >>  << A >>
XESS Corp. is releasing the third section of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will release a new section each week.

Each section describes a design example for the Triscend configurable system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both reprogrammable.  The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
Article: 23840
Subject: FS: domain name: AsicGuru.com
From: rlm@kauai.mv.com
Date: Wed, 12 Jul 2000 08:11:26 -0400
Links: << >>  << T >>  << A >>
Are you an ASIC Guru?  Here is the domain for you:  AsicGuru.com..

http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=377615972

Article: 23841
Subject: hold time errors in FPGA's ?
From: Matt Gavin <mtgavin@collins.rockwell.com>
Date: Wed, 12 Jul 2000 07:13:10 -0500
Links: << >>  << T >>  << A >>
FPGA designers,

I was wondering if any of you have seen hold-time violations in your
FPGA's
(for paths between internal flops).

I had thought that hold times were "taken care of", i.e. the designer
doesn't
need to worry about them.  For instance, the Xilinx data book
quotes a 0ns hold time requirement. However, I believe I have seen
hold time violations in my design, which was first in an Altera Flex10K,

and is now in a Xilinx Virtex 400. The problem has occurred in both
FPGA's.

The specific logic involves a flop that is clocked by an externally
generated (off-chip) clock.  This flop is supposed to "toggle" (i.e go
from
x to x_bar) when this external clock rises, and another internal
condition
is detected.  Thus the output of this flop wraps back to the input
quite quickly (although it does go through some logic.)  Still, I would
not
expect this to fail hold unless the clock was poor (it seems to be quite
clean).
However, this toggle flop (as described above) fails in the FPGA in lab,

from 1 to 10% of the time.

It is definitely not a setup timing issue, since all flop inputs arrive
well before the clock.
It sure look like a hold time problem, since I see the input and the
output of the flop
glitch, then return to their original state, when the clock rises.

I added some extra delay to the feedback path yesterday,
and now it works great.

Anyone have any comments? I would be interested in
hearing similar experiences.

Matt Gavin
Rockwell Collins

Article: 23842
Subject: DESIGNERS WANTED
From: md <margaretatwork@my-deja.com>
Date: Wed, 12 Jul 2000 13:19:25 GMT
Links: << >>  << T >>  << A >>
Work on the cutting edge of wireless technology!  A firm in Portland,
Oregon, specializing in the design of wireless products for consumers,
is looking for RF and baseband designers.  You must have a minimum of 3
years of professional experience designing electronic devices.  Visa
sponsorship will be considered for the right candidates.  Please send
your resume and contact information to margaret_dailey@oxfordcorp.com,
or call Margaret at 503-291-5250.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23843
Subject: Re: hold time errors in FPGA's ?
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Wed, 12 Jul 2000 14:37:16 GMT
Links: << >>  << T >>  << A >>
Hi - 

The thing that makes me think that this is not a device-related hold
time problem is the fact that you have seen malfunctions in both your
Altera and Xilinx implementations.

You commented that the clock seems to be fine.  What kind of 'scope
and probe did you use to look at the signal?  For modern logic, you'd
want a scope/probe combination with a bandwidth of around ~1GHz
minimum (I'm referring to analog bandwidth here, not sampling rate).
And even 1GHz bandwidth might obscure a glitch that's less than ~0.5ns
wide.  Be sure to look at both rising and falling edges of the clock,
as a glitch on either may be misread by the FPGA.

Your observation that adding delay in the flip-flop's output-to-input
path seems to fix the problem is consistent with clock glitching.  If
the flip-flop is seeing two closely-spaced rising edges instead of
one, delaying the feedback might keep the flip-flop from seeing its
output change until after the second clock.  This may be why, when you
don't add delay, you see the flip-flop change state very briefly
(after the first clock event) and then change back (after the second
clock event caused by the glitch).

Another possibility is that the other signals that condition the
toggle are not synchronous to the target flip-flop.  Are they clocked
out of flip-flops that are clocked by the same clock as the target
flip-flop, and are you using a global buffer to distribute that clock?

Bob Perlman

On Wed, 12 Jul 2000 07:13:10 -0500, Matt Gavin
<mtgavin@collins.rockwell.com> wrote:

>FPGA designers,
>
>I was wondering if any of you have seen hold-time violations in your
>FPGA's
>(for paths between internal flops).
>
>I had thought that hold times were "taken care of", i.e. the designer
>doesn't
>need to worry about them.  For instance, the Xilinx data book
>quotes a 0ns hold time requirement. However, I believe I have seen
>hold time violations in my design, which was first in an Altera Flex10K,
>
>and is now in a Xilinx Virtex 400. The problem has occurred in both
>FPGA's.
>
>The specific logic involves a flop that is clocked by an externally
>generated (off-chip) clock.  This flop is supposed to "toggle" (i.e go
>from
>x to x_bar) when this external clock rises, and another internal
>condition
>is detected.  Thus the output of this flop wraps back to the input
>quite quickly (although it does go through some logic.)  Still, I would
>not
>expect this to fail hold unless the clock was poor (it seems to be quite
>clean).
>However, this toggle flop (as described above) fails in the FPGA in lab,
>
>from 1 to 10% of the time.
>
>It is definitely not a setup timing issue, since all flop inputs arrive
>well before the clock.
>It sure look like a hold time problem, since I see the input and the
>output of the flop
>glitch, then return to their original state, when the clock rises.
>
>I added some extra delay to the feedback path yesterday,
>and now it works great.
>
>Anyone have any comments? I would be interested in
>hearing similar experiences.
>
>Matt Gavin
>Rockwell Collins

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 23844
Subject: Re: hold time errors in FPGA's ?
From: Matt Gavin <mtgavin@collins.rockwell.com>
Date: Wed, 12 Jul 2000 10:31:26 -0500
Links: << >>  << T >>  << A >>
Bob,

thanks much for your comments. I will check the scope/probe I am using,
but I suspect it isn't close to 1GHz.

In reference to your question about signals that condition the
toggle flop: The only inputs to the flop are its own output, and signals
which are synchronous to the clock (which I do have on a global buffer).
These signals all are setup early since I am using numerous wait states.
So there should be no metastability issues due to asynchronous inputs
toggling just when the clock rises.

Actually, the clock is a "strobe" which asserts for a bus cycle to my FPGA
(IOSTRBF from the TI C54 DSP).
Its rising edge clocks in data, address and control signals which stay
asserted
for a clock cycle after the strobe rises.
These (address and control) are decoded to toggle the flop input
when a read is done to a specific address.

FYI, I looked at the original gates in the Xilinx FPGA Editor (nice tool,
BTW)
and there are two muxes and a LUT in the feedback path that
seems to be failing.  (so there is at least SOME delay there.)

Thanks,

  Matt


Article: 23845
Subject: Re: Timing Simulation for Alter FPGAs
From: " S.K. Sharma" <sanjay.kumar.sharma@philips.com>
Date: Wed, 12 Jul 2000 15:35:15 GMT
Links: << >>  << T >>  << A >>
Hi Vivek,
Insteadof Max+2,  you can try Quartus from Altera, which also keep the link
between netlist from Certify/Synplify(may be) through the Native link
advanced feature in the tool. You can trace back the signal in your RTL.
for more detailed information abt Quartus go to www.altera.com.
For my design I am using Certify and Quartus flow and it seems to be
fine....
Sanjay

<khanzode@yahoo.com> wrote in message news:8kfs1h$2e6$1@nnrp1.deja.com...
> Hi,
>
> We have recently started desinging using Verilog and I have a question
> regarding the timing simulation. Altera FPGAs (10KE series) is used for
> the most part.
>
> The design flow is as follows:
>
> 1. Write code in Verilog
>
> 2. Functional simulation using VCS
>    (Synopsys Verion 5.1NT running on an NT workstation)
>
> 3. Synthesis using Synplify.
>
> 5. Place and route using Max+PlusII 9.6
>
> I have not been able to perform the full chip timing simulations very
> effectively.
>
> After synthesis, Synplify changes a _lot_ of internal nodenames and I
> have not found a way to observe the timing between some of these
> signals. Is there a way this can be performed with the above set of
> tools? I would appreciate any help from someone who has used the .vo
> file generated by Max+Plus II for timing simulation of the whole design.
>
> I am running into situations where the functional simulations (with
> phantom delays in combinational statements) are fine, but the
> synthesized design doesnot work on the bench. I also need the timing
> simulation to accurately estimate the top speed of the design.
>
> Thanks,
>
> -- Vivek
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 23846
Subject: Re: C++/Java generators vs. synthesizers
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 12 Jul 2000 09:24:02 -0700
Links: << >>  << T >>  << A >>
Jan Gray wrote:
> . . .
> HLL synthesis, I'm ambivalent about. I hate wasting hardware, but I
> understand others are more sanguine about that. 

I don't like wasting gates and flops either,
even though they aren't very expensive anymore. 
What I do like is finishing on time and 
knowing the thing is going to work as well as 
the simulation.

> I wonder just how much of an
> improvement over HDLs they are, given you often don't get the full HLL
> semantics, 

If you are into data structures and 
algorithmic processes, the improvement 
is significant. The best tools can infer
counters and memory. The only significant 
semantic restriction is WAIT delays.

> and apparently you often need to add pragmas and directives to
> help synthesis make the right things parallel and/or sequential, 
> put the right data in registers or internal RAM or external RAM, etc.

Apparently you haven't tried Exemplar.
No pragmas. Just code.

> Are they a revolutionary development that will make it
> easy for your average C/Java programmer to design hardware? Will they let
> you push a button and get hardware from a dusty deck C or Java library?  I
> doubt it. 

I agree. You might recover a function or single process.
Real hardware involves multiple concurrent processes.

> Software design concerns are quite different from hardware design
> concerns. Also, I believe that a good C programmer can pick up Verilog and
> Verilog concepts about as easily as they can learn the additional keywords
> and directives and restrictions necessary to infer comparable hardware with
> an HLL synthesis system.

It can be done, but not without lots of learning time.
Knowing C helped me a little with VHDL. My main
problem was learning from examples left over from
first-generation synthesis and simulation tools.

> Perhaps someone who uses and prefers HLL synthesis can share their
> experiences.

I am a logic designer who started with schematics 
and a logic analyzer with lots of little clip-probes.
I now do HLL design, sim and synthesis.
I don't need the logic analyzer any more --
just a single logic probe.
If it wiggles, it's working.


--    mike.treseler@flukenetworks.com or
--             tres@tc.fluke.com
Article: 23847
Subject: Re: C++/Java generators vs. synthesizers
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 12 Jul 2000 16:45:05 GMT
Links: << >>  << T >>  << A >>
In article <yeSa5.1842$4U4.326883@paloalto-snr1.gtei.net>,
Jan Gray <jsgray@acm.org> wrote:
>In my opinion, generators can have all the 'explicitness' advantages of
>schematics, plus text representation, HLL integration and programmability,
>with none of the disadvantages. There is just a critical mass adoption
>issue -- in lieu of one dominant approach, there is no opportunity for reuse
>across existing experimental systems and none have seemed to gain traction.

	As one of the primary developers of one of the generator
systems [Chu, Weaver, et al], I have to disagree somewhat.  The
explicitness of generators is VERY good for certain aspects of a
design, namely datapath and datapath macros, especially parameterized
macros, but it ends up suffering severly when trying to do a complete
design.

	What I believe would be effective would be a generation system
integrated into a conventional cad tool flow.  The current CoreGen
system from Xilinx would offer this potential, but they haven't
released their API so that joe-ranodm-user can use the system to
create new cores, only instantiate Xilinx designed ones.

	Probably because creating a good API for module generation is
not easy, and the languages don't help things.  You want to do a great
deal of introspection, deducing structure from what the programmer
specified and created, yet both C++ and Java fail miserably at it.

	C++ doesn't even attempt metalinguistic abstractions, and
Java's (the Reflection interface) is almost hopelessly crippled by
security restrictions.  And Java doesn't have good overloading
mechanisms of operators, which would make the syntax much cleaner for
many operations.

	A language like CLOS might be better suited, but then you have
an even harder task of adoption, at least with C++ or Java.

	Unfortunatly, I have got to take off now, so I can't add more
thoughts at this time.  But I will try to post a good discussion when
I get back (fri/sat), explaining my thoughts in more detail.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 23848
Subject: Re: hold time errors in FPGA's ?
From: Greg Neff <gregneff@my-deja.com>
Date: Wed, 12 Jul 2000 17:11:50 GMT
Links: << >>  << T >>  << A >>
In article <396C60D5.4DFFE2F6@collins.rockwell.com>,
  Matt Gavin <mtgavin@collins.rockwell.com> wrote:
(snip)
>
> It is definitely not a setup timing issue, since all flop inputs
arrive
> well before the clock.
> It sure look like a hold time problem, since I see the input and the
> output of the flop
> glitch, then return to their original state, when the clock rises.
>
> I added some extra delay to the feedback path yesterday,
> and now it works great.
>
> Anyone have any comments? I would be interested in
> hearing similar experiences.
>
> Matt Gavin
> Rockwell Collins
>
>

Did you use a global glock input and net? The 0ns hold time spec is
only valid if you do this.  If you use normal inputs and routing
resources for clocks, then you can have hold time violation problems.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23849
Subject: Re: hold time errors in FPGA's ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 12 Jul 2000 20:02:37 +0100
Links: << >>  << T >>  << A >>


Matt Gavin wrote:

> FPGA designers,
>
> I was wondering if any of you have seen hold-time violations in your
> FPGA's
> (for paths between internal flops).
>
> I had thought that hold times were "taken care of", i.e. the designer
> doesn't
> need to worry about them.  For instance, the Xilinx data book
> quotes a 0ns hold time requirement. However, I believe I have seen
> hold time violations in my design, which was first in an Altera Flex10K,
>
> and is now in a Xilinx Virtex 400. The problem has occurred in both
> FPGA's.
>
> The specific logic involves a flop that is clocked by an externally
> generated (off-chip) clock.  This flop is supposed to "toggle" (i.e go
> from
> x to x_bar) when this external clock rises, and another internal
> condition
> is detected.  Thus the output of this flop wraps back to the input
> quite quickly (although it does go through some logic.)  Still, I would
> not
> expect this to fail hold unless the clock was poor (it seems to be quite
> clean).
> However, this toggle flop (as described above) fails in the FPGA in lab,
>
> from 1 to 10% of the time.
>
> It is definitely not a setup timing issue, since all flop inputs arrive
> well before the clock.
> It sure look like a hold time problem, since I see the input and the
> output of the flop
> glitch, then return to their original state, when the clock rises.
>
> I added some extra delay to the feedback path yesterday,
> and now it works great.
>
> Anyone have any comments? I would be interested in
> hearing similar experiences.
>
> Matt Gavin
> Rockwell Collins

Have you tried running the Xilinx timing analyser with the -min flag set to
get a minimum timing analysis. This will work o.k. with Virtex if you have
the later service packs (SP4+ ?) that put the min values in the timing
files. The Xilinx help line has just told me that the min values for -E
parts aren't released yet.





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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search