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 35100

Article: 35100
Subject: Re: Synplicity logic replication
From: husby_d@yahoo.com (Don Husby)
Date: 20 Sep 2001 18:28:11 -0700
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogic.com.nospam.com> wrote:
> There may be an 'official' way, but I have always ended up
> instantiating the LUT.
> 
> Which is not too difficult in VHDL but, AFAIK, tricky in Verilog.
> 

  This is what I ended up doing.  I guess the Golden Age of high level
HDL hasn't arrived yet.  The sad thing is that everyone thinks it has,
so when I write something simple, the tool trys to second guess me and
make an "optimization".  I have to go to great effort to tell it to
just fucking do what I say.  Instantiating a LUT is to HDL programming
as instantiating machine op-codes is to C programming.

  Here's how to instantiate a LUT in Synplicity/Verilog:

    LUT3 #('h2f) shift0(Shift[0], Sending, Stall, Ready);

  Unfortunately, not all synthesis/simulation tools accept
the same format.


> "Don Husby" <husby_d@yahoo.com> wrote in message
> news:35802095.0109181335.38d1e3a1@posting.google.com...
> > How do I prevent Synplify from optimizing away my
> > attempts to replicate logic?
> >
> > For the following code, synplify will merge the two instances
> > of Shift into the same net:
> >
> >   wire  [1:0] Shift                            /* synthesis syn_keep=1 */;
> >   assign Shift[0]= Sending & !Stall | !Ready;  //
> >   assign Shift[1]= Sending & !Stall | !Ready;  // Replicated
> >
> > Also, is there some way to get synplify to print a message when
> > it encounters an attribute?  Otherwise, there's no way to tell
> > if the attribute has an error that causes it to not be recognized
> > as an attribute.

Article: 35101
Subject: Altera 20KE Bus Switching
From: "Dave Barry" <davebarry@home.com>
Date: Fri, 21 Sep 2001 04:36:55 GMT
Links: << >>  << T >>  << A >>
Has anyone seen noisy outputs in an Altera 20KE series device during bus
switching?  I have an output control signal located in a bank that drives a
wide bus (32 bits).  When all bits of the bus change at the same time, the
control signal glitches.  I'm trying to isolate the problem between the
circuit board layout and the Altera FPGA device.

Thanks.



Article: 35102
Subject: Hitop Warning hi434
From: Klaus Falser <kfalser@durst.ig>
Date: Fri, 21 Sep 2001 08:42:47 +0200
Links: << >>  << T >>  << A >>
I'm using a Xilinx XC95216-PQ160 CPLD and the fitter 'hitop' gives me the 
following warning :
 
WARNING:hi434 - We have detected that a large number of internal signals 
may 
be switching at the same time. To avoid potential simultaneous 
switching/ground bounce issues, please contact Xilinx customer support 
for more information.

Does anybody have any experience with this message?
The design seems to work correctly, I'm using a multilayer PCB,
the programmable GND pins and a 100nF Capacitor at every
supply pin, but I would like to know if there are some 
potential problems.

Thank you very much.

-- 
Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	  Vittorio Veneto Str. 59
	  I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@IHATESPAMdurst.it 

Article: 35103
Subject: Re: Increase routing delay in XILINX FPGA editor
From: "Chih-Hsun Lin" <Chih-Hsun.Lin@cern.ch>
Date: Fri, 21 Sep 2001 11:46:13 +0200
Links: << >>  << T >>  << A >>
Hi Philip :
I completely agree with you. Unfortunately, I can not avoid ASYNC signals in
my current work. However, my experience about estimated routing delay from
Xilinx or Altera design tools is not bad. Their estimation is reasonably
well.
(at least at room tempature).

Thanks for your comments.

regards,
LIN CH


