1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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 22000

Article: 22000
Subject: Is there any DSP and FPGA based board suitable to motor drive control?
From: "Jack D. Ma" <jma@ee.ryerson.ca>
Date: Tue, 11 Apr 2000 14:08:35 -0400
Links: << >>  << T >>  << A >>
Hi, friends,

Does anyone know is there any commercial DSP and FPGA based general
purpose control board suitable to motor drive control? FPGA takes care
of the A/D, D/A and gating and DSP takes care of the calculation part.

Thanks

Jack

Article: 22001
Subject: Re: Specifying PCI buffer for Xilinx 4000XLA
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Tue, 11 Apr 2000 16:04:37 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------52C692F9DB6146CF0CAA6CA1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Abhijit,

Thanks for the info.  One more question though.

What about the clamp diode?  The 3.3v PCI buffer is supposed to have a clamp
diode and the 5v PCI buffer cannot.  Do we have to specify this somewhere as
well or will the tools know to put a clamp on the input if it is 12ma
(3.3vPCI) and not if it is 24ma (5v PCI).
Tom

Abhijit Athavale wrote:

> Tom,
>
> It is as easy as that. Set the PCI outputs to FAST slew rate and set
> DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular
> XLA buffers are PCI compliant.
>
> Tom McLaughlin wrote:
>
> > All,
> > We know how to specify PCI buffers in Virtex and Virtex E.  We put the
> > statement:
> >
> > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value
> > OBUF_PCI33_3
> >
> > in the synthesis script and it passes the attribute to the backend.
> >
> > The problem is that we want to use a PCI compliant buffer on an XLA
> > part.  The docs say that it supports it, but we cannot figure out how to
> > implement it.  To check if the architecture does support it, I pulled up
> > the constraints editor after choosing an XLA part.  When I click on I/O
> > standards, I only have the option to set drive strength, slew rate, but
> > not the I/O standard.  If you do this with a Virtex part, a new column
> > appears called "I/O standards" which has all the I/O options, LVTTL,
> > SSTL, PCI etc.
> >
> > The libraries guide on the Xilinx web site does not show support for XLA
> > that we can find.  We tried using the above statement for the XLA
> > architecture, but it is not valid.
> >
> > The datasheet goes to great lengths to say the XLA has these PCI
> > compiant buffers, but does not say how to implement them.  Please
> > help!!!  Do we just implement LVTTL buffers with 12ma of drive strength
> > and that is PCI compliant....it can't be that easy.....???
> >
> > BTW, we are using Alliance 2.1i.
> >
> > Tom

--------------52C692F9DB6146CF0CAA6CA1
Content-Type: text/x-vcard; charset=us-ascii;
name="tomm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom McLaughlin
Content-Disposition: attachment;
filename="tomm.vcf"

begin:vcard
n:McLaughlin;Tom
tel;fax:314-935-7302
tel;work:314-935-7198
x-mozilla-html:FALSE
url:http://www.arl.wustl.edu/~tomm
org:Washington University;Applied Research Lab
version:2.1
email;internet:tomm@arl.wustl.edu
title:Research Associate
adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA
x-mozilla-cpt:;0
fn:Tom McLaughlin
end:vcard

--------------52C692F9DB6146CF0CAA6CA1--


Article: 22002
Subject: Re: Is there any DSP and FPGA based board suitable to motor drive
From: Ray Andraka <randraka@ids.net>
Date: Tue, 11 Apr 2000 21:07:17 GMT
Links: << >>  << T >>  << A >>
FPGAs don't have built in ADCs or DACs, although you can get at DAC
through pulse width modulation for lower frequency outputs.  If you are
using an FPGA for the motor drive controller, you can also do the PID or
other control fucntion in the FPGA and eliminate the processor, or
conversely, if the DSP already has enough umph to handle the calculation
part, it should be able to handle the gating, and might even have a built

"Jack D. Ma" wrote:

> Hi, friends,
>
> Does anyone know is there any commercial DSP and FPGA based general
> purpose control board suitable to motor drive control? FPGA takes care
> of the A/D, D/A and gating and DSP takes care of the calculation part.
>
> Thanks
>
> Jack

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 22003
Subject: Re: Clock Dividers
From: Ray Andraka <randraka@ids.net>
Date: Tue, 11 Apr 2000 21:32:37 GMT
Links: << >>  << T >>  << A >>
Use a DDFS.  The jitter will be a maximum of one cycle of the 77.76 MHz clock.
The frequency accuracy depends on the number of bits.  Basically this is an
accumulator clocked at the 77.76 MHz, to which a constant increment is added so
that the accumulator overflows once per 1.544MHz cycle.  The digital output,
assuming tht is what you are looking for, is the msb of the accumulator.  If you
need a different wave shape, the msbs of the accumulator can drive a look up or
other waveshape converter (the upper bits represent phase as a fractional
revolution).

For example, if you use a 12 bit accumulator,   an increment value of 81 gives
an output frequency of  1.5377MHz.  More bits will get better frequency
resolution.  You could get real close with a 12 bit accumulator if you modulate
the increment so it is 81 for 2 clocks and 82 for the 3rd.

Xanatos wrote:

