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
Franz Hollerer <franz.hollerer@ims.co.at> wrote: >>> Thus dear Xilinx programmers please note: >>> - NEVER ignore the return code of a program. >>> - Always return 0 on success and a value between 1 and 255 if an >>> error has occured. >> >> This really makes me wonder. >why? Because it's so basic. What other things can be in the same shape..Article: 121526
austin <austin@xilinx.com> wrote: >Mike, > >Easy. Just introduce a "new and improved" incompatible version, and >remove support for the old one. > >Another way of saying "the original soft processor was so bad, that we >redesigned it..." > >Thankfully, MicroBlaze(tm) soft processors followed the Harvard RISC >architecture, and we got it right the first time. Where I live harvard architecture means exit... Having a seperated code and data area causes a lot of overhead in software because each pointer needs to be extended with the memory type it is pointing to. It also makes the CPU more complicated because you need twice the amount of memory move instructions which wastes opcode combinations which could have been used for other usefull instructions for functions that usually take several instructions (like bit set, clear, and, or, xor). And why not use an ARM core? That would have made a lot more sense than creating something completely new. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 121527
Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message news:468e1bce$0$13850$ba620e4c@news.skynet.be... > I've had some contacts with Xilinx a few months ago regarding the Xilinx > Platform Cable USB and the horrible Windriver they use. I pointed out that > there are clean, free and open-source solutions to interface USB devices > from userspace that would solve many user issues with Windriver (not even > talking about the numerous security holes). People listened, developers > didn't act. A piece of the chain is probably broken in the middle. As long > as companies will refuse offers such as "I can make your software work > better, here's how, and I'm willing to spend time on this to help you for > free", we won't get decent softwares. We listened. The open source cable drivers are in alpha in 9.2.01i and are being made available to select customers for evaluation. SteveArticle: 121528
The answer is quite simple. For the equation: q=a*b library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; use IEEE.NUMERIC_BIT.ALL; signal t : std_logic_vector(19 downto 0); signal q : std_logic_vector(15 downto 0); signal a : std_logic_vector(3 downto 0); siganl b : std_logic_vector(15 downto 0); t <= a * b; process(clk) begin if clk'event and clk='1' then q <= t(15 downto 0); -- for integer multiplication end if; end process; xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx The use of IEEE.NUMERIC_BIT.ALL library allows you to use '*' to automatically sythesize and simulate the multipliers without the use of coregen. Keep in mind the product size is the vector sizes added together. Inputs should be clocked registers, to prevent transiants which will cause longer multiplication settling times. The multipliers operate in this mode up to about 100MHz. Faster times are possible with pipelining using coregen. You will get warnings of unused or unconnected bits for 't'. Just make sure the bits you are using are connected. What bits to use of the product depends on the application. Fix decimal is converted to binary for hardware multiplication. (value*16) for 4bit ex. (.5*16=8 1000b) resolution is 1/16 .9 (value*256) for 8bit ex. (.5*256= 10000000b) resolution is 1/256 or .99 (value*65536) for 16bit ex. (.5*65536= 1000000000000000b) resolution is 1/65536 or .9999 a = 0010 (4 bit integer) b = 0000000000000100 (16 bit integer) t = 00000000000000001000 q = XXXX_0000000000001000 ('_' truncation point) a = .1000 (4 bit decimal value '0.5') b = 0000000000000100 (16 bit integer) t = 0000000000000010.0000 q = XXXX_000000000010.0000 (retain 4bit decimal accuracy, '_' truncation point) a = .1000 (4 bit decimal value '0.5') b = 000000000100.1000 (12 bit integer, 4bit decimal value '4.5') t = 000000000010.01000000 (value 2 + (64/256) = 2.25) q = 000000000010.0100_XXXX (retain 4bit decimal accuracy, '_' truncation point 2 + 4/16 = 2.25) I hope this helps. evansamuel@charter.netArticle: 121529
i've synthesized or1200 and it consumed 3920 slices and 7258 LUT's which are beyond what is available with my xilinx device with 400K gates. (I followed instructions ghiven in "openrisc-HW-tutorial- Xilinx.pdf".) Why does this take this much of resources? is it possible to reduce this to an acceptable level? (by removing some stuff).Article: 121530
On Jul 5, 4:42 pm, vt2001cpe <vt2001...@gmail.com> wrote: > On Jul 5, 10:41 am, vt2001cpe <vt2001...@gmail.com> wrote: > > > > > > > Hello all, > > > I am trying to generate several MAC FIR Filter cores for the same > > project. The filters range in length from 32 to 63 taps. I do not have > > any problem generating the core, but have noticed that the core > > generates a MIF file with a default name of "DATA_COEF_BUFFER.mif". > > > For example, if I generate a filter with the name my_fir, all the > > files, including an additional MIF file are generated with the name > > my_fir.*. However, the MIF file pointed to in the my_fir.vhd file is > > DATA_COEF_BUFFER.mif. > > > This is not too much of a problem if you have one such core. However, > > I would like to have several. So for my case: > > > my_fir_1.vhd > > my_fir_2.vhd > > > each generate DATA_COEF_BUFFER.mif (the second core generated > > overwrites the first file). In order to simulate the cores, Modelsim > > wants the DATA_COEF_BUFFER.mif for each of the cores in the simulation > > directory. I tried changing the vhd file to point at the my_fir.mif, > > but the simulation does not work. > > > I am hoping that this is just a simulation problem, and that synthesis > > will look at he my_fir.mif instead of DATA_COEF_BUFFER.mif, but I > > would like a simulation of this model before moving to hardware. > > > Any ideas? Thanks! > > Additionally, I have noticed that the my_fir.mif contains a correct > hex copy of the coefficients. However, the DATA_COEF_BUFFER.mif has > incorrect values. Regenerating the core does not correct the > discrepancies in the mif files.- Hide quoted text - > > - Show quoted text - I created a completely new project and the DATA_COEF_BUFFER.mif file now contains the correct taps, but in a different order. I assume the ordering is based on how the core chose to optimize the filter. Additionally, I found that I had pathed the DATA_COEF_BUFFER.mif file incorrectly in the my_fir.vhd file. Everything now works as expected. However, I still believe that Xilinx should modify the DATA_COEF_BUFFER.mif file to be named something unique, thus allowing for multiple cores in a single directory. If someone has a better solution, please let me know. Thanks!Article: 121531
On 25-Jun-2007, "hitsx@hit.edu.cn" <hitsx@hit.edu.cn> wrote: > double a,b,c,d; > int i,j,m; > for (i=1;i<ii;i++) > for (j=1;j<jj;j++) > for (k=1;k<kk;k++) > c = (a * b + c) / d; Depending on the accuracy and bit size. You can get upto 160ns per calculation of 'c' using 16 bits. '(a*b+c)/d' is performed in one clock cycle. The division operation requires a higher rate clock to complete the operation within the aloted time. Worst case is 2.4us for 64bit. This varies depending whether pipelining can be used. Once the process is created, and tested, further optimization may be possible to get more speed. It all depends on the application. Division is the slow down, if 'd' is converted to decimal faster multiplcation can be used resulting in 2ns (500mhz clock) per calculation of ((a * b + c) * (1/d)). Thats 500million complete calculations per second or 1000 million multiplications, and 500 million additions. As you can see more complex equation could be performed with in a single cycle providing even more performance advandages over a DSP. If you can provide more detail on the equations and accuracy of the variables. I can give you much more accurate times and whether a DSP is better for your application. evansamuel@charter.netArticle: 121532
Water, >From our experts: " I recommend setting the OOB detection level (OOBDETECT_THRESHOLD_0) to 3'b100. In order to generate the TX OOB siganls, you must correctly assert the two ports TXCOMSTART and TXCOMTYPE. Refer to the GTP user guide (P.111) for more info on how to create COMRESET and COMWAKE. When the loopback mode is set to 001 and 010, the GTP is in near-end PCS and near-end PMA mode respectively. That means you receive the data you send out. All other modes will not loop transmitted data back to the receiver. Based on the received data in this case the ALIGN primitive (BC-7B-4A-4A), I suspect either the user clocks or clock correction attributes may not be set correctly. It will not be easy to debug the exact issue you are facing through newsgroup thread. I recommend you to take a look at the attached reference design. It is a working design that can link up SATA Gen2 hard disk on a ML505 board. You should be able to retarget it to ML555 straightforwardly." (attachment sent to poster, directly) AustinArticle: 121533
Your email address doesn't work. Please email me directly to get the attachment, AustinArticle: 121534
Hi i am debuggin a simple program running on the Spartan3e starter kit : int main() { int k = 3; int i = 2; int j = 4; i = k; i = j+j+k; while(i < 15) { j--; i++; } return 0; } The problem is that the value "k" after i step the first time is initialised to -1 and not 3 !! if i swap "int i = 2" with "int k = 3" then i = -1 and not 2 !! .. the rest of the code can be stepped thourg with no weird behaviour .. what can be the problem?Article: 121535
Ha~~ big hug ! thanks all people here to help me. evansam...@charter.net wrote: > The answer is quite simple. > > For the equation: q=a*b > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > use IEEE.NUMERIC_BIT.ALL; > > > signal t : std_logic_vector(19 downto 0); > signal q : std_logic_vector(15 downto 0); > signal a : std_logic_vector(3 downto 0); > siganl b : std_logic_vector(15 downto 0); > > t <= a * b; > > process(clk) > begin > if clk'event and clk='1' then > q <= t(15 downto 0); -- for integer multiplication > end if; > end process; > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > The use of IEEE.NUMERIC_BIT.ALL library allows you to > use '*' to automatically sythesize and simulate the multipliers without > the use of coregen. Keep in mind the product size is the > vector sizes added together. Inputs should be clocked registers, > to prevent transiants which will cause longer multiplication > settling times. The multipliers operate in this mode up to about 100MHz. > Faster times are possible with pipelining using coregen. > > You will get warnings of unused or unconnected bits for 't'. > Just make sure the bits you are using are connected. > > What bits to use of the product depends on the application. > Fix decimal is converted to binary for hardware multiplication. > (value*16) for 4bit ex. (.5*16=8 1000b) resolution is 1/16 .9 > (value*256) for 8bit ex. (.5*256= 10000000b) resolution is 1/256 or .99 > (value*65536) for 16bit ex. (.5*65536= 1000000000000000b) resolution is > 1/65536 or .9999 > > > a = 0010 (4 bit integer) > b = 0000000000000100 (16 bit integer) > t = 00000000000000001000 > q = XXXX_0000000000001000 ('_' truncation point) > > a = .1000 (4 bit decimal value '0.5') > b = 0000000000000100 (16 bit integer) > t = 0000000000000010.0000 > q = XXXX_000000000010.0000 (retain 4bit decimal accuracy, '_' truncation > point) > > a = .1000 (4 bit decimal value '0.5') > b = 000000000100.1000 (12 bit integer, 4bit decimal value '4.5') > t = 000000000010.01000000 (value 2 + (64/256) = 2.25) > q = 000000000010.0100_XXXX (retain 4bit decimal accuracy, '_' truncation > point 2 + 4/16 = 2.25) > > I hope this helps. > > evansamuel@charter.netArticle: 121536
You might want to try using FIR compiler core instead of the MAC FIR. I believe it has less bugs, although I am not sure. Keep us informed about what you find! /MikhailArticle: 121537
Steve Lass wrote: > We listened. The open source cable drivers are in alpha in 9.2.01i and > are being made available to select customers for evaluation. Thanks, Steve! And everyone else involved! EricArticle: 121538
Hi all, I am trying to build a sdr to demodulate am signals. i am using xilinx dds to generate my local oscillator signal. when i do simulations in matlab using an ideal cosine waveform everything works fine, but when i try to use the cosine wave my dds generated to demodulate the signal(in my matlab simulations), the demodulated signals amplitude falls off exponentially. has anybody faced such problems. what can i do to avoid this problem? Thanks, vballu.Article: 121539
steve.lass@xilinx.com wrote: > Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message > news:468e1bce$0$13850$ba620e4c@news.skynet.be... > > >>I've had some contacts with Xilinx a few months ago regarding the Xilinx >>Platform Cable USB and the horrible Windriver they use. I pointed out that >>there are clean, free and open-source solutions to interface USB devices >>from userspace that would solve many user issues with Windriver (not even >>talking about the numerous security holes). People listened, developers >>didn't act. A piece of the chain is probably broken in the middle. As long >>as companies will refuse offers such as "I can make your software work >>better, here's how, and I'm willing to spend time on this to help you for >>free", we won't get decent softwares. > > > We listened. The open source cable drivers are in alpha in 9.2.01i and > are being made available to select customers for evaluation. > > Steve Well done :) -jgArticle: 121540
<steve.lass@xilinx.com> wrote in message news:f6lscf$cvr1@cnn.xilinx.com... > Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message > We listened. The open source cable drivers are in alpha in 9.2.01i and > are being made available to select customers for evaluation. > Way to go Xilinx !!!! How about other software issues ? :) /MikhailArticle: 121541
On Jul 4, 8:15 pm, "water9...@yahoo.com" <water9...@yahoo.com> wrote: > V4 FPGA has independently RXSIGDET port signal,but V5 not. > > how to detect the signal on V5 GTP? You might want to take a look at RXELECIDLE in table 7-5 (p130, UG196 v1.3). Like RXSIGDET, it goes high when the RX differential voltage drops below the minimum threshold voltage for an OOB signal.Article: 121542
> Keep in mind > that you don't need to purchase either device to configure your FPGA. You > can always buy some flash and have a micorprocessor perform the > configuration. > Joe, Here's a solution that dedicates a small (4mmx4mm) low cost ($2), microcontroller to implement the suggested scheme. If you want to use SPI flash, then you can use the free open source version. http://www.opencores.org/projects.cgi/web/fpgaconfig/overview Or if you want to use SD/MMC flash memory cards, you can use the commercial version. http://www.base2designs.com/fpgaConfig.htm SteveArticle: 121543
I'm dealing with a multiprocessor board design. The major issue is speed. Processors should be connected to a ring but they don't have dedicated ports (similar with Serial Rapid IO on TI DSPs see here http://focus.ti.com/lit/ml/sprt405/sprt405.pdf). Each processor can address up to 2Gbytes of external SRAM/SDRAM memory and 1Mbyte of internal L2 memory. The goal is to connect the nodes on the ring (see basics here: http://www.techonline.com/learning/techpaper/192200524) so every node could address the shared memory (http://en.wikipedia.org/wiki/Shared_memory) and data may flow between any pair of nodes. How will you address the shared memory to achieve the goal ? thx, VasileArticle: 121544
On Jul 2, 2:05 pm, "jjlind...@hotmail.com" <jjlind...@hotmail.com> wrote: > Hello, I'm trying to decide to use an EPC16 or EPCS64 to program the > Stratix II EP2S601020C3 on my board. Can any comment which method is > better/faster? Altera's development kits are using the EPCS64 so I > leaning that direction. > > Thanks, > joe The better methode looks M25P64 without any compressed code inside and fastest serial solution. Using another microcontroller just for configuration (and not other purposes) seems to me a weird option even if harware cost less than $2 and programming/debugging/PCB design another $20. VasileArticle: 121545
i've checked out the binutils for or1k from opencores.org. the downloaded files contain two files with .diff extensions. it does not download most of headers and implementations files. Please let me know how to use these patch files to obtain the other stuff. thanksArticle: 121546
Hi all, i am designing a system in which we have a bram block,microblaze processor and other essential component.i have written verilog code for bram controller .i have to call this verilog code by a c programe. C code is: #include "stdio.h" #include "xparameters.h" #include "xuartlite_l.h" #include "mb_interface.h" int main(void) { int i,j,k; int *mem; int fill_value = 0x10000001; //basic uart test print ("hello world\r\n"); for (k=0;k<1;k++){ //fill in values at consecutive addresses mem= (int*)0x10000032; for (i=0;i<50;i++) { *mem = i; xil_printf("%x\t%d\n\r",mem,*mem); mem++; } //read back these values mem = (int*)0x10000032; for (i=0;i<55;i++) { print("ADDRESS="); xil_printf("%x",mem); print("\tfill_value="); xil_printf("%d",i); print("\tread="); xil_printf("%d",*mem); print("\r\n"); mem++; } print("\n\r done OK!"); } print("\n\rdone!"); for (;;); } The address of the bram controller is from 10000000 to 10001fff but this c code is not calling the verilog code written for the controller so please suggest possible changes to achieve it.Article: 121547
steve.lass@xilinx.com wrote: >Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message >news:468e1bce$0$13850$ba620e4c@news.skynet.be... >> I've had some contacts with Xilinx a few months ago regarding the Xilinx >> Platform Cable USB and the horrible Windriver they use. I pointed out that >> there are clean, free and open-source solutions to interface USB devices >> from userspace that would solve many user issues with Windriver (not even >> talking about the numerous security holes). People listened, developers >> didn't act. A piece of the chain is probably broken in the middle. As long >> as companies will refuse offers such as "I can make your software work >> better, here's how, and I'm willing to spend time on this to help you for >> free", we won't get decent softwares. >We listened. The open source cable drivers are in alpha in 9.2.01i and >are being made available to select customers for evaluation. Good initiative. What's the public release date?Article: 121548
yaa... xilinx ISE -9.1i webpack is available for free.. download.. i am using it comfortably.. btw me too a new bie,.,. breaking my head to get things working on FPGA..s:-) On Jul 6, 8:39 am, vssumesh <vssumesh_a...@yahoo.com> wrote: > I dont think yoy are a newbie and i am not a FPGA expert... > Anyway contact your local dealer from whome you bought this board. > They might have some evaluation version of the latest ISE. Also if > your design is for small FPGA you can use latest xilinx webpack which > is freely available at xilinx site. > regards > Sumesh V SArticle: 121549
Hi Steve, steve.lass@xilinx.com wrote: > Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message > news:468e1bce$0$13850$ba620e4c@news.skynet.be... > >> I've had some contacts with Xilinx a few months ago regarding the Xilinx >> Platform Cable USB and the horrible Windriver they use. I pointed out >> that there are clean, free and open-source solutions to interface USB >> devices from userspace that would solve many user issues with Windriver >> (not even talking about the numerous security holes). People listened, >> developers didn't act. A piece of the chain is probably broken in the >> middle. As long as companies will refuse offers such as "I can make your >> software work better, here's how, and I'm willing to spend time on this >> to help you for free", we won't get decent softwares. > > We listened. The open source cable drivers are in alpha in 9.2.01i and > are being made available to select customers for evaluation. thanks for the good news. Sorry for the rant but I hadn't heard from Xilinx for quite some time, and I thought the issue had just been forgotten. Laurent Pinchart
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