"Philip Freidin" <philip@fliptronics.com> wrote in message
news:0h3lqtgblji4gaha6o8th40l9srt72ncg1@4ax.com...
>
> I hope you understand that all the delays reported by the timing analyzer
> and the FPGA_Editor are worst case delays. You cannot get bestcase
> or actual delays.
>
> So if you have two paths and the tools tell you the delays are 16nS and
20nS
> adding 4 nS to the first one does not solve your problem because you
> dont know what the actual delays are, only the worst values that they
might be.
>
> For instance, the real delays might be 6 ns and 18ns. Adding 4 does not
> match them.
>
> Or they might be both actually 14 nS. adding 4 stops them from being
matched.
>
> Or any one of an infinite number of other possibilities.
>
> Without criticizing your design, when people ask about delay matching and
> screwing around with routing to adjust timing for any reason other than
meeting
> a cycle time requirement, my thinking is that you may need to rethink your
> design approach.
>
> Good luck,
>
> Philip Freidin
>
> On Wed, 19 Sep 2001 11:35:47 +0200, "Chih-Hsun Lin"
<Chih-Hsun.Lin@cern.ch>
> wrote:
> >Hi :
> >Thanks very much for your answer.
> >
> >Actually, my case is that two async signals come out from the same CLB to
2
> >output pads.
> >I want the routing delay for those two signals shall be similar. The
usual
> >routing medthod
> >is to get minimum delay. In order to match the routing delay, I think the
> >easy way shall be
> >increase routing dealy for one signal to match the other. However, I did
not
> >find a way to
> >do it easily in FPGA editor.
> >
> >Best regards,
> >Lin CH
> >
>
> Philip Freidin
> Fliptronics



Article: 35104
Subject: PCI design for Spartan-2
From: Alex <nanko@nanko.ru>
Date: Fri, 21 Sep 2001 04:02:24 -0700
Links: << >>  << T >>  << A >>
Is anybody who can help me with PCI-32 implementation for Spartan-2?
Please contact by E-mail 'nanko@nanko.ru', subject: "for Alexander Kurbasov".
Many thanks!!

Article: 35105
Subject: Control the programming of a Xilinx 9500 CPLD from an application
From: bruno.gebert@exor.ch (Bruno Gebert)
Date: 21 Sep 2001 04:28:37 -0700
Links: << >>  << T >>  << A >>
Hi everybody

I try to control the programming of a Xilinx 9500 CPLD from an
application. For this I need a CPLD-programmer and a software (exe or
dll) which must be controllable by my application.

e.g. I want to check if the CPLD is erased, erase a CPLD, program the
CPLD and make a verify of the downloaded code.

One of the possible solution may be that I call the programming
software with command line parameters and then get the exit code of
the program to return the status of the operation back to the calling
application.
Another solution may be that there is an ActiveX-Control or DLL
available to handle the communication with the programmer.

To program the CPLD I have either the JED file or the SVF file. 

=> Does anyone know about a programmer which is "remote" controllable
as described?

I have already looked at the JAM-Player from Altera, but XILINX seems
not to support the JAM format directly. If I convert a XILINX SVF file
with the Altera tool svf2jam the file grows from 2MB to 6MB (the JED
file is only 200k bytes!).
Also I could not find examples of DO_ERASE, DO_BLANKCHECK, DO_SECURE
procedures implemented in JAM for a XILINX 9500 CPLD.

=> Does anybody know about a JAM composer for XILINX 9500 CPLD's?

Thanks
Bruno

Article: 35106
Subject: Re: Altera 20KE Bus Switching
From: Ahmed Shihab <ashihab@alcahest.com>
Date: Fri, 21 Sep 2001 11:43:32 GMT
Links: << >>  << T >>  << A >>
if you have a large number of signals on the bus changing state simultaenously then you might run into ground bounce 
issues, especially if the physical layout is using the same IO bank and/or there is not enough de-coupling on the supply 
pins.

refer to the Quartus and APEX pins assignment guidelines in one of the Altera App Notes.

Ahmed.

On Fri, 21 Sep 2001 04:36:55 GMT, "Dave Barry" <davebarry@home.com> wrote:
> Has anyone seen noisy outputs in an Altera 20KE series device during bus
> switching?  I have an output control signal located in a bank that drives a
> wide bus (32 bits).  When all bits of the bus change at the same time, the
> control signal glitches.  I'm trying to isolate the problem between the
> circuit board layout and the Altera FPGA device.
> 
> Thanks.
> 
> 



Article: 35107
Subject: comparison of performance and advantages for fpga's versus
From: Jeffrey Graham <jgraham@lincom-asg.com>
Date: Fri, 21 Sep 2001 08:40:21 -0500
Links: << >>  << T >>  << A >>
Hello everyone,

I searched for answer to the above in several fpga faqs, but came up empty.

My project is about taking multiple sensor readings, doing some heavy
math involving PCA, matrices and waveform analysis, then controlling
some small dc motors in near-real time (soft).

There are also requirements for some wireless I/O and flash disk storage.

My primary constraint is the cost to develop a prototype considering my
limited experience with FPGAs.