> Hey all,
>
> I need to create a small clock divider circuit that divides a 77.76MHz clock
> downto 1.544MHz, and I need to have the resultant 1.544MHz clock to be as
> close to a 50/50 duty cycle as possible (as precise as possible), so that I
> don't have alot of jitter.
>
> Any suggestions?
>
> Thanks,
>
> Dave

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 22004
Subject: Re: Is there any DSP and FPGA based board suitable to motor drive
From: Ian Yellowley <yellowle@mech.ubc.ca>
Date: Tue, 11 Apr 2000 16:00:00 -0700
Links: << >>  << T >>  << A >>
Hello All,
as it happens we have recently ported our control
architecture to a simple low cost fpga based board, (XESS).
At present it is complete and under test. Only single axis
control, (via parallel port interface), is implemented.
Output to amp is pwm signal which needs to be amplified and
shifted, if you wish to use simple digital amp this would be
easier, (e.g. technology Artisans..since you are in
Toronto!). I would expect that we will have a multiple,(6 to
8), axis system using our stateline architecture over the
summer. The encoder feedback and overall system speed and
capability are equivalent or better than a system we
previously built using HP quad decode and 80c196 cpu,

Regards

Ian

"Jack D. Ma" wrote:
>
> Hi, friends,
>
> Does anyone know is there any commercial DSP and FPGA based general
> purpose control board suitable to motor drive control? FPGA takes care
> of the A/D, D/A and gating and DSP takes care of the calculation part.
>
> Thanks
>
> Jack

Article: 22005
Subject: Re: Specifying PCI buffer for Xilinx 4000XLA
From: Mike Peattie <mpeattie@xilinx.com>
Date: Tue, 11 Apr 2000 16:29:10 -0700
Links: << >>  << T >>  << A >>
Tom,

For 5v PCI, there is a bitgen switch (-g 5V_Tolerant_IO) which you should set
to Yes.  It can also be accessed in the Design Manager GUI under the
Configuration Template.

Mike

Tom McLaughlin wrote:

> Abhijit,
>
> Thanks for the info.  One more question though.
>
> What about the clamp diode?  The 3.3v PCI buffer is supposed to have a clamp
> diode and the 5v PCI buffer cannot.  Do we have to specify this somewhere as
> well or will the tools know to put a clamp on the input if it is 12ma
> (3.3vPCI) and not if it is 24ma (5v PCI).
> Tom
>
> Abhijit Athavale wrote:
>
> > Tom,
> >
> > It is as easy as that. Set the PCI outputs to FAST slew rate and set
> > DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular
> > XLA buffers are PCI compliant.
> >
> > Tom McLaughlin wrote:
> >
> > > All,
> > > We know how to specify PCI buffers in Virtex and Virtex E.  We put the
> > > statement:
> > >
> > > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value
> > > OBUF_PCI33_3
> > >
> > > in the synthesis script and it passes the attribute to the backend.
> > >
> > > The problem is that we want to use a PCI compliant buffer on an XLA
> > > part.  The docs say that it supports it, but we cannot figure out how to
> > > implement it.  To check if the architecture does support it, I pulled up
> > > the constraints editor after choosing an XLA part.  When I click on I/O
> > > standards, I only have the option to set drive strength, slew rate, but
> > > not the I/O standard.  If you do this with a Virtex part, a new column
> > > appears called "I/O standards" which has all the I/O options, LVTTL,
> > > SSTL, PCI etc.
> > >
> > > The libraries guide on the Xilinx web site does not show support for XLA
> > > that we can find.  We tried using the above statement for the XLA
> > > architecture, but it is not valid.
> > >
> > > The datasheet goes to great lengths to say the XLA has these PCI
> > > compiant buffers, but does not say how to implement them.  Please
> > > help!!!  Do we just implement LVTTL buffers with 12ma of drive strength
> > > and that is PCI compliant....it can't be that easy.....???
> > >
> > > BTW, we are using Alliance 2.1i.
> > >
> > > Tom


Article: 22006
Subject: Re: Virtex E Pads Output Impedance
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Wed, 12 Apr 2000 00:01:03 GMT
Links: << >>  << T >>  << A >>
Hi -

I should have added (at least) one thing.  The "typ," "min," and "max"
categories refer to typical, minimum, and maximum drive strength.  Max
therefore corresponds to the lowest impedance and min the highest.

given driver.  Much of this is due to process variation, and the rest
to voltage and temperature variation.

Bob Perlman

On Tue, 11 Apr 2000 16:38:25 GMT, bobperl@best_no_spam_thanks.com (Bob
Perlman) wrote:

>On Tue, 11 Apr 2000 15:49:02 +0200, "Jean-Paul GOGLIO"
><goglio@getris.com> wrote:
>
>>Hi All,
>>
>>Does anyone on this group know the output impedance of a Virtex E pad using
>>LVTTL standard and the influence of the drive current on this impedance ?
>>
>>Thanks
>
>Hi -
>
>
>http://www.xilinx.com/support/sw_ibis.htm
>
>I then did a quick and dirty output impedance calculation for the
>LVTTL outputs:
>                  LOW                HIGH
>             typ  min   max    typ   min   max
>------------------------------------------------
>LVTTL2S      131  197   103    157   245   117
>LVTTL4S       64   96    51     81   125    61
>LVTTL8S       26   39    21     42    64    32
>LVTTL16S      16   23    13     24    37    18
>LVTTL24S      10   14     8     15    22    11
>
>The file also contains information for a couple other driver
>strengths, but I got tired.
>
>Please note that the IBIS file itself is an approximation, having been
>generated from Spice models.  I got the impedances by dividing the 1V
>Pullup and Pulldown table entries by the corresponding currents, which
>is also an approximation.  So the table represents an approximation of
>an approximation.
>
>Note that:
> 1) Roughly speaking, the impedances are inversely proportional to the
>driver current rating, which makes sense.
> 2) Logic HIGH impedances are somewhat higher than the corresponding
>logic LOW impedances.
>
>Bob Perlman
>
>
>
>-----------------------------------------------------
>Bob Perlman
>Cambrian Design Works
>Digital Design, Signal Integrity
>http://www.best.com/~bobperl/cdw.htm
>Send e-mail replies to best<dot>com, username bobperl
>-----------------------------------------------------

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------

