So now we are learning about JTAG.
I know that the Propeller Parallax used Forth for testing.
Do I need JTAG if I have a Forth cpu on the device?
Do I need JTAG to debug the Forth CPU?
What do I need to be able to single step a Forth CPU, an debug a program.
Sorry to bother, I have a lot to learn.
Thank you.
Chris

On Thursday, April 20, 2023 at 3:37:54 PM UTC-4, Christopher Lozinski wrote:
> So now we are learning about JTAG.
> I know that the Propeller Parallax used Forth for testing.
> Do I need JTAG if I have a Forth cpu on the device?
> Do I need JTAG to debug the Forth CPU?
> What do I need to be able to single step a Forth CPU, an debug a program.
> Sorry to bother, I have a lot to learn.
> Thank you.
> Chris

Single stepping a Forth program has got to be one of the least effective ways to debug. Most people use REPL, meaning Read, Evaluate, Print Loop. Load the code, execute it and evaluate the results. Do this for every word, as you write it, and you will eliminate most bugs as you write. This presents many fewer bugs as you assemble the pieces of code into larger constructs, which you still debug with REPL.

I have not used a JTAG tool to debug anything in Forth, ever.

BTW, there are no Forth CPUs. When people use the term "Forth CPU", they mean either, a traditional register based CPU running a Forth interpreter/compiler, or a stack processor running a Forth interpreter/compiler. What do you mean by "Forth CPU". To the best of my knowledge, there are no actual Forth CPUs in common use.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Lorum Ipsum wrote
> there are no actual Forth CPUs in common use.

Correct. When I say Forth CPU, I mean a stack machine with multiple Forth words as primitives. Something like
the microcore, which has little usage, or Ting's EP 16/24/32 or the J1 and J1a. All barely in use.

After sleeping on it, I think that the way to use jtAG is as a test harness.. I can literally watch everything going on in a cpu, display it on a screen, or better yet, compare it to a simulation, to see where a misstep occurs.

Of course FPGA development takes much longer than software development, you cannot see what is going on inside of the chip. But if you attach a test harness, to be able to watch every thing that is going on, then it should be quite fast to develop and debug. The J1 is ony about 500 lines of code. The Ting ep16 is 2500 lines of code, if I have full visibility on what is going on, should be quite fast to test and debug.

Of course for production, I need to remove the test harness. I will then increase the clock speed, and when a bug arises, I will have no idea what the problem is, and fixing it will be very very slow. But that will only be a few timing bugs. Most will get caught with the test harness.

Am I on the right track?
Chris

On Friday, April 21, 2023 at 1:22:16 AM UTC-4, Christopher Lozinski wrote:
> Lorum Ipsum wrote
> > there are no actual Forth CPUs in common use.
> Correct. When I say Forth CPU, I mean a stack machine with multiple Forth words as primitives. Something like
> the microcore, which has little usage, or Ting's EP 16/24/32 or the J1 and J1a. All barely in use.

Much better to call a rose, a rose. If you mean a stack CPU, say stack CPU, so we know exactly what you mean. Not like Humpty Dumpty who said, a word "means just what I choose it to mean — neither more nor less."

> After sleeping on it, I think that the way to use jtAG is as a test harness. I can literally watch everything going on in a cpu, display it on a screen, or better yet, compare it to a simulation, to see where a misstep occurs.

Yeah, this will take a lot of work. The "JTAG" interface will have to breakpoint on every instruction executed, and save context, which means all registers, all memory, etc. This will run at a snail's pace and make real time emulation impossible.

Why are you so insistent on catching all this data, rather than just debugging your code, a word at a time like most people debug Forth. Have you done much programming in Forth? Lots of people program Forth on PCs and use no such debugger. They debug the words, by testing them with specific inputs, and verifying the outputs. Words are typically written to be small enough to readily debug this way.

> Of course FPGA development takes much longer than software development, you cannot see what is going on inside of the chip.

I don't care to see what is going on inside the chip. By the time my design is loaded onto a chip, 99.9% of the bugs are gone, as shown in simulation.. It is rare that I need to examine internal processes. When I do, I use a debug port and an real, live, logic analyzer. But that's very exceptional.

> But if you attach a test harness, to be able to watch every thing that is going on, then it should be quite fast to develop and debug. The J1 is ony about 500 lines of code. The Ting ep16 is 2500 lines of code, if I have full visibility on what is going on, should be quite fast to test and debug.

If you use someone else's code that is already debugged, why do you need such tools? Are you planning extensive mods? Why can't you debug in simulation? Simulating HDL is not like other software. The simulation does not leave much untested. If you code works in simulation, but is different in the chip, you have done something very wrong in your coding style. The fix for this is to repair your coding style.