The solution offered by Celoxica is interesting (www.celoxica.com) since
I get to stay in my comfort zone of just writing C without having to learn
everything about FPGAs.

Thanks in advance for your helpful advice,
Jeff


Article: 35108
Subject: Re: Synplicity logic replication
From: Ray Andraka <ray@andraka.com>
Date: Fri, 21 Sep 2001 14:09:44 GMT
Links: << >>  << T >>  << A >>
With synplicity, if you put the logic for the lut in a separate component and put
the synplify xc_map attribute on it, it does essentially what fmaps used to do in
schematics.  That way, you get the benefits of lut instantiation (you can even put
an RLOC on the instantiation) without the peril associated with getting the right
init string into the LUT.  For example, the following code is a 2 input OR that
can be instantiated, RLOC'd etc, and it doesn't disolve at the whim of the tools:


--FMAP'd or2
library IEEE;
use IEEE.std_logic_1164.all;

entity fmap_or2 is
  port ( a, b : in std_logic;
  z : out std_logic);
end fmap_or2;
architecture rtl of fmap_or2 is
    attribute xc_map : STRING;
    attribute xc_map of rtl : architecture is "lut";
begin
  z <=  a or b;
end rtl;






Don Husby wrote:

> "Tim" <tim@rockylogic.com.nospam.com> wrote:
> > There may be an 'official' way, but I have always ended up
> > instantiating the LUT.
> >
> > Which is not too difficult in VHDL but, AFAIK, tricky in Verilog.
> >
>
>   This is what I ended up doing.  I guess the Golden Age of high level
> HDL hasn't arrived yet.  The sad thing is that everyone thinks it has,
> so when I write something simple, the tool trys to second guess me and
> make an "optimization".  I have to go to great effort to tell it to
> just fucking do what I say.  Instantiating a LUT is to HDL programming
> as instantiating machine op-codes is to C programming.
>
>   Here's how to instantiate a LUT in Synplicity/Verilog:
>
>     LUT3 #('h2f) shift0(Shift[0], Sending, Stall, Ready);
>
>   Unfortunately, not all synthesis/simulation tools accept
> the same format.
>
> > "Don Husby" <husby_d@yahoo.com> wrote in message
> > news:35802095.0109181335.38d1e3a1@posting.google.com...
> > > How do I prevent Synplify from optimizing away my
> > > attempts to replicate logic?
> > >
> > > For the following code, synplify will merge the two instances
> > > of Shift into the same net:
> > >
> > >   wire  [1:0] Shift                            /* synthesis syn_keep=1 */;
> > >   assign Shift[0]= Sending & !Stall | !Ready;  //
> > >   assign Shift[1]= Sending & !Stall | !Ready;  // Replicated
> > >
> > > Also, is there some way to get synplify to print a message when
> > > it encounters an attribute?  Otherwise, there's no way to tell
> > > if the attribute has an error that causes it to not be recognized
> > > as an attribute.

--
--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: 35109
Subject: Re: Increase routing delay in XILINX FPGA editor
From: Ray Andraka <ray@andraka.com>
Date: Fri, 21 Sep 2001 14:16:22 GMT
Links: << >>  << T >>  << A >>
Even with async signals, you design should be done so that the signal delay is
not critical to circuit operation.  That requires correct hazard analysis for
both static and dynamic hazards.

From my experience, the xilinx delays reported by the tools are usually about
40-50% pessimistic at room temperature.  If the delay values were fairly
accurate at room temperature like you state, designs meeting timing in the
timing analyzer would fail at even slightly elevated temperatures.  The delays
reported are worst case over temperature, supply voltage, and process
variations.

I am with Philip, if you are trying to match delays, you probably need to
rethink your design.  If you do have truely async stuff, you need to look
carefully at async design techniques, and you will probably have to instantiate
luts or use keep buffers to keep your cover terms from being optimized out.

Chih-Hsun Lin wrote:

