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 39350

Article: 39350
Subject: toolbox.xilinx.com
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 07 Feb 2002 10:09:22 +0200
Links: << >>  << T >>  << A >>

Doesn't seem to be working... Same there?

Utku

Article: 39351
Subject: Re: CLKDLL x4 problem
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 07 Feb 2002 09:39:25 +0100
Links: << >>  << T >>  << A >>
dottavio@ised.it (Antonio) writes:

> By the way, to what is due this limitation of CLKDLL ??

The length of the delay line in the silicon, I guess.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 39352
Subject: Re: Making Altera development quicker
From: "Paul" <nospam@nospamplease.com>
Date: Thu, 7 Feb 2002 09:53:59 -0000
Links: << >>  << T >>  << A >>
"Jay" <kayrock66@yahoo.com> wrote in message
news:d049f91b.0202061643.4ebd0d16@posting.google.com...
> > 2) I did some tests on a 32 bit counter fed by cout of a 24bit (mod
> > 10,000,000 counter), The Fmax was 84MHz but a timing simulation showed
it
> > didn't work correctly when rolling over from FFFFFFFF to 00000000 with a
> > system clock of 80MHz. I looked at the static timing analysis but
couldn't
> > see why.
> > Note my vwf file only consisted of the clock signal, so not alot could
be
> > wrong with my stimuli waveform.
>
> This may be a silly question but did you by any chance feed the carry
> out of the first counter directly into the clock pin of the second
> counter?  If you did, then this would not be standard synchronous
> design as such, and the static timing check would not be meaningful.

Nope :)

Into the synchronous count enable pin of the 32 bit counter.



Article: 39353
Subject: Re: Altera MAX7000 PLD's
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 07 Feb 2002 10:00:12 +0000
Links: << >>  << T >>  << A >>
peter@nronline.com (Peter Jahnke) writes:

> I have been working with Altera MAX7000 PLD's in my new project and i
> have encountered some problems which i cannot solve.  I was wondering
> if anyone
> knew of specific newsgroups for this series of chip.  Alternatively i
> was wondering if someone know how to solve these problems.
> 
> Error: Node for pin "BusClock" must have the same name as the pin
> Error: Node for pin "BusFrame" must have the same name as the pin
> 
> I have checked the names and they match, i was wondering why this was
> occuring??

That's a bit wacky!  Are you using graphics or text to enter your
design?

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 39354
Subject: Re: Looking for Free EDIF/Verilog netlist - Schematic Viewer
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Thu, 07 Feb 2002 10:32:56 GMT
Links: << >>  << T >>  << A >>


Srinivasan Venkataramanan wrote:
> 
> Hi All,
>        Trying to set up a simple design flow at home using FREE EDA
> tools, I tried using Webpack for synthesis, but after synthesis I
> couldn't see any schematics. I know that Webpack can write EDIF (but
> not quite sure how to do that - if someone knows please do let me
> know) or Verilog netlist as output, but is there any schematic viewer
> (free) for the same? After some web search I found one at
> http://www.e-tools.com/content/download.html (EStudiopro), but when I
> try to run the same, it says "License expired" - though the web page
> doesn't talk about any license for this particular product.
> 
> Any links is greatly appreciated.

I don't think webpack does schematics (list of features on xilinx site).

Article: 39355
Subject: MC6800 vhdl design
From: poste libre <gaylord.pelletier@libertysurf.fr>
Date: Thu, 07 Feb 2002 10:59:31 +0000
Links: << >>  << T >>  << A >>
Hi,

I'm currently  looking for the RTL description of the Motorola MC6800
(VHDL) . Please contact me if you know where I can find it or if you
know a company which could make it for me.
Thanks,



Article: 39356
Subject: Re: Pseudorandom Bitstream
From: Stromeko@nexgo.de (Achim Gratz)
Date: 7 Feb 2002 03:37:02 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3C617D80.98BA6DF5@andraka.com>...
> One technique for a uniform distribution is to run the LFSR at a faster
> rate and use groups of bits to generate your density.

That was the source of my problem, I need to run the LFSR at the
maximum speed I can get because I need it to dither another bitstream
that is produced at 1...5MHz.

>  For example, for a
> 1 in 8 density you could use 3 consecutive bits out of an LFSR, if they
> are all '0' then the output is '1', otherwise it is zero.  You have to
> advance the LFSR by 3 bits per output sample in order to make this work.
> You can't just take multiple bits out of the LFSR on each clock because
> the additional bits are just time shifted copies of the first bit.
> ALternatively you could use parallel LFSRs each seeded at a different
> place in the sequence so that you can get a new output on every clock.