> Of course for production, I need to remove the test harness. I will then increase the clock speed, and when a bug arises, I will have no idea what the problem is, and fixing it will be very very slow. But that will only be a few timing bugs. Most will get caught with the test harness.

Timing bugs? Do you mean at the hardware level? That should not happen. HDL to FPGA tools have timing analysis tools that can check as much of the design as you wish. There is no reason for a timing error to ever reach production, even without testing on a chip.

> Am I on the right track?
> Chris

I think no. I just checked, and you are the software guy who had not designed hardware, but wants to work on advanced CPU designs. I believe you are also not an experienced Forth programmer, no? I think you will do best by learning how others write Forth programs and debug them, as well as how others design HDL and debug that.

There's no reason to reinvent the wheel.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Lorum Ipsum wrote:
> By the time my design is loaded onto a chip, 99.9% of the bugs are gone, as shown in simulation. It is rare that I need to examine internal processes. When I do, I use a debug port and an real, live, logic analyzer.

Thank you. That is what i needed to know. What I had been told earlier is that it is very difficult to debug FPGA applications.

My worry was not about debugging the Forth, that part is comparatively easy. Use an existing Forth, or write a test case for each word. My worry was about debugging the CPU.

You are correct, I am new to both FPGA's and Forth.
My FPGA experience is growing rapidly.

>Logic Analyzer.
Thank you. One more thing to learn about!

Back to doing my homework.
Chris

On Saturday, April 22, 2023 at 1:26:38 AM UTC-4, Christopher Lozinski wrote:
> Lorum Ipsum wrote:
> > By the time my design is loaded onto a chip, 99.9% of the bugs are gone, as shown in simulation. It is rare that I need to examine internal processes. When I do, I use a debug port and an real, live, logic analyzer.
> Thank you. That is what i needed to know. What I had been told earlier is that it is very difficult to debug FPGA applications.

It is very difficult for people who do things in complicated ways, to debug FPGA applications.

The Forth method of writing small modules and debugging each one separately before combining with the others, is very useful and effective, not to mention efficient. But it is hard to apply in an HDL, because of the work involved in creating a module. In Forth, the extra work is mostly writing the stack effect comment ( a -- b). In Verilog, it is much more verbose and in VHDL they don't even use the term verbosity, because it's off the scale.

Still, it is useful to create a test bench for each module, even if it's a fair amount of work. This has been studied and measured. They found that every level earlier that a bug is found, it saves about 10x the work of finding it in the next stage. At system integration, it can be thousands of times more work to find a bug, than if it is caught in unit test. This is absolutely true for FPGA work. So create all the bugs you want, but find them early and often.

> My worry was not about debugging the Forth, that part is comparatively easy. Use an existing Forth, or write a test case for each word. My worry was about debugging the CPU.

All the same principles apply. Code your CPU in small pieces, and test each one thoroughly before integrating it with any others.

> You are correct, I am new to both FPGA's and Forth.
> My FPGA experience is growing rapidly.
>
> >Logic Analyzer.
> Thank you. One more thing to learn about!

But you are not likely to need it. If you find a bug in your stack processor, you can likely figure it out to a given instruction that isn't working correctly, or at least a section of code. Then you can run that section of code in the HDL simulation and see everything you wish. If it works in simulation, but fails in the chip, try slowing the clock 10x. If it runs then, your timing constraints are in error.

Timing constraints are vital to an FPGA design working correctly, but there is no way to debug them. The best you can do is to get a measurement of coverage, the percentage of the chip that the timing constraints apply to. To get this to 100%, requires adding constraints to parts of the design that you don't care about, such as the global reset signal. There is no way to constrain this usefully, unless your clock is very slow, but it is counted in the coverage number, so give it a constraint, of 1 second. Timing constraints are useful, but hard to verify.

You might try talking about the FPGA stuff in comp.arch.fpga. You will get some competing opinions, from people who like to use the fancy tools, such as the tool based logic analyzers.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

