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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 139375

Article: 139375
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: rickman <gnuarm@gmail.com>
Date: Fri, 27 Mar 2009 16:03:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 1:25=A0pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Fri, 27 Mar 2009 08:19:43 -0700 (PDT), John <sampson...@gmail.com>
> wrote:
>
>
>
> >On Mar 27, 11:04=A0am, rickman <gnu...@gmail.com> wrote:
> >> I'm sure I'm not the first person to control an oscillator by the
> >> amount of data in a FIFO, but I haven't found a reference to this
> >> design which is similar to a PLL.
>
> >> In place of a typical phase detector, I am using the count of samples
> >> in the FIFO to control the DCO which drives the output clock. =A0Data =
is
> >> clocked into the FIFO using the reference (input) clock. =A0I have an
> >> integrator between the data count and the DCO phase step input. =A0The
> >> data count is also offset so that it is zero when at the set point.
>
> >> I am having trouble understanding how to model this design. =A0Is ther=
e
> >> a unique name for this sort of circuit? =A0At first I was thinking it
> >> was a frequency locked loop (FLL), but then I realized that the data
> >> count works the same as a phase detector by integrating the difference
> >> in frequency of the two signals, it just has a granularity of 1 cycle
> >> and does not wrap around like typical phase detectors do. =A0So should=
 I
> >> be using the same model for this as I would use for a conventional PLL
> >> using a standard phase detector?
>
> >> I am having trouble getting the circuit to lock in quickly without
> >> overshoot and hold lock as the frequency shifts. =A0I believe I need t=
o
> >> add a proportional element to the feedback loop. =A0I am also
> >> considering using different coefficients when the loop is locked and
> >> when not locked.
>
> >> Am I making this hard and it just needs to be treated like any other
> >> PLL?
>
> >> Rick
>
> >I call it a "rate-locked loop", but I'm not sure there is an official
> >name. Other keywords include "elastic store" or "elastic buffer".
>
> >You can write loop equations and get response curves. If the buffer
> >length is B, the error is (x - B/2)/(B/2) where x is how much is in
> >the buffer. The feedback is through a standard lead-lag filter, the
> >output of which controls the buffer's empty rate.
>
> >John
>
> Also sometimes called a "delay-locked loop".

I am pretty sure that this is not a delay locked loop.  A DLL uses a
delay in the feedback path to generate an output that has a different
phase than the original.  This is often used to compensate for a delay
elsewhere in the clock path.

In one incarnation of the design of this circuit the error integrator
was enabled by the input clock enable.  If there was a phase shift in
the input and output clock enables, it would produce a single count of
difference during part of the cycle, but would be zero again by the
next input clock enable.  However, with the phase accumulator (DCO)
operating on each cycle of the main clock, this single count would be
added in producing what amounted to a fractional phase step compared
to the value in the error integrator.  The result is that the smallest
adjustments in output frequency would be made by the phasing of the
input and output signals.  However, the phase would never be corrected
in the error integrator.

This is a bit hard to describe in words.  I hope it is clear.

Rick

Article: 139376
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: rickman <gnuarm@gmail.com>
Date: Fri, 27 Mar 2009 16:10:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 12:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> On Fri, 27 Mar 2009 08:04:43 -0700 (PDT)
>
>
>
> rickman <gnu...@gmail.com> wrote:
> > I'm sure I'm not the first person to control an oscillator by the
> > amount of data in a FIFO, but I haven't found a reference to this
> > design which is similar to a PLL.
>
> > In place of a typical phase detector, I am using the count of samples
> > in the FIFO to control the DCO which drives the output clock. =A0Data i=
s
> > clocked into the FIFO using the reference (input) clock. =A0I have an
> > integrator between the data count and the DCO phase step input. =A0The
> > data count is also offset so that it is zero when at the set point.
>
> > I am having trouble understanding how to model this design. =A0Is there
> > a unique name for this sort of circuit? =A0At first I was thinking it
> > was a frequency locked loop (FLL), but then I realized that the data
> > count works the same as a phase detector by integrating the difference
> > in frequency of the two signals, it just has a granularity of 1 cycle
> > and does not wrap around like typical phase detectors do. =A0So should =
I
> > be using the same model for this as I would use for a conventional PLL
> > using a standard phase detector?
>
> > I am having trouble getting the circuit to lock in quickly without
> > overshoot and hold lock as the frequency shifts. =A0I believe I need to
> > add a proportional element to the feedback loop. =A0I am also
> > considering using different coefficients when the loop is locked and
> > when not locked.
>
> > Am I making this hard and it just needs to be treated like any other
> > PLL?
>
> > Rick
>
> Sure sounds like it's just a phase detector. =A0That said, unless every
> clock of the input clock is putting a sample into the FIFO you start
> giving away gain pretty rapidly. =A0In a digital feedback loop,
> gain=3Dbits=3Dability to treat things as mathematically perfect rather th=
an
> mucking around in non-linear quantization effects.

I'm not sure I understand this.  Every clock of the input *does* put a
value into the FIFO.  Every clock of the output removes a sample from
the FIFO.

One thing that is confusing me is that I want to update the error
integrator only on the input clock enable, but the output clock phase
accumulator operates on every cycle of the main clock.  So a single
count in the error value produces multiple counts of offset in the
phase of the output.  This seems to make the output rate never
stabilize completely.  I suspect that I need to provide proper low
pass filtering which I don't currently use.

Rick

Article: 139377
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: John <sampson164@gmail.com>
Date: Fri, 27 Mar 2009 16:29:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 7:10=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 27, 12:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
>
>
>
> > On Fri, 27 Mar 2009 08:04:43 -0700 (PDT)
>
> > rickman <gnu...@gmail.com> wrote:
> > > I'm sure I'm not the first person to control an oscillator by the
> > > amount of data in a FIFO, but I haven't found a reference to this
> > > design which is similar to a PLL.
>
> > > In place of a typical phase detector, I am using the count of samples
> > > in the FIFO to control the DCO which drives the output clock. =A0Data=
 is
