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
eliben wrote: > Hello, > > In our application we have to receive and merge several proprietary > serial channels (200 MHz) over fibers, and send all the data over > Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained. > > While generally sending this amount of data is possible over Gbit > Ethernet, doing so in an embedded system isn't easy. That's because we > need to send it by UDP or TCP, for which a TCP/UDP/IP stack is > required (software). > > Since the translation of the proprietary format is certainly done in > an FPGA, I tried to calculate how to implement the whole process in an > FPGA. For example, I can take an Altera Stratix II GX (with a built in > Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on > the Nios II soft-core processor. Unfortunately, as Altera's appnote > 440 shows, the maximal bandwidth attainable this way is only 15-17 > MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet > adapters on PCs show a maximal bandwidth of 80-90 MByte/s. > > However, I wouldn't like to build in a Pentium into the embedded > system. Any suggestions / recommendations on how to solve the > problem ? > Try the Xilinx GSRD appnote. Performance of over 700 Mbps is possible with the embedded PowerPC. /SivaArticle: 123826
In my FPGA design, I need a result of EXP(z: is complex) as a tempary coefficient for other calculations. I've known to deal with the real part and imagin part separately. But I don't know how to deal with the floating point numbers. I only managed to deal with the easy floating point things, e.g. 2**(-A), A is an integer. I don't know how to deal with the tempary coefficient in the floating point type in the FPGA design. Does anyone here has the similar experience to deal with floating point as the tempary coefficient in the FPGA design? Can tell me some tip about this? Thank you.Article: 123827
On Sep 5, 9:19 am, Andy <jonesa...@comcast.net> wrote: > > Are you sure that Jim's assertion method in communicating mutually > > exclusivity to VHDL compiler is good enough without need for 'orif' > > introduction? > > It depends on the definition of "good enough", but there is not a > single situation where an assertion could not reasonably be used, but > where 'orif' could be. Conversely, there are several situations where > 'orif' is not an option, but an assertion would be. > > > > > 1. As I described before, if you use Jim's method and want to get the > > information to compiler, you must insist the 'if...end if' structure > > to get the benefits, otherwise it is useless, meaningless and wasting > > time. > > Not necessarily. There are many mutual exclusivity situations that > might even span different processes. Consider two processes that both > use multipliers. If both processes' uses of their multipliers are > enabled by specific conditions that can be shown to be mutually > exclusive, the synthesis tool has enough information to enable them to > share one multiplier. Of course whether or not current synthesis > tools share resources across processes is beyond the scope of this > argument. > > Another example is two state machines that are never both in a state > that uses a multiplier (or some other expensive, shareable resource). > > Both of these situations are certainly possible with if-then code > structures, but they don't have to be, and can still take advantage of > an assertion to verify and communicate the mutual exclusivity. > > > > > 2. When you use 'if...end if' structure, 'orif' is the best choice, no > > question! You can add the information line by line at any levels as > > you want. > > 'Orif' is only an option if you can code the function in an if-ELSIF > structure, which cannot be done for a parameterized loop of if-then > structures. > > > > > 3. My goal is to make writing VHDL for a hardware engineer as easy as > > writing C for a software engineer using 'if...end if' structure with > > mixing 'elsif' and 'orif'. > > Ouch! Then just use verilog; it is already as "easy to use as C" (and > to get into trouble with). ;^) > > The way I see it is thus: The barrier to new syntactical changes in > VHDL, particularly those that affect the synthesizable subset of VHDL, > should be quite high because of the problems that occur until every > tool in the chain can even read the new syntax. Therefore, syntactical > changes should only be made to allow functionality that cannot be > reasonably supported within the existing syntax. Of course, that > depends on the definition of "reasonably", but I just don't think > 'orif' exceeds the barrier. > > Thanks, > > Andy Hi Andy, "Conversely, there are several situations where 'orif' is not an option, but an assertion would be. " NEVER ! If you have an example to support your opinion, I would recall my propose forever. WengArticle: 123828
Hi Andy, Now it is clear to me, if not to you, What assertion onehot0() can do, orif can do better ! "You can NEVER use a parameterized loop of if-then structures" It is wrong now after our long discussions. Whenever you write a loop and try to transfer mutually exclusive information into it, you must remember that you must clearly write 'if..elsif..." structure, then each elsif is a perfect candatate to be replaced within your loop. REMEMBER: if you want to use assertion onehot0() to transfer mutually exclusive information, all signals in onehot() entries must be used after keywords if and elsif. Other coding short cut would leave the information useless and wastful. WengArticle: 123829
NickNitro wrote: > > If done correctly though wouldn't multiple CPLDs working on different > parts of the algorithm perform better overall than a single FPGA? No, almost certainly not. You can get FPGAs with thousands of times greater resources than a single CPLD. Also, many FPGAs are significantly faster than CPLDs. The CPLD is based on something like 36-input NAND gates, the FPGA is based on 4 x 4 RAMs. In some special cases the propagation time of a signal through a CPLD can be quicker than meandering all the way across an FPGA's interconnect fabric, but good choice of pinout and/or timing constraints can handle that. In most cases, signals get clocked through several stages of FFs, so propagation across long paths is not done, anyway. But, that sort of delay will be dwarfed by the delays associated with getting signals on and off multiple chips, keeping clocks synchronized between multiple CPLDs, etc. I tend to work at the low-performance side of the FPGA spectrum, so I usually don't run into these problems, anyway. But, the level of integration in FPGAs very quickly leaves CPLDs in the "dust", at a level of several thousand equivalent gates. If you can do the job in a SINGLE Xilinx XC9536 or 9572, they can be quite competitive. As soon as you go above the 9572 level, the smallest Spartan chips start becoming VERY attractive, both in cost and performance, and these are just the "entry level" parts in the FPGA spectrum. Look at the cost and capacity of the XC2E50 type Spartan chips from Xilinx. My guess is they can do your entire job on one chip for $12! JonArticle: 123830
On Sep 5, 12:41 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi Andy, > Now it is clear to me, if not to you, > > What assertion onehot0() can do, orif can do better ! > > "You can NEVER use a parameterized loop of if-then structures" > > It is wrong now after our long discussions. > > Whenever you write a loop and try to transfer mutually exclusive > information into it, you must remember that you must clearly write > 'if..elsif..." structure, then each elsif is a perfect candatate to be > replaced within your loop. Weng, Neither of your statements is true. With 'orif' you must have all of your mutually exclusive (orif) conditions in a single if-orif tree. 'orif' statements in different if- orif trees have no context relative to each other, and therefore cannot indicate mutual exclusivity. For example: if a = '1 then z <= x; orif b = '1' then -- a and b are mutex z <= y; end if; if c = '1' then g <= e; orif d = '1' then -- c and d are mutex g <= f; end if; Note that the above does not indicate that a and c are mutex, nor would you want it to, because then how would you code it such that a and c are NOT mutex, but both are executed (so you could not use elsif). For practical reasons, the scope of the mutual exclusivity must be limited to the same if- or elsif- tree. You can only unroll a loop of if-then statements into a single if-orif tree if you know the number of choices when you write it. Otherwise, you must use a loop with an if-then statement, using a parameter to determine the number of loop iterations. The if-then statement in the loop unrolls during synthesis to become separate if-then statements, so even if there was an orif in the loop's if-then statement, it would be meaningless between the separate, unrolled if-then statements. The parameter to control loop iterations may be related to a generic, or to the size of an unconstrained array port, so you could not possibly know it ahead of time and manually transform the loop into an if-orif tree. > REMEMBER: if you want to use assertion onehot0() to transfer mutually > exclusive information, all signals in onehot() entries must be used > after keywords if and elsif. Other coding short cut would leave the > information useless and wastful. An example of using an assertion without an associated if-then statement: Case state_a is ... when multiply_a => x <= y * z; ... end case. ... case state_b is ... when multiply_b => a <= b * c; ... end case; ... assert zero_one_hot((state_a=multiply_a, state_b=multiply_b)); The assertion could tell the synthesis tool that only one physical multiplier is needed. AndyArticle: 123831
> "Conversely, there are several situations where
> 'orif' is not an option, but an assertion would be. "
>
> NEVER !
>
> If you have an example to support your opinion, I would recall my
> propose forever.
Weng,
If you can re-write the following with an if-orif tree to indicate
that every element in enable is mutually exclusive, then you win!
BTW, the range of enable is unknown, but somewhere within the range of
integer'low to integer'high, if that helps.
type data_t is array (enable'range) of std_logic_vector(output'range);
signal data: data_t; -- could be a port instead...
...
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable);
Andy
Article: 123832On Wed, 05 Sep 2007 18:10:59 -0400, PeteS <axkz70@dsl.pipex.com> wrote: >John Larkin wrote: >> On Sun, 2 Sep 2007 13:15:25 +0100, "Symon" <symon_brewer@hotmail.com> >> wrote: >> >>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>> news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com... >>>>> Hi Jon, >>>>> Yes. But with a caveat. When your signals switch reference layers, make >>>>> sure >>>>> there is a path for the reference current. >>>>> >>>>> E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal >>>>> goes >>>> >from layer 1 to 6 through a via, you should have a bypass cap bewteen >>>>> power >>>>> and ground near this via. >>>> >>>> That's not necessary. There's already so much plane-plane capacitance >>>> that the planes are already equipotential as far as the tiny charge >>>> injected by the signal trace can affect them. >>>> >>>> Really, on a board with, say, 3000 vias, are you going to put a bypass >>>> via near every signal via? I've heard of people asking for two! >>>> >>>> John >>>> >>> Hi John, >>> I wish that was always the case! There are problems relying solely on the >>> interplane capacitance. There will be an impedance discontinuity at the via >>> no matter what, but using solely the interplane capacitance increases this >>> discontinuity. Clearly the inductance of the signal in this case is higher. >>> Also, if a bus does the transistion, all the even mode effects add up. >>> Finally, the high Q of the planes means you are vulnerable to plane >>> resonances. >>> >>> http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf >> >> Wow, that's about as incoherent as papers get! >> >> >>> http://www.hottconsultants.com/techtips/pcb-stack-up-6.html >> >> >> Incredible, dangerous nonsense. Absolutely moronic. Quote: >> >> "Referencing the Top and Bottom of the Same Plane. Whenever a signal >> switches layers and references first the top and then the bottom of >> the same plane we must still ask the question, how does the return >> current get from the top to the bottom of the plane. Do to the "skin >> effect" the current cannot flow through the plane, it can only flow on >> the surface of the plane. >> >> This is some sort of joke, right? > >I would call it glossing over certain issues. The current can obviously >pass through the plane copper [because skin effect doesn't cause >infinite impedance obviously], but it won't necessarily be a >particularly low impedance path (depends on copper weight and signal >speed, obviously) although it will be a short path ;) What's the dielectric constant of copper? JohnArticle: 123833
"PeteS" <axkz70@dsl.pipex.com> wrote in message news:A8ydnR7HRp-gfkPbRVnyvgA@pipex.net... > John Larkin wrote: <snip> >> >> Incredible, dangerous nonsense. Absolutely moronic. Quote: >> >> "Referencing the Top and Bottom of the Same Plane. Whenever a signal >> switches layers and references first the top and then the bottom of >> the same plane we must still ask the question, how does the return >> current get from the top to the bottom of the plane. Do to the "skin >> effect" the current cannot flow through the plane, it can only flow on >> the surface of the plane. >> >> This is some sort of joke, right? > > I would call it glossing over certain issues. The current can obviously > pass through the plane copper [because skin effect doesn't cause infinite > impedance obviously], but it won't necessarily be a particularly low > impedance path (depends on copper weight and signal speed, obviously) > although it will be a short path ;) > > For decently high speed signals (~ 50 psec rise/fall times) this issue > _can_ hit the signal budget if there are enough excursions of the return > path through the plane - not by much, but 'not much' is always dependent > on the design. If you only have 1dB of budget (as exists in some standards > I know), then this _can_ be an issue. > > In 95% (or more) of cases, it's lost in the noise. <snip> I smiled at the joke the first time around and am surprised that the reality didn't hit during the time it took to assemble the response. "Whenever a signal switches layers and references first the top and then the bottom of the same plane we must still ask the question, how does the return current get from the top to the bottom of the plane." No we mustn't. How the hell does the signal switch sides? A via! A hole between the top and bottom layers of the plane that has a skin effect associated with its edge. The ground plane skin-effect current limited to the top several microns of the top signal's reference and the bottom several microns of the bottom signal's reference switches sides around the skin of the via edge. There is no mystery and no pondering unless the signal changes sides of the reference plane without using a hole in the plane. Wouldn't that be a feat? - John_HArticle: 123834
James Harris wrote: (snip) > Simplistically, I'm thinking that each compute element (effectively > each part of the ALU) would raise or lower an output-ready indicator > just after its output lines had stabilised. When the next component > has read the output of that compute element it would strobe an > acknowledge line. The compute element would then reset its output- > ready line and be free to take on another piece of work. I guess this > is simple handshaking. This sounds like what is called "self timed logic", a form of asynchronous logic. > I've tried a search for clockless CPU which is a good summary of what > I have in mind. Some posts said others had thought of it but it would > be almost impossible to test but I cannot see why. I tried a search > for hazard spikes and got your post, above! The biggest problem is that all the design tools are for synchronous logic designs. Even more, for FPGAs you have all those FF's that you can't use. I believe the KA-10, one of the PDP-10 family of processors that DEC used to make, was built with self timed logic. -- glenArticle: 123835
>Consider a sphere with no other metal objects around it. >Add some charge and compute the change in voltage. >Divide, and that is the capacitance. It is a little harder >to calculate for other shapes, but it is still there. If there is nothing else nearby, where are you putting the other probe on your voltmeter? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123836
eliben wrote: (snip) > While generally sending this amount of data is possible over Gbit > Ethernet, doing so in an embedded system isn't easy. That's because we > need to send it by UDP or TCP, for which a TCP/UDP/IP stack is > required (software). TCP is somewhat complicated, but UDP is pretty simple. You might want external software to handle ARP and routing tables (if needed), but it should not be too hard to create and send a UDP packet in an FPGA. You don't say anything about receiving. Among the complications of IP are reassembling fragmented packets. You should be able to avoid that (if you control both ends, and the path in between). -- glenArticle: 123837
The typical source of the error is leaving the clock unconnected on the bus (opb, lmb, or plb) which is then forward propagated to all periphals on the bus. if this is the problem, then read no further. However, your situation may not be typical. First, you'll need to discover your source of the error in the trimming section of the MAP report. This is the .MRP file. To get a verbose description of the trimming report. You'll need to run xflow/projnav without the .BMM file. Without the BMM file in the flow, map/par will run to completion without the "all memory mapped blockram" error. Open the MRP and follow the trimming report. Good luck. young wrote: > Hi all, > > I met a wired BlockRam connection error when I tried to build a > mutilple processors system using EDK. Hope anyone can give me some > hint. > > Here is the background. With the EDK, we can create a single > processor (MicroBlaze or PowerPC) at ease. Based on > the single Processor sytem, I added those IPs, including the > processor (MB or PPC), the bus , BRAM memory, memory > controller and some pherpherals. I connected them in the same way the > single processor system do, which needs some modification in the mhs > file. > There is no connections between two processor system. In the Build > process, the project passed the syntheis and failed in the map. The > message is this: > --------------------------------------------------------------------------------------------------------------------------------- > > #----------------------------------------------# > # Starting program map > # map -o system_map.ncd -pr b system.ngd system.pcf > #----------------------------------------------# > Release 9.1.02i - Map J.33 > Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved. > Using target part "2vp30ff896-7". > Mapping design into LUTs...Mapping design into LUTs... > ERROR:MapLib:482 - Blockram ramb16_s9_s9_0 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_1 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_2 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_3 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_4 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_5 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_6 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > ERROR:MapLib:482 - Blockram ramb16_s9_s9_7 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > Error found in mapping process, exiting... > Errors found during the mapping phase. Please see map report file for > more > details. Output files will not be written. > --------------------------------------------------------------------------------------------------------------------------------- > > If anyone share the same error, I would appreciate your comment. > > Regards, > > Young >Article: 123838
ZHI wrote: > In my FPGA design, I need a result of EXP(z: is complex) as a tempary > coefficient for other calculations. I've known to deal with the real > part and imagin part separately. exp(x+iy)=exp(x)exp(iy) > But I don't know how to deal with the floating point numbers. Floating point in an FPGA is somewhat hard, but not impossible. You might be able to use fixed point but non-integer arithmetic. Otherwise, in an FPGA floating point multiply is easier than floating point addition. > I only managed to deal with the easy floating > point things, e.g. 2**(-A), A is an integer. I don't know how to deal > with the tempary coefficient in the floating point type in the FPGA > design. Does anyone here has the similar experience to deal with > floating point as the tempary coefficient in the FPGA design? Can tell > me some tip about this? Thank you. I would need to know a lot more about what you are trying to do to say more. Otherwise, my favorite architecture for such systems is a systolic array processor. -- glenArticle: 123839
John Larkin wrote: > On Sun, 2 Sep 2007 13:15:25 +0100, "Symon" <symon_brewer@hotmail.com> > wrote: > >> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >> news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com... >>>> Hi Jon, >>>> Yes. But with a caveat. When your signals switch reference layers, make >>>> sure >>>> there is a path for the reference current. >>>> >>>> E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal >>>> goes >>> >from layer 1 to 6 through a via, you should have a bypass cap bewteen >>>> power >>>> and ground near this via. >>> >>> That's not necessary. There's already so much plane-plane capacitance >>> that the planes are already equipotential as far as the tiny charge >>> injected by the signal trace can affect them. >>> >>> Really, on a board with, say, 3000 vias, are you going to put a bypass >>> via near every signal via? I've heard of people asking for two! >>> >>> John >>> >> Hi John, >> I wish that was always the case! There are problems relying solely on the >> interplane capacitance. There will be an impedance discontinuity at the via >> no matter what, but using solely the interplane capacitance increases this >> discontinuity. Clearly the inductance of the signal in this case is higher. >> Also, if a bus does the transistion, all the even mode effects add up. >> Finally, the high Q of the planes means you are vulnerable to plane >> resonances. >> >> http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf > > Wow, that's about as incoherent as papers get! > > >> http://www.hottconsultants.com/techtips/pcb-stack-up-6.html > > > Incredible, dangerous nonsense. Absolutely moronic. Quote: > > "Referencing the Top and Bottom of the Same Plane. Whenever a signal > switches layers and references first the top and then the bottom of > the same plane we must still ask the question, how does the return > current get from the top to the bottom of the plane. Do to the "skin > effect" the current cannot flow through the plane, it can only flow on > the surface of the plane. > > This is some sort of joke, right? I would call it glossing over certain issues. The current can obviously pass through the plane copper [because skin effect doesn't cause infinite impedance obviously], but it won't necessarily be a particularly low impedance path (depends on copper weight and signal speed, obviously) although it will be a short path ;) For decently high speed signals (~ 50 psec rise/fall times) this issue _can_ hit the signal budget if there are enough excursions of the return path through the plane - not by much, but 'not much' is always dependent on the design. If you only have 1dB of budget (as exists in some standards I know), then this _can_ be an issue. In 95% (or more) of cases, it's lost in the noise. > > > > http://dspace.kaist.ac.kr/bitstream/10203/664/1/effectof.pdf > > > That last one is academic and inconclusive, and the board he uses is > not at all realistic. > > Except in extreme situations, it's safe to assume that parallel planes > in a multilayer pcb, bypassed with scattered caps, is an equipotential > structure. It's that simple. > > > John > > I agree, especially with the 'in extreme situations'. My view is it's dependent on the specific board. There's a reason we stitch planes along the side of a track (a subject in it's own right) in certain circumstances; the reason being to make sure the planes *really* *are* equipotential (or damn close to it). Cheers PeteSArticle: 123840
John Larkin wrote: (snip) > If you design an SMA connector into a multilayer pcb, which I > occasionally do for amusement, you can TDR the planes. A typical plane > will look like a perfect cap to 15 GHz, my limit of measurement. As > you solder in bypass caps, the effective C goes up, irrespective of > where you add the caps. That's true enough to make my stuff work: How about an SMA connector in the center of two parallel plane circles. If you know the dielectric constant you should be able to find the velocity, and then the resonant frequency. Other than two (or one) nice circle, it might not be a high-Q resonator. At (2/3)c, 5cm diameter circles should have a resonance around 9GHz. -- glenArticle: 123841
vasile wrote: (snip) > If you're routing a long 3Gbps differential signal, then definitely > you must have ground vias near every signal pair vias. Bypassing with > a capacitor near an inductive vias has no effect. But using at least > one ZBC plane in the stack it helps. If it is a differential signal, then you should not need to worry about ground bypassing. There should be no net ground current, that is the whole point of differential signaling. -- glenArticle: 123842
On Wed, 05 Sep 2007 14:34:39 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >John Larkin wrote: >(snip) > >> If you design an SMA connector into a multilayer pcb, which I >> occasionally do for amusement, you can TDR the planes. A typical plane >> will look like a perfect cap to 15 GHz, my limit of measurement. As >> you solder in bypass caps, the effective C goes up, irrespective of >> where you add the caps. That's true enough to make my stuff work: > >How about an SMA connector in the center of two parallel plane >circles. If you know the dielectric constant you should be able >to find the velocity, and then the resonant frequency. Other than >two (or one) nice circle, it might not be a high-Q resonator. >At (2/3)c, 5cm diameter circles should have a resonance around 9GHz. > >-- glen I've put SMAs mostly on the power:ground planes, or smaller pours against ground, on VME boards, which are 6U Eurocards. I haven't observed anything on TDR that would correspond to an edge reflection, which would correspond to a plane resonance in the frequency domain. A 5 cm diameter circle might resonate. I suppose the question is what would be the Q. Given a plane separation of, say, 6 mils, the effective impedance of the cavity might be so low that the resonance is swamped by FR4 dielectric and copper skin losses. Multilayer inner-layer copper is usually etched (black oxide process) to improve adhesion and prevent delamination. That greatly increases skin losses at these sorts of frequencies, which is maybe why I'm not seeing plane resonances. Peel up some copper from a multilayer board: it's repulsive. We did just get a spiffy 3 GHz spectrum analyzer with tracking generator, so I'll have to do a board with several SMA taps on a plane, and see what transmission behavior between connectors is like. Has anybody seen, as opposed to simulated, plane resonances in a power:ground structure like this? JohnArticle: 123843
On Wed, 05 Sep 2007 14:46:32 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >vasile wrote: > >(I wrote) >>> Note that a plane >>>still has capacitance even without another nearby plane. > >> ??? The physics laws are different in your area ? > >I presume that is the one you are writing about. > >Consider a sphere with no other metal objects around it. >Add some charge and compute the change in voltage. >Divide, and that is the capacitance. It is a little harder >to calculate for other shapes, but it is still there. > 1 cm radius is 1 pF! JohnArticle: 123844
vasile wrote: (I wrote) >> Note that a plane >>still has capacitance even without another nearby plane. > ??? The physics laws are different in your area ? I presume that is the one you are writing about. Consider a sphere with no other metal objects around it. Add some charge and compute the change in voltage. Divide, and that is the capacitance. It is a little harder to calculate for other shapes, but it is still there. You can also do it by calculating the capacitance between two concentric spheres, in the limit as the outer one goes to infinity. Note that the parallel plate capacitor formula is only valid when the spacing is small compared to the size of the plates. -- glenArticle: 123845
Symon wrote: (snip) > As I'm sure you already know, this is because usually edge coupled signal > pairs on a PCB are not 'proper' differential pairs the way (say) twisted > pairs in CAT-5 are. The coupling between each distinct trace and the ground > plane is much greater than the coupling between the pair of traces > themselves. It should not matter how much coupling is between the pair, and from the pair to ground, as long as the coupling between each wire and ground is equal. Though just as important is to have a balanced source. -- glenArticle: 123846
On Sep 5, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
> > "Conversely, there are several situations where
> > 'orif' is not an option, but an assertion would be. "
>
> > NEVER !
>
> > If you have an example to support your opinion, I would recall my
> > propose forever.
>
> Weng,
>
> If you can re-write the following with an if-orif tree to indicate
> that every element in enable is mutually exclusive, then you win!
>
> BTW, the range of enable is unknown, but somewhere within the range of
> integer'low to integer'high, if that helps.
>
> type data_t is array (enable'range) of std_logic_vector(output'range);
> signal data: data_t; -- could be a port instead...
> ...
> for i in enable(i) loop
> if enable(i) = '1' then
> output <= data(i);
> exit;
> end if;
> end loop;
> assert zero_one_hot(enable);
>
> Andy
Hi Andy,
Your code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable); <-- useless and wasting time in its
purpose
My code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
Why do you need to tell VHDL compiler that every element in enable is
mutually exclusive?
My coding has already told VHDL compiler that
1. all enable(i) are mutually exclusive;
2. You don't have to do anything, I have done it for you and please
take the rest.
If you really want to tell SIMULATOR the information, it has nothing
to do with orif. You may write any function following assertion
statement without any problem.
Target to transfer mutually exclusive information to VHDL compiler is
the pivotal point. VHDL compiler fails to do a better job because VHDL
language lacks elements concisely, relaibly, easily and safely to
transfer the mutually exclusive information to VHDL compiler, not to
SIMULATOR.
VHDL doesn't lack tools to transfer any information to SIMULATORS.
Assertion have already been there for the purpose since its birth.
Jim just unexpertly devised a mechanism that is almost useless in its
purpose.
I would like to thank for your discussion on this topics, because
through our discussions I realized that if one wants to transfer
mutually exclusive information to VHDL compiler, he must stick with
the 'if...end if' statement strucure. Before it, I failed to recognize
it. This is what I said you had given me as a gift.
Please declare who is the
wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.
Weng
Article: 123847We've are using the MPC8349E at 400Mhz core and got only 480mbit/s sustained UDP data rate. These processors are marketed as communications processors but only have low level HW support (on Ethernet layer). All the upper level IP and UDP protocols are handled in software (when running linux). So it takes up CPU time. Same setup on two desktop PCs running linux yeilds 840mbit/s sustained UDP rate.Article: 123848
I'm a beginner in the Nios II System. When I learn the examples provided by Nios II IDE, I always see this type's function : IOWR_ALTERA_AVALON_PIO_DATA(LED_PIO_BASE, count); The function appears in the example "count_binary". But I can't find out the detailed information about this type function , only find these three messages: #define IOWR_ALTERA_AVALON_PIO_DATA(base, data) IOWR(base, 0, data) #define IOWR(BASE, REGNUM, DATA) \ __builtin_stwio (__IO_CALC_ADDRESS_NATIVE ((BASE), (REGNUM)), (DATA)) #define __IO_CALC_ADDRESS_NATIVE(BASE, REGNUM) \ ((void *)(((alt_u8*)BASE) + ((REGNUM) * (SYSTEM_BUS_WIDTH/8)))) But I still don't understand the meanning of this function. Please tell me how can I find out the detailed information about these types' function?Article: 123849
hezhikuan2007@gmail.com wrote: > I'm a beginner in the Nios II System. When I learn the examples > provided by Nios II IDE, I always see this type's function : > IOWR_ALTERA_AVALON_PIO_DATA(LED_PIO_BASE, count); In chapter 13 of the Quartus II Handbook V5: Embedded Peripherals, there is a brief note on page 6 under "Software Programming Model" that mentions the header file and the fact that there's no HAL API for the PIO core. And that's about the extent of the documentation IIRC. I've had similar frustrations with several aspects of the NIOS API - and on more than one occasion have had to search header files and 'reverse engineer' the interface to work out how to use the component. > #define IOWR_ALTERA_AVALON_PIO_DATA(base, data) IOWR(base, 0, > data) > #define IOWR(BASE, REGNUM, DATA) \ > __builtin_stwio (__IO_CALC_ADDRESS_NATIVE ((BASE), (REGNUM)), > (DATA)) > #define __IO_CALC_ADDRESS_NATIVE(BASE, REGNUM) \ > ((void *)(((alt_u8*)BASE) + ((REGNUM) * (SYSTEM_BUS_WIDTH/8)))) > But I still don't understand the meanning of this function. > Please tell me how can I find out the detailed information about these > types' function? These aren't "functions" as such but are macros which ultimately result in what appears to be a simple direct memory-pointer access provided by __builtin_stwio. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
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