Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #34509 > unrolled thread

when greenarrays desktop pc? with firefox? vga? usb3??

Back to article view | Back to comp.lang.forth

Contents

  when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-19 11:33 -0800
    Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-19 17:04 -0800
    Re: when greenarrays desktop pc? with firefox? vga? usb3?? JUERGEN <epldfpga@aol.com> - 2014-11-20 09:30 -0800
      Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-20 10:34 -0800
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? JUERGEN <epldfpga@aol.com> - 2014-11-20 13:21 -0800
          Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-20 13:27 -0800
            Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-20 20:56 -0500
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-20 18:43 -0800
                Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-20 23:45 -0500
                  Re: when greenarrays desktop pc? with firefox? vga? usb3?? Syd Rumpo <usenet@nononono.co.uk> - 2014-11-21 09:58 +0000
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? Mark Wills <markwills1970@gmail.com> - 2014-11-21 02:10 -0800
                      Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 06:08 -0500
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 05:57 -0500
                      Re: when greenarrays desktop pc? with firefox? vga? usb3?? Syd Rumpo <usenet@nononono.co.uk> - 2014-11-21 11:37 +0000
                        Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 07:07 -0500
                          Re: when greenarrays desktop pc? with firefox? vga? usb3?? Syd Rumpo <usenet@nononono.co.uk> - 2014-11-21 13:59 +0000
                            Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-21 10:46 -0800
                            Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 16:45 -0500
                              Re: when greenarrays desktop pc? with firefox? vga? usb3?? Syd Rumpo <usenet@nononono.co.uk> - 2014-11-22 11:39 +0000
                                Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-22 12:38 -0500
                                  Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-22 10:20 -0800
                                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? Coos Haak <chforth@hccnet.nl> - 2014-11-22 21:39 +0100
                                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? Paul Rubin <no.email@nospam.invalid> - 2014-11-22 12:51 -0800
                                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-22 17:55 -0500
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? Mark Wills <markwills1970@gmail.com> - 2014-11-21 02:06 -0800
                Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 16:49 -0500
                Thanks - was (Re: when greenarrays desktop pc? with firefox? vga? usb3??) Richard Owlett <rowlett@cloud85.net> - 2014-11-22 10:00 -0600
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-21 19:58 -0500
                Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-21 22:24 -0500
                  Re: when greenarrays desktop pc? with firefox? vga? usb3?? JUERGEN <epldfpga@aol.com> - 2014-11-22 01:06 -0800
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-22 15:40 -0500
                  Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-22 10:14 -0800
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-22 23:47 -0800
                  Re: when greenarrays desktop pc? with firefox? vga? usb3?? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-22 15:36 -0500
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-22 18:05 -0500
                    Re: when greenarrays desktop pc? with firefox? vga? usb3?? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-23 11:43 +0000
                      Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-29 09:12 -0800
      Re: when greenarrays desktop pc? with firefox? vga? usb3?? Jason Damisch <jasondamisch@yahoo.com> - 2014-11-20 13:48 -0800
    Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-29 09:14 -0800
      Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-29 20:38 -0500
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? Howerd <howerdo@yahoo.co.uk> - 2014-11-30 06:48 -0800
          Re: when greenarrays desktop pc? with firefox? vga? usb3?? Howerd <howerdo@yahoo.co.uk> - 2014-11-30 06:55 -0800
            Re: when greenarrays desktop pc? with firefox? vga? usb3?? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-11-30 17:40 +0000
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-11-30 12:57 -0800
          Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-11-30 16:43 -0500
            Re: when greenarrays desktop pc? with firefox? vga? usb3?? visualforth@rocketmail.com - 2014-12-01 19:03 -0800
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-12-01 23:08 -0500
            Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 19:16 -0800
            Re: when greenarrays desktop pc? with firefox? vga? usb3?? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-12-02 08:06 -0800
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? rickman <gnuarm@gmail.com> - 2014-12-02 12:02 -0500
                Re: when greenarrays desktop pc? with firefox? vga? usb3?? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-12-02 11:48 -0800
                Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-08 22:48 -0800
              Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-08 22:48 -0800
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 19:18 -0800
    Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 19:13 -0800
      Re: when greenarrays desktop pc? with firefox? vga? usb3?? farva <joshua.harden@farva.net> - 2014-12-01 19:43 -0800
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 22:26 -0800
          Re: when greenarrays desktop pc? with firefox? vga? usb3?? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2014-12-06 18:33 +0000
        Re: when greenarrays desktop pc? with firefox? vga? usb3?? the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 22:27 -0800