> > > clocked into the FIFO using the reference (input) clock. =A0I have an
> > > integrator between the data count and the DCO phase step input. =A0Th=
e
> > > data count is also offset so that it is zero when at the set point.
>
> > > I am having trouble understanding how to model this design. =A0Is the=
re
> > > a unique name for this sort of circuit? =A0At first I was thinking it
> > > was a frequency locked loop (FLL), but then I realized that the data
> > > count works the same as a phase detector by integrating the differenc=
e
> > > in frequency of the two signals, it just has a granularity of 1 cycle
> > > and does not wrap around like typical phase detectors do. =A0So shoul=
d I
> > > be using the same model for this as I would use for a conventional PL=
L
> > > using a standard phase detector?
>
> > > I am having trouble getting the circuit to lock in quickly without
> > > overshoot and hold lock as the frequency shifts. =A0I believe I need =
to
> > > add a proportional element to the feedback loop. =A0I am also
> > > considering using different coefficients when the loop is locked and
> > > when not locked.
>
> > > Am I making this hard and it just needs to be treated like any other
> > > PLL?
>
> > > Rick
>
> > Sure sounds like it's just a phase detector. =A0That said, unless every
> > clock of the input clock is putting a sample into the FIFO you start
> > giving away gain pretty rapidly. =A0In a digital feedback loop,
> > gain=3Dbits=3Dability to treat things as mathematically perfect rather =
than
> > mucking around in non-linear quantization effects.
>
> I'm not sure I understand this. =A0Every clock of the input *does* put a
> value into the FIFO. =A0Every clock of the output removes a sample from
> the FIFO.
>
> One thing that is confusing me is that I want to update the error
> integrator only on the input clock enable, but the output clock phase
> accumulator operates on every cycle of the main clock. =A0So a single
> count in the error value produces multiple counts of offset in the
> phase of the output. =A0This seems to make the output rate never
> stabilize completely. =A0I suspect that I need to provide proper low
> pass filtering which I don't currently use.
>
> Rick

Here's a simulation in Matlab that shows output rate adaptation to
keep buffer half full.

John

nco_fill=3D1;
nco_empty=3D1;
% write rate is 1/3
phinc_fill=3D1/3;
% read rate offset from write rate by 'ppm'
ppm=3D100;
phinc_empty=3Dphinc_fill*(1+ppm/1e6);
pherr=3D0;
Ki=3D1/1000;
Kp=3D1/10;
acc=3D0;

N=3D1e5;
backlog=3D0;
bv =3D zeros(N,1);sv=3Dbv;nf=3Dbv;ne=3Dbv;ev=3Dbv;
% buffer size is B
B=3D1000;
state=3D0;
for k =3D 1:N
    if(nco_fill-phinc_fill<=3D0)
        % write a sample into buffer when fill nco wraps
        backlog =3D backlog + 1;
        nco_fill =3D 1-abs(nco_fill-phinc_fill);
    else
        nco_fill=3Dnco_fill-phinc_fill;
    end
    if(state =3D=3D 0)
        % state 0: waiting for half full condition
        if(backlog > B/2)
            state =3D 1;
        end
    elseif(state =3D=3D 1)
        % state 1: emptying
        nco_empty=3Dnco_empty-phinc_empty-pherr;
        if(nco_empty<=3D0)
            % read a sample from buffer when empty nco wraps
            backlog =3D backlog-1;
            nco_empty=3D1-abs(nco_empty-phinc_empty-pherr);
        end
        % compute error and apply to PI filter
        e =3D (backlog-B/2)/(B/2);
        acc =3D Kp*e + acc;
        lag =3D Ki*acc;
        lead =3D Kp*e;
        pherr =3D lag + lead;
    end
    bv(k) =3D backlog;
end
plot(bv);grid;shg;title('Backlog');

Article: 139378
Subject: What does Xilinx mean by "Real 6-input look-up (LUT) technology"?
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Fri, 27 Mar 2009 18:16:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
For some time I've found it pretty humorous that Xilinx boast of "True
LUT6" in all their Virtex 5+ marketing material. Do they really think
that they can somehow imply that Altera's ALM isn't a "True LUT6" when
in fact it's obvious that the ALM encompasses a LUT6 and much more.

Or are there some unreal LUT6 out there?

Tommy

Article: 139379
Subject: Re: best soft core(s) that have C compiler support
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Fri, 27 Mar 2009 18:19:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 3:25=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> and i was considering MIPS if allowing more resource hungry
> implementations

Hey Antti,

I would be delighted if you would help lower the resource requirement
of YARI to suit your needs :-) I sure would learn a lot in the
process.

Tommy

Article: 139380
Subject: Re: What does Xilinx mean by "Real 6-input look-up (LUT) technology"?
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 28 Mar 2009 01:28:31 -0000
Links: << >>  << T >>  << A >>

"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:ca64ba48-4e07-42eb-b0c2-28d6ce8def81@d19g2000prh.googlegroups.com...
> For some time I've found it pretty humorous that Xilinx boast of "True
> LUT6" in all their Virtex 5+ marketing material. Do they really think
> that they can somehow imply that Altera's ALM isn't a "True LUT6" when
> in fact it's obvious that the ALM encompasses a LUT6 and much more.
>
> Or are there some unreal LUT6 out there?
>
> Tommy

Ooh!  Ooh! , Tommy!
Thank the Lord you posted. We would never have grasped that corporations do 
marketing! Do NVidia do crappy advertising also?
Lots of love, Syms. 