> Hi Philip :
> I completely agree with you. Unfortunately, I can not avoid ASYNC signals in
> my current work. However, my experience about estimated routing delay from
> Xilinx or Altera design tools is not bad. Their estimation is reasonably
> well.
> (at least at room tempature).
>
> Thanks for your comments.
>
> regards,
> LIN CH
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:0h3lqtgblji4gaha6o8th40l9srt72ncg1@4ax.com...
> >
> > I hope you understand that all the delays reported by the timing analyzer
> > and the FPGA_Editor are worst case delays. You cannot get bestcase
> > or actual delays.
> >
> > So if you have two paths and the tools tell you the delays are 16nS and
> 20nS
> > adding 4 nS to the first one does not solve your problem because you
> > dont know what the actual delays are, only the worst values that they
> might be.
> >
> > For instance, the real delays might be 6 ns and 18ns. Adding 4 does not
> > match them.
> >
> > Or they might be both actually 14 nS. adding 4 stops them from being
> matched.
> >
> > Or any one of an infinite number of other possibilities.
> >
> > Without criticizing your design, when people ask about delay matching and
> > screwing around with routing to adjust timing for any reason other than
> meeting
> > a cycle time requirement, my thinking is that you may need to rethink your
> > design approach.
> >
> > Good luck,
> >
> > Philip Freidin
> >
> > On Wed, 19 Sep 2001 11:35:47 +0200, "Chih-Hsun Lin"
> <Chih-Hsun.Lin@cern.ch>
> > wrote:
> > >Hi :
> > >Thanks very much for your answer.
> > >
> > >Actually, my case is that two async signals come out from the same CLB to
> 2
> > >output pads.
> > >I want the routing delay for those two signals shall be similar. The
> usual
> > >routing medthod
> > >is to get minimum delay. In order to match the routing delay, I think the
> > >easy way shall be
> > >increase routing dealy for one signal to match the other. However, I did
> not
> > >find a way to
> > >do it easily in FPGA editor.
> > >
> > >Best regards,
> > >Lin CH
> > >
> >
> > Philip Freidin
> > Fliptronics

--
--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: 35110
Subject: Re: Virtex-2 availability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 21 Sep 2001 07:52:29 -0700
Links: << >>  << T >>  << A >>
John_H,

My comments below....

Austin

John_H wrote:

> questions below:
>
> Austin Lesea wrote:
>
> > John_H wrote:
> >
> >> How long (if at all) does it take to settle from this
> >> delay-line-switched
> >> phase change?
> >
> > It takes 84 clocks on the CLKIN input, plus three on the PSCLK input
> > to effect a change (increment or decrement).  If those are tied
> > together (commonly done) that is 87 clocks.  You MUST wait for PSDONE
> > before PSEN is asserted to inc or dec again.
>
> 87 clocks to move 1/256 cycle (on average) gives 45ppm of frequency
> adjustment capability if continuous phase adjustment is achieved -
> disappointingly slow.  If I could directly control the phase value
> directly (best choice), inc/dec by more than 1/256, or have the change
> occur sooner (15 clocks?) the usability of the DCM increases
> significantly.

Yup.  No doubt about it.  +/- 45 ppm is just twice shy of where it would get
really interesting.  Thanks for confirming our math, '45' is the number we
get as well.