Page 1 of 3  [1] 2 3  Next page →

#34509 — when greenarrays desktop pc? with firefox? vga? usb3??

when?

[toc] | [next] | [standalone]

#34512

On Wednesday, November 19, 2014 11:33:12 AM UTC-8, the_gavino_himself wrote:
> when?

Me want to know to!

when?

Jason

[toc] | [prev] | [next] | [standalone]

#34516

On Wednesday, November 19, 2014 7:33:12 PM UTC, the_gavino_himself wrote:
> when?

... isn't the local memory per processor a bit small? (joke) ...

Is there an application note showing a largish program as example?
The low-power aspects would not be relevant anymore 

So - we should push to have GA144 included in the LUNAR1 Mission
http://www.bbc.co.uk/news/science-environment-30102343
... and see the result in another 10 years time

[toc] | [prev] | [next] | [standalone]

#34517

On Thursday, November 20, 2014 9:30:49 AM UTC-8, JUERGEN wrote:

> So - we should push to have GA144 included in the LUNAR1 Mission

It would need to be rad hardened to be able to be used for this.

Jason

[toc] | [prev] | [next] | [standalone]

#34520

On Thursday, November 20, 2014 6:34:35 PM UTC, Jason Damisch wrote:
> On Thursday, November 20, 2014 9:30:49 AM UTC-8, JUERGEN wrote:
> 
> > So - we should push to have GA144 included in the LUNAR1 Mission
> 
> It would need to be rad hardened to be able to be used for this.
> 
> Jason

I know Jason. I am Ex RCA - CDP1802 - SOS Silicon on Sapphire, High Rel ...

 But I mentioned it as I hope there is a discussion about it here - 
It could be as well in FPGA - or ASIC.
Or the RTX in FPGA/ASIC?
After the success on Philae there could be a chance.

[toc] | [prev] | [next] | [standalone]

#34521

On Thursday, November 20, 2014 1:21:14 PM UTC-8, JUERGEN wrote:

> After the success on Philae there could be a chance.

Well, using a small memory footprint is a safety feature.  So, the limited memory size of the RTX and the GA is appropriate. 

Greg said that he wanted to include about 64K of RAM on a GA chip someday.  That ought to be enough.

Sure, lets discuss it.

Who has a fab doing SOS who might be interested in hearing about this?  Who knows the right people to talk to?  You need credibility.  I'm not in the industry.  You say that you were.

[toc] | [prev] | [next] | [standalone]

#34526

On 11/20/2014 4:27 PM, Jason Damisch wrote:
> On Thursday, November 20, 2014 1:21:14 PM UTC-8, JUERGEN wrote:
>
>> After the success on Philae there could be a chance.
>
> Well, using a small memory footprint is a safety feature.  So, the limited memory size of the RTX and the GA is appropriate.
>
> Greg said that he wanted to include about 64K of RAM on a GA chip someday.  That ought to be enough.
>
> Sure, lets discuss it.
>
> Who has a fab doing SOS who might be interested in hearing about this?  Who knows the right people to talk to?  You need credibility.  I'm not in the industry.  You say that you were.

Just putting the memory on chip is not enough.  Access to it from 
various nodes needs to be included.  The GA144 is also very I/O limited, 
both quantity and compatibility.

The real issue with the GA144 is that it was driven by the "wouldn't 
this be cool" factor rather than any market.  So it addresses *no* 
market.  Chuck and friends saw the features of the F18A and thought it 
should be good for something, but it turns out it is not good for many 
apps.  One of the several limitations bites you in the... ankle... 
almost every time.

When I am done with my present project I might try doing a GA144 
project.  I looked at it some time back and just using the coding 
environment seemed a bear.  But I might be willing to deal with that to 
get an idea or two tested.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34527

On Thursday, November 20, 2014 5:57:07 PM UTC-8, rickman wrote:

> Just putting the memory on chip is not enough.  Access to it from 
> various nodes needs to be included.  The GA144 is also very I/O limited, 
> both quantity and compatibility.

From my understanding the memory would be used by a VM, either a Forth VM such as Polyforth, or a C VM.  The rest of the cores would be programmed in the each page of memory has its own core, so factor your program across multiple cores way.  If that does not appeal to you, the perhaps the GA144 is not for you?

Jason

[toc] | [prev] | [next] | [standalone]

