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 2009-06-01, phil hays <philhays@dont.spam> wrote: > soar2morrow wrote: > > Has anyone tried to install a Xilinx floating license? > > Yes, three days ago. It really was no problem. And this was on Fedora, > which isn't supported. I just tried it on OpenSuse 11.0 (another unsupported linux version) and xlcm segfaulted as soon as I click on the "Manage Xilinx Licenses" tab. (Or rather, I would guess that it crashes as soon as I get some sort of response from the license server because it only crashes if the LM_LICENSE_FILE is set to point to our license server.) I guess I will have to find a windows machine and see if it is a linux/opensuse only problem or a problem in windows as well. /AndreasArticle: 141001
On Jun 1, 2:35=A0pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote: > On Mon, 1 Jun 2009 13:15:13 -0700 (PDT), "jack.gassett" > > <jack.gass...@gadgetfactory.net> wrote: > >Hello all, > > >I just wanted to post that I have released an open source FPGA circuit > >design. Please feel free to use it as is or to quick start your own > >designs. It is released under the Creative Commons Attribution license > >exactly like the Arduino. This is a work in progress so any feedback > >is appreciated. > > >Here are some specifications: > >-Schematic and Board layout in EAGLE. > > Just curious, but why EAGLE and not one of the open source schematic > capture and board layout apps like gEDA or Kicad? > > If you're not familiar with the DRM issues associated with EAGLE, here's > one person's experience: > <http://groups.google.com/group/comp.arch.embedded/browse_frm/thread/f...= > > > -- > Rich Webb =A0 =A0 Norfolk, VA Wow, that posting sounds pretty horrible, thanks for pointing that out. I went with EAGLE because there really seems to be a large community that loves EAGLE. I wanted to go with the closest thing to a standard that I could find and it seemed to be EAGLE. One thing that might make EAGLE more palatable is that the size of my designs easily fit within the Freeware version restrictions. So as long as there is no profit involved it is possible to use the Freeware version. If profit is involved it only costs $49 for a size restricted license which seems pretty reasonable. So I think for my design, which is small, EAGLE is a reasonable choice. If the design were bigger it would be less attractive to use EAGLE for something being released open source. I'll have to try gEDA and Kicad out on another project. Another reason for using EAGLE was that I'm just not familiar with gEDA or Kicad. Maybe once I give them a try I will be better informed for the next project. Thanks, Jack.Article: 141002
Hi, I know I can run synplify in batch mode. When this is finished, I can run ISE in tcl mode. In this way, I have to wait until synplify is done then can I start ISE job in tcl. Is it possible to run synplify in tcl, I mean in xtclsh, is it possible to run synplify first, then start ISE? thanks. regards skyworldArticle: 141003
On Tue, 2 Jun 2009 06:53:56 -0700 (PDT), "jack.gassett" <jack.gassett@gadgetfactory.net> wrote: >On Jun 1, 2:35 pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote: >> On Mon, 1 Jun 2009 13:15:13 -0700 (PDT), "jack.gassett" >> >> <jack.gass...@gadgetfactory.net> wrote: >> >Hello all, >> >> >I just wanted to post that I have released an open source FPGA circuit >> >design. Please feel free to use it as is or to quick start your own >> >designs. It is released under the Creative Commons Attribution license >> >exactly like the Arduino. This is a work in progress so any feedback >> >is appreciated. >> >> >Here are some specifications: >> >-Schematic and Board layout in EAGLE. >> >> Just curious, but why EAGLE and not one of the open source schematic >> capture and board layout apps like gEDA or Kicad? >> >> If you're not familiar with the DRM issues associated with EAGLE, here's >> one person's experience: >> <http://groups.google.com/group/comp.arch.embedded/browse_frm/thread/f...> >> >> -- >> Rich Webb Norfolk, VA > >Wow, that posting sounds pretty horrible, thanks for pointing that >out. I went with EAGLE because there really seems to be a large >community that loves EAGLE. I wanted to go with the closest thing to a >standard that I could find and it seemed to be EAGLE. One thing that >might make EAGLE more palatable is that the size of my designs easily >fit within the Freeware version restrictions. So as long as there is >no profit involved it is possible to use the Freeware version. If >profit is involved it only costs $49 for a size restricted license >which seems pretty reasonable. So I think for my design, which is >small, EAGLE is a reasonable choice. If the design were bigger it >would be less attractive to use EAGLE for something being released >open source. > >I'll have to try gEDA and Kicad out on another project. Another reason >for using EAGLE was that I'm just not familiar with gEDA or Kicad. >Maybe once I give them a try I will be better informed for the next >project. Roger that. Lots of folks do get along just fine with EAGLE -- and I don't know how or whether the DRM-lockout issue affects the free version. One other thing to keep in mind is that EAGLE does not offer hierarchical schematics. Probably not a big issue for the free version but that capability is something you would likely really miss on large projects. -- Rich Webb Norfolk, VAArticle: 141004
On 15 May, 19:31, Tommy Thorn <tommy.th...@gmail.com> wrote: > On May 11, 1:02=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > it will be only short clip in localTV(estonian, kanal-2) in the DIY > > show, but was still funny to look into the camera with FPGA board in th= e > > hands. > > Is there a way to see this clip for non-estonians? > > Thanks, > > Tommy Hi Tommy it's online officially, the page is full of ads, but the clip is there too http://www.reporter.ee/2009/05/29/elektroonik-antti-leiutis-paneb-jonglased= -roomust-kilkama/ AnttiArticle: 141005
hi all as far a today as far as today i think that variables ,operators like '/','*' are unsynthesizable and have avoided their use. but if they are to be avoided how can we implement complex algorithms using VHDL. Should all the complex algorithms be left for microblaze? i wanted to create a hardware module which would process the data from accelerometer but i have to use the formula A=(t1/t2-50)/12.5. can a hardware module process this kind of formula or it should be left for microblaze. so please clear me about the reach and extent of VHDL. where the role of VHDL ends and where the role of microblaze comes into action. thank you prashantaArticle: 141006
doug <xx@xx.com> wrote: < Bond wrote: <> as far a today as far as today i think that variables, <> operators like '/','*' are unsynthesizable and have <> avoided their use. but if they are to be avoided how can <> we implement complex algorithms using VHDL. <> Should all the complex algorithms be left for microblaze? <> i wanted to create a hardware module which would process the <> data from accelerometer but i have to use the <> formula A=(t1/t2-50)/12.5. can a hardware module process this <> kind of formula or it should be left for microblaze. (snip) < You are thinking in terms of software. VHDL is a hardware description < language where you build hardware. You certainly can build hardware < to do multiply and divide but you need to understand what you are doing. < If you want to do programming, do software. If you want to do hardware < design, you have to do hardware design. They are different. If microblaze is fast enough, then it should probably be done that way. Though many now will synthesize multiply, especially on FPGAs with hardware multipliers, and likely also divide by constants, divide by a variable is less likely. If you write verilog like you were working with a box of TTL chips. (Well, maybe 74HCT by now.) then you won't get too lost. You are doing hardware design, and one thing that has to be designed is a divider. How fast does it need to be? How many stages of pipelining? How many quotient bits? Those all need to be known, and the synthesizer is unlikely to figure them out from a / operator. If you want a pipelined multiplier, you usually have to write that out, too. (Though many systems will have generators for special logic block that will do it given the appropriate parameters.) < Whether it is worth the effort to do the math in hardware is dependent < on what else you are doing. If there is to be a microblaze in the < system, it is less work to just do the math there. If the only reason < to exist for the microblaze is to do the math, it is probably easier < to do it in hardware. Especially how fast it needs to be. -- glenArticle: 141007
So does anyone understand the point of Tektronix's new TekVPI probe
interface? It seems to me pure connector conspiracy:
So lets see, now we have:
TekProbe-II: long standing probes...
TekVPI: 4 GHz probe interface, but pointlessly different from TekProbe-II.
$400 adaptors allow you to use TekProbe-II probes...
TekConnect: different from above to exceed 4 GHz BNC limit...
TAP1500 vs. P6245... no difference in specs, but TAP1500 cost more. P6245
available used for very little money.
The Agilent situations seems better. Their "high precision" BNC connectors
are used on all of their scopes so all probes are more or less compatible
with all scopes.
I traditionally prefer Tektronix, but their probe situation is starting to
really bug me.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 141008On Jun 1, 3:34=A0pm, phil hays <philh...@dont.spam> wrote: > soar2morrow wrote: > > Has anyone tried to install a Xilinx floating license? > > Yes, three days ago. It really was no problem. And this was on Fedora, > which isn't supported. > > > Now, just try to find XLCM on Xilinx's website (all you will find are > > references to it. > > If the Xilinx tools are installed on the system, open a command prompt > and type xclm. > > > To further complicate issues, it seems like the only > > way to get help of ANY KIND is to submit a web case. Just try to talk t= o > > someone on the phone! I actually did; guess what they said: SUBMIT A WE= B > > CASE! > > I'll be happy to solve problems like this for you for $85/hour plus > expenses and travel. Send me an email. I'm very familiar with the Xilinx > tools and FPGA design. > > -- > Phil Hays > (phil_hays at eeei.gro (fix the order for email) I installed the floating license yesterday on Windows 64-bit server. So far so good. Speaking of licenses, we needed a few node-locked licenses in addition to the floating one. It made things much more expensive and as the result we want to re-evaluate our commitment to Xilinx. Does anybody have a recent experience with Altera licensing cost. -outputlogic -- visit http://outputlogic.com : tools that improve productivity --Article: 141009
On Tue, 2 Jun 2009 08:16:45 -0700 (PDT), Bond wrote: > as far a today as far as today i think that variables ,operators like >'/','*' > are unsynthesizable Nonsense. Variables and * are fine for synthesis, as long as you understand that * will create rather large hardware in devices that don't have on-chip multipliers. Using variables for synthesis is a well-established technique that's been discussed here and on comp.lang.vhdl many times before. >i have to use the formula A=(t1/t2-50)/12.5 As others have asked, the key question is: how often (how fast) do you need to do this? For many of these sensor signal conditioning problems, you may find that the input values have interesting properties that can make the calculations easier if you are sufficiently ingenious. Tell us more. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 141010
> On Jun 1, 11:35 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>> The beauty of the DDS scheme is that the ratio between the two
>> frequencies (100 MHz and 2 MHz in this case) can be approximated by an
>> arbitrary long binary number, the length of the accumulator. A 27-bit
>> accumulator can represent any integer Hz, if that is what matters.
>> But nothing can possibly compensate for 100 MHz frequency drift while
>> the 2 MHz pulses are missing. That would need clairvoyance...
>> Peter A
Yes. I think Rick missed the point.
The phase accumulator portion of a DDS cirucit
is very useful for frequency synthesis and calibration.
Sine waves are optional.
rickman wrote:
> How about an infinite improbability drive circuit? That could work,
> at least in theory.
It works well in fiction.
-- Mike Treseler
Article: 141011jhallen@TheWorld.com (Joseph H Allen) writes: > So does anyone understand the point of Tektronix's new TekVPI probe > interface? It seems to me pure connector conspiracy: That's what I assumed too. > So lets see, now we have: > > TekProbe-II: long standing probes... > > TekVPI: 4 GHz probe interface, but pointlessly different from TekProbe-II. > $400 adaptors allow you to use TekProbe-II probes... > > TekConnect: different from above to exceed 4 GHz BNC limit... > > TAP1500 vs. P6245... no difference in specs, but TAP1500 cost more. P6245 > available used for very little money. The high-end scopes don't even come with probes. They offer a discount scheme, e.g. "2.5GHz for the price of 1GHz". But the 2.5GHz model does not come with probes, which are $4000 each... > The Agilent situations seems better. Their "high precision" BNC connectors > are used on all of their scopes so all probes are more or less compatible > with all scopes. Didn't know that, never used an Agilent. > I traditionally prefer Tektronix, but their probe situation is starting to > really bug me. That "legacy" probe situation helped to stop me spending ~$10-20k. -- John DevereuxArticle: 141012
Bond wrote: > hi all > as far a today as far as today i think that variables ,operators like > '/','*' > are unsynthesizable and have > avoided their use. but if they are to be avoided how can we implement > complex algorithms using VHDL. Should all the complex algorithms be > left for > microblaze? i wanted to create a hardware module which would process > the > data from accelerometer but i have to use the > formula A=(t1/t2-50)/12.5. can a hardware module process this kind of > formula or it should be left for microblaze. so please clear me about > the > reach and extent of VHDL. where the role of VHDL ends and where the > role of > microblaze comes into action. > thank you > prashanta > You are thinking in terms of software. VHDL is a hardware description language where you build hardware. You certainly can build hardware to do multiply and divide but you need to understand what you are doing. If you want to do programming, do software. If you want to do hardware design, you have to do hardware design. They are different. Whether it is worth the effort to do the math in hardware is dependent on what else you are doing. If there is to be a microblaze in the system, it is less work to just do the math there. If the only reason to exist for the microblaze is to do the math, it is probably easier to do it in hardware.Article: 141013
"jack.gassett" <jack.gassett@gadgetfactory.net> wrote in message news:10a0fac4-ac31-4563-a8f2-b8986a8c69d8@h28g2000yqd.googlegroups.com... On Jun 1, 2:35 pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote: > On Mon, 1 Jun 2009 13:15:13 -0700 (PDT), "jack.gassett" > If you're not familiar with the DRM issues associated with EAGLE, here's > one person's experience: > <http://groups.google.com/group/comp.arch.embedded/browse_frm/thread/f...> > > -- > Rich Webb Norfolk, VA Wow, that posting sounds pretty horrible, thanks for pointing that out. I went with EAGLE because there really seems to be a large ======= That does sound pretty inconvenient. The OP in the referenced thread didn't say if he tried cleaning up his old files using the old version, removing the offending part. For sure, it's a real PITA and waste of time, but not entirely a showstopper or a loss of his work. Just open it in the old version and remove the darned part. I could be wrong. He only relates that CadSoft said they wouldn't help him, and he went on to shrug and say no big loss. Not that I'm apologizing for CadSoft. I used EAGLE years ago, and while the interface was cryptically weird at times, it was the best thing going for small shops and DIY hobbyists.Article: 141014
Hi does anybody have real and realistic performance figures for Xilinx GbE solution with XPS_TEMAC/MPMC ? we need to get 60% of GbE wirespeed, UDP transmit only but it seems like real hard target to reach :( MPMC has memory latency of 23 cycles (added to EACH memory access cycle) so the ethernet SDMA takes a lot of bandwith already, there is another DMA writing data at same speed, and the PPC itself uses the same memory too AnttiArticle: 141015
"Joseph H Allen" <jhallen@TheWorld.com> wrote in message news:h03ib3$k9p$1@pcls6.std.com... > So does anyone understand the point of Tektronix's new TekVPI probe > interface? Possibly. It was meant to be as flexible as TekConnect (in terms of being able to hook up voltage probes, current probes, etc. and having them all "just work" and allowing *bi-drectional* communication between the probe and the 'scope) -- which is more flexible than what TekProbe II can do (but if you're just using "simple" probes you'll never see this...) -- while being inexpensive (mainly much cheapter than TekConnect, which is quite spendy given the need to support >4GHz... and as cheap or cheaper than TekProbe II). VPI stands for "Value Probe Initiative," and there was a bit of a running joke about how much of that "value" was for the end-user vs. Tektronix. :-) > TAP1500 vs. P6245... no difference in specs, but TAP1500 cost more. P6245 > available used for very little money. The lower-end digital scope market is quite competitive... so I expect that a lot of margin is now built into accessories with the core scope price cut to the bones. The "average" sales price of a scope today is probably <$5k, whereas when TekProbe II came out it was >$10k... which would be even more in "today's" money. ---JoelArticle: 141016
On Jun 2, 12:30=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > > On Jun 1, 11:35 pm, Peter Alfke <al...@sbcglobal.net> wrote: > >> The beauty of the DDS scheme is that the ratio between the two > >> frequencies (100 MHz and 2 MHz in this case) can be approximated by an > >> arbitrary long binary number, the length of the accumulator. A 27-bit > >> accumulator can represent any integer Hz, if that is what matters. > >> But nothing can possibly compensate for 100 MHz frequency drift while > >> the 2 MHz pulses are missing. That would need clairvoyance... > >> Peter A > > Yes. I think Rick missed the point. > The phase accumulator portion of a DDS cirucit > is very useful for frequency synthesis and calibration. > Sine waves are optional. "The beauty of the DDS scheme is that the ratio between the two frequencies (100 MHz and 2 MHz in this case) can be approximated by an arbitrary long binary number, the length of the accumulator." This may actually be irrelevant in this case. If the 2 MHz signal is an "arbitrary" frequency, then yes, a DCO is useful (although a DDS is total overkill). If the OP actually has a 2 MHz signal, not 2.00001 MHz, not 1.99999 MHz, but 2.0 MHz to as good an accuracy as his system clock, then there is no point in using a DCO since the ratio can be approximated by a 6 bit counter, a divide by 50! Like I said in my other post, until we know more about the problem, possibly more than the OP knows about it, we can't say if a DCO would provide a noticeably better solution than a divide by 50. I think we often get conditioned into thinking a certain way about accuracy and other sorts of optimizations that in any given problem may not be useful. RickArticle: 141017
In article <CZcVl.51777$Xo1.33938@en-nntp-07.dc1.easynews.com>,
Joel Koltner <zapwireDASHgroups@yahoo.com> wrote:
>VPI stands for "Value Probe Initiative," and there was a bit of a running joke
>about how much of that "value" was for the end-user vs. Tektronix. :-)
Hmm.. this might be the problem: US Patent 4708661, Nov. 24 1987. "Modified
BNC Connector for Active Probe". It looks like the TekProbe patent ran out.
The new patent is: D566047 (Apr 2008). Claim: "The ornamental design of a
plug for accessory-host interface, as shown and described."
So there is no technical advantage, it's just an ornamental design which
is patented that so nobody can copy it. Nice.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 141018On Jun 2, 1:20 pm, rickman <gnu...@gmail.com> wrote: > On Jun 2, 12:30 pm, Mike Treseler <mtrese...@gmail.com> wrote: > > > > On Jun 1, 11:35 pm, Peter Alfke <al...@sbcglobal.net> wrote: > > >> The beauty of the DDS scheme is that the ratio between the two > > >> frequencies (100 MHz and 2 MHz in this case) can be approximated by an > > >> arbitrary long binary number, the length of the accumulator. A 27-bit > > >> accumulator can represent any integer Hz, if that is what matters. > > >> But nothing can possibly compensate for 100 MHz frequency drift while > > >> the 2 MHz pulses are missing. That would need clairvoyance... > > >> Peter A > > > Yes. I think Rick missed the point. > > The phase accumulator portion of a DDS cirucit > > is very useful for frequency synthesis and calibration. > > Sine waves are optional. > > "The beauty of the DDS scheme is that the ratio between the two > frequencies (100 MHz and 2 MHz in this case) can be approximated by an > arbitrary long binary number, the length of the accumulator." > > This may actually be irrelevant in this case. If the 2 MHz signal is > an "arbitrary" frequency, then yes, a DCO is useful (although a DDS is > total overkill). If the OP actually has a 2 MHz signal, not 2.00001 > MHz, not 1.99999 MHz, but 2.0 MHz to as good an accuracy as his system > clock, then there is no point in using a DCO since the ratio can be > approximated by a 6 bit counter, a divide by 50! > > Like I said in my other post, until we know more about the problem, > possibly more than the OP knows about it, we can't say if a DCO would > provide a noticeably better solution than a divide by 50. > > I think we often get conditioned into thinking a certain way about > accuracy and other sorts of optimizations that in any given problem > may not be useful. > > Rick yes, this is along the lines I was thinking. and as far as the improbability drive is concerned, I do have a nice cup of really, really hot tea... the rs485 signal consists of two input pins, a data line, and the 2MHz clock signal for the data line. At this time the data line is insignificant, it is a slave to the clock pulses of the timing signal.Article: 141019
On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > Hi > > does anybody have real and realistic performance figures for Xilinx > GbE solution with XPS_TEMAC/MPMC ? > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > like real hard target to reach :( > > MPMC has memory latency of 23 cycles (added to EACH memory access > cycle) so the ethernet > SDMA takes a lot of bandwith already, there is another DMA writing > data at same speed, and the > PPC itself uses the same memory too > > Antti With custom Ethernet core + MPMC we get data rates slightly above 100MBps, depending on MTU. The single memory is shared by MicroBlaze/PPC for code and data access, at least one streaming data source (custom PIM for NPI) and the custom Ethernet IP (MAC + some packet composers, decoders, etc.) again connected to NPI. We rejected to use XPS_TEMAC because its low performance. The problem is I lost my benchmark results. Sorry. JanArticle: 141020
On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > > Hi > > > does anybody have real and realistic performance figures for Xilinx > > GbE solution with XPS_TEMAC/MPMC ? > > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > > like real hard target to reach :( > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > cycle) so the ethernet > > SDMA takes a lot of bandwith already, there is another DMA writing > > data at same speed, and the > > PPC itself uses the same memory too > > > Antti > > With custom Ethernet core + MPMC we get data rates slightly above > 100MBps, depending on MTU. The single memory is shared by MicroBlaze/PPC > for code and data access, at least one streaming data source (custom PIM > for NPI) and the custom Ethernet IP (MAC + some packet composers, > decoders, etc.) again connected to NPI. > We rejected to use XPS_TEMAC because its low performance. The problem is > I lost my benchmark results. Sorry. > > Jan hum.. my current task is to optimize a XPS_TEMAC based system (with 1 single DDR2 chip as main memory!) to reach about 580MBps :( I have never said that to be possible, but i need money :( and if the goal cant be reached there will be none... over 100MBps is sure possible (with XPS_TEMAC too) but 580MBps is beyong doable i think for sure AnttiArticle: 141021
<Antti.Lukats@googlemail.com> wrote in message news:45a07ecd-3a6c-4047-a640-cb5706d0b26b@k2g2000yql.googlegroups.com... > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: >> On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: >> > Hi >> >> > does anybody have real and realistic performance figures for Xilinx >> > GbE solution with XPS_TEMAC/MPMC ? >> >> > we need to get 60% of GbE wirespeed, UDP transmit only but it seems >> > like real hard target to reach :( >> >> > MPMC has memory latency of 23 cycles (added to EACH memory access >> > cycle) so the ethernet >> > SDMA takes a lot of bandwith already, there is another DMA writing >> > data at same speed, and the >> > PPC itself uses the same memory too >> >> > Antti >> >> With custom Ethernet core + MPMC we get data rates slightly above >> 100MBps, depending on MTU. The single memory is shared by MicroBlaze/PPC >> for code and data access, at least one streaming data source (custom PIM >> for NPI) and the custom Ethernet IP (MAC + some packet composers, >> decoders, etc.) again connected to NPI. >> We rejected to use XPS_TEMAC because its low performance. The problem is >> I lost my benchmark results. Sorry. >> >> Jan > > hum.. my current task is to optimize a XPS_TEMAC based system > (with 1 single DDR2 chip as main memory!) > to reach about 580MBps > > :( > > I have never said that to be possible, but i need money :( > and if the goal cant be reached there will be none... > > over 100MBps is sure possible (with XPS_TEMAC too) > but 580MBps is beyong doable i think for sure > > Antti > > > > >over 100MBps is sure possible (with XPS_TEMAC too) really? over GbE? impossible! I take it you mean over 100Mbps which is far more plausible. PhilArticle: 141022
On Tue, 2009-06-02 at 11:32 -0700, Antti.Lukats@googlemail.com wrote: > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > > On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > > > Hi > > > > > does anybody have real and realistic performance figures for Xilinx > > > GbE solution with XPS_TEMAC/MPMC ? > > > > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > > > like real hard target to reach :( > > > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > > cycle) so the ethernet > > > SDMA takes a lot of bandwith already, there is another DMA writing > > > data at same speed, and the > > > PPC itself uses the same memory too > > > > > Antti > > > > With custom Ethernet core + MPMC we get data rates slightly above > > 100MBps, depending on MTU. The single memory is shared by MicroBlaze/PPC > > for code and data access, at least one streaming data source (custom PIM > > for NPI) and the custom Ethernet IP (MAC + some packet composers, > > decoders, etc.) again connected to NPI. > > We rejected to use XPS_TEMAC because its low performance. The problem is > > I lost my benchmark results. Sorry. > > > > Jan > > hum.. my current task is to optimize a XPS_TEMAC based system > (with 1 single DDR2 chip as main memory!) > to reach about 580MBps > > :( > > I have never said that to be possible, but i need money :( > and if the goal cant be reached there will be none... > > over 100MBps is sure possible (with XPS_TEMAC too) > but 580MBps is beyong doable i think for sure > > Antti > Just a simple calculation: 125000000 / 1024 / 1024 = 119.2MBps It is without protocol overhead, FCS, IFGs. How do you want to exceed limit of Gigabit Ethernet? JanArticle: 141023
On Tue, 2009-06-02 at 20:47 +0200, Jan Pech wrote: > On Tue, 2009-06-02 at 11:32 -0700, Antti.Lukats@googlemail.com wrote: > > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > > > On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > > > > Hi > > > > > > > does anybody have real and realistic performance figures for Xilinx > > > > GbE solution with XPS_TEMAC/MPMC ? > > > > > > > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > > > > like real hard target to reach :( > > > > > > > MPMC has memory latency of 23 cycles (added to EACH memory access > > > > cycle) so the ethernet > > > > SDMA takes a lot of bandwith already, there is another DMA writing > > > > data at same speed, and the > > > > PPC itself uses the same memory too > > > > > > > Antti > > > > > > With custom Ethernet core + MPMC we get data rates slightly above > > > 100MBps, depending on MTU. The single memory is shared by MicroBlaze/PPC > > > for code and data access, at least one streaming data source (custom PIM > > > for NPI) and the custom Ethernet IP (MAC + some packet composers, > > > decoders, etc.) again connected to NPI. > > > We rejected to use XPS_TEMAC because its low performance. The problem is > > > I lost my benchmark results. Sorry. > > > > > > Jan > > > > hum.. my current task is to optimize a XPS_TEMAC based system > > (with 1 single DDR2 chip as main memory!) > > to reach about 580MBps > > > > :( > > > > I have never said that to be possible, but i need money :( > > and if the goal cant be reached there will be none... > > > > over 100MBps is sure possible (with XPS_TEMAC too) > > but 580MBps is beyong doable i think for sure > > > > Antti > > > > Just a simple calculation: > 125000000 / 1024 / 1024 = 119.2MBps > It is without protocol overhead, FCS, IFGs. How do you want to exceed > limit of Gigabit Ethernet? > > Jan > Or did I get you wrong and you talk about Mbits per second? I was talking about Mbytes per sec. If it is so, your goal should be reachable using xps_ll_temac instead of xps_temac. JanArticle: 141024
On 2 June, 21:46, "Phil Jessop" <p...@noname.org> wrote: > <Antti.Luk...@googlemail.com> wrote in message > > news:45a07ecd-3a6c-4047-a640-cb5706d0b26b@k2g2000yql.googlegroups.com... > > > > > On 2 June, 21:05, Jan Pech <inva...@void.domain> wrote: > >> On Tue, 2009-06-02 at 09:53 -0700, Antti wrote: > >> > Hi > > >> > does anybody have real and realistic performance figures for Xilinx > >> > GbE solution with XPS_TEMAC/MPMC ? > > >> > we need to get 60% of GbE wirespeed, UDP transmit only but it seems > >> > like real hard target to reach :( > > >> > MPMC has memory latency of 23 cycles (added to EACH memory access > >> > cycle) so the ethernet > >> > SDMA takes a lot of bandwith already, there is another DMA writing > >> > data at same speed, and the > >> > PPC itself uses the same memory too > > >> > Antti > > >> With custom Ethernet core + MPMC we get data rates slightly above > >> 100MBps, depending on MTU. The single memory is shared by MicroBlaze/P= PC > >> for code and data access, at least one streaming data source (custom P= IM > >> for NPI) and the custom Ethernet IP (MAC + some packet composers, > >> decoders, etc.) again connected to NPI. > >> We rejected to use XPS_TEMAC because its low performance. The problem = is > >> I lost my benchmark results. Sorry. > > >> Jan > > > hum.. my current task is to optimize a XPS_TEMAC based system > > (with 1 single DDR2 chip as main memory!) > > to reach about 580MBps > > > :( > > > I have never said that to be possible, but i need money :( > > and if the goal cant be reached there will be none... > > > over 100MBps is sure possible (with XPS_TEMAC too) > > but 580MBps is beyong doable i think for sure > > > Antti > > =A0> > > >over 100MBps is sure possible (with XPS_TEMAC too) > > really? over GbE? =A0impossible! > > I take it you mean over 100Mbps which is far more plausible. > > Phil yes, sorry, i did mean XPS_TEMAC/MPMC, GbE (1000 base-X fiber) > 100MBps is OK 580MBps -- hardly possible Antti
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