>
>
> >>   Can the phase shift be "wrapped around" such that decrementing
> >> past -255
> >> ends up back at zero?
> >
> > No.  The phase shift increments until it overflows (sticks at 255), or
> > decrements until 0 (then sticks at 0).  An external counter is
> > required if you want to keep track of it.  If you PSOVERFLOW, the unit
> > needs a RESET to go again.
>
> Does the RESET do nasty things to the clock or is it a seamless
> transition to zero phase?  (I guess I'm grasping at straws)

Nasty things.  All outputs go to hard '0'

If you want to do really neat things, contact you FAE for more subtle
details of the DCM (re: freeze mode, test mode).

>
>
> --- new question ---
>
> Can the BUFGMUX primitives be cascaded to allow selection of, say, 4
> clocks?  More specifically, 4 clock phases from a DCM?

I don't see why not.  The BUFGMUX is a state machine, so it always requires
the input clocks to be transistioning, or it will not switch.

Again, in the future, a simple mux option would be nice, and we have
recognized this.



Article: 35111
Subject: Re: Stopping a DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 21 Sep 2001 07:55:49 -0700
Links: << >>  << T >>  << A >>
Rick,

It exactly the right place, as you state.  That is why you have to be so
very careful.  If too many cycles go by, the DLL itself drifts, and then the
same place isn't there any more.

It is a lot like humming a tune on a CD, if you go away for too long, you
are not in sync when you come back.

In lab tests, we can interrupt the clock for periods of a few hundred
microseconds in a quiet environment, and it does not lose lock, but that is
pretty far from the real world.

Austin

Rick Filipkiewicz wrote:

> It says in the Virtex-E databook that the the clock input to a DLL can
> be stopped & restarted as long as the clock is stopped while its low.
>
> How does this square with the max cycle-to-cycle input variation
> parameter of 1nsec. ?
>
> When the clock is re-started does this mean that the the first new
> rising edge has to be in the same place +/- 1 nsec it would have been if
> the clock had not been stopped ?


Article: 35112
Subject: Re: Stopping a DLL
From: John_H <johnhandwork@mail.com>
Date: Fri, 21 Sep 2001 15:35:28 GMT
Links: << >>  << T >>  << A >>
So there's a free-running clock inside the DLL?  I thought the comparisons were
for delayed clock versus live clock such that once the comparison edges are
"lost" due to inactivity, the edge placement can be wherever;  it's just the
cycle time that's important at that point (which can easily drift).

This capability could have direct impact on an upcoming design.

Austin Lesea wrote:

> Rick,
>
> It exactly the right place, as you state.  That is why you have to be so
> very careful.  If too many cycles go by, the DLL itself drifts, and then the
> same place isn't there any more.
>
> It is a lot like humming a tune on a CD, if you go away for too long, you
> are not in sync when you come back.
>
> In lab tests, we can interrupt the clock for periods of a few hundred
> microseconds in a quiet environment, and it does not lose lock, but that is
> pretty far from the real world.
>
> Austin


Article: 35113
Subject: Re: Stopping a DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 21 Sep 2001 09:38:38 -0700
Links: << >>  << T >>  << A >>
John_H,

No there is not a free running clock.  There is a delay line.

The incoming edge stops happening.  The delay line empties out.

There is no CLKFB signal now.

Now you start again.  The CLKFB signal comes in again (some cyles later).  When it
does, it has to be in the window wrt to the CLKIN signal, or you lose lock.

Austin

John_H wrote:

> So there's a free-running clock inside the DLL?  I thought the comparisons were
> for delayed clock versus live clock such that once the comparison edges are
> "lost" due to inactivity, the edge placement can be wherever;  it's just the
> cycle time that's important at that point (which can easily drift).
>
> This capability could have direct impact on an upcoming design.
>
> Austin Lesea wrote:
>
> > Rick,
> >
> > It exactly the right place, as you state.  That is why you have to be so
> > very careful.  If too many cycles go by, the DLL itself drifts, and then the
> > same place isn't there any more.
> >
> > It is a lot like humming a tune on a CD, if you go away for too long, you
> > are not in sync when you come back.
> >
> > In lab tests, we can interrupt the clock for periods of a few hundred
> > microseconds in a quiet environment, and it does not lose lock, but that is
> > pretty far from the real world.
> >
> > Austin


Article: 35114
Subject: Re: Virtex Clock Enable and Synplify
From: ed.moore@snellwilcox.com (Edward Moore)
Date: 21 Sep 2001 11:07:47 -0700
Links: << >>  << T >>  << A >>
It is possible to use the enable input on the global clock buffers.
I think they work in the same way as the Virtex2 BUFGCE macro, its
just that they are not supported by the current software (maybe for
good reason ?).

You would need to create a hard macro in Fpga Editor containing a
GCLKBUF with the I, O and CE pins as external pins. You would also
need a black-box VHDL component for your macro and since simulation is
not supported a simple model as well.

The odd thing is, to get it to work you need to set the GCLKBUF CEMUX
to '1' (implying GCLKBUFs derived from a BUFG gate the clock with
whatever is routed to the CE pin).

To be safe, drive the CE pin from a FF clocked off the falling edge of
the ungated clock. The P&R tools will treat the clock net as being
un-gated.

Virtex BUFGCEs might be supported in the new version 4 software -
anyone ?

--
Edward Moore

Charles Ross <rossc@cs.colostate.edu> wrote in message news:<3BAA590B.FAF4E683@cs.colostate.edu>...
> Im interested in making use of the clock enable pins
> that exist in the Virtex CLBs.
> 
> I have got a VHDL component, which expects a streams
> of values to be entered in serial. However, the I/O
> bandwidth of my board is not sufficient to supply the
> stream.  I would like to specify a value to be used as
> the clock enable for the entire component.  This way
> I would be able to prepare one set of values, raise the
> clock enable for just one clock cycle, then lower it
> again while I prepare the next set of values.
> 
> The VHDL component is behavioral, and computer generated.
> So, I am unable to modify the code which generates it, or
> I would have added a "data valid" signal to the component
> This is unfortunatly not possible.  It also contains
> several other components, which I also cannot modify.
> 
> I thought about using a gated clock, IE:
>   my_gated_clock <= CLK and my_clock_enable;
> 
> And then using the gated clock to drive the clock of
> the component, but this seems quite primitive, and
> likly to cause clock scew, or other nasty problems.
> I know that clock signals have dedicated resources
> and it occured to me that using a gated clock would
> cause the clock signal to be a regular signal, which
> might cause problems. I am uneasy about messing with
> the actual clock lines.
> 
> I looked around in the synplify manuals and found
> an attribute called "syn_direct_enable" which appears
> to be for specifying a clock enable for a component,
> but the description of the attribute is poor. I have
> not been able to get it to work.
> 
> If I am able to figure out how to easily make use of
> the Clock enable I will be able to use them for other
> "data valid" type signals to generate more efficient
> code.
> 
> Any suggestions? Examples?

Article: 35115
Subject: Xilinx PCI bridge reference design
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 21 Sep 2001 15:33:22 -0400
Links: << >>  << T >>  << A >>
Hi;

I seem to remember seeing something along the lines of a synthesizable PCI
bridge reference design on the Xilinx web site some time ago. Now I can't
find it. Does anyone else remember this, or am I imagining things?

The reason I ask is that I'm looking for a lightweight PCI testbench. There
is a very simple one that comes with their PCI core for testing their
"ping32" example design. I thought there might be one included with the PCI
bridge reference design as well.

Cheers,
Jamie



Article: 35116
Subject: Re: Stopping a DLL
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 21 Sep 2001 20:57:58 +0100
Links: << >>  << T >>  << A >>


Austin Lesea wrote:

> Rick,
>
> It exactly the right place, as you state.  That is why you have to be so
> very careful.  If too many cycles go by, the DLL itself drifts, and then the
> same place isn't there any more.
>
> It is a lot like humming a tune on a CD, if you go away for too long, you
> are not in sync when you come back.
>
> In lab tests, we can interrupt the clock for periods of a few hundred
> microseconds in a quiet environment, and it does not lose lock, but that is
> pretty far from the real world.
>
> Austin
>
>

If I wanted to do this for longer & could figure out some ``refresh'' circuit
what would a realistic, noisy real-world, min period be ?

Clearly the best answer would be - use the clock mux on a V-2.




Article: 35117
Subject: Re: comparison of performance and advantages for fpga's versus microcontroller+dsp
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Fri, 21 Sep 2001 20:09:16 GMT
Links: << >>  << T >>  << A >>
That's exactly what Celoxica wants you to think.  If only it were true!

-Kevin

"Jeffrey Graham" <jgraham@lincom-asg.com> wrote in message
news:3BAB4345.B33B3F86@lincom-asg.com...
> Hello everyone,
>
> I searched for answer to the above in several fpga faqs, but came up
empty.
>
> My project is about taking multiple sensor readings, doing some heavy
> math involving PCA, matrices and waveform analysis, then controlling
> some small dc motors in near-real time (soft).
>
> There are also requirements for some wireless I/O and flash disk storage.
>
> My primary constraint is the cost to develop a prototype considering my
> limited experience with FPGAs.
>
> The solution offered by Celoxica is interesting (www.celoxica.com) since
> I get to stay in my comfort zone of just writing C without having to learn
> everything about FPGAs.
>
> Thanks in advance for your helpful advice,
> Jeff
>



Article: 35118
Subject: Re: Virtex Clock Enable and Synplify
From: Charles Ross <rossc@cs.colostate.edu>
Date: Fri, 21 Sep 2001 14:12:00 -0600
Links: << >>  << T >>  << A >>
Unfortunatly, this wont solve my problem..  Does anyone know if it possible to
specify a clock enable pin for EVERY clb in a component?
(Im using Synplify, and foundation tools 3.3ip8)

> You would need to create a hard macro in Fpga Editor containing a
> GCLKBUF with the I, O and CE pins as external pins. You would also
> need a black-box VHDL component for your macro and since simulation is
> not supported a simple model as well.

This sounds like a great one-time solution, but I wont be able to do this for each
and every computer generated VHDL component. (Of which there are a countless
number)  the component itself, in VHDL is not alowed to change.

> Virtex BUFGCEs might be supported in the new version 4 software -
> anyone ?

Which software? Synplify? Foundation Tools?

--
          _____ _____
   ___   |     | __  |
  |___|  |   --|    -|
         |_____|__|__|




Article: 35119
Subject: Re: problem with location constraints in Verilog
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Fri, 21 Sep 2001 22:34:21 GMT
Links: << >>  << T >>  << A >>
Why not put the location constraints in the .UCF file?  Makes the code
more portable.

--a

Johan Ditmar wrote:
> 
> Hello,
> 
> I have a problem with pin location constraints using Verilog/FPGA express.
> I have the following simple design:
> 
> module test(A, B);
> input A; //synopsys attribute LOC "P63"
> output B;
> 
> assign B=A;
> 
> endmodule
> 
> When I run synthesis and then place and route, the Xilinx PAR tools give the
> following warning:
> 
> WARNING:NgdBuild:483 - Attribute "LOC" on "N_A" is on the wrong type of
> object.
>     Please see the "Attributes, Constraints, and Carry Logic" section of the
> Libraries Guide for more information on this attribute.
> 
> It turns out, that FPGA express puts the constraint on the output net of the
> input buffer of A, in stead of A itself.
> Does anyone know how to solve this from within Verilog?
> 
> Kind Regards,
> 
> Johan

Article: 35120
Subject: Re: problem with location constraints in Verilog
From: Ray Andraka <ray@andraka.com>
Date: Fri, 21 Sep 2001 23:10:13 GMT
Links: << >>  << T >>  << A >>
Very tedious to do too, esp if you have any regular structure in your design.
Putting the placement in the code allows you to build the structure hierarchically
instead of flat.  You can floorplan even pretty big designs rather quickly that
way.

Of course, if it is just pin assignments you are worried about, I'd do that in the
UCF. I think it is easier (pins are flat anyway)

Andy Peters wrote:

> Why not put the location constraints in the .UCF file?  Makes the code
> more portable.
>
> --a
>
> Johan Ditmar wrote:
> >
> > Hello,
> >
> > I have a problem with pin location constraints using Verilog/FPGA express.
> > I have the following simple design:
> >
> > module test(A, B);
> > input A; //synopsys attribute LOC "P63"
> > output B;
> >
> > assign B=A;
> >
> > endmodule
> >
> > When I run synthesis and then place and route, the Xilinx PAR tools give the
> > following warning:
> >
> > WARNING:NgdBuild:483 - Attribute "LOC" on "N_A" is on the wrong type of
> > object.
> >     Please see the "Attributes, Constraints, and Carry Logic" section of the
> > Libraries Guide for more information on this attribute.
> >
> > It turns out, that FPGA express puts the constraint on the output net of the
> > input buffer of A, in stead of A itself.
> > Does anyone know how to solve this from within Verilog?
> >
> > Kind Regards,
> >
> > Johan

--
--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: 35121
Subject: Re: Stopping a DLL
From: John_H <johnhandwork@mail.com>
Date: Fri, 21 Sep 2001 23:42:17 GMT
Links: << >>  << T >>  << A >>
I sincerely appreciate your insight and assistance in this newsgroup.  You and Peter
Alfke are great resources to help pass along these Xilinx details to people who need
them.  So please see my continuing desire to understand in a positive light  :-)

