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 31075

Article: 31075
Subject: Re: Waveforms painting
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 11 May 2001 09:55:21 +0900
Links: << >>  << T >>  << A >>
Someone mentioned www.timingtool.com the other day.  Could that be what you're looking for?

-Kent

Article: 31076
Subject: Spartan Annoyances
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Thu, 10 May 2001 17:59:43 -0700
Links: << >>  << T >>  << A >>
Hi,

we've just shipped a new product that uses 5 Spartan-XL chips, and had
a fair amount of grief getting things up. We're using the basic
Foundation schematic-entry stuff, with service packs duly installed.

The worst thing we found is that, if we connect a signal to a pin and
don't reference it on the schematic, the pin will sometimes become an
output and do weird things. In one case, we ran the VME signal AS*
(address strobe) into the chip and decided later we didn't need it, so
ignored it. It then began hanging the VME bus by pulling AS* low, but
only when certain VME addresses were used!

In another case, all 5 FPGAs shared the DIN common config data pin;
once the first chip was configured, it started driving its own DIN as
an output, and trashed the config of the other four chips. This was
compile dependant (ie, random on different compiles).

The fix is to run all unused inputs into a huge AND gate and run the
output to an unconnected output pin, just to keep the compiler happy.

We never had such problems with 4000XL's. Any experience/ideas with
this one?

John

ps: the Spartan chips seem to have enough muscle to be a damned fine
VMEbus driver!

pps: the AND gate trick works, if there's an output pin available.
What if not? Then you'd have to invent a circuit with N inputs and no
outputs, but that was complex enough that the compiler couldn't figure
out that it's useless hence wouldn't strip it out!


Article: 31077
Subject: Re: Synplicity/Quicklogic choosing high drive input
From: Ken McElvain <ken@synplicity.com>
Date: Thu, 10 May 2001 20:00:52 -0700
Links: << >>  << T >>  << A >>
5.1.5 is very old.  I tried it in more recent versions and it worked.
I don't know if the attribute existed in that version.

