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

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

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

Custom Search

Messages from 69900

Article: 69900
Subject: Re: XIlinx V2P7: DCM won't lock
From: "John Adair" <newsreply@loseinspace.co.uk>
Date: Mon, 24 May 2004 12:25:42 +0100
Links: << >>  << T >>  << A >>
If you want to make your logic "quiet" I would suggest using a set/reset or
clock enable as the simplest way. This isn't going to solve issues after
locking.

I might have missed it in the thread  but is your Vccaux connected in any
way to a Vcco rail ? If it isn't please ignore the following:

Statement - 2 designs that are similar at HDL level may be very different
designs after synthesis. mapping and p&r.

In terms of I/O power noise if you have not used I/O registers for all I/O
in the design then significant differences in power noise may be experienced
between 2 functional similar designs but never the less different. One line
of HDL code can in some circumstances make a large difference in actual
implementation. With non-I/O registers the effective output timing varies
widely between I/O. The main consequence of this is switching of outputs is
spread over a window of time rather than be close together. Using non-I/O
registers you can get a different I/O timing spread, and hence noise,  every
time you make a minor alteration or difference.

The good thing about spreading the switching of I/Os is that ground bounce
and other power noise effects is usually less than a design that fully uses
I/O registers.

Ok so rather than bore everyone any more I suggest that if your Vccaux is
connected to a Vcco you try and reduce noise in that Vcco.  One way to do
this is to reduce the drive on I/Os and add slew rate control. A more
extreme method is to move I/O timing by using either both edges of the clock
switching half the outputs on one edge the other half on the other edge.
This technique can be further extended using multiples of the clock with
clock enable or even phases from a DCM. Other techniques involve locking
registers in particular places of the fabric to induce different timing
between I/O. The latter is very much a last resort as timing can vary widely
between batches, temperature, voltage etc.

More simply you can also add more decoupling and separate your Vccaux from
any Vcco power rails. Not always easy in already designed and built product.


John Adair
Enterpoint Ltd. - Home of Broaddown2
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Sean Durkin" <smd@despammed.com> wrote in message
news:2h9hnfFa6a0hU1@uni-berlin.de...
> Austin Lesea schrieb:
>
> > John,
> >
> > Couldn't have said it better.
> >
> > Also, I would start a webcase with the hotline.
> OK, I'll do that. But, as I said earlier, the thing that puzzles me, is
> that input clocks, output pins etc. are all identical in both designs.
> The only difference is in design B there is some more logic added, the
> rest is the same. Obviously that affects the locking/not locking of the
> DCMs... I've experienced something similar before, when I added a
> Chipscope-Core to the design, and as long as that was connected the DCMs
> wouldn't lock either. The only solution was to use a separate DCM to
> generate a clock for Chipscope.
>
> But could the following help:
>
> Assuming that the amount of logic connected to the output of a DCM does
> matter or some nearby output pins add jitter to the input clock, could I
> use a BUFGMUX at the output of the DCMs, and use the lock-output of the
> DCM as select-signal to switch between the DCM-output and GND? That way
> I could disable all logic in the FPGA until the DCMs are locked.
>
> Until then it seems I have to configure the FPGA twice to get the design
> running.
>
> cu,
> Sean
>



Article: 69901
Subject: Re: FPGA Board with Flash Memory
From: "John Adair" <newsreply@loseinspace.co.uk>
Date: Mon, 24 May 2004 12:31:55 +0100
Links: << >>  << T >>  << A >>
We can certain meet your requirements with our new product Broaddown2. Look
here http://www.enterpoint.co.uk/moelbryn/broaddown2.html .


John Adair
Enterpoint Ltd. - Home of Broaddown2
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.
"Basuki Endah Priyanto" <EBEPriyanto@ntu.edu.sg> wrote in message
news:Z6dbuF%23PEHA.2168@exchnews1.main.ntu.edu.sg...
> Hello all,
>
> I am looking for a FPGA board (preferably: Xilinx SPARTAN 100k-300k gates)
with flash memory attached on the board itself to store the bit file.
>
> Anyone can help me or just gimme the URL ?
>
> Thanks.
>
> -Basuki-
>
>



Article: 69902
Subject: VHDL simple question: is 2-D array synthesizable
From: "Jimmy" <mljiang@eee.hku.hk>
Date: Mon, 24 May 2004 21:42:47 +0800
Links: << >>  << T >>  << A >>
Dear All,
     I need to store and process 88 data(each is 8 bits), I use two
dimensional array to define a new data type. My questions are:
    1. Is 2-D array synthesizable ?
    2. I can't use downto with 2-D array ? such as the followings, which
results in syntax error.
....
    type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0);
    singal ,ChipBuffer_I2 : ChipBuffer ;
....
     ChipBuffer_I2(87 downto  1) <= ChipBuffer_I1( 86 downto 0);

     error:  ChipBuffer_I1 can not be used with range downto;