Article: 22007
Subject: Re: Clock Dividers
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Wed, 12 Apr 2000 03:15:52 GMT
Links: << >>  << T >>  << A >>
On Tue, 11 Apr 2000 21:32:37 GMT, Ray Andraka <randraka@ids.net>
wrote:

>Use a DDFS.  The jitter will be a maximum of one cycle of the 77.76 MHz clock.
>The frequency accuracy depends on the number of bits.  Basically this is an
>accumulator clocked at the 77.76 MHz, to which a constant increment is added so
>that the accumulator overflows once per 1.544MHz cycle.  The digital output,
>assuming tht is what you are looking for, is the msb of the accumulator.  If you
>need a different wave shape, the msbs of the accumulator can drive a look up or
>other waveshape converter (the upper bits represent phase as a fractional
>revolution).
>
>For example, if you use a 12 bit accumulator,   an increment value of 81 gives
>an output frequency of  1.5377MHz.  More bits will get better frequency
>resolution.  You could get real close with a 12 bit accumulator if you modulate
>the increment so it is 81 for 2 clocks and 82 for the 3rd.

Hi!

The phase accumulator actually isn't a good circuit to use for this
application, as the division will need to be exact (these are
telecommunications frequencies), and the ratio is such that it can't
be represented exactly with 2^N in the denominator.  That means that
an infinite number of bits in the phase accumulator is needed to get
the exact frequency.

I suggest a fractional-N divider.

My fractional-N divider generator program suggests that this
particular divider is best implemented with a /50, /51 dual modulus
prescaler (i.e. a counter that has selectable division ratios of 50
and 51).
The prescaler is controlled such that for every 193 output clocks, 123
of them are /50 and 70 of them are /51.
Output jitter will have a fundamental frequency of 8kHz, and its
amplitude will be minimised if the 70 clocks of /51 are interleaved as
evenly as possible between the 123 clocks of /50.
The minimum peak to peak jitter is 1 clock period of the 77.76MHz
input.

Note that the modulus controller can be clocked at the output
frequency of 1.544MHz (for low power) or at the input frequency of
77.76MHz (if you run out of clock nets, or are afraid of crossing
clock domain boundaries).  You will need to use clock enables if the
modulus controller is clocked from the input clock.

BTW, jitter is measured between like clock edges.  The duty cycle
usually doesn't come into it.  However, it is simple to design the
prescaler so that its output is high for 25 clocks, and low for 25 or
26 clocks (for /50 or /51, respectively), which gives a duty cycle of
either 49% or 50%.

Regards,
Allan.

>Xanatos wrote:
>
>> Hey all,
>>
>> I need to create a small clock divider circuit that divides a 77.76MHz clock
>> downto 1.544MHz, and I need to have the resultant 1.544MHz clock to be as
>> close to a 50/50 duty cycle as possible (as precise as possible), so that I
>> don't have alot of jitter.
>>
>> Any suggestions?
>>
>> Thanks,
>>
>> Dave


Article: 22008
Subject: Re: Multiple Clock design, setup & hold time violation
From: "MK Yap" <mkyap@REMOVE.ieee.org>
Date: Wed, 12 Apr 2000 11:33:56 +0800
Links: << >>  << T >>  << A >>
Hi!

I have a few modules that works in this way...
In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I
have synchornized the out_module to in_module and the warning goes away...
and yup! The simulation result is now correct :-))
but I suffer some delay(1-2 clk cycles) in sending data... :-(

There is another out2_module that works at much higher speed, (max f/3 or
11MHz). I believe my method no longer works since the delay (1-2 clk cycles)
is intolerable in this case... Does yer method work in this case?

btw, in Synplify, I managed to design all my modules to work at, say all
>70Mhz. But when I use schematic to interconnect the modules in max+plus2
(use fast logic synthesis), after compilation, the max frequency drops
drastically to ard 40MHz.... is there any way to improve the final max
frequency close to 70MHz??

Thanks Iglasner & Christian for sharing yer experiences... They're useful
for novice like me :-)

Regards
MK

<iglasner@zumanetworks.com> wrote in message
news:8cvpj6$51g$1@nnrp1.deja.com...
> Hi,
>
>    You ommite the clock frequance of the 2 clock's (or maybe more ?)
> you are talking about as well as are the infomation delay is crusial or
> can you wait a clock or two.
>
> according to the above  there are few way to approch the problem.
>
> as an example assume you have a data stored in module1 work with clk1
> in few buffers and you want to read a certain buffer to a module2 that
> work in clk2
>
> than a general sulotion will be that module2 will prepare the buffer
> number he want to read and than will rais a single saying he want to
>
> this read signal you will pass through syncronizer (to clk1) to module1
> domain and than module1 will look and see the address which is
>
> module1 will than put the data and will rais a signal saying data is
>
> this data is ready signal will also be syncronize (to clk2) and when
> module2 see it the data is already stable, and can be "used safely".
>
> than module 2 pulldown the read and as soon as mosule 1 see that the
> read signal is pulldown he pulldown the data is ready signal.
>
> this is just one way (usually called full-handshake) and there are many
> other.
>
> have a nice day
>
>    Illan
>
>
> In article <8cu1mq$3v1$1@coco.singnet.com.sg>,
>   "MK Yap" <mkyap@REMOVE.ieee.org> wrote:
> > Hi all,
> >
> > For my design, there is a global clock, some input signals,  some
> output
> > signals (clocked by external source).
> >
> > When input signals come in(synchronized by global clock), the central
> > controller will collect, organize, manipulate & store in buffer.
> > The output port interface portion will at intervals (ctrl by external
> clk)
> > request data from buffer.
> > During my design, I encounter hundreds of design warning by
> max+plus2 (i'm
> > using synplify vhdl sythesizer) saying sth like this
> > "Design Dr warning: flipflop or synchronous memory 'q_data_7'
> > that is synchronized by another clock at flipflop or synchronous
> memory
> > 'subc_datareq'   "
> >     &
> > "Design Dr warning: inverting delay chain starting at primitive
> > 'cntr_1_lut_5'  feeds primitive 'statemachine_cntr_i_0' "
> >
> > & my project fails to work during timing simulation.
> > Can somebody pls shed some light on how to properly design a multiple
> clock
> > system that meets all setup time, hold time....???
> > or is there any good reference that stress on this area of design?
> >
> > Any help is much appreciated.  Thanks in advance.
> >
> > Rgds
> > MK
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/