In article <36ab25dc-4188-4bfc-a5d8-12d2b3941accn@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
>On Saturday, April 22, 2023 at 1:26:38 AM UTC-4, Christopher Lozinski wrote:
>> Lorum Ipsum wrote:
>> > By the time my design is loaded onto a chip, 99.9% of the bugs are
>gone, as shown in simulation. It is rare that I need to examine internal
>processes. When I do, I use a debug port and an real, live, logic
>analyzer.
>> Thank you. That is what i needed to know. What I had been told earlier
>is that it is very difficult to debug FPGA applications.
>
>It is very difficult for people who do things in complicated ways, to
>debug FPGA applications.
>
>The Forth method of writing small modules and debugging each one
>separately before combining with the others, is very useful and
>effective, not to mention efficient. But it is hard to apply in an HDL,
>because of the work involved in creating a module. In Forth, the extra
>work is mostly writing the stack effect comment ( a -- b). In Verilog,
>it is much more verbose and in VHDL they don't even use the term
>verbosity, because it's off the scale.
>
>Still, it is useful to create a test bench for each module, even if it's
>a fair amount of work. This has been studied and measured. They found
>that every level earlier that a bug is found, it saves about 10x the
>work of finding it in the next stage. At system integration, it can be
>thousands of times more work to find a bug, than if it is caught in unit
>test. This is absolutely true for FPGA work. So create all the bugs
>you want, but find them early and often.

In general the more work testing a module is, the more useful is
desk checking. This is the art of studying your code carefully,
and simulating in your mind what has to be happening.
I tend to add to this a careful, almost legal, description of
each factor (Forth word). It has benefited me, but I am a lousy
programmer (really), I flunked the first assignment for numerical
analysis.

I seen some star FORTRAN programmers who did this, and then use
single stepping once, to verify if it agrees with the desk checking.
Other situation than Forth requires different techniques.

> Rick C.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Sunday, April 23, 2023 at 11:39:07 AM UTC+2, none albert wrote:
[..]
> In general the more work testing a module is, the more useful is
> desk checking. This is the art of studying your code carefully,
> and simulating in your mind what has to be happening.

I have been trying to do that for 40 years now, and I still can't
get it right. Most of my bugs are caused by being 100%
convinced that something works like "a", while actually it is
"b". (`5 1 do .. loop` exits after 5 iterations .., this word prints
a space after the output, ...).
Quite early on, I decided that it was more productive
to 'prototype' small parts of my code. For that it is
needed that they are not depending on global data,
and that scaffolding is inexpensive. It is also important
that the parts are not so small that the final assembly
becomes inscrutable because there are too many parts (here
it clashes with the `factor, factor` paradigm of Forth). When
this goes right, the work is in refining the assembly of small
components so that they produce the optimal result.
Unfortunately, this way of working does not align well with
working in teams.

> I tend to add to this a careful, almost legal, description of
> each factor (Forth word). It has benefited me, [..]

I add the legalese after it works, because I know that I won't
follow the rules when I spot a possible improvement or
simplification.
> I seen some star FORTRAN programmers who did this, and then use
> single stepping once, to verify if it agrees with the desk checking.
> Other situation than Forth requires different techniques.

Well, if the specification is very precise and one has no self-interest
in the result, I guess this can work.

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>Quite early on, I decided that it was more productive
>to 'prototype' small parts of my code. For that it is
>needed that they are not depending on global data,
>and that scaffolding is inexpensive. It is also important
>that the parts are not so small that the final assembly
>becomes inscrutable because there are too many parts (here
>it clashes with the `factor, factor` paradigm of Forth).

I don't see a problem. You don't have parts at just one level. Small
parts are assembled to bigger parts. If you try to assemble the
bigger parts just from primitives, the big part may become excessively
complex, and it may be better to compartmentalize this complexity into
smaller parts.

That being said, code that provides a lot of flexibility by factoring
and deferred words is often harder to follow than more
straightforward, but inflexible code. But that's not limited to
Forth.

>When
>this goes right, the work is in refining the assembly of small
>components so that they produce the optimal result.
>Unfortunately, this way of working does not align well with
>working in teams.

I don't think that's the case. If the components have a good
interface, the implementor of a component can work independently of
the user of the component. (I don't think that this independence
means lack of teamwork for you, does it?)

Admittedly, finding a good interface is hard and often takes several
attempts.

The data stack is such an interface: there have been repeated
discussions of adding registers, but they have never really taken off,
and here we are, 50+ years after the inception of Forth, still passing
data on the stack. And the implementors of a Forth system can add a
word that the users of the Forth system can use, and that other Forth
system implementors can implement, because we have this interface.

If we used registers for interfacing instead, either a lot of the
first implementation would be exposed accidentially in the interface,
or we would have to follow a calling convention like is used for
register machines, with saving some registers at the caller, some at
the callee, and passing the parameters and return values in specific
registers.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