#34534

On 11/20/2014 9:43 PM, Jason Damisch wrote:
> On Thursday, November 20, 2014 5:57:07 PM UTC-8, rickman wrote:
>
>> Just putting the memory on chip is not enough.  Access to it from
>> various nodes needs to be included.  The GA144 is also very I/O limited,
>> both quantity and compatibility.
>
>  From my understanding the memory would be used by a VM, either a Forth VM such as Polyforth, or a C VM.  The rest of the cores would be programmed in the each page of memory has its own core, so factor your program across multiple cores way.  If that does not appeal to you, the perhaps the GA144 is not for you?

Lol!  That is the problem.  There aren't many who the GA144 *does* 
appeal to, at least enough to design it into a product.

I have a board I manufacture that the GA144 is *almost* a good fit for. 
  But the same requirement that sinks all other MCUs sink the GA144.  It 
can't respond to the 33 MHz serial interface quickly enough.  Although I 
shouldn't say that absolutely.  The interface is clocked at 33 MHz, but 
there is a half clock cycle response time to put the first read data bit 
onto the output pin.  No MCU can do that since significant time is 
required just to read the data word.  In the GA144 15 ns is barely 
enough time to perform a memory operation and get the first bit to shift 
out.  But there also has to be timing controls and it needs an interface 
to the rest of the processors.  There might be a way to use multiple 
processors for this one task, but the point is this is very tight 
timing.  Heck, it was a bit on the edge of meeting timing it in an FPGA!

Then there was a control app which needed to do multiple FPGAs on five 
48 kSPS, 24 bit samples data streams.  I'm pretty sure the GA144 could 
manage to do the butterflies although they would need to be written from 
scratch.  The difficult part is shuffling all the data around for a 1024 
point real FFT.  The comms channels are fast, but I don't know if they 
are fast enough for this.  The ADCs aren't quite up to snuff for this 
app either.  The requirement was for 16 ENOB.  The GA144 ADCs can only 
convert 15 bits at this sample rate only supporting 16 bits at something 
like 20 some kSPS.

And that is the point.  Compare the GA144 for this app and it comes up 
short this way, compare it for that app and it comes up short another 
way.  When that person evaluated it they can't deal with the development 
system, another potential user wants more canned and proven interfaces 
or software libraries.  The list goes on and on.

I like the part.  I would like to try it in a *very* low power app I 
have in mind.  But it has issues even in low power apps where it is 
supposed to be ideal.  Try doing timing, a typical real time task.  To 
have an F18A run a timing loop costs 5 mW just to do timing that is so 
easy with any MCU that has built in timers running on microwatts.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34535

On 21/11/2014 04:45, rickman wrote:
> On 11/20/2014 9:43 PM, Jason Damisch wrote:
>> On Thursday, November 20, 2014 5:57:07 PM UTC-8, rickman wrote:
>>
>>> Just putting the memory on chip is not enough.  Access to it from
>>> various nodes needs to be included.  The GA144 is also very I/O limited,
>>> both quantity and compatibility.
>>
<snipped>
>
> I like the part.  I would like to try it in a *very* low power app I
> have in mind.  But it has issues even in low power apps where it is
> supposed to be ideal.  Try doing timing, a typical real time task.  To
> have an F18A run a timing loop costs 5 mW just to do timing that is so
> easy with any MCU that has built in timers running on microwatts.

I looked at it for a programmable FIR filter - ok, it doesn't have 
multipliers, but the step multiply was quick enough, and the limited 
amount of memory wouldn't be an issue.  What killed it was how to add 
all the stage outputs together.

Having used RTX and PSC1000, I'm a stack machine enthusiast, but I just 
can't think of an application for the GA144 which can't be done better 
another way, and it seems no-one else can either.  I'd love to be proved 
wrong.


Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#34538

On Friday, 21 November 2014 09:58:22 UTC, Syd Rumpo  wrote:
> 
> Having used RTX and PSC1000, I'm a stack machine enthusiast, but I just 
> can't think of an application for the GA144 which can't be done better 
> another way, and it seems no-one else can either.  I'd love to be proved 
> wrong.
> 
Do you think it would be accurate to say that the GA144 is
over-optimised and over-streamlined?

To me, it seems it needs a bit more "meat". Like clocks that you
can turn on/off if you need to, and more memory per node, and a
few extra instructions. Less cores would probably be an acceptable
trade-off.