So what can I use to replace the 2-D array in this case ,
Many thanks!

Jimmy



Article: 69903
Subject: Re: VHDL simple question: is 2-D array synthesizable
From: Nicolas Matringe <matringe.nicolas@numeri-cable.fr>
Date: Mon, 24 May 2004 15:56:59 +0200
Links: << >>  << T >>  << A >>
Jimmy a écrit:
> Dear All,
>      I need to store and process 88 data(each is 8 bits), I use two
> dimensional array to define a new data type. My questions are:
>     1. Is 2-D array synthesizable ?

Not as such, IIRC.
Note that your array is not a 2-D array but an array of arrays, which is 
synthesizable.


>     2. I can't use downto with 2-D array ? such as the followings, which
> results in syntax error.

You can but not as you did (see below)


> ....
>     type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0);
>     singal ,ChipBuffer_I2 : ChipBuffer ;
> ....
>      ChipBuffer_I2(87 downto  1) <= ChipBuffer_I1( 86 downto 0);
> 
>      error:  ChipBuffer_I1 can not be used with range downto;

You declared ChipBuffer type with ascending range, you must use an 
ascending range when using signals of type ChipBuffer:
ChipBuffer_I2(1 to 87) <= ChipBuffer_I1(0 to 86);

-- 
  ____  _  __  ___
|  _  \_)/ _|/ _ \   Adresse de retour invalide: retirez le -
| | | | | (_| |_| |  Invalid return address: remove the -
|_| |_|_|\__|\___/


Article: 69904
Subject: Re: Never right, always room for improvement
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 24 May 2004 07:21:00 -0700
Links: << >>  << T >>  << A >>
Peter,

I was referring to hard IP uP, not soft cores.

Austin

Peter Sommerfeld wrote:
> Multiple embedded processors?
> 
> I built a Stratix design with 6 Nios' on it a long time ago. The
> design from start to finish took less than half a day. Could have been
> more if I had the space on the FPGA.
> 
> -- Pete
> 
> 
>>Processors, plural.
>>
>>I'm still right.
>>
>>Austin
>>

Article: 69905
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 24 May 2004 07:25:34 -0700
Links: << >>  << T >>  << A >>
Allan,

Any suggestions made here are taken seriously by me (at least) and 
passed along to the ICDES group.

The fact that it can be done in the fabric means that it isn't critical, 
but when we go and poll customers, we may find it is common IP that is 
similar to all.  In that case, the 'Virtex Vortex' takes over, and it 
gets sucked into the chip (like many other good ideas).

Austin

Allan Herriman wrote:

> On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com>
> wrote:
> 
> 
>>Allan,
>>
>>Good suggestion.
>>
>>Timely too.
>>
>>Thanks,
>>
>>Austin
> 
> 
> 
> Hi Austin,
> 
> Are you hinting that this feature may be added in future silicon?
> 
> Regards,
> Allan.
> 
> 
> 
> 
>>Allan Herriman wrote:
>>
>>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com>
>>>wrote:
>>>
>>>
>>>
>>>>Sean,
>>>>
>>>>Brute force!
>>>>
>>>>As long as the locked signal is low, periodically reset the DCM, and see 
>>>>if the locked signal remains low.
>>>>
>>>>It takes a little state machine, and it would have to run off the DCM 
>>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
>>>>many counts you need to wait to make sure that LOCKED has gone high).
>>>>
>>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
>>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
>>>>the DCM).
>>>>
>>>>(pseudo code below)
>>>>
>>>>while CLKIN_STOPPED = 1 (clock is running)
>>>>
>>>>    assert (reset for one clock)
>>>>    wait XX uSec
>>>>
>>>>    check DCM:  DCM not operating? (check approp. status)
>>>>                     assert reset (for one clock)
>>>>                     wait XX uSec
>>>>                else do nothing
>>>>
>>>>    wait XX uSec (use one counter for all waits)
>>>>
>>>>    go to check DCM
>>>
>>>
>>>Hi Austin,
>>>
>>>Is there any fundamental reason why this logic couldn't be built into
>>>the DCM and be enabled/disabled by a config bit?
>>>
>>>The "wait XX usec" might be a problem, but this could by worked around
>>>in a number of ways (e.g. by using psclk as a timing reference, etc.)
>>>
>>>I find that having to add this state machine to all DCMs just to get
>>>them to work reliably is a bit of a pain.
>>>
>>>Regards,
>>>Allan.

Article: 69906
Subject: Re: VHDL simple question: is 2-D array synthesizable
From: "Jimmy" <mljiang@eee.hku.hk>
Date: Mon, 24 May 2004 22:37:26 +0800
Links: << >>  << T >>  << A >>
Thanks a million to Nicolas Matringe !!!, solve the problem according to
your suggestion :-) ,
Jimmy,