Marcel Hendrix schrieb am Sonntag, 23. April 2023 um 14:31:28 UTC+2:
> On Sunday, April 23, 2023 at 11:39:07 AM UTC+2, none albert wrote:
> [..]
> > In general the more work testing a module is, the more useful is
> > desk checking. This is the art of studying your code carefully,
> > and simulating in your mind what has to be happening.
> I have been trying to do that for 40 years now, and I still can't
> get it right. Most of my bugs are caused by being 100%
> convinced that something works like "a", while actually it is
> "b". (`5 1 do .. loop` exits after 5 iterations .., this word prints
> a space after the output, ...).
> Quite early on, I decided that it was more productive
> to 'prototype' small parts of my code. For that it is
> needed that they are not depending on global data,
> and that scaffolding is inexpensive. It is also important
> that the parts are not so small that the final assembly
> becomes inscrutable because there are too many parts (here
> it clashes with the `factor, factor` paradigm of Forth). When
> this goes right, the work is in refining the assembly of small
> components so that they produce the optimal result.
> Unfortunately, this way of working does not align well with
> working in teams.
> > I tend to add to this a careful, almost legal, description of
> > each factor (Forth word). It has benefited me, [..]
>
> I add the legalese after it works, because I know that I won't
> follow the rules when I spot a possible improvement or
> simplification.
> > I seen some star FORTRAN programmers who did this, and then use
> > single stepping once, to verify if it agrees with the desk checking.
> > Other situation than Forth requires different techniques.
> Well, if the specification is very precise and one has no self-interest
> in the result, I guess this can work.
I have a 'release' and 'debug' version of my system. The debug version
comprises runtime stack checking (with a special catch-throw mechanism
not present in the release version), T{ -- }T built in, stepping debugger, etc.
The release version generates no such code.

Developing, my factored code looks about like:

: FACTOR1 < some code > ; INLINE
T{ <testcase> }T
T{ <testcase> }T

: _FACTOR2 < some code > ; \ INLINE
T{ <testcase> }T
T{ <testcase> }T
...

: NEWWORD ... factorx ... factory ... factorz ... ;
T{ <testcase> }T
T{ <testcase> }T

Compiled with release flag, factors are inlined (when marked) and all
T{ -- }T are ignored (treated as comments). Headers of inlined words
and with names beginning with an _underscore are deleted from the dictionary.

After decades of coding this works best for me. It requires a bit more
discipline than just hacking away, but it brings:
- while writing the test cases I concentrate more on the algorithm
and often detect subtle program logic flaws
- if I find/invent a new idea for program optimization, the test cases are
already there, which helps a lot!

Although this looks like more work it is less, because otherwise one
would have to do the tests (repeatedly) on the command line afterwards.

In article <9921d2e3-6855-4246-9312-70470df98102n@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
>Marcel Hendrix schrieb am Sonntag, 23. April 2023 um 14:31:28 UTC+2:
>> On Sunday, April 23, 2023 at 11:39:07 AM UTC+2, none albert wrote:
>> [..]
>> > In general the more work testing a module is, the more useful is
>> > desk checking. This is the art of studying your code carefully,
>> > and simulating in your mind what has to be happening.
>> I have been trying to do that for 40 years now, and I still can't
>> get it right. Most of my bugs are caused by being 100%
>> convinced that something works like "a", while actually it is
>> "b". (`5 1 do .. loop` exits after 5 iterations .., this word prints
>> a space after the output, ...).
>> Quite early on, I decided that it was more productive
>> to 'prototype' small parts of my code. For that it is
>> needed that they are not depending on global data,
>> and that scaffolding is inexpensive. It is also important
>> that the parts are not so small that the final assembly
>> becomes inscrutable because there are too many parts (here
>> it clashes with the `factor, factor` paradigm of Forth). When
>> this goes right, the work is in refining the assembly of small
>> components so that they produce the optimal result.
>> Unfortunately, this way of working does not align well with
>> working in teams.
>> > I tend to add to this a careful, almost legal, description of
>> > each factor (Forth word). It has benefited me, [..]
>>
>> I add the legalese after it works, because I know that I won't
>> follow the rules when I spot a possible improvement or
>> simplification.
>> > I seen some star FORTRAN programmers who did this, and then use
>> > single stepping once, to verify if it agrees with the desk checking.
>> > Other situation than Forth requires different techniques.
>> Well, if the specification is very precise and one has no self-interest
>> in the result, I guess this can work.
>
>I have a 'release' and 'debug' version of my system. The debug version
>comprises runtime stack checking (with a special catch-throw mechanism
>not present in the release version), T{ -- }T built in, stepping debugger, etc.
>The release version generates no such code.
>
>Developing, my factored code looks about like:
>
>: FACTOR1 < some code > ; INLINE
>T{ <testcase> }T
>T{ <testcase> }T
>
>: _FACTOR2 < some code > ; \ INLINE
>T{ <testcase> }T
>T{ <testcase> }T
>..
>
>: NEWWORD ... factorx ... factory ... factorz ... ;
>T{ <testcase> }T
>T{ <testcase> }T
>
>Compiled with release flag, factors are inlined (when marked) and all
>T{ -- }T are ignored (treated as comments). Headers of inlined words
>and with names beginning with an _underscore are deleted from the dictionary.
>
>After decades of coding this works best for me. It requires a bit more
>discipline than just hacking away, but it brings:
>- while writing the test cases I concentrate more on the algorithm
>and often detect subtle program logic flaws
>- if I find/invent a new idea for program optimization, the test cases are
>already there, which helps a lot!
>
>Although this looks like more work it is less, because otherwise one
>would have to do the tests (repeatedly) on the command line afterwards.