[toc] | [prev] | [next] | [standalone]

#34540

On 11/21/2014 5:10 AM, Mark Wills wrote:
> On Friday, 21 November 2014 09:58:22 UTC, Syd Rumpo  wrote:
>>
>> Having used RTX and PSC1000, I'm a stack machine enthusiast, but I just
>> can't think of an application for the GA144 which can't be done better
>> another way, and it seems no-one else can either.  I'd love to be proved
>> wrong.
>>
> Do you think it would be accurate to say that the GA144 is
> over-optimised and over-streamlined?

Over optimized for what?  That's the problem, not optimization, but lack 
of focus.  It was just the expression of an idea based on what was easy 
to build to get low power consumption without consideration of how it 
might be used.  If you read Chuck's blog he often talks about "figuring 
out" how to do *anything* with the chip rather than having designed the 
chip to be useful for anything.


> To me, it seems it needs a bit more "meat". Like clocks that you
> can turn on/off if you need to, and more memory per node, and a
> few extra instructions. Less cores would probably be an acceptable
> trade-off.

You can use clocks with the chip.  Just attach one to an I/O pin and let 
that core pend on the transition.  This is essential to performing real 
time processing which is what most embedded is about.  In fact, some 
features of the chip really aren't useful without a precision clock, 
like the ADCs/DACs.  You can do hobbyist type stuff by using a timing 
loop on a core, but most work requires known sample rates.  That is one 
of the few things that seem to have been planned for.  Each ADC/DAC node 
has an I/O pin the processor can pend on to get good alignment between 
the clock edge and the "sample" point.

I looked at using the GA144 for a "single chip" oscilloscope once.  The 
ADCs could support up to 10's of MHz sample rate if you don't mind a 
significant loss of resolution.  That's the tradeoff, resolution vs. 
sample rate.  Still, in a low end unit getting 10's of MHz would be 
unique.  The problem is getting that data to a PC for display, not to 
mention adding memory that would support these sample rates.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34539

On 11/21/2014 4:58 AM, Syd Rumpo wrote:
> On 21/11/2014 04:45, rickman wrote:
>> On 11/20/2014 9:43 PM, Jason Damisch wrote:
>>> On Thursday, November 20, 2014 5:57:07 PM UTC-8, rickman wrote:
>>>
>>>> Just putting the memory on chip is not enough.  Access to it from
>>>> various nodes needs to be included.  The GA144 is also very I/O
>>>> limited,
>>>> both quantity and compatibility.
>>>
> <snipped>
>>
>> I like the part.  I would like to try it in a *very* low power app I
>> have in mind.  But it has issues even in low power apps where it is
>> supposed to be ideal.  Try doing timing, a typical real time task.  To
>> have an F18A run a timing loop costs 5 mW just to do timing that is so
>> easy with any MCU that has built in timers running on microwatts.
>
> I looked at it for a programmable FIR filter - ok, it doesn't have
> multipliers, but the step multiply was quick enough, and the limited
> amount of memory wouldn't be an issue.  What killed it was how to add
> all the stage outputs together.

I don't understand the problem.  What do you mean, "add all the stage 
outputs together"?  If you are talking about splitting the filter across 
multiple cores and the problem is combining the outputs of each, why 
can't they be either sent to a single core for adding together or passed 
daisy chain fashion adding the input to your subtotal and passing the 
result along?  Certainly this is less expensive than the multiplies...


> Having used RTX and PSC1000, I'm a stack machine enthusiast, but I just
> can't think of an application for the GA144 which can't be done better
> another way, and it seems no-one else can either.  I'd love to be proved
> wrong.

If any app is one the GA144 would be good for I would expect it to be a 
signal processing app, either filtering or a control app.

One I thing would have been ideal in terms of the processing was the 
control app using FFTs that had 5 ADC inputs and 2 DAC outputs.  The guy 
I was discussing this with wanted 16 bits ENOB which means the GA144 
ADCs fell just a little short.  For most control apps even 12 bit ADCs 
are fine so sample rates up to 400 kSPS could be supported.  Control 
apps typically have little I/O, again matching the GA144 limitations. 
The only real issue is the lack of memory, both program and data.  So 
likely external chips would be needed.

By far I think the biggest factor preventing the GA144 from being used 
is the development environment.  It is bad enough that few potential 
users know enough about Forth to feel comfortable, if they try to use 
the development environment they find a maze of poorly documented words 
scattered over a number of disconnected pages that are required to edit, 
simulate, compile and download code.  Maybe I just didn't spend enough 
time with it to figure it all out, but it was like exploring catacombs 
in my opinion.  I think most would run away screaming!

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34541

