EDK : FSL macros defined by Xilinx are wrong

[Joseph H Allen]

In article <442b7087$0$58081$742ec2ed@news.sonic.net>,
Tommy Thorn <foobar@nowhere.void> wrote:

JJ wrote:
I am surprised that we haven't seen alot more native FPGA MTA designs
though,.

In addition to what I mentioned, there's surely more inertia issues and
the complication of multi-threaded software (assuming you can even take
advantage of it).

I've worked on FPGA based NPs. It is a no-brainer for this case, each
packet can be treated as a separate thread. With enough buffering it's
feasible to have 16 threads, which conveniently matches the size of Xilinx
SRL16s. A simple micro-engine will run at 200 MHz with this technique, and
ends up being the same physical size as the single-threaded version.
--
/* jhallen@world.std.com (192.74.137.5) */ /* 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%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Joseph]

Jeff,

Well, your surprise at my clocking was warranted... I checked and I
seem to be running everything at 100Mhz now. Now I am curious if I can
get the speeds up as well. My processors do communicate well over the
OCM still. I think what happened for me was that I saw the 4:1 ratio
in the block reference guide and realized that my different clocks were
causing a problem. I probably, at that point, made everything run at
100Mhz and gave BRAMDSOCMCLK the same clock as the processor to be
certain I would get 1:1. When I posted to the group, I got the ratio
backwards (upside-down?). Thanks for setting me straight!

Like you, I have moved on and around this problem a bit. I was
surprised to see the clock values I had in my system. If I get time, I
may adjust them... maybe try the whole system at 200Mhz and see what
happens. Or just try 4:1 to see if things work. Speed isn't as
important in my system as it seems to be in yours, just the coherent
communcation is what matters. Oh, those touchy OCMs...

Joey

 

[Markus]

Weng Tianxiang schrieb:

On Jun 15, 4:36 am, rickman <gnu...@gmail.com> wrote:
On Jun 14, 1:21 pm, Weng Tianxiang <wtx...@gmail.com> wrote:





Hi,
I recently read Altera Stratix II, III and IV device handbook and
found its 3-bit addition circuit is really a genius invention. But I
was surprised to find that Altera patent application "Logic Cell
Supporting Addition of Three Binary Words" filed on Nov. 21, 2003 has
not been approved to be a patent so far today, even though many Altera
later patent applications based on the invention have been approved
for U.S. patents.
Is anyone knowledgable about the patent application willing to
transfer the patent application context to me and disclose why it
hasn't been approved as a U.S. patent.
My guess is it may never be approved by U.S. Patent Office to be a
patent, the reason is not its novelty violation, but its context
didn't disclose enough information about the 3-bit addition circuit, a
requirement for any patent application to be approved to be a U.S.
patent. At least those skilled in the art cannot get the idea what is
done within its circuit having an encircled '+' with 3 inputs and 2
outputs.
Altera another sister patent application "Arithmetic Structure is for
Programmable Logic Device" filed on Oct. 23, 2003 has the same fate.
Thank you.
Weng
I don't know why Altera wouldn't disclose info on the structure being
used in a device. It is relatively inexpensive to reverse engineer a
chip, so if it is not disclosed in a patent, it is not protected and
is vulnerable to being copied.

What exactly *does* the patent claim? Maybe the design inside the
circled + is not really novel and only the design around the circle is
novel enough to be patented?

In general, I think a three in put adder is *very useful*. I've never
seen such a circuit, I guess the carry chain has multiple bits, eh?

Rick- Hide quoted text -

- Show quoted text -


Hi Rick,
Here is a link to Stratix IV Device Handbook Volumn 1 and page 43
shows the invention circuit:
http://www.altera.com/literature/hb/stratix-iv/stx4_5v1.pdf

Why is it very useful? In the Stratix IV Device Handbook Volumn 1, it
describes two applications: multiplication and correlation function.

Any other applications? With multiplier hardware structure specially
introduced in FPGA, is multiplication circuit still used for
multiplication?
The structure is useful for:

- multipliers with a deep pipeline
- constant coefficient multipliers
- multipliers with small input values (i.e. few bits/operand)


-Markus

 

[John Larkin]

On Wed, 29 Jul 2009 10:25:49 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

On Jul 28, 6:55 pm, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Tue, 28 Jul 2009 15:12:35 -0700, "Joel Koltner"



zapwireDASHgro...@yahoo.com> wrote:
http://i.cmpnet.com/eetimes/news/09/07/1565chart_pg18.gif

Interesting, indeed.

Cypress had viable products but I'm convinced that management was the problem.
(I also remember they wanted a rather large premium for their CPLDs that were
sometimes only marginally better than the competition's.)

I don't know what Vantis's problem was, but at least after Lattive bought them
they kept a few of the parts around.

Intel doesn't have its heart in much of anything but their desktop CPUs --
they consistently bring out interesting products and then discontinue them
just when they're starting to gain traction.

You're pretty much a pure Xilinx man these days, aren't you, John?

Yes, although I occasionally use a 22V10 for glue logic and such.
We've used MMI, Gould/AMI, Actel, TI, and Lattice in the past.

We've been meaning to start using some CoolRunner type CPLDs for
various things, but no compelling application has come up.

Where the hell are the Spartan 6's? Nobody will tell me when we can
get some. Sales reps fall off the face of the Earth when you ask that
question. The best I can get is "available for purchase in September"
and nobody knows what that means.

So what else is new about Xilinx??? Same old, same old...

I don't get all worked up about the latest and greatest tech in FPGA
chips. I am much more concerned with availability and price than I am
getting the smallest geometry or the most developed technology. So
much of that stuff is actually in the noise when building a product.
I care how well my vehicle moves, the MPG and how often it goes in the
shop. Why should I care how many cylinders, how many valves or even
if it is electric?

With FPGAs, I care about if I can actually get them, will my design
fit (along with any future expansion allowance) and how much it costs,
optionally with what packaging if that matters in a given design. The
rest is in the noise including, for the top three, the tool set.

Turns out the there *are* some engineering-sample S6's available, and
it looks like we may get a few, so we can design them into a couple of
new projects.

Sadly, we are on the FPGA-addiction bandwagon. Every new gen of speed
and goodies lets us pump up the performance of a product, or write an
even-more-ludicrous proposal. In the current case, the S6/45 has two
hard DRAM controllers, megabits of block ram, and 58 DSP slices, most
of which resources we intend to gobble up. I can ask my FPGA guy for
the most insane signal processing, and in a few hours it's done.

John

 

[JosephKK]

On Wed, 29 Jul 2009 11:09:17 -0700, "Pete Fraser" <pfraser@covad.net>
wrote:

"Philip Pemberton" <usenet09@philpem.me.uk> wrote in message
news:00b7c995$0$4795$c3e8da3@news.astraweb.com...

Signetics were definitely before MMI.

Yes. I remember marking up fuse maps by hand,
then sending them away to Signetics and waiting
for a couple of days to get the parts back.

After a few weeks we got an upgrade to our
programmer that allowed us to program without
trashing too many parts (as long as we blasted them
with freeze spray during programming).

Pete

I remember hearing of that second and third hand. Nice to hear
someone actually there.

 

[Weng Tianxiang]

On Sep 11, 9:47 am, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

ehl...@isy.liu.se wrote:
1. Compile all source code files with +acc so that it is possible to
   add signals to the wave window.
2. Run simulation for 1 hour or until an error occurs.
3. If no error occured, save a checkpoint with a unique serial number,
   go back to step 2
4. At this point you can load up the latest checkpoint, add all
   relevant signals to your wave window (or signal log if you like the
   log-command) and rerun the simulation

The advantage of this approach is that you don't have to spend any
computation
time to log signal changes while retaining the ability to have full
visibility
when you are actually close to an error.

Look for the checkpoint command in the Modelsim documentation for more
info.

A simple do-script to run the simulation while a signal ("simulate" in my
case) is true, creating numbered checkpoints every 5 ms:

    # Quit simulation after assertion failure (avoids endless loop of just
    # writing checkpoints).
    #
    onbreak {quit -f}

    # Run the simulation as long as the simulate signal is set
    #
    set n 0
    while {[examine /tc/tb/simulate]} {
      incr n
      run 5 ms
      checkpoint chkpnt_$n
    }

If an error occurs, load the checkpoint that was created before the error,
enable tracing and continue simulation.

But please do test if a generated checkpoint can be loaded and the
simulation can continue from that checkpoint.

My experience is that either loading or continuing simulation does not work
on a unsupported platform like Fedora Core 6 or 8. On a platform that is
supported (like Redhat entreprise) it does work.

All I'm saying is: test if it works on your system before simulating for
days.

--
Paul Uiterlindenwww.aimvalley.nl
e-mail addres: remove the not.- Hide quoted text -

- Show quoted text -

Hi Paul,
Your method has a fatal problem: it doesn't guarantee the information
available has a guaranteed fixed length.
1. Assume your breakpoint time length is set at 5ms;
2. The error happens at 1.00501s.

From your breakpoint to the error postion there is only 100ns waveform
available.

In other words, your breakpoint method doesn't get information of a
guaranteed fixed length which is determined by the error position.

If you have two sets of breakpoint data saved at any time period, the
method will be OK.

Hans's method is OK, which gaurantees a fixed length of data available
at any time point.

Weng

 

[wzab]

A few months ago I've reported problems related to simulation of amforth
( http://amforth.sf.net ) in the VMLAB ( http://www.amctools.com/vmlab.htm)
details are described here:
http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1240766206
I have discovered that the problems are caused by the fact, that VMLAB
does not simulate correctly behaviour of the AVR when the flash memory
is reprogrammed but only with '1' changed to '0'.
The amforth uses "inteligent" algorithm, which erases the page only when
any '0' is changed to '1' otherwise the page is reprogrammed without
erasing, which causes, that VMLAB assumes that operation fails.

If anyone wants to simulate the amforth with the current version
of the VMLAB, it is necessary to switch off this mechanism (only for the
version used in simulation, do not do it in the version burned into the
real AVR):
The change has to done in file core/words/istore_nrww.asm
I have done it in the way which keeps the size and location of the code
unchanged (only the jump destination is modified).

The original amforth 3.5 code:
[code:1:444d662359]
; an erase cycle is only necessary
; when changing a bit from 0 to 1
.dw XT_OVER
.dw XT_OVER
.dw XT_IFETCH
.dw XT_INVERT
.dw XT_AND
.dw XT_DOCONDBRANCH
.dw PFA_ISTORE_WRITE
.dw XT_DUP
.dw XT_SPMERASE
PFA_ISTORE_WRITE:
.dw XT_DUP
.dw XT_SPMWRITE
.dw XT_SPMRWW
.dw XT_DROP
.dw XT_DROP
.dw XT_R_FROM
.dw XT_INTRESTORE
.dw XT_EXIT
[/code:1:444d662359]

The changed amforth code - simulates correctly (erase always):
[code:1:444d662359]
; an erase cycle is only necessary
; when changing a bit from 0 to 1
.dw XT_OVER
.dw XT_OVER
.dw XT_IFETCH
.dw XT_INVERT
.dw XT_AND
.dw XT_DOCONDBRANCH
; Jump to the next instruction - erase always
.dw PFA_ISTORE_ERASE
PFA_ISTORE_ERASE:
.dw XT_DUP
.dw XT_SPMERASE
PFA_ISTORE_WRITE:
.dw XT_DUP
.dw XT_SPMWRITE
.dw XT_SPMRWW
.dw XT_DROP
.dw XT_DROP
.dw XT_R_FROM
.dw XT_INTRESTORE
.dw XT_EXIT
[/code:1:444d662359]

--
HTH & Regards,
Wojtek

 

[wzab]

I'm sorry, this post should go to comp.arch.embedded, not
comp.arch.fpga.
Sorry for confusion.
--
Regards,
Wojtek

 

[rickman]

On Oct 15, 7:57 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

So far I have received no response to the email which I sent to
announceme...@Altera.com on October 12th, 2009. I am not pleased.

Colin Paul Gloster

Did you give them your email address? Is this spam or you just don't
like the fact that it is much harder for them to meet the regulations
of dozens of countries than it is to only make the offer in the single
country where most of their business comes from?

I don't like 95% of the advertising email I get. But I've asked for
99% of it and if I don't like it, I just unsubscribe from it. The
stuff I get where they got my email address from a spam list
encourages me to send an email asking them to get in touch with me.
Then I ask them how they got my address and let them know I'm not
happy with being spammed.

But if you are just complaining that you don't like the way they've
set up their offer, why waste your time with that thought... like why
am I wasting my time with *this* thought?

Rick

 

[Michael Schwingen]

On 2009-10-15, rickman <gnuarm@gmail.com> wrote:

Did you give them your email address? Is this spam or you just don't
like the fact that it is much harder for them to meet the regulations
of dozens of countries than it is to only make the offer in the single
country where most of their business comes from?

On a related note: is it possible Xilinx is giving out mail addresses to
other companies?

I use separate disposable mail addresses for each web registration, and I
just got spam from a Mentor Graphics user group, sent to the mail address
that I only used at xilinx.com. Guess I'll have to disable that account on
my mail server.

cu
Michael

 

[rickman]

On Oct 16, 3:14 am, Michael Schwingen
<news-1235297...@discworld.dascon.de> wrote:

On 2009-10-15, rickman <gnu...@gmail.com> wrote:

Did you give them your email address?  Is this spam or you just don't
like the fact that it is much harder for them to meet the regulations
of dozens of countries than it is to only make the offer in the single
country where most of their business comes from?

On a related note: is it possible Xilinx is giving out mail addresses to
other companies?

I use separate disposable mail addresses for each web registration, and I
just got spam from a Mentor Graphics user group, sent to the mail address
that I only used at xilinx.com. Guess I'll have to disable that account on
my mail server.

cu
Michael

I had that happen once or twice as well. I don't think they are
literally selling the list. I think it is more of a sales channel
thing. I believe the time it happened to me, I got spam from a rep
firm who handled Xilinx, but also tools. I think they took some
liberties with the usage of the list and sent tool advertisements to
everyone on the Xilinx list.

In your case, it would seem they pulled your address from their
forum. I know that Xilinx will pull email addresses from anywhere,
including support calls! I have a couple of email addresses that I
have given only to Xilinx support that they send advertising to.

Rick

 

[General Schvantzkoph]

On Sat, 24 Oct 2009 03:19:06 -0700, Sharath Raju wrote:

Hi,

This question isn't directly related to FPGAs, I felt people may be able
to help.

I am trying to generate PWM pulses of width 'W' in sync to a square wave
signal X . Please refer Fig1.http://brsharath.googlepages.com/
24102009.jpg

I tried to delay the signal X using logic gates and xored the delayed
signal with the original signal, to get pulses whose ON time equals the
sum of the propagation delay of the logic gates.

See Fig 2 http://brsharath.googlepages.com/24102009001.jpg

Though I am able to see the pulses on the oscilloscope, I see ringing at
the falling edge of the pulse.

What is the cause of ringing ?, and

Are there any alternative ways of generating PWM pulses.

You need to terminate the signal.

 

[KJ]

On Oct 24, 6:19 am, Sharath Raju <brshar...@gmail.com> wrote:

I tried to delay the signal X using logic gates and xored the delayed
signal with the original signal, to get pulses whose ON time equals
the sum of the propagation delay of the logic gates.

There are parts called delay lines that generate controlled delays of
specified amounts. Having a design depend on prop delays through
logic is a design that can be depending upon unspecified behavior.
Does the part you're using specify both a minimum and a maximum prop
delay? If not, how do you guarantee a minimum pulse width coming
out? Presumably you have a requirement for that.

See Fig 2http://brsharath.googlepages.com/24102009001.jpg

Though I am able to see the pulses on the oscilloscope, I see ringing
at the falling edge of the pulse.

What is the cause of ringing ?, and

The output impedance of the driver does not match the impedance of the
circuit board and the receiver. Add either a ~33 ohm resistor in
series with the output pin or tack on a ~50 ohm resistor to ground
across the output. Either method will get rid of most of your
ringing.

Kevin Jennings

 

[Sharath Raju]

On Oct 25, 12:45 am, KJ <kkjenni...@sbcglobal.net> wrote:

On Oct 24, 6:19 am, Sharath Raju <brshar...@gmail.com> wrote:

I tried to delay the signal X using logic gates and xored the delayed
signal with the original signal, to get pulses whose ON time equals
the sum of the propagation delay of the logic gates.

There are parts called delay lines that generate controlled delays of
specified amounts.
I wasn't aware of them. Thanks

 Having a design depend on prop delays through

logic is a design that can be depending upon unspecified behavior.
Does the part you're using specify both a minimum and a maximum prop
delay?  If not, how do you guarantee a minimum pulse width coming
out?  Presumably you have a requirement for that.

I had initially thought of using a 555 monostable multivibrator to
generate pulses of a specified width. The problem is that the
monostable ckt is only falling edge triggered. So I thought of making
a circuit (Fig2 http://brsharath.googlepages.com/24102009001.jpg) that
can recognize both rising and falling edges. and then use it to
trigger the 555.

So as such, I dont have a specific requirement for the width. The only
requirement is to detect both rising and falling edges.


Of course, using delay lines and xor logic, i think the 555 can be
avoided.

See Fig 2http://brsharath.googlepages.com/24102009001.jpg

Though I am able to see the pulses on the oscilloscope, I see ringing
at the falling edge of the pulse.

What is the cause of ringing ?, and

The output impedance of the driver does not match the impedance of the
circuit board and the receiver.  Add either a ~33 ohm resistor in
series with the output pin or tack on a ~50 ohm resistor to ground
across the output.  Either method will get rid of most of your
ringing.
shall try that and see.

Kevin Jennings
thanks

 

[-jg]

On Oct 24, 11:19 pm, Sharath Raju <brshar...@gmail.com> wrote:

Are there any alternative ways of generating PWM pulses.

There are many ways of generating PWM pulses.
It depends what is important to you.

The simplest, for both edges, is as you describe with a XOR gate +
delay element, which can be gates, or a RC, depending on the absolute
times involved. Universal Tiny Logic gates have XOR/XNOR choices,and
schmitt pins.

Then, issues of jitter, stability and matching come into play, and
they might push you into different solution directions.

As you have failed to give any numbers for any of these, advice is
impossible.
-jg

 

[Theo Markettos]

[Please note, followups set to news.groups]

The newsgroup comp.arch.hobbyist was created some years ago for the
discussion of recreational hardware design. The activity when it was
created was (for example) people wirewrapping their own microprocessor
boards at home, but the scope in the charter (below) is a bit broader than
that.

It was created as a moderated group because the community previously
inhabited alt.comp.hardware.homebuilt which was filled with off-topic posts
like 'How do I plug in SIMMs to my PC?'. That was probably a mistake, as
I'm not sure moderation was needed in comp.arch.*

Anyway, for some years the moderator has been AWOL and as a result the group
was been dead. So the Big 8 Management Board are currently seeing if
there's any interest in replacing the moderator, or whether the group should
be deleted.

Is there any interest in a newsgroup for non-commercial electronics/hardware
design? That might have a slightly different feel from, say,
comp.arch.embedded where the emphasis is on commercial development.
Hardware, software, FPGAs (and more) would be covered. It might not be a
particularly high-traffic group, as long as there are some people interested
in reading and posting.

If there's interest, the group is already carried by many news servers so
moderation just needs to be arranged - either on a simple automatic approval
system or, if manpower is available, with human moderators. I'm willing to
set this up if people think it's worthwhile. But I'm also happy for the
group to be deleted if no-one is interested.

So please followup to this posting (followup will go to news.groups not
comp.arch.* or sci.electronics.*) if you have an opinion.

Theo
(original proponent of comp.arch.hobbyist 1997-8)



Here's the official Moderator Vacancy Investigation posting (from
news.groups.proposals):

In news.announce.newgroups Alexander Bartolich <alexander.bartolich@gmx.at> wrote:

MODERATOR VACANCY INVESTIGATION (MVI)
moderated group comp.arch.hobbyist

This is a formal Moderator Vacancy Investigation (MVI), begun because
moderated newsgroup comp.arch.hobbyist is not functioning, and may have
been abandoned by its moderator(s).

This investigation will attempt to verify the reasons for non-function,
and may result in the removal of the group or the selection and instal-
lation of a new moderator. In practice, the Big-8 Management Board
considers the third alternative--changing the status of the group from
moderated to unmoderated--as likely to cause more harm than good.

NEWSGROUPS LINE:

comp.arch.hobbyist Homebrew digital electronics design. (Moderated)

DISTRIBUTION:

news.announce.newgroups
news.groups.proposals
comp.arch.hobbyist

PROPONENT:

Alexander Bartolich <alexander.bartolich@gmx.at

CHARTER OF COMP.ARCH.HOBBYIST

A moderated forum to exchange ideas, techniques, problems, solutions,
and other information concerning the hobby of electronics design and
construction, specifically related to digital machines and their
peripherals.

Commercial advertisements (except when non-repetitive and directly
relevant to the topic of the group) are expressly forbidden; it is up
to the moderation group to make individual exceptions.

Binary postings in this group are unwelcome. No postings containing
10K or more of binary content will be accepted. Postings containing
less than 10K of binary content should only be used where no other
reasonable method is available to convey the information they contain.
All postings containing binary content of more than 10 lines or 300
bytes, whichever is the smaller, shall be forwarded to the daily
moderators for inspection in the same manner as articles from unknown
authors.

Posters wishing to post binaries that do not fit the above criteria
should upload this data to an FTP or WWW site and instead post a
pointer to that site. The binary regulations do not apply to the
posting of ASCII schematics.

A 'bot moderator will be used, which will reject articles by authors
who have not read the posting guidelines. Articles rejected by the
'bot will be forwarded to a group of three daily moderators for
review. These daily moderators will be appointed by a moderation group
of at least eight and at most twelve members who will decide on
moderation policy in general and the workings of the 'bot in
particular. Moderation will follow the scheme outlined below:

The 'bot:

- auto-approves articles that match all of these:
- known author
OR keyword/phrase in article
OR reply to approved article to the same set of newsgroups
- article with less than 300 bytes or 10 lines of binary
content, whichever is the smaller
- plain text, without markup encoding
- mails notification of non-approval to original authors,
without an attempt to circumvent spamblocks
- notification message explains moderation system,
and points poster to relevant posting guidelines
- sends non-approved articles to the daily moderators
- uploads non-approved articles to a WWW site, and
regularly posts a pointer to them
- scans for forged approvals and cancels


The daily moderators:
- individually check articles the 'bot rejected;
- if at least one of the daily moderators think the
article is on-topic, it gets posted
- if it is reposted, the original author is notified

The moderation group:
- appoints the daily moderators
- deals with group abuse that's not caught by the 'bot
- it has the power to bar persistent abusers by
unanimous decision for a period of up to
30 days at a time
- deals with long-term moderation policy
- is obliged to post details of all moderation group
decisions to the newsgroup
- if a moderation group member does not express an opinion
on a matter, then their silence shall not be taken as
supporting either side of a decision

Moderators of news.announce.newgroups and successor groups are
allowed blanket crossposting at their discretion.

RATIONALE:

Probe posts to this group resulted in bounces.

comp-arch-hobbyist@moderators.isc.org>: host
moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address
(in reply to RCPT TO command)

HISTORY OF THE GROUP:

comp.arch.hobbyist is a moderated newsgroup which passed its vote for creation
by 199:15 as reported in news.announce.newgroups on 30 Jun 1998.

PROCEDURE:

Those who wish to comment on this moderator vacancy investigation should
subscribe to news.groups.proposals and participate in the relevant
threads in that newsgroup.

To this end, the followup header of this RFD has been set to
news.groups.proposals.

For more information on the MVI process, please see

http://www.big-8.org/dokuwiki/doku.php?id=policies:mvi

CHANGE HISTORY:

2009-10-29 Probe post bounced
2009-11-01 Moderator Vacancy Investigation

 

[whygee]

-jg wrote:

On Nov 26, 9:22 am, whygee <y...@yg.yg> wrote:
So... what's left ?
It's not clear exactly what you are asking ?
I'm asking for more ideas or methods

Epson, EM Microelectronic et al, have 32Khz osc
modules, that include the crystal.
all I have seen up to now at my usual sources

is the small crystals. Maybe I should dig more.
However, I'm looking at cheap lots of 50pc
from second hand/refurbishers etc.

Maxim have one that is TCXO as well, and
if precision matters, then you will need txco.
The precision that I need is crystal-like,

but I fear that if I do my own circuit,
I can't tune it to reach it.
Compensation capacitors, track parasites etc.
can spoil the circuit unnecessarily.
So a canned osc sounds best.

NXP PCF2129 is another candidate, but less stocked.
Never heard about this part...

I'll have to google it :-/

MicroCrystal.com also have a range.
hmmm yet another new name for me

<click>
wow, it looks expensive

Some tcxo's are fixes in time, not frequency, so
watch the details
I'll watch them but what do you mean exactly ?

thanks,

-jg
yg

--
http://ygdes.com / http://yasep.org

 

[whygee]

malcolm wrote:

If this is for motion control,
it's likely the 40ns jitter and 5ppm of
my earlier example is fine...
By "motion control" I mean something similar to

Microchip's AN964 : "Software PID Control of an Inverted Pendulum Using the PIC16F684 "
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en021807

So I think the jitter is not critical, but overall stability is desirable.
Commercial temperature range is OK.
But a cheap, long-term stable, pre-tuned oscillator for clocks/calendars
would have been good : it could keep track of time/date AND provide real-time signals

.. but in case it is not, if you are going to x4 the 25MHz anyway in a
PLL, then this can apply :
I've thought about this, since I target operation 100MHz in the digital domain.

1-((1*(3051/100e6)+3*(3052/100e6))/4)*32768
ans = 2.56e-6
That's a complex computation, the PLL's dividers

are too small for division by 3051...

ie from 100MHz, you get 2.56ppm, and 10ns jitter,
and any binary time under 32768/4, has no jitter
at all.

My last thought is that the 25MHz is not so critical.
I have other frequency requirements so other frequencies
are needed anyway. Power being proportional to frequency,
and serial communications (UART/RS232) are potential too,
I found that a 12.288MHz canned osc is a good compromise :
- 2x less toggles on the pins compared to 25MHz so (locally) lower draw
- I get 98.308MHz in the digital domain after 8x in the PLL
(it could even be dynamically changed from the PLL configuration register),
which is only 2% below the target (not a real loss).
- I get a stable 48KHz time base for sound (x256 for delta/sigma chips)
- and a good 32.768KHz base after division by 3*5*5*5.
- RS232 @ 38400 bps is OK, faster if some %err is possible
(a x3 in the PLL gets me to 230400bps)
- Some displays require 24.5454 in NTSC mode,
which is very close to 12.288*2=24.576MHz

For the 25MHz, I'll try to hook a pin of a nearby ENC28J60 module.
However it is risky (it will disturb the oscillator's stability
if i connect a wire to the crystal) and since I'm missing my digital
frequency target by only 2%, it's not a big issue.

Now, I'll have to find cheap lots of >50pc 5x7 oscillators from my usual
brokers. Too bad I have already found the 25MHz ones :-/
Yes, I try to cut costs in any reasonable way ;-)

regards,

-jg
jg != malcolm ?

yg

--
http://ygdes.com / http://yasep.org

 

[whygee]

Hi Rick !

rickman wrote:

I think you've covered all the bases given your apparently conflicting
requirements. Often engineering is a matter of determining an optimal
combination of all requirements, but sometimes it is a matter of
trading off one against the other so that neither is optimal, but both
are adequate.
Yeah, I remember reading a Usenet poster's signature along these lines

on comp.arch or something like that

So if you *must* use 25 MHz, then you need a 25 MHz
oscillator, not 24.576.
right.

I realised that the "stable" 25MHz is required by the 10BaseT interface,
which already has its own crystal.
For the rest, as written in my last post, the -%2 compromise
on digital speed is compensated by a better match in most other
interfaces so I won't complain. Well, except about availability
at very low prices ;-)

That means you have to provide another
clock. If using a 32.576 kHz oscillator is too power consuming,
at least if I do it myself, because I'm not sure to do it right.

I have no atomic clock at home to help calibrate the capacitors

how do you expect to get this second clock? I don't see how a clock chip
would be any better than a 32.576 kHz oscillator. The clock chip
still uses a crystal.
I first thought about using an integrated external clock/calendar

but I don't know one that outputs its internal Xtal's output :-/

Using a 12.288MHz as a main and single clock looks like the best idea yet
but availability is an issue. I mean : outside of the "usual suspects"'s
distribution prices. I'll have to go harrass the brokers again :-D

_o/

Rick
yg

--
http://ygdes.com / http://yasep.org

 

[-jg]

On Nov 26, 11:27 am, whygee <y...@yg.yg> wrote:

-jg wrote:

The precision that I need is crystal-like,
but I fear that if I do my own circuit,
I can't tune it to reach it.
Compensation capacitors, track parasites etc.
can spoil the circuit unnecessarily.
So a canned osc sounds best.

Digikey shows 69 items for Oscillator[32.768Khz]
and 41 for stocked.

Some tcxo's are fixes in time, not frequency, so
watch the details

I'll watch them but what do you mean exactly ?

The DS32Khz TCXO, is probably your best choice, if you don't want to
use the 25Mhz (or need more precision).
(or the NXP ones, have more modern Vcc ranges, but not as easy to
get..)

These trim via a Cap on the Crystal, so the fix is in the frequency
domain.

Some RTCs that trim, somewhat 'cheat' and vary the dividers, so that
the average time-of-day is corrected, but NOT the 32Khz frequency.
For their intended use that's fine.. but probably not for using
alongside a FPGA.

-jg