Article: 139381
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: Eric Jacobsen <eric.jacobsen@ieee.org>
Date: Fri, 27 Mar 2009 19:34:50 -0700
Links: << >>  << T >>  << A >>
On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>On Mar 27, 1:25pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>> On Fri, 27 Mar 2009 08:19:43 -0700 (PDT), John <sampson...@gmail.com>
>> wrote:
>>
>>
>>
>> >On Mar 27, 11:04am, rickman <gnu...@gmail.com> wrote:
>> >> I'm sure I'm not the first person to control an oscillator by the
>> >> amount of data in a FIFO, but I haven't found a reference to this
>> >> design which is similar to a PLL.
>>
>> >> In place of a typical phase detector, I am using the count of samples
>> >> in the FIFO to control the DCO which drives the output clock. Data is
>> >> clocked into the FIFO using the reference (input) clock. I have an
>> >> integrator between the data count and the DCO phase step input. The
>> >> data count is also offset so that it is zero when at the set point.
>>
>> >> I am having trouble understanding how to model this design. Is there
>> >> a unique name for this sort of circuit? At first I was thinking it
>> >> was a frequency locked loop (FLL), but then I realized that the data
>> >> count works the same as a phase detector by integrating the difference
>> >> in frequency of the two signals, it just has a granularity of 1 cycle
>> >> and does not wrap around like typical phase detectors do. So should I
>> >> be using the same model for this as I would use for a conventional PLL
>> >> using a standard phase detector?
>>
>> >> I am having trouble getting the circuit to lock in quickly without
>> >> overshoot and hold lock as the frequency shifts. I believe I need to
>> >> add a proportional element to the feedback loop. I am also
>> >> considering using different coefficients when the loop is locked and
>> >> when not locked.
>>
>> >> Am I making this hard and it just needs to be treated like any other
>> >> PLL?
>>
>> >> Rick
>>
>> >I call it a "rate-locked loop", but I'm not sure there is an official
>> >name. Other keywords include "elastic store" or "elastic buffer".
>>
>> >You can write loop equations and get response curves. If the buffer
>> >length is B, the error is (x - B/2)/(B/2) where x is how much is in
>> >the buffer. The feedback is through a standard lead-lag filter, the
>> >output of which controls the buffer's empty rate.
>>
>> >John
>>
>> Also sometimes called a "delay-locked loop".
>
>I am pretty sure that this is not a delay locked loop.  A DLL uses a
>delay in the feedback path to generate an output that has a different
>phase than the original.  This is often used to compensate for a delay
>elsewhere in the clock path.
>
>In one incarnation of the design of this circuit the error integrator
>was enabled by the input clock enable.  If there was a phase shift in
>the input and output clock enables, it would produce a single count of
>difference during part of the cycle, but would be zero again by the
>next input clock enable.  However, with the phase accumulator (DCO)
>operating on each cycle of the main clock, this single count would be
>added in producing what amounted to a fractional phase step compared
>to the value in the error integrator.  The result is that the smallest
>adjustments in output frequency would be made by the phasing of the
>input and output signals.  However, the phase would never be corrected
>in the error integrator.
>
>This is a bit hard to describe in words.  I hope it is clear.
>
>Rick

That's also a DLL, and perhaps the more commonly-used meaning of the
term in my experience.

This FIFO thing is also pretty common but doesn't seem to have a
universal name.   As John mentioned, they've been referred to as RLLs,
"Elastic buffer", and I've heard DLL when the purpose was to match the
delay to some other output to which the stream needs to be
synchronized.  In the satellite world there's also "plesiochronous
buffer" (one of my fave names for this).

I guess since the jobs that it does can different a universal name is
impractical.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php

Article: 139382
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 27 Mar 2009 21:35:53 -0500
Links: << >>  << T >>  << A >>
On Fri, 27 Mar 2009 08:04:43 -0700, rickman wrote:

> I'm sure I'm not the first person to control an oscillator by the amount
> of data in a FIFO, but I haven't found a reference to this design which
> is similar to a PLL.
> 
> In place of a typical phase detector, I am using the count of samples in
> the FIFO to control the DCO which drives the output clock.  Data is
> clocked into the FIFO using the reference (input) clock.  I have an
> integrator between the data count and the DCO phase step input.  The
> data count is also offset so that it is zero when at the set point.
> 
> I am having trouble understanding how to model this design.  Is there a
> unique name for this sort of circuit? 

I don't believe so, but I'm not good with names.

> At first I was thinking it was a
> frequency locked loop (FLL), but then I realized that the data count
> works the same as a phase detector by integrating the difference in
> frequency of the two signals, it just has a granularity of 1 cycle and
> does not wrap around like typical phase detectors do.  So should I be
> using the same model for this as I would use for a conventional PLL
> using a standard phase detector?

Yes and no.  It doesn't wrap, but it does quantize.  So you still need to 
model the offset accumulation process as an integration, but you don't 
need to model the phase accumulator rollover, and you do need to model 
quantization one way or another.

> I am having trouble getting the circuit to lock in quickly without
> overshoot and hold lock as the frequency shifts.  I believe I need to
> add a proportional element to the feedback loop. 

You sure do!  How well does a double integrator loop with no damping 
settle, after all?

> I am also considering
> using different coefficients when the loop is locked and when not
> locked.

That may be wise.

> Am I making this hard and it just needs to be treated like any other
> PLL?
> 
> Rick

I think you're overanalyzing some simple things, and overlooking some 
complexities.  You should be able to _leverage_ your knowledge of PLL 
theory, but you have to modify it wisely to make it work in this case.

-- 
http://www.wescottdesign.com

Article: 139383
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 27 Mar 2009 21:44:31 -0500
Links: << >>  << T >>  << A >>
On Fri, 27 Mar 2009 16:10:07 -0700, rickman wrote:

> > > I'm sure I'm not the first person to control an oscillator by the
> > > amount of data in a FIFO, but I haven't found a reference to this
> > > design which is similar to a PLL.
>
> > > In place of a typical phase detector, I am using the count of 
samples
> > > in the FIFO to control the DCO which drives the output clock.  Data 
is
> > > clocked into the FIFO using the reference (input) clock.  I have an
> > > integrator between the data count and the DCO phase step input.  The
> > > data count is also offset so that it is zero when at the set point.
>
> > > I am having trouble understanding how to model this design.  Is 
there
> > > a unique name for this sort of circuit?  At first I was thinking it
> > > was a frequency locked loop (FLL), but then I realized that the data
> > > count works the same as a phase detector by integrating the 
difference
> > > in frequency of the two signals, it just has a granularity of 1 
cycle
> > > and does not wrap around like typical phase detectors do.  So 
should I
> > > be using the same model for this as I would use for a conventional 
PLL
> > > using a standard phase detector?
>
> > > I am having trouble getting the circuit to lock in quickly without
> > > overshoot and hold lock as the frequency shifts.  I believe I need 
to
> > > add a proportional element to the feedback loop.  I am also
> > > considering using different coefficients when the loop is locked and
> > > when not locked.
>
> > > Am I making this hard and it just needs to be treated like any other
> > > PLL?
>
> > > Rick
>
> > Sure sounds like it's just a phase detector.  That said, unless every
> > clock of the input clock is putting a sample into the FIFO you start
> > giving away gain pretty rapidly.  In a digital feedback loop,
> > gain=bits=ability to treat things as mathematically perfect rather 
than
> > mucking around in non-linear quantization effects.
>
> I'm not sure I understand this.  Every clock of the input *does* put a
> value into the FIFO.  Every clock of the output removes a sample from
> the FIFO.
>
> One thing that is confusing me is that I want to update the error
> integrator only on the input clock enable, but the output clock phase
> accumulator operates on every cycle of the main clock.  So a single
> count in the error value produces multiple counts of offset in the
> phase of the output.  This seems to make the output rate never
> stabilize completely.  I suspect that I need to provide proper low
> pass filtering which I don't currently use.
>
> Rick

