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 'm trying to count the number of '1' in a std_logic_vector of 64 bits. In fact, I want ot know if there are more '1' or '0'. I want to use 10 slices(MAX). So I write the following line SUM = IN(0)+IN(1)+..+IN(63); These is a error with the compilatot, so I try : SUM = '0'&IN(0) + '0'&IN(1) + .. + '0'&IN(63); no error with the compilator, but result(SUM) is false. thank for your help CedricArticle: 79326
try with SUM = '00000'&IN(0) + '000000''&IN(1) + .. + '000000''&IN(63); because the max value will be 64 so it needs a result on 7 bits. or try to declare sum as an integer ranged betwen 0 and 64 and convert element of IN signal in integer alexis "cedric" <clehobey@orange.fr> a écrit dans le message de news: 9d5f771f.0502170716.de7402f@posting.google.com... > Hi, > > I 'm trying to count the number of '1' in a std_logic_vector of 64 bits. > In fact, I want ot know if there are more '1' or '0'. > > I want to use 10 slices(MAX). > So I write the following line > > SUM = IN(0)+IN(1)+..+IN(63); > > These is a error with the compilatot, so I try : > > SUM = '0'&IN(0) + '0'&IN(1) + .. + '0'&IN(63); > > no error with the compilator, but result(SUM) is false. > > thank for your help > > CedricArticle: 79327
"Jack" <JEmoderatz@yahoo.com> wrote in message news:<1108638481.381505.324530@c13g2000cwb.googlegroups.com>... > hi all > > I am starting practicing the multi-thread programming and a simple > example is working in desktop linux machine. > After trying in same example in EDK with microblaze (standalone), the > error message is > > ---- > TestApp/src/TestApp.c : in function 'main': > TestApp/src/TestApp.c : 12 'pthread_t' undeclared > ... > ---- > > so it seems that EDK tool chain does not have pthread library and > header file. No. > How can we fix this problem ? Anyone have experience on this? You will have to port pthreads to microblaze. I'm not sure pthreads is really the most approriate threading library for MB though. Cheers, JonArticle: 79328
Vaughn, Well, you certainly have been fooled. See below, Austin Vaughn Betz wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:cuvptt$baj6@cliff.xsj.xilinx.com... > >>Vaugn, >> >>Shell and pea game: no, you do not get the entire benefit of reduced C. > > > The entire benefit would be 19% speed and dynamic power reduction. As I > said, we get about 2/3 of that maximum benefit, since not all C is metal C, > but most is. > >>Also, not all layer dielectrics are Lo-K. For example, the clock tree is >>near the top, where regular dielectric is used, isn't it? > > > We use low-k to near the top of the metal stack. At the very top, where > you're routing power and ground, you don't need (or even want it), since > high capacitance on power and ground is beneficial (helps prevent ground > bounce & vcc sag). The vast majority of the switching capacitance (clocks, > routing, ALMs, MACs, etc.) is in metal surrounded by low-k. I doubt it. The dielectric above the transistors is regular undoped glass (SiO2). K = 4.3. Then comes the lo-K after M1. M1 through M5 is all they can do as lo-K, if they do more, it sufffers major yield and reliability issues. Of maybe you haven't noticed the delamination yet? > > >>At least, we evaluated both with, and without Lo-K devices (from the same >>masks and fab), and were surprised to see only a 5% improvement. >> >>Did you do the same experiment? We were surprised. > > > We simulated everything with and without low-K, and got the ~13% improvement Nope. You did not. If you did, you would discover that the layer above the transistors and below metal 1, as well as the upper layers for clocks, etc. leads to less than expected improvements. I am pretty sure your ICDES folks just scaled everything. It would be a major project to develop, and QC spice models for both processes, and I seriously doubt anyone would bother. > I previously mentioned. I am also surprised you got only 5%. That is > certainly well below mainstream for the industry -- if everyone were seeing > such small gains, which they are. I doubt the fabs and semiconductor equipment vendors would > be pumping billions into developing low-k (and next generation extra-low-k) > dielectrics. The only folks making money on this are the equipment suppliers. No one I know asked for it. Yes, it can be a major benefit to ASIC, uP, and perhaps memories. But, it just isn't doing anything for us. Now, we will get lo-K for free, as they have the equipment and process now, butguess what? We still do not see more than a 5% improvement from V4 without lo-K to V4 with lo-K. Wow, two generations and two sets of side by side lo-K and regular experiments. Ignorance I guess is bliss. Sounds like you may have used low-k for only a few metal > layers, so perhaps that explains your disappointing experience. Nope,as I described, the only layers alloed to be lo-K for lifetime delamination issues and quality are the ones above M1, and below M5. Anymore than that, and we have see problems with fab process qual (not on our parts, but their test structures). > > >>Turns out, there is a lot more in the equations that just C. >> >>If it was just that simple, extracted simulations in spice would be >>unneeded. > > > This is backwards. As metal capacitance has become the dominant > capacitance, extracting layouts to obtain all the metal parasitics before > running SPICE has become essential to getting accurate answers. Go back > enough process generations and this was less true -- you could write up your > transistor-level schematic in a SPICE deck, simulate it with no thought of > metal, and you wouldn't be that far off for most circuits, since transistor > parasitics dominated. Now that metal dominates, you have to extract layouts > to get the metal C or you get bad answers. I can see you really have no clue about where the wire models are going. How thick is the metal, how thick is the dielectric? How close are the wires? There is R there (and lots of it). There is C there, too. There is also side wall C (the sidewalls are regular FSG, or SiO2 -- no lo-K advantage). Again, you go back and ask if they actually had foundry models for with, and without, and what the actual stack up was. One of the biggest overstatements we have seen recently is all of this nonsense about the superiority of lo-K. Its nice, don't get me wrong, but don't tout it as a miracle if you have never proven it is. You don't know. We do. Take the time to do it right, or at least study it right. Get an ICDES wire model expert to talk to you about where the lo-K is, and isn't. > > Vaughn Betz > Altera > [v b e t z (at) altera.com] > >Article: 79329
There is one that is loaded on the Spartan 3 starter kit. The source is available from the Xilinx web. You probably can get an idea of resource usage from it. The name of the subcomponent is opb_color_video_ctrl_v1_00_a. I don't know if it is a licensed IP. -Newman "FAS3" <tortoisedundee@yahoo.com> wrote in message news:sgXQd.9113$O95.8724@fe07.lga... > Hello: > > Does anyone have a opb vga core for the MicroBlaze? > > Thanks > > >Article: 79330
Here's what i'm looking for. i'm using an RPM build strategy, rather than actually creating an RPM. Using a bottom-up flow, i synthesise a block, constrain it to the bottom left hand corner of the chip using area_groups, then run a full place and route. I then want to use the placed design to generate an RPM for the block, which i can use at the next level. So i need a way to extract the placement information from the completed ncd. The floorplanner does this with the Replace Floorplan with Placement option but i have ten's of blocks to do this on each time i performa build. a0-0bArticle: 79331
Paul, Sleep is also a function of the hardware. The ppc405 core will signal that it wishes to be put to sleep with the C405CPMCORESLEEPREQ ouput signal. It is the responisbility of external user logic to actually put the processor to sleep. This external logic is non-trivial. The right place to get started is in the UserGuide for the core from Xilinx: http://www.xilinx.com/bvdocs/userguides/ug018.pdf Look at the last paragraph on page 35. Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 (fax) 617.695.9234 (web) http://www.birger.comArticle: 79332
hi Jon Can you kindly tell me how we can port pthread to emulate threading-like programming then......with what step? Could you inform me what is an appropriate threading library ? Thx for replyArticle: 79333
For simple multiplications and divisions: X << m = X * (2^m) X >> m = X / (2^m) Be sure not to lose the sign bit on multiplications (i.e. overflow). Looks like you're trying to do X >>2 i.e. a multiplication by 2 (but the o(0)<= not a(6) doesn't make any sense). You don't need to synthesize something this simple to get an idea of the combinatorial delay. If you draw this out you'll see that the prop delay is simply a wire between two flops. My advice to you would be to first understand what you're trying to do before coding it up and synthesizing. There are no shortcuts. -PaulArticle: 79334
As long as you are just doing the serial to parallel conversion at 270
Mhz, you should be OK. I'm pretty sure if you keep to one level of
logic between flip-flops and hand place the flip-flops and LUTs you can
get to 270 MHz in a virtexE-6. If doing PAR, you find out that you
can't, you can use a 135 MHz clock, and by hand routing the segment from
the pin to your first registers, you can clock the odd and even samples
into separate shift registers, one clocked on the rising edge, one on
the falling edge (or you can use the DLL to get you a 180 degree
clock). You'll need to be clever with your bit counter: a binary
counter is going to be too slow. Instead use a counter based on a shift
register (such as a Johnson counter), but DO NOT use the SRL16 in this
application because the minimum clock pulse width won't be met with a
270 MHz clock.
If your customer is going to be producing this in any volume and has not
bought his parts, moving to SpartanIII may save more than the cost of
respinning the board, and will greatly reduce your design effort.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 79335cedric wrote: > I 'm trying to count the number of '1' in a std_logic_vector of 64 bits. > In fact, I want ot know if there are more '1' or '0'. > I want to use 10 slices(MAX). > So I write the following line > SUM = IN(0)+IN(1)+..+IN(63); If you care about delay, you want a carry save adder tree, though I don't know if it will synthesize it from a sum of bits. I believe it is also close to the minimum number of slices. A full adder will add three bits and provide a two bit sum. 21 full adders, given 63 inputs, will provide 21 bits of place value 1 and 21 bits of place value 2, plus the 64th bit. The next level combines the 1's and 2's using more full adders, generating place values of 1, 2, and 4. Continue until you have only one of each place value. It might be that you don't need all the logic to only detect more '1' or '0', but you will need it all to test for '1' and '0' being equal. -- glen P.S. If this is homework, reference the newsgroup. Your instructor probably reads it, too.Article: 79336
Göran Bilski wrote: > Since both processors starts at address 0, they will start to execute > the same initialization code. > You need to use a FSL port with different constant signals for each > MicroBlaze. > The boot code would then read the FSL port to know which MicroBlaze it's. > Using this it would jump to the right code section. Dual CPU IBM S/360 have a system for exchanging a block of low memory for another block somewhere else. That let each one have its own address 0. It is extra logic in the address path, but it might work in this case. -- glenArticle: 79337
Paul wrote: > For simple multiplications and divisions: > > X << m = X * (2^m) > X >> m = X / (2^m) > > Be sure not to lose the sign bit on multiplications (i.e. overflow). > > Looks like you're trying to do X >>2 i.e. a multiplication by 2 > (but the o(0)<= not a(6) doesn't make any sense). > > You don't need to synthesize something this simple to > get an idea of the combinatorial delay. If you draw this > out you'll see that the prop delay is simply a wire between > two flops. > > My advice to you would be to first understand what you're trying > to do before coding it up and synthesizing. There are > no shortcuts. > > -Paul Paul, My second question was a general question about combination delay, not specific to the design we are looking at. Yes, I think theres a fix I need to make in this code. I would apprecu=iate if you could aadvise on the combination delay question/ ThanksArticle: 79338
y <= x is a wire assignment; there is no logic in the path. Your combinatorial delay is the of the actual wire on the chip, with all the routing switchbox overhead. Read the Altera or Xilinx device reference manual section which explains the circuit architecture of the chip you're using to gain an understanding of what you're mapping to. PaulArticle: 79339
Austin Lesea wrote: > Vaughn, <snip mostly informative low-k debate> > > Again, you go back and ask if they actually had foundry models for with, > and without, and what the actual stack up was. One of the biggest > overstatements we have seen recently is all of this nonsense about the > superiority of lo-K. Carefull Austin, I think you have both agreed Low-K is better, but like the old Oscar Wilde joke, the debate centres on "how much". Sounds rather like the FPGA speed claims themselves - maybe marketing could just put this under an 'Up to 19%' umbrella ? -jgArticle: 79340
Hello,
I have a problem related with opb_ddr core for Virtex4. I'm trying to
add support for DDR to my design and when using the opb_ddr I get the
following warning which I think is related to the fact that the opb bus
hangs when reading from ddr:
WARNING:DesignRules - Blockcheck: The placed component DDR_DQS_net_O<0> has
the
REV pin connected to the signal
opb_ddr_0/opb_ddr_0/DDR_CTRL_I/dqs_setrst<0>
while the adjacent site has the placed component
opb_ddr_0/opb_ddr_0/DDR_CTRL_I/ddr_read_dqs<0> with the REV pin
unconnected.
This is a resource conflict since the unconnected pin cannot be tied off
as
part of bitstream generation. Both pins should either be connected to
the
same signal or they should both be left unconnected.
Anyone know now to fix this?
Regs,
---
Cristian
Article: 79341We are experiencing problems with our VirtexII FPGA. Preliminary debugging indicates that it may be bad hardware. We want to verify that the cells in the FPGA are good. Is there any kind of diagnostic tool available to scan FPGA and verify hardware integrity? Thanks in advance,Article: 79342
Paul wrote: > y <= x is a wire assignment; there is no logic in the path. > > Your combinatorial delay is the of the actual wire on the chip, > with all the routing switchbox overhead. Read the Altera or > Xilinx device reference manual section which explains the > circuit architecture of the chip you're using to gain an understanding > of what you're mapping to. > > Paul Paul, I guess I'm really bad at expressing myself. Ok so heres one last try of explaining my question. Lets say I do have a design which involves lot of logic (multipliers, adders, subtractors etc etc). My question is whats the best way to find out the exact delay using free Xilinx WebPack? the synthesis report does give me a max combination path delay, is that what I should be looking at? Thanks in advance.Article: 79343
"Rudolf Usselmann" <russelmann@hotmail.com> a écrit dans le message de news: cuumm1$gbc$1@nobel.pacific.net.sg... > Antti Lukats wrote: >> >> Hi Rudi, >> >> I think a bus bridgeing component for EDK can not be >> implemented fully as netlist at all, not with current >> state of the tools, and maybe never. > > Why not ? > >> So at least one file of the ip core should be HDL source >> the remaining can be netlist. The parameters are handled >> in the HDL part of of the core. >> >> Antti > > The only issue is the parameter handling, which currently > I guess are synthesized away. One way around that would be > to make the parameters real wires and have the user specify > constant values on those wire. > > That would of course defeat the whole purpose of EDK and > being able to do auto-config. Unless of course we add > another wrapper on top of the IP Core to hide this ... what > a mess ! If we have a way to plug wishbone signal between the wrapper and the ipcore(wishbone one) imported from the wizard i can live with this. Even is it's not automaticaly connected together. If we can add thoses connection in a easy way i can live with this ! > > rudi > ============================================================= > Rudolf Usselmann, ASICS World Services, http://www.asics.ws > Your Partner for IP Cores, Design, Verification and SynthesisArticle: 79344
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le message de news: 42125d33$0$311$ba620e4c@news.skynet.be... > Jonathan Dumaresq wrote: >> yes i con buit it too.. >> >> >> When I look at the system.pbd, I expected to to see a new bus for the wb. >> But i did'nt see it. I don't know if we need to see it or not. > > No you won't see a new bus. This wrapper just export all wishbone bus > signals as port. Then you need to connect them manually. How can i connect them manualy ? regards Jonathan > > >> But i see that the wrapper is connected to the opb bus as a slave. > > Yes, the opb2wb wrapper translate OPB access to WishBone access. So it's > an OPB Slave and a WishBone master. > >> The other question that i have is how to built a edk-core compatible with >> verilog file ? >> >> As i can see ther is only the vhdl file that can be use to make an edk >> core compitible. >> >> so if anyone have any idea of what we have to do to plug a simple >> wishbone GPIO connected to opbbus via the wrapper.... > > Just use the wizard and you can use a verilog design. But AFAIK, you can't > easily use a mixed verilog/vhdl ... > > > SylvainArticle: 79345
You might want to have a look at the EDK reference design for the ML401 board: http://www.xilinx.com/ml401 It does have a PLB VGA controller in the pcores directory. The PLB is used for bandwidth reasons. - Peter FAS3 wrote: > Hello: > > Does anyone have a opb vga core for the MicroBlaze? > > Thanks > > >Article: 79346
I hope everybody here realizes that there is no trade-off between triple gate oxide and low-k dielectric. They reside on different "floors" of the vertical IC structure. The availability of a third oxide thickness at the transistor level (ground floor) gives the designer the freedom to reduce leakage current in pass transistors (where it does not affect speed) and in configuration memory, where lower speed is actually desirable. We at Xilinx think it is a great tool to reduce leakage current without any performance loss, specially in FPGAs where certain (millions of) transistors would benefit from being slow. Low K dielectric (at the upper floors) hasnothing to do with the transistors, since it is used only in the layers of interconnect well above the transistors. It is obviously desirable to lower parasitic capacitance, as long as it can be done with good yield and without loss of reliability. Different foundries have different approaches and different attitudes. Thicker high-K dielectric in the gate oxide (ground floor) would actually be desirable, since it would reduce gate leakage current, but it does not seem to be a mature process yet ( I have been told. I'm not an expert). We are all chasing the holy grail of high performance at low (or at least reasonable) static and dynamic power consumption. Peter AlfkeArticle: 79347
news wrote: > Hello, > > I have a problem related with opb_ddr core for Virtex4. I'm trying to > add support for DDR to my design and when using the opb_ddr I get the > following warning which I think is related to the fact that the opb bus > hangs when reading from ddr: > > > WARNING:DesignRules - Blockcheck: The placed component DDR_DQS_net_O<0> has > the > REV pin connected to the signal > opb_ddr_0/opb_ddr_0/DDR_CTRL_I/dqs_setrst<0> > while the adjacent site has the placed component > opb_ddr_0/opb_ddr_0/DDR_CTRL_I/ddr_read_dqs<0> with the REV pin > unconnected. > This is a resource conflict since the unconnected pin cannot be tied off > as > part of bitstream generation. Both pins should either be connected to > the > same signal or they should both be left unconnected. > > Anyone know now to fix this? > > Regs, > --- > Cristian > > This is a real limitation. The phrase "adjacent site" refers to the paired ILOGIC and OLOGIC sites which share a routing resource for the REV pins. It's not possible to have one REV pin connected to this resource and the other not connected, hence the error. The fix would be to design with this limitation in mind. No other placement is possible since the ILOGIC and OLOGIC components are connected to the same pad. On a related issue, the tools will currently also error out if GND is on one REV pin and the other is not connected. Beginning with version 7.1i SP1, MAP will strip the GND connection, avoiding the error. Regards, BretArticle: 79348
Just to provide some quick numbers... here is a quick test. I'll shortly need to do many stages "wide" forward difference units, so I took a quick look at the speed. Of course, the chip was "empty", in a real design it's more difficult... This was a "push-button" design, no particular optimization was done. // Optimize for speed, -4, normal effort, xc3s400-4ft256, ISE 6.3i3 // Up-counter: q <= q + 1, registered // 16 bit: 210 Mhz // 24 bit: 191 Mhz // 32 bit: 173 Mhz // 48 bit: 148 Mhz // 64 bit: 130 Mhz // 128 bit: 87 Mhz // Addition, unsigned q <= a+b, both registered // 32 bit: 89 Mhz // 48 bit: 66 Mhz // Accumulator, q <= q + a, both reg. // 32 bit: 158 Mhz // 64 bit: 127 Mhz // 80 bit: 83 Mhz > Yeah, it seems though, that there is no difficulty counting that fast! > So I don't need to worry at all ;-) That's a nice thing!Article: 79349
Besides Linear, check also the upcoming Texas TPS75003... seems good, but still preliminary announcementl. >> I am trying to select the most efficient and low power voltage >> regulators to provide the 3.3, 2.5 and 1.2 voltages to a Spartan 3 >> (PQ208). The input power supply is 5V. >>
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