When there is no clock activity, there is no CLKFB and there is no CLKIN for the
Xilinx DLL.  Since the DLL was "trained" earlier by a clock that caused the DLL to
choose a delay tap, the delay is set and fixed (for now).  When the clock starts up
again, the CLKIN has an edge but CLKFB is absent.  Once CLKIN propagates through the
delay line, CLKFB will be present and (if CLKIN has the same period it had before) the
phases will match.  The only "window" is CLKIN relative to CLKFB.  So if a clock has
been absent long enough for CLKFB to flatline, the new phase alignment is arbitrary.

If the above sequence of events doesn't describe the operation, what is the window
referenced to?

- John


Austin Lesea wrote:

> John_H,
>
> No there is not a free running clock.  There is a delay line.
>
> The incoming edge stops happening.  The delay line empties out.
>
> There is no CLKFB signal now.
>
> Now you start again.  The CLKFB signal comes in again (some cyles later).  When it
> does, it has to be in the window wrt to the CLKIN signal, or you lose lock.
>
> Austin


Article: 35122
Subject: Re: Virtex Clock Enable and Synplify
From: John_H <johnhandwork@mail.com>
Date: Fri, 21 Sep 2001 23:53:08 GMT
Links: << >>  << T >>  << A >>
I didn't reply immediatly because I have a Verilog bent.  Knowing what I
do about Synplify, you should be able to get the Virtex CLB clock enable
pins worked into your code easily.  No tricks.  There is one directive
(attribute?) that might help for some signals - look up syn_isenable on
Synplify's online help; I think that's valid but can't check quickly.