Perhaps you need to crank your integrator gain down?

-- 
http://www.wescottdesign.com

Article: 139384
Subject: Re: best soft core(s) that have C compiler support
From: -jg <Jim.Granville@gmail.com>
Date: Fri, 27 Mar 2009 19:53:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> sorry, i did mean vendor provided open-source one (the onlysuch one
> bein mico32)

I'm still lost as to why you exclude those ? If it is open source, you
are
free to start your own branch design, should you spot something that
really need adding, but can only be done at the cost of something
else....

> and as of clean room microblaze vs i8080 clone, i think i did think
> i8080 clone  is more safe and clean then microblaze clones

Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
of FPGAs
makes register based cores more natural.
(indeed, even ones with a register frame pointer)

What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?

-jg


Article: 139385
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 28 Mar 2009 03:57:18 GMT
Links: << >>  << T >>  << A >>
On Fri, 27 Mar 2009 08:04:43 -0700, rickman wrote:

> I'm sure I'm not the first person to control an oscillator by the amount
> of data in a FIFO, but I haven't found a reference to this design which
> is similar to a PLL.
> 
> In place of a typical phase detector, I am using the count of samples in
> the FIFO to control the DCO which drives the output clock.  Data is
> clocked into the FIFO using the reference (input) clock.  I have an
> integrator between the data count and the DCO phase step input.  The
> data count is also offset so that it is zero when at the set point.
> 
> I am having trouble understanding how to model this design.  Is there a
> unique name for this sort of circuit?  At first I was thinking it was a
> frequency locked loop (FLL), but then I realized that the data count
> works the same as a phase detector by integrating the difference in
> frequency of the two signals, it just has a granularity of 1 cycle and
> does not wrap around like typical phase detectors do.  So should I be
> using the same model for this as I would use for a conventional PLL
> using a standard phase detector?
> 
> I am having trouble getting the circuit to lock in quickly without
> overshoot and hold lock as the frequency shifts.  I believe I need to
> add a proportional element to the feedback loop.  I am also considering
> using different coefficients when the loop is locked and when not
> locked.
> 
> Am I making this hard and it just needs to be treated like any other
> PLL?

Hi Rick,

I've done this sort of thing in a few real-world designs.  The FIFO is a 
phase / frequency detector when used this way, and the regular PLL theory 
applies.

I break the PFD implementations into a number of types:  

1.  The "half full" output of the FIFO is used as the phase error 
signal.  This gives bang-bang control, which can result in a chaotic 
system.  These are hard to analyse, but can still be made to give good 
results.  Things like jitter gain will vary with input jitter amplitude.  
(This doesn't apply to your design, and I won't consider it further.)

2a.  The depth output of the FIFO is used to give a (more or less) linear 
phase error signal.  The FIFO will have stops at either end (writes 
disabled if full and reads disabled if empty) which means that the FIFO 
also acts as a frequency detector (e.g. if there is a constant difference 
in the input and output frequencies, the phase error signal will have an 
average value that is non-zero).  Note that the frequency detector 
doesn't work in a linear way: it is either +max, -max, or off (and the 
FIFO is operating as a phase detector with a linear output).

2b.  Like 2a, but without the stops.  This disables the frequency 
detector action of the FIFO.  You will need some other sort of frequency 
detector to enable the loop to lock.  This can be handy if you want to 
avoid windup.

> So should I be
> using the same model for this as I would use for a conventional PLL
> using a standard phase detector?

Yes.  For both 2a and 2b, you can calculate the equivalent phase detector 
gain in terms of output units per radian of phase error.  Analog phase 
detectors have a gain usually measured in volt / radian or amp / radian 
(for charge pump types).  If you wish, you can convert units to volts to 
enable you to plug your design into old-fashioned PLL design equations.

> I am having trouble getting the circuit to lock in quickly without
> overshoot and hold lock as the frequency shifts.  I believe I need to
> add a proportional element to the feedback loop.

Yes, in a Type II system you *need* a zero (from the proportional 
element) to position the closed loop poles in a good location.  (BTW, the 
Type II system has two (open loop) integrators: one is the integrator in 
your loop filter, the other is the DCO.)

> I am also considering
> using different coefficients when the loop is locked and when not
> locked.

When used as a frequency detector, the FIFO depth output will be stuck at 
+max or -max as long as the frequency difference is present.  You can 
vary the relative frequency detector / phase detector gain by varying the 
depth of your FIFO.  A deeper FIFO means that +max and -max will be 
larger, and they will slew your integrator faster (meaning lock time will 
be lower).
It is also possible to go the other way and reduce the effective 
frequency detector "gain" by clipping the PFD output to smaller limits.

When locked, the PFD output only needs to be linear over a limited range, 
given by the amount of jitter you need to absorb outside the loop 
bandwidth.  This is typically small (perhaps a few cycles?).  Clipping 
the PFD output so that it can't go outside this range can help to reduce 
windup effects and improve the overshoot during initial frequency 
acquisition, at the cost of increased lock time.

Regards,
Allan

