Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search

Messages from 141000

Article: 141000
Subject: Re: Has anyone tried to install a Xilinx floating license? The documentation (UG631 (v 11.1.0) April 27, 2009) says that the required
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 2 Jun 2009 10:22:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

/Andreas

Article: 141001
Subject: Re: Open Source FPGA circuit design.
From: "jack.gassett" <jack.gassett@gadgetfactory.net>
Date: Tue, 2 Jun 2009 06:53:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: how to run synplify & ise in tcl?
From: chenyong20000@gmail.com
Date: Tue, 2 Jun 2009 06:56:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

skyworld

Article: 141003
Subject: Re: Open Source FPGA circuit design.
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Tue, 02 Jun 2009 10:26:00 -0400
Links: << >>  << T >>  << A >>
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, VA

Article: 141004
Subject: Re: verilog in TV show (soon)
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 2 Jun 2009 07:34:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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/

Antti

Article: 141005
Subject: the reach of VHDL
From: Bond <prashant.gyawali@gmail.com>
Date: Tue, 2 Jun 2009 08:16:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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


Article: 141006
Subject: Re: the reach of VHDL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 2 Jun 2009 15:54:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 141007
Subject: Tektronix vs. Agilent, probes
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 2 Jun 2009 16:00:35 +0000 (UTC)
Links: << >>  << T >>  << A >>

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: 141008
Subject: Re: Has anyone tried to install a Xilinx floating license? The
From: OutputLogic <evgenist@gmail.com>
Date: Tue, 2 Jun 2009 09:06:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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
Subject: Re: the reach of VHDL
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 02 Jun 2009 17:23:49 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: phase locking a slow (2Mhz) signal.
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 02 Jun 2009 09:30:54 -0700
Links: << >>  << T >>  << A >>

> 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: 141011
Subject: Re: Tektronix vs. Agilent, probes
From: John Devereux <john@devereux.me.uk>
Date: Tue, 02 Jun 2009 17:32:32 +0100
Links: << >>  << T >>  << A >>
jhallen@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 Devereux

Article: 141012
Subject: Re: the reach of VHDL
From: doug <xx@xx.com>
Date: Tue, 02 Jun 2009 08:38:58 -0800
Links: << >>  << T >>  << A >>


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
Subject: Re: Open Source FPGA circuit design.
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Tue, 2 Jun 2009 11:51:23 -0500
Links: << >>  << T >>  << A >>
"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
Subject: Xilinx GbE performance
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 2 Jun 2009 09:53:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 141015
Subject: Re: Tektronix vs. Agilent, probes
From: "Joel Koltner" <zapwireDASHgroups@yahoo.com>
Date: Tue, 2 Jun 2009 10:05:35 -0700
Links: << >>  << T >>  << A >>
"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.

---Joel



Article: 141016
Subject: Re: phase locking a slow (2Mhz) signal.
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 Jun 2009 10:20:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 141017
Subject: Re: Tektronix vs. Agilent, probes
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 2 Jun 2009 17:29:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
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: 141018
Subject: Re: phase locking a slow (2Mhz) signal.
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 2 Jun 2009 10:35:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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
Subject: Re: Xilinx GbE performance
From: Jan Pech <invalid@void.domain>
Date: Tue, 02 Jun 2009 20:05:44 +0200
Links: << >>  << T >>  << A >>

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



Article: 141020
Subject: Re: Xilinx GbE performance
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 2 Jun 2009 11:32:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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







Article: 141021
Subject: Re: Xilinx GbE performance
From: "Phil Jessop" <phil@noname.org>
Date: Tue, 2 Jun 2009 19:46:57 +0100
Links: << >>  << T >>  << A >>

<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.

Phil 



Article: 141022
Subject: Re: Xilinx GbE performance
From: Jan Pech <invalid@void.domain>
Date: Tue, 02 Jun 2009 20:47:29 +0200
Links: << >>  << T >>  << A >>

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


Article: 141023
Subject: Re: Xilinx GbE performance
From: Jan Pech <invalid@void.domain>
Date: Tue, 02 Jun 2009 20:50:47 +0200
Links: << >>  << T >>  << A >>

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.
Jan


Article: 141024
Subject: Re: Xilinx GbE performance
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 2 Jun 2009 11:51:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search