On 21/11/2014 10:57, rickman wrote:
> On 11/21/2014 4:58 AM, Syd Rumpo wrote:

<snip>

>> I looked at it for a programmable FIR filter - ok, it doesn't have
>> multipliers, but the step multiply was quick enough, and the limited
>> amount of memory wouldn't be an issue.  What killed it was how to add
>> all the stage outputs together.
>
> I don't understand the problem.  What do you mean, "add all the stage
> outputs together"?  If you are talking about splitting the filter across
> multiple cores and the problem is combining the outputs of each, why
> can't they be either sent to a single core for adding together or passed
> daisy chain fashion adding the input to your subtotal and passing the
> result along?  Certainly this is less expensive than the multiplies...

Each tap would use a core to multiply a signal by a coefficient - it's a 
fairly fast sampling rate.  The signal is shifted along through many 
cores.  The sum of all these multiplies is the result.  The difficulty 
is routing - it doesn't matter (in this particular application) if the 
result is delayed by some number of clocks, so an adder tree could be 
used, but nonetheless the there just isn't enough routing flexibility to 
make anything worthwhile.

An FPGA is the answer, but I was hoping to create something a bit more 
flexible and a lot more interesting.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#34542

On 11/21/2014 6:37 AM, Syd Rumpo wrote:
> On 21/11/2014 10:57, rickman wrote:
>> On 11/21/2014 4:58 AM, Syd Rumpo wrote:
>
> <snip>
>
>>> I looked at it for a programmable FIR filter - ok, it doesn't have
>>> multipliers, but the step multiply was quick enough, and the limited
>>> amount of memory wouldn't be an issue.  What killed it was how to add
>>> all the stage outputs together.
>>
>> I don't understand the problem.  What do you mean, "add all the stage
>> outputs together"?  If you are talking about splitting the filter across
>> multiple cores and the problem is combining the outputs of each, why
>> can't they be either sent to a single core for adding together or passed
>> daisy chain fashion adding the input to your subtotal and passing the
>> result along?  Certainly this is less expensive than the multiplies...
>
> Each tap would use a core to multiply a signal by a coefficient - it's a
> fairly fast sampling rate.  The signal is shifted along through many
> cores.  The sum of all these multiplies is the result.  The difficulty
> is routing - it doesn't matter (in this particular application) if the
> result is delayed by some number of clocks, so an adder tree could be
> used, but nonetheless the there just isn't enough routing flexibility to
> make anything worthwhile.
>
> An FPGA is the answer, but I was hoping to create something a bit more
> flexible and a lot more interesting.

It doesn't need to be a tree, a linear chain would do just fine and is 
handled very well by the GA144.  The delays would be analogous to an 
adder time, a fixed interval plus a ripple.  In the adder there is a 
time for the bit sums which all run in parallel and then the carry 
ripples.  In the decomposed filter the time to perform the multiply is 
significant and then the time to ripple the adds through all the cores 
can be significant too.

I am picturing a line of cores where each one handles one coefficient. 
Data is initialized to zeros in each core.  On each clock a sample is 
input to the first core which does the multiply and passes the partial 
sum on to the next cell which only has to perform the next partial sum 
and pass that result on until it reaches the end where it is a result. 
The data sample is also passed on to the next core which performs it's 
multiply and waits for the next partial sum.  Each core has passed on 
its data sample to the next cell so all the multiplies have been done 
ahead of time and only the first multiply and all the partial sums need 
to be performed.  Yes, this is *exactly* like the timing for an adder. 
No clock delay, just the N adds and communication time, should be around 
10 to 12 ns per coefficient.  For a 128 tap filter the ripple delay time 
would be about 1.5 uS.  The fastest sample processing time would be on 
the order of 100 ns or 10 MHz.  At least that is my $0.50 analysis.  You 
can send me a check.  lol

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34543