Article: 22009
Subject: Re: Multiple Clock design, setup & hold time violation
From: Ray Andraka <randraka@ids.net>
Date: Wed, 12 Apr 2000 03:37:14 GMT
Links: << >>  << T >>  << A >>
First, it is possible you are adding relatively long combinatorial delays when
you connect the modules together, or you may be loading down a signal with too
high a fanout.  That can be mitigated somwhat by duplicating logic.

You may be filling the device up to where routing congestion gets in the way and
slows it down.  The Altera devices are vulnerable to this phenomenon, especially
in heavily data path and arithmetic designs because of the routing structure.
Here, about all that really helps is going to a different design approach.  You
can go to a larger device, but you won't get the same speeds for your modules
there (see below).

Also be aware that the Altera line slows down as you go to bigger devices in the
same family/speed grade, again due to the routing resources.

Without knowing more about your design, it is hard to say what the exact problem
is.

MK Yap wrote:

> Hi!
>
> I have a few modules that works in this way...
> In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I
> have synchornized the out_module to in_module and the warning goes away...
> and yup! The simulation result is now correct :-))
> but I suffer some delay(1-2 clk cycles) in sending data... :-(
>
> There is another out2_module that works at much higher speed, (max f/3 or
> 11MHz). I believe my method no longer works since the delay (1-2 clk cycles)
> is intolerable in this case... Does yer method work in this case?
>
> btw, in Synplify, I managed to design all my modules to work at, say all
> >70Mhz. But when I use schematic to interconnect the modules in max+plus2
> (use fast logic synthesis), after compilation, the max frequency drops
> drastically to ard 40MHz.... is there any way to improve the final max
> frequency close to 70MHz??
>
> Thanks Iglasner & Christian for sharing yer experiences... They're useful
> for novice like me :-)
>
> Regards
> MK
>
> <iglasner@zumanetworks.com> wrote in message
> news:8cvpj6$51g$1@nnrp1.deja.com...
> > Hi,
> >
> >    You ommite the clock frequance of the 2 clock's (or maybe more ?)
> > you are talking about as well as are the infomation delay is crusial or
> > can you wait a clock or two.
> >
> > according to the above  there are few way to approch the problem.
> >
> > as an example assume you have a data stored in module1 work with clk1
> > in few buffers and you want to read a certain buffer to a module2 that
> > work in clk2
> >
> > than a general sulotion will be that module2 will prepare the buffer
> > number he want to read and than will rais a single saying he want to
> >
> > this read signal you will pass through syncronizer (to clk1) to module1
> > domain and than module1 will look and see the address which is
> > already "long ago" stable.
> >
> > module1 will than put the data and will rais a signal saying data is
> >
> > this data is ready signal will also be syncronize (to clk2) and when
> > module2 see it the data is already stable, and can be "used safely".
> >
> > than module 2 pulldown the read and as soon as mosule 1 see that the
> > read signal is pulldown he pulldown the data is ready signal.
> >
> > this is just one way (usually called full-handshake) and there are many
> > other.
> >
> > have a nice day
> >
> >    Illan
> >
> >
> > In article <8cu1mq$3v1$1@coco.singnet.com.sg>,
> >   "MK Yap" <mkyap@REMOVE.ieee.org> wrote:
> > > Hi all,
> > >
> > > For my design, there is a global clock, some input signals,  some
> > output
> > > signals (clocked by external source).
> > >
> > > When input signals come in(synchronized by global clock), the central
> > > controller will collect, organize, manipulate & store in buffer.
> > > The output port interface portion will at intervals (ctrl by external
> > clk)
> > > request data from buffer.
> > > During my design, I encounter hundreds of design warning by
> > max+plus2 (i'm
> > > using synplify vhdl sythesizer) saying sth like this
> > > "Design Dr warning: flipflop or synchronous memory 'q_data_7'
> > > that is synchronized by another clock at flipflop or synchronous
> > memory
> > > 'subc_datareq'   "
> > >     &
> > > "Design Dr warning: inverting delay chain starting at primitive
> > > 'cntr_1_lut_5'  feeds primitive 'statemachine_cntr_i_0' "
> > >
> > > & my project fails to work during timing simulation.
> > > Can somebody pls shed some light on how to properly design a multiple
> > clock
> > > system that meets all setup time, hold time....???
> > > or is there any good reference that stress on this area of design?
> > >
> > > Any help is much appreciated.  Thanks in advance.
> > >
> > > Rgds
> > > MK
> > >
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 22010
Subject: Re: Clock Dividers
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Wed, 12 Apr 2000 04:59:19 GMT
Links: << >>  << T >>  << A >>
On Wed, 12 Apr 2000 03:15:52 GMT,
allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman) wrote:

[snip description of fractional-N divider]

Another approach that results in even less jitter is to use a /50,
/50.5 prescaler instead of a /50, /51 prescaler.

The controller will give 53 counts of /50 and 140 counts of /50.5

The fundamental output jitter frequency is still 8kHz (= 1.544MHz /
(53 + 140)), but the amplitude will be only 0.5 periods of the
77.76MHz clock (assuming this clock has a 50% duty cycle).  This is
only 0.010 UIp-p, which is surely good enough for your application.

The output duty cycle also improves to 49.5%

Regards,
Allan.

Article: 22011
Subject: CFP: PART2000 - Seventh Australasian Parallel and Real-Time Systems
From: Oliver Diessel <odiessel@cse.unsw.edu.au>
Date: Wed, 12 Apr 2000 16:08:14 +1000
Links: << >>  << T >>  << A >>
                             P A R T 2 0 0 0

The Seventh Australasian Conference on Parallel and Real-Time Systems
29 -- 30 November 2000, Sydney, Australia

CALL FOR PAPERS

PART is the premier conference for Parallel and Real-Time Systems
researchers in the Australasian region. The seventh annual event will be

held in Sydney, 29 - 30 November, 2000.  The aim of this conference is
to
bring together Australasian and International researchers in parallel
and
real-time systems and their applications, and to provide the opportunity

for creative discussions.

The theme for the 2000 event is:

Internet and Multimedia --- Parallel and Real-Time Issues.

With their inherent parallelism, real-time demands, and widespread usage

and appeal, Internet-based distributed multimedia systems raise
important
issues for researchers and practitioners in the real-time and parallel
systems areas. The 2000 conference aims to bring researchers involved
in parallel and real-time systems together with researchers involved in
developing the Internet and multimedia applications of the future.

Authors are invited to submit manuscripts that demonstrate original
unpublished research in all areas of parallel and real-time systems.
Submissions with applications or addressing issues in the multimedia and

Internet areas are particularly encouraged.  Topics of interest include,

but will not be limited to:

o  Parallel architectures and algorithms
o  Parallel programming
o  Performance analysis and modelling
o  Mobile computing
o  Network-based concurrent computing
o  Object-oriented Real-time and Parallel computing
o  Parallel I/O systems
o  Heterogeneous computing
o  Multimedia systems
o  Internet applications for parallel and real-time systems
o  Distributed operating systems
o  Message Passing Systems
o  Real-time languages and tools
o  Fault-tolerant computing
o  Real-time aspects of distributed systems
o  Real-time scheduling
o  AI and neural networks in real-time control
o  Reconfigurable Computing
o  Real-time collaboration support
o  Real-time aspects of database management systems
o  Parallel databases
o  Visualisation and visual programming of parallel systems

SUBMISSION GUIDELINES

Authors should submit manuscripts not exceeding ten (10) A4 pages
and not more than 5000 words.  The authors' names, affiliations,
and email addresses should be on the front page. All papers will be
refereed and authors will be notified of acceptance as per the dates
Springer-Verlag.

Authors are encouraged to submit manuscripts electronically
by emailing them as attachments in plain Postscript to
part2000@cse.unsw.edu.au. Alternatively, a hardcopy of the paper may be
sent to the Address for Correspondence below.

CONFERENCE ATTENDANCE

Accepted papers must be presented at the conference with the presenting
author registering as a delegate in order for the papers to be included
in the proceedings. Manuscripts whose authors are full-time students,
as certified by their universities, should be marked as student papers
to be considered for a Best Student Paper'' award.

SPECIAL SESSIONS

Proposals for special sessions are solicited.  Interested individuals
should submit a proposal to the Program Co-Chairs.

TUTORIALS

Friday 1 December, 2000 is reserved for tutorials. We welcome
expressions
of interest in presenting a half- or full-day tutorial related to the
theme of the conference. Please send the title, a brief description
(not longer than 4 pages), and a short biography of the presenters to
the Program Co-Chairs by the date specified below. Electronic submission

is preferred.

IMPORTANT DATES

Paper Submission Deadline         3rd July 2000
Camera-ready copies due           18th August 2000
Tutorial expression of interest   24th July 2000

PART2000                                      email:
part2000@cse.unsw.edu.au
c/o Oliver Diessel                            Tel: +61 2 9385 5922
School of Computer Science and Engineering    Fax: +61 2 9385 5995
The University of New South Wales
UNSW SYDNEY    NSW    2052
Australia

ORGANISATION

General Co-chair:        Dr Arcot Sowmya (UNSW)

Organising Co-chairs:    Dr Oliver Diessel (UNSW)
Partha Roop (UNSW)

Program Co-chairs:       A/Prof. Hossam Elgindy (UNSW)
Dr Colin Fidge (UQ)

Steering chair:          A/Prof. Nalin Sharda(VU)

FURTHER INFORMATION

http://www.cse.unsw.edu.au/~part2000 or contact the Organising Co-Chairs


Article: 22012
Subject: pci bus, critical path
From: "jok" <jok@erols.com>
Date: Wed, 12 Apr 2000 07:26:01 -0400
Links: << >>  << T >>  << A >>
1) Anyone know of a good block diagram for the PCI bus controller?

2) What is the critical path in the design?