Article: 139386
Subject: Re: Where to find a xc6200 xilinx fpga?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 27 Mar 2009 22:39:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 12:55=A0am, thomas.sch...@hotmail.fr wrote:
> Does anyone know where I could find a xc6200 fpga? I would like to
> experiment things on reconfigurable computing and it seems to be the
> only fpga with a complete documentation to be fully dynamically
> reconfigurable.
> Thanks.
>
> Thomas

Atmel AT40 and AT94K also have full documentation :)
and are easier to access

Antti

Article: 139387
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 27 Mar 2009 22:45:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> <Antti.Luk...@googlemail.com> wrote:
> > sorry, i did mean vendor provided open-source one (the onlysuch one
> > bein mico32)
>
> I'm still lost as to why you exclude those ? If it is open source, you
> are
> free to start your own branch design, should you spot something that
> really need adding, but can only be done at the cost of something
> else....
>
> > and as of clean room microblaze vs i8080 clone, i think i did think
> > i8080 clone =A0is more safe and clean then microblaze clones
>
> Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> of FPGAs
> makes register based cores more natural.
> (indeed, even ones with a register frame pointer)
>
> What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> -jg

Hi Jim,

let me explain in more detail:

if I use LatticeMico32 for commercial product targetting Xilinx,
Altera..
or
if I use MicroBlaze(tm) clone on Altera, Lattice

then I suppose it may get unwanted attention, or if not it will get
absolute nil support from the vendors where soft-core marketed
by direct competitor is used.

regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
et others
would not mind, as Intel is not FPGA vendor.
and i do not think intel would send C&D either

this was the full reasoning behind the selection based on licensing
and clones.

=3D=3D

C- Compiler for PicoBlaze, well it can be used for some test to prove
it generates code, but PicoBlaze is so crippled that the solution is
not much useable. Just too small code space.

=3D=3D
YARI, hm i am interested too, if even the caches could be disabled
it maybe small enough


Antti




























Article: 139388
Subject: Re: best soft core(s) that have C compiler support
From: -jg <Jim.Granville@gmail.com>
Date: Fri, 27 Mar 2009 23:02:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
> > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > sorry, i did mean vendor provided open-source one (the onlysuch one
> > > bein mico32)
>
> > I'm still lost as to why you exclude those ? If it is open source, you
> > are
> > free to start your own branch design, should you spot something that
> > really need adding, but can only be done at the cost of something
> > else....
>
> > > and as of clean room microblaze vs i8080 clone, i think i did think
> > > i8080 clone =A0is more safe and clean then microblaze clones
>
> > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> > of FPGAs
> > makes register based cores more natural.
> > (indeed, even ones with a register frame pointer)
>
> > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> > -jg
>
> Hi Jim,
>
> let me explain in more detail:
>
> if I use LatticeMico32 for commercial product targetting Xilinx,
> Altera..
> or
> if I use MicroBlaze(tm) clone on Altera, Lattice
>
> then I suppose it may get unwanted attention, or if not it will get
> absolute nil support from the vendors where soft-core marketed
> by direct competitor is used.

What sort of unwanted attention ? It is open sourced, they do not care
if
it goes into an ASIC, or any FPGA.
As for support, yes, if Z or A tools barf on some detail, then you
need to work
yourself, but the same applies to any other candidate on your list
too....



> regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
> et others
> would not mind, as Intel is not FPGA vendor.
> and i do not think intel would send C&D either

;) IF you could even find anyone at intel who knew what an 8080 was !!

>
> C- Compiler for PicoBlaze, well it can be used for some test to prove
> it generates code, but PicoBlaze is so crippled that the solution is
> not much useable. Just too small code space.

But there are choices, and V3 supports 24 bits of address space, which
is more than I recall a 8080 offering

>
> =3D=3D
> YARI, hm i am interested too, if even the caches could be disabled
> it maybe small enough

-jg


Article: 139389
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 27 Mar 2009 23:24:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 8:02=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
> > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> > > <Antti.Luk...@googlemail.com> wrote:
> > > > sorry, i did mean vendor provided open-source one (the onlysuch one
> > > > bein mico32)
>
> > > I'm still lost as to why you exclude those ? If it is open source, yo=
u
> > > are
> > > free to start your own branch design, should you spot something that
> > > really need adding, but can only be done at the cost of something
> > > else....
>
> > > > and as of clean room microblaze vs i8080 clone, i think i did think
> > > > i8080 clone =A0is more safe and clean then microblaze clones
>
> > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> > > of FPGAs
> > > makes register based cores more natural.
> > > (indeed, even ones with a register frame pointer)
>
> > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> > > -jg
>
> > Hi Jim,
>
> > let me explain in more detail:
>
> > if I use LatticeMico32 for commercial product targetting Xilinx,
> > Altera..
> > or
> > if I use MicroBlaze(tm) clone on Altera, Lattice
>
> > then I suppose it may get unwanted attention, or if not it will get
> > absolute nil support from the vendors where soft-core marketed
> > by direct competitor is used.
>
> What sort of unwanted attention ? It is open sourced, they do not care
> if
> it goes into an ASIC, or any FPGA.
> As for support, yes, if Z or A tools barf on some detail, then you
> need to work
> yourself, but the same applies to any other candidate on your list
> too....
>
> > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
> > et others
> > would not mind, as Intel is not FPGA vendor.
> > and i do not think intel would send C&D either
>
> ;) IF you could even find anyone at intel who knew what an 8080 was !!
>
>
>
> > C- Compiler for PicoBlaze, well it can be used for some test to prove
> > it generates code, but PicoBlaze is so crippled that the solution is
> > not much useable. Just too small code space.
>
> But there are choices, and V3 supports 24 bits of address space, which
> is more than I recall a 8080 offering
>
>
>
> > =3D=3D
> > YARI, hm i am interested too, if even the caches could be disabled
> > it maybe small enough
>
> -jg

Jim

LatticeMico8 Ver 3 supports 24 bit banked address space for the IO
but still only 4K instruction memory, and PicoBlaze asfaik doesnt
support large memory addressing nativly

and, I am not saying my list is good one, or has the right candidates
it was the best to my knowledge at the time or making it based on
the criteria i had in mind. maybe there are much better candidates
thats why i posted in the first place.

i8080 is on the list mainly because the lightweigt8080 is rather
small.. i was suprised.

