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
there are no actual Forth CPUs in common use.
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 isgoing 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 willget caught with the test harness.
Am I on the right track?
Chris
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.
Logic Analyzer.Thank you. One more thing to learn about!
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!
On Saturday, April 22, 2023 at 1:26:38 AM UTC-4, Christopher Lozinski wrote: >> Lorum Ipsum wrote:
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, logicBy the time my design is loaded onto a chip, 99.9% of the bugs are
analyzer.
Thank you. That is what i needed to know. What I had been told earlieris 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.
Rick C.
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, [..]
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.
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.
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 isI have been trying to do that for 40 years now, and I still can't
desk checking. This is the art of studying your code carefully,
and simulating in your mind what has to be happening.
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 useWell, if the specification is very precise and one has no self-interest
single stepping once, to verify if it agrees with the desk checking.
Other situation than Forth requires different techniques.
in the result, I guess this can work.
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 isI have been trying to do that for 40 years now, and I still can't
desk checking. This is the art of studying your code carefully,
and simulating in your mind what has to be happening.
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 useWell, if the specification is very precise and one has no self-interest
single stepping once, to verify if it agrees with the desk checking.
Other situation than Forth requires different techniques.
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.
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 isI have been trying to do that for 40 years now, and I still can't
desk checking. This is the art of studying your code carefully,
and simulating in your mind what has to be happening.
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 useWell, if the specification is very precise and one has no self-interest
single stepping once, to verify if it agrees with the desk checking.
Other situation than Forth requires different techniques.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 41:02:46 |
Calls: | 6,708 |
Calls today: | 1 |
Files: | 12,243 |
Messages: | 5,353,786 |