On Tuesday, October 11, 2022 at 9:54:49 AM UTC-4, jpit...@gmail.com wrote:
> On Monday, 10 October 2022 at 16:52:33 UTC+1, gnuarm.del...@gmail.com wrote:
> > On Monday, October 10, 2022 at 11:19:41 AM UTC-4, jpit...@gmail.com wrote:
> > > On Monday, 10 October 2022 at 08:35:40 UTC+1, gnuarm.del...@gmail.com wrote:
> > > > On Monday, October 10, 2022 at 2:23:05 AM UTC-4, jpit...@gmail.com wrote:
> > > > > On Sunday, 9 October 2022 at 20:15:22 UTC+1, gnuarm.del...@gmail.com wrote:
> > > > > > On Sunday, October 9, 2022 at 1:54:54 PM UTC-4, jpit...@gmail.com wrote:
> > > > > > > On Sunday, 9 October 2022 at 18:51:06 UTC+1, gnuarm.del...@gmail.com wrote:
> > > > > > > > On Sunday, October 9, 2022 at 12:50:32 PM UTC-4, jpit...@gmail.com wrote:
> > > > > > > > > On Sunday, 9 October 2022 at 09:18:58 UTC+1, Jurgen Pitaske wrote:
> > > > > > > > > > On Sunday, 9 October 2022 at 07:37:50 UTC+1, johnro...@gmail.com wrote:
> > > > > > > > > > > On Wednesday, January 12, 2022 at 3:35:17 AM UTC-7, jpit...@gmail.com wrote:
> > > > > > > > > > > > On Wednesday, 12 January 2022 at 08:01:17 UTC, johnro...@gmail.com wrote:
> > > > > > > > > > > > > On Thursday, November 25, 2021 at 2:39:20 AM UTC-7, jpit...@gmail.com wrote:
> > > > > > > > > > > > > > On Thursday, 25 November 2021 at 07:06:47 UTC, johnro...@gmail.com wrote:
> > > > > > > > > > > > > > > \ Op Code File for MFX. Generated by MAKE-OPS v13
> > > > > > > > > > > The Logic Compiler is working and the modules for the processor are done and tested. After the mem interface module is complete we'll be ready to put the design into the fpga. We're using a X02-7000 but the design will work in any equivalent part.
> > > > > > > > > > > jrh
> > > > > > > > > > Looking forward to it.
> > > > > > > > > > Posting and distributing it in different places including facembbok should be easy.
> > > > > > > > > >
> > > > > > > > > > An idea crossed my mind:
> > > > > > > > > > Why not do a presentation during a FIG Zoom?
> > > > > > > > > > And this would help with where to post it.
> > > > > > > > > > http://www.forth.org/svfig/
> > > > > > > > > Just for people who might not know the context:
> > > > > > > > >
> > > > > > > > > Would it not be nice to use VHDL on an FPGA to write to it directly in Forth.
> > > > > > > > > See the link to Testra where it has been done already.
> > > > > > > > > http://testra.com/Forth/VHDL.htm
> > > > > > > > >
> > > > > > > > > And hopefully there is more soon from Testra posted here...
> > > > > > > > Sorry, I don't follow. What are you describing by, "use VHDL on an FPGA to write to it directly in Forth"?
> > > > > > > >
> > > > > > > > If you are talking about a stack CPU, written in VHDL, running on an FPGA, that has been done many, many times, some published, many not published. It would seem to be a trivial exercise.
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Rick C.
> > > > > > > >
> > > > > > > > --+ Get 1,000 miles of free Supercharging
> > > > > > > > --+ Tesla referral code - https://ts.la/richard11209
> > > > > > > You are proving again that you attention span is zero - or is it your reading capability?
> > > > > > >
> > > > > > > Designing logic with the Forth VHDL
> > > > > > >
> > > > > > > 1. Write a software simulation of the design.
> > > > > > > 2. Test the design.
> > > > > > > 3. Convert the software simulation into a hardware definition..
> > > > > > > 4. Compile the hardware definition into logic equations.
> > > > > > > 5. Fit the logic equations into the device.
> > > > > > > 6. Verify that the logic equations work correctly.
> > > > > > > 7. Route the signals and assign the I/O pins.
> > > > > > > 8. Convert the routed design into a fusemap.
> > > > > > "Forth VHDL"??? You are talking about a VHDL synthesis tool written in Forth??? No, that doesn't fit the description of what is going on. In fact, your description doesn't seem to relate to VHDL at all.
> > > > > >
> > > > > > I can't tell what you are talking about from this description,
> > > > > > but it sounds like it is for CPLDs, rather than FPGAs.
> > > > > Maybe we are hitting a language barrier.
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Rick C.
> > > > > >
> > > > > > -+- Get 1,000 miles of free Supercharging
> > > > > > -+- Tesla referral code - https://ts.la/richard11209
> > > > > The linfo at Testra clearly states:
> > > > >
> > > > > Using Forth as a VHDL ( Virtual Hardware Definition Language )
> > > > > John R. Hart, Testra Corporation
> > > > Ah, so he's bastardizing the term VHDL. That's normally used as the name of a language for programming digital logic (VHSIC Hardware Description Language).
> > > > > They used it on a CPLD first, and on a Lattice FPGA 7k now.
> > > > > Hugh Aguilar was involved there.
> > > > >
> > > > > And with all of the knowledge and experience here or elsewhere
> > > > > it could probably be ported to
> > > > > other FPGA families.
> > > > >
> > > > > You have all of the advantages of Forth,
> > > > > and no need for the overhead of FPGA tools as I understand.
> > > > It's not quite that simple. To target an FPGA device, you have to know the bitstream format. The vendors don't typically provide that information. Some people have reverse engineered a very few of the Lattice parts. I was not aware that the X02-7000 had been reverse engineered, but it's possible. Figuring out the bit map for other devices is not at all simple. It's tons of work.
> > > > > I am surprised this has not been of interest for the last many years,
> > > > > as the info on the Testra website was always there.
> > > > Open source tools have been of interest and exist. But not for many parts, for the reasons I've explained.
> > > > > But now we hopefully get the opportunity to see a full example.
> > > > "Full example"???
> > > >
> > > > It's a tool of little value in the FPGA world. Homebrew amateurs may find it interesting, but the FPGA world will simply yawn.
> > > >
> > > > I don't know how accurate your list of steps in using the tool is, but it sounds to me like a lot more work than the use of typical FPGA tools.. Here's the steps required for designing FPGAs.
> > > >
> > > > 1. Write the design in VHDL or Verilog
> > > > 2. Write a test bench for the simulation stimulus and error checking.
> > > > 3. Simulate the design using conventional simulators.
> > > > 4. Synthesize the design for the target chip.
> > > > 5. Test on the target board.
> > > >
> > > > Done. The only "writing" of code is the design and the test bench for simulation. Everything else is a working tool.
> > > >
> > > > --
> > > >
> > > > Rick C.
> > > >
> > > > -++ Get 1,000 miles of free Supercharging
> > > > -++ Tesla referral code - https://ts.la/richard11209
> > > I am sorry, but your post does not make sense to me.
> > >
> > > Testra use this setup for many years in their products
> > > and it must make sense there,
> > > otherwise they would just use the standard Lattice tools.
> > >
> > > If it is not relevant to you - fine - I never asked you.
> > > Just like asking an experienced C programmer - why not Forth ...
> > LOL Yes, if one guy working in a corner of the room is using it, then it must be not only good, but GREAT!
> >
> > The millions of users of VHDL and Verilog must have it wrong.
> >
> > One of my early jobs involved designing a microprogrammed DMA controller using an off the shelf sequencer chip. The other, similar designs in the company all used the same assembler tool. I added a few macros and opcodes, in order to give my design additional self-test capabilities. One of the managers said that was a bad idea because no one else would know how to use this "different" tool. I realized that there are many times when standardization is preferred over technical advantages, because technical advantages are of no use if they make the design hard to work with or modify.
> >
> > In this case, there is no real utility to this "special" design process and it actually appears to be much more complex and difficult to use.
> >
> > Thank you for the information.
> >
> > --
> >
> > Rick C.
> >
> > +-- Get 1,000 miles of free Supercharging
> > +-- Tesla referral code - https://ts.la/richard11209
> It seems there are others working in the corner that are interested in this subject,
> see about 46.00 onwards, e.g. gelforth
> https://www.youtube.com/watch?v=ASgBoKisWac

"Others"??? You mean "other", I think.

Trying to use Forth as the language to compose logic is solving a problem that doesn't exist. We have Verilog and VHDL as the mainstream languages for logic hardware design and they work well. There are efforts to use C for hardware logic design, which is seldom used. The main justification for using C is to have a common language for hardware and software, so the dividing line is easily moved, allowing one system design to be implemented in different ways with different performance levels. In reality, this is not at all simple to do. Hardware and software require interfaces. When you change the dividing line in the code for that interface and you have to redesign everything about that interface. So it is seldom used this way.

I stand by my statement that using Forth for both software and hardware design is of little value. The fact that you found one guy, who, six years ago, worked on using Forth as a hardware description language, does not mean it is a good idea. If that were true, why has nothing happened with it in the last six years?

People like to think that applying Forth to a problem, will make that problem simple to solve. Digital hardware logic design is not a simple task, not because of the tools used. The tools are complicated because the problem is complicated. The existing tools have simplified the work by hiding the complexity as much as possible. This works 99.9% of the time, allowing work to proceed with reasonable speed and accuracy. I can't see where Forth is going to help this at all.

--

Rick C.

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