Be aware that CLBram and SRL instances won't pack nicely with write
enables and register resets.  BlockRams also may need a little help.

In Verilog the clock enable would just be one big "if" statement wrapped
around everything inside my "always" blocks.


Charles Ross wrote:

> Im interested in making use of the clock enable pins
> that exist in the Virtex CLBs.
>
> I have got a VHDL component, which expects a streams
> of values to be entered in serial. However, the I/O
> bandwidth of my board is not sufficient to supply the
> stream.  I would like to specify a value to be used as
> the clock enable for the entire component.  This way
> I would be able to prepare one set of values, raise the
> clock enable for just one clock cycle, then lower it
> again while I prepare the next set of values.
>
> The VHDL component is behavioral, and computer generated.
> So, I am unable to modify the code which generates it, or
> I would have added a "data valid" signal to the component
> This is unfortunatly not possible.  It also contains
> several other components, which I also cannot modify.
>
> I thought about using a gated clock, IE:
>   my_gated_clock <= CLK and my_clock_enable;
>
> And then using the gated clock to drive the clock of
> the component, but this seems quite primitive, and
> likly to cause clock scew, or other nasty problems.
> I know that clock signals have dedicated resources
> and it occured to me that using a gated clock would
> cause the clock signal to be a regular signal, which
> might cause problems. I am uneasy about messing with
> the actual clock lines.
>
> I looked around in the synplify manuals and found
> an attribute called "syn_direct_enable" which appears
> to be for specifying a clock enable for a component,
> but the description of the attribute is poor. I have
> not been able to get it to work.
>
> If I am able to figure out how to easily make use of
> the Clock enable I will be able to use them for other
> "data valid" type signals to generate more efficient
> code.
>
> Any suggestions? Examples?
>
> --
>           _____ _____
>    ___   |     | __  |
>   |___|  |   --|    -|
>          |_____|__|__|