"Nicolas Matringe" <matringe.nicolas@numeri-cable.fr> wrote in message
news:40B1FF2B.3090702@numeri-cable.fr...
> Jimmy a écrit:
> > Dear All,
> >      I need to store and process 88 data(each is 8 bits), I use two
> > dimensional array to define a new data type. My questions are:
> >     1. Is 2-D array synthesizable ?
>
> Not as such, IIRC.
> Note that your array is not a 2-D array but an array of arrays, which is
> synthesizable.
>
>
> >     2. I can't use downto with 2-D array ? such as the followings, which
> > results in syntax error.
>
> You can but not as you did (see below)
>
>
> > ....
> >     type ChipBuffer is array (0 to 87) of std_logic_vector(7 downto 0);
> >     singal ,ChipBuffer_I2 : ChipBuffer ;
> > ....
> >      ChipBuffer_I2(87 downto  1) <= ChipBuffer_I1( 86 downto 0);
> >
> >      error:  ChipBuffer_I1 can not be used with range downto;
>
> You declared ChipBuffer type with ascending range, you must use an
> ascending range when using signals of type ChipBuffer:
> ChipBuffer_I2(1 to 87) <= ChipBuffer_I1(0 to 86);
>
> -- 
>   ____  _  __  ___
> |  _  \_)/ _|/ _ \   Adresse de retour invalide: retirez le -
> | | | | | (_| |_| |  Invalid return address: remove the -
> |_| |_|_|\__|\___/
>



Article: 69907
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 25 May 2004 01:05:49 +1000
Links: << >>  << T >>  << A >>
On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>Allan,
>
>Any suggestions made here are taken seriously by me (at least) and 
>passed along to the ICDES group.

Good.  The "auto-DCM-relocker" will need the following features (at
least):

1.  Auto-relock feature can be disabled by a config bit, which allows
"good 'ol mode" to be emulated.  Auto-relock will be off by default.

2.  There needs to be a new status bit which indicates that the
auto-relock feature has been active (to aid fault finding, etc.).
This bit would be reset by a) config and b) user reset of DCM.


How would you expect to implement the "wait XX uSec" part of the
design?  Every FPGA design I've ever done has had a reliable (i.e. not
via a DLL, PLL or DCM) clock somewhere in the range 2MHz to 50MHz.
Such a clock could be connected to the PSCLK input of the DCM (or
perhaps a new input?) and there would be a new DCM attribute to
indicate the freq / period of this clock.
Or maybe you can do it with analog delays on the chip (?)

Regards,
Allan.

>
>The fact that it can be done in the fabric means that it isn't critical, 
>but when we go and poll customers, we may find it is common IP that is 
>similar to all.  In that case, the 'Virtex Vortex' takes over, and it 
>gets sucked into the chip (like many other good ideas).
>
>Austin
>
>Allan Herriman wrote:
>
>> On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com>
>> wrote:
>> 
>> 
>>>Allan,
>>>
>>>Good suggestion.
>>>
>>>Timely too.
>>>
>>>Thanks,
>>>
>>>Austin
>> 
>> 
>> 
>> Hi Austin,
>> 
>> Are you hinting that this feature may be added in future silicon?
>> 
>> Regards,
>> Allan.
>> 
>> 
>> 
>> 
>>>Allan Herriman wrote:
>>>
>>>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com>
>>>>wrote:
>>>>
>>>>
>>>>
>>>>>Sean,
>>>>>
>>>>>Brute force!
>>>>>
>>>>>As long as the locked signal is low, periodically reset the DCM, and see 
>>>>>if the locked signal remains low.
>>>>>
>>>>>It takes a little state machine, and it would have to run off the DCM 
>>>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
>>>>>many counts you need to wait to make sure that LOCKED has gone high).
>>>>>
>>>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
>>>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
>>>>>the DCM).
>>>>>
>>>>>(pseudo code below)
>>>>>
>>>>>while CLKIN_STOPPED = 1 (clock is running)
>>>>>
>>>>>    assert (reset for one clock)
>>>>>    wait XX uSec
>>>>>
>>>>>    check DCM:  DCM not operating? (check approp. status)
>>>>>                     assert reset (for one clock)
>>>>>                     wait XX uSec
>>>>>                else do nothing
>>>>>
>>>>>    wait XX uSec (use one counter for all waits)
>>>>>
>>>>>    go to check DCM
>>>>
>>>>
>>>>Hi Austin,
>>>>
>>>>Is there any fundamental reason why this logic couldn't be built into
>>>>the DCM and be enabled/disabled by a config bit?
>>>>
>>>>The "wait XX usec" might be a problem, but this could by worked around
>>>>in a number of ways (e.g. by using psclk as a timing reference, etc.)
>>>>
>>>>I find that having to add this state machine to all DCMs just to get
>>>>them to work reliably is a bit of a pain.
>>>>
>>>>Regards,
>>>>Allan.


