Could the CPU be reducing its clock rate when it's not being loaded?  Just
a guess, most multi-core processors these days have power saving features
like that.

eric

On Wed, Apr 4, 2012 at 3:22 PM, Mike S mikes@flatsurface.com wrote:

That is the AMD speed step, but doesn't intel do the same thing?

Incidentally, there are hacks for linux to make it more real time, i.e.
lower latency. I never messed with them, but you find this mentioned
related to multimedia oriented distributions.

On 4/4/2012 3:53 PM, Randall Prentice wrote:

The INTEL HRET (High Resolution blagh Timer) seemed to work whereas the AMD equivalent didn't seem to fix the problem.
Note: this was older AMD ATHLON processors,  they may have fixed this by now.

Regards
Randall
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of gary
Sent: Thursday, 5 April 2012 10:58 a.m.
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] NTP jitter with Linux

That is the AMD speed step, but doesn't intel do the same thing?

Incidentally, there are hacks for linux to make it more real time, i.e.
lower latency. I never messed with them, but you find this mentioned related to multimedia oriented distributions.

On 4/4/2012 3:53 PM, Randall Prentice wrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

On 4/4/2012 6:51 PM, Eric Williams wrote:

Setting /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor to
"performance" should lock that core to the max clock rate.

In looking that up, I found that the script I made to set this was just
doing cpu0 (i.e. one of four cores). Doh! I've changed it to do all 4
cores, and am trying that again to see if that's it.

El 05/04/2012 00:58, gary escribió:

I suppose so. In any case, under Linux you can force off the speed step
(i.e. force the CPU to a fixed clock). I did that some time ago in a
Dell server with a dual quad-core Opteron with Fedora Core 10... but
don't remember the procedure

Regards,

Javier

On 4 Apr, 2012, at 16:10 , Mike S wrote:

I don't know much about Linux but if that doesn't help try to find out what
the operating system does in its idle loop.  If it is ending up in some
power-saving state when it is idle it may be volunteering to do this by
executing some magic `wait' instruction which does the power-saving thing as
a side effect, and if you can find where it does this you might be able to
work around it.

Dennis Ferguson

There are a lot of problems here.  I'm not even sure where to start, but
here goes.  ;)

I suspect if you keep within the input period, ie, of 1pps you may not see
long term problems. All the pase shifting will average out to 1 in the long
run. 1 second is a lot of time for a PC to miss, but it could theoretically
happen. Consider a page out pr fault in combination with and idle cpu and
idle disk, or worse powered down disk.--that would be very expensive and
you may see a second or more with no signal, then all the signals show up
in a very tight window.

Back to the problem, breaking the 1pps down as far as 10micro seconds,The
most obviously problem is that you are trying to use an inaccurate clock
source(the pc) to sample a precise and accurate source. --A PC is not a
frequency standard so it can't be used for (2/f) ..(3/f) ..(n/f)
measurements. After if it could do this, we would see PC based high
precision and accuracy frequency standards.

One way to achieve your goal is to use a higher source frequency standard
to drive a  cacheless microcontroller(most like a low end 8bit model),
derive a precision timer from the high frequency source, log the 1pps
signal and apply a time stamp to each sample.  Pull those samples via
USB/Serial, whatever...  Though this all defeats the purpose of NTP doesn't
it?

I think the simple answer here is that PC architecture is not intended for
such precise, accurate measurements.

Steve

Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)...
I don't think you'll ever do it, or at least not in a way that can be peer
reviewed.

On Wed, Apr 4, 2012 at 6:22 PM, Mike S mikes@flatsurface.com wrote:

On 4/4/2012 10:41 PM, Steve . wrote:

Your reply ignores the simple fact that it does track within a couple
of microseconds, as long as the processor is busy. The PC is not the
clock source, a PPS signal derived from GPS is. A PC is perfectly
capable of 10 us accuracy. Even slower processors are capable of
significantly better accuracy - http://www.febo.com/pages/soekris/ .

???

Maybe your PC runs in MHz, but mine runs in GHz. Are you confusing us
with ns?

It doesn't matter how fast the CPU clock rate is because you are not
dealing with a simple rate monotonicity. There are far too many
inconstancies in a PC to properly apply simple O(n) algorithms.

microseconds, as long as the processor is busy. The PC is not the clock
source, a >PPS signal derived from GPS is. A PC is perfectly capable of 10
us accuracy. Even slower processors are capable of significantly better
accuracy

In this you are exposing a complex detail in the sampling conditions.
It is quite obvious that the experiment (The hardware,software, and
figures)
do not exhibit the precise control that you require. The more you focus,
the more problems you will find. Likewise, the mixed results you find
from one experiment to another, strengthens the argument for
lack of precision in the control. Whatever changes you make to increase
precision are not likely to apply to any one else.
Those who do not see a problem are simply not objective in regards to the
scientific method. Just cargo cult science.

Steve

On Wed, Apr 4, 2012 at 11:42 PM, Mike S mikes@flatsurface.com wrote:

I built a small form factor PC using the Intel D525.

If you look at the features (or lack thereof!), it lacks "turbo boost"
and "enhanced Intel Speed Step technology". So you may not have to
resort to using a uP if you don't want the PC clock to be a moving
target. I was a bit surprised that the Atoms (at least to that
generation) didn't play clock and core voltage games.

On Thu, Apr 5, 2012 at 12:17 AM, gary lists@lazygranch.com wrote:

If the architecture has cache or wait states, it is still subject to be a
moving target. I'm naturally skeptical on all architectures that have
multiple channels, show me an architecture with cache or waits states and
i'll show you a problem ( in regards to real time, that is)

I stand firm that the only proper way to do this is with a 100%
deterministic architecture.

Steve

On Wed, Apr 4, 2012 at 9:17 PM, gary lists@lazygranch.com wrote:

I did the same thing.  They work well and even if you have a "free"
quad core PC in a closet some place it is cost effective to toss the
thing in the trash and by a new computer with an Atom CPU.  The
reason is the price of electric power.  A large desktop PC, if you run
it 24x7 can add quite a bit to your utility bill.  After a year you
have paid for two Atoms  My Atom main board runs so cool there is no
cooling fan and it is still only just warm to the touch.  It is not
super fast but a 1.8GHz Atom is total overkill for running NTP

Get a flash drive, install the OS on that and run the little server
with no hard drive and no monitor, keyboard or mouse.

--

Chris Albertson
Redondo Beach, California

Yep. This is what I run 24 and 7 for a number of monitoring tasks. It
has an Intel SSD. Mobo was $140 at Fry's. SSD was a Fry's special too.
It has a Nvidia ion2 (it does home theater PC streaming at times.] USB
3. Gigabit ethernet. Ignore the comment about it not playing 720P. It
does 1080 no problem IF you are using hardware acceleration.

The D525 was the first 64 bit atom. It can use a full 4G of RAM. There
may be better Atoms out there now since I've built this.

This particular mobo is very picky on RAM. It is best to read the
feedback on Newegg, which was of more use than the Asus webpage. [I see
someone claims 8Gbytes..eh, I think the chipset limit is 4.] Using
SODIMMs is a drawback (more expensive than standard RAM).

"I did the same thing.  They work well and even if you have a "free"
quad core PC in a closet some place it is cost effective to toss the
thing in the trash and by a new computer with an Atom CPU."

On Wed, Apr 4, 2012 at 9:22 PM, Steve . iteration69@gmail.com wrote:

..only proper way to do what?  The goal is to discipline the internal
software clock to GPS.  A typical application is a database server
that is running a web e-comerse site so that transactions get time
tagged.  So you would run a web, file or database server on a
deterministic, no cache micro controller?

Of course it would be easier to discipline a clock inside a purpose
built computer but that does not server the gol of time tagging
transactions in the server room

Or to say in another way.  If the goal is to deep a small micro
processor's clock in sync with GPS you don't need anything as complex
as NTP.  What NTP does well is that it can use reference loves that
are connected by slow and un-reliable data connections ilk the
Internet.  It works well over less than perfect links

Chris Albertson
Redondo Beach, California

As a rule of thumb, any general purpose architecture will be less
effective at a specific task than a specially designed one. That applies
more and more to the "modern" way of solving tasks: software.
The PC is one of the classical examples of GPA, and as such it is best
to know its limitations, so as to not have exaggerated expectations.
The first limitation, in that specific case, is the way the PPS source
is connected to the system. LinuxPPS tries to optimize it.
The serial port is far from being a precision path, the "newer"
implementations being optimized for throughput (FIFOs) are even worse.
Any additional layer (USB especially) makes things just more and more worse.
As for linux itself, to increase predictability, any disturbing factor
should be minimized, if not eliminated. That would mean especially
laptop power consumption optimization gimmicks, which are useless in a
high performance server/workstation environment (eco, green, and the
other trendy marketingdroid buzzwords are lately more, and more abused
for a few percent power consumption reduction).
The suggested RTOS approach is workable, but it represents just another
example of tweaking a GPA to a specific task, which for a server is
usually not desired. The low latency patches are another example, used
usually for DAWs, but with the reverse side of increased processor loading.
First you must define what your goals, and necessities are, and then
optimize your system for the desired task - here linux is your friend,
with its almost unlimited tweaking options (no comparison to windumb.)
Also, don't use a dumbed down distro, and (learn to) patch/compile your
own special kernels (best stripped down of all useless ballast of a
"generic" one).

On 4/5/2012 1:22 AM, Mike S wrote:

Indeed, I'm looking forward to getting a few raspberry pis to play with. NTP is but one of the interesting time related projects possible with a $35(us) Linux platform. The system has a number of i/o pins directly exposed that will make interfacing interesting.

On a side note, speaking of deterministic systems, why has no one built a GPSDO with an FPGA yet? Or an NTP server? :)

Bob

On Apr 5, 2012, at 1:15, MailLists lists@medesign.ro wrote:

In the original message, Mike is trying to get the jitter better than 20e-6
on a pc. I don't believe this falls in the typical use of NTP category.
What i assume here is that the jitter is local to the machine sampling the
1pps signal. Otherwise this is moot.

Numerically... 1/(20e-6) = 50e3,  likewise with nyquist variance (50e3 x2)
= 10e3, or time domain that is 100khz wide. This tells us that the input of
the pc must be rate monotonic to 100khz. The only thing that i can think of
that comes close to this monotic bw is a 192khz sound card, i have to
assume these cards are rated in raw sampling rate and not nyquist, so
correcting we see (192khz /2) = 96khz bw. Pretty close to 100khz. Maybe
close enough when considering both sides of figure contain the correction
for twice the highest bw.  Assuming i did not fat finger a calculation, a
192khz sound card is another possible solution to the problem.

The sound card approach would permit conversion to the frequency domain and
i think it would be fun to apply fourier analysis to something like a 1pps
signal. Does anyone have any thoughts as to how stable an approach like
this would be?

Steve

Nice toy, but the question of the necessity of a fully fledged OS for
most tasks thrown at such a small system still remains (integrated
network connectivity is a plus).
NTP isn't capable to improve the precision of a system's clock, as it
works over a heterogeneous path, which is quite unpredictable (NTP being
specifically optimized to compensate for such effects). It can only
improve the long term accuracy, similarly to a GPSDO. If the internal
clock of the system to get synchronized isn't precise enough, NTP won't
help.
While FPGAs excel at high throughput/parallel processing, the GPSDO
process is mostly a quite slow one (with the notable exception of phase
comparison - for which a CPLD is more than enough), so they would be
overkill. A NTP server needs a network stack, and those are mostly
included in full OSs - there are some small uC ones, but it's debatable
if such a uC is capable of servicing more requests, and/or having a low
enough and predictable processing overhead.
There are a few implementations of linux systems in a FPGA, but a bigger
uC/SoC would be enough for such a task, costs being another factor -
that task would fit nicely a PI.

On 4/5/2012 8:36 AM, Gmail wrote:

[]

Mike, have you tried FreeBSD instead?  Does it show the same problems?

Cheers,
David

SatSignal software - quality software written to your requirements
Web:  http://www.satsignal.eu
Email:  david-taylor@blueyonder.co.uk

GPSDO with an FPGA yet? Or an NTP server? :)

Yes, I have: I have a GPSDO entirely on a 50Kgates FPGA (Spartan3 XC3S50)
without microprocessor. GPS is the iLotus M12M and OCXO is a Morion MV201,
the DAC is... well, not exactly the best choice but it is an AD5660 16bit
only, anyway it works.

On Thu, Apr 5, 2012 at 8:51 AM, David J Taylor <
david-taylor@blueyonder.co.uk> wrote:

On 4/5/2012 2:51 AM, David J Taylor wrote:

I have a couple of Soekris Net 4501s running FreeBSD and NTP. They don't
have much jitter, but they're a very different architecture. The machine
with the jitter is my home "do all" machine - router, firewall,
file/email/print/web/ntp server, etc.

It's certainly not critical to get rid of the jitter, it's a time-nuts
thing. It bothers me. I noticed that when my backup process ran, NTP
jitter dropped very significantly. I'm sure it's related in some way to
interrupt latency - the first thing the PPS driver does when a PPS
interrupt comes in is to save a nanotimestamp.

Dennis Ferguson mentioned the OS idle loop. So, I added "no-hlt" to the
kernel boot line. This did improve things quite a bit. All else the
same, it reduces jitter to the 3-4 us range - better than the 20 us
without, but not as good as the 1-2 when I simply load up the processor.

El 05/04/2012 12:20, Azelio Boriani escribió:

Oh, I've done that (an NTP server, not GPSO) in a Cyclone III FPGA. But
well... it has a Nios-II CPU and runs Linux, so I suppose it does not
count too much :). A pure FPGA (without CPU) NTP server would be very
fun, but I suppose that the development effort required would not worth
it, taking into account that implementing a true ntp in an embedded
linux is quite easy. I have recently put into work an application that
reads and writes UDP packets for a relatively high speed (280Mbps)
ethernet to ECSS-E-ST-50-01C TM transfer frames gateway. The Ethernet
part was quite easy to implement (the RAM-based FIFOs and flow and error
control were a bit more difficult, since you must have a continous
uninterrupted 280Mbps output, and the input is Ethernet - with extremely
variable latencies).

Regards,

Javier

An older laptop (Pentium M for instance) can be had for $80 or so any day of the week, won't take much space, is completely standalone (built-in keyboard and display, built-in battery backup) and sips power when idle, which it will be most of the time.

The only issue is that you might be tempted to run more things on it and affect NTP performance. But if you load it with BSD and use it just for that, it will be a dandy solution.

Didier KO4BB

Sent from my BlackBerry Wireless thingy while I do other things...

-----Original Message-----
From: gary lists@lazygranch.com
Sender: time-nuts-bounces@febo.com
Date: Wed, 04 Apr 2012 22:09:14
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] NTP jitter with Linux

Yep. This is what I run 24 and 7 for a number of monitoring tasks. It
has an Intel SSD. Mobo was $140 at Fry's. SSD was a Fry's special too.
It has a Nvidia ion2 (it does home theater PC streaming at times.] USB
3. Gigabit ethernet. Ignore the comment about it not playing 720P. It
does 1080 no problem IF you are using hardware acceleration.

The D525 was the first 64 bit atom. It can use a full 4G of RAM. There
may be better Atoms out there now since I've built this.

This particular mobo is very picky on RAM. It is best to read the
feedback on Newegg, which was of more use than the Asus webpage. [I see
someone claims 8Gbytes..eh, I think the chipset limit is 4.] Using
SODIMMs is a drawback (more expensive than standard RAM).

"I did the same thing.  They work well and even if you have a "free"
quad core PC in a closet some place it is cost effective to toss the
thing in the trash and by a new computer with an Atom CPU."

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Old doesn't necessarily mean it sips power. Power consumption is based
on "buckets of charge" shuffled through the chips. Older processes have
more capacitance, hence bigger buckets for the same amount of work.

Further, notebooks have all the power saving features that are causing
(potentially) problems in the first place.

On 4/5/2012 1:03 PM, shalimr9@gmail.com wrote:

On 5 Apr, 2012, at 13:03 , shalimr9@gmail.com wrote:

I'll take some issue with that.  The best clock source for software
running on a computer, particularly when the applications might be
expected to take a lot of time stamps, is one which (a) works, (b)
has reasonable precision, and (c) is as cheap as possible to sample.
On Intel processors the most precise and inexpensive-to-read counter
available (i.e. conditions (b) and (c)) is the TSC, so you want to
use this if at all possible.  The problem with using the TSC is that
it sometimes violates condition (a), that is the "works" part.  On
some older processors it does not necessarily increment at a constant
rate, and on boards with multiple CPUs there can be multiple TSCs with
different times, so in these cases you may have to use something else
which isn't as good as the TSC would be if it worked.

For some random computer whose clock you want to set this is all fine.
It should use a counter known to work, and if the TSC doesn't it should
just use something else.  For something you are buying to be a dedicated
NTP server, however, it is worth while adding "working TSC" very high
on the list of desirable attributes.  The problem with some older CPUs,
like the Pentium M, is they are of a vintage which did not guarantee the
TSC would increment at a constant rate, and a variable rate makes it useless
as a clock.  It is possible you could work around that at some cost (maybe
the "sips power when idle" part) but I'm of the opinion that life is too
short for that and it would be better to pick something with a known-to-work
TSC for this application.

The Atom processors aren't bad.

Dennis Ferguson

On Thu, Apr 5, 2012 at 1:03 PM,  shalimr9@gmail.com wrote:

I'm using one of these.  Uses even less power
http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-di510mo.html
Brand new they cost well under $100 (assuming you can provide a case
and power)

Whatever you use do make sure it has a "real" serial port not just
USB.  It is getting harder to find new equipment that has RS232.    So
if you use a notebook make sure it has rs232

Yes the notebook has a screen and keyboard but after you are set up
you don't need that.  I've used notebooks.

Chris Albertson
Redondo Beach, California

Azelio Boriani <azelio.boriani@...> writes:

I'd be interested in hearing more about this. For about the past year I've been
building an NTP server on an Arduino (ATMega2560 microcontroller, WizNet W5100
ethernet/TCP/IP offload engine, boring off-the-shelf 16MHz quartz crystal).
Nowadays it's nearing completion (meaning I've hit the limits of the accuracy I
can get with this setup) and I've been thinking about what I can do next to make
it better.

One option is keeping the AVR platform, but building a custom board instead of
using the Arduino, and disciplining an OCXO in proper GPSDO fashion instead of
the digital frequency synthesis that I'm doing now. This would be interesting
for the pure timekeeping aspect, although it wouldn't improve the accuracy of
the NTP server very much.

Another option would be building something on an FPGA. This would be a
considerable stretch for me, since I've never done FPGA work, but if I build
from the ground up, I can have very tight control over things that are chosen
for me with a microcontroller. I can timestamp Ethernet frames while they're
still coming in from the wire, and timestamp outgoing NTP packets at the last
possible moment; I can make delays pretty much as deterministic as I want; I can
control counter widths and divisors, and interrupt priorities, etc. It's really
fascinating and I think at some time I'd like to try it.

Andrew

On Fri, Apr 6, 2012 at 9:41 PM, Andrew Rodland andrew@cleverdomain.org wrote:

A compromise is to find a "soft core" for the FPGA.  This is a CPU
implemented in FPGA and then it runs software just like a "real" CPU.
This would let you move your micro controller based be sign over to
the FPGA quickly.  After that you can implement some specialized
peripherals that do time stamping

How does the performance of the Arduino based NTP compare with what
you could do with Linux on (say) and Atom or ARM processor?

Chris Albertson
Redondo Beach, California

The Xilinx and Altera have their embedded CPUs (Microblaze and Nios) IP.
I'm not familiar with them and don't know how much they cost. Until now I
have developed on Xilinx 50Kgates FPGA and 128 cells CPLD with the Xilinx's
free tools.

On Sat, Apr 7, 2012 at 7:53 AM, Chris Albertson
albertson.chris@gmail.comwrote:

El 07/04/2012 13:19, Azelio Boriani escribió:

Mostly expensive for amateur use, although reduced free versions exists
(for Nios-II it is Nios-II/e without MMU and no cache, I suppose that
something similar for Microblaze). But both are closed-source.

There are open-source soft processors like LatticeMico32 and LEON3. I'm
moving to one of these for a next project (not yet decided which one,
since in this case it will be a bare-metal application, with no
operating system, but I would like to use a processor that is supported
by Linux distribution for the future). Linux is ported to both, and for
LM32 (not sure if for LEON3), RTEMS also (see www.milkymist.org , an
open source hardware and software project with an LM32 implementation on
a Spartan 6 FPGA using RTEMS. Also there is a plethora of soft
implementation of several processors in OpenCores (ranging from 6502 to
OpenRISC) and also somewhere I read about an implementation of a Cray-1
in a Spartan-3 :)

Regards,

Javier

The Cray-1 implementation is here http://chrisfenton.com/homebrew-cray-1a/

On Sat, Apr 7, 2012 at 1:47 PM, Javier Herrero jherrero@hvsistemas.eswrote:

On Sat, 07 Apr 2012 13:19:14 +0200, Azelio Boriani wrote:

Maybe ZPU
http://opensource.zylin.com/zpuref.html
http://opencores.org/project,zpu

http://embdev.net/articles/
ZPU:_Softcore_implementation_on_a_Spartan-3_FPGA

/Cfo

On 4/7/12 4:47 AM, Javier Herrero wrote:

I'm very familiar with the LEON and RTEMS, having managed a software
development project with it for the last 3 or 4 years at work.

http://www.gaisler.com/ for LEON
http://www.rtems.org/ for RTEMS

And yes, there is a port (maybe two) of Linux for the LEON as well (A
few years ago, we loaded up the Snapgear port, but since we went RTEMS,
I haven't fooled with it).  You'd have to check the Gaisler.com website.

You can drop a LEON core into a Virtex II in about a day, and judging
from the traffic on the LEON yahoo list (where the Gaisler folks hang
out), lots of people are doing things like multiple cores and things on
all manner of Xilinx eval boards.

Gaisler's GPL library of assorted cores (pretty much all using AMBA)
make life pretty easy from a hardware interface standpoint.  Their basi
strategy is that source and documentation is free, but that if you want
the fault tolerant versions, or the versions intended for spaceflight,
or the testbenches for the cores, you have to go with a license ( a few
thousand bucks per core, depending on what it is).

Gaisler's basic business model (hopefully I'm summarizing correctly..)
is that they do custom FPGA/ASIC designs for people, putting together
pieces of their library, possibly adding new modules, targeted to
platforms like the Actel AX2000 (or Xilinx, or FPGA->ASIC).  SO you have
products like the Atmel AT697  (A LEON-FT with memory controllers and
peripherals) which we use in JPL's space radios) or the Aeroflex UT699
(another LEON core with various peripherals).

RTEMS wise... It's pretty well supported by the community, it's open
source, it does all the stuff you want a RTOS to do.  it's NOT a
multitasking, dynamic loading OS like Linux.  That is it doesn't support
an MMU and process space isolation (although that might be possible in
newer versions.. there's a lot of configurability).  It's basically a
statically linked single task with threads.  They've got RAM (and disk)
file systems, IP stacks, a shell, YAFFS, etc.

Like all open source, there's quite a lot of interesting stuff available
(not from rtems.org, but others) that is 90% complete.  Somebody at
Google Summer of Code or for their Masters decides to implement
something cool, and gets most of the way done, then wanders away (the
summer ended, they got their degree, the usual story).

But there's also a core of users who are serious and rigorous and
contribute back, so the main stuff in the distribution from Joel
Sherrill at OAR (who make RTEMS) is pretty rock solid.

ESA has several rigorously verified flight qualified versions of RTEMS
(in Portugal and Austria, as I recall)

OK, taken a look: it seems that the smallest Spartan3 usable is the
400Kgates. I don't need the ZPU now but good to know.

On Sat, Apr 7, 2012 at 3:35 PM, cfo xnews3@luna.dyndns.dk wrote:

If you are looking for free soft core CPUs for use in an FPGA then look here:
http://opencores.org/projects
Look under "processors" for many CPU cores.  They also have some
Eithernet controllers you'd need.

On Sat, Apr 7, 2012 at 6:35 AM, cfo xnews3@luna.dyndns.dk wrote:

--

Chris Albertson
Redondo Beach, California

On Sat, Apr 7, 2012 at 1:47 PM, Javier Herrero jherrero@hvsistemas.es wrote:

We use the LM32 (http://www.ohwr.org/projects/lm32) in the White
Rabbit and other projects. Here's a LibreOffice presentation on why it
was chosen: http://www.ohwr.org/attachments/download/559 It's smaller
than the LEON3 and more capable than the ZPU. We found it to be a good
compromise. The guys in GSI (a German Physics lab) developed a good
debugging tool for it (http://www.ohwr.org/projects/phase). Our PTP
stack (http://www.ohwr.org/projects/ppsi/wiki) will soon run on it.

Cheers,

Javier

When you install the Altera tools, it automatically installs NIOS and gcc. I assume there are no restrictions for private use, but you may have to send $ if you make a commercial product. That remains to be checked.

I have not used NIOS either.
Didier KO4BB

Sent from my BlackBerry Wireless thingy while I do other things...

-----Original Message-----
From: Azelio Boriani azelio.boriani@screen.it
Sender: time-nuts-bounces@febo.com
Date: Sat, 7 Apr 2012 13:19:14
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] FPGA GPSDO (Was: Re: NTP jitter with Linux)

The Xilinx and Altera have their embedded CPUs (Microblaze and Nios) IP.
I'm not familiar with them and don't know how much they cost. Until now I
have developed on Xilinx 50Kgates FPGA and 128 cells CPLD with the Xilinx's
free tools.

On Sat, Apr 7, 2012 at 7:53 AM, Chris Albertson
albertson.chris@gmail.comwrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

El 07/04/2012 18:17, shalimr9@gmail.com escribió:

With the Quartus Web, you can use any Nios but in time limited form (1
hour or so) or as long as the debug cable is tied to the PC. The only
Nios free for use (commercial or private) is the Nios-II/e version. The
only NIOS really useful, NIOS-II/f (with MMU, caches, and faster) is
commercial, and the license pack inclding the triple speed ethernet core
is $995. Also other IPs are commercial (like memory controllers, etc.)

Regards,

Javier

El 07/04/2012 16:02, Jim Lux escribió:

I will have a look to RTEMS

I've done. The Snapgear port is quite old now, but the other port is
actively maintained and updated with current kernel.

And also for Altera (for example, the Terasic DE2-115 with a Cyclone IV)
and others. I've seen you int that list :) An I've seen implementations
for smaller FPGAs like the Spatarn 6LX25

I will learn more about RTEMS. For the application I've (and this links
directly to the message from Javier Serrano), the hardware platform is
one of the CERN Open Hardware ones, the SPEC. For the purpose and
interface needs, really an operating system is not required (no
filesystem, no TCP/IP needed, no multitasking, no framebuffer...), and
certainly a Linux would have a very large footprint without providing
any real help. And about the processor selection, the trade-off that
Javier exposes are the same I'm confronting. Both are open-sourced and
well supported, and in one side the LM32 is smaller, in the other the
LEON3 has more capabilities that can be implemented or not (like MMU or
FPU, and better multi-core support, although not currently needed in my
project). I probably will take the LEON3 road, but also because it is
more popular in my current field, but for now I usually do not need the
FT version since I'm more related with GSEs.

Yes, this is one of the reasons to gain experience in that road :) I
have some tendency to stay in Linux because I'm very familiarized with
it in the non-MMU implementations (for Blackfin) and also with MMU - and
I've found that for a small embedded system, to have the MMU is not so
important, even sometimes it is a drawback.

In any case we are running a bit OT (except considering that this
general discussion has timing applications, of course ;) ). Also I'm
happy to have found a time-nut colleage in other list, and probably I
will ask you some things about off-list in order to not increase noise,
if possible.

Best regards,

Javier

Chris Albertson <albertson.chris@...> writes:

chosen

Pretty well, I think. A PPS generated by my board shows an RMS absolute jitter
of 174ns compared to a Spectracom 9183, which is almost impossibly good
considering that all the timing is done off of a 2MHz clock.

As measured from the NTP side, the performance is diluted a lot by the fact that
the W5100 ethernet chip has unknown and unpredictable delays, but it still comes
back with a jitter of <20us (possibly better — the box I'm using to measure the
NTP is a Linux machine that isn't really a timing champ. Wish I still had my
net4801.)

Andrew

On 4/7/12 10:08 AM, Javier Herrero wrote:

RTEMS might be just what you need.  Kernel, basic OS calls for
scheduling, queues, etc. It's nice when you decide you want threading to
not have to graft it into a "big loop no-OS" style program.

You can use native calls or POSIX style (I like POSIX, because I can
develop on Linux and just recompile for the RTEMS target).

There's all the usual GDB support as well.

And about the processor selection, the trade-off that

And that's good because the FT version costs money, but the regular old
LEON2 and LEON3 are free, and pretty bulletproof by now.

Device drivers are easy to write for RTEMS, and it has VERY fast ISRs.
That's probably one of the big advantages..

It's a small footprint, stripped down RTOS, but because you can work
with POSIX API calls, you can do most of your development in Linux
(particuarly things like calibration interfaces and computational stuff)
and then it ports very easily when you move it to RTEMS on the target.

On 4/7/12 8:57 AM, Chris Albertson wrote:

Like all things opencores/sourceforge/etc  you need to examine whats out
there...

We've used a SDRAM controller from opencores (and modified it for our
puproses) and it works pretty well.  Some other stuff, maybe not so
finished and ready for use.

It all depends on provenance....

To blow our horn a bit, we've got some useful building blocks available
for free.. We are targeting Xilinx Virtex II, but they're designed to be
pretty generic Verilog for any target.

If you need a 64 bit timer core with a bunch of latches and a
programmable pulse generator, let me know.  We've got one at JPL we're
happy to distribute (for free).

Goddard Space FLight Center has a variety of SpaceWire cores (in VHDL),
and we've got a Verilog wrapper for it at JPL.

Simple cores to do things like record samples from an ADC into a giant
SDRAM buffer or play back samples from SDRAM into a DAC, we've also got.
You want that digital oscilloscope or ARB with a 10s of MegaSample
buffer.. we've got it.

Gaisler has a lot of useful, well debugged, cores for free.. Ethernet,
RAM controlkers, various other peripherals.

El 08/04/2012 00:21, Jim Lux escribió:

Yes, it is starting to seem that would fit my needs for this project
very nicely.

I would say that one of the most important for me. Sometimes I've dealed
with Xenomai/Adeos and uClinux when Linux latencies and worse, latency
uncertainities, but things then start to be a bit complicated...

Looks very good for several of my usual applications, where bare metal
sometimes requires too much work, and Linux requires too much footprint
:) Also, to support POSIX style is a great advantage.

I've had a quick look around www.rtems.org, and I see that it is also
ported to Blackfin, so it will also fit my usual ADSP-BF532 based
platform. I hope that the learning curve will not be too steep :)

Thanks for the info. Best regards,

Javier

Hi, Jim,

I will ask off-list to reduce noise... :)

El 08/04/2012 00:29, Jim Lux escribió:

I take good note. This is the kind of things that comes handy from time
to time :)

GSF SpW cores are available for free? Or are even available for non-US?
One of the things that I plan to do sometime is an SpW implementation,
mainly for instrument EGSEs - probably will try in the near future if
one of my customers wins a project and contracts us the EGSE. We are
currently using SpW cards from Dynamic Engineering, but sincerely I'm
not too happy with their support. For internal use, we have a Star
Dundee SpW USB brick, but I find that SpW boards from Star Dundee are
expensive and only with 3 ports - and we usually need 4 (you know,
nominal and redundant I/Fs to both nominal and redundant instruments :) ).

There are some "free" SpW ESA cores. The fun part is that they are free
except for a 5000 EUR management fee...

Best regards,

Javier

--

Javier Herrero
Chief Technology Officer                  EMAIL: jherrero@hvsistemas.com
HV Sistemas S.L.                          PHONE:        +34 949 336 806
Los Charcones, 17                        FAX:          +34 949 336 792
19170 El Casar - Guadalajara - Spain      WEB: http://www.hvsistemas.com