I was under the impression that while the bitstream of an LFSR is a
very good approximation to being random, codes built in that way might
not be that good. Any papers on how to know in advance, without
fooling around with the feedback taps?

> If you used, say 16 uniquely seeded long LFSRs, you could get an arbitrary
> threshold on a uniform variable that could be set at anywhere from 0 to
> 65535/65536.  If you do this in xilinx, the individual LFSRs can be made
> very compact (1 CLB) using the SRL16 shift registers (and they could
> easily be long enough not to repeat within your lifetime once seeded).

That sounds wonderful, I was thinking to use Spartan-II or Virtex-II
devices.

[...]
I'll look up your paper later. Thanks for your suggestions.


Achim.

Article: 39357
Subject: Re: Pseudorandom Bitstream
From: vt313@comsys.ntu-kpi.kiev.ua
Date: Thu, 07 Feb 2002 15:31:37 +0200
Links: << >>  << T >>  << A >>


Achim Gratz wrote:
> 
> Ray Andraka <ray@andraka.com> wrote in message news:<3C617D80.98BA6DF5@andraka.com>...
> > One technique for a uniform distribution is to run the LFSR at a faster
> > rate and use groups of bits to generate your density.
> 
> That was the source of my problem, I need to run the LFSR at the
> maximum speed I can get because I need it to dither another bitstream
> that is produced at 1...5MHz.
> 

In the LSFR bitstream the bytes of neighboring bits,
considered as signed vectors, are practically
uncorrelated, and belong to the interval (-1.0 : 1.0).
Therefore LSFR generator at 100 MHz 
provides the byte stream at 100 MHz.

If you add couples of neigboring 
sampling bytes from LSFR,
then you get the  approximation
of the "triangle" distribution.

If you want the Gaussian distribution,
then you would add n>10 neigboring 
sampling bytes from LSFR,
and get the rather exact approximation
of the Gaussian distribution.

Anatoli  S.

Article: 39358
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 13:36:37 GMT
Links: << >>  << T >>  << A >>
Can you get away with a read-ahead cache in your application.  If you can, then you can use the
block ram to read ahead.  There's a hit when the read pattern changes but otherwise you can
anticipate the read and have the data ready.  Of course, only some applications (eg video
buffer) can benefit.

Rick Filipkiewicz wrote:

> Allan Herriman wrote:
>
> > On Wed, 06 Feb 2002 01:14:29 +0000, Rick Filipkiewicz
> > <rick@algor.co.uk> wrote:
> >
> > >
> > >
> > >Jay wrote:
> > >
> > >> Why don't you give it a rough cut, then synth, and P&R and see what
> > >> you get.  If you're a designer of similar caliber to some of the
> > >> regular posters on here then you should have a good shot at it.  We
> > >> run our ECC SDRAM interface at 25MHz, but then again, its a standard
> > >> cell design being proto'd in a Vertex 2 6000, not a purpose build FPGA
> > >> design.
> > >>
> > >
> > >So far I've manged to push ours to 100MHz or so in an XCV600E-6, no floorplanning or hard
> > >macro'ing,  just the auto P&R tools. The target/goal, after some floorplanning & much
> > >sweat+cursing etc, is 125/133Mhz in a -7.
> > >
> > >Then, sometime in April, we'll move to the V2 and I'll start similing again.
> >
> > I recently did one at 133MHz in an XCV2000E-7.  No problems at all,
> > and no floorplanning required.  It was heavily pipelined though, as
> > latency doesn't matter for my particular application.
> >
> > Regards,
> > Allan.
>
> Yes. That's the difficulty I face - CPU read latency is critical in my app so I can't go the
> "natural" FPGA way with lots of pipeline stages. What I'll probably do is add some stages as
> "scaffolding" to check that no board SI issues get in the way of 133MHz, get Linux running
> reliably, then figure out how to remove them.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39359
Subject: Re: Pseudorandom Bitstream
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 13:44:39 GMT
Links: << >>  << T >>  << A >>
The thing you need to be careful with an LFSR is that you can only take one bit per
clock.  If you take more than one bit, the second bit is highly correlated (it is a time
shifted copy of the first bit) to the first, so you lose the randomness.  A common mistake
is to take several bits broadside out of the LFSR and then clock it only once per sample.