Article: 35123
Subject: Re: Stopping a DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 21 Sep 2001 17:02:44 -0700
Links: << >>  << T >>  << A >>
You got it.

The problem is entirely the change in the delay line with the changing environment.  If
the voltage, or temperature changes, you are going to be unlocked when that next rising
edge comes along.

We estimated that it would take about 1 ms for the micro-environment to change enough to
lose lock this way...it is really hard to estimate what the worst case drift of a few
hundred buffers are in the delay line chain.

When you add in power supply ripple, SSO's, and all of the other normal stuff, it isn't
recommended.

Thanks,

Austin

John_H wrote:

> I sincerely appreciate your insight and assistance in this newsgroup.  You and Peter
> Alfke are great resources to help pass along these Xilinx details to people who need
> them.  So please see my continuing desire to understand in a positive light  :-)
>
> When there is no clock activity, there is no CLKFB and there is no CLKIN for the
> Xilinx DLL.  Since the DLL was "trained" earlier by a clock that caused the DLL to
> choose a delay tap, the delay is set and fixed (for now).  When the clock starts up
> again, the CLKIN has an edge but CLKFB is absent.  Once CLKIN propagates through the
> delay line, CLKFB will be present and (if CLKIN has the same period it had before) the
> phases will match.  The only "window" is CLKIN relative to CLKFB.  So if a clock has
> been absent long enough for CLKFB to flatline, the new phase alignment is arbitrary.
>
> If the above sequence of events doesn't describe the operation, what is the window
> referenced to?
>
> - John
>
> Austin Lesea wrote:
>
> > John_H,
> >
> > No there is not a free running clock.  There is a delay line.
> >
> > The incoming edge stops happening.  The delay line empties out.
> >
> > There is no CLKFB signal now.
> >
> > Now you start again.  The CLKFB signal comes in again (some cyles later).  When it
> > does, it has to be in the window wrt to the CLKIN signal, or you lose lock.
> >
> > Austin


Article: 35124
Subject: FS DATA I/O 2900 Proramming Fixture
From: tonys2@aol.com (TonyS2)
Date: 22 Sep 2001 00:30:34 GMT
Links: << >>  << T >>  << A >>
Priced for quick turnover
apparently unused
Contact
Tony Stein



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