the goal is to find best CPU for minimal SoC that should be
possible to fit to widest possible selection of FPGA's thats
why the huge ones are not listed. L8080 fits into smaller
end of FPGAs where 32 bit Cores do no longer fit. Also
some smaller FPGAs may have too small BRAM so
the 32 bit CPUs would just have too small instruction memory
for the C compiler to be useable at all. So I would prefer
to have some 8 bit CPU on my offering as well. It seems
that L8080 could be the candidate.

Antti








Article: 139390
Subject: Re: best soft core(s) that have C compiler support
From: -jg <Jim.Granville@gmail.com>
Date: Sat, 28 Mar 2009 00:24:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 6:24=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 28, 8:02=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
> > On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
> > > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> > > > <Antti.Luk...@googlemail.com> wrote:
> > > > > sorry, i did mean vendor provided open-source one (the onlysuch o=
ne
> > > > > bein mico32)
>
> > > > I'm still lost as to why you exclude those ? If it is open source, =
you
> > > > are
> > > > free to start your own branch design, should you spot something tha=
t
> > > > really need adding, but can only be done at the cost of something
> > > > else....
>
> > > > > and as of clean room microblaze vs i8080 clone, i think i did thi=
nk
> > > > > i8080 clone =A0is more safe and clean then microblaze clones
>
> > > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram natur=
e
> > > > of FPGAs
> > > > makes register based cores more natural.
> > > > (indeed, even ones with a register frame pointer)
>
> > > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc =
?
>
> > > > -jg
>
> > > Hi Jim,
>
> > > let me explain in more detail:
>
> > > if I use LatticeMico32 for commercial product targetting Xilinx,
> > > Altera..
> > > or
> > > if I use MicroBlaze(tm) clone on Altera, Lattice
>
> > > then I suppose it may get unwanted attention, or if not it will get
> > > absolute nil support from the vendors where soft-core marketed
> > > by direct competitor is used.
>
> > What sort of unwanted attention ? It is open sourced, they do not care
> > if
> > it goes into an ASIC, or any FPGA.
> > As for support, yes, if Z or A tools barf on some detail, then you
> > need to work
> > yourself, but the same applies to any other candidate on your list
> > too....
>
> > > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice=
,
> > > et others
> > > would not mind, as Intel is not FPGA vendor.
> > > and i do not think intel would send C&D either
>
> > ;) IF you could even find anyone at intel who knew what an 8080 was !!
>
> > > C- Compiler for PicoBlaze, well it can be used for some test to prove
> > > it generates code, but PicoBlaze is so crippled that the solution is
> > > not much useable. Just too small code space.
>
> > But there are choices, and V3 supports 24 bits of address space, which
> > is more than I recall a 8080 offering
>
> > > =3D=3D
> > > YARI, hm i am interested too, if even the caches could be disabled
> > > it maybe small enough
>
> > -jg
>
> Jim
>
> LatticeMico8 Ver 3 supports 24 bit banked address space for the IO
> but still only 4K instruction memory, and PicoBlaze asfaik doesnt
> support large memory addressing nativly

Oops, I just glanced at the data.... - Still, that's not hard to fix.
I think the Mico8 does not map the PC onto register-space ?
- doing that would allow 16 bit calls ?

-jg

Article: 139391
Subject: Re: FIFO controlled loop, PLL, FLL or something else?
From: rickman <gnuarm@gmail.com>
Date: Sat, 28 Mar 2009 01:31:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 10:34 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnu...@gmail.com>
> wrote:
>
> >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
> >> Also sometimes called a "delay-locked loop".
>
> >I am pretty sure that this is not a delay locked loop.  A DLL uses a
> >delay in the feedback path to generate an output that has a different
> >phase than the original.  This is often used to compensate for a delay
> >elsewhere in the clock path.
>
> >In one incarnation of the design of this circuit the error integrator
> >was enabled by the input clock enable.  If there was a phase shift in
> >the input and output clock enables, it would produce a single count of
> >difference during part of the cycle, but would be zero again by the
> >next input clock enable.  However, with the phase accumulator (DCO)
> >operating on each cycle of the main clock, this single count would be
> >added in producing what amounted to a fractional phase step compared
> >to the value in the error integrator.  The result is that the smallest
> >adjustments in output frequency would be made by the phasing of the
> >input and output signals.  However, the phase would never be corrected
> >in the error integrator.
>
> >This is a bit hard to describe in words.  I hope it is clear.
>
> >Rick
>
> That's also a DLL, and perhaps the more commonly-used meaning of the
> term in my experience.

Yeah, I guess people use whatever term they want often and that makes
it hard to communicate about these things.  I am pretty sure that the
"correct" definition of a Delay Locked Loop is as I described above.
But if there is no "official" group to decide these things, there
really is no correct definition.


> This FIFO thing is also pretty common but doesn't seem to have a
> universal name.   As John mentioned, they've been referred to as RLLs,
> "Elastic buffer", and I've heard DLL when the purpose was to match the
> delay to some other output to which the stream needs to be
> synchronized.  In the satellite world there's also "plesiochronous
> buffer" (one of my fave names for this).

In my case the use is two fold.  I am receiving a bit stream and I
need to interleave other data with it at a odd ratio (31:1, 15:1,
etc).  The interleave ratio also determines a delay in the other bit
stream which must be compensated for in the first bit stream with a
fixed quantity delay.  Then as the first bit stream speeds or slows,
the second bit stream clock rate is adjusted to match.  The second bit
rate is just a simple ratio to the first, so that would not require a
PLL.  But the output stream is now 32/31 times the bit rate of the
first input.  This is what the PLL is for.

At the other end a similar circuit de-interleaves the two bit streams
and a PLL generates the output clock.  A similar FIFO adds a delay at
this end and the FIFO data count is again used as the phase
detector.


> I guess since the jobs that it does can different a universal name is
> impractical.

I would like to think that the name would be based on how the circuit
works, not so much on what it is used for.  A FIFO is always called a
FIFO (or a queue) regardless of how it is being used.  Oh, well.  The
main thing is to get it to work.

Rick