Thanks.

JJ


Article: 22013
Subject: Re: Programator for xilinx
From: Leon Heller <leon_heller@hotmail.com>
Date: Wed, 12 Apr 2000 12:16:21 GMT
Links: << >>  << T >>  << A >>
In article <8cuclp$h1d$1@okapi.ict.pwr.wroc.pl>,
"Tomasz Brychcy" <tbrychcy@sensor.ime.pz.zgora.pl> wrote:
> Hello,
>
> What programator should I have if i would like to programm circuits of
> xilinx (virtex,xc4000xl,l,xv).

configuration directly into the device with the Xilinx Parallel port
cable. You lose the configuration when the power is removed, of course.
The cable is quite cheap, or you can make your own from the circuit
Xilinx provide on their web site.

Leon
--
Leon Heller, G1HSM
Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824
Email: leon_heller@hotmail.com
Web: http://www.geocities.com/SiliconValley/Code/1835

Sent via Deja.com http://www.deja.com/

Article: 22014
Subject: parity - block ram
From: Thomas Zipper <Thomas.Zipper@icn.siemens.de>
Date: Wed, 12 Apr 2000 14:47:43 +0200
Links: << >>  << T >>  << A >>
Hi,

has anyone an opinion about parity checking within a FPGA (e.g. Virtex),
especially protecting the content of Block-RAMs?

Bye

Thomas


Article: 22015
Subject: Re: Specifying PCI buffer for Xilinx 4000XLA
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Wed, 12 Apr 2000 09:31:05 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Abhijit,
Thanks very much.  Our confusion lied in the fact that we could specificly call out
a PCI primitive in the Virtex lib, but not in the XLA lib.  You have cleared it
up.  Thanks very much.
Tom

Abhijit Athavale wrote:

> Tom,
>
> It is a bitgen option and you can choose that in the configuration options
> window if you are using the design manager. You can either select 5V tolerance
> or 3.3V tolerance. If you select 5V tolerance, device is not 3.3V pci compliant.
> If you choose 3.3V tolerance, device will lose its 5V compliance.
>
> We achieve 5V compliance through the ESD protection diode as per the databook
> and add a clamping diode for 3.3V protection.
>
> Tom McLaughlin wrote:
>
> > Abhijit,
> >
> > Thanks for the info.  One more question though.
> >
> > What about the clamp diode?  The 3.3v PCI buffer is supposed to have a clamp
> > diode and the 5v PCI buffer cannot.  Do we have to specify this somewhere as
> > well or will the tools know to put a clamp on the input if it is 12ma
> > (3.3vPCI) and not if it is 24ma (5v PCI).
> > Tom
> >
> > Abhijit Athavale wrote:
> >
> > > Tom,
> > >
> > > It is as easy as that. Set the PCI outputs to FAST slew rate and set
> > > DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular
> > > XLA buffers are PCI compliant.
> > >
> > > Tom McLaughlin wrote:
> > >
> > > > All,
> > > > We know how to specify PCI buffers in Virtex and Virtex E.  We put the
> > > > statement:
> > > >
> > > > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value
> > > > OBUF_PCI33_3
> > > >
> > > > in the synthesis script and it passes the attribute to the backend.
> > > >
> > > > The problem is that we want to use a PCI compliant buffer on an XLA
> > > > part.  The docs say that it supports it, but we cannot figure out how to
> > > > implement it.  To check if the architecture does support it, I pulled up
> > > > the constraints editor after choosing an XLA part.  When I click on I/O
> > > > standards, I only have the option to set drive strength, slew rate, but
> > > > not the I/O standard.  If you do this with a Virtex part, a new column
> > > > appears called "I/O standards" which has all the I/O options, LVTTL,
> > > > SSTL, PCI etc.
> > > >
> > > > The libraries guide on the Xilinx web site does not show support for XLA
> > > > that we can find.  We tried using the above statement for the XLA
> > > > architecture, but it is not valid.
> > > >
> > > > The datasheet goes to great lengths to say the XLA has these PCI
> > > > compiant buffers, but does not say how to implement them.  Please
> > > > help!!!  Do we just implement LVTTL buffers with 12ma of drive strength
> > > > and that is PCI compliant....it can't be that easy.....???
> > > >
> > > > BTW, we are using Alliance 2.1i.
> > > >
> > > > Tom

Content-Type: text/x-vcard; charset=us-ascii;
name="tomm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom McLaughlin
Content-Disposition: attachment;
filename="tomm.vcf"

begin:vcard
n:McLaughlin;Tom
tel;fax:314-935-7302
tel;work:314-935-7198
x-mozilla-html:FALSE
url:http://www.arl.wustl.edu/~tomm
org:Washington University;Applied Research Lab
version:2.1
email;internet:tomm@arl.wustl.edu
title:Research Associate
adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA
x-mozilla-cpt:;0
fn:Tom McLaughlin
end:vcard


Article: 22016
Subject: Modeltech Error
From: "Thomas Rinder" <thomas.rinder@unibw-hamburg.de>
Date: Wed, 12 Apr 2000 17:09:20 +0200
Links: << >>  << T >>  << A >>
Hi,

I try to use  Modeltech 5.3a to perform a timing analysis (XILINX ping
design).

The simulation script stops with:
sdf file: requires Xilinx primitive library

I included the the primsim and unisim library from the <XILINX> directory.

Does anybody have an idea, how to fix this problem ?

Thank, Thomas


