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


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

tethered fpga Forth from Poland

Started byPaul Rubin <no.email@nospam.invalid>
First post2014-02-20 23:46 -0800
Last post2014-02-21 10:55 -0800
Articles 4 — 2 participants

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


Contents

  tethered fpga Forth from Poland Paul Rubin <no.email@nospam.invalid> - 2014-02-20 23:46 -0800
    Re: tethered fpga Forth from Poland forthisit@gmail.com - 2014-02-21 07:31 -0800
      Re: tethered fpga Forth from Poland Paul Rubin <no.email@nospam.invalid> - 2014-02-21 10:28 -0800
        Re: tethered fpga Forth from Poland forthisit@gmail.com - 2014-02-21 10:55 -0800

#28641 — tethered fpga Forth from Poland

FromPaul Rubin <no.email@nospam.invalid>
Date2014-02-20 23:46 -0800
Subjecttethered fpga Forth from Poland
Message-ID<7xios8oqlq.fsf@ruckus.brouhaha.com>
This looks interesting.  They implemented a MISC-like softcore cpu as a
diagnostic tool for other stuff running on an FPGA, driven by an
interactive host-side Forth compiler written in Python and communicating
with the FPGA target.

http://www.ise.pw.edu.pl/~rrom/SPIE/SPIE8903-WILGA2013/8903/CD/WI13/DATA/8903_30.PDF

[toc] | [next] | [standalone]


#28660

Fromforthisit@gmail.com
Date2014-02-21 07:31 -0800
Message-ID<7147b831-dee2-4829-8057-b2e267ac9b37@googlegroups.com>
In reply to#28641
On Friday, February 21, 2014 1:46:25 AM UTC-6, Paul Rubin wrote:
> This looks interesting.  They implemented a MISC-like softcore cpu as a
> diagnostic tool for other stuff running on an FPGA, driven by an
> interactive host-side Forth compiler written in Python and communicating
> with the FPGA target.
> 
> http://www.ise.pw.edu.pl/~rrom/SPIE/SPIE8903-WILGA2013/8903/CD/WI13/DATA/8903_30.PDF

Thanks for posting this. This is exactly the application area that I think will contribute the most to keeping Forth out of "oblivion". However, I don't understand their rationale for dismissing the j1 for the role of target CPU.  It's an efficient, fast, soft-core CPU that also happens to be stack-based with an instruction format that directly maps to primitive Forth words. What's not to like?

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


#28664

FromPaul Rubin <no.email@nospam.invalid>
Date2014-02-21 10:28 -0800
Message-ID<7x61o8tj5k.fsf@ruckus.brouhaha.com>
In reply to#28660
forthisit@gmail.com writes:
> However, I don't understand their rationale for dismissing the j1 for
> the role of target CPU.  It's an efficient, fast, soft-core CPU that
> also happens to be stack-based with an instruction format that
> directly maps to primitive Forth words. What's not to like?

From page 2 of the paper:

    J1 is a very interesting solution, however from our point of view it
    has one significant disadvantage -- it doesn't offer possibility of
    interactive work. The program for J1 must be written and compiled in
    advance, and put into the program memory located in internal RAM in
    FPGA.

I notice they don't mention the B16 though.

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


#28666

Fromforthisit@gmail.com
Date2014-02-21 10:55 -0800
Message-ID<e8798fde-c0be-4502-b17d-afcb6460a41b@googlegroups.com>
In reply to#28664
On Friday, February 21, 2014 12:28:23 PM UTC-6, Paul Rubin wrote:
> forthisit@gmail.com writes:
> > However, I don't understand their rationale for dismissing the j1 for
> > the role of target CPU.  It's an efficient, fast, soft-core CPU that
> > also happens to be stack-based with an instruction format that
> > directly maps to primitive Forth words. What's not to like?
> 
> From page 2 of the paper:
> 
>     J1 is a very interesting solution, however from our point of view it
>     has one significant disadvantage -- it doesn't offer possibility of
>     interactive work. The program for J1 must be written and compiled in
>     advance, and put into the program memory located in internal RAM in
>     FPGA.
> 
> I notice they don't mention the B16 though.

I know. But what would make them think the J1 soft-core doesn't offer 
the possibility of interactive work, while an ARM soft-core does? (I have
used the J1 for interactive work.) I can only guess that they didn't
think the J1 was compatible with their EXEC_PC instruction somehow.

From page 5 of the paper:

  The CPU is a small 16-bit processor. It offers instruction set 
  suited for execution of Forth language (see Table 1). To support 
  the tethered model, the CPU has special instruction (EXEC_PC) to 
  execute operator in the host part of the system. The CPU is 
  implemented according to the MISC (Minimal Instruction Set Architecture)
  paradigm - only the necessary instructions are supported, and more 
  complex actions are implemented as Forth words. CPU executes 
  instructions compiled and stored in the internal FPGA RAM memory.

Regardless of the CPU used in the target, it's going to be running code 
out of the "internal FPGA RAM memory". What prevents that code from 
being interactive in the case of the J1? I must be missing something.

[toc] | [prev] | [standalone]


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


csiph-web