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 152575

Article: 152575
Subject: Re: Can't get the Xilinx cable drivers installed on SL6.1 (RHEL
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 15 Sep 2011 13:44:52 GMT
Links: << >>  << T >>  << A >>
On Thu, 15 Sep 2011 08:31:17 +0200, Jan Pech wrote:

> Is there any particular reason to compile your own libusb instead of
> using the distribution packages?
> 
> To make the Xilinx JTAG cable working in the RHEL/CentOS/SL 6.x do the
> following stops. There is detailed description on my website
> http://www.sensor-to-image.cz/doku.php?id=eda:xilinx but unfortunately
> it is in Czech language only. Sorry.
> 
> 1. Install and "fix" libusb:
> 
> yum install libusb libusb1 fxload
> cd /usr/lib64 (or /usr/lib if you are running 32b system) ln -s
> libusb-1.0.so.0.0.0 libusb.so
> 
> 2. "Fix" the Xilinx cable setup script
> <xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or the same path
> with lin instead of lin64) which does not detect udev correctly:
> 
> # Use udev always
> #TP_USE_UDEV="0"
> #TP_UDEV_ENABLED=`ps -e | grep -c udevd` TP_USE_UDEV="1"
> TP_UDEV_ENABLED="1"
> 
> 3. Run the script from its directory:
> 
> cd <xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or lin instead
> of lin64)
> ./setup_pcusb
> 
> 4. Generated udev rule uses wrong syntax. The rule for current version
> of udev /etc/udev/rules.d/xusbdfwu.rules must look like this (long lines
> must be retained, see my website for proper formatting):
> 
> # version 0003
> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd",
> ATTR{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I
> /usr/share/xusbdfwu.hex -D $tempnode" SUBSYSTEM=="usb", ACTION=="add",
> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0009", RUN+="/sbin/fxload -v
> -t fx2 -I /usr/share/xusb_xup.hex -D $tempnode" SUBSYSTEM=="usb",
> ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d",
> RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $tempnode"
> SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd",
> ATTR{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I
> /usr/share/xusb_xlp.hex -D $tempnode" SUBSYSTEM=="usb", ACTION=="add",
> ATTR{idVendor}=="03fd", ATTR{idProduct}=="0013", RUN+="/sbin/fxload -v
> -t fx2 -I /usr/share/xusb_xp2.hex -D $tempnode" SUBSYSTEM=="usb",
> ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="0015",
> RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_xse.hex -D $tempnode"
> 
> 5. Connect/reconnect your cable, check dmesg, test iMPACT/ChipScope.
> 
> Regards,
> Jan
> 
> 
> Sorry if the post appears twice. I had some problems posting the
> message.
> 
> 
> 
> On Thu, 2011-09-15 at 03:02 +0000, General Schvantzkoph wrote:
>> On Thu, 15 Sep 2011 12:42:21 +1000, Steve wrote:
>> 
>> > On 09/15/2011 08:51 AM, General Schvantzkoph wrote:
>> >> Has anyone been able to get Impact or Chipscope working on
>> >> SL6.1/CentOS6/ RHEL6?
>> >>
>> >> It failed with the xsetup GUI but it only gave a useless error
>> >> message that it failed in the log.
>> >>
>> >> When I tried to run the install script in
>> >>
>> >> LabTools/LabTools/bin/lin64/install_script/install_drivers
>> >>
>> >> I got a bunch of compile errors, apparently it's incompatible with a
>> >> 2.6.32 kernel.
>> >>
>> >> I also couldn't find libusb-driver in 13.2, the most recent copy
>> >> that I had was in 10.
>> >>
>> >>
>> > I had a similar problem getting my Xilinx USB-JTAG cable working on
>> > Fedora 13.  I ended up using the open source Linux driver instead,
>> > works fine:
>> > 
>> > http://rmdir.de/~michael/xilinx/
>> > 
>> > Steve Ecob
>> > Silicon On Inspiration
>> > Sydney Australia
>> 
>> I've already tried to build the libusb-driver but it won't build on
>> SL6.1.

Thanks that worked.


Article: 152576
Subject: Re: FPGA acceleration v.s. GPU acceleration
From: "fpga_me" <linuxfreak87@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 15 Sep 2011 09:42:31 -0500
Links: << >>  << T >>  << A >>
>If I choose FPGA co-processing, the algorithm will be specifically
>optimized and R&D time will be very noticeable. If I choose GPU plan,
>algorithm migration will cost little time(even the original one is
>Matlab code), and the acceleration performance will also be quite
>well.

I like the way you are looking at this issue, that is, from a cost
efficiency point-of-view. 

>As a conclusion, the FPGA acceleration only suits some certain and
>fixed application. However in the real world , many projects and many
>algorithms are very uncertain and arbitrary. With same power
>consumption, GPU plan  may lead better results. For a concrete
>project, I will consider GPU or DSP, and FPGA at last.

Again, here it boils down to cost efficiency and how you choose to measure
it. Can we devote the time to optimize the algorithm for the FPGA? Can we
afford to make it massively parallel to reduce latency? Does it even matter
if the latency is worse than the GPU? Is the cost performance ratio better
than that of the GPU? And so on... 

The way you use "suit" and "certain" is extremely subjective. If as the
system architect, I see that though my system is not optimized for latency,
for example, it may still be acceptable to use depending on system
requirements and cost efficiency. Rarely does one get a system spec that
states "Run as fast as possible." 
 
>Do everybody agree?

Cost efficiency rules here. How can you measure it? Power, latency, area,
throughput, NRE, etc. Simply saying that FPGAs can't implement a function
as good as a GPU because of fabric differences is not the best way to say
"it is worse than a GPU." In short, the system specs and ultimately the
cost efficiency says use the GPU or FPGA or CPU...and it will tell you
which is better for *your* application.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152577
Subject: Re: reduce EDK synthesis time
From: "fpga_me" <linuxfreak87@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 15 Sep 2011 10:26:10 -0500
Links: << >>  << T >>  << A >>
Echoing what others have said. You should really use versions greater than
11.4. This is because Xilinx changed a lot of the backend algorithms. ISE
is now noticeably faster than <11.4. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152578
Subject: Re: Xilinx Tin Whiskers ?
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 15 Sep 2011 11:53:31 -0500
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> On Sep 15, 10:11 am, Jon Elson <jmel...@wustl.edu> wrote:
>> This new condition is different, and
>> shows REALLY typical-looking tin whiskers that are growing out of the
>> bends of the gull-wing leads on these Xilinx QFP parts.
> 
> Interesting location, suggests stress helps ?
> 
This is a known part of the whisker problem, if you read the literature.
Compressive stress will produce the whiskers, tensile stress suppresses
the whisker growth.  Funny, these sort of look like they are coming from
the outer side of the bend, but there may be initial tensile stress
there that then becomes compressive when the reflow relaxes strains
in the lead.
> Are these on both bends, & on the compression, or tension part of
> each ?
It SEEMS that these are mostly showing up on the back of the
first bend up from the PC board, that would be the second bend
out from the package body, and facing toward the package.
> 
> Were these manually or reflow soldered ?
> At Lead-based, or Lead-free temperatures ? Post cleaned or not ?
These are lead-free parts, soldered with 63/37 Tin/Lead solder
paste (Shenmao solder paste distributed by Manncorp), and reflowed
onto Tin/Lead plated 6-layer PC boards with a peak reflow temp
actually measured on the board of about 235 C.  (My batch reflow oven
has a thermocouple that I poke into a through-hole on one of the boards
near the center to monitor actual substrate temperature.)
But, then as I am still getting my solder stencil technology
figured out, I had to do a bunch of rework to remove solder
shorts.)

THEN, the boards were stored for about 6 months, and now when I inspected
them, I see the whisker growth.  The boards were not cleaned after reflow,
but were cleaned just before this inspection.

Thanks for the comments and questions!

Jon

Article: 152579
Subject: Re: Xilinx Tin Whiskers ?
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 15 Sep 2011 11:59:56 -0500
Links: << >>  << T >>  << A >>
Nico Coesel wrote:


> 
> My guess is that you'll need to look at the temperature profile of the
> soldering process. I'd get some lead-free soldering experts to look at
> the problem.
> 
My feeling on this is that the whiskers have been growing over the
6 months of storage, and that whisker growth is not possible during
the reflow.  I believe all the other parts on the board are ALSO lead-free,
and the whiskers are ONLY showing up on this ONE part.  And, we use
other Xilinx parts where it is NOT showing up.  ONLY on the 100-lead
QFP, but not on 44- or 144-lead parts.

Searching the literature, I have NOT found anyone who says temperature
profile has ANY effect on whisker growth.  Alloys, stresses in the tin
plating, thickness of the tin plating, purity (or lack of) in the Tin,
storage conditions (humidity and thermal cycling) have all been implicated
in affecting the rate or prevalence of the whisker growth.  But, I
have never seen a paper that mentions the reflow temp profile.  If you
have a reference, I'd like to read it.

Thanks,

Jon

Article: 152580
Subject: Re: Xilinx Tin Whiskers ?
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 15 Sep 2011 17:26:41 GMT
Links: << >>  << T >>  << A >>
Jon Elson <elson@pico-systems.com> wrote:

>Nico Coesel wrote:
>
>
>> 
>> My guess is that you'll need to look at the temperature profile of the
>> soldering process. I'd get some lead-free soldering experts to look at
>> the problem.
>> 
>My feeling on this is that the whiskers have been growing over the
>6 months of storage, and that whisker growth is not possible during
>the reflow.  I believe all the other parts on the board are ALSO lead-free,
>and the whiskers are ONLY showing up on this ONE part.  And, we use
>other Xilinx parts where it is NOT showing up.  ONLY on the 100-lead
>QFP, but not on 44- or 144-lead parts.
>
>Searching the literature, I have NOT found anyone who says temperature
>profile has ANY effect on whisker growth.  Alloys, stresses in the tin
>plating, thickness of the tin plating, purity (or lack of) in the Tin,
>storage conditions (humidity and thermal cycling) have all been implicated
>in affecting the rate or prevalence of the whisker growth.  But, I
>have never seen a paper that mentions the reflow temp profile.  If you
>have a reference, I'd like to read it.

Simply use common sense and knowledge: the whiskers grow because of
stresses in the crystal structure of tin. If you (nearly) melt a metal
you'll alter the crystal structure*. Humidity and temperature may
accellerate growth of whiskers, but only if the initial stress is in
the crystal structure. Thats why I'm pointing to the temperature
profile of the soldering process as the source of the problem.

You should check whether the whiskers also grow on parts which have
not been soldered yet. I bet they don't otherwise Xilinx would have a
really big problem on their hands.

* think about hardening steel by cooling it very fast after it has
been heated close to the melting point.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 152581
Subject: Re: Xilinx Tin Whiskers ?
From: Andy <jonesandy@comcast.net>
Date: Thu, 15 Sep 2011 10:52:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 15, 11:59=A0am, Jon Elson <el...@pico-systems.com> wrote:
> Nico Coesel wrote:
>
> > My guess is that you'll need to look at the temperature profile of the
> > soldering process. I'd get some lead-free soldering experts to look at
> > the problem.
>
> My feeling on this is that the whiskers have been growing over the
> 6 months of storage, and that whisker growth is not possible during
> the reflow. =A0I believe all the other parts on the board are ALSO lead-f=
ree,
> and the whiskers are ONLY showing up on this ONE part. =A0And, we use
> other Xilinx parts where it is NOT showing up. =A0ONLY on the 100-lead
> QFP, but not on 44- or 144-lead parts.
>
> Searching the literature, I have NOT found anyone who says temperature
> profile has ANY effect on whisker growth. =A0Alloys, stresses in the tin
> plating, thickness of the tin plating, purity (or lack of) in the Tin,
> storage conditions (humidity and thermal cycling) have all been implicate=
d
> in affecting the rate or prevalence of the whisker growth. =A0But, I
> have never seen a paper that mentions the reflow temp profile. =A0If you
> have a reference, I'd like to read it.
>
> Thanks,
>
> Jon

Using pure Sn lead finishes in standard Pb soldering profiles is a no-
no.

You need to run your profile at the higher, Pb-free process
temperatures. Make sure all of your materials (board, other
components, flux, paste, etc.) can handle the higher temperatures. If
you do not get up to the Pb-free process temperatures, the Sn finish
is not annealed properly, and thus stresses between plating and base
metal are not relieved properly, thus causing an increase in Sn-
whisker growth rate.

Andy

Article: 152582
Subject: Re: Xilinx Tin Whiskers ?
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 15 Sep 2011 13:41:06 -0500
Links: << >>  << T >>  << A >>
On 09/15/2011 12:52 PM, Andy wrote:

> Using pure Sn lead finishes in standard Pb soldering profiles is a no-
> no.
>
> You need to run your profile at the higher, Pb-free process
> temperatures. Make sure all of your materials (board, other
> components, flux, paste, etc.) can handle the higher temperatures. If
> you do not get up to the Pb-free process temperatures, the Sn finish
> is not annealed properly, and thus stresses between plating and base
> metal are not relieved properly, thus causing an increase in Sn-
> whisker growth rate.
Xilinx has knowledge base articles where they specifically say that
you can safely use their lead-free parts in standard Sn/Pb solder
processes without change to the process.  Or, at least that is how I 
read what they said there.

Jon

Article: 152583
Subject: Re: The Manifest Destiny of Computer Architectures
From: Quadibloc <jsavard@ecn.ab.ca>
Date: Thu, 15 Sep 2011 11:42:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 14, 11:02=A0pm, Mark Thorson <nos...@sonic.net> wrote:
> Quadibloc wrote:
>
> > So, just as larger caches are the present-day form of memory on the
> > chip, coarse-grained configurability will be the way to increase
> > yields, if not the way to progress to that old idea of wafer-scale
> > integration. (That was, of course, back in the days of three-inch
> > wafers. Fitting an eight-inch wafer into a convenient consumer
> > package, let alone dealing with its heat dissipation, hardly bears
> > thinking about.)
>
> Oh, sure it does. =A0Just have four of them on the top
> of the box, put it in the kitchen, and call it a stove.

Ah. Do your power gaming while waiting for supper to be ready. But
silicon carbide has too many defects to run chips at that temperature
yet...

John Savard

Article: 152584
Subject: clock enable for fixed interval
From: Jim <james.knoll@gmail.com>
Date: Thu, 15 Sep 2011 12:04:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
What would be the proper way to clock a register at a fixed multiple
of the system clock?  I am trying to create a signal that is active
around the rising edge of the system clock as a clock enable.  I am
using a counter to generate a signal at the time interval of
interest.  I am then performing an edge detection to get a signal that
is active for a single system clock cycle.  To get the enable centered
around the rising edge of the system clock, I am clocking the edge
detector with an inverted system clock.  I have read not to use
anything other than the system clock as the clock signal to a flip
flop, so I am uncomfortable using the inverted clock.  Is the inverted
clock ok?  Does anyone have any recommendations on a better way to do
this.

library ieee;
use ieee.std_logic_1164.all;

entity edge_detector is
    port (
        clock : in std_logic;
        d : in std_logic;
        rising_edge_out : out std_logic
    );
end;

architecture behavioral of edge_detector is
    signal sreg : std_logic_vector(1 downto 0);
begin
    edge_detector_proc : process(clock)
    begin
        if rising_edge(clock) then
            if sreg(1 downto 0) = "01" then
                rising_edge_out <= '1';
            else
                rising_edge_out <= '0';
            end if;

            sreg <= sreg(0) & d;
        end if;
    end process;
end architecture;

entity clock_divider is
    port (
        clock : in std_logic;
        reset : in std_logic;
        clock_enable_clock_divided : out std_logic
    );
end clock_divider;

architecture behavioral of clock_divider is
    signal inverted_clock : std_logic;
    signal clock_divided_i : std_logic;
    signal count : unsigned(4 downto 0) := (others => '0');
begin
    clock_divided_edge_proc : entity work.edge_detector
        port map (
            clock => inverted_clock,
            d => clock_divided_i,
            rising_edge_out => clock_enable_clock_divided
        );

    inverted_clock <= not clock;

    clock_divider_counter_proc: process (reset, clock)
    begin
        if reset = '1' then
            count <= (others => '0');
            clock_divided_i <= '0';
        elsif rising_edge(clock) then
            count <= count + 1;
            clock_divided_i <= count(4);
        end if;
    end process;
end behavioral;

Article: 152585
Subject: LFSR in xilinx 13.2
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Thu, 15 Sep 2011 14:38:33 -0500
Links: << >>  << T >>  << A >>
Hi,
I am using xilinx 13.2 for my design synthesis and i want to use xilinx IP
for LFSR but i cannot find it in core gen. I am using Spartan3 xc3s4000
FPGA.

Does anyone know where i can find it?


regards
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152586
Subject: Re: LFSR in xilinx 13.2
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 15 Sep 2011 15:47:03 -0500
Links: << >>  << T >>  << A >>
On Thu, 15 Sep 2011 14:38:33 -0500, salimbaba wrote:

> Hi,
> I am using xilinx 13.2 for my design synthesis and i want to use xilinx
> IP for LFSR but i cannot find it in core gen. I am using Spartan3
> xc3s4000 FPGA.
> 
> Does anyone know where i can find it?

The actual LFSR description should take two or three lines, and it's not 
the kind of thing that needs superhuman effort to optimize, particularly 
if it's an internal XOR type.

An extern XOR type with a whole lot of taps might benefit from some 
pipelining, but even that shouldn't be too hard.

So maybe they didn't think they needed to bother.

-- 
www.wescottdesign.com

Article: 152587
Subject: Re: LFSR in xilinx 13.2
From: OutputLogic <evgenist@gmail.com>
Date: Thu, 15 Sep 2011 20:15:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Here is the link to online LFSR code generator:

http://outputlogic.com/?page_id=275

Thanks,
Evgeni



Article: 152588
Subject: Re: clock enable for fixed interval
From: backhus <goouse99@googlemail.com>
Date: Thu, 15 Sep 2011 23:14:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 15 Sep., 21:04, Jim <james.kn...@gmail.com> wrote:
> What would be the proper way to clock a register at a fixed multiple
> of the system clock? =A0I am trying to create a signal that is active
> around the rising edge of the system clock as a clock enable. =A0I am
> using a counter to generate a signal at the time interval of
> interest. =A0I am then performing an edge detection to get a signal that
> is active for a single system clock cycle. =A0To get the enable centered
> around the rising edge of the system clock, I am clocking the edge
> detector with an inverted system clock. =A0I have read not to use
> anything other than the system clock as the clock signal to a flip
> flop, so I am uncomfortable using the inverted clock. =A0Is the inverted
> clock ok? =A0Does anyone have any recommendations on a better way to do
> this.
>
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity edge_detector is
> =A0 =A0 port (
> =A0 =A0 =A0 =A0 clock : in std_logic;
> =A0 =A0 =A0 =A0 d : in std_logic;
> =A0 =A0 =A0 =A0 rising_edge_out : out std_logic
> =A0 =A0 );
> end;
>
> architecture behavioral of edge_detector is
> =A0 =A0 signal sreg : std_logic_vector(1 downto 0);
> begin
> =A0 =A0 edge_detector_proc : process(clock)
> =A0 =A0 begin
> =A0 =A0 =A0 =A0 if rising_edge(clock) then
> =A0 =A0 =A0 =A0 =A0 =A0 if sreg(1 downto 0) =3D "01" then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rising_edge_out <=3D '1';
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rising_edge_out <=3D '0';
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
>
> =A0 =A0 =A0 =A0 =A0 =A0 sreg <=3D sreg(0) & d;
> =A0 =A0 =A0 =A0 end if;
> =A0 =A0 end process;
> end architecture;
>
> entity clock_divider is
> =A0 =A0 port (
> =A0 =A0 =A0 =A0 clock : in std_logic;
> =A0 =A0 =A0 =A0 reset : in std_logic;
> =A0 =A0 =A0 =A0 clock_enable_clock_divided : out std_logic
> =A0 =A0 );
> end clock_divider;
>
> architecture behavioral of clock_divider is
> =A0 =A0 signal inverted_clock : std_logic;
> =A0 =A0 signal clock_divided_i : std_logic;
> =A0 =A0 signal count : unsigned(4 downto 0) :=3D (others =3D> '0');
> begin
> =A0 =A0 clock_divided_edge_proc : entity work.edge_detector
> =A0 =A0 =A0 =A0 port map (
> =A0 =A0 =A0 =A0 =A0 =A0 clock =3D> inverted_clock,
> =A0 =A0 =A0 =A0 =A0 =A0 d =3D> clock_divided_i,
> =A0 =A0 =A0 =A0 =A0 =A0 rising_edge_out =3D> clock_enable_clock_divided
> =A0 =A0 =A0 =A0 );
>
> =A0 =A0 inverted_clock <=3D not clock;
>
> =A0 =A0 clock_divider_counter_proc: process (reset, clock)
> =A0 =A0 begin
> =A0 =A0 =A0 =A0 if reset =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 count <=3D (others =3D> '0');
> =A0 =A0 =A0 =A0 =A0 =A0 clock_divided_i <=3D '0';
> =A0 =A0 =A0 =A0 elsif rising_edge(clock) then
> =A0 =A0 =A0 =A0 =A0 =A0 count <=3D count + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 clock_divided_i <=3D count(4);
> =A0 =A0 =A0 =A0 end if;
> =A0 =A0 end process;
> end behavioral;

Hi Jim,
using clock enables for multirate systems is a proper way, but you are
trying to do it unneccessary complicated.
It is much simpler.

You have a master clock, and a counter that provides the neccessary
frequency division.
So far so good.
Now you only need to create an impulse for a single clock period.
This can be done like this:

    clock_divider_counter_proc: process (reset, clock)
    begin
        if reset =3D '1' then
            count <=3D (others =3D> '0');
            clock_divided_i <=3D '0';
        elsif rising_edge(clock) then
            count <=3D count + 1;
            -- clock_divided_i <=3D count(4); -- this would be too long
            if count =3D "11111" then
               clock_enable_clock_divided  <=3D 1;
           else
              clock_enable_clock_divided  <=3D 0;
           end if;
        end if;
    end process;
end behavioral;

That's all you need.
When assigning to  clock_enable_clock_divided the clock to output
delay and routing delay are sufficient to
keep the signal valid beyond the next rising clock edge.
(If that wouldn't work this way pipelining data from one register to
the next wouldn't work too, but it does.)


Have a nice synthesis
   Eilert

Article: 152589
Subject: Re: LFSR in xilinx 13.2
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Fri, 16 Sep 2011 08:55:11 +0200
Links: << >>  << T >>  << A >>
"salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote in message 
news:H7-dnYe-8Nqkye_TnZ2dnUVZ_t-dnZ2d@giganews.com...
> Hi,
> I am using xilinx 13.2 for my design synthesis and i want to use xilinx IP
> for LFSR but i cannot find it in core gen. I am using Spartan3 xc3s4000
> FPGA.
>
> Does anyone know where i can find it?

http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf



Article: 152590
Subject: Re: clock enable for fixed interval
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 16 Sep 2011 08:55:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Thu, 15 Sep 2011 12:04:12 -0700, Jim wrote:

> ... I am clocking the edge detector with an
> inverted system clock.  I have read not to use anything other than the
> system clock as the clock signal to a flip flop, so I am uncomfortable
> using the inverted clock.  Is the inverted clock ok?  Does anyone have
> any recommendations on a better way to do this.

I'll let others comment on the overall strategy. Just want to point out 
that you can clock on negative edges  ... "if falling_edge(clk) then "
So an inverted clock is unnecessary.

- Brian

Article: 152591
Subject: Re: The Manifest Destiny of Computer Architectures
From: kenney@cix.compulink.co.uk
Date: Fri, 16 Sep 2011 04:13:18 -0500
Links: << >>  << T >>  << A >>
In article <j4r508$rgl$1@speranza.aioe.org>, gah@ugcs.caltech.edu (glen 
herrmannsfeldt) wrote:

> Very few problems divide up that way.  For those that do, static
> reconfiguration is usually the best choice.  Dynamic reconfiguration
> is fun, but most often doesn't seem to work well with real problems.

 Green Array are already selling processor arrays with the biggest being 
144 processors. Each processor has it's own on chip memory and fast 
communication channels with the others. They can be configured 
individually. Supplied language is Color Forth. I do not know anything 
more about this, just what I picked up reading comp.language.forth, but 
evaluation boards are available.  

 Ken Young

Article: 152592
Subject: Virtex 6 dev. board suppliers?
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Fri, 16 Sep 2011 02:24:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a Xilinx Virtex 6 based dev. board, (with PCIe and SFP
connectors for 10G Ethernet). Other than Hitech Global, what other
suppliers are there? You suggestions are much appreciated. Thanks.

Rupert

Article: 152593
Subject: Re: clock enable for fixed interval
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 16 Sep 2011 05:24:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 15, 3:04=A0pm, Jim <james.kn...@gmail.com> wrote:
> What would be the proper way to clock a register at a fixed multiple
> of the system clock? =A0I am trying to create a signal that is active
> around the rising edge of the system clock as a clock enable. =A0I am
> using a counter to generate a signal at the time interval of
> interest.

Once you have the counter, then the clock enable is simply...

Clock_Enable <=3D '1' when (Counter =3D xx) else '0';

Where 'xx' is the precise value of 'Counter' that you want to use to
enable the other logic that uses the clock enable.  Depending on how
many bits there are in 'Counter', you might find that it is better
from a timing perspective for the clock enable to be the output of a
flip flop.  This can be implemented like this...

if rising_edge(Clock) then
  if (Counter =3D (xx - 1)) then
    Clock_Enable <=3D '1';
  else
    Clock_Enable <=3D '0';
  end if;
end if;

> =A0I am then performing an edge detection to get a signal that
> is active for a single system clock cycle. =A0To get the enable centered
> around the rising edge of the system clock, I am clocking the edge
> detector with an inverted system clock. =A0I have read not to use
> anything other than the system clock as the clock signal to a flip
> flop, so I am uncomfortable using the inverted clock. =A0Is the inverted
> clock ok? =A0Does anyone have any recommendations on a better way to do
> this.
>

Simple synchronous logic like what you're describing here will never
need anything more than the rising edge of one clock.  Falling edges
are rarely needed.

Kevin Jennings

Article: 152594
Subject: Re: LFSR in xilinx 13.2
From: "FPGA ACE, LLC" <mikegulotta@gmail.com>
Date: Fri, 16 Sep 2011 05:35:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 15, 2:38=A0pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hi,
> I am using xilinx 13.2 for my design synthesis and i want to use xilinx I=
P
> for LFSR but i cannot find it in core gen. I am using Spartan3 xc3s4000
> FPGA.
>
> Does anyone know where i can find it?
>
> regards
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

In all ISE releases you can find example designs.  XAPP211: PN
Generator, is one I authored years ago.  There's a verilog and VHDL
version.  A PN Generator is basically an LFSR.  There should be enough
comments in the code to explain how to infer SRL16s (vs FFs).  Here're
some other docs in case you're interested...

Pseudo-random Noise Generators using SRLs (app note and reference
design):
(http://www.xilinx.com/support/documentation/application_notes/
xapp211.pdf)

HDL Coding for PN Generators:
(http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/
xcell/xl35/xl35_44.pdf)


Good luck,
Mike
www.fpgaace.com

Article: 152595
Subject: Re: clock enable for fixed interval
From: Marc Jet <jetmarc@hotmail.com>
Date: Fri, 16 Sep 2011 09:03:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your approach is flawed.  It will not work well because it is not in
line with the generally accepted way of FPGA programming.  It uses
asynchronous logic, which is frowned upon because the tools don't
support it well.  Insisting on using asynchronous logic will do you no
favor.

It's perfectly valid that you want a clock-enable.  However, it's
unusual that you want the clock-enable to be centered "around the
clock edge". It probably stems from working with discrete chips, where
THAT was most reliable way to enable clocks.

In logic (discrete or FPGA), it's also possible to "enable" clocks by
adding the enable as extra logic input, plus feedback of the previous
output.  Then you can "always clock" the register, yet make it only
accept (honor) the change when "enable" is active.  From the logic
point of view, this is equivalent to a real clock-enable. But from
other points of view, like for example power consumption, it may not
be.

Yet it is good enough, and it helps achieving another goal: make a
whole design from nothing but synchronous logic!  This has been a
major milestone in FPGA architecture. It's so much easier to do timing
analysis on purely synchronous designs.  In fact, the current tools do
almost exclusively synchronous analysis ("static timing").  It was
easier to make designs synchronous, than to make the tools handle
asynchronous designs..

Using synchronous logic is very important for you.  If you have any
timing problems with your design, then you've either not read the
timing report, or you've used non-synchronous tricks and are about to
regret them.

Your desire to enable clocks is very wide spread, and so the FPGA
makers have implemented support for their synchronous equivalent,
right in the hardware. The necessary extra logic input and the
feedback of the previous state is "free" in all modern (and not so
modern) FPGAs.  There is dedicated circuitry just for this purpose.

The following code shows how to register something on every other
cycle.  The tools will recognize it and use none of "your" resouces
for it.

	process (clk)
	begin
		if rising_edge(clk) then
				clkenable		<= not(clkenable);
		end if;
	end process;

	process (clk)
	begin
		if rising_edge(clk) then
			if clkenable='1' then
				reg_something		<= combinatorial_something;
			end if;
		end if;
	end process;

PS: There is another common desire for asynchronous logic in many
designs, specifically for RESET.  Read about it in other threads on
this group or elsewhere.  There's more opinion about it because doing
it wrong doesn't fail right away. Yet (in my opinion) you should also
go strictly synchronous because that's what the tools can handle.

Article: 152596
Subject: Re: clock enable for fixed interval
From: Marc Jet <jetmarc@hotmail.com>
Date: Fri, 16 Sep 2011 09:09:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your approach is flawed.  It will not work well because it is not in
line with the generally accepted way of FPGA programming.  It uses
asynchronous logic, which is frowned upon because the tools don't
support it well.  Insisting on using asynchronous logic will do you no
favor.

It's perfectly valid that you want a clock-enable.  However, it's
unusual that you want the clock-enable to be centered "around the
clock edge". It probably stems from working with discrete chips, where
THAT was most reliable way to enable clocks.

In logic (discrete or FPGA), it's also possible to "enable" clocks by
adding the enable as extra logic input, plus feedback of the previous
output.  Then you can "always clock" the register, yet make it only
accept (honor) the change when "enable" is active.  From the logic
point of view, this is equivalent to a real clock-enable. But from
other points of view, like for example power consumption, it may not
be.

Yet it is good enough, and it helps achieving another goal: make a
whole design from nothing but synchronous logic!  This has been a
major milestone in FPGA architecture. It's so much easier to do timing
analysis on purely synchronous designs.  In fact, the current tools do
almost exclusively synchronous analysis ("static timing").  It was
easier to make designs synchronous, than to make the tools handle
asynchronous designs..

Using synchronous logic is very important for you.  If you have any
timing problems with your design, then you've either not read the
timing report, or you've used non-synchronous tricks and are about to
regret them.

Your desire to enable clocks is very wide spread, and so the FPGA
makers have implemented support for their synchronous equivalent,
right in the hardware. The necessary extra logic input and the
feedback of the previous state is "free" in all modern (and not so
modern) FPGAs.  There is dedicated circuitry just for this purpose.

The following code shows how to register something on every other
cycle.  The tools will recognize it and use none of "your" resouces
for it.

	process (clk)
	begin
		if rising_edge(clk) then
				clkenable		<= not(clkenable);
		end if;
	end process;

	process (clk)
	begin
		if rising_edge(clk) then
			if clkenable='1' then
				reg_something		<= combinatorial_something;
			end if;
		end if;
	end process;

PS: There is another common desire for asynchronous logic in many
designs, specifically for RESET.  Read about it in other threads on
this group or elsewhere.  There's more opinion about it because doing
it wrong doesn't fail right away. Yet (in my opinion) you should also
go strictly synchronous because that's what the tools can handle.

Article: 152597
Subject: Re: clock enable for fixed interval
From: Jim <james.knoll@gmail.com>
Date: Fri, 16 Sep 2011 12:14:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Hi Jim,
> using clock enables for multirate systems is a proper way, but you are
> trying to do it unneccessary complicated.
> It is much simpler.
>
> You have a master clock, and a counter that provides the neccessary
> frequency division.
> So far so good.
> Now you only need to create an impulse for a single clock period.
> This can be done like this:
>
> =A0 =A0 clock_divider_counter_proc: process (reset, clock)
> =A0 =A0 begin
> =A0 =A0 =A0 =A0 if reset =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 count <=3D (others =3D> '0');
> =A0 =A0 =A0 =A0 =A0 =A0 clock_divided_i <=3D '0';
> =A0 =A0 =A0 =A0 elsif rising_edge(clock) then
> =A0 =A0 =A0 =A0 =A0 =A0 count <=3D count + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 -- clock_divided_i <=3D count(4); -- this would b=
e too long
> =A0 =A0 =A0 =A0 =A0 =A0 if count =3D "11111" then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock_enable_clock_divided =A0<=3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock_enable_clock_divided =A0<=3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 end if;
> =A0 =A0 end process;
> end behavioral;
>
> That's all you need.
> When assigning to =A0clock_enable_clock_divided the clock to output
> delay and routing delay are sufficient to
> keep the signal valid beyond the next rising clock edge.
> (If that wouldn't work this way pipelining data from one register to
> the next wouldn't work too, but it does.)
>
> Have a nice synthesis
> =A0 =A0Eilert

Eilert,

Thanks for the quick response.  After I posted, I read that FPGAs
typically have 0 hold times so your approach seems great.  Thanks for
the help.

Article: 152598
Subject: Re: The Manifest Destiny of Computer Architectures
From: Scott Michel <scooter.phd@gmail.com>
Date: Fri, 16 Sep 2011 14:49:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 14, 2:06=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > 6. =A0A new language with APL-like semantics would allow programmers to
> > state their wishes at a high enough level for compilers to determine
> > the low-level method of execution that best matches the particular
> > hardware that is available to execute it.
>
> APL hasn't been popular over the years, and it could have done
> most of this for a long time. =A0On the other hand, you might look
> at the ZPL language. =A0Not as high-level, but maybe more practical.

ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go.

Have a look at the DARPA HPCS languages, notably, Chapel, Fortress and
X10. Not entirely sure about their respective statuses, but they were
an attempt in the HPC arena to raise the level of abstraction.


-scooter

Article: 152599
Subject: Re: The Manifest Destiny of Computer Architectures
From: nmm1@cam.ac.uk
Date: Sat, 17 Sep 2011 09:44:35 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <270b4f6b-a8e8-4af0-bf4a-c36da1864692@u19g2000vbm.googlegroups.com>,
Scott Michel  <scooter.phd@gmail.com> wrote:
>On Sep 14, 2:06 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> > 6.  A new language with APL-like semantics would allow programmers to
>> > state their wishes at a high enough level for compilers to determine
>> > the low-level method of execution that best matches the particular
>> > hardware that is available to execute it.
>>
>> APL hasn't been popular over the years, and it could have done
>> most of this for a long time.  On the other hand, you might look
>> at the ZPL language.  Not as high-level, but maybe more practical.
>
>ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go.
>
>Have a look at the DARPA HPCS languages, notably, Chapel, Fortress and
>X10. Not entirely sure about their respective statuses, but they were
>an attempt in the HPC arena to raise the level of abstraction.

No, they aren't.  Sorry.  They raise the level above that of the
mainstream 1970s and 1980s languages, but not above that of later
ones such as, say, modern Fortran.

What they do do is to try to raise the level of the abstraction
of the parallelism.  I found Chapel and Fortress a bit unambitious,
and wasn't convinced that any of them were likely to be genuinely
and widely useful.  However, I mean to take another look when (!)
I get time.  May I also draw your attention to BSP?

Despite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
All viable ones have chosen a single model and stuck with it,
though sometimes (as with MPI) one programming model can be easily
and efficiently implemented on another as well.


Regards,
Nick Maclaren.



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