Article: 139392
Subject: Re: best soft core(s) that have C compiler support
From: rickman <gnuarm@gmail.com>
Date: Sat, 28 Mar 2009 01:51:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> i know has been discussed before ;)
>
> if we leave out the vendor supplied ones (including open source like
> mico32)
> and the large ones, then my current list:
>
> Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE
> 10.1 results)
> ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for micr=
ocode
>
> ZPU is stack based so most weird, but it has GCC support
> C16 has its own assembler/compiler/simulator supplied with source code
> i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> available
> L8080 (lightweight 8080) not sure if it is correct enogh to run c
> compiler code
>
> I wonder if there are better candidates for each bit-width category
> microblaze clone could be considered for 32, but i would rather leave
> such clones out from the table
>
> Antti

I'm curious, where did you get the data for your table, in particular
the ZPU?  I have been following the ZPU closely, reading the mailing
list.  Although the performance per MHz is not great, they seem to
have produced a fairly compact design, much smaller than 1000 LUTs.
They do a trade off between LUT usage and program memory by
"emulating" some instructions.  In reality, this is done like the
Intel software interrupt tables.  Instead of being executed by the
CPU, the opcode specifies an entry point to a code table to perform
the function of the instruction.  Just in the last week or so, a
person working on a pipelined version has gotten over 200 MHz in a
Virtex 5 and over 100 MHz in a Spartan 3.  It uses 655 LUTs when area
optimized and 711 when speed optimized.  The author claims 3.3 DMIPS @
50MHz.  I don't know so much about DMIPS, but that sounds pretty slow
to me.  Clock speed isn't everything.

They claim even less LUT usage in other versions with less speed
optimizations, but I have not been able to verify this.

Rick

Article: 139393
Subject: Re: best soft core(s) that have C compiler support
From: rickman <gnuarm@gmail.com>
Date: Sat, 28 Mar 2009 01:58:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> i know has been discussed before ;)
>
> if we leave out the vendor supplied ones (including open source like
> mico32)
> and the large ones, then my current list:
>
> Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE
> 10.1 results)
> ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for micr=
ocode
>
> ZPU is stack based so most weird, but it has GCC support
> C16 has its own assembler/compiler/simulator supplied with source code
> i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> available
> L8080 (lightweight 8080) not sure if it is correct enogh to run c
> compiler code
>
> I wonder if there are better candidates for each bit-width category
> microblaze clone could be considered for 32, but i would rather leave
> such clones out from the table
>
> Antti

Oh, BTW, why are you limiting your list to those processors?  There
are a ton of CPUs on the open cores web site.  Of course many of them
are not ready for prime time and some aren't even written, just shells
that were built for a project idea that never really started.  On the
other hand, there are many that are not only workable, seem to be
quite good.

One of the problems with open cores for CPUs is that there is no
standard for submission, so anyone can start a CPU design which is
listed along side of "real" projects, no matter how far it progresses
or what the goal.  More than one is just a design to see if it can be
done or an educational project.  I would like to see more info
provided by the authors and to have a summary table available that
allows the large list of CPU projects to be quickly evaluated for your
purpose.  As it is now, everyone who wished to look for a CPU there
has to spend hours looking at all of the projects.  The "new look"
they have come up with does nothing for the functionality that I can
see and some of the site still is not working, such as the forums.

Rick

Article: 139394
Subject: Re: Where to find a xc6200 xilinx fpga?
From: rickman <gnuarm@gmail.com>
Date: Sat, 28 Mar 2009 02:01:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 6:55=A0pm, thomas.sch...@hotmail.fr wrote:
> Does anyone know where I could find a xc6200 fpga? I would like to
> experiment things on reconfigurable computing and it seems to be the
> only fpga with a complete documentation to be fully dynamically
> reconfigurable.

These chips were only available for a short while.  I don't really
know why Xilinx produced them and then not only stopped, but seems to
have killed them off entirely.

I seem to recall that there were projects around to allow you to do
any manipulation of the bit stream you wish through a JAVA interface.
Not the same as open source tools, but it was supposed to make the
same functionality available.

Rick

Article: 139395
Subject: Re: What does Xilinx mean by "Real 6-input look-up (LUT) technology"?
From: rickman <gnuarm@gmail.com>
Date: Sat, 28 Mar 2009 02:08:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 9:16=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote:
> For some time I've found it pretty humorous that Xilinx boast of "True
> LUT6" in all their Virtex 5+ marketing material. Do they really think
> that they can somehow imply that Altera's ALM isn't a "True LUT6" when
> in fact it's obvious that the ALM encompasses a LUT6 and much more.
>
> Or are there some unreal LUT6 out there?

I don't know what they are referring to by that.  I Lattice provides a
dual LUT6 or a single LUT7 in their equivalent to the CLB.  I think
they do that by combining LUT4 outputs with dedicated muxes.  Heck,
that's "real" enough for me.  I wonder what the advantage of a "real"
LUT6 is?  :^)

Rick

Article: 139396
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 28 Mar 2009 02:11:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 10:58=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > i know has been discussed before ;)
>
> > if we leave out the vendor supplied ones (including open source like
> > mico32)
> > and the large ones, then my current list:
>
> > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE
> > 10.1 results)
> > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi=
crocode
>
> > ZPU is stack based so most weird, but it has GCC support
> > C16 has its own assembler/compiler/simulator supplied with source code
> > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> > available
> > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > compiler code
>
> > I wonder if there are better candidates for each bit-width category
> > microblaze clone could be considered for 32, but i would rather leave
> > such clones out from the table
>
> > Antti
>
> Oh, BTW, why are you limiting your list to those processors? =A0There
> are a ton of CPUs on the open cores web site. =A0Of course many of them
> are not ready for prime time and some aren't even written, just shells
> that were built for a project idea that never really started. =A0On the
> other hand, there are many that are not only workable, seem to be
> quite good.
>
> One of the problems with open cores for CPUs is that there is no
> standard for submission, so anyone can start a CPU design which is
> listed along side of "real" projects, no matter how far it progresses
> or what the goal. =A0More than one is just a design to see if it can be
> done or an educational project. =A0I would like to see more info
> provided by the authors and to have a summary table available that
> allows the large list of CPU projects to be quickly evaluated for your
> purpose. =A0As it is now, everyone who wished to look for a CPU there
> has to spend hours looking at all of the projects. =A0The "new look"
> they have come up with does nothing for the functionality that I can
> see and some of the site still is not working, such as the forums.
>
> Rick