That is similar to my REGRESS system
REGRESS 1 2 + S: 3

Production ciforth code is mostly an executable.
lina -c
automatically revectors REGRESS to be a stack comment.

The more involved a system is, the more it pays off.
The optimiser of ciforth has 590 REGRESS lines.
Refactoring so complicated a system is nerve wrecking unless you have
such a mechanism in place.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 25/04/2023 09:17, minforth wrote:
> Marcel Hendrix schrieb am Sonntag, 23. April 2023 um 14:31:28 UTC+2:
>> On Sunday, April 23, 2023 at 11:39:07 AM UTC+2, none albert wrote:
>> [..]
>>> In general the more work testing a module is, the more useful is
>>> desk checking. This is the art of studying your code carefully,
>>> and simulating in your mind what has to be happening.
>> I have been trying to do that for 40 years now, and I still can't
>> get it right. Most of my bugs are caused by being 100%
>> convinced that something works like "a", while actually it is
>> "b". (`5 1 do .. loop` exits after 5 iterations .., this word prints
>> a space after the output, ...).
>> Quite early on, I decided that it was more productive
>> to 'prototype' small parts of my code. For that it is
>> needed that they are not depending on global data,
>> and that scaffolding is inexpensive. It is also important
>> that the parts are not so small that the final assembly
>> becomes inscrutable because there are too many parts (here
>> it clashes with the `factor, factor` paradigm of Forth). When
>> this goes right, the work is in refining the assembly of small
>> components so that they produce the optimal result.
>> Unfortunately, this way of working does not align well with
>> working in teams.
>>> I tend to add to this a careful, almost legal, description of
>>> each factor (Forth word). It has benefited me, [..]
>>
>> I add the legalese after it works, because I know that I won't
>> follow the rules when I spot a possible improvement or
>> simplification.
>>> I seen some star FORTRAN programmers who did this, and then use
>>> single stepping once, to verify if it agrees with the desk checking.
>>> Other situation than Forth requires different techniques.
>> Well, if the specification is very precise and one has no self-interest
>> in the result, I guess this can work.
>
> I have a 'release' and 'debug' version of my system. The debug version
> comprises runtime stack checking (with a special catch-throw mechanism
> not present in the release version), T{ -- }T built in, stepping debugger, etc.
> The release version generates no such code.
>
> Developing, my factored code looks about like:
>
> : FACTOR1 < some code > ; INLINE
> T{ <testcase> }T
> T{ <testcase> }T
>
> : _FACTOR2 < some code > ; \ INLINE
> T{ <testcase> }T
> T{ <testcase> }T
> ..
>
> : NEWWORD ... factorx ... factory ... factorz ... ;
> T{ <testcase> }T
> T{ <testcase> }T
>
> Compiled with release flag, factors are inlined (when marked) and all
> T{ -- }T are ignored (treated as comments). Headers of inlined words
> and with names beginning with an _underscore are deleted from the dictionary.
>
> After decades of coding this works best for me. It requires a bit more
> discipline than just hacking away, but it brings:
> - while writing the test cases I concentrate more on the algorithm
> and often detect subtle program logic flaws
> - if I find/invent a new idea for program optimization, the test cases are
> already there, which helps a lot!
>
> Although this looks like more work it is less, because otherwise one
> would have to do the tests (repeatedly) on the command line afterwards.

I too write test cases as I develop software for the same reasons.
However I find it more convenient to put the tests in a separate file
for two reasons. Firstly I have a set of test helper definitions that
are commonly used and secondly I sometimes need to build test data
structures. I don't want these to clutter the source code of the
application/tool.

--
Gerry