On 21/11/2014 12:07, rickman wrote:
> On 11/21/2014 6:37 AM, Syd Rumpo wrote:
>> On 21/11/2014 10:57, rickman wrote:
>>> On 11/21/2014 4:58 AM, Syd Rumpo wrote:
>>
>> <snip>
>>
>>>> I looked at it for a programmable FIR filter - ok, it doesn't have
>>>> multipliers, but the step multiply was quick enough, and the limited
>>>> amount of memory wouldn't be an issue.  What killed it was how to add
>>>> all the stage outputs together.
>>>
>>> I don't understand the problem.  What do you mean, "add all the stage
>>> outputs together"?  If you are talking about splitting the filter across
>>> multiple cores and the problem is combining the outputs of each, why
>>> can't they be either sent to a single core for adding together or passed
>>> daisy chain fashion adding the input to your subtotal and passing the
>>> result along?  Certainly this is less expensive than the multiplies...
>>
>> Each tap would use a core to multiply a signal by a coefficient - it's a
>> fairly fast sampling rate.  The signal is shifted along through many
>> cores.  The sum of all these multiplies is the result.  The difficulty
>> is routing - it doesn't matter (in this particular application) if the
>> result is delayed by some number of clocks, so an adder tree could be
>> used, but nonetheless the there just isn't enough routing flexibility to
>> make anything worthwhile.
>>
>> An FPGA is the answer, but I was hoping to create something a bit more
>> flexible and a lot more interesting.
>
> It doesn't need to be a tree, a linear chain would do just fine and is
> handled very well by the GA144.  The delays would be analogous to an
> adder time, a fixed interval plus a ripple.  In the adder there is a
> time for the bit sums which all run in parallel and then the carry
> ripples.  In the decomposed filter the time to perform the multiply is
> significant and then the time to ripple the adds through all the cores
> can be significant too.
>
> I am picturing a line of cores where each one handles one coefficient.
> Data is initialized to zeros in each core.  On each clock a sample is
> input to the first core which does the multiply and passes the partial
> sum on to the next cell which only has to perform the next partial sum
> and pass that result on until it reaches the end where it is a result.
> The data sample is also passed on to the next core which performs it's
> multiply and waits for the next partial sum.  Each core has passed on
> its data sample to the next cell so all the multiplies have been done
> ahead of time and only the first multiply and all the partial sums need
> to be performed.  Yes, this is *exactly* like the timing for an adder.
> No clock delay, just the N adds and communication time, should be around
> 10 to 12 ns per coefficient.  For a 128 tap filter the ripple delay time
> would be about 1.5 uS.  The fastest sample processing time would be on
> the order of 100 ns or 10 MHz.  At least that is my $0.50 analysis.  You
> can send me a check.  lol
>
So...

Begin

Read new data sample into core 1 and multiply by coefficient 1.

Pass result to core 2, which adds in the result from its last multiply 
and passes this to core 3, etc, rippling through all the used cores 
adding in their results to produce a filter output sample.

Then shift all data samples to the next core.

Multiply all these shifted samples (not the first one) by their 
coefficients ahead of the next new data sample.

Again

So the limiting factor for more than a small number of taps would be the 
ripple adder, rather than the step multiply.

I think for $0.50 you're underselling yourself.

It's a shame that I didn't think of that (neither did GA) or it would 
have been a good solution - we needed 128 taps at 5MHz, maybe 64 taps 
would be enough.  An FPGA was used, which was very quick to do but no fun.


Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#34544

So, quite possibly after the 64K of Static Ram is added to the chip, those with a soft spot for Forth may finally find some use for it.  

Time will tell.

Jason

[toc] | [prev] | [next] | [standalone]

#34545

On 11/21/2014 8:59 AM, Syd Rumpo wrote:
> On 21/11/2014 12:07, rickman wrote:
>>
>> It doesn't need to be a tree, a linear chain would do just fine and is
>> handled very well by the GA144.  The delays would be analogous to an
>> adder time, a fixed interval plus a ripple.  In the adder there is a
>> time for the bit sums which all run in parallel and then the carry
>> ripples.  In the decomposed filter the time to perform the multiply is
>> significant and then the time to ripple the adds through all the cores
>> can be significant too.
>>
>> I am picturing a line of cores where each one handles one coefficient.
>> Data is initialized to zeros in each core.  On each clock a sample is
>> input to the first core which does the multiply and passes the partial
>> sum on to the next cell which only has to perform the next partial sum
>> and pass that result on until it reaches the end where it is a result.
>> The data sample is also passed on to the next core which performs it's
>> multiply and waits for the next partial sum.  Each core has passed on
>> its data sample to the next cell so all the multiplies have been done
>> ahead of time and only the first multiply and all the partial sums need
>> to be performed.  Yes, this is *exactly* like the timing for an adder.
>> No clock delay, just the N adds and communication time, should be around
>> 10 to 12 ns per coefficient.  For a 128 tap filter the ripple delay time
>> would be about 1.5 uS.  The fastest sample processing time would be on
>> the order of 100 ns or 10 MHz.  At least that is my $0.50 analysis.  You
>> can send me a check.  lol
>>
> So...
>
> Begin
>
> Read new data sample into core 1 and multiply by coefficient 1.
>
> Pass result to core 2, which adds in the result from its last multiply
> and passes this to core 3, etc, rippling through all the used cores
> adding in their results to produce a filter output sample.
>
> Then shift all data samples to the next core.
>
> Multiply all these shifted samples (not the first one) by their
> coefficients ahead of the next new data sample.
>
> Again