The LFSR by itself is not a good way for producing a cryptographic bit stream because you
can reconstruct the polynomial from just N+1 bits where N is the length of the LFSR.  Once
you know the polynomial and the current state (which you also discover in those N+1 bits),
you can predict the rest of the sequence.  Cryptographic systems use considerably more
elaborate techniques to make it harder to recover the key stream.

Achim Gratz wrote:

> Ray Andraka <ray@andraka.com> wrote in message news:<3C617D80.98BA6DF5@andraka.com>...
> > One technique for a uniform distribution is to run the LFSR at a faster
> > rate and use groups of bits to generate your density.
>
> That was the source of my problem, I need to run the LFSR at the
> maximum speed I can get because I need it to dither another bitstream
> that is produced at 1...5MHz.
>
> >  For example, for a
> > 1 in 8 density you could use 3 consecutive bits out of an LFSR, if they
> > are all '0' then the output is '1', otherwise it is zero.  You have to
> > advance the LFSR by 3 bits per output sample in order to make this work.
> > You can't just take multiple bits out of the LFSR on each clock because
> > the additional bits are just time shifted copies of the first bit.
> > ALternatively you could use parallel LFSRs each seeded at a different
> > place in the sequence so that you can get a new output on every clock.
>
> I was under the impression that while the bitstream of an LFSR is a
> very good approximation to being random, codes built in that way might
> not be that good. Any papers on how to know in advance, without
> fooling around with the feedback taps?
>
> > If you used, say 16 uniquely seeded long LFSRs, you could get an arbitrary
> > threshold on a uniform variable that could be set at anywhere from 0 to
> > 65535/65536.  If you do this in xilinx, the individual LFSRs can be made
> > very compact (1 CLB) using the SRL16 shift registers (and they could
> > easily be long enough not to repeat within your lifetime once seeded).
>
> That sounds wonderful, I was thinking to use Spartan-II or Virtex-II
> devices.
>
> [...]
> I'll look up your paper later. Thanks for your suggestions.
>
> Achim.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39360
Subject: Re: CLKDLL x4 problem
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 13:53:47 GMT
Links: << >>  << T >>  << A >>
The DLL consists of a tapped digital delay line and a state machine that
controls which taps are used to supply the signal.  In order for it to
work properly, the input signal period has to fit within the length of
the delay line. Otherwise there is no way to achieve a lock.  The
multiplied frequency is achieved by clever use of the delay taps to set
and reset the output flip-flop, so no lock means no multiplied
frequency.

The DINI board, at least the one I have here, has sockets for the
crystals.  choose a clock crystal appropriate to the design:  it should
be at least 25 MHz, probably less than 100Mhz for that board.  If you
need a 40 MHz clock out, perhaps pick a 40 MHz xtal.  Use the clkdll
divide to get the 10 MHz, and then you uhave the same frequencies you
first asked about.

Antonio wrote:

> Oh,
> I know of this but I was thinking that this apply only for divider
> capabilities of clkdll not also multiply. this means I've to go out
> from the FPGA with at least 100MHz, but this seems to be to much for
> the DINI board I use.
> By the way, to what is due this limitation of CLKDLL ??
>
> Antonio

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39361
Subject: Re: Announce: VHDL Simili 2.0 - Graphics, Windows, Linux, Affordable
From: "Haneef Mohammed" <haneefd@attbi.com.nospam>
Date: Thu, 07 Feb 2002 13:55:29 GMT
Links: << >>  << T >>  << A >>

"Srinivasan Venkataramanan" <srinivasan@siliconsystems.USE_REPLY_TO_ID.co.in> wrote in message news:a3t6u3$eui@news.or.intel.com...
> Simli, it compiles fine, but during simulation (VHDLE), it says
> "Unknown Fatal Error, contact Symphony EDA" (or something similar
> message). I couldn't figure out what's going wrong. Would you like to
> try it out? The example data is available at:
> http://www.estec.esa.nl/wsmwww/leon/

I will look into it right away. Thanks for the pointer.



Article: 39362
Subject: Re: MC6800 vhdl design
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 13:56:57 GMT
Links: << >>  << T >>  << A >>
There is a model for a 68HC11 out by Green Mountain at
http://www.gmvhdl.com/hc11core.html.  SInce the 'HC11 is based on the
6800, perhaps that would be a good starting point.

poste libre wrote:

> Hi,
>
> I'm currently  looking for the RTL description of the Motorola MC6800
> (VHDL) . Please contact me if you know where I can find it or if you
> know a company which could make it for me.
> Thanks,

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39363
Subject: Multiple clock domein synchronization.
From: Richard Meester <rme@quest-innovations.com>
Date: Thu, 07 Feb 2002 15:26:02 +0100
Links: << >>  << T >>  << A >>
Hello All,

Why do you typically use 2 ffflops on a source signal to synchronize
between 2 clocks with 2 different speeds. Has this to do with glitches?

Could someone perhaps point me to a website which has good information
about this topic.


Thanks,

Richard

--


Quest Innovations
tel: +31 (0) 227 604046
fax: +31 (0) 227 604053
http://www.quest-innovations.com



Article: 39364
Subject: Re: MC6800 vhdl design
From: "Paul" <nospam@nospamplease.com>
Date: Thu, 7 Feb 2002 14:34:02 -0000
Links: << >>  << T >>  << A >>
I'm not that familiar with the procesor family, but there is a synthesisable
6805 at
http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/2000_w/vhdl/6805/

not sure what its licensing is like though. You ought to do some
investigations at the college website and persuade them to get it hosted by
one of the free ip core places if they are interested.

Paul

"poste libre" <gaylord.pelletier@libertysurf.fr> wrote in message
news:3C625E13.8F93B96C@libertysurf.fr...
> Hi,
>
> I'm currently  looking for the RTL description of the Motorola MC6800
> (VHDL) . Please contact me if you know where I can find it or if you
> know a company which could make it for me.
> Thanks,
>
>



Article: 39365
Subject: Which PC for ALTERA development tools ?
From: "Stéphane" <sjulhes@free.fr>
Date: Thu, 7 Feb 2002 16:00:42 +0100
Links: << >>  << T >>  << A >>
Hello,

I'm designing with Quartus II and Modelsim using VHDL on a DELL PII 450 Mhz
with 256 Mo of RAM.
The FPGA is an ALTERA APEX 20KE400 -2X in a FC672 package.

I'm doing real time image treatment and i'm doing one frame simulation.

