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
All It seems to me that when I learnt Kirchoffs there should have been a caveat that these laws are almost completely pointless (even at DC!) Any decent pointers as to where to start reading would be appreciated. ColinArticle: 96401
austin <austin@xilinx.com> wrote: > Further, > Anyone who can point to a clear and simple explanation, please do. > When I first mentioned this to our packaging group, the lead engineer > said "oh yes, I see this in the EM simulations..." > So, I know I am not imagining it! Perhaps put some simulation results online, with an explanation of the input data. With simulation GIGO (garbage in, garbage out) easily comes into play. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 96402
i am quite a newbie in FPGA development. my idea is build a SoC(System on Chip) which will be a Video/Audio player based on FPGA(Xilinx Spartan 3E 1M gate count). the video and audio decoders are Vorbis for audio and Theora for video and will be almost hardware based as posible. the desgin will have a Soft CPU for directing data from CF,reading the fs and then output a bitstream to decoders. the audio decoder will output all the data to a DAC(20bit or 24 bit for better quality). the video decoder will write to a RAM which will be the LCD framebuffer. the cpu also can write to the framebuffer but it will write over decoder data so i will have some kind of osd when the decoder is playing(like for remaining time,volume and other stuff). from what i understand,doing a full ogg decoder on chip is madness so what i have to do i build coproccessors that will do most of clock-expensive and the software will use those coprocessors,right? the storage will be a CF card which are damn cheap and can work as IDEs. the part i want to know if this is posible to be done in a FPGA. i saw a guy that made a full Theora camera which use a encoder for super-high resolutions(1024x768@30FPS-->1280x1024@15FPS) on a Spartan 2E which have a 300K gates.(that desgin is 96% of the FPGA,the article is in linuxdevices) so i guess a decoder that can decode 160x120-->640x480 @25FPS streams will be alot smaller and could fit into a FPGA. i could move all the ogg vorbis decoder to a ASIC vorbis decoder(they exsist :) ) so saving the time about implenting the ogg vorbis format. what you think,it is posible? which soft cpu(s) should i use,which things the cpu need to preform real fast? is it posible on a Spartan(development boards for spartan are damn cheap). if it is important to someone the desgin(the final one) will be powered with a LiPo battery :) thx in advanceArticle: 96403
Peter Alfke wrote: > Yes, and the first computers used two triode vaccuum tubes to store a > bit, with a supply voltage around 150 V. > 60 years of Progress ! > Peter Alfke > Colossus used (afair) 4 pentodes: 2 for the flipflop, and 2 more to switch it, essentially wire-ANDed to each of the F/F tube anodes. They made each of the switch tubes act as a 2-input AND gate, using the control & screen grids independently (& at different voltage levels). Why pentodes? They were already being produced in vast numbers, for radio & radar. Triodes had much less use in that sector. An anecdote has it that when the truck driver went to requisition yet another truckload of EF36 tubes (but didn't know what they were for), the storeman asked him "what are you doing with those things? Shooting them at the Jerries?" :-)Article: 96404
nhurley wrote: > Hi Guys > > I'm looking for some die area information on FPGAs. It is prooving > quite difficult to find any information so if anyone has some pointers > or datapoints it'd be much appreciated. > > Thanks! > Quick answer: find a friendly dentist, & have him X-ray the package in question. That's what we did at work many years ago (I no longer work at that company), when we wanted to examine (non-destructively) a competitor's product.Article: 96405
On 2 Feb 2006 17:07:42 -0800, "dp" <dp@tgi-sci.com> wrote: >Austin Lesea wrote: >> ..... >> The static magnetic field will force the static electric field to be >> confined to the area adjacent to the current flow in the opposite direction. >> >> ..... > >Austin, > >sure you did not really mean that? Static magnetic fields do not >affect electric field(s) according to physics. I think the confusion is in the use of the word 'static'. A DC current produces a magnetic field (Ampere's law, and Maxwell's 4th eqn). Line up two conductors next to each other, run a current through them, and the two resultant magnetic fields will interact. An electron in bar A will move in the component of the magnetic field produced by bar B, and so will feel a force due to it. This is the proximity effect. Perhaps not all 'static', but all DC.Article: 96406
So, what's the answer? Either a) The central balls "carry no current at all", are isolated from the die GND, and are just for thermal conduction, or b) They are connected to the die GND, they do carry some return current, although less than the GND pins at the edge, and their decoupling is still important, but not very important?Article: 96407
On Fri, 03 Feb 2006 00:52:20 -0800, Caleb Leak <dornif@gmail.com> wrote: > I am trying to show the gap >narrowing between these two over time. Why would it narrow? At first sight, it should stay constant. For a given FPGA technology, the differences are simply due to the extra die resources required to implement a programmable feature as opposed to a fixed feature. This difference should stay constant as both the FPGA and ASIC move to new processes. The obvious differential is that the larger FPGA companies will be able to take advantage of a new process earlier than most ASIC customers. However, as process lifetimes increase (about 5 years now?) this differential decreases, rather than increasing. Besides, it's not in the interest of the fabs to only have a handful of customers on a new process; they want everybody on it. Another factor to take into account is that the FPGA vendor's cutting-edge devices - the first ones on 90nm, for example - are invariably large, expensive, and low yield, and so probably not useful to most customers. So, it could even be argued that the ability to take advantage of new processes isn't actually that useful anyway.Article: 96408
Hello, Please refer to this thread: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/4373c26ee4c38328/aebfcf5e6f06f52c?lnk=st&q=PLB+Master&rnum=1&hl=en#aebfcf5e6f06f52c (Google "PLB Master" in Googe Groups and this will be your first hit). Properly using the IP2IP_Addr in the IPIF is what allowed my master to work properly. Good luck, NN agou wrote: > Hi, group > > I generated a IPIC interface by the Create and Import Peripheral Wizard > > to access PLB_DDR blockon the PLB bus. > > I chose the DMA, user logic Master Support mode. And then try to > develop my own logic based on the generated files. Here, I have one > problem: > > To write to an address on PLB bus, I need to provide two addresses: > IP2IP_Addr which stores the source data and IP2Bus_Addr > to which writes the data. Do I need to instantiate a BRAM in the FPGA > to provide the source address? > > What I am not clear is whether the BRAM is compatible the IPIC logic. > Or do I have to instantiate another PLB_Bram and then hook it up to the > PLB? Are there any other simple method? > > Thank you for the help. > RogerArticle: 96409
Try make ARCH=ppc CROSS_COMPILE=<cross-compile toolchain prefix> "Anonymous" <someone@microsoft.com> schrieb im Newsbeitrag news:KitEf.959$no3.741@tornado.southeast.rr.com... > So the process is really: > > 1. get PPC cross compiler > 2. get kernel source from kernel.org > 3. generate board support packages from fpga design > 4. build kernel > 5. build ace file and boot > > So the magic is all in the BSP stuff which I assume is basically the BIOS > code in a regular PC and the libraries/memory spaces for the various > peripherals? Monte Vista is just making it easier for folks by packaging > everything in one place? > > How does the kernel source know that I'm building for a PPC target? > > Thanks, > Clark > > <tony.p.lee@gmail.com> wrote in message > news:1138904088.604673.26180@g47g2000cwa.googlegroups.com... >> >> mvista is rsync site is just mirror of the public linux kernel site. >> You don't need to pay monte vista to use it. >> >> It is not the only place to get it. >> >> -Tony >> > >Article: 96410
On 2 Feb 2006 18:25:17 -0800, "dp" <dp@tgi-sci.com> wrote: >austin wrote: >> Further, >> >> Anyone who can point to a clear and simple explanation, please do. >> >> When I first mentioned this to our packaging group, the lead engineer >> said "oh yes, I see this in the EM simulations..." >> >> So, I know I am not imagining it! >> >> Austin > >Austin, > >the only way a simulator can see DC current >resulting from a static magnetic field is a software bug >or, worse, misconcepted basics behind the software. I don't think he's talking about the magnetic field generating a DC current; but modifying the path of one that exists from other causes (the PSU). Think about those moving electrons (beta particles) in a particle detector; a static magnetic field certainly modifies their path. (Thus you can determine their velocity from its radius) Also think about the force on two busbars carrying a _DC_ current; on what does the force act? On the electrons, i.e. on the current, which (in modifying their path) apply force to the busbar. The same will apply in a BGA package; it will not generate any current, but it may redistribute it between conductors. - Brian - BrianArticle: 96411
In general, I don't think that a synthesis tool will share resources
between always blocks.
I find it best to "help" the synthesys tool where possible.
I would re-write the above code (verilog is a bit rusty)
parameter FinalCount := 8'h25 ;
wire AtFinalCount <= (process == FinalCount) ? '1' : '0' ; // or
always block
always @(clk)
begin
if (pop0 && FinalCount) || kick0
whatever <= asdf0 ;
else if
etc etc
end // always
Article: 96412
Hello all,
I have a problem with internal tristates in Xilinx Virtex-2. They
basically don't exist, although are widely used in the documentation.
Imagine you have N dual port rams with the enable inputs attached to
the output of a tristate like this:
g_loop: for x in 0 to N-1 generate
nEnable(x) <= something(x) when (connect(x) = '1') else 'Z';
end generate;
As you know, the high impedance 'Z' state doesn't really exist inside
Xilinx Virtex-2 FPGAs, and will in fact appear as a '1'. When we
perform a pre-synthesis simulation, the simulator sees the signal as a
'Z', which is not the actual behaviour. After synthesis and
translation, the signal is properly seen as '1' instead of 'Z'.
A possible solution to make pre-synthesis and post-translate
simulations behave the same would be to use multiplexers instead of
tristates. But how can we build them in VHDL with a generic number of
inputs?
Other solution would be to make the pre-synthesis simulator see a 'Z'
as a '1'. We could achieve this with a pullup component, although I
never got it to work in the past. I wonder if there is another way to
make the simulator understand a 'Z' as a '1'.
Any hints?
Regards.
Jose.
Article: 96413Austin Lesea wrote: > All, > > More heat is conducted out the bumps, through the substrate, through to > the pcb than through the backside heat spreader (without a heatsink). Howdy Austin, Could you provide a bit more detail on this? UG112 seems to say that theta JB varies too much from situation to situation to be worth publishing. If it has even more impact on cooling the device than the theta JC, it seems like more information should be provided. Furthermore, how much closer to 0 degC/W could the thermal resistance be, compared to the ~0.6 degC/W of the flip-chip packages? Or were you referring to everything except flip-chip? > Even with a heatsink, as much as half of the power is going through to > the pcb. > > I know that is hard to believe, but the heat is much closer to the > bumps, the bumps are metal (ultra low alpha lead), and they go directly > to a copper plane in the substrate (package pcb). FR4 and epoxies are > pretty good at conducting heat. > > The lead balls to the copper pcb completes the (best) heat conduction path. Isn't the heat spreader on the flip-chips also copper? It seems like going through one tiny layer of thermal grease and one layer of heatspreader would have less thermal resistance than bumps + epoxy + substrate + ball + pad + via + ground plane. I don't see mention that the substrate has a substantal amount of copper in it, but that doesn't mean it isn't there and just not well documented. > The backside of the die is almost 1 mm of SiO2 away from the area that > is hot, and has to then go through a thermal compound to get to the top > heat spreader, and then has to be mechanically bonded to a heatsink (if > you really want to get power out of the top of the package). I think you are referring to non-flip-chip here? Thank you! MarcArticle: 96414
hi
When exercising xapp290.pdf example, I met following error message
during MAP stage.
----------------------------------------------------
ERROR:Pack:1107 - Unable to combine the following symbols into a single
IOB
component:
PAD symbol "clock" (Pad Signal = clock)
BUF symbol "clock_IBUF" (Output Signal = clock_IBUF)
Each of the following constraints specifies an illegal physical site
for a
component of type IOB:
Symbol "clock_IBUF" (LOC=BUFGMUX4S)
Please correct the constraints accordingly.
----------------------------------------------------
Meanwhile, I found following Answer in Xilinx Answer browser
---------------------------------------------------
The GCLK IOs can only use IBUFGs, so the tool is unable to pack a IBUF
into the IOB. To work around this issue, specify that the net use an
IBUFG. This can be done by instantiating it in your code or adding a
BUFFER_TYPE constraint to your code with the value set to IBUFG. The
syntax for these can be found in the Software Manuals.
--------------------------------------------------
However, when I put the following attribute, still same error message
appeared.
// synthesis attribute BUFFER_TYPE clock "ibufg";
Does anyone have any suggestion? Thankyou in advance.
Article: 96415Pasacco schrieb: > > Meanwhile, I found following Answer in Xilinx Answer browser > --------------------------------------------------- > The GCLK IOs can only use IBUFGs, so the tool is unable to pack a IBUF > into the IOB. To work around this issue, specify that the net use an > IBUFG. This can be done by instantiating it in your code or adding a > BUFFER_TYPE constraint to your code with the value set to IBUFG. The > syntax for these can be found in the Software Manuals. > -------------------------------------------------- You are on the right path. It 'clock' is ffed into a GCLK pin, it must use a IBUFG! > However, when I put the following attribute, still same error message > appeared. > > // synthesis attribute BUFFER_TYPE clock "ibufg"; > > Does anyone have any suggestion? Thankyou in advance. Those damm attributes are case sensitive, even in VHDL (which is usually NOT case sensitive) use // synthesis attribute BUFFER_TYPE clock "IBUFG"; instead. But if 'clock' is used a s a clock inside your code, the compiler will detect this automatically and insert an IBUFG. So no need for explicitly using the attribute. Regards FalkArticle: 96416
Brian Drummond wrote: > ... > >the only way a simulator can see DC current > >resulting from a static magnetic field is a software bug > >or, worse, misconcepted basics behind the software. > > I don't think he's talking about the magnetic field generating a DC > current; but modifying the path of one that exists from other causes > (the PSU). > > Think about those moving electrons (beta particles) in a particle > detector; a static magnetic field certainly modifies their path. > (Thus you can determine their velocity from its radius) I really regret I have to go back to this thread. I suggest everyone posting more on this nonsense makes sure to consult at least some high-school physics books first. The electrons (or beta particles, the origin does not matter) can be moved in vacuum or in a gas because they, when moving, produce a magnetic field, which interacts with the static magnetic field, exactly in the same way as two magnet pieces interact with each other (i.e. results in a force applied to the freely moving electron). When the electrons move inside a conductor (metal), this effect is seen as a mechanical force applied to the _conductor_. It takes electric rather than magnetic field to move electrons inside the conductor. This is how electric motors work. You _cannot_ affect the path of the electrons inside the conductor by a static magnetic field, just as you cannot force them to exit the conductor. > Also think about the force on two busbars carrying a _DC_ current; on > what does the force act? On the electrons, i.e. on the current, which > (in modifying their path) apply force to the busbar. > > The same will apply in a BGA package; it will not generate any current, > but it may redistribute it between conductors. > > - Brian No. It cannot. I am tired of this thread, I would have hoped all electronics engineers would have at least some fundamental understanding of physics. Apparently there are some who don't. Anybody who has doubts please consider taking some basic course of physics. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 96417
"dp" wrote: > You _cannot_ affect >the path of the electrons inside the conductor by a static magnetic >field, just as you cannot force them to exit the conductor. Hall effect. http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html -- Phil HaysArticle: 96418
Hi , I would realy appreciate it if someone could explain the possible usage of a DCR bus (with PPC or MB). Thanks in advance, Mordehay.Article: 96419
"dp" <dp@tgi-sci.com> wrote in message news:1138977225.228637.248310@z14g2000cwz.googlegroups.com... > Brian Drummond wrote: > When the electrons move inside a conductor (metal), this effect > is seen as a mechanical force applied to the _conductor_. It takes > electric rather than magnetic field to move electrons inside the > conductor. This is how electric motors work. You _cannot_ affect > the path of the electrons inside the conductor by a static magnetic > field, just as you cannot force them to exit the conductor. > <snip> > No. It cannot. I am tired of this thread, I would have hoped all > electronics engineers would have at least some fundamental > understanding of physics. Apparently there are some who don't. > Anybody who has doubts please consider taking some basic > course of physics. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > Hi Dimiter, Did you ever learn about the Hall Effect in your physics classes? Check out:- http://en.wikipedia.org/wiki/Hall_effect There's even a nice picture for you! ;-) HTH, Syms.Article: 96420
"Phil Hays" <Spampostmaster@comcast.net> wrote in message news:q8r6u1h32albkt9oqkq0vkatko9uudniiu@4ax.com... > > Hall effect. > > > -- > Phil Hays > Phil, you beat me by 3 minutes. Dammit! Cheers, Syms.Article: 96421
Phil Hays wrote: > "dp" wrote: > > > You _cannot_ affect > >the path of the electrons inside the conductor by a static magnetic > >field, just as you cannot force them to exit the conductor. > > Hall effect. > > http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html > > > -- > Phil Hays Hall effect has negligible values in conductors. On the other hand, it may take place somewhere on the die, that might well be. If the current does not flow out of the chip into the wires there is no need to redistribute it. I hope everyone is happy now. DimiterArticle: 96422
"dp" wrote: >Phil Hays wrote: >> "dp" wrote: >> >> > You _cannot_ affect >> >the path of the electrons inside the conductor by a static magnetic >> >field, just as you cannot force them to exit the conductor. >> >> Hall effect. >> >> http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html >> >> >> -- >> Phil Hays > >Hall effect has negligible values in conductors. Not always. Same as with skin effect, it isn't always negligible at power line frequencies. Best to do the calculations before, rather than after. -- Caution: Contents may contain sarcasm.Article: 96423
Phil Hays wrote: > "dp" wrote: > > >Phil Hays wrote: > >> "dp" wrote: > >> > >> > You _cannot_ affect > >> >the path of the electrons inside the conductor by a static magnetic > >> >field, just as you cannot force them to exit the conductor. > >> > >> Hall effect. > >> > >> http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html > >> > >> > >> -- > >> Phil Hays > > > >Hall effect has negligible values in conductors. > > Not always. Same as with skin effect, it isn't always negligible at > power line frequencies. Best to do the calculations before, rather > than after. > > > -- > Caution: Contents may contain sarcasm. It has nothing to do with frequencies, and we are talking DC. And yes, it is negligible inside the conductors in the context ot the thread, this is why I did not mention it at all. If you want to pursue this further, you are welcome to do the maths and prove me wrong, with all the sarcasm included. I shall not do it, I have more practical things to do. DimiterArticle: 96424
Clark, we have released the source code for the Linux port to Virtex-II Pro to the linuxppc open source repository at http://penguinppc.org . Click on the "Kernel Source" link on the left side to find out what the different ways are to get access to that source code. linuxppc-2.4 is the correct tree. Various distributions have picked up that source code. To get started, though, you will need cross-compiler, kernel, and root filesystem. The MontaVista Preview Kit contains all these things and combined with XAPP765 that should get you started. - Peter Anonymous wrote: > I'm confused. I thought the xilinx linux was open source? Is monte vista the > only place to get the source? > > "Peter Ryser" <peter.ryser@xilinx.com> wrote in message > news:drteng$8a31@cliff.xsj.xilinx.com... > >>Have a look at XAPP765 >>(http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for >>an older EDK version but the principles of operation are still the same. >> >>- Peter >> >> >>Anonymous wrote: >> >>>I have an evm on order, but is there a place I can download the PPC > > linux > >>>for Virtex-4? I want to make sure I can build it okay. >>> >>>Thanks, >>>Clark >>> >>> >> > >
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