Hi,
Well, I am attempting to use Diamond IDE 3.5 on Fedora 22 - 64bit.
I finally got the Altera Quartus v15.0.2 working right in Fedora 22 - 64bit, so I will now work on the Lattice Diamond IDE 3.5 install in the same Fedora 22 - 64bit.
I previously was have problems with Diamond IDE 3.5 in Windows7 Starter 32bit, but it may have been that I was running out of disk space. Or I just didn't know enough to make it work well.
Altera seems to hang back from the latest versions of OSes, so Lattice may be in the same situation and Windows 10 might just be too leading edge for both.
These large installations are tedious -- everything gets done by waiting and storage problems easily get in the way. I will let you know ASAP if I get Diamond IDE 3.5 working and how the eP16 files compile, including the creation of dual port memory.
Up until now, most of what I have been sharing has been from reading the code while muddling through these installation problems. That appears to be coming to an end.
@Ale,
I presumed that I would quickly get Lattice Diamonnd IDE 3.5_x64 set up in Fedora 22, but it appears that was foolish.
Lattice uses a license scheme that checks the MAC address on the computer's Ethernet card. Traditionally these were specificed eth0, eth1, and so on. But RHEL and Fedora have changed the numbering scheme to something else that the licensing software won't recognize as it only looks for those eth# designation.
There is a fix, but it is a bit involved. This is all about a bit of software by FLEXnet, called the FLEXlm application. And it seems that while it works in Windows, they haven't keep up with security changes on the Linux side.
So until I sort this out, the application refuses to let me in, and I can't investigate why you might be having difficulties with creating of memory blocks.
++++++++++
In sum, you are better off playing with FPGAs in Windows and more than likely an earlier version such as Windows 7. But I would consider an upgrade from 3.1 to 3.5. The software actually seems to be a bit smaller at 1.2Gbytes.
Gosh, this gets a bit silly. Along the way, I have successfully compiled PIV and loaded it to the BeMicroCV, and that is the only complete success.
All I really want to do is to get both Quartus II v15.0.2 and Diamond IDE 3.5 working and stable so that I can explore FPGAs ==> especially P1V and eP16 Forth.
A. I started with Lattice Diamond IDE in Windows7, but ran out of space on my netbook hard disk -- had to try something else.
B. I started with Quartus II in Debian as I don't have a 64bit version of Windows. Quartus II wasn't working perfectly in my Debian Jessie amd64, I decided to migrate that to Fedora 22 which is closer to RHEL (Red Hat Enterprise Linux).
C. Since Lattice Diamond IDE 3.6_x64 comes in an RPM package format, I presumed that it would be easiest to install in Fedora 22 as RPM is a Rad Hat application.
D. Fedora 22 no longer directly supports RPM or YUM and has gone over to 'dnf'; so it took a bit of extra effort to get the package installed in Fedora 22
E. Fedora 22 is Selinux and has quit the eth# designation if network ports for something like enp3s0, which won't work with the Diamond IDE license MAC address verification software (needed even for the free version)
F. Changing the Fedora 22 back to providing the eth0 rather than the enp3s0 is a rather extensive modification.
G. It seems that Debian Jessie amd64 will provide the eth0 without modification and I can install an RPM installer very easily to install Diamond IDE 3.6_x64.
And so, in my little triple boot world...
1. I dumped Quartus II v15.02 from Debian Jessie 8.1 amd64, and found joy and happiness for it in Fedora 22 (installs easily with one minor tweak)
2. It seems Diamond IDE 3.5_x64 is going to find a better home in Debian Jessie 8.1 amd64, and may need to stay way from Red Hat related distributions.
3. The third boot is Windows Vista 32bit in Chinese only and the system administration pop-ups drive me crazy. It just sits in reserve for that 'absolutely must use
Windows' situation.
I am sure this makes Windows users feel much more vindicated, but I still feel that I have enjoyed what I learned in Linux.. stuff that Windows might never teach you.
$ sudo rpm -ivh diamond_3_5-base_x64-102-x86_64-linux.rpm (worked just fine)
seems to have worked just fine - ended up putting diamond in /usr/local/diamond/3.5_x64
generate a license file with your ethernet MAC address - done through the Lattice website
put the license.dat file that is emailed to you in /usr/local/diamond/3.5_x64/license
OK, this is where it is a bit of a pain - Fedora is using consistent network device naming (a feature?) so you get a interface name like enp2s0 (in the case of my machine) instead of eth0
So you lie to the computer - create a /etc/udev/rules.d/70-persistent-net.rules file containing this line (except use the MAC address you registered with Lattice):
Now, go to /etc/sysconfig/network-scripts and copy the ifcfg-xxxxx file for your funny named ethernet interface to ifcfg-eth0
Edit that new file so the line with NAME=funny_name says NAME=eth0
REBOOT
Now, when you do ifconfig, you should see eth0.
When you do start diamond, you should get into the IDE and be ready to run. I need to create a symlink to mine because /usr/local/diamond/3.5_x64/bin/lin64/diamond is too much for me to type!!
I don't have a Lattice FPGA board yet to actually try any programming.
I now have Quartus II 15.02, Xilinx Vivado and Lattice Diamond all running on the same Linux distro installation under the same user and haven't seen any problems. I need to install Xilinx ISE next then my collection is pretty complete.
@mindrobots
I imagine this is all boring to some people, but it is useful knowledge and I suspect we will be seeing more and more hobby use of FPGAs. There seems to be a 'Proprietary Free-Masonry' that gets all vague about using any OS with their application that is Free. I have been going slow with this because it is all too easy to brick one's hard disk if one rushes into things. Yes, I have reloaded OSes at least 3 or 4 times as I have been working on this... reloads are reasonably fast in Linux.
Thanks, I still have Diamond IDE installed in Fedora 22, so I will give this a try. What I found as a work around on the Web seemed rather challenging and unnecessary. I have spent years avoiding Selinux due to some bad experiences in learning it. So I figured it was better to go back to Debian.
So these days, I have finally been learning the Red Hat way and the Selinux security -- quite a bit.
Meanwhile, I worked on the Debian 8.1 Jessie amd64 solution, which involved some much needed housekeeping (I reinstalled it with a completely new User, though I saved all my old /home/<old User> to be later migrated to the new user.
That is intended to get rid of some hidden dot files and dot directories that stayed on through several changes in distributions.
++++++
And the best part...
I installed 'alien', which is Debian's app to cover RPM packages for a 'dpkg' install. Then I converted the whole 1.2Gbytes to a .deb file and have installed it. I just have to see if it will boot and behave.
++++++
So I will continue on with BOTH installs and let everyone know which works best.
I'm having fun, learning things (can I say that these days???)
I was either going to find a way to make it work or send an email to Lattice saying they need to reconsider their licensing. As a free license holder, I'm sure that email would have carried much weight!!
I started looking for ways to change the bios derived name back to good old eth0 and the steps above seemed most promising and easiest.
======
I had tried alien on a couple rpm packages and it didn't work. I'm glad it worked on the BIG Diamond download.
======
I don't seem to be getting much done lately beyond system administration but I am at least learning more about that process. (My user is really grouchy, though!! )
Okay, I got Diamond IDE 3.5 working in Debian Jessie 8.1 amd64. Conversion with alien did work. Started up nicely on the first try.
It is 4:30AM.
Now I will go back and try to get the Fedora 22 installation to work as well.
For the record....
How did I successfully use 'alien' to convert the .rpm to .deb?
Well I did have to do about 4 attempts at conversion to get it right. And the first 3 I interrupted, had to clear unfinished work that prevents a clean run, and started over. The --veryverbose provides you with a better idea of what all is being done and why it is taking so long.
1. Use -d to create a .deb target
2. Do not use the -i to install the package, I installed with dpkg in a normal manner as su.
3. Use -c to include all the shell scripts. (Alien will tell you if it is ignoring shell scripts if you forget this.)
4. Use the --veryverbose to monitor the process.
5. Remove all the failed attempts leftovers before attempting another good run, that includes the failed final target, and the failed interim working directory. You will have to do this in Terminal with rm -r. You can't just move to Trash. Leftover files will block alien from finishing.
6. Give it all enough time. Near the end it hangs is what appears to be a finished state, but doesn't return to a Terminal prompt. It isn't finished. It is a big file, so give it plenty of time to get it right.
So the conversion command looks something like this below.. when in the same working directory as the <target .rpm file> (I used /home/<user_name/Desktop/ for my working directory)
@mindrobots
Here is a link that offers what seems to be ALL the alternatives for fixing FLEXlm problems due to no eth0.
I do wonder if these will work if you actually seek Lattice web support within Diamond IDE as that might try to check via another avenue and come up with something different. Rolling the OS back to using eth0 seems to be the wisest alternative if this is the case.
FLEMlm is likely to resurface for Linux users of Free versions of commercial software as the corporate world seems to think they have the right solution. Frankly, the new Linux ethernet designation that is BIOS sources is more difficult to cheat. MAC addresses in Linux can easily be replaced with a dummy in software. So the registration has no real ability to tie the installation to an actual physical network card.
BTW - The Korora Project is yet another fork of Fedora that is supposed to make it easy for the end-user to have an OS that provides desired features that are hard to maintain or install in Fedora. That is interesting.
Ah....... installation of IDEs seems to have settled down, finally.
What's next.
A. Attempt a conventional compile and load of eP16 on the Lattice XP2 Brevia2
B. Attempt a conversion of the working VHDL code into Verilog in the Diamond IDE
C. Attempt a migrate to Quartus VHDL and load of eP16 including new ram_memory.vhd generated for the BeMicroCV
D. Attempt a conversion of that working VHDL code to Verilog
E. Compare the Lattice generated Verilog to the Altera generated Verilog as a preliminary study.
The main thing here is to be studying the differences with an actual working project and not the short tutorial examples that indicate very little.
++++++++++
After all that is done, I will being to try to Frankenstein the eP16 into an eP32, and than a eP32/Propeller-like 8 CPU scheme.
Okay, here is a list of warnings in a first attempt to build ep16 in VHDL in Diamond IDE.
You can see which file, which line, and how many spaces in the offending item in code is. That is enough to get started with some serious VHDL debugging. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
While the attempt came through without any errors, a lot of these warnings are serious enough to need a solution. I suppose the 'no errors' means that the basic VHDL files are good enough to presume they will work IF the warnings are addresses.
The attempt was done without i/o pinout assignments and that is the source of some of the complaints. Adding i/o pin assignments will resolve many of the complaints, but not all.
I do see that the wrong value in Slot was noticed.
I also see the CTS problem that needs a pullup resistor to Vcc.
I am NOT sure what all the 'no load' complaints are about. I have used the existing ram_memory.vhd file and not tried to create a new revision.
Well, I am following a few loose ends and promises... like Selinux and actually running Diamond IDE from the RPM file in Fedora 22
Actually, I may have to use the Fedora version as their is a new patch RPM file for 3.5 and it fails to convert with 'alien' to a working .deb file. It seems that the patch switched to using csh, rather than bash. Alien seems to only tolerate bash, and I end up with half the automated install in Bash and the final bit in csh.... So I am wonder if Fedora will not be so finicky.
RPM is quite a complicated program. That worries me. It is for installing, making, and debugging .rpm packages... a bit over the top on choices. But NOTE - the Lattice Diamond IDE for Linux says to use 'rpm' in install mode for their updates. 'rpm' does have a couple of other modes for up-dating, but I guess we should avoid those.
I said I would get Diamond IDE running in Fedora 22 as well as Debian, so I decided to use the method that requires me to change the Ethernet port each and every time in advance of starting the Diamond IDE. It simply is the safest, most conservative means.
This was because I dread that Selinux might give me grief in the future.
+++++++++ Results
Diamond IDE 3.5 is up and running, but needs further work to get the documentation from Lattice on the Web. (
That same problem may exist in Debian, I need to go back and confirm)
I have had the same web documentation problem with Quartus II in Debian, but not Feodora - go figure. But now that the problem is becoming an old friend, I may figure out more about how to resolve. I saw something about the need to install some sort of hook up to a special version of Mozilla....
+++++++++
For the past few days, I have been thinking that Fedora 22 must install with Selinux OFF for all this spoofing of Ethernet ports to work.
So I ran down some info on how to get the Selinux status. You have two choices to use [1] getenforce, or [2] sestatus.
Both offer good results with sestatus providing more detail.
So silly me, I guessed wrong. Selinux out of the box is active in its highest security role.
Here attached are what comes up in Terminal. And this has me thinking it may be safe to make a permanent spoof of the eth0 port.
A bit more progress.... 'has no load' messages
IN the Warnings listing of FirstTry that I provided above, it appears that all the 'has no load' messages are referring to individual cells in memory that remain unintialized.
Most of it is the end of the 16x4096 RAM cells that could have been declared as empty in the mem.mif file. Bit it appears that file merely provided values that were actually Forth code or marking spaces for buffer use.
Other items are small items, such as the RX and TX counters.
+++++++++++++
I strongly suspect that the 'has no load' list may not need to be resolved at all. If that is the case, [1] ram_memory.vhd is good as provided, and [2] the details to get a working eP16 appear to be a relatively short list.
I have been pondering the Warnings Listing while fooling with all the installation problems. So it seems in a few days, I might actually have a working eP16 loading in the Lattice XP2 Brevia2, AND a good idea of how to generate a similar eP16 in the BeMicroCV.
Spent some time trying to interpret the Warnings List.
I had hopes that Lattice would provide a document that reveals what these things mean, but I can't find one. And my Diamond IDE 3.5 installations in both Debian and Fedora do NOT properly link me to the Web to get documents from Lattice while working within Diamond IDE. (I had a similar problem with Quartus in Debian, but in Fedora with tweaks.. the problem went away.)
Nonetheless, I am moving on in an attempt to work with the less-than-perfectly-installed software.
+++++++++++
For the most part, the Warnings may not be serious at all. But if you actually try to build the eP16 by following C.H.Ting's ep16inVHDL.pdf, there are some frustrations in the presentation.
Reading C.H.Ting's document gets a bit muddled. Here is how... consider this your 'sweat equity' for using his many years of developing eP16 Forth.
a. It tends to lead you through rebuilding the ram_memory.vhdl and that appears entirely unnecessary.
b. The next step is a simulation that is wise, but a bit awkward.
c. Then comes the pin i/o assignments which provide a good list - but no real explanation of how these get set up in Diamond IDE.
d. Some of the functional issues that I worry about come up both in the simulation and the actual pin i/o assignment. Warnings has provided me with an idea of what to watch.
It seems we are in dire need of a pull-up to Vcc on CTS, that we might as well include CTS and RTS pins, and that the five Interrupt inputs should be pulled either up or down for the sake of stable running.
e. There are a few typos that really cause tailspins. Fig. 6 mentions 5 slots, which relates to the eP32, not the eP16. It should be 3 slots. And, the i/o configuration file is called a .pdf, which it is certainly NOT.
===========
The basic problem here is that FPGA software is vast, the documentation is vast, and the installation is complex. A new learner just doesn't know where or why to take short cuts.
I presume what I have installed will work for the completion of this project. But I have my nose in manuals and search engines trying to find how to get a basic build from beginning to end.
What's next?
I really need to get the simulation done cleanly. That means not only including the Clock and the Reset as C.H.Ting suggests, but also providing for CTS and the Interrupts.
If that all goes well, according the C.H.Ting the serial port should sent out <CR> that indicates the compile is successful. And, this will also indicate exactly how important the proper termination of those other signals is.
How does one generate a proper i/o document?
Well C.H.Ting mentions the document and show an almost full specimen (lacks the RTS and CTS). But I only get a blank one in my software. The Lattice literature specifically states that some line items should be automatic generation, so just copying the specimen may behave poorly.
For now, I have discovered a hardware window in spreadsheet format. And that seems to be promising. It may be the proper place to enter all the i/o Pin assignments. And I still need to read a wee bit more on how to code pull-ups and pull-downs in VHDL.
If those solutions work, I will get through the simulation and have something ready to load. Now that I know what I am looking for reviewing a Lattice video or tutorial might help.
I have been working on what to do about running a simulation, and what to do about assigning the i/o pinouts for the final design.
Lattice does provide a 64 page Diamond IDE 3.5 tutorial that is now making a lot of sense to me.
+++++++++++++
I had assumed that C. H. Ting's assignments as provided in fig. 23 were good, and most are somewhat okay.
But 5 of the 16 bit i/o port signals are assigned to the first 5 bits of the SRAM on the XP2 Brevia2. That seems all wrong to me.
Frankly, all the interrupts are assigned to DIP switches, and the 16bit gpio have 8 bits assigned to LEDs, 3 bits assigned to DIP switches, and the above mentioned 5 bits assigned to SRAM.
I might use the DIP switches and LEDs -- but haven't the foggiest as to what 5 bits of data are attached to SRAM which has none of its addressing attached - and which the text claims in NOT included in the eP16 design scheme.
Of the remaining 4 pins,
2 are the the serial Tx and Rx that are hardwired to the FTDI USD to serial device. So it seems that I should eventually assign CTS and RTS to their respective FTDI hardwire pins and plan to get started with a Termiinal that includes hardware flow control being active.
The other 2 pins are the aclk and the arst inputs.
The arst is assigned to the devices hardwire Reset, so that seems good.
All the above was taken from Tables on page 11-14 in a Lattice XP2 Brevia2 document. But for the aclk, I have to dig to locate a 50Mhz osciallator that is hardwired to pin 21.
The Conclusion --
Revise the whole i/o pin assignment list to a final design something that uses the 16pin GPIO header, and the other header or switches for the interrupts.
But also provide an interim test bench configuration that is safe to use and that allows me to verify Forth is doing what it should.
___________________
I suppose all my concern about pull-up and pull-down resistors should go away if items are hardwired to other devices (like the CTS and the RTS signals). And it seems I have a bank of switches that have active pull-ups when open, while pulled to ground when closed. Those for the interrupts seem be fine... at least for now. I simply don't know what I will need to use interrupts for.... even considering removing the feature.
Oh, no!!!
I settled in to some serious reading of my Diamond IDE 3.5 tutorial on my Intel Quad 64 bit -- the computer that has all and everything installed for this and other FPGA project, only to find it now unstable and randomly rebooting after 5 to 60 or so seconds.
Yes, this is my main desktop computer that is failing.
It doesn't matter which of the OSes I use in the triple boot. Unless I am just getting extremely dirty power from outside, it is likely to be a power supply, a motherboard, or a hard disk failure. I just hope it is the power supply, and I do have a spare that I can swap out and observe.
So far, the power supply voltages look okay, so it may not have damaged the motherrboard or storage. And the temperature of the CPU is fine. But the computer itself is out of order until a lot of fundamental repair diagnostics resolves the instability. I've never had power spike problems here, so I don't really think that is the cause.
It could also be a hard disk that is stalling its disk motor. But so far I haven't gotten into the computer for enough time to get hard disk health reports.
I also need to run a DDR3 stability test (comes with the Linux Live CDs).
+++++++
What can I do?
Keep on truckin'.
Reload Lattice Diamond IDE 3.5 32-bit in Windows 7 starter after making space for it. (Actually, I already got this done and have Diamond IDE 3.5 installed in 3 different OSes.)
I won't be able to do anything with the Altera Quartus II until I get the 64bit machine right, or replaced. But I can limp along in Windows 7 Starter. The IDE software install in Win7 actually is the cleanest install I have amongst the three.
But Windows 7 Starter refuses to let me turn off the automatic update process. That wastes a lot of time turning on and turning off the netbook.
A lot of back and forth in trying to get eP16 in VHDL to run in Lattice Diamond IDE 3.5.
I am looking forward to moving on the Altera Quartus II v15.0.2 which actually seems to be a complete sucessful installation in Fedora 22 64bit. It seems very obvious now that all my attempts to install Lattice Diamond IDE 3.5 in Linux will run only the basic compiler and not the Lattice Active HDL simulation software that I REALLY NEED to confirm that the ep16 will run right on the target hardware.
Any progress?
Yes, I managed to eliminate the CTS complaints, and the Slot complaints in warnings by cleaning up code. In the case of the CTS, I just added a line of code that set holds CTS to '1' at all times. And, I changed the Slot range from 0 to 3 to reflect the 16 bit reality as the 0 to 5 range was for the 32bit ep32.
That left me with just some odd conflicts on what seems to be an internal systems bus with acknowledging something, maybe interrupts. There actually may be some redundant declarations that new to just be remarked out or removed. I have high hopes that if I resolve this, I can get Active HDL to give me a good simulation as I still have my one and only complete Lattice Diamnod IDE 3.5 reinstalled in Windows 7 Starter.
Once I get the ep16 running and loaded n a Lattice XP2 Brevia2, I will immediately migrate to the BeMicroCV and Quartus II.
Is this all worth it?
Well, maybe NO.
All the code I have for the eP16 in VHDL is clearly noted as property of C.H.Ting and 'all rights reserved'. In other words, anyone that really wants to use this Forth machine architecture will have to get a license from C.H.Ting or find another independent solution.
The code is there for reading and study. And even after I fit it all, I have no rights to reproduce and sell the code independent of C.H.Ting. But it is not all negative. It is a good contrasting study example to a conventional microcontroller model in VHDL. Lattice offers both an 8 bit and a 32 bit model that can be compared as to complexity and writing style. So at the very least this is a good way to get started in CPU designs in FPGA. There are several other proposed Forth CPUs in FPGA, but starting with the one that is nearest to complete has huge advantages. One gets some idea of all the processes required to build a Forth CPU - including the creation of a starting dictionary, the need to simulate before loading to determine if it will run, and some time in the trenches of running down loose ends in the Warnings.
The code is there for reading and study. And even after I fit it all, I have no rights to reproduce and sell the code independent of C.H.Ting. But it is not all negative. It is a good contrasting study example to a conventional microcontroller model in VHDL. Lattice offers both an 8 bit and a 32 bit model that can be compared as to complexity and writing style. So at the very least this is a good way to get started in CPU designs in FPGA. There are several other proposed Forth CPUs in FPGA, but starting with the one that is nearest to complete has huge advantages. One gets some idea of all the processes required to build a Forth CPU - including the creation of a starting dictionary, the need to simulate before loading to determine if it will run, and some time in the trenches of running down loose ends in the Warnings.
That's right. And from all that you learn, a lot. And that is what is important (IMHO).
I wrote a couple of Forth cores, more or less in working condition. Just the other day I looked at GreenArrays' (skimpy) Datasheet and wondered how would I write such a core (using a clock, of course) It packs up to 4 instructions in one word... pretty cool , simple opcodes but powerful nontheless. 1,5 ns per opcode... niiice
Today I decided to go back to my beloved pet project: The 6309 core. This time I'll try (yet) another approach.
Using the code I posted a few days back I was able to compile the eP16, no idea if it works, though.... I have to put a board together and do some tests...
@Ale,
If there is one thing that C.H.Ting's ep16 in VHDL has demonstrated to me, it is that just compiling someone else's code, loading it, and hoping it will run is NOT enough... potentially unwise.
It is important to be able to run the code in simulation and verify it is working before bothering to load it to your actual FPGA. I am not sure that you can directly damage the FPGA with the wrong code. But I already damaged on i/o pin on my BeMicroCV by a wrong add-on board. If you send output to unexpected places, you may get unexpected damage.
The real baseline, is that one really has to know their FPGA and the related software to do well with these devices. Damaging and replacing FPGAs can get expensive quickly.
+++++++++++
I have two GA144 chips and they confounded me. But now that I have been working with the eP16, I begin to see that I missed a lot. Yes, the data sheets for the GA144 leave lot to be desired, and most of it is marked Preliminary.
So it seems one by-product of using the eP16 is that I am becoming more professional in how I attempt to use the FPGA. I knew I was a rank beginner and would have these issues.. so the material by C. H. Ting has at least pointed me in the right direction.
Lattice tutorials don't do much to explain the all-important .lpf fie. That is where one designates pin-out assignments. So after running around in circles, I just opened and added all the pin-out assignments as I desired, but left out any of the timing related assignments as they appear to be generated by software and may cause problems. I won't add the timing assignments until I fully understand why I should do so, and I suspect I don't need to.
The other by-product of exploring the eP16 is that I may one day actually get my GA144 chips running. It seems that the two are related architecture and given the under-the-hood peek at the ep16, I begin to see areas I didn't comprehend.
++++++++++
So my main advice with the eP16 is the following.
1. Compile the basic 5 files and look at the Warnings.
2. Add all the i/o assignments to the .lpf file to get something that will actually work with interrupt vectors and LED displays - but understand this is not the final i/o you may desire -- only a bench test set up. Don't include the timing assignments in the .lpf that you see in the C. H. Ting screen dump.
3. Have CTS driven high to stop that nonsense, change to 4 slots as 16 bit should have, run-down the loose ends in redundant internal bus interrrupt acknowledges.
4. Try to get that to run in the Simulation software - Active HML and do what C.H. Ting claims it is supposed to do -- output a <CR> to the Tx from a cold boot.
5. If the Simulation is satisfactory, then do a recompile and create the binary to load.
I previously skipped steps, got something in a binary that did load into my Lattice XP2 Brevia2 - but it now won't talk to the outside world and none of the LEDs will light. I suppose I should go back and attempt to load the binary that came installed and run some verification that I didn't damage it -- before trying to load anything else.
Just jumping ahead and presuming someone else did good work may end up with bad results. Learning how to check the code and run simulations is empowering. I think I could even run simulations on each individual VHDL file if I have too. Right now, I am just trying to run one for the whole eP16 scheme.
Just another day of effort.
I had expectations that I might actually get the Active-HDL simulation to finally give me a good indication I have something that can be loaded and run for eP16. But no luck.
It seems that the Simulation software is in many ways more complex than the compiler. So I ended up getting quite confused after several attempts. There is simply more to learn and more to review in the eP16 in VHDL pdf.
I also did re-confirm that Lattice does NOT provide the Active-HDL in thier Linux verison, so I have to use the Windows version to have simulation. I can't find anything in their literature about this, but the Windows configuration shows the proper environment set up for Active-HDL. I simply cannot locate the Active-HDL binary in either the Debian or Fedora installition I have.
++++++++++
Being frustrated with Lattice, got me to get back into Quartus II v15.0.2. In particular, trying to get the 2-Port RAM memory module generated in VHDL that is critical to getting the ep16 runnng on a BeMicroCV.
I had tons of frustration with this... especially since I actually got the IP Core to run the module once. Finally after many hours of poking at different things, I started the Quartus, not from the Icon -- but from the terminal and the IP Core that I desired ran beautifully.
Upon investigating, the Icon uses ./quartus/bin/quartus --64bit, and from the terminal I omitted the --64bit. So I guess that the IP Core library has 32bit code that is blocked when you start with the --64bit designation.
=========
That brings me to pretty much having both the Lattice Diamond IDE 3.5 working right in Windows, and the Quartus II v15.0.2 working right in Fedora 22 64bit. And my biggest problems with the ep16 in VHDL for both targets remains just learning how to tweak the code so it will run under a simulation.
Gosh, I really thought I would have things up and running in Quartus by now, but set backs on two fronts have appeared.
First Item...
I just have no luck with replicating how my Megatrends IP Cores for Two Port Ram works. I thought the log in without the --64bit was the solution, but apparently not.
I did locate a Quartus V14 tutorial User Guide for RAM and ROM that details how to use Megatrends, and I have read the more general IP Core material for V15 that mentions that Megatrends is their older, legacy software (with different methods to intantantate - the new way and the legacy way). Ugh. it just gets more and more invovlved to get that ram_memory.vhdl module.
I did have something, but it wasn't quite right as I had a port for write address, and a separate port for read address, and was missing another logic input that I needed.
Second Item...
Beware of missing white spaces or added white space. Beware of code that compiles but is sloppy. Both can cause big trouble.
Defects in style in C.H. Ting's code do exist. The more I read and learn VHDL, the more I see little things that are not quite right. So far my efforts have been mainly focused on the Top file, and the eP16.VHD that is the CPU file. I just presume the rest is A-Okay.. at least for now.
The Top VHDL file includes Port declarations, Port maps, and buses. Some of this stuff goes nowhere. Other items have assignments that make little sense to me. So I have to untangle all of it. Just the fact that Port maps use => for their assignments, ant use <= for equations operating on those assignments had me digging for a few days. It doesn't help that VHDL is NOT case-sensitive, as the author seems to have enjoyed being wishy-washy about upper and lower case.
The most important thing is that VHDL will allow you to have a module with some of its i/o that eventually is unused, but the good form is to assign it to 'open'. And I don't see any 'open' assignments in the eP16 VHDL files. I have quite a few lines that I need to add 'open' to.
In the eP16.VHD file, their is a 'generic' called width that creates a constant of 16. The compiler has been complaining about this from the start in relation to a sensitivity list not including 'i' where 'i' is really 'i(width - 1) in the line of code where the complaint originates.
Now I have discovered that the code reads 'width: .....' and there should be a white space between the width and the colon.
+++++++++
And so, I have been deeply imersed in VHDL and not gotten more than a few peeks at the Verilog code for P1V. Actually, the Verilog looks harder for me to read than the VHDL, but that judgement may be premature. But Verilog seems to require more detail.
Comments
Well, I am attempting to use Diamond IDE 3.5 on Fedora 22 - 64bit.
I finally got the Altera Quartus v15.0.2 working right in Fedora 22 - 64bit, so I will now work on the Lattice Diamond IDE 3.5 install in the same Fedora 22 - 64bit.
I previously was have problems with Diamond IDE 3.5 in Windows7 Starter 32bit, but it may have been that I was running out of disk space. Or I just didn't know enough to make it work well.
Altera seems to hang back from the latest versions of OSes, so Lattice may be in the same situation and Windows 10 might just be too leading edge for both.
These large installations are tedious -- everything gets done by waiting and storage problems easily get in the way. I will let you know ASAP if I get Diamond IDE 3.5 working and how the eP16 files compile, including the creation of dual port memory.
Up until now, most of what I have been sharing has been from reading the code while muddling through these installation problems. That appears to be coming to an end.
I presumed that I would quickly get Lattice Diamonnd IDE 3.5_x64 set up in Fedora 22, but it appears that was foolish.
Lattice uses a license scheme that checks the MAC address on the computer's Ethernet card. Traditionally these were specificed eth0, eth1, and so on. But RHEL and Fedora have changed the numbering scheme to something else that the licensing software won't recognize as it only looks for those eth# designation.
There is a fix, but it is a bit involved. This is all about a bit of software by FLEXnet, called the FLEXlm application. And it seems that while it works in Windows, they haven't keep up with security changes on the Linux side.
So until I sort this out, the application refuses to let me in, and I can't investigate why you might be having difficulties with creating of memory blocks.
++++++++++
In sum, you are better off playing with FPGAs in Windows and more than likely an earlier version such as Windows 7. But I would consider an upgrade from 3.1 to 3.5. The software actually seems to be a bit smaller at 1.2Gbytes.
All I really want to do is to get both Quartus II v15.0.2 and Diamond IDE 3.5 working and stable so that I can explore FPGAs ==> especially P1V and eP16 Forth.
A. I started with Lattice Diamond IDE in Windows7, but ran out of space on my netbook hard disk -- had to try something else.
B. I started with Quartus II in Debian as I don't have a 64bit version of Windows. Quartus II wasn't working perfectly in my Debian Jessie amd64, I decided to migrate that to Fedora 22 which is closer to RHEL (Red Hat Enterprise Linux).
C. Since Lattice Diamond IDE 3.6_x64 comes in an RPM package format, I presumed that it would be easiest to install in Fedora 22 as RPM is a Rad Hat application.
D. Fedora 22 no longer directly supports RPM or YUM and has gone over to 'dnf'; so it took a bit of extra effort to get the package installed in Fedora 22
E. Fedora 22 is Selinux and has quit the eth# designation if network ports for something like enp3s0, which won't work with the Diamond IDE license MAC address verification software (needed even for the free version)
F. Changing the Fedora 22 back to providing the eth0 rather than the enp3s0 is a rather extensive modification.
G. It seems that Debian Jessie amd64 will provide the eth0 without modification and I can install an RPM installer very easily to install Diamond IDE 3.6_x64.
And so, in my little triple boot world...
1. I dumped Quartus II v15.02 from Debian Jessie 8.1 amd64, and found joy and happiness for it in Fedora 22 (installs easily with one minor tweak)
2. It seems Diamond IDE 3.5_x64 is going to find a better home in Debian Jessie 8.1 amd64, and may need to stay way from Red Hat related distributions.
3. The third boot is Windows Vista 32bit in Chinese only and the system administration pop-ups drive me crazy. It just sits in reserve for that 'absolutely must use
Windows' situation.
I am sure this makes Windows users feel much more vindicated, but I still feel that I have enjoyed what I learned in Linux.. stuff that Windows might never teach you.
$ sudo rpm -ivh diamond_3_5-base_x64-102-x86_64-linux.rpm (worked just fine)
seems to have worked just fine - ended up putting diamond in /usr/local/diamond/3.5_x64
generate a license file with your ethernet MAC address - done through the Lattice website
put the license.dat file that is emailed to you in /usr/local/diamond/3.5_x64/license
OK, this is where it is a bit of a pain - Fedora is using consistent network device naming (a feature?) so you get a interface name like enp2s0 (in the case of my machine) instead of eth0
So you lie to the computer - create a /etc/udev/rules.d/70-persistent-net.rules file containing this line (except use the MAC address you registered with Lattice):
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="dc:0e:a1:36:66:52", NAME="eth0"Now, go to /etc/sysconfig/network-scripts and copy the ifcfg-xxxxx file for your funny named ethernet interface to ifcfg-eth0Edit that new file so the line with NAME=funny_name says NAME=eth0
REBOOT
Now, when you do ifconfig, you should see eth0.
When you do start diamond, you should get into the IDE and be ready to run. I need to create a symlink to mine because /usr/local/diamond/3.5_x64/bin/lin64/diamond is too much for me to type!!
I don't have a Lattice FPGA board yet to actually try any programming.
I now have Quartus II 15.02, Xilinx Vivado and Lattice Diamond all running on the same Linux distro installation under the same user and haven't seen any problems. I need to install Xilinx ISE next then my collection is pretty complete.
I imagine this is all boring to some people, but it is useful knowledge and I suspect we will be seeing more and more hobby use of FPGAs. There seems to be a 'Proprietary Free-Masonry' that gets all vague about using any OS with their application that is Free. I have been going slow with this because it is all too easy to brick one's hard disk if one rushes into things. Yes, I have reloaded OSes at least 3 or 4 times as I have been working on this... reloads are reasonably fast in Linux.
Thanks, I still have Diamond IDE installed in Fedora 22, so I will give this a try. What I found as a work around on the Web seemed rather challenging and unnecessary. I have spent years avoiding Selinux due to some bad experiences in learning it. So I figured it was better to go back to Debian.
So these days, I have finally been learning the Red Hat way and the Selinux security -- quite a bit.
Meanwhile, I worked on the Debian 8.1 Jessie amd64 solution, which involved some much needed housekeeping (I reinstalled it with a completely new User, though I saved all my old /home/<old User> to be later migrated to the new user.
That is intended to get rid of some hidden dot files and dot directories that stayed on through several changes in distributions.
++++++
And the best part...
I installed 'alien', which is Debian's app to cover RPM packages for a 'dpkg' install. Then I converted the whole 1.2Gbytes to a .deb file and have installed it. I just have to see if it will boot and behave.
++++++
So I will continue on with BOTH installs and let everyone know which works best.
I was either going to find a way to make it work or send an email to Lattice saying they need to reconsider their licensing. As a free license holder, I'm sure that email would have carried much weight!!
I started looking for ways to change the bios derived name back to good old eth0 and the steps above seemed most promising and easiest.
======
I had tried alien on a couple rpm packages and it didn't work. I'm glad it worked on the BIG Diamond download.
======
I don't seem to be getting much done lately beyond system administration but I am at least learning more about that process. (My user is really grouchy, though!!
It is 4:30AM.
Now I will go back and try to get the Fedora 22 installation to work as well.
How did I successfully use 'alien' to convert the .rpm to .deb?
Well I did have to do about 4 attempts at conversion to get it right. And the first 3 I interrupted, had to clear unfinished work that prevents a clean run, and started over. The --veryverbose provides you with a better idea of what all is being done and why it is taking so long.
1. Use -d to create a .deb target
2. Do not use the -i to install the package, I installed with dpkg in a normal manner as su.
3. Use -c to include all the shell scripts. (Alien will tell you if it is ignoring shell scripts if you forget this.)
4. Use the --veryverbose to monitor the process.
5. Remove all the failed attempts leftovers before attempting another good run, that includes the failed final target, and the failed interim working directory. You will have to do this in Terminal with rm -r. You can't just move to Trash. Leftover files will block alien from finishing.
6. Give it all enough time. Near the end it hangs is what appears to be a finished state, but doesn't return to a Terminal prompt. It isn't finished. It is a big file, so give it plenty of time to get it right.
So the conversion command looks something like this below.. when in the same working directory as the <target .rpm file> (I used /home/<user_name/Desktop/ for my working directory)
alien -d -c --veryverbose <target .rpm file>
Here is a link that offers what seems to be ALL the alternatives for fixing FLEXlm problems due to no eth0.
I do wonder if these will work if you actually seek Lattice web support within Diamond IDE as that might try to check via another avenue and come up with something different. Rolling the OS back to using eth0 seems to be the wisest alternative if this is the case.
FLEMlm is likely to resurface for Linux users of Free versions of commercial software as the corporate world seems to think they have the right solution. Frankly, the new Linux ethernet designation that is BIOS sources is more difficult to cheat. MAC addresses in Linux can easily be replaced with a dummy in software. So the registration has no real ability to tie the installation to an actual physical network card.
You solution is included.
https://kororaproject.org/support/engage/question/flexlm-hostid-eth0-issue
BTW - The Korora Project is yet another fork of Fedora that is supposed to make it easy for the end-user to have an OS that provides desired features that are hard to maintain or install in Fedora. That is interesting.
WELL... that wasn't quite all the ways.
Here is another site's proposed fix...
http://www.sysarchitects.com/em1_to_eth0
I do wonder where that Selinux security is with all this spoofing. That was my original concern. ===> Maybe, these guys just didn't turn it on!
What's next.
A. Attempt a conventional compile and load of eP16 on the Lattice XP2 Brevia2
B. Attempt a conversion of the working VHDL code into Verilog in the Diamond IDE
C. Attempt a migrate to Quartus VHDL and load of eP16 including new ram_memory.vhd generated for the BeMicroCV
D. Attempt a conversion of that working VHDL code to Verilog
E. Compare the Lattice generated Verilog to the Altera generated Verilog as a preliminary study.
The main thing here is to be studying the differences with an actual working project and not the short tutorial examples that indicate very little.
++++++++++
After all that is done, I will being to try to Frankenstein the eP16 into an eP32, and than a eP32/Propeller-like 8 CPU scheme.
Still a ways to go........
You can see which file, which line, and how many spaces in the offending item in code is.
That is enough to get started with some serious VHDL debugging.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
While the attempt came through without any errors, a lot of these warnings are serious enough to need a solution. I suppose the 'no errors' means that the basic VHDL files are good enough to presume they will work IF the warnings are addresses.
The attempt was done without i/o pinout assignments and that is the source of some of the complaints. Adding i/o pin assignments will resolve many of the complaints, but not all.
I do see that the wrong value in Slot was noticed.
I also see the CTS problem that needs a pullup resistor to Vcc.
I am NOT sure what all the 'no load' complaints are about. I have used the existing ram_memory.vhd file and not tried to create a new revision.
Actually, I may have to use the Fedora version as their is a new patch RPM file for 3.5 and it fails to convert with 'alien' to a working .deb file. It seems that the patch switched to using csh, rather than bash. Alien seems to only tolerate bash, and I end up with half the automated install in Bash and the final bit in csh.... So I am wonder if Fedora will not be so finicky.
RPM is quite a complicated program. That worries me. It is for installing, making, and debugging .rpm packages... a bit over the top on choices. But NOTE - the Lattice Diamond IDE for Linux says to use 'rpm' in install mode for their updates. 'rpm' does have a couple of other modes for up-dating, but I guess we should avoid those.
I said I would get Diamond IDE running in Fedora 22 as well as Debian, so I decided to use the method that requires me to change the Ethernet port each and every time in advance of starting the Diamond IDE. It simply is the safest, most conservative means.
This was because I dread that Selinux might give me grief in the future.
+++++++++
Results
Diamond IDE 3.5 is up and running, but needs further work to get the documentation from Lattice on the Web. (
That same problem may exist in Debian, I need to go back and confirm)
I have had the same web documentation problem with Quartus II in Debian, but not Feodora - go figure. But now that the problem is becoming an old friend, I may figure out more about how to resolve. I saw something about the need to install some sort of hook up to a special version of Mozilla....
+++++++++
For the past few days, I have been thinking that Fedora 22 must install with Selinux OFF for all this spoofing of Ethernet ports to work.
So I ran down some info on how to get the Selinux status. You have two choices to use [1] getenforce, or [2] sestatus.
Both offer good results with sestatus providing more detail.
So silly me, I guessed wrong. Selinux out of the box is active in its highest security role.
Here attached are what comes up in Terminal. And this has me thinking it may be safe to make a permanent spoof of the eth0 port.
'has no load' messages
IN the Warnings listing of FirstTry that I provided above, it appears that all the 'has no load' messages are referring to individual cells in memory that remain unintialized.
Most of it is the end of the 16x4096 RAM cells that could have been declared as empty in the mem.mif file. Bit it appears that file merely provided values that were actually Forth code or marking spaces for buffer use.
Other items are small items, such as the RX and TX counters.
+++++++++++++
I strongly suspect that the 'has no load' list may not need to be resolved at all. If that is the case, [1] ram_memory.vhd is good as provided, and [2] the details to get a working eP16 appear to be a relatively short list.
I have been pondering the Warnings Listing while fooling with all the installation problems. So it seems in a few days, I might actually have a working eP16 loading in the Lattice XP2 Brevia2, AND a good idea of how to generate a similar eP16 in the BeMicroCV.
I had hopes that Lattice would provide a document that reveals what these things mean, but I can't find one. And my Diamond IDE 3.5 installations in both Debian and Fedora do NOT properly link me to the Web to get documents from Lattice while working within Diamond IDE. (I had a similar problem with Quartus in Debian, but in Fedora with tweaks.. the problem went away.)
Nonetheless, I am moving on in an attempt to work with the less-than-perfectly-installed software.
+++++++++++
For the most part, the Warnings may not be serious at all. But if you actually try to build the eP16 by following C.H.Ting's ep16inVHDL.pdf, there are some frustrations in the presentation.
Reading C.H.Ting's document gets a bit muddled. Here is how... consider this your 'sweat equity' for using his many years of developing eP16 Forth.
a. It tends to lead you through rebuilding the ram_memory.vhdl and that appears entirely unnecessary.
b. The next step is a simulation that is wise, but a bit awkward.
c. Then comes the pin i/o assignments which provide a good list - but no real explanation of how these get set up in Diamond IDE.
d. Some of the functional issues that I worry about come up both in the simulation and the actual pin i/o assignment. Warnings has provided me with an idea of what to watch.
It seems we are in dire need of a pull-up to Vcc on CTS, that we might as well include CTS and RTS pins, and that the five Interrupt inputs should be pulled either up or down for the sake of stable running.
e. There are a few typos that really cause tailspins. Fig. 6 mentions 5 slots, which relates to the eP32, not the eP16. It should be 3 slots. And, the i/o configuration file is called a .pdf, which it is certainly NOT.
===========
The basic problem here is that FPGA software is vast, the documentation is vast, and the installation is complex. A new learner just doesn't know where or why to take short cuts.
I presume what I have installed will work for the completion of this project. But I have my nose in manuals and search engines trying to find how to get a basic build from beginning to end.
What's next?
I really need to get the simulation done cleanly. That means not only including the Clock and the Reset as C.H.Ting suggests, but also providing for CTS and the Interrupts.
If that all goes well, according the C.H.Ting the serial port should sent out <CR> that indicates the compile is successful. And, this will also indicate exactly how important the proper termination of those other signals is.
How does one generate a proper i/o document?
Well C.H.Ting mentions the document and show an almost full specimen (lacks the RTS and CTS). But I only get a blank one in my software. The Lattice literature specifically states that some line items should be automatic generation, so just copying the specimen may behave poorly.
For now, I have discovered a hardware window in spreadsheet format. And that seems to be promising. It may be the proper place to enter all the i/o Pin assignments. And I still need to read a wee bit more on how to code pull-ups and pull-downs in VHDL.
If those solutions work, I will get through the simulation and have something ready to load. Now that I know what I am looking for reviewing a Lattice video or tutorial might help.
Lattice does provide a 64 page Diamond IDE 3.5 tutorial that is now making a lot of sense to me.
+++++++++++++
I had assumed that C. H. Ting's assignments as provided in fig. 23 were good, and most are somewhat okay.
But 5 of the 16 bit i/o port signals are assigned to the first 5 bits of the SRAM on the XP2 Brevia2. That seems all wrong to me.
Frankly, all the interrupts are assigned to DIP switches, and the 16bit gpio have 8 bits assigned to LEDs, 3 bits assigned to DIP switches, and the above mentioned 5 bits assigned to SRAM.
I might use the DIP switches and LEDs -- but haven't the foggiest as to what 5 bits of data are attached to SRAM which has none of its addressing attached - and which the text claims in NOT included in the eP16 design scheme.
Of the remaining 4 pins,
2 are the the serial Tx and Rx that are hardwired to the FTDI USD to serial device. So it seems that I should eventually assign CTS and RTS to their respective FTDI hardwire pins and plan to get started with a Termiinal that includes hardware flow control being active.
The other 2 pins are the aclk and the arst inputs.
The arst is assigned to the devices hardwire Reset, so that seems good.
All the above was taken from Tables on page 11-14 in a Lattice XP2 Brevia2 document. But for the aclk, I have to dig to locate a 50Mhz osciallator that is hardwired to pin 21.
The Conclusion --
Revise the whole i/o pin assignment list to a final design something that uses the 16pin GPIO header, and the other header or switches for the interrupts.
But also provide an interim test bench configuration that is safe to use and that allows me to verify Forth is doing what it should.
___________________
I suppose all my concern about pull-up and pull-down resistors should go away if items are hardwired to other devices (like the CTS and the RTS signals). And it seems I have a bank of switches that have active pull-ups when open, while pulled to ground when closed. Those for the interrupts seem be fine... at least for now. I simply don't know what I will need to use interrupts for.... even considering removing the feature.
I settled in to some serious reading of my Diamond IDE 3.5 tutorial on my Intel Quad 64 bit -- the computer that has all and everything installed for this and other FPGA project, only to find it now unstable and randomly rebooting after 5 to 60 or so seconds.
Yes, this is my main desktop computer that is failing.
It doesn't matter which of the OSes I use in the triple boot. Unless I am just getting extremely dirty power from outside, it is likely to be a power supply, a motherboard, or a hard disk failure. I just hope it is the power supply, and I do have a spare that I can swap out and observe.
So far, the power supply voltages look okay, so it may not have damaged the motherrboard or storage. And the temperature of the CPU is fine. But the computer itself is out of order until a lot of fundamental repair diagnostics resolves the instability. I've never had power spike problems here, so I don't really think that is the cause.
It could also be a hard disk that is stalling its disk motor. But so far I haven't gotten into the computer for enough time to get hard disk health reports.
I also need to run a DDR3 stability test (comes with the Linux Live CDs).
+++++++
What can I do?
Keep on truckin'.
Reload Lattice Diamond IDE 3.5 32-bit in Windows 7 starter after making space for it. (Actually, I already got this done and have Diamond IDE 3.5 installed in 3 different OSes.)
I won't be able to do anything with the Altera Quartus II until I get the 64bit machine right, or replaced. But I can limp along in Windows 7 Starter. The IDE software install in Win7 actually is the cleanest install I have amongst the three.
But Windows 7 Starter refuses to let me turn off the automatic update process. That wastes a lot of time turning on and turning off the netbook.
Trial and tribulations, oh my.
I am looking forward to moving on the Altera Quartus II v15.0.2 which actually seems to be a complete sucessful installation in Fedora 22 64bit. It seems very obvious now that all my attempts to install Lattice Diamond IDE 3.5 in Linux will run only the basic compiler and not the Lattice Active HDL simulation software that I REALLY NEED to confirm that the ep16 will run right on the target hardware.
Any progress?
Yes, I managed to eliminate the CTS complaints, and the Slot complaints in warnings by cleaning up code. In the case of the CTS, I just added a line of code that set holds CTS to '1' at all times. And, I changed the Slot range from 0 to 3 to reflect the 16 bit reality as the 0 to 5 range was for the 32bit ep32.
That left me with just some odd conflicts on what seems to be an internal systems bus with acknowledging something, maybe interrupts. There actually may be some redundant declarations that new to just be remarked out or removed. I have high hopes that if I resolve this, I can get Active HDL to give me a good simulation as I still have my one and only complete Lattice Diamnod IDE 3.5 reinstalled in Windows 7 Starter.
Once I get the ep16 running and loaded n a Lattice XP2 Brevia2, I will immediately migrate to the BeMicroCV and Quartus II.
Is this all worth it?
Well, maybe NO.
All the code I have for the eP16 in VHDL is clearly noted as property of C.H.Ting and 'all rights reserved'. In other words, anyone that really wants to use this Forth machine architecture will have to get a license from C.H.Ting or find another independent solution.
The code is there for reading and study. And even after I fit it all, I have no rights to reproduce and sell the code independent of C.H.Ting. But it is not all negative. It is a good contrasting study example to a conventional microcontroller model in VHDL. Lattice offers both an 8 bit and a 32 bit model that can be compared as to complexity and writing style. So at the very least this is a good way to get started in CPU designs in FPGA. There are several other proposed Forth CPUs in FPGA, but starting with the one that is nearest to complete has huge advantages. One gets some idea of all the processes required to build a Forth CPU - including the creation of a starting dictionary, the need to simulate before loading to determine if it will run, and some time in the trenches of running down loose ends in the Warnings.
That's right. And from all that you learn, a lot. And that is what is important (IMHO).
I wrote a couple of Forth cores, more or less in working condition. Just the other day I looked at GreenArrays' (skimpy) Datasheet and wondered how would I write such a core (using a clock, of course) It packs up to 4 instructions in one word... pretty cool
Today I decided to go back to my beloved pet project: The 6309 core. This time I'll try (yet) another approach.
Using the code I posted a few days back I was able to compile the eP16, no idea if it works, though.... I have to put a board together and do some tests...
If there is one thing that C.H.Ting's ep16 in VHDL has demonstrated to me, it is that just compiling someone else's code, loading it, and hoping it will run is NOT enough... potentially unwise.
It is important to be able to run the code in simulation and verify it is working before bothering to load it to your actual FPGA. I am not sure that you can directly damage the FPGA with the wrong code. But I already damaged on i/o pin on my BeMicroCV by a wrong add-on board. If you send output to unexpected places, you may get unexpected damage.
The real baseline, is that one really has to know their FPGA and the related software to do well with these devices. Damaging and replacing FPGAs can get expensive quickly.
+++++++++++
I have two GA144 chips and they confounded me. But now that I have been working with the eP16, I begin to see that I missed a lot. Yes, the data sheets for the GA144 leave lot to be desired, and most of it is marked Preliminary.
So it seems one by-product of using the eP16 is that I am becoming more professional in how I attempt to use the FPGA. I knew I was a rank beginner and would have these issues.. so the material by C. H. Ting has at least pointed me in the right direction.
Lattice tutorials don't do much to explain the all-important .lpf fie. That is where one designates pin-out assignments. So after running around in circles, I just opened and added all the pin-out assignments as I desired, but left out any of the timing related assignments as they appear to be generated by software and may cause problems. I won't add the timing assignments until I fully understand why I should do so, and I suspect I don't need to.
The other by-product of exploring the eP16 is that I may one day actually get my GA144 chips running. It seems that the two are related architecture and given the under-the-hood peek at the ep16, I begin to see areas I didn't comprehend.
++++++++++
So my main advice with the eP16 is the following.
1. Compile the basic 5 files and look at the Warnings.
2. Add all the i/o assignments to the .lpf file to get something that will actually work with interrupt vectors and LED displays - but understand this is not the final i/o you may desire -- only a bench test set up. Don't include the timing assignments in the .lpf that you see in the C. H. Ting screen dump.
3. Have CTS driven high to stop that nonsense, change to 4 slots as 16 bit should have, run-down the loose ends in redundant internal bus interrrupt acknowledges.
4. Try to get that to run in the Simulation software - Active HML and do what C.H. Ting claims it is supposed to do -- output a <CR> to the Tx from a cold boot.
5. If the Simulation is satisfactory, then do a recompile and create the binary to load.
I previously skipped steps, got something in a binary that did load into my Lattice XP2 Brevia2 - but it now won't talk to the outside world and none of the LEDs will light. I suppose I should go back and attempt to load the binary that came installed and run some verification that I didn't damage it -- before trying to load anything else.
Just jumping ahead and presuming someone else did good work may end up with bad results. Learning how to check the code and run simulations is empowering. I think I could even run simulations on each individual VHDL file if I have too. Right now, I am just trying to run one for the whole eP16 scheme.
I had expectations that I might actually get the Active-HDL simulation to finally give me a good indication I have something that can be loaded and run for eP16. But no luck.
It seems that the Simulation software is in many ways more complex than the compiler. So I ended up getting quite confused after several attempts. There is simply more to learn and more to review in the eP16 in VHDL pdf.
I also did re-confirm that Lattice does NOT provide the Active-HDL in thier Linux verison, so I have to use the Windows version to have simulation. I can't find anything in their literature about this, but the Windows configuration shows the proper environment set up for Active-HDL. I simply cannot locate the Active-HDL binary in either the Debian or Fedora installition I have.
++++++++++
Being frustrated with Lattice, got me to get back into Quartus II v15.0.2. In particular, trying to get the 2-Port RAM memory module generated in VHDL that is critical to getting the ep16 runnng on a BeMicroCV.
I had tons of frustration with this... especially since I actually got the IP Core to run the module once. Finally after many hours of poking at different things, I started the Quartus, not from the Icon -- but from the terminal and the IP Core that I desired ran beautifully.
Upon investigating, the Icon uses ./quartus/bin/quartus --64bit, and from the terminal I omitted the --64bit. So I guess that the IP Core library has 32bit code that is blocked when you start with the --64bit designation.
=========
That brings me to pretty much having both the Lattice Diamond IDE 3.5 working right in Windows, and the Quartus II v15.0.2 working right in Fedora 22 64bit. And my biggest problems with the ep16 in VHDL for both targets remains just learning how to tweak the code so it will run under a simulation.
A bit of progress, and a ton of frustration.
First Item...
I just have no luck with replicating how my Megatrends IP Cores for Two Port Ram works. I thought the log in without the --64bit was the solution, but apparently not.
I did locate a Quartus V14 tutorial User Guide for RAM and ROM that details how to use Megatrends, and I have read the more general IP Core material for V15 that mentions that Megatrends is their older, legacy software (with different methods to intantantate - the new way and the legacy way). Ugh. it just gets more and more invovlved to get that ram_memory.vhdl module.
I did have something, but it wasn't quite right as I had a port for write address, and a separate port for read address, and was missing another logic input that I needed.
Second Item...
Beware of missing white spaces or added white space. Beware of code that compiles but is sloppy. Both can cause big trouble.
Defects in style in C.H. Ting's code do exist. The more I read and learn VHDL, the more I see little things that are not quite right. So far my efforts have been mainly focused on the Top file, and the eP16.VHD that is the CPU file. I just presume the rest is A-Okay.. at least for now.
The Top VHDL file includes Port declarations, Port maps, and buses. Some of this stuff goes nowhere. Other items have assignments that make little sense to me. So I have to untangle all of it. Just the fact that Port maps use => for their assignments, ant use <= for equations operating on those assignments had me digging for a few days. It doesn't help that VHDL is NOT case-sensitive, as the author seems to have enjoyed being wishy-washy about upper and lower case.
The most important thing is that VHDL will allow you to have a module with some of its i/o that eventually is unused, but the good form is to assign it to 'open'. And I don't see any 'open' assignments in the eP16 VHDL files. I have quite a few lines that I need to add 'open' to.
In the eP16.VHD file, their is a 'generic' called width that creates a constant of 16. The compiler has been complaining about this from the start in relation to a sensitivity list not including 'i' where 'i' is really 'i(width - 1) in the line of code where the complaint originates.
Now I have discovered that the code reads 'width: .....' and there should be a white space between the width and the colon.
+++++++++
And so, I have been deeply imersed in VHDL and not gotten more than a few peeks at the Verilog code for P1V. Actually, the Verilog looks harder for me to read than the VHDL, but that judgement may be premature. But Verilog seems to require more detail.