Article: 22017
Subject: Re: Modeltech Error
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 12 Apr 2000 11:31:57 -0700
Links: << >>  << T >>  << A >>
Thomas Rinder wrote in message <8d23b9$bsm$1@rzsun03.rrz.uni-hamburg.de>...
>Hi,
>
>I try to use  Modeltech 5.3a to perform a timing analysis (XILINX ping
>design).
>
>The simulation script stops with:
>sdf file: requires Xilinx primitive library
>
>I included the the primsim and unisim library from the <XILINX> directory.
>
>Does anybody have an idea, how to fix this problem ?

See the following Xilinx tech answer doc.  it tells all.

http://support.xilinx.com/techdocs/2561.htm

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 22018
Subject: Re: Multiple Clock design, setup & hold time violation
From: iglasner@zumanetworks.com
Date: Wed, 12 Apr 2000 19:14:12 GMT
Links: << >>  << T >>  << A >>
Hi,

you mention that you have low freq which are f/16, IF this low freq
is generate from the base freq (f) than you might not need the
syncronizer at all BUT here come the tricky quesiton, how do you
generate the low freq ?

if you have a counter/devider than depend on the way you designed this
devide, if you design is such as that both posedge of the low freq and
high freq are togther (a cascade DFF as a simple counter therfore will
not do) than when you send a signla from the low freq to the high the
signal not need to have any "handling" HOWEVER when you send from the
high to the low than you must hold it for few clock so it will still be
active when the low freq finaly get to the posedge. (if you also use
negedge of clock somewhere you will need that also both negedge of the
clock will be on the same time).

BTW the "suffer" of clock delay is expected as after all you sample it
twice in the syncronizer.

also you might consider not a full-handshake incase you are certain
that the other module "saw" the signla, and in this case you can de-
active the signal as soon as you belive it is ok.

unless you are limited due to number of FF/gates I belive this will
work also in higher frequance, what you might consider doing but is all
depend on your desing is that you might consider adding a fifo, or
maybe make the data passing as burst mode meaning that when you ask to
(the how many will be treated as data and not need to be syncronized)
and than you can get few block of data but again it is all just an
idea's and it all depoend on your design.

have a nice day

Illan

In article <8d0qfd$d19$1@coco.singnet.com.sg>,
"MK Yap" <mkyap@REMOVE.ieee.org> wrote:
> Hi!
>
> I have a few modules that works in this way...
> In_module which works at .. say 33Mhz( f), out_module at ard 2MHz (
f/16). I
> have synchornized the out_module to in_module and the warning goes
away...
> and yup! The simulation result is now correct :-))
> but I suffer some delay(1-2 clk cycles) in sending data... :-(
>
> There is another out2_module that works at much higher speed, (max
f/3 or
> 11MHz). I believe my method no longer works since the delay (1-2 clk
cycles)
> is intolerable in this case... Does yer method work in this case?
>
> btw, in Synplify, I managed to design all my modules to work at, say
all
> >70Mhz. But when I use schematic to interconnect the modules in
max+plus2
> (use fast logic synthesis), after compilation, the max frequency drops
> drastically to ard 40MHz.... is there any way to improve the final max
> frequency close to 70MHz??
>
> Thanks Iglasner & Christian for sharing yer experiences... They're
useful
> for novice like me :-)
>
> Regards
> MK
>
> <iglasner@zumanetworks.com> wrote in message
> news:8cvpj6$51g$1@nnrp1.deja.com...
> > Hi,
> >
> >    You ommite the clock frequance of the 2 clock's (or maybe more ?)
> > you are talking about as well as are the infomation delay is
crusial or
> > can you wait a clock or two.
> >
> > according to the above  there are few way to approch the problem.
> >
> > as an example assume you have a data stored in module1 work with
clk1
> > in few buffers and you want to read a certain buffer to a module2
that
> > work in clk2
> >
> > than a general sulotion will be that module2 will prepare the buffer
> > number he want to read and than will rais a single saying he want to
> >
> > this read signal you will pass through syncronizer (to clk1) to
module1
> > domain and than module1 will look and see the address which is
> > already "long ago" stable.
> >
> > module1 will than put the data and will rais a signal saying data is
> >
> > this data is ready signal will also be syncronize (to clk2) and when
> > module2 see it the data is already stable, and can be "used safely".
> >
> > than module 2 pulldown the read and as soon as mosule 1 see that the
> > read signal is pulldown he pulldown the data is ready signal.
> >
> > this is just one way (usually called full-handshake) and there are
many
> > other.
> >
> > have a nice day
> >
> >    Illan
> >
> >
> > In article <8cu1mq$3v1$1@coco.singnet.com.sg>,
> >   "MK Yap" <mkyap@REMOVE.ieee.org> wrote:
> > > Hi all,
> > >
> > > For my design, there is a global clock, some input signals,  some
> > output
> > > signals (clocked by external source).
> > >
> > > When input signals come in(synchronized by global clock), the
central
> > > controller will collect, organize, manipulate & store in buffer.
> > > The output port interface portion will at intervals (ctrl by
external
> > clk)
> > > request data from buffer.
> > > During my design, I encounter hundreds of design warning by
> > max+plus2 (i'm
> > > using synplify vhdl sythesizer) saying sth like this
> > > "Design Dr warning: flipflop or synchronous memory 'q_data_7'
> > > that is synchronized by another clock at flipflop or synchronous
> > memory
> > > 'subc_datareq'   "
> > >     &
> > > "Design Dr warning: inverting delay chain starting at primitive
> > > 'cntr_1_lut_5'  feeds primitive 'statemachine_cntr_i_0' "
> > >
> > > & my project fails to work during timing simulation.
> > > Can somebody pls shed some light on how to properly design a
multiple
> > clock
> > > system that meets all setup time, hold time....???
> > > or is there any good reference that stress on this area of design?
> > >
> > > Any help is much appreciated.  Thanks in advance.
> > >
> > > Rgds
> > > MK
> > >
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/
>
>

