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
Jonathan Bromley wrote:
> It uses formal analysis techniques to locate multi-cycle
> paths and check the validity of your multi-cycle constraints.
> BluePearl's tool does somewhat similar things.
>
> I suspect that both are likely to be priced out of reach
> of typical FPGA users, though.
Most likely.
These tools might provide rehab for a critical design
that is already hooked on multi-cycle constraints.
However, for a new design, I would rather keep the
monkey off my back in the first place.
-- Mike Treseler
Article: 123326
Hi Forumees,
Anyone have any experience simulating the verilog model of the DDR
SDRAM Controller in modelsim?
I am trying to use the following command -
#compile the encrypted ddr controller in the work
#dir
vlog ${ddrc2_ctl_dir}/_src/ddr_c2_sctl.vo
#re-compile ddr controller in work directory
#this substituting the white-box blocks in
#the database
vlog ${ddrc2_ctl_dir}/_src/ddr_c2_sctl_example_top.v \
+libext+.v+.vo -y ${ddrc2_ctl_dir}/_sim \
-y ${ddrc2_ctl_dir}/_sim/testbench \
-y ${ddrc2_ctl_dir}/_src \
-y ${ddr_sdram_megacore_rootdir}/lib \
-v $env(QUARTUS_ROOTDIR)/eda/sim_lib/altera_mf.v \
-v $env(QUARTUS_ROOTDIR)/eda/sim_lib/220model.v \
-v $env(QUARTUS_ROOTDIR)/eda/sim_lib/sgate.v \
-v $env(QUARTUS_ROOTDIR)/eda/sim_lib/${sim_family_name}_atoms.v
The command does not have any problems running. But it does not
compile the auk_ddr_ctlr module. I do not know why? BTW, I have
verified that the tcl variables are pointing to the correct path.
I appreciate any help.
Thank you.
Best regards,
Sanjay
Article: 123327John Larkin wrote: > On Thu, 23 Aug 2007 07:34:02 -0700, "Eddie H" <> wrote: > > >>It needs to run at around 5 MHz. Yes the traces will be long about 24 inches or more. >> >>Eddie > > > Then to make it really clean, put the resistors near the FPGA and make > R1 || R2 equal to the trace impedance, which will source-terminate the > line. > > I don't know which cml parts you're using, so check my math as regards > levels. Also see my earlier post, with a 3 resistor solution. That allows matching of signal-swing levels, and impedance, independently. -jgArticle: 123328
On Fri, 24 Aug 2007 07:44:35 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >John Larkin wrote: >> On Thu, 23 Aug 2007 07:34:02 -0700, "Eddie H" <> wrote: >> >> >>>It needs to run at around 5 MHz. Yes the traces will be long about 24 inches or more. >>> >>>Eddie >> >> >> Then to make it really clean, put the resistors near the FPGA and make >> R1 || R2 equal to the trace impedance, which will source-terminate the >> line. >> >> I don't know which cml parts you're using, so check my math as regards >> levels. > >Also see my earlier post, with a 3 resistor solution. >That allows matching of signal-swing levels, and impedance, >independently. > Right. That would likely result in less loading of the FPGA pin, too. He probably only needs 0.8 volts of swing, maybe less. JohnArticle: 123329
I want to build a reconfigurable region that has no static routing inside. In the 8.2 version of the tools this was possible using the ROUTING=CLOSED constraint of the AREA_GROUP for the reconfigurable region. When I upgraded to the 9.1 version of the tools I got errors indicating that ROUTING is not a valid constraint. Anyone know of another constraint that would do the trick?Article: 123330
I looked through the constraints guide and I couldn't even find the ROUTING modifier for the area group constraint. I look in both the 8 and 9 versions of the guide. Is this some undocumented feature? As far as I know, by reading the constraints guide, there are no real routing constraints to make routes go in a region or stay out of one. ---Matthew Hicks > I want to build a reconfigurable region that has no static routing > inside. In the 8.2 version of the tools this was possible using the > ROUTING=CLOSED constraint of the AREA_GROUP for the reconfigurable > region. When I upgraded to the 9.1 version of the tools I got errors > indicating that ROUTING is not a valid constraint. > > Anyone know of another constraint that would do the trick? >Article: 123331
Hi all, Am I the only one who finds the digital magazine subscription of Xcell Journal very annoying? Is there a place where I can download the new editions as a pdf-file? Thanks and Regards, Christian, DenmarkArticle: 123332
"Christian Obel" <christian@coo.dk> wrote in message news:91E627C4E10634CCF346ABF7A147A5DC@in.webx.sUN8CHnE... > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Lines: 8 > Message-ID: <46ce0de8$0$90265$14726298@news.sunsite.dk> > Organization: SunSITE.dk - Supporting Open source > NNTP-Posting-Host: 82.180.32.65 > X-Trace: news.sunsite.dk > DXC=702=mT7?`I2\:k25BLkF8;YSB=nbEKnk;M<T]Q@UfnT0c7>KCIa7fD0ff8MIR:Bo9;V5nDhDY9O=9\?W2m0kLG_=RU172;b1Cb7 > X-Complaints-To: staff@sunsite.dk > > Hi all, > > Am I the only one who finds the digital magazine subscription of Xcell > Journal very annoying? Is there a place where I can download the new > editions as a pdf-file? > > Thanks and Regards, > Christian, Denmark ---------------------------------------------------- This is a VERY recent post (cut & pasted): ---------------------------------------------------- On 22 Aug, 21:07, Weng Tianxiang <wtx...@gmail.com> wrote: > On Aug 20, 1:54 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > Somebody asked for access to old XCell magazines. > > I was able to download all issues #17 through #39 ( 2Q1995 through > > 1Q2001) by clicking > > on:ftp://ftp.xilinx.com/pub/documentation/xcell/xcell17.pdf etc. > > Peter Alfke > > Hi Peter, > Do you have the newer XCell magazines to download at once? > > I like XCell very much. > > Thank you. > > Weng Here is a link: http://www.xilinx.com/publications/xcellonline/index.htm SvenArticle: 123333
On Aug 23, 8:33 am, mmihai <iia...@yahoo.com> wrote:
> On Aug 23, 3:34 am, Frank Buss <f...@frank-buss.de> wrote:
>
> > bhb wrote:
> > > for (j = 1; j<=1000; j++)
> > > {
> > > for (k = 1; k<=1000; k=k+1)
> > > {
> > > result=k*k*a+j*b+c;
> > > }
> > > }
>
> > You can improve the speed of this code by a factor of 1 million:
>
> > result=1000*1000*a+1000*b+c
>
> Yes, you can, but your reduction of the sum of sum it is not
> correct ...
> Try again :-)
My bad, I've read result+=...
--
mmihai
Article: 123334
>From my somewhat limited knowledge of the system and after asking a
colleague with more knowledge, it seems that the clocks can be safely
treated as being asynchronous to one another. It also seems that all
these different clocks are needed to avoid major logic changes. I was
hoping that I could add both period and cross-clock constraints w.r.t.
the outputs of the 4 BUFG's and also include 'DATAPATHONLY' on the
cross-clock constraints and be done with it. However, the timing
analyzer looks like it's analyzing more paths because of the 6
"clocks" going into my MUX before the BUFG. I tried doing a TIG on
the inputs to the 2 BUFG's after my logic MUX, but that was bad in
that more things than I intended were placed in this TIG in the
analysis. The system has 4 clocks but I don't think I'm constraining
it properly. Below is a simple diagram of my setup. You'd want to
view this ugly diagram definitely with a fixed-point font. The reg
clk's I show in the diagram are generated from the 40 BUFG and 60 BUFG
respectively.
(40 out) <---|----------<BUFG>------------| |----<BUFG>----> (80
out)
| | |
| DCM_0 | |
| ------------------ | |
|--->|FB 0 |--40--|---|------------------
>|------|
| | |
| |
40 --<IBUFG>--|------>|IN 2X |--80------|------------------
>| |
| | |
| 6:1 |
| | DV |--20-------------------------
>| MUX |
| | |
| |----<BUFG>---> Selectable clock 1
| | FX |--120----| |-----------10---
>| |
| ------------------ | |
| |
| | | reg clk 5 ---
>| |
| |----------<BUFG>------------| | |
| |
| | | | | reg clk 2.5 ---
>|------|
| | DCM_1 | | |
| | ------------------ | | |
| |--->|FB 0 |--40--| | |
| | |
|--|-------------------------------------|
|------>|IN 2X | |
| |
| | |
| |
| DV
|--10-----|--| |
| |
| |
| FX | | |----------
<BUFG>-----------| |
------------------ |
| | |
| |
DCM_2 | |
| |
------------------ | |
| |-->|
FB 0 |--60--|--| |----->|------|
|
| | | | |
|---120-->|
IN 2X | |--------->| |
| | | 6:1 |
| DV |--15--------------->| MUX |
| | | |----<BUFG>--->
Selectable clock 2
| FX |--30--------------->| |
------------------ | |
(CLKIN_DIV_BY_2) reg clk 7.5 --->| |
| |
reg clk 3.75 --->|------|
Article: 123335On Aug 23, 5:29 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote: > >From my somewhat limited knowledge of the system and after asking a > > colleague with more knowledge, it seems that the clocks can be safely > treated as being asynchronous to one another. It also seems that all > these different clocks are needed to avoid major logic changes. I was > hoping that I could add both period and cross-clock constraints w.r.t. > the outputs of the 4 BUFG's and also include 'DATAPATHONLY' on the > cross-clock constraints and be done with it. However, the timing > analyzer looks like it's analyzing more paths because of the 6 > "clocks" going into my MUX before the BUFG. I tried doing a TIG on > the inputs to the 2 BUFG's after my logic MUX, but that was bad in > that more things than I intended were placed in this TIG in the > analysis. The system has 4 clocks but I don't think I'm constraining > it properly. Below is a simple diagram of my setup. You'd want to > view this ugly diagram definitely with a fixed-point font. The reg > clk's I show in the diagram are generated from the 40 BUFG and 60 BUFG > respectively. > I would run the whole design on the 120 MHz clock, and then use a synchronous divider (counter + decoder) to enable the various sections appropriately. That way you have a synchronous design, no hold-time issues, and you don't have to worry too much about the distribution delays. This is going to save you a lot of headaches. You could of course also run most of the circuit on a 40 MHz clock in a similar fashion. Everything to avoid your clocking mess... Peter AlfkeArticle: 123336
Hello everybody,
I am having trouble incorporating a inout port of my custom peripheral
in EDK. I found that the wrapper of the custom IP expanded a inout
port into a tri-state _I/_O/_T. I read past posts in comp.arch.fpga
that there can be 2 remedies:
1. Using a "THREE_STATE=FALSE, IOB_STATE=BUF" in the .mpd file
OR, 2. Make the code EDK compliant by having _I, _O, _T as ports and
then EDK infer a inout port.
I tried both options but without luck. The first option (which
required the external pin name to be the same as the IP port, which I
did), synthesized and the implementation went fine, but the generated
bit file did not work as expected in the FPGA.
For option 2, I incorparated the following code,
SDA_I : in std_logic;
SDA_O : out std_logic;
SDA_T : out std_logic;
SDA_T <= sda_dir;
process (sda_dir, sda_bit)
begin
if (sda_dir = '1') then
SDA_O <= sda_bit;
else
SDA_O <= 'Z';
end if;
end process;
.....
if (sda_dir = '0')
NACK <= SDA_I;
end if;
However, the generated bit file again did not wok as expected in the
FPGA.
I would be greatly appreciate if somebody could let me know if I am
doing something wrong or missing something.
Thanks in advance,
Koustav
Article: 123337
On Aug 23, 11:32 am, bert <trala...@joepie.nl> wrote:
> Hi,
> Does anybody have any luck with running the Xilinx usb-cable driver on a
> Linux 64 system? I'm having severe problems with this. I have done the
> steps below but have run out of ideas.
> 1. system is latest opensuse 10.2 with kernel 2.6.18.8-0.5 The xilinx usb
> cable is detected as:
> $lsusb
> Bus 005 Device 001: ID 0000:0000
> Bus 001 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 007 Device 001: ID 0000:0000
> Bus 006 Device 001: ID 0000:0000
> Bus 004 Device 001: ID 0000:0000
> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
> Bus 003 Device 002: ID 03fd:0008 Xilinx, Inc.
> Bus 003 Device 001: ID 0000:0000
>
> I tried the udev driver, compiled as 32 bits but when preloaded I get
> ERROR: ld.so: object './libusb-driver.so' from LD_PRELOAD cannot be
> preloaded: ignored.
> Compiled as 64 bits gives the same problem.
> The contents of /etc/udev/rules.d/xusbdfwu.rules is:
> SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"
> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t
> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t
> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t
> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t
> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t
> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"
>
> And I think this is correct.
> f I manually run
> sbin/fxload with the options above and -D /proc/bus/usb/003/002
> I can see that the cable is addressed on the spartan 3A board, but
> afterwards a lsusb shows:
> Device 001: ID 0000:0000
> Bus 001 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 007 Device 001: ID 0000:0000
> Bus 006 Device 001: ID 0000:0000
> Bus 004 Device 001: ID 0000:0000
> Bus 003 Device 005: ID 03fd:0008 Xilinx, Inc.
> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
> Bus 003 Device 001: ID 0000:0000
>
> Any ideas? Anybody have any luck with modifying the makefile of windrvr64
> driver to get a decent 2.6.18 kerneldriver or any clue on the LD_PRELOAD
> problem?
> Taco
Have you tried the libusb-driver developed by Michael Gernoth. Read my
blog to find out more.
http://svenand.blogdrive.com/archive/55.html
Sven
Article: 123338On Aug 22, 2:06 am, ghel...@lycos.com wrote: > On Aug 21, 12:33 pm, sriman <srima...@gmail.com> wrote: > > > > > > > hi > > > i have wrote the program for nios processor. when i am trying to > > complie it, i am getting the follwing errors. can anyone help me out > > in rectificing the errors > > > **** Build of configuration Debug for project ucosii_tutorial_0_syslib > > **** > > > make -s all > > Compiling smsc_mem.c... > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c: In function `mac2ip': > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:46: error: `LAN91C111_BASE' undeclared > > (first use in this function) > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:46: error: (Each undeclared identifier is > > reported only once > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:46: error: for each function it appears > > in.) > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:46: error: > > `LAN91C111_LAN91C111_REGISTERS_OFFSET' undeclared (first use in this > > function) > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c: In function `s91_port_prep': > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:93: error: `LAN91C111_BASE' undeclared > > (first use in this function) > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:93: error: > > `LAN91C111_LAN91C111_REGISTERS_OFFSET' undeclared (first use in this > > function) > > /cygdrive/f/altera/61/ip/sopc_builder_ip/altera_avalon_lan91c111/ > > UCOSII/src/iniche/smsc_mem.c:94: error: `LAN91C111_IRQ' undeclared > > (first use in this function) > > make: *** [obj/iniche/smsc_mem.o] Error 1 > > Build completed in 43.25 seconds > > > i am using UCOS/OSII Rtos and using the simple socket server demo and > > made the necessary changes to suit to my design > > You made one too many changes: The LAN91C111 module is either missing > from your NIOS core, or you re-named it. > > There is a very specific hardware configuration needed for NIOS-uCos; > you have to have certain cores, and they must have the correct names. > > G.- Hide quoted text - > > - Show quoted text - i have just comiled with the given example. i got these errors. can u tell me what these are.. **** Build of configuration Debug for project simple_socket_server_0 **** make -s all Creating generated_app.mk... Creating system.h... Aug 24, 2007 11:13:18 AM - (SEVERE) generate: java.lang.IllegalStateException: java.lang.IllegalStateException: java.lang.NumberFormatException: empty String make[1]: *** [system_description/../obj/system.h-t] Error 1 make: *** [system_project] Error 2 Build completed in 80.344 secondsArticle: 123339
Hi, I would like to make a test in which I try to prove the differences in speed between DSPs and FPGAs. The test could be implemented in C for the DSP or the PC, and in VHDL for FPGA. Perhaps some image processing. Any suggestion?Article: 123340
John_H <newsgroup@johnhandwork.com> wrote: ... > Here is a link: http://www.xilinx.com/publications/xcellonline/index.htm But these are single article PDFs, not whole magazine PDFs, as far as I can tell... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 123341
Hi, I've been working on Virtex 4 with a DDR2 controller for about 1 year now and it works fine. The controller is based on MiG generated controller that we modified. The changes were some little bug fixes and changes in the user interface. This controller uses the ISERDES / OSERDES so that at the end, the physical interface of DDR2 is 8 bits at 250 MHz and the user interface internally is 32 bits at 125 MHz. For Virtex 5 there doesn't seem to be such a design yet (with control and user interface running at half the frequency) so we just tried to use the one we used on virtex 4. Personnaly I don't see why this would not work. The control part is pure HDL and the IO part uses components that are present in both V4 and V5 and I couldn't see any difference in them. But unfortunatly we didn't manage to make it work. My colleagues worked on it part of last week and I worked on it theses last 3 days without success. The simulation is OK but on the physical board it just doesn't calibrate (i.e. it doesn't manage to do a single good read even when trying all possible IDELAY values for DQ/DQS delaying). Does any one know of any differences between V4 and V5 that would make it un-usable ? Or particular points I should pay attention to ? Thanks, SylvainArticle: 123342
Hello All,
I am using Virtex II pro for a design with PPC,Timer,
Bram, OCM, PLB,OPB. The Bram is attached on the OCM bus. I have done
the Bram's PORT_B ports as external in order to load a stimuli vhdl
file(as testbench) in order to load address and data and then these to
be read through Port_A from the PPC. I came along some problems that i
cannot find the answers.
My bram is 32x32. The data and the address is 32 bits long. A part of
the code is:
Bram_WEN_B_pin <= transport ("1111");
Bram_Addr_B_pin <= transport
std_logic_vector' ("00000000000000000000000000000001) ---address
location 1
Bram_Dout_B_pin <= transport
std_logic_vector' ("00000000000000000001000100010001) -- data 1111
(a) Should all the 4 bits of the WEN_B be always all ones when
writing?
(b) The address locations i am writing are from 0-15, ( total range
0-255). These BRAM locations migth be captured by other IPs?
(c) The data port of the Brams becomes as XXXXXF83532XXX..blablbla. ok
these are from (8:29) range but the XXX from where these bits are
filled?
(d) I cannot find the flag bit that the PPC sends back to the BRAM at
the address point 16 so from there i can read the flag and load new
data after an interval of time.
thank you very much.
regards
Xenix
Article: 123343Hello out there, I don't know whether this is the right group to post this message. Still, I'll try anyway. For a few weeks I'm using the Xilinx ISE 9.2i WEBPack. I wrote my code in vhdl, simulated and post-simulated it until I was satisfied with the results. So far so good. Then I JTAGged it to the Spartan-3 Starter Board, which went fine in Xilinx ISE 8.1, but to my amazement doesn't work in 9.2i. It just says "failed", the "DONE" pin doesn't go up. I looked at the properties of the bit generator, but I don't know if, nor what I'm doing wrong. Does anyone of you know of this problem. Does anyone have a solution? I can't find anything at Xilinx. Thanks RutgerArticle: 123344
>John_H <newsgroup@johnhandwork.com> wrote: > >... >> Here is a link: http://www.xilinx.com/publications/xcellonline/index.htm > >But these are single article PDFs, not whole magazine PDFs, as far as I can >tell... > From: http://www.xilinx.com/publications/xcellonline/xcell_60/index.htm "On this site, you can download individual articles for reading or printing. Or if you like, you can read the magazine in its entirety by registering for a FREE subscription immediately available in digital format." Hope that helps!Article: 123345
>Hi, > >I would like to make a test in which I try to prove the differences in >speed between DSPs and FPGAs. The test could be implemented in C for >the DSP or the PC, and in VHDL for FPGA. Perhaps some image >processing. > >Any suggestion? > > There are 3 kinds of lies: lies, damn lies, and benchmarks. ;-) For instance, in FFT benchmarks, the quoted speeds for DSPs are produced from carefully-optimised Assembler sub-routines. For an FPGA, the speed will depend on how many multipliers are being used in parallel, and the pipelining of the data flow. The implementation is likely to be optimal for one length of transform only.Article: 123346
svenand wrote:
> On Aug 23, 11:32 am, bert <trala...@joepie.nl> wrote:
>> Hi,
>> Does anybody have any luck with running the Xilinx usb-cable driver on a
>> Linux 64 system? I'm having severe problems with this. I have done the
>> steps below but have run out of ideas.
>> 1. system is latest opensuse 10.2 with kernel 2.6.18.8-0.5 The xilinx usb
>> cable is detected as:
>> $lsusb
>> Bus 005 Device 001: ID 0000:0000
>> Bus 001 Device 001: ID 0000:0000
>> Bus 002 Device 001: ID 0000:0000
>> Bus 007 Device 001: ID 0000:0000
>> Bus 006 Device 001: ID 0000:0000
>> Bus 004 Device 001: ID 0000:0000
>> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
>> Bus 003 Device 002: ID 03fd:0008 Xilinx, Inc.
>> Bus 003 Device 001: ID 0000:0000
>>
>> I tried the udev driver, compiled as 32 bits but when preloaded I get
>> ERROR: ld.so: object './libusb-driver.so' from LD_PRELOAD cannot be
>> preloaded: ignored.
>> Compiled as 64 bits gives the same problem.
>> The contents of /etc/udev/rules.d/xusbdfwu.rules is:
>> SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"
>> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
>> SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t
>> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
>> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
>> SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t
>> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
>> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
>> SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t
>> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
>> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
>> SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t
>> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
>> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
>> SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t
>> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
>> ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"
>>
>> And I think this is correct.
>> f I manually run
>> sbin/fxload with the options above and -D /proc/bus/usb/003/002
>> I can see that the cable is addressed on the spartan 3A board, but
>> afterwards a lsusb shows:
>> Device 001: ID 0000:0000
>> Bus 001 Device 001: ID 0000:0000
>> Bus 002 Device 001: ID 0000:0000
>> Bus 007 Device 001: ID 0000:0000
>> Bus 006 Device 001: ID 0000:0000
>> Bus 004 Device 001: ID 0000:0000
>> Bus 003 Device 005: ID 03fd:0008 Xilinx, Inc.
>> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
>> Bus 003 Device 001: ID 0000:0000
>>
>> Any ideas? Anybody have any luck with modifying the makefile of windrvr64
>> driver to get a decent 2.6.18 kerneldriver or any clue on the LD_PRELOAD
>> problem?
>> Taco
>
> Have you tried the libusb-driver developed by Michael Gernoth. Read my
> blog to find out more.
> http://svenand.blogdrive.com/archive/55.html
>
> Sven
thanks, but I exactly did this xx times. I've this driver, but it doesn't
want to be preloaded somehow. The 64 bits neither. I've now only once
succeeded in loading the driver and the cable is recognized, but
programming failed. after quitting impact I get again the same problems and
a careful repetition of all actions gives the same result. Because the
cable is showing with correct ID in lsusb listings, I suppose that the udev
stuff is executed (I presume the name Xilinx is somewhere in these hex
files). I'm afraid this is (again) a kernel issue with the opensuse 64 bit
handling. Trying to do it with a different 32 bit PC... Asking xilinx for a
working kernel driver will not help I presume.
Taco
Article: 123347
On Aug 24, 6:52 am, Bert <trala...@joepie.nl> wrote:
> svenand wrote:
> > On Aug 23, 11:32 am, bert <trala...@joepie.nl> wrote:
> >> Hi,
> >> Does anybody have any luck with running the Xilinx usb-cable driver on a
> >> Linux 64 system? I'm having severe problems with this. I have done the
> >> steps below but have run out of ideas.
> >> 1. system is latest opensuse 10.2 with kernel 2.6.18.8-0.5 The xilinx usb
> >> cable is detected as:
> >> $lsusb
> >> Bus 005 Device 001: ID 0000:0000
> >> Bus 001 Device 001: ID 0000:0000
> >> Bus 002 Device 001: ID 0000:0000
> >> Bus 007 Device 001: ID 0000:0000
> >> Bus 006 Device 001: ID 0000:0000
> >> Bus 004 Device 001: ID 0000:0000
> >> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
> >> Bus 003 Device 002: ID 03fd:0008 Xilinx, Inc.
> >> Bus 003 Device 001: ID 0000:0000
>
> >> I tried the udev driver, compiled as 32 bits but when preloaded I get
> >> ERROR: ld.so: object './libusb-driver.so' from LD_PRELOAD cannot be
> >> preloaded: ignored.
> >> Compiled as 64 bits gives the same problem.
> >> The contents of /etc/udev/rules.d/xusbdfwu.rules is:
> >> SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"
> >> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> >> SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t
> >> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> >> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> >> SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t
> >> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> >> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> >> SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t
> >> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> >> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> >> SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t
> >> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> >> BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
> >> SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t
> >> fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
> >> ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"
>
> >> And I think this is correct.
> >> f I manually run
> >> sbin/fxload with the options above and -D /proc/bus/usb/003/002
> >> I can see that the cable is addressed on the spartan 3A board, but
> >> afterwards a lsusb shows:
> >> Device 001: ID 0000:0000
> >> Bus 001 Device 001: ID 0000:0000
> >> Bus 002 Device 001: ID 0000:0000
> >> Bus 007 Device 001: ID 0000:0000
> >> Bus 006 Device 001: ID 0000:0000
> >> Bus 004 Device 001: ID 0000:0000
> >> Bus 003 Device 005: ID 03fd:0008 Xilinx, Inc.
> >> Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
> >> Bus 003 Device 001: ID 0000:0000
>
> >> Any ideas? Anybody have any luck with modifying the makefile of windrvr64
> >> driver to get a decent 2.6.18 kerneldriver or any clue on the LD_PRELOAD
> >> problem?
> >> Taco
>
> > Have you tried the libusb-driver developed by Michael Gernoth. Read my
> > blog to find out more.
> >http://svenand.blogdrive.com/archive/55.html
>
> > Sven
>
> thanks, but I exactly did this xx times. I've this driver, but it doesn't
> want to be preloaded somehow. The 64 bits neither. I've now only once
> succeeded in loading the driver and the cable is recognized, but
> programming failed. after quitting impact I get again the same problems and
> a careful repetition of all actions gives the same result. Because the
> cable is showing with correct ID in lsusb listings, I suppose that the udev
> stuff is executed (I presume the name Xilinx is somewhere in these hex
> files). I'm afraid this is (again) a kernel issue with the opensuse 64 bit
> handling. Trying to do it with a different 32 bit PC... Asking xilinx for a
> working kernel driver will not help I presume.
> Taco
Xilinx mentioned a few months ago that they were going to support an/
the open-source driver w/ their tools and it was in fact being shipped
to certain beta users. The link to the exact post is on the libusb-
driver website under the link "XILINX listened". I bet if you asked
you may be able to get the driver for beta testing in your
environment.
-- Mike
Article: 123348On 24 Aug., 08:36, Pablo <pbantu...@gmail.com> wrote: > Hi, > > I would like to make a test in which I try to prove the differences in > speed between DSPs and FPGAs. The test could be implemented in C for > the DSP or the PC, and in VHDL for FPGA. Perhaps some image > processing. > > Any suggestion? The usual suspects for good results in FPGAs are: - DNA pattern matching (smith-waterman algorithm) - DES breaking - logic simulation, especially fault modeling and ATPG But essentially all these benchmarking in the hardware field only tests your grad studen vs. my grad student. For example have a look at commercially available AES or Reed-Solomon- Decoders. There is a variance in efficiency (processing power per LUT) of several orders of magnitude. So how do you compare that to a DSP implementation? The same DSP implementation might be 10x faster as one FPGA solution and 10x slower than another. And this is essentially the result of past research in that area: For anything that does not fit perfactly on the MAC-Architecture of current DSPs the FPGA has the higher potential processing power. However, it is much easier to exploit the potential of an DSP compared to the potential of an FPGA. A large FPGA in the hands of someone like Ray Andraka is extremely fast. Your avarage EE Major however might be better of with a DSP. Kolja SulimmaArticle: 123349
http://www.samtec.com/sudden_service/current_literature/powerposer.asp I saw this and thought of comp.arch.fpga . I'm not endorsing this, just a 'FYI'. I wonder if any of you guys have used this yet? I see it uses the X2Y caps we mentioned a few months back. Anyway, I hope it's interesting. Cheers, Syms.
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