Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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>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.comArticle: 152577
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.comArticle: 152578
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! JonArticle: 152579
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, JonArticle: 152580
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
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. AndyArticle: 152582
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. JonArticle: 152583
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 SavardArticle: 152584
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: 152585Hi, 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.comArticle: 152586
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.comArticle: 152587
Hi, Here is the link to online LFSR code generator: http://outputlogic.com/?page_id=275 Thanks, EvgeniArticle: 152588
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"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.pdfArticle: 152590
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. - BrianArticle: 152591
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 YoungArticle: 152592
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. RupertArticle: 152593
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: 152594On 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.comArticle: 152595
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
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> 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
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. -scooterArticle: 152599
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:
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