Sent via Deja.com http://www.deja.com/

Article: 22019
Subject: Re: Multiple Clock design, setup & hold time violation
From: Christian Mautner <at@utanet.cmautner>
Date: 12 Apr 2000 21:17:33 +0200
Links: << >>  << T >>  << A >>
"MK Yap" <mkyap@REMOVE.ieee.org> writes:

> Hi!
>
> I have a few modules that works in this way...
> In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I
> have synchornized the out_module to in_module and the warning goes away...
> and yup! The simulation result is now correct :-))
> but I suffer some delay(1-2 clk cycles) in sending data... :-(
>
> There is another out2_module that works at much higher speed, (max f/3 or
> 11MHz). I believe my method no longer works since the delay (1-2 clk cycles)
> is intolerable in this case... Does yer method work in this case?
>

You are writing "f" and "f/16". Are these frequencies synchronous,
that is, is that f/16 created from f by division? In this case,
it would be much easier and better to feed the higher frequency to all
modules and to do the "frequency division" by distributing a f/16
clock-enable signal.

This would be a fully synchronous design, and all synchronization
problems would be solved, maybe (but not necessarily) at the cost of
higher logic consumption.

> btw, in Synplify, I managed to design all my modules to work at, say all
> >70Mhz. But when I use schematic to interconnect the modules in max+plus2
> (use fast logic synthesis), after compilation, the max frequency drops
> drastically to ard 40MHz.... is there any way to improve the final max
> frequency close to 70MHz??

This is very hard to tell without knowing more about the whole
design. The timing analyzer might help you to find the specific signal
that needs that 25ns.

chm.

--
cmautner@  -  Christian Mautner
utanet.at  -  Vienna/Austria/Europe

Article: 22020
Subject: Word up
From: deviant<beigebox@usa.net>
Date: 12 Apr 2000 22:27:42 GMT
Links: << >>  << T >>  << A >>
Check out my music at http://nav.to/deviant3/

eveything under the sun.. mp3s and impulse tracker files are available...


Article: 22021
Subject: DSP - FPGA
From: Gerhard Griessnig <grie@sbox.tu-graz.ac.at>
Date: Thu, 13 Apr 2000 09:08:44 +0200
Links: << >>  << T >>  << A >>
Hello, I am a student.
also need a communication between a DSP (Ti-TMS320C60x) and a Xilinx
(Virtex) for
a realtime network.

Should (could) I use some demo-ports with pci-slots and start the
comminication
with the pci-bus (is it fast enough??) or can I make a direct connection
???
Are any other connections possible ??

Thanks for all informations!
Gerhard


Article: 22022
Subject: Demo - board
From: Philipp <phlamp@my-deja.com>
Date: Thu, 13 Apr 2000 10:18:13 GMT
Links: << >>  << T >>  << A >>
Hello,
I'm looking for demo board to do some design practice on my own (the
university board is not very good). It should work with the Xilinx 4000
series, have at least 3 7-seg displays and some switches, buttons, ADC,
Maybe somebody can recommend me a cheap and good one.

Thanks,
Philipp

Sent via Deja.com http://www.deja.com/

Article: 22023
Subject: Parallel to serial
From: Jamil Khatib <jamilkhatib75@yahoo.com>
Date: Thu, 13 Apr 2000 12:58:01 +0200
Links: << >>  << T >>  << A >>
    Please is there any way to convert from parallel to serial without
using a counter to control the shift register?

Thanks


Article: 22024
Subject: Re: jtag/jtagprog and fpga-demo-board
From: <marko.udvanc@trilus-spe.si>
Date: Thu, 13 Apr 2000 11:43:10 GMT
Links: << >>  << T >>  << A >>

Hello!

Command line? I presume DOS-Prompt.
As I saw the .bsd file has a long file name not 8.3 format.
The DOS prompt can't find file beyond 8.3 format.

Try changing names or similar.

Greetings
Marko

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 7.4.00, 10:00:32, Joerg RiTTer <ritter@informatik.uni-halle.de> wrote=
=20
regarding jtag/jtagprog and fpga-demo-board:

> Hi,

> hardware-debugger-software and the xchecker-cable.
> Now I was looking for a command line version.
> I've realized, that the jtagprog command line tool could be a=20
solution.
message
> :

> JTAG Programmer Started 2000/04/06 10:20:37
> 'g:/Xilinx/xc4000e/data/xc4005e_pc84.bsd'.....completed
> successfully.
>     Checking boundary-scan chain integrity...ERROR:JTag -=20
Boundary-scan
> chain test failed at bit position '1' on instance 'addsub(Device1)'.
>      Check that the cable, system and device JTAG TAP connections are=

> correct,
>      that the target system power supply is set to the correct level,=

>       that the system grounds are connected and that the parts are
> properly decoupled.
>     ERROR:JTag - Boundary scan chain has been improperly specified.

chain

> information.
>     Boundary-scan chain validated unsuccessfully.
>     ERROR:JTag - : The boundary-scan chain has not been declared
> correctly.
>      Verify the syntax and correctness of the device BSDL files,=20
correct

> the files,
>      reset the cable and retry this command.

> I was using the same xchecker cable, fpga-board and the exactly the=20=

same

> Any ideas ?
> Is there a command line version of the hardware debugger ?

> Thanks
> Joerg