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
On 2007-09-06, eliben <eliben@gmail.com> wrote:
> 2) If the client is a PC of some sort, working on the MAC packet level
> isn't too simple,
It's easy:
$ man packet
> as the networking APIs don't provide that level.
Sure they do. See above.
Of course it sucks trying to do it under Windows, but it sucks
trying to do _anything_ under Windows. ;)
> A separate driver to the NIC should be used, or whatever.
>
> 3) If I want to advance to a more complicated network, such as one
> with a few clients, working on the IP level is much more convenient as
> I can set up a router with all the niceties it brings - multicasts,
> groups, etc.
Yup. One of the products I work on started out with MAC level
networking. It's fast and has very low overhead, but there are
always going to be customers who want IP networking. So now
the product will do either MAC networking or TCP networking (or
both, actually).
Beware of relying on the Ethernet CRC. I've run across two
different uController/MAC combinations where it wasn't
reliable.
--
Grant Edwards grante Yow! Wait ... is this a FUN
at THING or the END of LIFE in
visi.com Petticoat Junction??
Article: 123876
On 2007-09-06, Paul Keinanen <keinanen@sci.fi> wrote:
>>2) If the client is a PC of some sort, working on the MAC packet level
>>isn't too simple, as the networking APIs don't provide that level. A
>>separate driver to the NIC should be used, or whatever.
>
> I haven't written any raw Ethernet protocols in two decades, but in
> those days setting the receiver into Promiscuous mode was all that was
> needed.
There's no need for promiscuous mode. None of the MAC packet
level products I've worked on used promiscuous mode at all.
> With the cost of the system that the OP asked, there would not be a
> cost issue of installing an extra network cards on the receiving PC.
> Thus, one NIC could handle the fast traffic in Promiscuous mode, while
> the other NIC(s) could handle ordinary network traffic.
I don't see what promiscuous mode has to do with it. The MAC
level protocols I worked with were all still unicast.
--
Grant Edwards grante Yow! FOOLED you! Absorb
at EGO SHATTERING impulse
visi.com rays, polyester poltroon!!
Article: 123877"John_H" <newsgroup@johnhandwork.com> wrote in message news:j0TDi.4846$J96.4401@trnddc02... > Symon wrote: >> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >> news:lZqdnS0_y5YKvULbnZ2dnUVZ_s7inZ2d@comcast.com... >>> 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. >>> >>> -- glen >>> >> Hi Glen, >> I think it does matter in this case. I think we're agreed that the two >> signals that make up the pair are mainly coupled to the plane, not to >> each other. This means that current is flowing in the ground. As you say >> in another reply in this thread to me, that doesn't matter, UNTIL the >> signals come to a discontinuity in the 'signal to ground' coupling. Such >> a situation arises at the transition between layers, which is why the use >> of adjacent ground vias can mitigate the situation. >> HTH, Symon. > > But Symon... > > The signal is differential so when the return currents hit the wall, they > cancel each other out at that border. There's no reflection because the > common mode voltage isn't changing. If the differential signal wasn't > routed differentially, then the reference currents would disperse when > they hit the discontinuity and then eventually find each other or other > ways to balance the current. Even though a large portion of the reference > current is in the plane, the discontinuity results in almost no distance > to travel for the differential reference currents to find peace. > > - John_H Hi John, A good point, I agree, that's true. As you say, there will be a discontinuity nevertheless, as the currents need to cancel out across the plane, but I would think this is a small effect. Furthermore, in that case, I think it means it is important to match the lengths of the traces from each termination to the vias as well as the total length of the individual traces. In the case where the extra ground vias are in place, that isn't so important. Of course, the differential signal continues on its merry way through the vias. Without the ground vias, the transmission line impedance will have a significant discontinuity. Anyway, thanks for pointing that out! Cheers, Syms.Article: 123878
Weng, To elaborate on what Jim and Brian have stated, In the loop, in order for enable(n) to be considered, enable(n-1) must have been false. This evaluation of enable(n-1) requires additional gates UNLESS there is something else that tells the compiler (synthesis or simulation) that the enable bits are mutually exclusive, and therefore that if enable(n) is set, by definition enable(n-1) is not set. It is interesting to note that the presence of the exit statement has no effect on the synthesized gates IF enable is mutually exclusive. However in the absence of both the exit statement and mutual exclusivity, the last executed assignment to output wins, so enable(n) is only used if enable(n+1) is not set, thus also requiring additional gates. Both of these explanations assume an index ordering of "to", not "downto"; however, the behavior is similar (and the effect on hardware the same) with "downto". So, in fact your code DOES NOT demonstrate, nor optimize for, the mutual exclusivity of the bits in enable. Contrary to your erroneous statement, your code merely demonstrates your lack of understanding of the significance of order of execution among sequential statements, a fundamental concept in simulation and logic synthesis. Jim's (and others') implementation using OR works well for data types that support the OR operator: booleans, bits and vectors, but neither integers, enumerated types nor other aggregate types, without a conversion to/from an ORable data type, can use this method. In addition, without the assertion, the (erroneous) lack of mutual exclusivity upon which the solution depends would likely go unnoticed in simulation. And while the ability of the simulator to use the assertion has existed since the beginning, the ability of synthesis tools to use the assertion (not to verify it, but to optimize circuitry because of it) does not, to this day, exist. Oh, and by the way, I AM THE WINNER! ;^) AndyArticle: 123879
On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote: > > If you have the choice between UDP and TCP, UDP is much simpler and > > fits an FPGA well. The big issue in choosing between the two is if you > > require the guaranteed delivery of TCP, or can tollerate the potential > > packet loss of UDP. > > > As an example, we make a card that acquires real time data in a custom > > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a > > protocol offload engine that uses the Xilinx PicoBlaze soft processor > > to deal with the protocol stack. The PicoBlaze is an 8-bit soft > > processor. It looks at each incomming packet and reads the header to > > see if it is one of the real time streams we are trying to offload. > > If it is, it sends the header to one circular buffer in memory and the > > data to another circular buffer. If it is not, it sends it to a > > kernel buffer and we let the Linux network stack deal with it. > > > With this setup, we can consume data at over 90 MB/sec per Gigabit > > Ethernet port. The data part of the packet is 1024 bytes, and each > > GigE port has its own PicoBlaze dedicated to it. > > So where is the actual UDP communication implemented ? In Linux ? What > processor is it running on ? Is it an external CPU or the built-in PPC > of Virtex 4 ? > > We are using one of the embedded PowerPCs to run Linux, and one PicoBlaze soft processor per EMAC in the design. As each packet exits the EMAC, its header is examined by software that is running on the PicoBlaze. The PicoBlaze is running a very simple stack written in assembly language. As it looks at each layer of the header, it makes a decision to do one of several things. At the Ethernet level, it is deciding if it should just throw the packet away, or pass it on to the next layer. At the IP and UDP layers, it is deciding if the packet belongs to the protocol that we are offloading, and is a stream that we have requested. If the packet does belong to the protocol that we are offloading, the PicoBlaze sets up a PLB DMA engine to send it down one data path. If the packet does not belong to the protocol we are offloading, then the PicoBlaze sends it down another data path and it is given to the Linux kernel to deal with. So for the protocol that we are offloading, the entire Ethernet, IP, UDP, and custom protocol stack are implemented in PicoBlaze assembly code. For everything else, the stack is in Linux. Since the data we are offloading is multicast data, this lets us have the PicoBlaze deal with the simple but high speed UDP packets, and the PowerPC running Linux deal with the IGMP messaging required to join, leave and maintain membership in a multicast group. The PicoBlaze is just running a single threaded loop of code that polls for input or output data, and then deals with it. Its program is loaded from the PowerPC taking advantage of the fact that the BRAM holding its program is dual ported. The PowerPC also tells the PicoBlaze what streams of data it is supposed to be acquiring, and what buffers in DDR2 memory to write the data to. The PicoBlaze will generate an interrupt once it has written a certain number of packets to the buffer, so the PowerPC just sees big chunks of data showing up in the buffers and does not have to deal with each packet. The PowerPC only needs to spend 1 or 2 percent of its compute to deal with acquiring each stream of data. > > > I did notice that you want to send GigE instead of receive it like we > > are doing, but this method should work for sending a custom protocol > > wrapped in UDP with some minor changes. > > > How is the GigE that you are sending the data over connected? Is it > > point to point, a dedicated network, or something else? > > We can assume for the sake of discussion that it is point to point, > since the network is small and we're likely to use a fast switch to > ensure exclusive links between systems. > > Eli With this setup, you should be able to have an error rate that is incredibly low. As long as the possibility of a lost packet is not catastrophic, UDP would be a very good match. The protocol we offload has sequence numbers in it, so we know if we have lost a packet. The data is being used for realtime signal processing, so losing a packet just looks like a burst of noise. Regards, John McCaskill www.fastertechnology.comArticle: 123880
Hi Brian, 1. Please write target answer's name, otherwise I may miss your comments. 2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did you see any burning? 3. The following claim is irrelative to Andy's requirement: "Andy's code caught the problem before synthesis, so he fixed it. Because his synthesis tool (the 2008 version) understood the assertion" Andy wants me to use orif to transfer mutually exclusive information to within loop, in this respect, no orif is needed and things are done perfectly, because mutually exclusive Information has been clearly transfered to within the loop by coding style. I think it is the best explanation to your question: Nothing is better than extra. Whatever assertion onehot0() can do in terms of mutually exclusive information tranfer mechanism, orif can do better, faster, safer and more reliable ! The above sentence is too long to remember, the following sentence was used and everyone involved knows its full meaning: What assertion onehot0() can do, orif can do better. I have to emphasize that onehot0() function is useful in general, but useless in terms of its introduction purpose. WengArticle: 123881
Hi,
If an Altera design does not have a reset, then what
happens to the registers during gate level simulation? I assume that
the Q outputs are initilaised to 0, but what happens with the D
inputs, I guess they would be assigned U at time 0 , so when the
registers clock changes the U will appear on Q, which would then
propagate throught the fpga? How are designs tested without resets?
Thanks Andy
Article: 123882If all Q outputs are 0, then the whole design is defined, and each D input is what the combinatorial logic determines it to be.. Where do you see the problem? Peter Alfke On Sep 6, 7:55 am, aclegg1...@googlemail.com wrote: > Hi, > > If an Altera design does not have a reset, then what > happens to the registers during gate level simulation? I assume that > the Q outputs are initilaised to 0, but what happens with the D > inputs, I guess they would be assigned U at time 0 , so when the > registers clock changes the U will appear on Q, which would then > propagate throught the fpga? How are designs tested without resets? > > Thanks AndyArticle: 123883
On Thu, 6 Sep 2007 10:14:40 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:7gdtd3lnoebp1hualfofq6444ukph0jrt5@4ax.com... >> >> >> The GSSG structure makes sense in both those papers, not because it >> provides a "return current path" (which the papers, thankfully, don't >> say) but because it keeps the impedances of the traces constant as >> they burrow through the epoxy-glass, by providing uniform grounded >> capacitive loading. There is a difference. >> >Hi John, >So, if there's no return current, no current flows in the via right? **So >you could disconnect one end of the via and it would not affect the >operation of the curcuit? A transmission line is equivalent to a string of series Ls and shunt Cs. The Cs all end at "ground" for a single line, and there are additional Cs between lines for diff pairs. Of course all the Cs must be charged as a wavefront moves along the line. If that's what you want to call "return current" then do so. I call it the charging current of the capacitive component of the transmission line. The words aren't important. What's in question is whether a signal can dump its current into, say, a ground plane, hit a via, and then dump its charging current blips onto the other side of that plane, or into a sandwiched power plane, without bad things happening. My position is that planes, in real life, so close to equipotential, so firmly glued together by plane-plane capacitance and (at low frequencies) by bypass caps, that they all look like ground to the transmission line, so all the articles and "consultants" claims about managing "return current" are mostly a waste of words. > >It's important to realise that transmission lines are not just defined by >capacitance. The structures have inductance also. Gosh. > It is an excess of this >inductance that will slow down your signal. It is this inductance that is >adjusted by the cunning placement of vias. The GSSG ground vias do indeed moderate the inductance and capacitance of the signals as they scoot through the vias. Simulate and optimize for that. But they don't really serve to connect the planes so that the "return current" can find its way home. > >It is true that this sort of stuff only really matters at high speeds. >However, modern FPGAs have sub ns rise time outputs whether you need that >speed or not. This is why readers of this group should be interested. No argument there. Some of the OnSemi ecl chips, and a couple of Analog Devices comparators, are also running around 35 ps edge rates, where things atart to get interesting. > >HTH, Syms. > >** My thanks to a friend for pointing this out to me! > >p.s. Here's a nice article about plane inductance. >http://www.ansoft.com/news/articles/02.02_PCDmag.pdf > His decoupling cap calculation in page 2, where he comes up with 20 uF, is typical of plugging numbers mindlessly into equations just because the dimensions seem to fit. The rest is similarly silly. JohnArticle: 123884
Andy, Your following claim is false: "...enable(n-1) must have been false.." Only enable() is a static, a foolish case, the above situation would happen and your assertion part plays a role for a VHDL compiler. The static values may be all 0. So that no code would be generated for the code segment. Are you serious enough to design a mechanims to deal with the stupid case only? It has nothing to do with mutually exclusive information. Nothing is better than extra gabage. WengArticle: 123885
<aclegg1986@googlemail.com> wrote in message news:1189090543.879764.76630@r29g2000hsg.googlegroups.com... > Hi, > > If an Altera design does not have a reset, then what > happens to the registers during gate level simulation? I assume that > the Q outputs are initilaised to 0, but what happens with the D > inputs, I guess they would be assigned U at time 0 , so when the > registers clock changes the U will appear on Q, which would then > propagate throught the fpga? How are designs tested without resets? > > > Thanks Andy Only if the clock was scheduled before any of the other logic at time zero would the assumption of undefined Ds with defined Qs be a problem. The issue with most simulation is the assumption of undefined Qs independent of the fact that FPGAs configure to a very well defined state. Depending on the manufacturer, device, or even development software revision, the assumption that all Qs start off 0 may or may not be valid. Some FPGAs have global resets available that mimic the power-on reset, at least for registers. Memory elements might not be affected by the GSR. It's because of the simulation/synthesis mismatch that I've very dutifully added those pitifully unnecessary async resets throughout my recent designs except for the logic that I *know* will perform better (where performance is needed) without the constraints of an async reset. I don't have enough recent experience with Altera devices to tell you what *will* take care of your simulation initialization problems. Until I get my synthesizer to properly deal with initial states in my source code, I'll keep adding the insanely unneeded async resets. - John_HArticle: 123886
Jim, Sorry for any usage of inappropriate words. WengArticle: 123887
On Sep 6, 8:30 am, xenix <last...@gmail.com> wrote: > Hello all, > > I am trying to load a 32bit data (word) from the PortB of a BRAM to a > GPR (general purpose register) of the PowerPC. > > Address Map for Processor ppc405_0 > (0b0000010000-0b0000010011) ppc405_0 > (0b0000100000-0b0000100011) ppc405_0 > (0xa0008000-0xa000ffff) docm_cntlr docm > (0xffff8000-0xffffffff) iocm_cntlr iocm > > i am using the LWZ command like LWZ r1, r1 (0xa0008001) but is not > working. which is the right syntax for the specific adresses? > > regards How is it not working? Not compiling, or not getting the data you expect? What are you compiling with, and do you have the MMU of the PowerPC turned on? Regards, John McCaskill www.fastertechnology.comArticle: 123888
<rponsard@gmail.com> wrote in message news:1188988082.702740.278390@o80g2000hse.googlegroups.com... > > is there any reason for edk 9.1 registration failure with linux (I use > the same id that successfully register edk on the same dual boot vista/ > ubuntu laptop ?) I had a similar problem with my Kubuntu installation. I installed the original EDK9.1 OK, but when I tried to add SP2 it would refuse to take my ID no matter what I did... In the end I resolved the issue by running the Webupdate from inside of the EDK... /MikhailArticle: 123889
Dear All, I found this online and found it useful. Maybe you will too. http://incompetech.com/graphpaper/ Cheers, Syms.Article: 123890
On Thu, 06 Sep 2007 13:11:43 GMT, John_H <newsgroup@johnhandwork.com> wrote: >Symon wrote: >> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >> news:lZqdnS0_y5YKvULbnZ2dnUVZ_s7inZ2d@comcast.com... >>> 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. >>> >>> -- glen >>> >> Hi Glen, >> I think it does matter in this case. I think we're agreed that the two >> signals that make up the pair are mainly coupled to the plane, not to each >> other. This means that current is flowing in the ground. As you say in >> another reply in this thread to me, that doesn't matter, UNTIL the signals >> come to a discontinuity in the 'signal to ground' coupling. Such a situation >> arises at the transition between layers, which is why the use of adjacent >> ground vias can mitigate the situation. >> HTH, Symon. > >But Symon... > >The signal is differential so when the return currents hit the wall, >they cancel each other out at that border. There's no reflection >because the common mode voltage isn't changing. If the differential >signal wasn't routed differentially, then the reference currents would >disperse when they hit the discontinuity and then eventually find each >other or other ways to balance the current. Even though a large portion >of the reference current is in the plane, the discontinuity results in >almost no distance to travel for the differential reference currents to >find peace. > >- John_H If a diff signal hits a region where the impedance changes, there will be a partial differential reflection, kicked back to the driver. Unless the driver is a matched impedance, which it generally ain't, the reflection will bounce off the driver and get tangled with the data stream, introducing jitter and closing up the data eye. The differential impedance is determined by both signal-ground capacitance and signal-signal capacitance (which gets double credit). For a very fast edge, a diff signal that changes layers on vias can encounter a different impedance region and do some bouncing. The fast parts of the signal will tend to bounce back, and the slow parts will tend to pass forward, not good. The via structure can certainly be optimized for signal integrity. Above a few hundred ps risetime, it's generally not a big deal. JohnArticle: 123891
On Sep 6, 10:30 am, Weng Tianxiang <wtx...@gmail.com> wrote: > Andy, > Your following claim is false: > "...enable(n-1) must have been false.." > > Only enable() is a static, a foolish case, the above situation would > happen and your assertion part plays a role for a VHDL compiler. > Enable() is NOT static! It is a dynamic signal/variable that is driven from elsewhere. Note that I said "in order for enable(n) to be considered". I did NOT say "for enable(n) to be set"! If enable(n-1) was set, then the loop would have exited before evaluating enable(n). Therefore output gets data(n) only if enable(n) = '1' AND enable(n-1) = '0' AND enable(n-2) = '0' AND... This results in additional logic that is not necessary if it is known that the enable bits are mutually exclusive. If you don't believe me, compare the synthesis results of your code with Jim's code (since the assertion in my code is not understood by synthesis yet). Jim's code is the logical equivalent of what a synthesis tool should implement for your code (or my code), if the tool was aware of, and could optimize for, mutual exclusivity. > The static values may be all 0. So that no code would be generated for > the code segment. Are you serious enough to design a mechanims to deal > with the stupid case only? Since you ask, this function is intended for a clocked process, so "doing nothing" means maintaining the previous value (i.e. a clock enable), which is far from a "stupid case". AndyArticle: 123892
On Sep 6, 4:45 pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote: > > > > > > If you have the choice between UDP and TCP, UDP is much simpler and > > > fits an FPGA well. The big issue in choosing between the two is if you > > > require the guaranteed delivery of TCP, or can tollerate the potential > > > packet loss of UDP. > > > > As an example, we make a card that acquires real time data in a custom > > > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a > > > protocol offload engine that uses the Xilinx PicoBlaze soft processor > > > to deal with the protocol stack. The PicoBlaze is an 8-bit soft > > > processor. It looks at each incomming packet and reads the header to > > > see if it is one of the real time streams we are trying to offload. > > > If it is, it sends the header to one circular buffer in memory and the > > > data to another circular buffer. If it is not, it sends it to a > > > kernel buffer and we let the Linux network stack deal with it. > > > > With this setup, we can consume data at over 90 MB/sec per Gigabit > > > Ethernet port. The data part of the packet is 1024 bytes, and each > > > GigE port has its own PicoBlaze dedicated to it. > > > So where is the actual UDP communication implemented ? In Linux ? What > > processor is it running on ? Is it an external CPU or the built-in PPC > > of Virtex 4 ? > > We are using one of the embedded PowerPCs to run Linux, and one > PicoBlaze soft processor per EMAC in the design. > > As each packet exits the EMAC, its header is examined by software that > is running on the PicoBlaze. The PicoBlaze is running a very simple > stack written in assembly language. As it looks at each layer of the > header, it makes a decision to do one of several things. At the > Ethernet level, it is deciding if it should just throw the packet > away, or pass it on to the next layer. At the IP and UDP layers, it is > deciding if the packet belongs to the protocol that we are offloading, > and is a stream that we have requested. If the packet does belong to > the protocol that we are offloading, the PicoBlaze sets up a PLB DMA > engine to send it down one data path. If the packet does not belong to > the protocol we are offloading, then the PicoBlaze sends it down > another data path and it is given to the Linux kernel to deal with. > > So for the protocol that we are offloading, the entire Ethernet, IP, > UDP, and custom protocol stack are implemented in PicoBlaze assembly > code. For everything else, the stack is in Linux. Since the data we > are offloading is multicast data, this lets us have the PicoBlaze deal > with the simple but high speed UDP packets, and the PowerPC running > Linux deal with the IGMP messaging required to join, leave and > maintain membership in a multicast group. > > The PicoBlaze is just running a single threaded loop of code that > polls for input or output data, and then deals with it. Its program > is loaded from the PowerPC taking advantage of the fact that the BRAM > holding its program is dual ported. At what frequency does the PicoBlaze run ? It must be pretty fast to deal with packets at this bandwidth. Or is the fact that it's only examining the frame headers saves you from the need of high speed ? Thanks EliArticle: 123893
On Sep 6, 1:44 pm, "Symon" <symon_bre...@hotmail.com> wrote: > Dear All, > I found this online and found it useful. Maybe you will too.http://incompetech.com/graphpaper/ > Cheers, Syms. Very cute. I usually use Visio for making graph paper. They seem to be missing my favorite one - timing diagram paper. Regards, GaborArticle: 123894
What are the different ways of crossing clock boundaries. Is there any website with good information on that. Thanks AmishArticle: 123895
On Sep 6, 1:25 pm, eliben <eli...@gmail.com> wrote: > On Sep 6, 4:45 pm, John McCaskill <jhmccask...@gmail.com> wrote: > > > > > On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote: > > > > > If you have the choice between UDP and TCP, UDP is much simpler and > > > > fits an FPGA well. The big issue in choosing between the two is if you > > > > require the guaranteed delivery of TCP, or can tollerate the potential > > > > packet loss of UDP. > > > > > As an example, we make a card that acquires real time data in a custom > > > > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a > > > > protocol offload engine that uses the Xilinx PicoBlaze soft processor > > > > to deal with the protocol stack. The PicoBlaze is an 8-bit soft > > > > processor. It looks at each incomming packet and reads the header to > > > > see if it is one of the real time streams we are trying to offload. > > > > If it is, it sends the header to one circular buffer in memory and the > > > > data to another circular buffer. If it is not, it sends it to a > > > > kernel buffer and we let the Linux network stack deal with it. > > > > > With this setup, we can consume data at over 90 MB/sec per Gigabit > > > > Ethernet port. The data part of the packet is 1024 bytes, and each > > > > GigE port has its own PicoBlaze dedicated to it. > > > > So where is the actual UDP communication implemented ? In Linux ? What > > > processor is it running on ? Is it an external CPU or the built-in PPC > > > of Virtex 4 ? > > > We are using one of the embedded PowerPCs to run Linux, and one > > PicoBlaze soft processor per EMAC in the design. > > > As each packet exits the EMAC, its header is examined by software that > > is running on the PicoBlaze. The PicoBlaze is running a very simple > > stack written in assembly language. As it looks at each layer of the > > header, it makes a decision to do one of several things. At the > > Ethernet level, it is deciding if it should just throw the packet > > away, or pass it on to the next layer. At the IP and UDP layers, it is > > deciding if the packet belongs to the protocol that we are offloading, > > and is a stream that we have requested. If the packet does belong to > > the protocol that we are offloading, the PicoBlaze sets up a PLB DMA > > engine to send it down one data path. If the packet does not belong to > > the protocol we are offloading, then the PicoBlaze sends it down > > another data path and it is given to the Linux kernel to deal with. > > > So for the protocol that we are offloading, the entire Ethernet, IP, > > UDP, and custom protocol stack are implemented in PicoBlaze assembly > > code. For everything else, the stack is in Linux. Since the data we > > are offloading is multicast data, this lets us have the PicoBlaze deal > > with the simple but high speed UDP packets, and the PowerPC running > > Linux deal with the IGMP messaging required to join, leave and > > maintain membership in a multicast group. > > > The PicoBlaze is just running a single threaded loop of code that > > polls for input or output data, and then deals with it. Its program > > is loaded from the PowerPC taking advantage of the fact that the BRAM > > holding its program is dual ported. > > At what frequency does the PicoBlaze run ? It must be pretty fast to > deal with packets at this bandwidth. Or is the fact that it's only > examining the frame headers saves you from the need of high speed ? > > Thanks > Eli We run the EMAC 8 bits wide at 125 MHz, and the PicBlaze at 62.5 MHz using a divided by two version of the EMAC clock. The PicoBlaze takes two cycles per instruction, and the packets we are offloading are a bit over 1KB, so we about 512 instructions to deal with an offloaded packet and other overhead. Dealing with a non-offloaded packet takes the shortest path through the code to keep the number of packets per second we can handle up. The network the data is on is tightly controlled, so there is very little on it that is not the protocol we are offloading, mostly just IGMP packets for dealing with the multicast groups, and they are at a very low rate. You are correct in that we do not look at the entire packet with the PicoBlaze, just the header. Once it has determined that it wants to offload that packet, it then has a little bit more work to do to calculate addresses and load them into the DMA engine. To make sure that we do not drop packets, we just need to make sure that the longest path through the code takes less time than about how long it takes to receive a packet. We have a FIFO between the EMAC and the DMA engine, so we can smooth things out a bit. Regards, John McCaskill www.fastertechnology.comArticle: 123896
I have a design with 3 DCMs. The first DCM generates 280 MHz out of 210 MHz. It is then divided by 2 and 4 in a PMCD. There are 2 more DCMs, one driven by resulting 70 MHz clock and another by 140 MHz clock. Both have problem locking. Their resets are slightly delayed and negated locked condition of the first DCM. As it stands now I need to reset the first DCM a few times until I get all 3 locked (the first DCM locks every time easily). The frequency ranges for all of the DCMs seem to be set correctly. Any ideas? Thanks, /MikhailArticle: 123897
Forgot to mention that it is all taking place in a V4 device... /MikhailArticle: 123898
On Sep 6, 1:56 pm, "MM" <mb...@yahoo.com> wrote: > Forgot to mention that it is all taking place in a V4 device... > > /Mikhail The FX output jitter spec of the DCMs does not meet the input jitter requirements of the DCMs. What you are trying to do will not work reliably. Regards, John McCaskill www.fastertechnology.comArticle: 123899
"John McCaskill" <jhmccaskill@gmail.com> wrote in message news:1189105528.073561.184050@d55g2000hsg.googlegroups.com... > > The FX output jitter spec of the DCMs does not meet the input jitter > requirements of the DCMs. What you are trying to do will not work > reliably. Yes, I remember reading it... So, no hope here? Anyone from Xilinx? I don't care much about the output jitter on the two DCMs, I just need them to produce the clocks at right frequencies.... If I can't do it, I am in real trouble... Thanks, /Mikhail
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