Article: 69908
Subject: Re: XIlinx V2P7: DCM won't lock
From: Sean Durkin <smd@despammed.com>
Date: Mon, 24 May 2004 17:18:44 +0200
Links: << >>  << T >>  << A >>
John Adair wrote:

> If you want to make your logic "quiet" I would suggest using a set/reset or
> clock enable as the simplest way. This isn't going to solve issues after
> locking.
I don't have any issues after locking, my problem is the DCMs not 
locking in the first place. After they've locked, everything works fine, 
the output clock is as perfect as it gets coming from a DCM, and they 
never lose lock again.
The entire design is kept in reset until all DCMs have locked. In one 
variant the design will never come out of reset, since the DCMs never 
lock, even though at that particular time no outputs are active at all, 
or at least they shouldn't be switching; so there should be no power 
noise added from switching I/Os as far as I understand it...

> I might have missed it in the thread  but is your Vccaux connected in any
> way to a Vcco rail ? If it isn't please ignore the following:
It is, but this is more or less a finished product and I can't do 
anything about it now. But I'll keep that in mind for future designs.

> Statement - 2 designs that are similar at HDL level may be very different
> designs after synthesis. mapping and p&r.
Yes, that's right, the whole design flow seems rather "chaotic" :)

cu,
Sean

Article: 69909
Subject: How to convert a pattern to SVF
From: stevels70@yahoo.com (Ste)
Date: 24 May 2004 08:22:08 -0700
Links: << >>  << T >>  << A >>
Hi all,

I have some test programs for a device that have been developed inside
a verilog testbench; the result of the simulation is an EVCD file that
I am able to convert to WGL and ASC.

The issue is that I need to get a SVF version of it...

Does anybody knows of a tool that can convert my EVCD or WGL or ASC
stimuli to SVF?

Thanks & Regards,

Steve

Article: 69910
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 24 May 2004 08:40:03 -0700
Links: << >>  << T >>  << A >>
Allan,

I will let the ICDES folks solve the problems.  It is enough that we 
specify the feature!

Since the DCM is entirely digital (state machines and delay lines), it 
is pretty trivial to see if the states are progressing, stuck, or not valid.

Austin

Allan Herriman wrote:
> On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com>
> wrote:
> 
> 
>>Allan,
>>
>>Any suggestions made here are taken seriously by me (at least) and 
>>passed along to the ICDES group.
> 
> 
> Good.  The "auto-DCM-relocker" will need the following features (at
> least):
> 
> 1.  Auto-relock feature can be disabled by a config bit, which allows
> "good 'ol mode" to be emulated.  Auto-relock will be off by default.
> 
> 2.  There needs to be a new status bit which indicates that the
> auto-relock feature has been active (to aid fault finding, etc.).
> This bit would be reset by a) config and b) user reset of DCM.
> 
> 
> How would you expect to implement the "wait XX uSec" part of the
> design?  Every FPGA design I've ever done has had a reliable (i.e. not
> via a DLL, PLL or DCM) clock somewhere in the range 2MHz to 50MHz.
> Such a clock could be connected to the PSCLK input of the DCM (or
> perhaps a new input?) and there would be a new DCM attribute to
> indicate the freq / period of this clock.
> Or maybe you can do it with analog delays on the chip (?)
> 
> Regards,
> Allan.
> 
> 
>>The fact that it can be done in the fabric means that it isn't critical, 
>>but when we go and poll customers, we may find it is common IP that is 
>>similar to all.  In that case, the 'Virtex Vortex' takes over, and it 
>>gets sucked into the chip (like many other good ideas).
>>
>>Austin
>>
>>Allan Herriman wrote:
>>
>>
>>>On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com>
>>>wrote:
>>>
>>>
>>>
>>>>Allan,
>>>>
>>>>Good suggestion.
>>>>
>>>>Timely too.
>>>>
>>>>Thanks,
>>>>
>>>>Austin
>>>
>>>
>>>
>>>Hi Austin,
>>>
>>>Are you hinting that this feature may be added in future silicon?
>>>
>>>Regards,
>>>Allan.
>>>
>>>
>>>
>>>
>>>
>>>>Allan Herriman wrote:
>>>>
>>>>
>>>>>On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com>
>>>>>wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Sean,
>>>>>>
>>>>>>Brute force!
>>>>>>
>>>>>>As long as the locked signal is low, periodically reset the DCM, and see 
>>>>>>if the locked signal remains low.
>>>>>>
>>>>>>It takes a little state machine, and it would have to run off the DCM 
>>>>>>CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
>>>>>>many counts you need to wait to make sure that LOCKED has gone high).
>>>>>>
>>>>>>Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
>>>>>>use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
>>>>>>the DCM).
>>>>>>
>>>>>>(pseudo code below)
>>>>>>
>>>>>>while CLKIN_STOPPED = 1 (clock is running)
>>>>>>
>>>>>>   assert (reset for one clock)
>>>>>>   wait XX uSec
>>>>>>
>>>>>>   check DCM:  DCM not operating? (check approp. status)
>>>>>>                    assert reset (for one clock)
>>>>>>                    wait XX uSec
>>>>>>               else do nothing
>>>>>>
>>>>>>   wait XX uSec (use one counter for all waits)
>>>>>>
>>>>>>   go to check DCM
>>>>>
>>>>>
>>>>>Hi Austin,
>>>>>
>>>>>Is there any fundamental reason why this logic couldn't be built into
>>>>>the DCM and be enabled/disabled by a config bit?
>>>>>
>>>>>The "wait XX usec" might be a problem, but this could by worked around
>>>>>in a number of ways (e.g. by using psclk as a timing reference, etc.)
>>>>>
>>>>>I find that having to add this state machine to all DCMs just to get
>>>>>them to work reliably is a bit of a pain.
>>>>>
>>>>>Regards,
>>>>>Allan.
> 
> 