The simulations times ( about 20mn ) and the Quartus working times ( about
12 mn for 12% of the APEX's ressources !! ) are quite long.

I have the opportunity to buy a new PC, so what would be the best
configuration to get a faster development workstation ???

Thanks.

Stéphane.

Thales Microelectronics.



Article: 39366
Subject: Re: Adding internal JTAG chains on FPGA
From: guiducci@cern.ch (Luigi)
Date: 7 Feb 2002 07:17:43 -0800
Links: << >>  << T >>  << A >>
Ciao,
I think that AN39 describes the Boundary Scan Architecture. Ok, I need
that, but it seems ALTERA doesn't talk anywhere about what I need too,
adding 'separate' chains for user-configuration registers. I mean,
registers that the logic in the design reads to perform operations
according to configurable choices.
But I found that it is explicitly said for the XILINX VIRTEX
processor: that the Jtag port can drive up to 2 user chains displaced
into the logic blocks (while the BST chain is unchanged, it's
built-in). That's exactly what I need. Beside this, I heard another
guy who did this stuff on a xilinx device.
Did you use separate jtag chains for user-configuration-register on
some altera device? Do you know someone who did it? No problem for me
using xilinx (also because in some way there you can get more lvds I/O
than in altera) but altera's software is so easy...

thank you 
Luigi

Article: 39367
Subject: Re: Which PC for ALTERA development tools ?
From: "Paul" <nospam@nospamplease.com>
Date: Thu, 7 Feb 2002 15:41:20 -0000
Links: << >>  << T >>  << A >>
I'm using a 20KE600-1X with a 1GHz Athlon + 512Mbyte and I'm in need of an
upgrade!

Take a look at how much memory your system is using and I think you might
upgrade it.

I've got a similar thread (2/3 days ago) 'Making Altera development quicker'
with a few bits of advice.

An Athlon 1800+ plus 1Gb of RAM looks to be the most cost effective option
at the moment.
You may be able to get away with 512Mb of RAM.

FWIW I use Leonardo (Alt.Ed) for synthesis and Quartus just for P&R as
Leonardo seems better at synthesis.
I'm slowly getting used to ModelSIM.

Paul

"Stéphane" <sjulhes@free.fr> wrote in message
news:3c6297a4$0$4618$626a54ce@news.free.fr...
> Hello,
>
> I'm designing with Quartus II and Modelsim using VHDL on a DELL PII 450
Mhz
> with 256 Mo of RAM.
> The FPGA is an ALTERA APEX 20KE400 -2X in a FC672 package.
>
> I'm doing real time image treatment and i'm doing one frame simulation.
>
> The simulations times ( about 20mn ) and the Quartus working times ( about
> 12 mn for 12% of the APEX's ressources !! ) are quite long.
>
> I have the opportunity to buy a new PC, so what would be the best
> configuration to get a faster development workstation ???
>
> Thanks.
>
> Stéphane.
>
> Thales Microelectronics.
>
>



Article: 39368
Subject: Re: Pseudorandom Bitstream
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 15:46:26 GMT
Links: << >>  << T >>  << A >>
No.  The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies
of previous bits.  If you take more than 1 bit per clock from an LFSR, you lose the uniform
white properties.  Consider the 4 bit LFSR  X^3+X^2+1:

0000
0001
0011
0111
1110
1101
1011
0110
1100
1001
0010
0101
1010
0100
1000
0000

Note that only the right most bit is random, the other bits are the same as the rightmost
but delayed by 1,2 and 3 clocks.  If you use more than one bit per clock from an LFSR, you
wind up with a correlation that colors the output and destroys the uniform random
properties.  The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100
MHz, not a byte stream.  To get a random byte stream, you need to clock the LFSR 8 times
between samples so as to get new bit values (uncorrelated to any bits in previous sample)
in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz.

vt313@comsys.ntu-kpi.kiev.ua wrote:

> In the LSFR bitstream the bytes of neighboring bits,
> considered as signed vectors, are practically
> uncorrelated, and belong to the interval (-1.0 : 1.0).
> Therefore LSFR generator at 100 MHz
> provides the byte stream at 100 MHz.
>
> If you add couples of neigboring
> sampling bytes from LSFR,
> then you get the  approximation
> of the "triangle" distribution.
>
> If you want the Gaussian distribution,
> then you would add n>10 neigboring
> sampling bytes from LSFR,
> and get the rather exact approximation
> of the Gaussian distribution.
>
> Anatoli  S.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39369
Subject: Re: Which PC for ALTERA development tools ?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 15:50:55 GMT
Links: << >>  << T >>  << A >>
As much memory as you can put in it, available memory has the biggest impact on
simulation times.  Second, is high speed disk access so that when it does have
to page, it can do it quickly.  We use dual processor boxes so that we are not
left totally unproductive during long simulations or PAR runs.  The
simulation/PAR software doesn't take advantage of the second processor, but
additional tasks will not have to share processor cycles with the simulation.

"Stéphane" wrote:

> Hello,
>
> I'm designing with Quartus II and Modelsim using VHDL on a DELL PII 450 Mhz
> with 256 Mo of RAM.
> The FPGA is an ALTERA APEX 20KE400 -2X in a FC672 package.
>
> I'm doing real time image treatment and i'm doing one frame simulation.
>
> The simulations times ( about 20mn ) and the Quartus working times ( about
> 12 mn for 12% of the APEX's ressources !! ) are quite long.
>
> I have the opportunity to buy a new PC, so what would be the best
> configuration to get a faster development workstation ???
>
> Thanks.
>
> Stéphane.
>
> Thales Microelectronics.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39370
Subject: Re: Multiple clock domein synchronization.
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 15:53:57 GMT
Links: << >>  << T >>  << A >>
It is not for glitches, it is for metastability resolution.  Metastability
is a state between the legal 0 and 1 states that can be entered if the
flip-flop's data input changes right when the clock is clocking in the data
input.  See the comp.arch.fpga FAQ (http://www.fpga-faq.com/) on
metastability.

Richard Meester wrote:

> Hello All,
>
> Why do you typically use 2 ffflops on a source signal to synchronize
> between 2 clocks with 2 different speeds. Has this to do with glitches?
>
> Could someone perhaps point me to a website which has good information
> about this topic.
>
> Thanks,
>
> Richard
>
> --
>
> Quest Innovations
> tel: +31 (0) 227 604046
> fax: +31 (0) 227 604053
> http://www.quest-innovations.com

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39371
Subject: Ptractical polyphase filter question
From: dottavio@ised.it (Antonio)
Date: 7 Feb 2002 08:02:17 -0800
Links: << >>  << T >>  << A >>
Good Morning,
I would want to test a polyphase filter, it has a master clock of
40MHz and a derived clock of for example 40/6 MHz, at this reduced
rate I put inside my test vector from the pattern generator, it could
delivery this data and the associated clock, the problem is that the
clock associated with these data is different from the one that I
produce inside the FPGA starting from the 40MHz.
How I could synchronize the 2 clocks and test the circuit ??

Antonio

Article: 39372
Subject: Re: Pseudorandom Bitstream
From: vt313@comsys.ntu-kpi.kiev.ua
Date: Thu, 07 Feb 2002 18:10:03 +0200
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> No.  The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies
> of previous bits.  If you take more than 1 bit per clock from an LFSR, you lose the uniform
> white properties.  Consider the 4 bit LFSR  X^3+X^2+1:
> 
> 0000
> 0001
> 0011
> 0111
> 1110
> 1101
> 1011
> 0110
> 1100
> 1001
> 0010
> 0101
> 1010
> 0100
> 1000
> 0000
> 
> Note that only the right most bit is random, the other bits are the same as the rightmost
> but delayed by 1,2 and 3 clocks.  If you use more than one bit per clock from an LFSR, you
> wind up with a correlation that colors the output and destroys the uniform random
> properties.  The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100
> MHz, not a byte stream.  To get a random byte stream, you need to clock the LFSR 8 times
> between samples so as to get new bit values (uncorrelated to any bits in previous sample)
> in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz.
> 

You are right,
if you consider the similarity of words as the correlation.
But if you calculate
the autocorrelation function for this sequence
for the rather long period N of LSFR (but exactly N elements)
then you get 1 dirac impulse and other zeros.

Anatoli .S.

Article: 39373
Subject: Re: Looking for Free EDIF/Verilog netlist - Schematic Viewer
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Thu, 07 Feb 2002 10:26:39 -0600
Links: << >>  << T >>  << A >>
Gatevision is a schematic viewer available from EDA direct. A free
limited time is available at
http://www.edadirect.com/Product-Catalog.htm

XST writes a .ngc netlist file and you can get a gate level netlist by
running "ngdbuild" followed by "ngd2edif" commands.


-Vikram


Srinivasan Venkataramanan wrote:

> Hi All,
>        Trying to set up a simple design flow at home using FREE EDA
> tools, I tried using Webpack for synthesis, but after synthesis I
> couldn't see any schematics. I know that Webpack can write EDIF (but
> not quite sure how to do that - if someone knows please do let me
> know) or Verilog netlist as output, but is there any schematic viewer
> (free) for the same? After some web search I found one at
> http://www.e-tools.com/content/download.html (EStudiopro), but when I
> try to run the same, it says "License expired" - though the web page
> doesn't talk about any license for this particular product.
>
> Any links is greatly appreciated.
>
> TIA,
> Srinivasan
>
> --
> Srinivasan Venkataramanan
> ASIC Design Engineer
> Software & Silicon Systems India Pvt. Ltd. (An Intel company)
> Bangalore, India, Visit: http://www.simputer.org)
> "I don't Speak for Intel"


Article: 39374
Subject: Re: Which PC for ALTERA development tools ?
From: kayrock66@yahoo.com (Jay)
Date: 7 Feb 2002 09:35:27 -0800
Links: << >>  << T >>  << A >>
Wow a P2?  That's impressive.  Consider getting a machine with one of
the newer memory achitectures like DDR or Rambus.  The database that
the P&R tool is accessing is so large the processor is surely memory
bound.  A 20kE400 probably needs a Gig minimum.

As far as accellerating your sim times, consider running mini-frames
(1/4, 1/16, ...) untill you think everything is perfect, then
recompile with the full size and check.

Regards

"St?hane" <sjulhes@free.fr> wrote in message news:<3c6297a4$0$4618$626a54ce@news.free.fr>...
> Hello,
> 
> I'm designing with Quartus II and Modelsim using VHDL on a DELL PII 450 Mhz
> with 256 Mo of RAM.
> The FPGA is an ALTERA APEX 20KE400 -2X in a FC672 package.
> 
> I'm doing real time image treatment and i'm doing one frame simulation.
> 
> The simulations times ( about 20mn ) and the Quartus working times ( about
> 12 mn for 12% of the APEX's ressources !! ) are quite long.
> 
> I have the opportunity to buy a new PC, so what would be the best
> configuration to get a faster development workstation ???
> 
> Thanks.
> 
> Stéphane.
> 
> Thales Microelectronics.



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