Rick

I do have a large Excel table where i list all the soft cores, and
their features :)

will be published soon too

i just am trying to use the table for one specific purpose now

i know there are tons of cores, and .. many of them useable for
some purpose, just the selection and find the right one is not
always trivial

Antti





Article: 139397
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 28 Mar 2009 02:14:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 10:51=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > i know has been discussed before ;)
>
> > if we leave out the vendor supplied ones (including open source like
> > mico32)
> > and the large ones, then my current list:
>
> > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE
> > 10.1 results)
> > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi=
crocode
>
> > ZPU is stack based so most weird, but it has GCC support
> > C16 has its own assembler/compiler/simulator supplied with source code
> > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> > available
> > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > compiler code
>
> > I wonder if there are better candidates for each bit-width category
> > microblaze clone could be considered for 32, but i would rather leave
> > such clones out from the table
>
> > Antti
>
> I'm curious, where did you get the data for your table, in particular
> the ZPU? =A0I have been following the ZPU closely, reading the mailing
> list. =A0Although the performance per MHz is not great, they seem to
> have produced a fairly compact design, much smaller than 1000 LUTs.
> They do a trade off between LUT usage and program memory by
> "emulating" some instructions. =A0In reality, this is done like the
> Intel software interrupt tables. =A0Instead of being executed by the
> CPU, the opcode specifies an entry point to a code table to perform
> the function of the instruction. =A0Just in the last week or so, a
> person working on a pipelined version has gotten over 200 MHz in a
> Virtex 5 and over 100 MHz in a Spartan 3. =A0It uses 655 LUTs when area
> optimized and 711 when speed optimized. =A0The author claims 3.3 DMIPS @
> 50MHz. =A0I don't know so much about DMIPS, but that sounds pretty slow
> to me. =A0Clock speed isn't everything.
>
> They claim even less LUT usage in other versions with less speed
> optimizations, but I have not been able to verify this.
>
> Rick

Rick

the 1000 slice for ZPU wonder me too :(
i did just run synthesis on the zpu_med

i know it looks awafylly wrong, but i used the results reported
the zpu is said to be as small as 400 lut or so, what is way
less the 1000 slices i got from ISE test run

Antti






Article: 139398
Subject: Re: best soft core(s) that have C compiler support
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 28 Mar 2009 02:19:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 28, 10:51=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > i know has been discussed before ;)
>
> > if we leave out the vendor supplied ones (including open source like
> > mico32)
> > and the large ones, then my current list:
>
> > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE
> > 10.1 results)
> > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450
> > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi=
crocode
>
> > ZPU is stack based so most weird, but it has GCC support
> > C16 has its own assembler/compiler/simulator supplied with source code
> > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler
> > available
> > L8080 (lightweight 8080) not sure if it is correct enogh to run c
> > compiler code
>
> > I wonder if there are better candidates for each bit-width category
> > microblaze clone could be considered for 32, but i would rather leave
> > such clones out from the table
>
> > Antti
>
> I'm curious, where did you get the data for your table, in particular
> the ZPU? =A0I have been following the ZPU closely, reading the mailing
> list. =A0Although the performance per MHz is not great, they seem to
> have produced a fairly compact design, much smaller than 1000 LUTs.
> They do a trade off between LUT usage and program memory by
> "emulating" some instructions. =A0In reality, this is done like the
> Intel software interrupt tables. =A0Instead of being executed by the
> CPU, the opcode specifies an entry point to a code table to perform
> the function of the instruction. =A0Just in the last week or so, a
> person working on a pipelined version has gotten over 200 MHz in a
> Virtex 5 and over 100 MHz in a Spartan 3. =A0It uses 655 LUTs when area
> optimized and 711 when speed optimized. =A0The author claims 3.3 DMIPS @
> 50MHz. =A0I don't know so much about DMIPS, but that sounds pretty slow
> to me. =A0Clock speed isn't everything.
>
> They claim even less LUT usage in other versions with less speed
> optimizations, but I have not been able to verify this.
>
> Rick

   Number of BUFGMUXs                        1 out of 24      4%
   Number of MULT18X18SIOs                   3 out of 20     15%
   Number of RAMB16BWEs                     16 out of 20     80%
   Number of Slices                       1057 out of 5888   17%
      Number of SLICEMs                      0 out of 2944    0%

ZPU_med

results without tweaking.. :(

seems i need serious optimizing to get down the resource useage

Antti

Article: 139399
Subject: Re: best soft core(s) that have C compiler support
From: Kolja <ksulimma@googlemail.com>
Date: Sat, 28 Mar 2009 05:27:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Mrz., 06:45, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:

>  if I use MicroBlaze(tm)
Last time I checked there was no registered "microblaze" trademark.
Neither in
the US nor in Germany.
And if there was, it would only prevent you from calling your product
"Microblaze".
You could still be 100% compatible.

> clone on Altera, Lattice
> then I suppose it may get unwanted attention, or if not it will get
> absolute nil support from the vendors where soft-core marketed
> by direct competitor is used.

The Microblaze clone is not marketed by Xilinx but by open cores.

ISAs can't be protected and the simple single issue implementations
hardly use anything that has been patented in the last 25 years.


> > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
> et others
> would not mind, as Intel is not FPGA vendor.
> and i do not think intel would send C&D either

And if they to ignore it. Any patents covering 8080 are long expired
and
copyright law does not apply (as long as you did not copy any HDL or
schematics from them)

Please everybody: Don't believe the FUD of the vendors.
They try to spread incorrect views on the legal situation.

And if I should ever get a C&D from Xilinx I would immediately answer
with a
C&D regarding the incorrect use of the GPL in the ISE distribution.
Well that is a major copyrigh violation on their side.

As a side note to extend you list:
What about LEON and the other open source versions of SPARC?
Did not SUN open source their design?
And doesn't openRISC have C-Compiler support?

Have fun,

Kolja





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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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