Article: 69911
Subject: Re: XIlinx V2P7: DCM won't lock
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 24 May 2004 08:43:43 -0700
Links: << >>  << T >>  << A >>
Sean,

One issue with the DCM's is that they need the CLKFB input stable when 
they start if they are to lock.

A common problem is that the CLKIN, or the CLKFB (or both) are not 
stable when DONE goes high, so the DCM fails to lock.  A subsequent 
reset usually solves this problem.

Again, it sounds like you should send this to the hotline, as they are 
well versed in getting to the root of these issues,

Austin

Sean Durkin wrote:

> John Adair wrote:
> 
>> If you want to make your logic "quiet" I would suggest using a 
>> set/reset or
>> clock enable as the simplest way. This isn't going to solve issues after
>> locking.
> 
> I don't have any issues after locking, my problem is the DCMs not 
> locking in the first place. After they've locked, everything works fine, 
> the output clock is as perfect as it gets coming from a DCM, and they 
> never lose lock again.
> The entire design is kept in reset until all DCMs have locked. In one 
> variant the design will never come out of reset, since the DCMs never 
> lock, even though at that particular time no outputs are active at all, 
> or at least they shouldn't be switching; so there should be no power 
> noise added from switching I/Os as far as I understand it...
> 
>> I might have missed it in the thread  but is your Vccaux connected in any
>> way to a Vcco rail ? If it isn't please ignore the following:
> 
> It is, but this is more or less a finished product and I can't do 
> anything about it now. But I'll keep that in mind for future designs.
> 
>> Statement - 2 designs that are similar at HDL level may be very different
>> designs after synthesis. mapping and p&r.
> 
> Yes, that's right, the whole design flow seems rather "chaotic" :)
> 
> cu,
> Sean

Article: 69912
Subject: Re: Very Big numbers
From: "Vincent Diepeveen" <diep@xs4all.nl>
Date: Mon, 24 May 2004 17:00:31 +0100
Links: << >>  << T >>  << A >>

"ds" <nospam@thankyou.nl> wrote in message
news:40292c93$0$32739$4a441750@news.euronet.nl...
> Sometimes you need a quick routine, or a routine that uses encryption.


> Sometimes you need a simple multiplication of Big numbers...

> If so, we would like to know we developed a collection
> of functions (library, dll) for working with real big numbers and all
that.
> (...numbers bigger than the normal data types a programmer can handle.)
>
> It was made for Visual Basic, but can be used in
> any language that can invoke a .DLL (such as C++, VBA in Excel, Access or
> whatever)
>
> It's the only DLL available for Windows for UNLIMITED BIG NUMBERS with
> functions such as: +/-* Power2, Power10, MOD DIVIDE, ISPRIME, COMPARE, Xor

exponent squaring?

> etc...
>
> Calculations are sometimes even faster than you are used to,
> cause everything was made in assembly.

For which cpu's have you been optimizing?

% and /  are very slow operations at most cpu's.

64 bits?

> It's shareware and it is online on http://www.big-numbers.com
> David




Article: 69913
Subject: Re: Very Big numbers
From: "Vincent Diepeveen" <diep@xs4all.nl>
Date: Mon, 24 May 2004 17:02:05 +0100
Links: << >>  << T >>  << A >>
The only interesting thing is whether your library is faster at x86-64 than
the GNU tools. The rest doesn't count.


"ds" <nospam@thankyou.nl> wrote in message
news:40294431$0$98746$d5255a0c@news.wanadoo.nl...
> Oh, can it also be used in Visual Basic? On a Win 98 machine ?
> Can it also find all 100% proven Prime Numbers?
> Can it also find RSA-factors ?...
> Does it include encryption modules?
>
> Oh....
> ---
> Just restoring balance...
>
> David
>
> "Marius Vollmer" <marius.vollmer@uni-dortmund.de> schreef in bericht
> news:ljr7x2brup.fsf@troy.dt.e-technik.uni-dortmund.de...
> > "ds" <nospam@thankyou.nl> writes:
> >
> > > It's the only DLL available for Windows for UNLIMITED BIG NUMBERS with
> > > functions such as: +/-* Power2, Power10, MOD DIVIDE, ISPRIME, COMPARE,
> Xor
> > > etc...
> >
> > To restore balance to the force, I'd ike to mention GNU MP:
> >
> >     http://www.gnu.org/software/gmp
> >
> > which has most if not all of the features of the above DLL and is Free
> > Software (i.e., comes with full source code).
>
>