Yes, well stated.


> So the limiting factor for more than a small number of taps would be the
> ripple adder, rather than the step multiply.

Yes, again, very much like the timing of a ripple carry adder.  This 
suits the grid comms of the GA144 better than a tree arrangement which 
would have better delays.  Even so, I expect I could fashion a tree 
layout for 128 taps and certainly for 64 taps.  I'm not sure it would be 
tons faster since the input data still has to ripple through.  That is 
determined by the algorithm... but there may be a way to cheat that 
problem if you don't mind the code being different in the different cells.


> I think for $0.50 you're underselling yourself.

Possibly.  But supply and demand is in action.  At this time I might do 
some interesting work for free, lol.


> It's a shame that I didn't think of that (neither did GA) or it would
> have been a good solution - we needed 128 taps at 5MHz, maybe 64 taps
> would be enough.  An FPGA was used, which was very quick to do but no fun.

That's falling off a log for an FPGA... as long as you have the 
multipliers.  The FPGA would be physically larger and suck more power 
(depending on the device chosen) too.  I like the Lattice devices which 
have some true low power options.

How did you get your data into the FPGA, serial, parallel?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#34556

On 21/11/2014 21:45, rickman wrote:
> On 11/21/2014 8:59 AM, Syd Rumpo wrote:

<snip>

>
>> It's a shame that I didn't think of that (neither did GA) or it would
>> have been a good solution - we needed 128 taps at 5MHz, maybe 64 taps
>> would be enough.  An FPGA was used, which was very quick to do but no
>> fun.
>
> That's falling off a log for an FPGA... as long as you have the
> multipliers.  The FPGA would be physically larger and suck more power
> (depending on the device chosen) too.  I like the Lattice devices which
> have some true low power options.
>
> How did you get your data into the FPGA, serial, parallel?
>
It was a 100Mbps differential serial input, but I didn't do the FPGA 
work - a colleague writes VHDL almost as quickly as he can read the 
requirements.  It was an Actel Igloo, and yes, plenty of multipliers.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#34558

On 11/22/2014 6:39 AM, Syd Rumpo wrote:
> On 21/11/2014 21:45, rickman wrote:
>> On 11/21/2014 8:59 AM, Syd Rumpo wrote:
>
> <snip>
>
>>
>>> It's a shame that I didn't think of that (neither did GA) or it would
>>> have been a good solution - we needed 128 taps at 5MHz, maybe 64 taps
>>> would be enough.  An FPGA was used, which was very quick to do but no
>>> fun.
>>
>> That's falling off a log for an FPGA... as long as you have the
>> multipliers.  The FPGA would be physically larger and suck more power
>> (depending on the device chosen) too.  I like the Lattice devices which
>> have some true low power options.
>>
>> How did you get your data into the FPGA, serial, parallel?
>>
> It was a 100Mbps differential serial input, but I didn't do the FPGA
> work - a colleague writes VHDL almost as quickly as he can read the
> requirements.  It was an Actel Igloo, and yes, plenty of multipliers.

The 100 Mbps serial interface would be a problem as well.  I think it 
would be hard to get that into the GA144 through an I/O pin at that 
rate.  Maybe close to it but that would not be many instructions per bit 
and all memory accesses are rather slow compared to ALU instructions. 
Both reading the I/O pin and writing to the comms port to another node 
are memory accesses.

The GA144 has SERDES, but they are not designed to work with anything 
external.  I don't think they even provide enough info to use it with 
something else like an FPGA, but I could be wrong.

This is one of those areas where the GA144 was not designed to do a 
useful task, it was just designed to do *something*.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web