Uwe Bonnes wrote:
> 
> Ken McElvain <ken@synplicity.com> wrote:
> : input foo /* synthesis ql_padtype="normal" */;
> : See the help file for examples.
> 
> :>
> :> Can anybody give a hint how to stop synplicity to choose a dedicated
> :> input pin for an input with high load?
> 
> Hallo Ken,
> 
> thanks for your help. Probably I missed to tell you the information that I
> run Synpicity delivered with Quickworks (V8.2 plus the 8.22 patch), which
> identifies itself as "Synplify-Lite 5.1.5", which substantially lags the
> present Synlify release. Local quicklogic support tried to be helpfull, but
> only gave the hint to rewrite my verilog code to include explicit
> buffers. However I don't feel satisfied with that work-around.
> 
> I tried your solution in two places for a single input and for a vector of
> inputs, to be sure that the vector doesn't cause problems (line numbers
> given for reference, not included in the files)
> 
>        1 `define VERSION "K-DELAY 0.00-1"
>        2
>        3 module camacdelay8(/*AUTOARG*/
>        4    // Outputs
>        5    Q_N, X_N, WRITE_EN_N, R_N,
>        6    // Inouts
>        7    DOUT0, DOUT1, DOUT2, DOUT3, DOUT4, DOUT5, DOUT6, DOUT7,
>        8    // Inputs
>        9    RESET_N, S1_N, S2_N, N_N, I_N, F_N, A_N, W_N
>       10    );
>       11    input                RESET_N,S1_N,S2_N,N_N;
>       12    input                I_N/* synthesis ql_padtype="normal" */;
>       13    input [4:0]          F_N;
>       14    input [3:0]          A_N/* synthesis ql_padtype="normal" */;
> 
> However Synplify ignores these hints and gives following report in the
> .srr file:
> 
> $ Start of Compile
> #Thu May 10 11:11:35 2001
> 
> Synplify Verilog Compiler, version 5.1.5, built Jul 20 1999
> Copyright (C) 1994-1999, Synplicity Inc.  All Rights Reserved
> 
> @I::"c:\cae\pasic\spde\data\macros.v"
> @I::"...\camacdelay8.v"
> @W:"...\camacdelay8.v":12:27:12:36|ignoring property ql_padtype
> @W:"...\camacdelay8.v":14:33:14:42|ignoring property ql_padtype
> Verilog syntax check successful!
> 
> Pathnames truncated for clarity.
> 
> The .qds file still instanciates a input only pad for the :
> 
> gate A_Nz_p[2] master Q_HINPAD cell IO108 end
> 
> Any hints why the properties are ignored?
> 
> Thanks again
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
> 
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

-- 
Ken McElvain, CTO
Synplicity Inc.
(408)215-6060

Article: 31078
Subject: Re: Spartan Annoyances
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 10 May 2001 20:56:49 -0700
Links: << >>  << T >>  << A >>
On Thu, 10 May 2001 17:59:43 -0700, John  Larkin
<jjlarkin@highlandSNIPTHIStechnology.com> wrote:
>Hi,
>
>we've just shipped a new product that uses 5 Spartan-XL chips, and had
>a fair amount of grief getting things up. We're using the basic
>Foundation schematic-entry stuff, with service packs duly installed.
>
>The worst thing we found is that, if we connect a signal to a pin and
>don't reference it on the schematic, the pin will sometimes become an
>output and do weird things. In one case, we ran the VME signal AS*
>(address strobe) into the chip and decided later we didn't need it, so
>ignored it. It then began hanging the VME bus by pulling AS* low, but
>only when certain VME addresses were used!

This make no sense. The only time I have seen random pins being
driven is when you have output signals that have not been locked to
a specific pin.

Can you give details of what the signals are that are driving these
pins that were prior inputs, and should now be un-used (as in your
above example). What did the PAR report say about these pins,
what about the xxx.PAD file , what about the fpga_editor.

In designs that have all the application I/O pins locked to specific
pins, all the remaining I/O pins of Xilinx FPGAs are defaulted to inputs
with a weak pull-up to VCC. This has been true for all FPGA products
and versions of software for all of the last 10 years.

>In another case, all 5 FPGAs shared the DIN common config data pin;
>once the first chip was configured, it started driving its own DIN as
>an output, and trashed the config of the other four chips. This was
>compile dependant (ie, random on different compiles).

Again, this sounds like you have an output in your design that you have not
locked to a specific pin. Each compile puts it somewhere, sometimes on
the DIN pin.

In your shared DIN pin case, are the FPGAs the same devices, and loaded
with the same design? if so they should all go done at the same time. If
not, then how are you managing the shared DIN? Separate Program pins?

>The fix is to run all unused inputs into a huge AND gate and run the
>output to an unconnected output pin, just to keep the compiler happy.

This is un-needed. You need to figure out what is being routed to these
supposedly unused input pins. Maybe it is some leftover debug stuff of
signals that you were routing out separately?

>We never had such problems with 4000XL's. Any experience/ideas with
>this one?

Architecturally they are very similar. It seems more likely that in your 4KXL
designs you dont have any un-locked outputs.

>John
>
>ps: the Spartan chips seem to have enough muscle to be a damned fine
>VMEbus driver!

Isn't that neat. Sure saves on a bucket of octal TTL buffers.

>pps: the AND gate trick works, if there's an output pin available.
>What if not? Then you'd have to invent a circuit with N inputs and no
>outputs, but that was complex enough that the compiler couldn't figure
>out that it's useless hence wouldn't strip it out!

I still dont think you need this, so I dont think this is an issue.


Good luck,

Philip
Philip Freidin
Fliptronics

Article: 31079
Subject: [Q]CardBus PC Card with PCI device
From: "Ben" <ejhong@future.co.kr>
Date: Fri, 11 May 2001 04:37:46 GMT
Links: << >>  << T >>  << A >>
Hi,

I have a PCI device whose interface is not compatible with CardBus standard.
But I want to build a CardBus PC Card with the PCI device.
In this case, is it possible to build a CardBus PC Card by integrating
CardBus-to-PCI bridge and the PCI device?
I wonder if there exists any CardBus-to-PCI bridge.
By the way, does it make sense to build a CardBus PC Card with a PCI device?

Thanks,

Ben



Article: 31080
Subject: Re: Waveforms painting
From: Srinivasan Venkataramanan <srini@realchip.co.in>
Date: Fri, 11 May 2001 10:36:40 +0530
Links: << >>  << T >>  << A >>
Check out,

http://members.aol.com/d2fabrizio/
http://www.timingtool.com/

HTH,
Srini

Marek Ponca wrote:
> 
> Do you know any free tool for painting digital waveforms ?
> Not for testbench generation, only for documentation.
> 
> Marek

-- 
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India

Article: 31081
Subject: Re: Need Advice on what Xilinx Tools to purchase
From: Ray Andraka <ray@andraka.com>
Date: Fri, 11 May 2001 05:55:44 GMT
Links: << >>  << T >>  << A >>
Type real is not synthesizable.  Some synthesis tools support reals for the math
to generate a constant, but that's as far as it goes.  THink about it, how would
you represent a real type with logic?

You need to find or develop a library of floating point components (remember,
floating point is just a fixed point mantissa with a second fixed point value to
indicate the position of the radix point).  That said, most applications do not
need floating point hardware throughout.  In the cases where you do have to deal
with floats, you can usually treat a sequenc of operations with fixed point
arithmetic, passing the exponents around and rejoining later in the pipeline. 
You can also let it get denormalized in you processing or even stray away from
IEEE 32 bit to help save on the hardware (it does require some time analyzing
your needs).  

For your system, 256MB is more or less entry level for serios FPGA design. 
Check the size of your paging file, could be you are filling that.

Alliance is the back end tools only, no synthesis, no design entry.  If you have
the cash, I'd go with Alliance + synplicity + Aldec or Modelsim for simulation.

ISE has a very weak VHDL, which you will find very frustrating to use.

Kris Nichols wrote:
> 
> Hey there,
>                I'm started a project 4 months ago using Xilinx Student
> Edition v2.1 tools and an evaluation board (XESS XS40).  It turns out
> I've since needed to use 32-bit IEEE floating point addition and
> multiplication throughout my design.  Currently, there the evaluation
> board I'm using no longer has the real-estate I need to implement my
> design with.  When I attempt to synthesize and simulate this design with
> the Xilinx Student Edition v2.1 tools, it runs out of memory (even
> through I'm using a WinNT platform with 256MB of SDRAM).
>             To solve my real-estate problem, I'm probably going to
> purchase one of the Xilinx Vertex-II FPGAs.  However, I'm not sure which
> of the following Xilinx Development Systems I should purchase (to help
> overcome the rest of my problems):
> 1.  Alliance Series
> 2.  Foundation Series ISE, or
> 3.  Foundation Series
> How do these Xilinx Development Systems compare??  Any suggestions or
> recommendations??  Does anybody know if any of these Xilinx Development
> Systems have support for 'real' types in VHDL (i.e. floating point
> numbers)??  Thanks.
> 
> Kris Nichols

-- 
-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

Article: 31082
Subject: Re: Waveforms painting
From: Marek Ponca <marek.ponca@et.stud.tu-ilmenau.de>
Date: Fri, 11 May 2001 08:13:35 +0200
Links: << >>  << T >>  << A >>
Hi Joerg, 

This looks really good, andventegous for documentation written
in Latex.

Thanks,
M. 



> Hello Marek,
> 
> if you are familar with Latex , you can use a style file named
> timing.sty (see
> ftp://ftp.dante.de/tex-archive/macros/latex/contrib/other/timing/).
> With the help of these style-files you can create waveforms with your
> favorite editor and the latex environment instead of paiting them.
> 
> ciao
> Joerg

-- 
Dipl.-Ing. Marek Ponca
Institut of Circuit Technology and Electronics
Faculty of Electrical Engineering and Information Technology
Ilmenau Technical University
P.O. BOX 10 05 65
98684 Ilmenau, Germany

Tel: +49 3677 69 1167 fax:(1163)
http://www.inf-technik.tu-ilmenau.de/~marek/
marek.ponca@et.stud.tu-ilmenau.de

Article: 31083
Subject: Asynchronous Compare
From: Thomas Zipper <Thomas.Zipper@icn.siemens.de>
Date: Fri, 11 May 2001 08:47:28 +0200
Links: << >>  << T >>  << A >>
Hello,

I do a compare-equal of the output of two Cray counters. Each counter is
connected to a separate clock (different freq.).
Can I expect that there a no spikes on the output of the compare-equal?
If yes, is there a way to proof that?

Bye

Thomas



Article: 31084
Subject: Re: Finally, an FPGA tool chain for Linux (Altera Quartus II)
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Fri, 11 May 2001 09:22:27 +0200
Links: << >>  << T >>  << A >>


> Given that VMWare provides a way of using the command line tools under
> Linux then
> (3) => Xilinx doesn't have to do a Linux port.

But I still have to pay and support for VMWare and Windows running inside
VMWare.

If you look at the processes running after starting a foundation compile, then
you can see that
the backend tools seem to be 16 Bit only, so you should be able to run them
within DOSEMU.

You could also get the freeware version of Alliance (include in SuSE Linux for
example).
With the help of JBits it should be possible to add support for Xilinx chips to
it.

But hey, wait, you can do all your designs with JBits. You will use a couple of
month with respect to
time-to-market, but everything will be hand optimized and fine tuned to get very
good results.

Kolja Sulimma


Article: 31085
Subject: Re: Finally, an FPGA tool chain for Linux (Altera Quartus II)
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Fri, 11 May 2001 09:40:33 +0200
Links: << >>  << T >>  << A >>
Quartus II runs from the command line and actually this interface is more
powerful than the GUI. It supports TCL and there are several pre-written
scripts available from the Altera web site and some more, sophisticated and
easy to use ones from FAEs. All Quartus specific TCL commands are well
documented.With this inteface you can access the device and timing database
and do powerful manipulations like floorplanning or setting timing
constraints. The syntax is: quartus_cmd -f <script_file>
For big designs, especially when integrated with other synthesis or
simulation tools we prefer to use TCL rather than the GUI.


Rick Filipkiewicz <rick@algor.co.uk> wrote in message
news:3AFAF39C.2923316D@algor.co.uk...
>
>
> Eric Smith wrote:
> >
> > Altera has announced a port of Quartus II (including MAX+PLUS II)
> > to Linux!
> >
> >
http://www.altera.com/corporate/press_box/releases/pr-linux_quartus.html
> >   http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.050701/211270104
> >
> > At last, one of the programmable logic vendors gets it.  They say "Linux
> > has enjoyed dramatic success over the last several years as a platform
> > for a variety of EDA point tools, such as simulation, because of the low
> > cost per compute cycle."  An interesting contrast from Xilinx' claims
> > that there is no customer demand for Linux.
> >
> >
>
> I wonder if Xilinx's attitude stems from these 2 (my opinion only)
> equivalences:
>
> (1) Linux user <=> serious user
>
> (2) GUI user <=> !serious user
>
>
> From which we can derive
>
> (3) Linux user <=> !GUI user
>
> Given that VMWare provides a way of using the command line tools under
> Linux then
> (3) => Xilinx doesn't have to do a Linux port.
>
>
> Question: Do Quartus & Warp tools run from the command line as well as
> the Xilinx ones do ? are the command line i/f's as well documented ?
>
> <snip>



Article: 31086
Subject: Re: Virtex-2 - experiences ?
From: "Meelis Kuris" <matiku@hot.ee>
Date: Fri, 11 May 2001 11:56:21 +0300
Links: << >>  << T >>  << A >>

"Erik Widding" <widding@birger.com> wrote in message
news:%PaK6.12945$t12.971754@bgtnsc05-news.ops.worldnet.att.net...
...
> revision.  But overall, none of the errata is particularly bad, just don't
> expect the DCM to do all the really cool stuff listed in the data sheet.
What do you mean by that? What doesn't it do then?
Actually, the thing I'm concerned about is, does fine phase shift
work ok (at 270MHz)?
Can't test it right now myself but my whole project relies on that phase
shift,
so I'm a bit worried.

Meelis





Article: 31087
Subject: Re: Asynchronous Compare
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 11 May 2001 02:20:24 -0700
Links: << >>  << T >>  << A >>
Thomas Zipper <Thomas.Zipper@icn.siemens.de> writes:
> I do a compare-equal of the output of two Cray counters.

Do you mean "grey code counters"?  I'll assume that you do.

> Each counter is
> connected to a separate clock (different freq.).
> Can I expect that there a no spikes on the output of the compare-equal?
> If yes, is there a way to proof that?

This sounds like a homework problem, and one that you should be able to
figure out by studying a good digital logic textbook.  But perhaps it
merits discussion anyhow.

There are two cases to consider:

1)  The counters are never clocked simultaneously (or near simultaneously).
    Since by definition a grey code counter will only change one of its
    output bits when it is clocked, and the one that is not clocked will
    not change any of its bits, the output of an equality comparator will
    make at most one transition for the clock.  Thus no glitch.

    However, if you have two separately generated clocks of different
    frequencies, you WILL have near-simultaneous clocks, and you have to
    deal with that case.

2)  The counters are clocked simultaneously (or near simultaneously).  So
    one output of each counter will change.  There are several cases,
    I'll let you think about the comparator output for these cases
    yourself.  It might help to draw some timing diagrams.  For the
    truly simultaneous case, the analysis is trivial.  But in the real
    world, you should never expect that two "simultaneous" signal
    changes will actually be simultaneous, even if they outputs of flops
    sharing a common clock.  There will almost always be some minor
    difference in prop delay in the clock, the output signal path, or
    (likely) both.  This delay may be very short, but if you count on it
    being zero you will get screwed.

    However, if you design something that *depends* on the two transitions
    NOT being simultaneous, it will happen that they are.

    So the cases to focus on involve one counter being clocked, then the
    other being clocked very soon thereafter.

    What happens if the counters were originally equal?

    What happens if they were NOT originally equal?  Are there multiple
    posibilities?

Bonus question for extra points:  Assume that you are using the grey code
counters and comparator as part of a FIFO to interface between two clock
domains.  Suppose it is possible for the comparator output to have a
glitch.  How can you prevent this from being a problem in your system?

Article: 31088
Subject: using FPGAs in communication products....
From: "Mike DeLaney" <FPGA@globalnetr.com>
Date: Fri, 11 May 2001 12:29:55 GMT
Links: << >>  << T >>  << A >>

Interested in a Cutting EDGE company, Hot technology, Tremendous growth,
Pre-IPO stock opt's $ -  securely funded  - 2nd round of funding May 2001
$50mil
Great locations/Warm Climate - either  GA or  N. VA
Superb Management Team with a proven track record with building successful
Start-ups.
Product launch - June 2001 at Supercomm.

Join a winning team that is moving at record breaking pace and redefining
the way technologies are developed and networks are built.    -- We are
designing the next generation end-to-end dynamically controlled all-optical
networking solutions.
-- We are expanding the boundaries of transport networks.
 In a very short time, we have built a world-class organization that is a
mix of optical technology experts, software and systems designers, and
forward-looking visionaries.  With 190+ employees and aggressively growing.

Funding secured by the leaders in the optical arena - Worldview Technology
Partners and Menlo Ventures
Their reputation for success has been unsurpassed.


         ***  WANTED  -   HARDWARE  Engineers  -  FPGA/Verilog  ASIC  &
Digital Board Level  Designers    ***


Salary $70k -115k + bonus + stock opt's $$$
Excellent benefits package +  dynamic work environment
Unbeatable salary


Curious,  Interested .......Contact me -  Mike DeLaney    toll free -
888.338.9087
Even if your curious it's worth calling.





Article: 31089
Subject: Re: Shannon Capacity, a quote from the paper
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 11 May 2001 13:42:37 +0100
Links: << >>  << T >>  << A >>
On Thu, 10 May 2001 09:17:19 -0700, Austin Lesea
<austin.lesea@xilinx.com> wrote:

>I really am going to quit replying:
>
>But I thought I would leave it in Shannon's own words....with a few of my own.
>
>For that, I really do apologize:  Shannon really did a great job explaining it,
>and I feel that maybe the best thing to do is read his paper, and then go build
>something to prove it to yourself.  My learning experience was a 16QAM modem with
>BCH coding.
>
>From "Communication in the Presence of Noise,"  1940, published 1948.
>
>C = W log2 (P+N)/N

at last, with the correct sign. 

>"This shows that the rate W log (P+N)/N measures in a sharply defined way the
>capacity of the channel for transmitting information.  It is a rather surprising
>result, since one would expect that reducing the frequency of errors would require
>reducing the rate of transmission, and that the rate must approach zero as the
>error frequency does.  Actually we can send at the rate C but reduce errors by
>using a more involved encoding and longer delays at the transmitter and receiver."
>
>(emphasis added by me)
>
>I begin to see what is so confusing.  We have a bunch of people with only two
>fingers.

I have to apologise for leaving some confusion around the term "symbol"
- I contemplated expanding on that, but decided against it because it
seemed to be taking up too much bandwidth. But your reply gives me an
easier way in than I found.

>If one confines oneself to using a binary symbol in the channel (on off, 1-0,
>etc), then for every bit in C, there must be some extra bits added for correction
>in the channel to perform error correction.  But if we increate the rate of the
>bits in the channel, we get more errors for a given N, keeping P constant.  Thus,
>C ends up including the error correction bits because the channel C must be equal
>to or greater than the information C.
>
>Thus, we must reduce the number of bits in the channel per unit time given a
>specific error correcting code to achieve some desired performance.

So far, correct. 

>If we instead use arbitrarily more complex symbols (QPSK, 16OQAM, OFDM ....), then
>for every bit in C, there are bits added to the channel, but the rate of the
>symbols may now actually be much less than that of the rate of the binary channel
>(PSK = 2 bits per symbol, 16QAM = 4 bits/symbol, etc.).  

Of course.

>This added degree of
>freedom in effect allows for many more bits in the channel to be utilized for
>error correction without increasing the bandwidth W of the channel, or the power P
>of the information in the channel.  C (rate in b/s) in the channel is greater than
>the C (rate in b/s) of the information, allowing for the error checking and
>correcting information.

At last. 

But you have used the term C - "rate in b/s" to mean two entirely
different things. Only one of these is the channel capacity.

We could call them "useful channel capacity" and "raw channel capacity"
if you like - and your position was that C is the "raw channel
capacity".

Your argument suggests you could replace that 16QAM with 64QAM or
256QAM, or higher, and greatly increase the raw capacity of the channel.
And indeed you could.  Ad infinitum.

But in the presence of the same noise level, you would have to eat up
ALL the additional data with redundancy, to overcome the decreased
reliability of decoding these less robust symbols. (Leaving aside the
difficulty of designing a suitable system of redundancy. That's simply a
matter of how closely you approach the limit)

In other words, you can increase the binary digit rate (raw channel
capacity) of the channel ad infinitum. But because of the redundancy you
need for reliability in the presence of noise, you cannot increase the
_information_ rate beyond a certain limit - the useful channel capacity.

Having separated these two concepts, it seems obvious to me, that
Shannon's "channel capacity" refers to the "useful channel capacity"
since he refers to it as the ability to carry information. In other
words the redundancy is NOT counted as part of the channel capacity.

- Brian.

Article: 31090
Subject: Re: Waveforms painting
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 11 May 2001 14:01:14 +0100
Links: << >>  << T >>  << A >>


Marek Ponca wrote:
> 
> Hi Joerg,
> 
> This looks really good, andventegous for documentation written
> in Latex.
> 
> Thanks,
> M.
> 
>

Is this the new flexible documentation format designed to stop errors
from being propagated ? [Sorry couldn't resist]

Article: 31091
Subject: Re: Spartan Annoyances
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Fri, 11 May 2001 09:40:57 -0400
Links: << >>  << T >>  << A >>
To avoid unpredictable behavior on unused I/Os - just draw the IPADs on
schematics with PULLUP resistors attached.

"John Larkin" <jjlarkin@highlandSNIPTHIStechnology.com> wrote in message
news:QTn7OlPqzSzduavnh=XdwH3QvcuK@4ax.com...
> Hi,
>
> we've just shipped a new product that uses 5 Spartan-XL chips, and had
> a fair amount of grief getting things up. We're using the basic
> Foundation schematic-entry stuff, with service packs duly installed.
>
> The worst thing we found is that, if we connect a signal to a pin and
> don't reference it on the schematic, the pin will sometimes become an
> output and do weird things. In one case, we ran the VME signal AS*
> (address strobe) into the chip and decided later we didn't need it, so
> ignored it. It then began hanging the VME bus by pulling AS* low, but
> only when certain VME addresses were used!
>
> In another case, all 5 FPGAs shared the DIN common config data pin;
> once the first chip was configured, it started driving its own DIN as
> an output, and trashed the config of the other four chips. This was
> compile dependant (ie, random on different compiles).
>
> The fix is to run all unused inputs into a huge AND gate and run the
> output to an unconnected output pin, just to keep the compiler happy.
>
> We never had such problems with 4000XL's. Any experience/ideas with
> this one?
>
> John
>
> ps: the Spartan chips seem to have enough muscle to be a damned fine
> VMEbus driver!
>
> pps: the AND gate trick works, if there's an output pin available.
> What if not? Then you'd have to invent a circuit with N inputs and no
> outputs, but that was complex enough that the compiler couldn't figure
> out that it's useless hence wouldn't strip it out!
>
>



Article: 31092
Subject: Nasty "register ordering" in map
From: hamish@cloud.net.au
Date: Fri, 11 May 2001 13:46:37 GMT
Links: << >>  << T >>  << A >>
For the last few days I've been fighting with Xilinx MAP's
"register ordering" feature. This "feature" attempts to group
flip flops with similar names (related by numbers in the signal name)
into the same slice. For example, mybus(0) and mybus(1) will be
mapped together, and so will mysig_0 and mysig_1.

Of course, once MAP has done this, there's nothing PAR can do about
it. If mysig_0 and mysig_1 are both sourced and sunk on opposites
sides of the die, PAR will just place the slice as best it can,
and both paths may fail timing. Not desirable when you're running
fast (150MHz+) in a large chip (XCV2000E). 

I'm used to delaying signals in my code to improve the routing
by doing things like mysig_d1, mysig_d2, etc. However, since MAP
groups these together into a single slice, there's no routing
improvement at all. Same if you use a vector; mysig_d(0) and
mysig_d(1) will be grouped together.

To make matters worse, when Synplify duplicates signals to
improve the fanout, the resulting signal names attract MAP's
attention. eg mysig may be duplicated to mysig_1, mysig_2 etc
which will be grouped into pairs by the register ordering.

(On the other hand, it's a useful feature when you are dealing with 
signals which truely are parallel parts of a bus. If you disable
register ordering (map -r), you can see what happens without it.
The logic gets a lot bigger, especially if you happen to be working
on a 64 bit bus; then timing fails due to routing congestion etc.)

Any ways to work around this? MAP doesn't seem to allow you to
turn this off on a signal by signal basis. The best I can do is
to try to name signals so that MAP won't touch them.
Some things I've done to trick MAP:

1. Rename mysig_d1, mysig_d2 to mysig_1d, mysig_2d, etc. Doesn't
   help if you use an array mysig_d(n downto 0) though.

2. Interestingly, if you have a signal mybus(7 downto 0), and Synplify
   duplicates some of those, you get mybus_1(0), mybus_2(0),
   mybus_1(1), mybus_2(2) etc. These get grouped as mybus_1(0) with
   mybus_1(1), etc, which might not be so bad.

   It might be possible to use this to work around the problem with
   mysig_d. What if mysig_d was an array of std_logic_vector(0 to 0)?
   Your signals would be mysig_d(n)(0), which MAP might overlook.

3. The biggest hack, but the most effective.. use a Perl script to
   modify the EDIF netlist after synthesis. I get my script to look
   for particular signals which I want MAP to leave alone. It then
   changes things like mybus(0) to mybus_0_,
   mybus_1(0) to mybus_1_0_, mybus_d(0) to mybus_d_0_, etc. The
   trailing underscore stops MAP from finding the number.

#3 is pretty ugly. Synplify has an attribute to specify the
format of the signal name in the EDF -- syn_edif_bit_format.
You can apply it signal by signal, in your VHDL code.
However, I tried getting it to write out mybus(0)_, and the
attribute was completely ignored. Looks like it can only
let you configure the type of brackets used; (), <>, [].

Anyone else have any ideas? This behaviour is a real killer on
signals with large fanout (eg in the order of several hundred,
to thousands of flip-flops).


regards
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 31093
Subject: SpartanII: non clock pad drives clock net ?
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Fri, 11 May 2001 17:16:10 +0200
Links: << >>  << T >>  << A >>
Hi,

is it possible to use a normal (non clock) pad from a Spartan II FPGA to
drive an internal clock net ? Automatic implementation cannot do that
and aborts with an error ! Is it possible to force a connection from PAD
to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad
to the FFs is not that critical for this design !

Has anybody an idea how to do this ?

Matthias
-- 
-------------------------------------------------
\ Matthias Fuchs                                 \
 \ esd electronic system design Gmbh              \
  \ Vahrenwalder Straße 205                        \
   \ D-30165 Hannover                               \
    \ email: matthias.fuchs@esd-electronics.com      \
     \ phone: +49-511-37298-0                         \
      \ fax:   +49-511-37298-68                        \
       --------------------------------------------------

Article: 31094
Subject: How to program a mach 4? How to get a chain file?
From: mwnews@pentax.boerde.de (Matthias Weingart)
Date: 11 May 2001 16:17:24 GMT
Links: << >>  << T >>  << A >>
Hi,

this is my first time programming a MACH 4 and now am I in a dead end ..
I am not able to program a MACH 4 (M4A5-32/32) using
 ispDesignExpert from Lattice to create the Jedec files ...
 ispVM (LatticePro) to program it using the programming cable

My problem is - the Lattice Pro want a JTAG chain file *.wch, but 
ispDesignExpert only create *.jedec files. How do I get a chain file?

ispVM Download itself does not support the Mach4. The readme says that I 
have to convert the Mach-files to *.svf with LatticePro.

Please help me out of this nightmare,

thx

Matthias

Article: 31095
Subject: Re: SpartanII: non clock pad drives clock net ?
From: "Carsten Nöding" <carsten.noeding@uni-mainz.de>
Date: Fri, 11 May 2001 19:24:31 +0200
Links: << >>  << T >>  << A >>
According to Xilinx documentation the BUFGPs of the Virtex and Spartan-II
devices can only be driven by the four dedicated IOBs. That means that you
cannot use an internal signal to drive a BUFGP.

Carsten

"Matthias Fuchs" <matthias.fuchs@esd-electronics.com> wrote in message
news:3AFC023A.F6987791@esd-electronics.com...
> Hi,
>
> is it possible to use a normal (non clock) pad from a Spartan II FPGA to
> drive an internal clock net ? Automatic implementation cannot do that
> and aborts with an error ! Is it possible to force a connection from PAD
> to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad
> to the FFs is not that critical for this design !
>
> Has anybody an idea how to do this ?
>
> Matthias
> --
> -------------------------------------------------
> \ Matthias Fuchs                                 \
>  \ esd electronic system design Gmbh              \
>   \ Vahrenwalder Straße 205                        \
>    \ D-30165 Hannover                               \
>     \ email: matthias.fuchs@esd-electronics.com      \
>      \ phone: +49-511-37298-0                         \
>       \ fax:   +49-511-37298-68                        \
>        --------------------------------------------------



Article: 31096
Subject: Re: [Q]CardBus PC Card with PCI device
From: "Markus Meng" <meng.engineering@bluewin.ch>
Date: Fri, 11 May 2001 20:20:18 +0200
Links: << >>  << T >>  << A >>
Hi Ben,

a few CardBus Slave cards to exist. However the majority is still based on
the "isa-bus" based PCMCIA Card interface... Then does it make sense to
make a Master PCI to PCMCIA Interface...
I think using QuickLogic devices can be a goog starting point

markus

"Ben" <ejhong@future.co.kr> schrieb im Newsbeitrag
news:u0KK6.11$09.832@news2.bora.net...
> Hi,
>
> I have a PCI device whose interface is not compatible with CardBus
standard.
> But I want to build a CardBus PC Card with the PCI device.
> In this case, is it possible to build a CardBus PC Card by integrating
> CardBus-to-PCI bridge and the PCI device?
> I wonder if there exists any CardBus-to-PCI bridge.
> By the way, does it make sense to build a CardBus PC Card with a PCI
device?
>
> Thanks,
>
> Ben
>
>



Article: 31097
Subject: Re: Asynchronous Compare
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 11 May 2001 11:39:03 -0700
Links: << >>  << T >>  << A >>
Grey counters are often used as FIFO address counters , where address identity
must be detected for determining the extreme conditions of Full or Empty.
If the two counters are at differing states, even changing asynchronously, there
will NEVER be a decoding spike at the output of the identity comparator.
If counter A is incremented to become identical with counter B, but counter B
is, very soon after, incremented, there can be a LEGITIMATE "identity" decoding
spike of undefined length.

Luckily, this does not matter in a FIFO. The spike either sets the Full/Empty
flag ( causing a one-clock period wait state) or it does not set that flag,
since the identity has already disappeared.
Either case is acceptable.

I have an improved description of very efficient and fast asynchronous FIFO
implementations in Virtex BlockRAMs. If anybody is interested, send me e-mail.

Peter Alfke, Xilinx Applications
========================
Thomas Zipper wrote:

> Hello,
>
> I do a compare-equal of the output of two Cray counters. Each counter is
> connected to a separate clock (different freq.).
> Can I expect that there a no spikes on the output of the compare-equal?
> If yes, is there a way to proof that?
>
> Bye
>
> Thomas


Article: 31098
Subject: Re: SpartanII: non clock pad drives clock net ?
From: Catalin Baetoniu <starnet@home.com>
Date: Fri, 11 May 2001 18:45:53 GMT
Links: << >>  << T >>  << A >>
Matthias,

Each one of the four global clock buffers in Spartan2/Virtex can be driven by
one of the two dedicated IOBs (either top or bottom side), by either the top
or bottom DLLs or by any internal signal. To drive a global clock net with any
normal IOB you have to instantiate (in schematics or HDL) an IBUF followed by
a BUFG.

Catalin Baetoniu
Starnet Engineering Inc.

"Carsten Nöding" wrote:

> According to Xilinx documentation the BUFGPs of the Virtex and Spartan-II
> devices can only be driven by the four dedicated IOBs. That means that you
> cannot use an internal signal to drive a BUFGP.
>
> Carsten
>
> "Matthias Fuchs" <matthias.fuchs@esd-electronics.com> wrote in message
> news:3AFC023A.F6987791@esd-electronics.com...
> > Hi,
> >
> > is it possible to use a normal (non clock) pad from a Spartan II FPGA to
> > drive an internal clock net ? Automatic implementation cannot do that
> > and aborts with an error ! Is it possible to force a connection from PAD
> > to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad
> > to the FFs is not that critical for this design !
> >
> > Has anybody an idea how to do this ?
> >
> > Matthias
> > --
> > -------------------------------------------------
> > \ Matthias Fuchs                                 \
> >  \ esd electronic system design Gmbh              \
> >   \ Vahrenwalder Straße 205                        \
> >    \ D-30165 Hannover                               \
> >     \ email: matthias.fuchs@esd-electronics.com      \
> >      \ phone: +49-511-37298-0                         \
> >       \ fax:   +49-511-37298-68                        \
> >        --------------------------------------------------


Article: 31099
Subject: Re: SpartanII: non clock pad drives clock net ?
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Fri, 11 May 2001 12:42:27 -0700
Links: << >>  << T >>  << A >>
Hi Matthias,
The problem is that you're using a BUFGP.  Use a BUFG instead and this
connection scheme will work just fine.  The problem is that a BUFGP is a
macro containing a IBUFG and BUFG in series- which will result in an error
if it's input is connected to an IBUF output.
Regards,
Tim Jaynes
CAE


Matthias Fuchs wrote:

> Hi,
>
> is it possible to use a normal (non clock) pad from a Spartan II FPGA to
> drive an internal clock net ? Automatic implementation cannot do that
> and aborts with an error ! Is it possible to force a connection from PAD
> to INBUF to BUFGP by hand ? Clock skew or the delay from the clock pad
> to the FFs is not that critical for this design !
>
> Has anybody an idea how to do this ?
>
> Matthias
> --
> -------------------------------------------------
> \ Matthias Fuchs                                 \
>  \ esd electronic system design Gmbh              \
>   \ Vahrenwalder Straße 205                        \
>    \ D-30165 Hannover                               \
>     \ email: matthias.fuchs@esd-electronics.com      \
>      \ phone: +49-511-37298-0                         \
>       \ fax:   +49-511-37298-68                        \
>        --------------------------------------------------




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