+++++++++
FPGA devices didn't arrive today (which is what was promised)
DHL called and wanted clarification on my 'company name' that I was a private individual.
So it seems putting one's own name in that data field on your order is important. Giving a fake name may just lead to a long-winded discussion with your local customs about not properly registering a business name with Customs.
Also, the delivery truck driver might just be driving around looking for a company sign in a residential district.
Nope, but I appended my last name with 'Company' in the business field of Arrow Electronics required field and it seems their shipping documents and invoice omitted my full name.
As a result, Taiwan Customs went looking for an 'unregistered enterprise' and I have had to explain it was just an individual purchase. I am a bit more wary of these issues as I am not a citizen of Taiwan and here on a permanent residency visa. Even though I have an 'open work permit' that allows me to start my own business or work for anyone, I really don't want to get into all the Taiwanese business regulations.
Heater protested my suggestion to put your own name in this field, but it now becomes clear to me that my preference for using my own name really works best. People do fabricate names all the time to get free samples which is something I don't pursue. But they don't realize that all sorts of local and national governments are searching to verify unlicensed business.
++++++++++++++++++ VHDL versus Verilog
Actually, the non-delivery has given me more time to ponder what to do upon arrival.
Due to the Parallax code being mainly offered in Verilog, the fact that the eP16 code is all VHDL initially put me into a tailspin. But a bit of research has shown that Quartus II may actually be able to convert VHDL code to Verilog code for you.
Since my hopes are to combine Propeller 1V and eP16 code together, I really need that conversion. And if Quartus II doesn't do an adequate job, there are other VHDL to Verilog converters available.
So I am a bit relieved. I may not even have to learn VHDL if the converter does an adequate job. Verilog to VHDL may be more difficult as VHDL has more choices rather than less. There is available software to do that as well.
Heater protested my suggestion to put your own name in this field, but it now becomes clear to me that my preference for using my own name really works best.
Err...no, I did not.
That comment was all about filling in forms and registering for some web sites in order to get a download. Altera in that particular case.Where entering any fake information is the norm if the fields are required. Anyway your entering your name as a company when you are not is mis-representation is it not?
I would not suggest putting fake information on purchase orders, actual commercial transactions, like your order from Arrow. Especially not when customs, duties, import/expert regulations are involved.
Just now I have imported 20 radar units from Germany into the USA. It's a big enough hassle when you get all the details correct. Being RF transmitters there is also the FCC approval to deal with. Grrr...
Arrow Electronics had the 'required' company field as well as Altera.
My own feelings are that everyone has been asking for too much information, and sharing it with unknown persons or authorities. I am happy to the new Parallax Forums eliminated a lot of features that could be attractive to people wanting to do identity theft. Birthday registration, etc.
But it does get tricky when one decides to not offer info or to offer misleading info.
One kind of answer for downloading software, another answer for importing electronics, and definitely a third is one's government is asking the question.
While I often leave data fields blank if I am allowed to do so, the U.S. government occasionally demands info from me for tax and such. Not answering is not an option, and lies to the Federal government or its representative is a crime-- maybe a felony.
Meanwhile, law in Taiwan is not available in English -- so I really do try not to get caught up with it.
++++++++++
More about eP16.zip
I have been spending the day trying to figure out how I might compile the eP16 VHDL files for eForth and the presentation seems somewhat straight forward. There are a group of 5 related VHDL files with the eP16_chip.vdh file being the top one. The tutorial does a good job of explain which ones are useful and how to use -- but it is all for Xilinx, not Altera and a smaller FPGA
I just have to get Quartus II completely working and create a project with the files migrated into them to attempt a compile for either the BeMicro CV or the CVA9. I then hope that will lead to figuring out how to also convert the VHDL to Verilog so that I may combine the CPU and Forth resources with a Propeller architecture.
Quartus II V15.0.2 (that 2 is for Update 2) is confirmed as installed on my Debian 8.1.
But I read something about having to get it added to the PATH in the environment. And while it starts and appears to run correctly, I am getting a Warning in the Terminal window when I start that one module of software can't be found.
The missing module appears to be included in the iceweasle-dev package. But my first attempt to install then went haywire and I had to back out.. (Debian 8.1 wanted me to load from DVD rather than repository, but won't recognize the DVD)
So I first have to clear my Quartus II and see if that warning remains or even matters.
Meanwhile, the ep16.zip includes a version of the same Forth engine as a VM with support in software compiled for Windows under the executable called WeForth.exe and there is a rather long discussion about first familiarizing one's self with that before working in the FPGA.
Apparently the eP32_chip.vdhl file is for reference only as the text mentions that it was written first and the eP16 came later. So one still has to locate a complete set of eP32 files in VDHL to file a 32 bit scheme. And C. H. Ting mentions there are actually 16 bit, 24 bit, and 32 bit FPGA images.
Early on, the J1 16 bit Forth Verilog code was mentioned as a possible Forth core. That seems attractive because all the instructions are one clock cycle, or so it claims. But the eP16 and eP32 seem to have also achieved the same goal of one clock cycle execution. For now, there isn't much reason to look at anything other than the eP16 and eP32 Forths to eventually meld with a Propeller-like architecture.
++++++++++
Not much to continue comparing. It seems to now be time to get deeply into the set of files I have for eP16 Forth and Propeller IV.
Also, I should soon take a good look at what the WeForth.exe really does and read along in the tutorial.
++++++++++
I believe that when I downloaded the Chinese eP32 tutorial, the VHDL files for the 32bit example were all included. But I have to confirm that I actually did acquire those. This is very much a bi-lingual project. The VHDL is all in English code with Chinese notes. But the text appears to be a clone of the eP16 tutorial.
While Quartus II 15.0.2 is installed. I have discovered two issues that need to be resolved in the Debian 8.1 Jessie amd64 OS. I am posting all the details in the Quartus II V15 installation thread. And it just may be that my problems are specific to Debian 8.1 Jessie amd64. Other Linux distribution may install more easily.
1. I had to set up active repositories, acquirre libcanberra-gtk3-module and install it. The initial start up suddenly changed from a long wait to a near instant start.
2. D-Bus is not properly configured. I do have an active dbus-daemon and dbus-launch, but
Quartus II can't locate it. I suspect this relates to something that was mentioned about configuring a path for something. I can't find the Altera publication that I read that in.
STATUS -- It seems that I can't do anything with the eP16 VHDL files until Quartus is right.
Sure, I can ready the manual, but that is thousands of pages. So, I am seeking some short cuts.
Loopy,
"Arrow Electronics had the 'required' company field as well as Altera."
No doubt.
Entering into a transaction with money changing hands and all kind of repercussions regarding shipping, import/export controls, customs duties, VAT, etc is a very different thing than signing up for a free software download.
Actually I have never understood this mode of operation of companies like Altera. Why not give us a download button and be done with it? Don't they realize that the random anonymous geek that downloads their software today may well become a big customer of their devices in the future when he gets his creation off the ground? Surely it's in their interest to make that process as frictionless as possible?
I registered my 'business name' as an educator, which I am. I have decades of Taiwan and US tax returns declaring myself a business for private teaching. That explains the obvious smallness of the business and the lack of plans to bring a product to market -- but they still welcome teachers because they create some eventual demand for the product.
At least that is the rationale.
We do have several private schools that teach FPGA programing in Taiwan. Engineers do want help with sorting out all that English documentation. FPGAs just keep getting cheaper and cheaper. And there is nothing wrong with being a solo private teacher of FPGA use.
On the one hand, I prefer not to lie; on the other hand, my use isn't likely to directly create sales.
Nobody can survive in business on giving free samples to people that just want free samples. At least I have purchased the FPGA development boards and can help others to learn. I doubt if I will ever completely retire from the English teaching. It is fun and interesting.
Loopy,
I'm sure you are right about the free samples.
I snagged some free samples of AVR and PIC back in the day. Presumably such companies are savvy enough to assess when and how much it is a good idea to do that.
Eventually I decided it was not a good idea for me as a hobbyist or even potential small time business. What if I develop a great project around a free sample of a device that ends up not being easily available to every one else or even myself in the future? What if that device does not take off and gets canned?
All in all it's better to stick with mainstream easily available devices. Rather than chasing the cutting edge.
New hope....
I am going to run some simple test project in VHDL and Verilog to see what my current Quartus II installation does. Then I may uninstall everything and start over.
Meanwhile, it certainly seems the Xilinx FPGA scheme for VHDL ram memory in eP16 is going to need to be revised to work with the BeMicroCV.
And so, I just keep going back and forth.... some progress is occurring, but requires effort and thought
And, there ain't no such thing as a free search engine either. These days I get more barrages of advertising that I ever got back in the day of physical junk mail. They all try to lock on to my cash in pocket.
Of course, there was a time when pretty girls handed out free introductory packages of Winston and Kool cigarettes on a downtown street corner in major US cites. But the idea was to push the nicotine addiction. Beware of strangers with gifts, even the pretty ones.
With Altera support -- Ones I found don't have support for Altera-Quartus MEMORY.
So it is not possible to compile clean eP16 system from them for Altera FPGA's
++++++++++
More about eP16.zip
I have been spending the day trying to figure out how I might compile the eP16 VHDL files for eForth and the presentation seems somewhat straight forward. There are a group of 5 related VHDL files with the eP16_chip.vdh file being the top one. The tutorial does a good job of explain which ones are useful and how to use -- but it is all for Xilinx, not Altera and a smaller FPGA
I just have to get Quartus II completely working and create a project with the files migrated into them to attempt a compile for either the BeMicro CV or the CVA9. I then hope that will lead to figuring out how to also convert the VHDL to Verilog so that I may combine the CPU and Forth resources with a Propeller architecture.
Loopy, is there a short summary of one of the Fpga forth implementations?
I thought I might just get the time to download and read on the plane home on Tuesday. Btw transiting taipai so i will give you a wave as I go by.
If You download this file <eP16.zip> -- It has very nice description on that implementation.
Loopy, is there a short summary of one of the Fpga forth implementations?
I thought I might just get the time to download and read on the plane home on Tuesday. Btw transiting taipai so i will give you a wave as I go by.
Saphina appears to have identified the crux of the matter.
eP16.zip has a pdf that explains that the Lattice Ram Memory is asynchronous and other FPGAs appear to ONLY provide synchronous RAM. So it will at least be necessary to rewrite the whole RAM_memory.vhdl in order to get this running on a BeMicro CV or other Altera product.
Additionally, the problem is that a synchronous memory solution may run significantly slower.... 50% slower.
It is all discussed in eP16inVHDL.pdf starting at section 5.3 RAM Memory Module page 76.
I hope someone can see a solution other than buying a Lattice product.
+++++++++++++
At this point, I still am having concerns with my Debian 8.1 Jessie amd64 installation of Quartus II V15.0.2.
So while I ponder what to do about the eP16 Ram Memory Module issue, I am going to work on improving and verifying my Quartus II installation.
To that end, I will attempt to compile the Propeller 1V for BeMicroCV and BeMicroCVA9 Verilog. And then attempt to load in those platforms. Others have succeeded in Windows and maybe other Linux installation, so it seems important that I verify my Quartus II is working as expected.
The problems in Linux are related to two facts -- Quartus II may not be trying to support the latest releases of Linus (they obvious do not desire to support Fedora 7 yet), and some of the software is 64bit while other parts are 32bit (so the installation has to deal with running both in harmony).
=============
For now, I am disappointed that eP16 may only run half as fast on an Altera FPGA solution -- if at all. But that would be better than nothing.
By the way....
C. H. Ting does have an eP32 VHDL installation on an Altera product. I believe it was a Stratix II FPGA.
I may have to purchase a CD from www.offete.com with code for that solution to get a clue as to how to resolve the RAM memory module. But I do have a hunch that the Stratix II FPGA might offer asynchronous RAM as well (Can anyone confirm?)
Thanks for the paper, Saphiena.
Deep down, I always expected their to be some difficulty with migrating code from Xilinix to Altera. And there was always the looming challenge of reconfiguring RAM on a single CPU Forth to a shared HUBram.
I am just a bit perplexed whether I can do asynchronous RAM in the Cyclone V. I simply require 64Kbits of 16bit RAM and appear to have lots of space and resources.
=================
A bit more progress.........
My goodies arrived from Arrow Electronics -- A BeMicroCV, a BeMicroCVA9, and a BESCOPE card. So I have actually hardware to proceed with.
+++++++++++
Rereading the eP16 Manual pdf,
it seems that C.H. Ting is primarily concerned with the memory being read on the leading clock edge versus the following clock edge. So I am going to focus on removing the entire existing RAM_memory.vhd file and attempt the creation of another tailored to the BeMicroCV.
If one read the eP16 manual, C. H. Ting used a Xilinx application to create the whole RAM Memory VHDL file, so it seems feasible to just replace it and patch whatever other code is tied into it.
################
Saphiena's paper is worth reading, but I am a bit wary of the need to pipeline instructions or deal with program counters when I don't quite know what the eP16 CPU requires. And the attachment of serial SRAM, such as an SDcard with its FAT16 are back-burnner issues to me right now.
In short, I just want to see if the eP16 is feasible on the BeMicroCV before I begin to seek out modifications and additions beyond what C.H. Ting envisions.
++++++++
As it is, I may have to take a couple of weeks getting up to speed with Quartus II V15.0.2 and fooling around with the Propeller 1V image on the BeMicroCV. There is a lot to learn about both VHDL and Verilog. So don't expect a lot from me in the immediate future.
Having drunk the FPGA Kool-Aide, I must admit that I pretty much jumped in with high hopes and little to no knowledge of what this might all involved.
My choice of the BeMicroCV and BeMicroCVA9 Development Kits was based on a strong bias toward emulation of the Propeller 1 and Propeller 2.
++++++++
So far, my reading on the eP16 has made it obvious that C. H. Ting investigated a wide variety of FPGAs for Forth and settled on the LatticeXP2 with the Diamond IDE as the best -- for his purposes, a Forth device.
Meanwhile Parallax is doing something entirely separate and different.
++++++++
I have begun to see that the conflicts between the two are not an easy entry point for the new FPGA learner. So it would likely be best for a Forth enthusiast to purchase the $49.00USD LatticeXP2 device, get a free download of Diamond IDE, and learn as much as possible from C. H. Ting before melding Forth and Propeller.
If fact I just may have to do that to get started.
In part, I see that the 'memory blocks' available on the LatticeXP2 are vast, while the same resources on the BeMicroCV and BeMicroCVA9 are relatively limited. That one difference in architecture forces a rather severe redesign for the Altera Cyclones (C. H. Ting did succeed on the much more expensive Altera Stratix devices as they have the right resources in adequate supply)
Saphiena provided a rather interesting article on Forth memory optimization that is yet another issue. Simply put, a Forth machine with only a 32bit data bus is awkward in a world where many storage devices and communication ports are 8bit devices.
To me, I just want to get the eForth concept working before I consider such additions or alternatives. But the issue is a very real one. It might just be best in the beginning to focus on all 8bit being handled serially.
++++++++
In any event, I am having to reinstall my Quartus II from scratch in light of new information. It is obvious I made a mess of that as well.
In Linux, Altera claims that one can simply remove the <home>./altera directory with its sub-directories and contents. But I also discovered another hidden directory, <home>/.altera-quartus and am removing that as well.
Then I will see what appears after installation. ArchLinux provided a rather
Well, the idea of combining Forth and the Propeller 1 architecture may be a punishing brainwave, but I am moving ahead. I just haven't seen how reporting all my frustrations while they are happening is helpful.
So, a progress report.
1. FedEx dropped off a new LatticeXP2-Brevia2 that will allow me to learn eP16 and eP32 in C. H. Ting's preferred platform before attempting to migrate to Altera CycloneV devices.
My thoughts about not having enough memory blocks in the Altera devices may have been premature. So issues may be just that I don't know how to use memory blocks to generate asynchronous RAM in the Altera Cyclone V..
2. Quartus II V15.0.2. has demonstrated that it can work in Debian 8.1 Jessie amd64. But I need to do more work on Debian to get 32bit programs to work in the 64bit environment.
Apparently Debian 7.xx wheezy went to multi-arch from ia32 support for 32bit applications in a 64bit environment and I have not set it up yet. Quartus II happens to run Both 32bit and 64bit applications under the IDE and the 32bit features are still missing for me.
+++++++++++
What's next?
Upgrading to Debian 8.1, shifting to amd64(64bit) from i368 (32bit), and learning how to install Quartus II V15.0.2, all at the same time, was rather stupid.
So I will trying Diamond IDE on my Windows 7 notebook first and avoid yet another challenge in Linux. Then I will work through the eP16 tutorial and attempt to get the eP16 and/or eP32 eForth engine running on the Lattice device.
Along with all that, I need to know the specifics of clock generation in both Verilog and VHDL for both Lattice and Altera. That code may be nearly the same for both manufacturers.
I have a BeMicroCV running the P1v code from Jac Goudsmit. So I know that Verilog code is not broken and worth in depth study. I just need to go through the same install verification for eP16 in VHDL. (I do wonder if I should dare attempt to install the P1v on the Brevia, just to learn a bit more about portability -- we will see.)
+++++++++++
I realize my approach may seem odd to others, but basically I am trying to follow working tutorials and then learn the FPGAs by contrasting Lattice with Altera and contrasting Verilog with VHDL.
From what I have read so far, Verilog may actually be the easier code to learn. I am not sure if the brand of FPGA makes things easier or more difficult.
The main point is that I am progressing, and I feel that I can continue -- but it won't be quick. A lot of study, testing, and learning is involved. (That's really the fun of it anyway, isn't it?)
I am delighted with the ability of FPGA devices to explore CPU architecture creatively.
I see this thread has had quite a bit of interest with 1.4K views and 2 followers.
Forgive me for neglecting to update, but I have been working on the eP16 VHDL code with both the Lattice XP2 Brevia2 and the BeMicroCV.
There is another Parallax thread that I have documented my progress which has been rough. But I have learned enough to begin to migrate the eP16 code to create an eP32. And I have moved the Lattice Diamond IDE 3.5 over to Linux as Windows has not worked well for me.
I am deep into reconfiguring my 64 bit Quad to get the best out of Lattice Diamond 3.5 and Quartus II v15.0.2. Both desire Red Hat/Fedora Linux or a Windows OS. To do so, I have to add a third OS as I already have Windows Vista and Debian Linus that I desire to keep.
In Debian Jessie amd64, Quartus II v15.0.2 did install and worked with P1V images by Jac Goudsmit. But features for eP16, such as the IP Cores provided by Metatrends software are not working right. To resolve problems, It just seems easier to go with the Linux they desire.
I also have other distractions this weekend that may delay getting that done for another week. I am sorry if this disappoints anyone. I'd like to make more progress too.
+++++++++++++++++++++++++
If you are trying to do something on your own...
To get started - stay with 16bit Forth and with Lattice, or be prepared to do more work in Altera Quartus II and in Windows (using meForth).
eP16 requires a binary image provided by the Metacompiler (a Forth cross-compiler) in Windows and provides an meForth.exe to run that.
The Metacompiler will create an image of the Forth dictionary that is provided at startup with appropriate use of eP16 binary code. That image is included in the ram_memory.vhd file. So if you can successfully use the existing ram_memory.vhd, you don't have to deal with the mem.mif file at all.
++++++++++++++
To date, it seems the easiest way to attempt a first install of FPGA eForth is to stay with the eP16 image in Lattice Diamond IDE and use the 5 provided VHDL files, including the existing ram_memory file that contains an image of the eForth dictionary that should start up if the compile and install go smoothly.
The top file is the eP16_chip.vhd file, but you will notice that it is internally labeled eP32 if you open the actual text... an apparent and annoying typo. C.H.Thing also provide the eP32_chip.file as a reference item to allow people to reconfigure back to eP32 or to attempt to reconfigure to other word widths (24bit perhaps).
Changing over to Quartus II may or may not accept the existing mem.mif file. I haven't run down the details as I have had not luck with IP Core's Two Port Memory -- if won't run for me.
If that mem.mif is not useful, one must go into weForth (in Windows) and meta-compile a new image for inclusion with the creation of a new ram_memory.vhd that applies to Altera products and their IP Cores by Megatrends.
It seems that the existing provided mem.mif file might be for 16bit only -- so any change in to 32bit in Diamond IDE along with any change over to Quartus II will likely demand a new mem.mif file for 32bit ram.
The reason that 16bit mem.mif will not work with 32bit ram is that machine code is packed into three 5 bit commands preceeded by a one bit flag. So in 16bit storage, the first bit indicates how the following 15 bits shall be used. (1-5-5-5)
With the 32bit ram, packing the 5bit codes would be six codes per 32bit and I am unclear as to how the 5bit codes are packed and unpacked.
I really don't know how many times I will have to reread all of C.H.Ting's various material resource to get what I want out it, but re-read is working for me.
I came across a series of Power Point presentations for the eP32, and found some very revealing details that the eP16 in VHDL.pdf doesn't mention.
Packing codes in the eP32 scheme are significantly different from the eP16.
From the ep16 in VHDL.pdf, I had gotten tine impression that all the 'short codes' were always 5 bits as the machine language was less than 32 instructions -- nothing more should be needed.
That works well in 16bit word length. There are 5 major instructions that use addressing and pretty much create a longer 15bit CALL and a shorter 10bit Jump. And then, pure machine instructions can pack three 5 bit instructions in one 16bit work.
1. We have a CALL instruction that starts with a 0 bit and then a 15bit address.
2.We have a JUMP instruction (and three others) that start with a 1 bit, then a 5 bit code, and a 10bit 'page' address.
3And finally we have the other machine instructions that start with a 1bit, then up to three 5 bit codes, or less with NOPs following.
So I have spent a lot of time trying to figure out how to get the 32bit version to pack. It did seem obvious that six 5bit codes would take the place of the 16 bit configuration with 3 5bit codes. Of course, that left me wondering where the other two bits might go.
To cut it short, the two bits go at the beginning, and I am not sure that the second bit ever changes.
But real shocker is that C.H. Ting presents not six 5 bit codes in the 32bit scheme, but five 6bit codes. The implication is that one can have as many as 64 machine codes if required. And no explanation is provided as to why the coding went this way. It may be simply faster than bothering with six 5 bit codes.
OR, it may be that the overall addressing of Jump and Call can just easily have more range (I suspect this is the true reason).
++++++++++
Of course the implications are simply that one is going to have to do some reconstruction of the meForth metacompiler to pack to the preferred 32bit geometry, and all the 5 bit listings need an added bit. I haven't gotten that for.
==========
So I guess I have made some progress in identify how the change over to eP32 will get done. But I am sure there will be even more implications when I consider trying to set up an 8 CPU scheme with these added differences. GPIO with 32 bits rather than with 16bits of i/0 seems to be another logical next step.
After a good night's sleep, I realize that five 6bit code spaces in 32bit actually provide one bit less (or 50% less) address width than six 5bit code spaces in 32bit.
I have no idea why C.H.Ting chose that option.
It seems that this will just remain an open question ... at least until I get a eP32bit model actually working.
+++++++++
Now, I am devoting a lot of study to the instruction pipeline, the 'slot machine', and how all that timing comes together. Either I am a bit slow or the text is a bit confusing. I'll report back later.
I've read that they have 35 instructions yet they only list 32. It may be that they found this MISC a bit too minimal and needed some more instructions.
While this endeavour of yours, as excellent as it is, results in learning more about about FPGAs, Verilog/VHDL, and Forth CPUs, it does not result in any increase in understanding about Forth as you have probably found. The "Forth" CPU is in fact a stack machine, even the Spin bytecode interpreter has many of these stack operations. Forth is the language and the environment whether it runs on a native stack machine or a 6502 or a Propeller.
Well, I am hoping to get a performance boost by having a hardware Forth CPU. Maybe it will prove pointless, but I am trying it out anyway.
The other added pluses are that I can get a Propeller with more resources than the Propeller 1 in FPGA -- more i/o, maybe faster timing, and more Hubram. I had put off learning more about Forth because I was waiting for the Propeller 2. The FPGAs are allowing me to finally move ahead without waiting for anyone.
eP16 actually claims 27 instructions bare minimum, but doesn't include the NOP. I would count that as 28 out of 32 or 27 out of 31. eP32 uses the same count but the presentation claims 64 machine instructions are available to those that desire to add more.
I guess some versions of eForth add more in order to deal with the serial interface of the hardware it is residing on.
Tachyon seems to demonstrate that there are other ways to achieve the most optimal performance out of Forth, and it just may outperform eP16 or eP32. That remains to be determined.
+++++++
Yes, mostly I am learning FPGA compilation. But eventually, the target is to have a multiple CPU Forth machine that shares a common dictionary and is similar to the Propeller 1.
Stacks are certainly useful and important. SPIN documentation has never made it very clear how important stacks are to passing variables between objects.. but they are and they have to be long enough to avoid crashes. And I am pretty sure that the BS2 has a stack machine processing its tokens. Others that use stacks are Java and some forms of document display (maybe pdr readers?).
So stack machines don't have to be Forth at all.
+++++++
eForth has fascinated me from the start as it has always sought the minimum in actual machine instructions and making the rest of the Forth dictionary fro that 'Forth Kernel'. It may not be the fastest Forth as some CPUs might actually have machine instructions that could take less time.
By using a minimal number of machine instructions, eForth just makes it easier to quickly port Forth to any CPU with enough space for a dictionary in RAM. And so, the Zen in eForth has always been about minimalism, not about optimal performance.
For anyone reading the eP16inVHDL.pdf by C.H.Ting; Figure 6 seems to have been copied from an eP32 document without proper correction. All the mention of five code steps, should be three code steps.
I have run into several typos while studying the material, but the discussion of pipeline and the 'slot machine' seems to have been adapted from the eP32 design and not completely adjusted to reflect changes that the eP16 bit scheme required. I am still trying to figure out if it is correct for eP16, or actually presenting eP32 in error.
For ep16, the 16bit word may accommodate up to 3 codes, but has up to 4 slots.
Slot0 is 1 bit
Slot1 is 5 bits of Code
Slot 2 is 5 bits of Code
Slot 3 is 5 bits of code
For ep32, the 32bit word may accommodate up to 5 Codes, but has up to 6 slots.
Slot0 is 2 bits
Slot1 is 6 bits
Slot2 is 6 bits
Slot 3 is 6 bits
Slot 4 is 6 bits
Slot 5 is 6 bits
That Slot0 does take one clock, and each additional Slot takes one clock - unless there is a NOP in the slot.
If you followed Chuck Moore's CPU design you can see that he loves to use these slots to optimize memory bandwidth with the idea that you read in all the instructions in that word in one slow memory cycle, execute them, and then proceed to the next word. The trouble is IMO to make it work effectively you almost need to code in a way that fits instructions to slots and slots to words, so you end up concentrating on juggling bits vs writing code. Some words end up with mostly nops as the program needs to jump to another word. What you really need is 5 or 6-bit wide memory that is as fast as the CPU.
With the Prop I toyed with the idea of reading a long and extracting bytecodes but that was terribly messy and inefficient so I scrapped that before I even started.
Now you speak of eForth and Zen with a kind of reverence and as if Ting has achieved apotheosis of some kind but all these subjects simply have a goal, of doing something well. What that something is is not always the same or what we think it is nor is it always generally discernible.
Ting's use of Bill Muench's educational Forth or eForth is about "minimalism" in the sense that it has a minimal "custom" kernel, the part that is specific to that CPU etc. However not being a student of Zen I would still hazard a guess that this alone is not "Zen". Even after we gain insight and strip off all the traditions and trappings etc, we are doing so not for the sake of minimization, but to minimize the redundancies, to gain insight and to get to the heart of the subject, of what is necessary vs the "fluff", to do something well.
In the case of Forth, it is not a case of getting the machine to run Forth but it is a case of getting a machine to perform a function and usually as efficiently as possible (and as much fun as possible ). In this "respect" eForth fails because the whole reason for using Forth (or anything else) in the first place was to get it to perform a function and to do so efficiently, perhaps both from a development and runtime perspective. However, in the respect of "speed of implementation" for conventional (not any) CPUs eForth does succeeds in a "Zen" like fashion just as you mentioned
By using a minimal number of machine instructions, eForth just makes it easier to quickly port Forth to any CPU with enough space for a dictionary in RAM. And so, the Zen in eForth has always been about minimalism, not about optimal performance.
Isn't it funny though that if eForth were that easy to port it would have been the first Forth ported to the P1?
So while I dream and "meditate" I am still a pragmatist and while eForth has proven fine for implementing Forth in minimal time on conventional CPUs it is not designed to be the Zen-like Forth for that machine, but is useful to test out new CPUs and hardware and for teaching.
Tachyon was designed for the P1, not for educational purposes or for compatibility, but for practical applications, based partly on my experience with writing a bytecode Forth for ARM and seeing the merits of this part of the approach, but many other aspects of its design were based on the tools and the architecture and the way we actually use the P1. My gut feeling is that Tachyon, if it is still called that for the P2 will be a very different implementation indeed.
Well,others easily may be better informed about Forth than myself. I did not follow the evolution of Forth from the beginning. I came late to the party.
These days, C. H. Ting just seems to be one of the more accessible authors and has provided a more in-depth documentation FPGA solution that anyone else. At times, he seems to actually have too much to say.
Yes indeed, the 'slot machine' is a curious beast. At first I was attracted to C. H. Ting's claim than each and every instruction code was one clock. That seemed to indicate a deterministic model that I find part of my attraction to the Propeller and the BasicStamp.
But now that I have looked into, the Slot0 requires an additional clock and changes the whole scheme of one clock/one instruction into something more complex.
So far...
The Propeller 1 still is my favorite small Forth microcontroller. But it is obvious that 512K of Hubram and some ADC i/o would allow the Propeller to challenge AVRs and ARMs in 3D printing and other demanding automation situations. I had put my Forth projects 'on hold' while waiting for the Propeller 2.
I have no problem with admitting that Tachyon is well-optimized and thoughtfully developed. And I am uncertain that C. H. Ting has reached the apex of Forth machines. But I do enjoy having enough reading material to guide me as I study a topic.
I have tried learning about the GA144 devices from Chuck Moore, but they just confound me. So eP16 seemed to be something in between the Forth on the Propeller 1 and the GA144 chip.
None of it is perfect. There are always typos, a bit of bias on the originator's part, each has an imprint of personality (like having to learn Chuck Moore's Color Forth),and so on.
The main thing is I am moving forward in learning more. I don't think I will ever be blindly loyal to one particular solution.
Regarding the costs of the FPGA with board...
It is difficult for me to say that they are too expensive. The BeMicroCV cost me only $49.00USD and includes several useful additions that a Propeller 1 does not -- an SDcard slot, DDR3 Ram, and so on.
Some say the FPGA producers are dumping their cheaper products on the market place. But it could be that inexpensive FPGA boards may been the next shift in hardware. That would mean that CPU architecture may be shifting from being hardware/firmware to being software.
Of course, the greatest burden with the FPGAs is the huge compiler programs (and their purchase cost if you actually buy one). Also, there is the fact that Altera seems to only provide a 64bit IDE. So one must have the right hardware to compile code for these.
When the Propeller 2 arrives, the whole FPGA solution may collapse into being too demanding of time and resources. But, it is hard to say for sure. I certainly do not desire to DIY ball-gate-array chips, but I do like buying a blank slate that will let me design a CPU to specifics.
If we spend our time designing CPUs we aren't getting much time in designing applications for CPUs as I see it. Have you had any fun with chopsticks lately?
Chip has spent many years just designing the P1 and now the P2 and the tools to get them running. As much as I probably would like to have lots of time to do the same I also would not want to miss out on all the applications that I could use them in and the fun of bringing a system to life and seeing it put to use.
Let's face it, all the hard work and sweat and tears that goes into a CPU is buried under all that epoxy, hidden away and in itself "unexciting" in that unlike Hollywood tech it doesn't blink and bleep and conquer the world or even make the headlines like Ahmed's homemade clock. It's just a little black blob, a boring "silicone (sic) chip" Of course it is never boring to us. So I look forward to the P2 as I continue to battle the bewildering myriads of ARM and MIP monsters spawning and rapidly taking over the world as we know it.
I am not here to debate so much as I am here to explore and learn.
And I don't have a product to tout as being superior to all others.
Finding that 'killer application' that will make me rich is not as appealing to me as learning how FPGAs can actually be deployed as a solderless mega-breadboard.
I am enjoying the journey and the puzzle that FPGAs offer. There may come a point that I will migrate to boards that combine a Propeller and a FPGA together. Soldering irons and 'order your own' boards to populate are likely to be the next item to disappear... like the paper straw, desktop calculators, slide-rulers, and all that other stuff.
Procurement of odd-ball components has always been an issue due to my living abroad, but now I can create my own in an FPGA rather that endlessly seeking the right item in the right package at the right price. Huge procurement headaches seem to just vanish.
The fact that Intel purchased Altera just may indicate that the FPGA will be far more central to our future in microcontrollers, both as a hobby and an industry. Microcontrollers have in the past decade been the biggest growth sector of silicon production and microcomputers seem to be taking a backseat.
So if you want to deny that possibility that FPGAs are the future and hang on to the past, feel free to do so.
Printing names on chopsticks or getting a balancing bot to wander about the room for bragging rights also is no big deal. I am just not that vested in ego or making money from all this.
As far as teaching kids, even with my English classes - the main focus is to teach kids how to enjoy working with their mind and applying effort. I also focus on teaching them that they have to constantly grow if they want to be winners in today's world. Too narrow a focus is bound to leave them short in life even if it makes one wealthy.
In truth, I actually have very few needs.
Adding robotics and networks to all and everything I live with just isn't necessary. I am driven by expanding horizons of understanding design, the interplay of concepts, and fundamentally whether technology is indeed going to take the world to a better place. I deeply enjoyed learning Madgwick and management of inertial guidance, but I haven't built a quad-copter.
So far, I have mixed feelings about all the technological. It is a merry chase, but is it making the planet better for all of us? I dunno.
Back in the days of reliable postal service, I never got as much junk mail in a month that the internet is capable of delivering now in one day. And now that the Kaohsiung police have covered all the streets in my neighborhood with video cameras, I see they are going back and installing more in the alleys. We all live with a lot of changes we never considered possible.
I watch, I wonder, and I learn. Forth on an FPGA adds something good to my day.
Comments
+++++++++
FPGA devices didn't arrive today (which is what was promised)
DHL called and wanted clarification on my 'company name' that I was a private individual.
So it seems putting one's own name in that data field on your order is important. Giving a fake name may just lead to a long-winded discussion with your local customs about not properly registering a business name with Customs.
Also, the delivery truck driver might just be driving around looking for a company sign in a residential district.
Tell us you did not put Loopy Byteloose in the name field !
As a result, Taiwan Customs went looking for an 'unregistered enterprise' and I have had to explain it was just an individual purchase. I am a bit more wary of these issues as I am not a citizen of Taiwan and here on a permanent residency visa. Even though I have an 'open work permit' that allows me to start my own business or work for anyone, I really don't want to get into all the Taiwanese business regulations.
Heater protested my suggestion to put your own name in this field, but it now becomes clear to me that my preference for using my own name really works best. People do fabricate names all the time to get free samples which is something I don't pursue. But they don't realize that all sorts of local and national governments are searching to verify unlicensed business.
++++++++++++++++++ VHDL versus Verilog
Actually, the non-delivery has given me more time to ponder what to do upon arrival.
Due to the Parallax code being mainly offered in Verilog, the fact that the eP16 code is all VHDL initially put me into a tailspin. But a bit of research has shown that Quartus II may actually be able to convert VHDL code to Verilog code for you.
Since my hopes are to combine Propeller 1V and eP16 code together, I really need that conversion. And if Quartus II doesn't do an adequate job, there are other VHDL to Verilog converters available.
So I am a bit relieved. I may not even have to learn VHDL if the converter does an adequate job. Verilog to VHDL may be more difficult as VHDL has more choices rather than less. There is available software to do that as well.
Heater protested my suggestion to put your own name in this field, but it now becomes clear to me that my preference for using my own name really works best.
Err...no, I did not.
That comment was all about filling in forms and registering for some web sites in order to get a download. Altera in that particular case.Where entering any fake information is the norm if the fields are required. Anyway your entering your name as a company when you are not is mis-representation is it not?
I would not suggest putting fake information on purchase orders, actual commercial transactions, like your order from Arrow. Especially not when customs, duties, import/expert regulations are involved.
Just now I have imported 20 radar units from Germany into the USA. It's a big enough hassle when you get all the details correct. Being RF transmitters there is also the FCC approval to deal with. Grrr...
Messing with customs can be very bad for you.
My own feelings are that everyone has been asking for too much information, and sharing it with unknown persons or authorities. I am happy to the new Parallax Forums eliminated a lot of features that could be attractive to people wanting to do identity theft. Birthday registration, etc.
But it does get tricky when one decides to not offer info or to offer misleading info.
One kind of answer for downloading software, another answer for importing electronics, and definitely a third is one's government is asking the question.
While I often leave data fields blank if I am allowed to do so, the U.S. government occasionally demands info from me for tax and such. Not answering is not an option, and lies to the Federal government or its representative is a crime-- maybe a felony.
Meanwhile, law in Taiwan is not available in English -- so I really do try not to get caught up with it.
++++++++++
More about eP16.zip
I have been spending the day trying to figure out how I might compile the eP16 VHDL files for eForth and the presentation seems somewhat straight forward. There are a group of 5 related VHDL files with the eP16_chip.vdh file being the top one. The tutorial does a good job of explain which ones are useful and how to use -- but it is all for Xilinx, not Altera and a smaller FPGA
I just have to get Quartus II completely working and create a project with the files migrated into them to attempt a compile for either the BeMicro CV or the CVA9. I then hope that will lead to figuring out how to also convert the VHDL to Verilog so that I may combine the CPU and Forth resources with a Propeller architecture.
Quartus II V15.0.2 (that 2 is for Update 2) is confirmed as installed on my Debian 8.1.
But I read something about having to get it added to the PATH in the environment. And while it starts and appears to run correctly, I am getting a Warning in the Terminal window when I start that one module of software can't be found.
The missing module appears to be included in the iceweasle-dev package. But my first attempt to install then went haywire and I had to back out.. (Debian 8.1 wanted me to load from DVD rather than repository, but won't recognize the DVD)
So I first have to clear my Quartus II and see if that warning remains or even matters.
Meanwhile, the ep16.zip includes a version of the same Forth engine as a VM with support in software compiled for Windows under the executable called WeForth.exe and there is a rather long discussion about first familiarizing one's self with that before working in the FPGA.
Apparently the eP32_chip.vdhl file is for reference only as the text mentions that it was written first and the eP16 came later. So one still has to locate a complete set of eP32 files in VDHL to file a 32 bit scheme. And C. H. Ting mentions there are actually 16 bit, 24 bit, and 32 bit FPGA images.
Early on, the J1 16 bit Forth Verilog code was mentioned as a possible Forth core. That seems attractive because all the instructions are one clock cycle, or so it claims. But the eP16 and eP32 seem to have also achieved the same goal of one clock cycle execution. For now, there isn't much reason to look at anything other than the eP16 and eP32 Forths to eventually meld with a Propeller-like architecture.
++++++++++
Not much to continue comparing. It seems to now be time to get deeply into the set of files I have for eP16 Forth and Propeller IV.
Also, I should soon take a good look at what the WeForth.exe really does and read along in the tutorial.
++++++++++
I believe that when I downloaded the Chinese eP32 tutorial, the VHDL files for the 32bit example were all included. But I have to confirm that I actually did acquire those. This is very much a bi-lingual project. The VHDL is all in English code with Chinese notes. But the text appears to be a clone of the eP16 tutorial.
1. I had to set up active repositories, acquirre libcanberra-gtk3-module and install it. The initial start up suddenly changed from a long wait to a near instant start.
2. D-Bus is not properly configured. I do have an active dbus-daemon and dbus-launch, but
Quartus II can't locate it. I suspect this relates to something that was mentioned about configuring a path for something. I can't find the Altera publication that I read that in.
STATUS -- It seems that I can't do anything with the eP16 VHDL files until Quartus is right.
Sure, I can ready the manual, but that is thousands of pages. So, I am seeking some short cuts.
"Arrow Electronics had the 'required' company field as well as Altera."
No doubt.
Entering into a transaction with money changing hands and all kind of repercussions regarding shipping, import/export controls, customs duties, VAT, etc is a very different thing than signing up for a free software download.
Actually I have never understood this mode of operation of companies like Altera. Why not give us a download button and be done with it? Don't they realize that the random anonymous geek that downloads their software today may well become a big customer of their devices in the future when he gets his creation off the ground? Surely it's in their interest to make that process as frictionless as possible?
I registered my 'business name' as an educator, which I am. I have decades of Taiwan and US tax returns declaring myself a business for private teaching. That explains the obvious smallness of the business and the lack of plans to bring a product to market -- but they still welcome teachers because they create some eventual demand for the product.
At least that is the rationale.
We do have several private schools that teach FPGA programing in Taiwan. Engineers do want help with sorting out all that English documentation. FPGAs just keep getting cheaper and cheaper. And there is nothing wrong with being a solo private teacher of FPGA use.
On the one hand, I prefer not to lie; on the other hand, my use isn't likely to directly create sales.
Nobody can survive in business on giving free samples to people that just want free samples. At least I have purchased the FPGA development boards and can help others to learn. I doubt if I will ever completely retire from the English teaching. It is fun and interesting.
I'm sure you are right about the free samples.
I snagged some free samples of AVR and PIC back in the day. Presumably such companies are savvy enough to assess when and how much it is a good idea to do that.
Eventually I decided it was not a good idea for me as a hobbyist or even potential small time business. What if I develop a great project around a free sample of a device that ends up not being easily available to every one else or even myself in the future? What if that device does not take off and gets canned?
All in all it's better to stick with mainstream easily available devices. Rather than chasing the cutting edge.
I am going to run some simple test project in VHDL and Verilog to see what my current Quartus II installation does. Then I may uninstall everything and start over.
Meanwhile, it certainly seems the Xilinx FPGA scheme for VHDL ram memory in eP16 is going to need to be revised to work with the BeMicroCV.
And so, I just keep going back and forth.... some progress is occurring, but requires effort and thought
@Heater
TANSTAAFL per Robert Heinlien
https://en.wikipedia.org/wiki/There_ain't_no_such_thing_as_a_free_lunch
And, there ain't no such thing as a free search engine either. These days I get more barrages of advertising that I ever got back in the day of physical junk mail. They all try to lock on to my cash in pocket.
Of course, there was a time when pretty girls handed out free introductory packages of Winston and Kool cigarettes on a downtown street corner in major US cites. But the idea was to push the nicotine addiction. Beware of strangers with gifts, even the pretty ones.
Have You found any eP16.zip?
With Altera support -- Ones I found don't have support for Altera-Quartus MEMORY.
So it is not possible to compile clean eP16 system from them for Altera FPGA's
++++++++++
More about eP16.zip
I have been spending the day trying to figure out how I might compile the eP16 VHDL files for eForth and the presentation seems somewhat straight forward. There are a group of 5 related VHDL files with the eP16_chip.vdh file being the top one. The tutorial does a good job of explain which ones are useful and how to use -- but it is all for Xilinx, not Altera and a smaller FPGA
I just have to get Quartus II completely working and create a project with the files migrated into them to attempt a compile for either the BeMicro CV or the CVA9. I then hope that will lead to figuring out how to also convert the VHDL to Verilog so that I may combine the CPU and Forth resources with a Propeller architecture.
I thought I might just get the time to download and read on the plane home on Tuesday. Btw transiting taipai so i will give you a wave as I go by.
If You download this file <eP16.zip> -- It has very nice description on that implementation.
Loopy, is there a short summary of one of the Fpga forth implementations?
I thought I might just get the time to download and read on the plane home on Tuesday. Btw transiting taipai so i will give you a wave as I go by.
eP16.zip has a pdf that explains that the Lattice Ram Memory is asynchronous and other FPGAs appear to ONLY provide synchronous RAM. So it will at least be necessary to rewrite the whole RAM_memory.vhdl in order to get this running on a BeMicro CV or other Altera product.
Additionally, the problem is that a synchronous memory solution may run significantly slower.... 50% slower.
It is all discussed in eP16inVHDL.pdf starting at section 5.3 RAM Memory Module page 76.
I hope someone can see a solution other than buying a Lattice product.
+++++++++++++
At this point, I still am having concerns with my Debian 8.1 Jessie amd64 installation of Quartus II V15.0.2.
So while I ponder what to do about the eP16 Ram Memory Module issue, I am going to work on improving and verifying my Quartus II installation.
To that end, I will attempt to compile the Propeller 1V for BeMicroCV and BeMicroCVA9 Verilog. And then attempt to load in those platforms. Others have succeeded in Windows and maybe other Linux installation, so it seems important that I verify my Quartus II is working as expected.
The problems in Linux are related to two facts -- Quartus II may not be trying to support the latest releases of Linus (they obvious do not desire to support Fedora 7 yet), and some of the software is 64bit while other parts are 32bit (so the installation has to deal with running both in harmony).
=============
For now, I am disappointed that eP16 may only run half as fast on an Altera FPGA solution -- if at all. But that would be better than nothing.
C. H. Ting does have an eP32 VHDL installation on an Altera product. I believe it was a Stratix II FPGA.
I may have to purchase a CD from www.offete.com with code for that solution to get a clue as to how to resolve the RAM memory module. But I do have a hunch that the Stratix II FPGA might offer asynchronous RAM as well (Can anyone confirm?)
www.forth.org/svfig/kk/04-2013-Ting.pdf
Attached some good description on MEMORY requirement for FORTH
Deep down, I always expected their to be some difficulty with migrating code from Xilinix to Altera. And there was always the looming challenge of reconfiguring RAM on a single CPU Forth to a shared HUBram.
I am just a bit perplexed whether I can do asynchronous RAM in the Cyclone V. I simply require 64Kbits of 16bit RAM and appear to have lots of space and resources.
=================
A bit more progress.........
My goodies arrived from Arrow Electronics -- A BeMicroCV, a BeMicroCVA9, and a BESCOPE card. So I have actually hardware to proceed with.
+++++++++++
Rereading the eP16 Manual pdf,
it seems that C.H. Ting is primarily concerned with the memory being read on the leading clock edge versus the following clock edge. So I am going to focus on removing the entire existing RAM_memory.vhd file and attempt the creation of another tailored to the BeMicroCV.
If one read the eP16 manual, C. H. Ting used a Xilinx application to create the whole RAM Memory VHDL file, so it seems feasible to just replace it and patch whatever other code is tied into it.
################
Saphiena's paper is worth reading, but I am a bit wary of the need to pipeline instructions or deal with program counters when I don't quite know what the eP16 CPU requires. And the attachment of serial SRAM, such as an SDcard with its FAT16 are back-burnner issues to me right now.
In short, I just want to see if the eP16 is feasible on the BeMicroCV before I begin to seek out modifications and additions beyond what C.H. Ting envisions.
++++++++
As it is, I may have to take a couple of weeks getting up to speed with Quartus II V15.0.2 and fooling around with the Propeller 1V image on the BeMicroCV. There is a lot to learn about both VHDL and Verilog. So don't expect a lot from me in the immediate future.
My choice of the BeMicroCV and BeMicroCVA9 Development Kits was based on a strong bias toward emulation of the Propeller 1 and Propeller 2.
++++++++
So far, my reading on the eP16 has made it obvious that C. H. Ting investigated a wide variety of FPGAs for Forth and settled on the LatticeXP2 with the Diamond IDE as the best -- for his purposes, a Forth device.
Meanwhile Parallax is doing something entirely separate and different.
++++++++
I have begun to see that the conflicts between the two are not an easy entry point for the new FPGA learner. So it would likely be best for a Forth enthusiast to purchase the $49.00USD LatticeXP2 device, get a free download of Diamond IDE, and learn as much as possible from C. H. Ting before melding Forth and Propeller.
If fact I just may have to do that to get started.
In part, I see that the 'memory blocks' available on the LatticeXP2 are vast, while the same resources on the BeMicroCV and BeMicroCVA9 are relatively limited. That one difference in architecture forces a rather severe redesign for the Altera Cyclones (C. H. Ting did succeed on the much more expensive Altera Stratix devices as they have the right resources in adequate supply)
Saphiena provided a rather interesting article on Forth memory optimization that is yet another issue. Simply put, a Forth machine with only a 32bit data bus is awkward in a world where many storage devices and communication ports are 8bit devices.
To me, I just want to get the eForth concept working before I consider such additions or alternatives. But the issue is a very real one. It might just be best in the beginning to focus on all 8bit being handled serially.
++++++++
In any event, I am having to reinstall my Quartus II from scratch in light of new information. It is obvious I made a mess of that as well.
In Linux, Altera claims that one can simply remove the <home>./altera directory with its sub-directories and contents. But I also discovered another hidden directory, <home>/.altera-quartus and am removing that as well.
Then I will see what appears after installation. ArchLinux provided a rather
So, a progress report.
1. FedEx dropped off a new LatticeXP2-Brevia2 that will allow me to learn eP16 and eP32 in C. H. Ting's preferred platform before attempting to migrate to Altera CycloneV devices.
My thoughts about not having enough memory blocks in the Altera devices may have been premature. So issues may be just that I don't know how to use memory blocks to generate asynchronous RAM in the Altera Cyclone V..
2. Quartus II V15.0.2. has demonstrated that it can work in Debian 8.1 Jessie amd64. But I need to do more work on Debian to get 32bit programs to work in the 64bit environment.
Apparently Debian 7.xx wheezy went to multi-arch from ia32 support for 32bit applications in a 64bit environment and I have not set it up yet. Quartus II happens to run Both 32bit and 64bit applications under the IDE and the 32bit features are still missing for me.
+++++++++++
What's next?
Upgrading to Debian 8.1, shifting to amd64(64bit) from i368 (32bit), and learning how to install Quartus II V15.0.2, all at the same time, was rather stupid.
So I will trying Diamond IDE on my Windows 7 notebook first and avoid yet another challenge in Linux. Then I will work through the eP16 tutorial and attempt to get the eP16 and/or eP32 eForth engine running on the Lattice device.
Along with all that, I need to know the specifics of clock generation in both Verilog and VHDL for both Lattice and Altera. That code may be nearly the same for both manufacturers.
I have a BeMicroCV running the P1v code from Jac Goudsmit. So I know that Verilog code is not broken and worth in depth study. I just need to go through the same install verification for eP16 in VHDL. (I do wonder if I should dare attempt to install the P1v on the Brevia, just to learn a bit more about portability -- we will see.)
+++++++++++
I realize my approach may seem odd to others, but basically I am trying to follow working tutorials and then learn the FPGAs by contrasting Lattice with Altera and contrasting Verilog with VHDL.
From what I have read so far, Verilog may actually be the easier code to learn. I am not sure if the brand of FPGA makes things easier or more difficult.
The main point is that I am progressing, and I feel that I can continue -- but it won't be quick. A lot of study, testing, and learning is involved. (That's really the fun of it anyway, isn't it?)
I am delighted with the ability of FPGA devices to explore CPU architecture creatively.
Forgive me for neglecting to update, but I have been working on the eP16 VHDL code with both the Lattice XP2 Brevia2 and the BeMicroCV.
There is another Parallax thread that I have documented my progress which has been rough. But I have learned enough to begin to migrate the eP16 code to create an eP32. And I have moved the Lattice Diamond IDE 3.5 over to Linux as Windows has not worked well for me.
Go here to catch up...
http://forums.parallax.com/discussion/162035/verilog-versus-vhdl-or-maybe-both
In Debian Jessie amd64, Quartus II v15.0.2 did install and worked with P1V images by Jac Goudsmit. But features for eP16, such as the IP Cores provided by Metatrends software are not working right. To resolve problems, It just seems easier to go with the Linux they desire.
I also have other distractions this weekend that may delay getting that done for another week. I am sorry if this disappoints anyone. I'd like to make more progress too.
+++++++++++++++++++++++++
If you are trying to do something on your own...
To get started - stay with 16bit Forth and with Lattice, or be prepared to do more work in Altera Quartus II and in Windows (using meForth).
eP16 requires a binary image provided by the Metacompiler (a Forth cross-compiler) in Windows and provides an meForth.exe to run that.
The Metacompiler will create an image of the Forth dictionary that is provided at startup with appropriate use of eP16 binary code. That image is included in the ram_memory.vhd file. So if you can successfully use the existing ram_memory.vhd, you don't have to deal with the mem.mif file at all.
++++++++++++++
To date, it seems the easiest way to attempt a first install of FPGA eForth is to stay with the eP16 image in Lattice Diamond IDE and use the 5 provided VHDL files, including the existing ram_memory file that contains an image of the eForth dictionary that should start up if the compile and install go smoothly.
The top file is the eP16_chip.vhd file, but you will notice that it is internally labeled eP32 if you open the actual text... an apparent and annoying typo. C.H.Thing also provide the eP32_chip.file as a reference item to allow people to reconfigure back to eP32 or to attempt to reconfigure to other word widths (24bit perhaps).
Changing over to Quartus II may or may not accept the existing mem.mif file. I haven't run down the details as I have had not luck with IP Core's Two Port Memory -- if won't run for me.
If that mem.mif is not useful, one must go into weForth (in Windows) and meta-compile a new image for inclusion with the creation of a new ram_memory.vhd that applies to Altera products and their IP Cores by Megatrends.
It seems that the existing provided mem.mif file might be for 16bit only -- so any change in to 32bit in Diamond IDE along with any change over to Quartus II will likely demand a new mem.mif file for 32bit ram.
The reason that 16bit mem.mif will not work with 32bit ram is that machine code is packed into three 5 bit commands preceeded by a one bit flag. So in 16bit storage, the first bit indicates how the following 15 bits shall be used. (1-5-5-5)
With the 32bit ram, packing the 5bit codes would be six codes per 32bit and I am unclear as to how the 5bit codes are packed and unpacked.
I came across a series of Power Point presentations for the eP32, and found some very revealing details that the eP16 in VHDL.pdf doesn't mention.
Packing codes in the eP32 scheme are significantly different from the eP16.
From the ep16 in VHDL.pdf, I had gotten tine impression that all the 'short codes' were always 5 bits as the machine language was less than 32 instructions -- nothing more should be needed.
That works well in 16bit word length. There are 5 major instructions that use addressing and pretty much create a longer 15bit CALL and a shorter 10bit Jump. And then, pure machine instructions can pack three 5 bit instructions in one 16bit work.
1. We have a CALL instruction that starts with a 0 bit and then a 15bit address.
2.We have a JUMP instruction (and three others) that start with a 1 bit, then a 5 bit code, and a 10bit 'page' address.
3And finally we have the other machine instructions that start with a 1bit, then up to three 5 bit codes, or less with NOPs following.
So I have spent a lot of time trying to figure out how to get the 32bit version to pack. It did seem obvious that six 5bit codes would take the place of the 16 bit configuration with 3 5bit codes. Of course, that left me wondering where the other two bits might go.
To cut it short, the two bits go at the beginning, and I am not sure that the second bit ever changes.
But real shocker is that C.H. Ting presents not six 5 bit codes in the 32bit scheme, but five 6bit codes. The implication is that one can have as many as 64 machine codes if required. And no explanation is provided as to why the coding went this way. It may be simply faster than bothering with six 5 bit codes.
OR, it may be that the overall addressing of Jump and Call can just easily have more range (I suspect this is the true reason).
++++++++++
Of course the implications are simply that one is going to have to do some reconstruction of the meForth metacompiler to pack to the preferred 32bit geometry, and all the 5 bit listings need an added bit. I haven't gotten that for.
==========
So I guess I have made some progress in identify how the change over to eP32 will get done. But I am sure there will be even more implications when I consider trying to set up an 8 CPU scheme with these added differences. GPIO with 32 bits rather than with 16bits of i/0 seems to be another logical next step.
I have no idea why C.H.Ting chose that option.
It seems that this will just remain an open question ... at least until I get a eP32bit model actually working.
+++++++++
Now, I am devoting a lot of study to the instruction pipeline, the 'slot machine', and how all that timing comes together. Either I am a bit slow or the text is a bit confusing. I'll report back later.
While this endeavour of yours, as excellent as it is, results in learning more about about FPGAs, Verilog/VHDL, and Forth CPUs, it does not result in any increase in understanding about Forth as you have probably found. The "Forth" CPU is in fact a stack machine, even the Spin bytecode interpreter has many of these stack operations. Forth is the language and the environment whether it runs on a native stack machine or a 6502 or a Propeller.
The other added pluses are that I can get a Propeller with more resources than the Propeller 1 in FPGA -- more i/o, maybe faster timing, and more Hubram. I had put off learning more about Forth because I was waiting for the Propeller 2. The FPGAs are allowing me to finally move ahead without waiting for anyone.
eP16 actually claims 27 instructions bare minimum, but doesn't include the NOP. I would count that as 28 out of 32 or 27 out of 31. eP32 uses the same count but the presentation claims 64 machine instructions are available to those that desire to add more.
I guess some versions of eForth add more in order to deal with the serial interface of the hardware it is residing on.
Tachyon seems to demonstrate that there are other ways to achieve the most optimal performance out of Forth, and it just may outperform eP16 or eP32. That remains to be determined.
+++++++
Yes, mostly I am learning FPGA compilation. But eventually, the target is to have a multiple CPU Forth machine that shares a common dictionary and is similar to the Propeller 1.
Stacks are certainly useful and important. SPIN documentation has never made it very clear how important stacks are to passing variables between objects.. but they are and they have to be long enough to avoid crashes. And I am pretty sure that the BS2 has a stack machine processing its tokens. Others that use stacks are Java and some forms of document display (maybe pdr readers?).
So stack machines don't have to be Forth at all.
+++++++
eForth has fascinated me from the start as it has always sought the minimum in actual machine instructions and making the rest of the Forth dictionary fro that 'Forth Kernel'. It may not be the fastest Forth as some CPUs might actually have machine instructions that could take less time.
By using a minimal number of machine instructions, eForth just makes it easier to quickly port Forth to any CPU with enough space for a dictionary in RAM. And so, the Zen in eForth has always been about minimalism, not about optimal performance.
I have run into several typos while studying the material, but the discussion of pipeline and the 'slot machine' seems to have been adapted from the eP32 design and not completely adjusted to reflect changes that the eP16 bit scheme required. I am still trying to figure out if it is correct for eP16, or actually presenting eP32 in error.
For ep16, the 16bit word may accommodate up to 3 codes, but has up to 4 slots.
Slot0 is 1 bit
Slot1 is 5 bits of Code
Slot 2 is 5 bits of Code
Slot 3 is 5 bits of code
For ep32, the 32bit word may accommodate up to 5 Codes, but has up to 6 slots.
Slot0 is 2 bits
Slot1 is 6 bits
Slot2 is 6 bits
Slot 3 is 6 bits
Slot 4 is 6 bits
Slot 5 is 6 bits
That Slot0 does take one clock, and each additional Slot takes one clock - unless there is a NOP in the slot.
NOP seems to not take a clock.
With the Prop I toyed with the idea of reading a long and extracting bytecodes but that was terribly messy and inefficient so I scrapped that before I even started.
Now you speak of eForth and Zen with a kind of reverence and as if Ting has achieved apotheosis of some kind
Ting's use of Bill Muench's educational Forth or eForth is about "minimalism" in the sense that it has a minimal "custom" kernel, the part that is specific to that CPU etc. However not being a student of Zen I would still hazard a guess that this alone is not "Zen". Even after we gain insight and strip off all the traditions and trappings etc, we are doing so not for the sake of minimization, but to minimize the redundancies, to gain insight and to get to the heart of the subject, of what is necessary vs the "fluff", to do something well.
In the case of Forth, it is not a case of getting the machine to run Forth but it is a case of getting a machine to perform a function and usually as efficiently as possible (and as much fun as possible
So while I dream and "meditate" I am still a pragmatist and while eForth has proven fine for implementing Forth in minimal time on conventional CPUs it is not designed to be the Zen-like Forth for that machine, but is useful to test out new CPUs and hardware and for teaching.
Tachyon was designed for the P1, not for educational purposes or for compatibility, but for practical applications, based partly on my experience with writing a bytecode Forth for ARM and seeing the merits of this part of the approach, but many other aspects of its design were based on the tools and the architecture and the way we actually use the P1. My gut feeling is that Tachyon, if it is still called that for the P2 will be a very different implementation indeed.
These days, C. H. Ting just seems to be one of the more accessible authors and has provided a more in-depth documentation FPGA solution that anyone else. At times, he seems to actually have too much to say.
Yes indeed, the 'slot machine' is a curious beast. At first I was attracted to C. H. Ting's claim than each and every instruction code was one clock. That seemed to indicate a deterministic model that I find part of my attraction to the Propeller and the BasicStamp.
But now that I have looked into, the Slot0 requires an additional clock and changes the whole scheme of one clock/one instruction into something more complex.
So far...
The Propeller 1 still is my favorite small Forth microcontroller. But it is obvious that 512K of Hubram and some ADC i/o would allow the Propeller to challenge AVRs and ARMs in 3D printing and other demanding automation situations. I had put my Forth projects 'on hold' while waiting for the Propeller 2.
I have no problem with admitting that Tachyon is well-optimized and thoughtfully developed. And I am uncertain that C. H. Ting has reached the apex of Forth machines. But I do enjoy having enough reading material to guide me as I study a topic.
I have tried learning about the GA144 devices from Chuck Moore, but they just confound me. So eP16 seemed to be something in between the Forth on the Propeller 1 and the GA144 chip.
None of it is perfect. There are always typos, a bit of bias on the originator's part, each has an imprint of personality (like having to learn Chuck Moore's Color Forth),and so on.
The main thing is I am moving forward in learning more. I don't think I will ever be blindly loyal to one particular solution.
Regarding the costs of the FPGA with board...
It is difficult for me to say that they are too expensive. The BeMicroCV cost me only $49.00USD and includes several useful additions that a Propeller 1 does not -- an SDcard slot, DDR3 Ram, and so on.
Some say the FPGA producers are dumping their cheaper products on the market place. But it could be that inexpensive FPGA boards may been the next shift in hardware. That would mean that CPU architecture may be shifting from being hardware/firmware to being software.
Of course, the greatest burden with the FPGAs is the huge compiler programs (and their purchase cost if you actually buy one). Also, there is the fact that Altera seems to only provide a 64bit IDE. So one must have the right hardware to compile code for these.
When the Propeller 2 arrives, the whole FPGA solution may collapse into being too demanding of time and resources. But, it is hard to say for sure. I certainly do not desire to DIY ball-gate-array chips, but I do like buying a blank slate that will let me design a CPU to specifics.
Chip has spent many years just designing the P1 and now the P2 and the tools to get them running. As much as I probably would like to have lots of time to do the same I also would not want to miss out on all the applications that I could use them in and the fun of bringing a system to life and seeing it put to use.
Let's face it, all the hard work and sweat and tears that goes into a CPU is buried under all that epoxy, hidden away and in itself "unexciting" in that unlike Hollywood tech it doesn't blink and bleep and conquer the world or even make the headlines like Ahmed's homemade clock. It's just a little black blob, a boring "silicone (sic) chip"
And I don't have a product to tout as being superior to all others.
Finding that 'killer application' that will make me rich is not as appealing to me as learning how FPGAs can actually be deployed as a solderless mega-breadboard.
I am enjoying the journey and the puzzle that FPGAs offer. There may come a point that I will migrate to boards that combine a Propeller and a FPGA together. Soldering irons and 'order your own' boards to populate are likely to be the next item to disappear... like the paper straw, desktop calculators, slide-rulers, and all that other stuff.
Procurement of odd-ball components has always been an issue due to my living abroad, but now I can create my own in an FPGA rather that endlessly seeking the right item in the right package at the right price. Huge procurement headaches seem to just vanish.
The fact that Intel purchased Altera just may indicate that the FPGA will be far more central to our future in microcontrollers, both as a hobby and an industry. Microcontrollers have in the past decade been the biggest growth sector of silicon production and microcomputers seem to be taking a backseat.
So if you want to deny that possibility that FPGAs are the future and hang on to the past, feel free to do so.
Printing names on chopsticks or getting a balancing bot to wander about the room for bragging rights also is no big deal. I am just not that vested in ego or making money from all this.
As far as teaching kids, even with my English classes - the main focus is to teach kids how to enjoy working with their mind and applying effort. I also focus on teaching them that they have to constantly grow if they want to be winners in today's world. Too narrow a focus is bound to leave them short in life even if it makes one wealthy.
In truth, I actually have very few needs.
Adding robotics and networks to all and everything I live with just isn't necessary. I am driven by expanding horizons of understanding design, the interplay of concepts, and fundamentally whether technology is indeed going to take the world to a better place. I deeply enjoyed learning Madgwick and management of inertial guidance, but I haven't built a quad-copter.
So far, I have mixed feelings about all the technological. It is a merry chase, but is it making the planet better for all of us? I dunno.
Back in the days of reliable postal service, I never got as much junk mail in a month that the internet is capable of delivering now in one day. And now that the Kaohsiung police have covered all the streets in my neighborhood with video cameras, I see they are going back and installing more in the alleys. We all live with a lot of changes we never considered possible.
I watch, I wonder, and I learn. Forth on an FPGA adds something good to my day.