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
Hi, I want to do multiplication operation in my Microblaze's Test_Application in Xilinx Plaform Studio. But i get some errors.can you help me? This my code temp1=j=16; temp2=temp1*0.5;//error occurs when i use " * " *com2=(temp2); These are the error messages /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section .text) /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section .text) /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .init [00000050 -> 00000073] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .fini [00000074 -> 0000008f] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .rodata [00000090 -> 00000374] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .data [0000037c -> 000003a7] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .ctors [000003a8 -> 000003af] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .dtors [000003b0 -> 000003b7] overlaps section .text [00000050 -> 00002463] /cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real: section .jcr [000003b8 -> 000003bb] overlaps section .text [00000050 -> 00002463] collect2: ld returned 1 exit status make: *** [TestApp_Memory/executable.elf] Error 1Article: 123051
On 14 Aug., 08:58, Antti <Antti.Luk...@googlemail.com> wrote: > On 14 Aug., 08:53, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > > > hi > > > is there a reason why the clock divisor for the spi clock in edk 9.1 > > cant be smaller than 16? > > i would need 4. is there a way to do that or do i have to write my own > > spi module? > > > thanks > > urban > > its simpler to write your own, besides the OPB_SPI is very bad in > terms of logic levels, > very often it is reducing the max clock of the entire system > > hm, I think some xilinx ref design includes some other SPI core > and there is free SPI core from finger lakes also > > http://spreadsheets.google.com/ccc?key=ptIl7po0K1kGmgMEYsJIUPw > there are some links > > Antti hi thanks for the answer but i can't open the file. it says i don't have access rights. urbanArticle: 123052
On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote: > Hi, > > I want to do multiplication operation in my Microblaze's Test_Application > in Xilinx Plaform Studio. > But i get some errors.can you help me? > > This my code > > temp1=j=16; > temp2=temp1*0.5;//error occurs when i use " * " > *com2=(temp2); > You're doing some floating point multiplication which causes the floating point math libraries to be linked in, which is then causing you to run out of code memory space. Try dividing by 2 instead of * 0.5. If you really do want to do floating point math, you'll have to increase the size of your memory. Cheers, JonArticle: 123053
On Aug 14, 9:53 pm, bruce_hw_...@hotmail.com wrote: > I am using the MIG generated DDR2 controller in a V5 device. The DDR2 > runs at 266 MHz. I am meeting timing, but I am finding the performance > of the controller to be a little dissapointing. Which MIG version are you using? Xilinx changed the controller algorithm between versions 1.6 and 1.7 of MIG. In a Xilinx webcast on the MIG DDR2, they explained that one of the areas that people may want to modify is the bank switching algorithm, as their controller can only maintain a limited number of banks open at a time. This will probably have an impact on your random access performance. Have you compared the bus utilisation with that when you write contiguous blocks? That way, you will know for definite if that is your issue. AndrewArticle: 123054
On Aug 13, 7:37 pm, pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > AndrewBurnsidewrote: > > Certainly Xilinx has DDR 1/2 controllers available that plug onto > > their micro cores. > > I can not find them, are you sure? > > > This would be less error prone than hacking around with a MIG design, > > unless producing a controller is the main part of your academic > > project. > >From the IP section of the Xilinx website: Multi Channel OPB DDR2 Controller The Xilinx Multi-Channel On-chip Peripheral Bus Double Data Rate Synchronous DRAM (MCH OPB DDR2 SDRAM) controller for Xilinx FPGAs provides a DDR2 SDRAM controller that connects to the OPB and multiple channel interfaces and provides the control interface for DDR2 SDRAMs. It is assumed that the reader is familiar with DDR2 SDRAM and the MCH protocol.Article: 123055
Are you sure you need > (greater than) operator here? This requires a subtraction and a carry chain, so your counter needs two carry chains and won't pack. Can you use not-equal instead? (This also applies to < (less than) operator) Alan Nishioka On Aug 14, 6:17 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > What does this "PACKER" warning > mean? > > Lut _ driving carry _ can not > be packed with the carry due > to conflict with the common > signal requirement between Lut > inputs and the Carry DI/MAND pins. > This would result in an extra Lut > for a feedthrough. > > Here is the VHDL code: > > count_int_proc:process(clk) > begin > if(clk'event and clk='1')then > if(reset='1')then > count_int <= start_value; > elsif( enable='1') then > if(up='1' and count_int<max)then > count_int<=count_int+1; > elsif( down='1'and count_int>0) then > count_int<=count_int-1; > end if; > end if; > end if; > end process; > > Thanks, > Brad Smallridge > AI VisionArticle: 123056
Hi, I increased the size of the memory and i checked the "Enable Floating Point Unit".Still i am facing with same errors. >On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote: >> Hi, >> >> I want to do multiplication operation in my Microblaze's Test_Application >> in Xilinx Plaform Studio. >> But i get some errors.can you help me? >> >> This my code >> >> temp1=j=16; >> temp2=temp1*0.5;//error occurs when i use " * " >> *com2=(temp2); >> > >You're doing some floating point multiplication which causes the >floating point math libraries to be linked in, which is then causing >you to run out of code memory space. > >Try dividing by 2 instead of * 0.5. > >If you really do want to do floating point math, you'll have to >increase the size of your memory. > >Cheers, >Jon > >Article: 123057
Martin, At the end this will result in using LUT's as long shift register or a DPRAM as FIFO, doesn't it? A memory based approach can save up the usage of LUTs. I think it's best to implement by using block RAM's. Luc On Tue, 14 Aug 2007 18:52:39 -0000, m <martin.usenet@gmail.com> wrote: >I have to delay a pulse train by a given number of clocks on the same >domain as the pulse to be delayed. > >The best approach I can think of is to run a counter of sufficient >width and log pulse transitions and states into a circular "pulse >transition list" of sufficient depth. After waiting for the desired >number of clock transitions (the delay) an output counter of the same >width as the input sample counter is allowed to start counting. This >counter is used to address the "pulse transition list" to generate a >delayed output that matches the input. > >Using SelectRAM memory for delay is out of the question as too much >memory would be required and it is needed elsewhere in the design. > > >Can anyone suggest a better way to do this? The incoming pulses are >relatively regular and can be of any duration, from a few clocks to >hundreds. > >Thanks, > >-MartinArticle: 123058
On Aug 14, 2:50 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I have designed an SDRAM controller and nearly ready to synth and P&R. My > question is do I need to add any offset constraints to the ucf? I see that > the Xilinx XAPP134 uses them but the newer DDR designs which are generated > using MIG do not. Any info would be appreciated? > > Cheers > > Jon It's important to constrain any timing that is critical to the SDRAM. Normally you can use offset constraints to require outputs to switch within a specified time of the input clock. However in a design where all of the outputs are constrained to use IOB flip-flops, there is really no room for place & route to change the timing offset, unless you're not using global clock resources. This may be why there are no offset constraints in the MIG.Article: 123059
Hi, You are mixing int and floating-point types without an explicit type-casting. The default implicit type-casting in C for floating point is to use double-precision. Since the HW FPU for microblaze is only for single-precision, the software-based double precision library is needed and this libary will be linked in to your application. You should avoid implicit type-casting and you also have to decide if you need double precision floating point or single precision. This example can be done completely using integer operation and would make the program size much smaller. You can check the size of the program with mb-size and see if it fits into the memory. Göran Bilski "mfgunes" <mfgunes@yahoo.com> wrote in message news:vMadnfW6uvJrcl_bRVn_vgA@giganews.com... > Hi, > I increased the size of the memory and i checked the "Enable Floating > Point Unit".Still i am facing with same errors. > > > > > >>On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote: >>> Hi, >>> >>> I want to do multiplication operation in my Microblaze's > Test_Application >>> in Xilinx Plaform Studio. >>> But i get some errors.can you help me? >>> >>> This my code >>> >>> temp1=j=16; >>> temp2=temp1*0.5;//error occurs when i use " * " >>> *com2=(temp2); >>> >> >>You're doing some floating point multiplication which causes the >>floating point math libraries to be linked in, which is then causing >>you to run out of code memory space. >> >>Try dividing by 2 instead of * 0.5. >> >>If you really do want to do floating point math, you'll have to >>increase the size of your memory. >> >>Cheers, >>Jon >> >> > >Article: 123060
Hi Andrew, thanks for your response. I'm using MIG version 1.7. I have modified the contoller code to fix a bug where the MULTI_BANK_EN is incorrectly being defined as an integer 1. This is now defined as 1b'1. Before I did that the controller would issue a new active command even when the next access was to a bank/row that was already open. I have run a test where all of my accesses are to the same bank and row. The test would write 128 bytes (toggling only col address bits) read it back, write another 128 bytes, read it back, and so on. This test achieved 51% data bus utilization. If I did a similar test where only bank address bits toggled I could sustain 41% utilization. Neither of these scenarios are very practical, but it tells me that even under the best conditions the bus is idle half the time. If I only read, or only write, than the controller can come close to 100% utilization, but that's not going to do me much good. -BruceArticle: 123061
Keep increasing the memory until the error messages go away. If that is "too much memory" then you cannot use floating-point. Note that "multiply by 0.5" is equivalent to "divide by 2" is equivalent to (for integer variables) "shift right by 1". >Hi, >I increased the size of the memory and i checked the "Enable Floating >Point Unit".Still i am facing with same errors. >Article: 123062
Hi John, As far as I can tell until now I think it is an issue of the placement of the FFs in the datapath to the RAM. I think next I will try to find a stable configuration (w. Chipscope) and then directly lock the placement of these FFs, we'll see if that helps. I'll probably get back to you once I have more news. Thanks & Cheers, MichaelArticle: 123063
DRAM is tricky because of the multiplexed row/column addresses, and the need to consider device refresh. DDR is tricky because of the need to output and acquire data on both edges of the clock. Use old-fashioned SRAM if at all possible. Unless you are an 'intellectual masochist' with a lot of spare time...Article: 123064
Hi, I recently created a Google custom search engine called ChipHit at http://www.chiphit.com. Please take a look and provide suggestions. I spend many hours a day searching the internet for ASIC, FPGA, and EDA tool topics as I am ASIC/FPGA applications engineer. Frequently, when searching, I would come across results from Google that would require significant digging to get to the "right" answer. It was very frustrating. One day I was searching for a particular topic and came across a feature of Google that allows you to customize the Google search engine by telling the engine to only search specific sites. So, I started populating the engine with a few sites, and quickly realized that this could be valuable to more than just me. I went home, bought the ChipHit domain name and bought some space on a web hosting service, and began madly customizing the Google search engine. So, the next time you are searching for an ASIC, FPGA, or EDA topic, why not check out http://www.chiphit.com. Thanks, TedArticle: 123065
Initial impression is that it looks rather useful. Ta!Article: 123066
On Aug 14, 8:17 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > What does this "PACKER" warning > mean? > > Lut _ driving carry _ can not > be packed with the carry due > to conflict with the common > signal requirement between Lut > inputs and the Carry DI/MAND pins. > This would result in an extra Lut > for a feedthrough. > > Here is the VHDL code: > > count_int_proc:process(clk) > begin > if(clk'event and clk='1')then > if(reset='1')then > count_int <= start_value; > elsif( enable='1') then > if(up='1' and count_int<max)then > count_int<=count_int+1; > elsif( down='1'and count_int>0) then > count_int<=count_int-1; > end if; > end if; > end if; > end process; > > Thanks, > Brad Smallridge > AI Vision If you use an integer subtype for count_int and check for "not(count_int - 1 < 0)" or "not (count_int + 1 > max)" then the carry out of the incrementor and decrementor can be shared with the respective comparison (and/or similarly optimized). That's also assuming max = 2**N-1 for positive integer N. Don't try this with SLV or UNSIGNED. AndyArticle: 123067
m <martin.usenet@gmail.com> wrote: >On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote: >> Huffman run-length encoding has been used successfully in early- >> generation fax machines. >> Whether that or any other compression (e.g. edge-detection) scheme is >> good, depends on the characteristics of the bitstream in question. >> Peter Alfke > >I should have also mentioned that there's a need to delay more than >one such pulse streams (at least four). That would require about >twenty 18K BRAMS...I use that many without going to a significantly >larger device. I think the description of your solution in your original post was rather confused. To me your "circular pulse transition list" needs to be a FIFO. If you only record transitions you need wide counters and FIFO to handle wide pulse spacing. A very long 1 bit FIFO is the opposite extreme. The optimum will be run length encoding with a FIFO width of something in between (assuming there is no pattern to the pulse data which a compression scheme could exploit). 1 bit to indicate the data state and n bits of count of clock cycles at that state. For multiple streams you can add more data bits and use only one set of encoding/decoding logic and one larger FIFO. --Article: 123068
bruce_hw_guy@hotmail.com wrote: >Hi Andrew, thanks for your response. > >I'm using MIG version 1.7. I have modified the contoller code to fix >a bug where the MULTI_BANK_EN is incorrectly being defined as an >integer 1. This is now defined as 1b'1. Before I did that the >controller would issue a new active command even when the next access >was to a bank/row that was already open. > >I have run a test where all of my accesses are to the same bank and >row. The test would write 128 bytes (toggling only col address bits) >read it back, write another 128 bytes, read it back, and so on. This >test achieved 51% data bus utilization. If I did a similar test where >only bank address bits toggled I could sustain 41% utilization. >Neither of these scenarios are very practical, but it tells me that >even under the best conditions the bus is idle half the time. > >If I only read, or only write, than the controller can come close to >100% utilization, but that's not going to do me much good. I suppose this has to do with transaction pipelining and ordering. In theory you can setup a read or write access in another bank so it commences right after finishing the current bank. This make the controller a lot more complex. Don't forget the MIG tool is a demonstrator! -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 123069
It is interesting to see the Rent's rule.
You can help me better understand the relationship.
For example, suppose :
Xilinx FPGA has a regular structure of CLBs.
Each CLB contains one SWITCH BOX and 4 SLICEs.
Each SLICE has approximately 40 pins.
Each CLB has approximately 400 pins.
Consider, device 1 has 100 CLBs and device 2 has 10000 CLBs.
According to your posting:
Device 2 is supposed to have "100^1.5" times more wires than device 1.
Device 2 is supposed to have "100^2" more area than device 1.
Am I understanding correctly?
It was mentioned that:
--------------------------------------------------------------
Number of wires grows at a rate of somewhat over g^1.5 and the area
of the wires (because the avarage length is g^0.5) grows faster than
g^2
--------------------------------------------------------------
Could you please explain why :
(1) Average length is "g^0.5",
==> Does this 'length' mean by "wire length" ?
How did you obtain the value '0.5' ?
(2) Number of wires grows over "g^1.5",
==> How did you obtain the value '1.5' ?
(3) Area of wires grows faster than "g^2" ?
==> How did you obtain the value '2' ?
It will be appreciated if you provide some example :).
Thank you very much.
Article: 123070ted wrote: > Hi, > > I recently created a Google custom search engine called ChipHit at > http://www.chiphit.com. Please take a look and provide suggestions. > > I spend many hours a day searching the internet for ASIC, FPGA, and > EDA tool topics as I am ASIC/FPGA applications engineer. Frequently, > when searching, I would come across results from Google that would > require significant digging to get to the "right" answer. It was very > frustrating. One day I was searching for a particular topic and came > across a feature of Google that allows you to customize the Google > search engine by telling the engine to only search specific sites. So, > I started populating the engine with a few sites, and quickly realized > that this could be valuable to more than just me. I went home, bought > the ChipHit domain name and bought some space on a web hosting > service, and began madly customizing the Google search engine. > > So, the next time you are searching for an ASIC, FPGA, or EDA topic, > why not check out http://www.chiphit.com. > > Thanks, > Ted > looks interesting ...Article: 123071
Pasacco, you are mixing up two things: Renz' rule, and real FPGAs A real FPGA family does not span a 100-to-one size ratio. Usually just 10-to-1. In Xilinx FPGAs, the area is roughly proportional to the number of CLBs or Slices or LUTs, pick your preferred measurement. This picture gets more complex due to the large number of non-CLB elements (BRAMs, I/O, multipliers, CPUs etc.) that also populate the FPGA. And play a very important role in making the FPGA fast, efficient, and competitive. I assume yours is a theoretical discussion... Peter Alfke On Aug 15, 10:14 am, Pasacco <pasa...@gmail.com> wrote: > It is interesting to see the Rent's rule. > > You can help me better understand the relationship. > > For example, suppose : > Xilinx FPGA has a regular structure of CLBs. > Each CLB contains one SWITCH BOX and 4 SLICEs. > Each SLICE has approximately 40 pins. > Each CLB has approximately 400 pins. > > Consider, device 1 has 100 CLBs and device 2 has 10000 CLBs. > > According to your posting: > Device 2 is supposed to have "100^1.5" times more wires than device 1. > Device 2 is supposed to have "100^2" more area than device 1. > Am I understanding correctly? > > It was mentioned that: > -------------------------------------------------------------- > Number of wires grows at a rate of somewhat over g^1.5 and the area > of the wires (because the avarage length is g^0.5) grows faster than > g^2 > -------------------------------------------------------------- > > Could you please explain why : > > (1) Average length is "g^0.5", > ==> Does this 'length' mean by "wire length" ? > How did you obtain the value '0.5' ? > > (2) Number of wires grows over "g^1.5", > ==> How did you obtain the value '1.5' ? > > (3) Area of wires grows faster than "g^2" ? > ==> How did you obtain the value '2' ? > > It will be appreciated if you provide some example :). > Thank you very much.Article: 123072
On 14 Aug., 03:52, David Bishop <dbis...@vhdl.org> wrote: > Xilinx said that they were going to fix this in 9.3. I have not had a > chance to check it out yet, but I would try that first. Thanks for the info. 9.3 isn't released yet, do you have any idea when it will be? AndreasArticle: 123073
Brad Smallridge wrote:
> What does this "PACKER" warning
> mean?
The fitter feels guilty about one of the LUTs it used.
It's just a warning.
Unless I were short on LUTs I would
not spend time on it.
The code looks ok to me.
You could combine the up/down input.
-- Mike Treseler
Article: 123074nospam wrote: > m <martin.usenet@gmail.com> wrote: > > >>On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote: >> >>>Huffman run-length encoding has been used successfully in early- >>>generation fax machines. >>>Whether that or any other compression (e.g. edge-detection) scheme is >>>good, depends on the characteristics of the bitstream in question. >>>Peter Alfke >> >>I should have also mentioned that there's a need to delay more than >>one such pulse streams (at least four). That would require about >>twenty 18K BRAMS...I use that many without going to a significantly >>larger device. > > > I think the description of your solution in your original post was rather > confused. > > To me your "circular pulse transition list" needs to be a FIFO. If you > only record transitions you need wide counters and FIFO to handle wide > pulse spacing. A very long 1 bit FIFO is the opposite extreme. > > The optimum will be run length encoding with a FIFO width of something in > between (assuming there is no pattern to the pulse data which a compression > scheme could exploit). > > 1 bit to indicate the data state and n bits of count of clock cycles at > that state. For multiple streams you can add more data bits and use only > one set of encoding/decoding logic and one larger FIFO. A good idea, but what if you want co-incident edges ? Perhaps a small phase-nudge field, that passes to the IO block, and allow sequential FIFO unloads, but coincident IO edges ?. -jg
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