Article: 69914
Subject: Re: NIOS Board Stratix Edition - FPGA won't configure
From: kempaj@yahoo.com (Jesse Kempa)
Date: 24 May 2004 10:06:48 -0700
Links: << >>  << T >>  << A >>
vbishtei@hotmail.com (vadim) wrote in message news:<2a613f5d.0405231856.56b8c5ae@posting.google.com>...
> I was fully aware that the MAX CPLD was programming the Stratix
> device. We tried
> to find the pin that is connected to the MAX CPLD and program it to be
> tied to VCC (reconfig_req_n). This failed. 
> I was not aware there was a software setting inside Quartus to
> Tri-State unused pins, which only found through this newsgroup (thing
> like this should appear
> on the front pages of the NIOS Board manual). 
> 
> Generally, from working and learning Altera devices and software a
> pattern seems to emerge - bad and ambiguous documentation. Huge and
> wordy documents
> that don't state the "beef" but tend to repeat things without much
> elaboration.
> This reminded me of learning Cadence software...
> 

Hi Vadim,

I'm sorry that this problem caused you any trouble. With regards to
documentation, I think a lot of people feel the same way. The
unfortunate thing is that some readers need a lot of hand-holding when
getting started with a new tool, while some prefer the 'beef' as you
mention (I personally prefer the no-nonsense brief approach myself). I
think an ideal solution would be to have the verbose, and then
ultra-brief versions of select documents. This is, of course, very
difficult when shipping a product as the documentation tends to
require a completed product from the engineering standpoint and it's a
real rush to get all the docs done correctly when the product is
nearly ready to go.

Anyways, about this issue specifically: There is now a warning that is
called out of regular text (i.e., not just a paragraph) in the Nios II
HW development tutorial that tells the reader to change this setting
before starting Quartus compilation. The revised tutorial is up on our
web site and will ship on the Nios II CDs shortly.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 69915
Subject: Re: Transputer on FPGA
From: johnjakson@yahoo.com (john jakson)
Date: 24 May 2004 10:28:06 -0700
Links: << >>  << T >>  << A >>
albert@spenarnc.xs4all.nl (Albert van der Horst) wrote in message news:<Hy5wHL.1nz.1.spenarn@spenarnc.xs4all.nl>...
> In article <adb3971c.0405222015.4821eb9@posting.google.com>,
> john jakson <johnjakson@yahoo.com> wrote:
> 
> <SNIP>
> >I just realised, you probably don't need to look at the Transputer
> >because it has no sp type stack that you'd need for Forth, Pascal, C
> >etc. It does have a HW stack for eval expressions just like a HP RPN
> >calc but it is only 3 reg deep and tied into the scheduler for
> >switching processes when its empty IIRC..
> 
> It is not the stack (or a stack). These are registers at the lowest
> level, almost a RISC way to write microcode explicitly.
> The register at the next to lowest level are 16, and you can add two
> registers and put it back in a third by 3 single byte instructions.
> You can use a couple of those for stack pointers, without exhausting
> resources, like in a Pentium.
> 
> <SNIP>
> >
> >A google for Transputer & Forth should draw a blank I'd guess but I
> >could be wrong.
> 
> Of course you are wrong.
> You should know by now, that there is a Forth for every processor
> that is over 6 month old.
> 

Ofcourse I checked on the next line before signing off, and saw tforth and others

> tforth is the precursor is iforth, and it is still available from DFW.
> It is a solid piece of work, if I may say so myself.
> There are more.
> 
> >Yes it does look like they did it, well I wonder what they did?
> >
> >regards
> >
> >johnjakson_usa_com

Article: 69916
Subject: Re: How to select an FPGA size (beginner)
From: thangkho <>
Date: Mon, 24 May 2004 10:35:00 -0700
Links: << >>  << T >>  << A >>
A wild guest, it would well fit in spartan2 100 :)


Article: 69917
Subject: Re: Never right, always room for improvement
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 24 May 2004 19:06:26 +0100
Links: << >>  << T >>  << A >>
Jesse Kempa wrote:

> As an example, the user can debug many (we have tested up to
> 8) processorS (plural) simultaneously via a single JTAG connection and
> a nice IDE environment.

This is where we are today, but it just doesn't play to the strength of
an FPGA.  It's a bit like having one (or 8) block RAM.  The FPGA really
gets rolling when we can make parallel use of a shed-load of resources.
Just as nothing can beat the bandwidth of a big FPGA with all the block
RAMs going in parallel, nothing will be able to touch an FPGA with lots
of application-tailored CPUs.

Not great for evaluating spreadsheets, but pretty good in other domains.

I once had a project (paper only) where each processor's instruction
stream was scanned for the opcodes used, then the corresponding FPGA
processor implementation was modified to match the usage.



Article: 69918
Subject: I have problem with readback for virtex2
From: weimingxx@hotmail.com (wei ming)
Date: 24 May 2004 11:50:16 -0700
Links: << >>  << T >>  << A >>
Now I am doing Xilinx Virtex2 (xc2v1000)  readback to capture register
status. I have done C++ code for this, but it doesn't work at all.
After I send the CFG_IN(000101) instruction, the command is following:

aa995566h(sync word);
30002001h(write to FAR register);
Frameaddr(from the .ll file);
30008001h(write to CMD register);
00000004h(RCFG);
280060d4h(Number of word to readback)(3392 Bit/Frame 106x 32 for
xc2v1000.   212(d4h)x32)
00000000h;flush the command pipeline.
00000000h;flush the command pipeline.(64 Bit register)

I think, the virtex2 is same with virtex. The value for one frame
readback word is 2 times the Frame Bit. The first 3392 Bit is pad
frame. then is CLB frame.

then after the CFG_OUT(000100) instruction, ignore the first 3392 bit,
after that readback from TDO when offset (from .ll file) plus 32(pad
word). I instantiated the capture_virtex2. So I don't know how to do
it. Have anyone idea to do it? Any informtion is welcome. Thanks in
advance.

Article: 69919
Subject: Re: Never right, always room for improvement
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 24 May 2004 20:02:36 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <c8tdmh$8o2$1$8300dec7@news.demon.co.uk>,
Tim <tim@rockylogic.com.nooospam.com> wrote:
>Jesse Kempa wrote:
>
>> As an example, the user can debug many (we have tested up to
>> 8) processorS (plural) simultaneously via a single JTAG connection and
>> a nice IDE environment.
>
>This is where we are today, but it just doesn't play to the strength of
>an FPGA.  It's a bit like having one (or 8) block RAM.  The FPGA really
>gets rolling when we can make parallel use of a shed-load of resources.
>Just as nothing can beat the bandwidth of a big FPGA with all the block
>RAMs going in parallel, nothing will be able to touch an FPGA with lots
>of application-tailored CPUs.
>
>Not great for evaluating spreadsheets, but pretty good in other domains.

Surely spreadsheets are pretty much infinitely parallel once you've
spread up the dependency graph for the cells among the various
processors ... word processing is the bit I have more trouble thinking
how to divide among a myriad processors, not that anyone types fast
enough for that to matter :)

Tom

Article: 69920
Subject: Re: The fastest interface between FPGA's
From: Luc Braeckman <luc.braeckman@pandora.be>
Date: Mon, 24 May 2004 19:20:03 GMT
Links: << >>  << T >>  << A >>
I fully agree with Ray.
When it comes to high bandwidth bidir communication, your only cost
effective solution is serial io.
3 to 5 cm is not a big distance, but be aware at 2.5Gbps and above,
PCB design is not very straight forward. Differences in trace length,
cross-over distortion, etc. are things that you will have to deal
with. Robustness of the serdes, easy of programming, jitter tolerance,
... are very important.

Regards
On Thu, 05 Feb 2004 08:15:07 -0500, Ray Andraka <ray@andraka.com>
wrote:

>From a cost standpoint, that is not always true.  Also, if you have a
>memory intensive application, you get more memory by using two smaller
>devices (say XC2V3000's) instead of one larger one (eg XC2V6000).  If
>you have the luxury of using a chip with the high speed serial i/o,
>that will give you rather high bandwidth connections without using up
>many pins.  Otherwise, you need to refer to the data sheets for each of
>the i/o standards supported to see the speeds and what is required to
>make it work.  Some of the lower voltage swings are faster, but have
>special voltage requirements you may not be able to meet.  LVDS is
>generally faster, at least on longer runs.  You may need external
>terminators as well, as IIRC, invoking the DCI has a substantial speed
>penalty.
>
>Uwe Bonnes wrote:
>
>> Griva <griva@poczta.onet.pl> wrote:
>> : Hi,
>>
>> : I'm looking for the fastest interface/standard between two FPGAs.
>> : Have You got any suggestions?
>>
>> It depends on reuirements:
>> - Uni/Bidirectional
>> - Distance between chips
>> - Number of connections allowed
>> ...
>>
>> I think that nearly always it is best to get a bigger FPGA and put
>> everything into one package.
>>
>> Bye
>> --
>> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>>
>> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 69921
Subject: NGDBUILD warnings...please help
From: srkumar26@hotmail.com (kumar)
Date: 24 May 2004 12:31:18 -0700
Links: << >>  << T >>  << A >>
hello guys,
I am  working on a verilog design. But the top level module is written
in handel-C.
First i synthesised the verilog design with the synthesis option 'Add
I/O buffers' unchecked. it generated .ngc file. the synthesis report
showed that the design used some 280 slices of the device considered.

Next while running NGDBUILD for the top level module, i used the ngc
file generated, as it has to merge the two source files and create a
single file.
But while i am doing this i am getting several warnings as:

WARNING:NgdBuild:454 - logical net 'W168_send_protocol_56_main' has no
load
WARNING:NgdBuild:454 - logical net 'W169_send_protocol_56_main' has no
load
WARNING:NgdBuild:454 - logical net 'W170_send_protocol_56_main' has no
load
WARNING:NgdBuild:454 - logical net 'W171_send_protocol_56_main' has no
load
WARNING:NgdBuild:454 - logical net 'W172_send_protocol_56_main' has no
load
...

send_protocol is the top level design name.

And the synthesis report shows that the design uses only 324 slices. i
dont understand what the problem is.
could anyone please help me.

thanks,
kumar

Article: 69922
Subject: Re: DLL - Change in input frequency (CLKIN) ---help needed
From: rajes_kumar@yahoo.com (Rajesh Murugesan)
Date: 24 May 2004 12:43:52 -0700
Links: << >>  << T >>  << A >>
td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0405181256.7895fada@posting.google.com>...

> I have the same requirement and have successfully generated a reset
> signal for the CLKDLL, so I know it can be done. It looks something
> like this:
> 
> dll : CLKDLL port map ( 
>   CLKIN => clk,
>   CLKFB => clkfb,
>   RST => dll_reset,
>   etc.
>   );
> 
> dll_reset <= error1 OR error2; -- error1, error2 generated by internal
> logic
> 
> Good luck!
> -td

Hi

Thanks a lot.. I tried to generate a reset signal for the DLL from the
above mentioned logic and I found the same errors as it was before.

I guess its not because of the bad logic and I am not sure whether the
rest of the design (apart from the using DLL) has logical errors. I
have been using Xilinx ISE 6.2i and the service pack of the current
version is updated as well.

Also. I have gotten new warnings...

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

Checking timing specifications ...
Checking expanded design ...
WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted
value for
   attribute "IOSTANDARD" on "Clock_x4_rstpad".
WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted
value for
   attribute "IOSTANDARD" on "mod_clk_x2_rstpad".
WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted
value for
   attribute "IOSTANDARD" on "Clock_x4_clkpad".
WARNING:NgdBuild:488 - Attribute value "LVCMOS25" is not an accepted
value for
   attribute "IOSTANDARD" on "mod_clk_x2_clk40_pad".

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

The error list also denote me that the reset signal has illegal
connection and in the .ngr file, I see the illegal connection that I
havent mentioned in the design.

Eagerly waiting for ur suggestions...

Thanks in advance..

grüss

Rajesh

Article: 69923
Subject: Nios II = Microblaze
From: seannstifler69@hotmail.com (Stifler)
Date: 24 May 2004 13:56:28 -0700
Links: << >>  << T >>  << A >>
Altera finally wakes up. They realize that the window register type
architecture is not good for FPGAs and probably in general. They can
no longer support their own marketing hype about how great Nios I is.
If Nios 1 was so great, why did it need a complete redesign and
rearchitecture? It means it was poor. That's the only reason you do a
complete redesign. I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.

They copy the Xilinx Microblaze style implementation. To me it shows
who knows what about designing and running a soft processor in an
FPGA. Enough said.

They throw all the current Nios customers under the bus. Requires
publishing a 38 page app note to switch a Nios 1 to Nios II design.
Current Nios users, I feel sorry for you. Be careful and do your back
ups!

Article: 69924
Subject: HSTL and Virtex 2
From: adamsmithece@yahoo.com (A_Smith)
Date: 24 May 2004 14:17:02 -0700
Links: << >>  << T >>  << A >>
Does anybody out there have a working design using a virtex 2 with an
"FG" package type and HSTL signals?  Currently I have a design with an
HSTL clock coming from the fpga to a self-terminating Samsung QDR
memory. I am having major problems getting it to work.  As I increase
the frequency the amplitude of the signal decreases.  At 25 MHz I get
a 1.4 V signal, and at 100 MHz I get a 200 mV signal.  The memory does
not even work until a clock speed of 130 MHz can be reached.

I am aware of designs using a virtex 2 with an "FF" package type.  I
don't want to go into detail but I have performed several tests and am
suspecting there is something wrong with the virtex 2 "FG" package
type and HSTL signals.  If anybody out there can tell me they have
something working it would tell me that I am wrong and it is something
else.  Please only reply if you have an actual working board or if you
have also failed to make a "FG" virtex 2 part work.


Here is some information on the traces,

It is a point to point connection
less than 3/4 of an inch
the line impedence was measured with TDR and it is between 50 and 53
ohms



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

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

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

Custom Search