I am deeply into the ep16 VHDL code now for the purposes of debugging and to migrate to the ep32 version as I want the 32bit for that final creation of 8 Forth Cogs.
But I am a bit concerns about the Altera IP Core software, Megatrends is refusing to work in Debian 8.1 Jessie amd64.
Whatever FPGA you desire to use, you will find the IDE to be a merry chase with finicky OS preferences.
++++++++++++++
I mentioned to Heater and Dr_Acula that the Z-80 has been recreated in FPGA. I think it might be possible to combine a P1V image with that to get a complete CP/M machine with SDcard file system on one FPGA board. The P1V would mostly provide terminal video, keyboard, and mouse services... maybe some GPIO.
Started the Quartus II V15.0 and left it running with it attempting to generate a VHDL file for a Two-Port RAM from the Altera IP Cores.
It may be that I just didn't realize how long that might take due to Altera removing the parallel processing from the Free version.
We will see
+++++++++++++++++++
Meanwhile, I am beginning to see how to migrate the eP16 code to eP32. I even have doubts that the eP16 was successful ported from eP32 originally. I have references for both... so putting it back into eP32 may settle everything down.
Right now the GPIO is 16 bit port. I may expand that to a 32 bit port as well if the FPGA will tolerate such. The Lattice XP2 Brevia2 does not have enough i/o pins for 32 bit GPIO.
+++++++++++++++++++
In any event, I don't have Lattice Diamond IDE loaded in any computer at this point, so I am focusing on some how making Quartus II V15.0.2 work well.
Quote "I mentioned to Heater and Dr_Acula that the Z-80 has been recreated in FPGA. I think it might be possible to combine a P1V image with that to get a complete CP/M machine with SDcard file system on one FPGA board. The P1V would mostly provide terminal video, keyboard, and mouse services... maybe some GPIO.
I love this blue sky thinking! Well, interesting you chose that link because Will Sowerbutts wrote the MMU we are using on the CP/M machine we are running on the cyclone IV.
It is similar to the propeller obex, where you grab objects written by lots of different people and join them together. So the z80 core is written by one person, the MMU by another, the SD controller by a third person.
There are pages and pages of discussion on this forum about what people wanted to see on their particular version of the propeller. Now the code is open source, anyone can build these things themselves. Why not a hardware uart in fgpa, and a software uart on a cog... running at the same time.
I guess the big barrier is getting into fpga in the first place. It is a bit daunting to start with, but great fun once you realise how components interact with each other, and very similar in a way to working with real hardware. Data busses, address busses, control signals.
I was very happy to see that someone mentioned that the actually use Lattice Diamond IDE, and even prefer it to Altera Quartus II. I have yet to decide which I prefer --- for now, both are a struggle to me. And both, have been removed and reloaded to get rid of the mess that a first attempt made of depositing projects in and amongst their file system.
Good housekeeping is important. So be prepared to start over when you learn how sloppy you have been.
................................
Okay, I confess... I am mostly a hardware person. So it seems FPGA comes more easily than bytecode and virtual machines, or LMM. The pleasure is in not having to produce a board, procure parts and bits, and solder the whole together.
Not sure if or when I will ever get around to the Z-80 FPGA as I am really passionate about eForth. The all Propeller version is a bit more exotic than the FPGA version.
I am beginning to think that some people only learn one CPU in a lifetime and then recreate it on everything they use. I have only tried to seriously learn a few - the SX28, SX48, the Propeller, and Microchip 16F84.
+++++++++++
In seeking out bugs and surveying for the change over from 16bit to 32bit at the same time, I think that the conversion to 32 bit may be the easiest task I have to deal with... but ideally it would be easier to get the eP16 working first.
Why is it easy?
Well the eP16 zip files included two Top level files -- one for eP16 and the other for eP32. Those make getting started much easier.
The best part is that the eP16.vhd file has a line near the top that defines a variable as Width:=16. This is obviously a quick change variable to get 32bit without line-by-line changes. It appears one global change does it all.
(If fact, the bug in ep16 may be that the eP16 code doesn't work in 16, but does work in 32bit. There is a 'Slot Code' that should be designated for three 5 bit wide slots in the 16 bit scheme, but I see six 5 bit wide slots (needed for 32bit scheme) in the VHDL configuration.)
More study and more testing is needed to confirm.
Meanwhile I am banging away at trying to get Altera to provide me with an acceptable ram_memory.vhd and I might not really make any progress until I do some serious downloading and reconfiguration of my 64-bit Quad machine.
A. Download a 64-bit Linux Fedora or ArchLinux for RPM friendly install.
B. Download a 64-bit RPM Quartus II V15.0.2
C. Download a 64-bit RPM Diamond IDE and 32-bit RPM Diamond IDE
D. Repartition the 64-bit machine to allow a third OS.
E. Install all of that.
It will be the weekend before I will have time to do all that as I have teaching for the new few days. I may get some of the downloads down by running the machine 24/7 leading into the weekend.
And so........in eP16.
That Top file and the actual CPU file are the challenging ones that change from the 16 bit to the 32 bit change over.
The others will require investigation and modification, but are rather minor tweaks that just confirm you are beginning to comprehend the VHDL way.
ram_memory.vhd also needs to change to 32bit width as well. But if the software support is there, that is rather painless. C.H.Ting discusses how to do this in Lattice Diamond IDE, but the proceedure is similar in Quartus (if only the software lets me in).
Not yet sure how the UART handles change overs, maybe, but it seems to require line-by-line change over of the data_i and data_0 16 bit buses to 32 bit. I may revise my UART files to 16 and 32bit versions designated clearly in their names.
To do these 16 to 32bit correctiosn, one compares the two Top Level files UART entries first and then makes the lower level files into two sets that conform in bus width.
===========
The big hangup remaining is that Altera IP Code two-port RAM in Megatrends software. If that won't budge, it is back to Lattice Diamond IDE (but with a Linux RPM file) and try, try again while I consider what the problem in Quartus II V.15 might be and where my solution lies. If just may be that the Cyclone V support in V15.0.2 has not been completed and the Megatrends IP Cores in some instances won't work.
%%%%%%%%%%%%%%%%%%%
Yes indeed, learning the FPGA IDE is most of the challenge. It is impossible to read all and everything before starting, so I toggle back and forth between blockages in progress.
Until I can get past this, I am uncertain what will happen. Even with this problem, I was able to compile and load P1v to the BeMicroCV. So it is odd, very odd.
Are you actually seeing that specific error? Quote:
Stack Trace:
0x214ed: addbyter + 0xd (curl.so.4)
0x21829: dprintf_formatf + 0x159 (curl.so.4)
0x22a45: curl_mvsnprintf + 0x25 (curl.so.4)
0x125be: Curl_failf + 0x9e (curl.so.4)
0x910f: Curl_resolv_timeout + 0x12f (curl.so.4)
0x415d: clock_gettime + 0x1d (rt.so.1)
Because that patch for 14.1 cannot possibly work for 15.0. I checked, and it appears that Altera has included their own build of libcurl instead of using the system one - just about every Linux distro includes it - (and btw that comment about 'not thread safe' in the link is wrong - Altera was simply using the library incorrectly).
What that patch does will be very 14.1 specific.
The comment also says that it's been fixed for 15.0, which is why I asked about the specific error you see, it would be very strange if that shows up after they claim to have re-done that part of the code or the self-built variant of the libcurl library they use.
(Edit: One thing you *could* try though is to install 14.1, install the patch, and then carefully check exactly which file got updated - if it was *only* a library (a .so.* file) in /some/path/quartus/linux64/, then you could transplant that file to the 15.0.2 version - with backup, of course. Actually, if you could figure out which file was updated maybe there's a way to make the patch yourself even if that didn't work - I see their version of libcurl.so.4 in there, that one can be replaced with either a self-compiled one or a system version. But first it needs to be verified that the error is the one you're actually seeing).
And both, have been removed and reloaded to get rid of the mess that a first attempt made of depositing projects in and amongst their file system.
Good housekeeping is important. So be prepared to start over when you learn how sloppy you have been.
I think I have finally got my head around the file structures for Altera. Copying the structure Grant Searle uses http://searle.hostei.com/grant/Multicomp/index.html
start with a folder. In this folder, no files, and just two or three sub folders - Grant has Components, Computer and ROMS. In Computer there is the "main" vhdl file, equivalent to the "main" part of a C program. This calls everything and has a .vhd extension. There are some other files in that folder with extensions .qsf, .qwf, .qip - these do things like describe which physical pins on the chip go to which pins in the code.
In the ROMs folder are rom images - things like bootup code, fonts.
In the Components folder are multiple folders, each containing components such as SD card, Uart. These are .vhd files. Component folders will generally just have one file in them, and .vhd files can be edited in a text editor if you want to.
If you copy a project you can copy all of this and it keeps things together.
There is a catch with copying groups of folders and a fix. If you have compiled the project many times, quartus will have created a db and a greybox folder in the main folder, and each time it is recompiled, more files appear in these two folders. The package can grow from a few hundred kilobytes to many megabytes very quickly. But it appears these files in these two folders can all be deleted.
I'm working with someone in another city building a project, and originally we were exchanging the whole package, but now we understand the file structure, Max might send me an email saying he has changed the uart so it has flow control, and he might send me the new uart.vhd file which is only 3kb and I just replace the file in my project. In an old skool way of thinking, he has created a brand new 6850 chip and I throw away all my old 6850 uart chips in my parts drawer and replace them with new ones.
I think I have finally got my head around the file structures for Altera. Copying the structure Grant Searle uses http://searle.hostei.com/grant/Multicomp/index.html
start with a folder. In this folder, no files, and just two or three sub folders - Grant has Components, Computer and ROMS. In Computer there is the "main" vhdl file, equivalent to the "main" part of a C program. This calls everything and has a .vhd extension. There are some other files in that folder with extensions .qstf, .qwf, .qip - these do things like describe which physical pins on the chip go to which pins in the code.
In the ROMs folder are rom images - things like bootup code, fonts.
In the Components folder are multiple folders, each containing components such as SD card, Uart. These are .vhd files. Component folders will generally just have one file in them, and .vhd files can be edited in a text editor if you want to.[..]
That's very useful, and explained clearly. Thanks! But I wonder how on earth you managed to extract that from Grant's page? I've read through it several times and I can't see the directory (aka folder) structre described at all there. I may be blind, but.. in any case, your description is clear!
Edit: Ah, I think I got it - it's the layout found in the Multicomp.zip file, right?
Edit: Ah, I think I got it - it's the layout found in the Multicomp.zip file, right?
You got it!
Another thought. If you start with a complete project, the structure describes all the components and all the pin connections. But you can start with a brand new clean slate - just a main.vhd file. Add one component, and in quartus you tell it where this component is via a dropdown menu. Then do the pin connections (after telling it which chip you are using). So you can rebuild it from just .vhd files, which are only short text files.
Knowing this, you can port projects between cyclone II, III, IV and V boards.
Dr_Acula and Tor,
Well I took the slap dash approach before I read your posts. I attempted to force the V14.1 patch into V15.0.2. I need to read, review, and ponder yours and Tors suggestions in regards to fixing the Altera Quartus II.
I fear I am stuck with another night long download to acquire Quartus II v14.0.
V15.0.2.xxx accepted the patch with protest of wrong version, but it did not abate the message. Not sure what Altera is up to. I did send an email begging for advice as I get the same error message (but maybe not the same specifics). I can't seem to roll back the patch, so it appears I need to completely reinstall v15.0.2 anyway. And yes indeed, it appears to only target the /quartus/linux64/.....<curl stuff>.
So what am I to do?
I guess I could install V14.0 and run the patch and use the BeMicroCV. Later I would update to V15.0.2 in order to use my BeMicroCVA9.
Tedious distractions...........
Meanwhile.....
The desktop ran all last night downloading Lattice Diamond IDE 3.5 for 64-bit Linux. It is an RPM file, so I may install Fedora and then install Diamond IDE on the desktop with hopes that it will be more stable than my Windows 7 Starter in 32bit and full hard disk was.
FPGAs certainly have a way of making one get their Administrative chores in order.
New goals...........
Simply to organize two sets of files in two separate Folders to be used to create separate projects in Lattice and Altera ==
eP16 VHDL
eP32 VHDL
I am all ears about how to properly do further management in Altera and Lattice IDEs. I am still a novice.
I think I have identified all that needs to be corrected in eP16 to get a 32bit scheme running, but I certain need that two port RAM memory to do a complete build in the most direct fashion. So far, Lattice is the only one providing a workable solution.
Altera's IP Cores in Megatrends software is freezing up on me when I try to build many of its modules... not just the two port Ram. From what I read, I am supposed to have access to it in the Free version of Quartus II v15.0.x.xxxx
For now and in Lattice........
It is very possible for me to attempt to complete the whole project, including migration to Verilog and melding the P1V architecture with eP32 in Lattice if Altera doesn't come through.
But I might not have the right FPGA to actually physically run the code. I might only manage a simulation. I am a bit unclear if the Lattice XP2 Brevia2 resources are enough.
+++++++++
In any event, youall see what I am doing. I push in one direction until blocked, and then try another.
I am searching to a way to settle into the right Linux to work with both Lattice and Altera IDES. I don't desire to buy a Windows 7 Pro installation just to get the job done.
Well, back when Grant posted his multicomp code one thing he did say was that it wouldn't run on the latest version of Quartus and you had to go back to version 13. I guess by the time a fpga gets down to a decent price on ebay (cyclone II), they are considered obsolete. I'm not entirely sure about that logic - in fact I'd argue they have finally reached a point where they are at an attractive price.
Anyway I went up about $15 to go from cyclone II to IV (interestingly the cyclone Vs may be cheaper than IV if you buy them locally from Arrow etc). So at least IV and V run on the latest version of Quartus.
So then, yes, like you say, a huge download. I did it twice, used up a significant chunk of my monthly download quota (which upset the kids a bit). Second time, kept a backup of the download.
Then tried running it. Two machines, both about 8 years old, ex government boxes, nothing special with speed or specs and both work fine for me, one running win7, one on win10. The win10 one says it is only a 32 bit box and needs 64bit so wouldn't install any further. Nothing to do with the OS (the win10 one had ubuntu on it last week) but I guess it needs relatively new PC hardware, regardless of whatever operating system happens to be running.
I wonder if it almost might be worth writing up a led flashing fpga bit of code? Take the onboard xtal (50mhz on the cyclone II, 25mhz on the cyclone IV and we are using a PLL to double that), divide it down and flash an onboard led. Just as a demo bit of vhdl to test out really simple things like "does my version of quartus run on my PC and my operating system" and "does it compile" and "can you connect the pins up correctly" and "can it download via jtag and AS". In some ways it might be simpler than leaping right in to a microcomputer simulation.
Loopy
FYI
If you want to use your BeMicro CV-A9 board you will have to somehow get Quartus version 15.0.x working.
Earlier versions don't support the A9 device.
Loopy
FYI
If you want to use your BeMicro CV-A9 board you will have to somehow get Quartus version 15.0.x working.
Earlier versions don't support the A9 device.
Very, very true....
But I purchased BOTH a BeMicroCV(A2) and a BeMicroCVA9.
And since I have a long history of damaging what I am first learning on, I have kept the more expensive BeMicroCVA9 in reserve for when P2 code becomes available or I learn enough to need it. I have already damaged on i/o pin on the CV.
Altera seems to primarily support Quartus II in Windows and struggles a bit with completing their Linux installation. I am beginning to think that I might have to wait awhile for them to fully clean up V15.0.x.xxxx.
So I am staying with the BeMicroCV for now and may actually install v14.xxx to move ahead with this project. The CVA9 can wait.
Loopy, you could always try a virtual machine. I never tried Fedora but Quartus I think it was 12 or 13 used to work (except programmer) well on CentOS 6. I have here a VM with CentOS 7, I'll try and see if it works. CentOS is closer to RH than Fedora is, at least the similar numbered versions... (Regarding the patch, I tried the 14 patch in a 14 installation without luck... no idea).
I downloaded centos 6.7 (my 7 has no gui...), installed as Programming worstation.
QII 15.0.0.145, first try to installl fails, it says that it can't copy some files... why ? there is enough place on both partitions... well...
2nd. try: I copied all extracted files to the /tmp and run it from there.... no dice.
The MD5SUM of the downloaded file is the one on Altera's website .
3rd. try, installing as root (I installed previously as user, some files were copied...)
"There has been an error. Error copying file. The application will exit now"
Not promising
4th. try, directly from shared folder... Success !
***
Note: something went/goes wrong when installing from linux...
tar unpacked a wrong file ?
All files (unpacked in linux and in windows) have the same md5sum... strange, why does one of them does not install !?
***
OK, it runs.
I created a sample project and a 8 kBytes Dual ported RAM... everything seems to work..., lets try to compile... it compiles...
Thanks... Centros Linux and SUSE are supposedly supported for installing Quartus II in Linux, as well as Red Hat/Fedora.
I think if you look in the setup.sh file, you will see some specifics that are selected for each of those 3, and the rest of the Linux distros are supposed to generate an 'unsupported' message.
I didn't not see this when I first attempted an install in Debbie Jessie amd64 and had not idea why I had some problems. There are some differences with compiling Linux to amd64 versus the x86-64, but I have no idea if that really causes any trouble or not.
If so, which operation triggers it?
If this is really the problem I should be able to figure out a fix, but unfortunately it will probably have to wait until I'm back at my own Debian 64-bit desktop - and that won't happen until mid-November. I can access it remotely from here but I can't connect my DE0 board, obviously. I have a Debian 64-bit notebook where I'm now, but I don't have an FPGA board here (I haven't quite managed to duplicate everything for my two locations).
Tor,
I appreciate that you want to help me with this.
My work and other daily life have been demanding I meet some deadlines and I haven't been able to spend much time with the FGPA projects.
I never did an actual stack track to confirm that the Error message was for the same condition as documented in V14.1 or a new curl problem putting out the the same error message in v15.0.2.
Since my 64 bit machine is all Intel, I began to wonder if the amd64 binary might create problems -- purely my imagination at this point.
My solution has been to start over with Fedora on my 64bit Quad Intel machine as a 3rd boot. And I haven't yet had time to sort out partition space. I intend to install both Lattice Diamond IDE 3.5 and Quartus II v15.0.2 in Fedora, but that takes quite a few Gbytes
I removed everything from the Debian Jessie amd64 (Quartus II v15.0.2)and my W7 (32bit Diamond IDE 3.5)as well. So I don't actually have any FPGA IDEs installed at this point.
Until I get Fedora 64bit working, I can't give you a good reply.
I do intend to install BOTH Quartus II v14.1 and v15.0.2 to evaluate the start up problems. That is where I get the complaints about curl code. Of course that means even more Gbytes of partition. I will start with v14.1
Don't be concerned about the 'amd' in 'amd64', it isn't really amd vs. Intel, it's just the name of the 64-bit architecture - AMD came up with it, and Intel adopted it (was actually forced to adopt it). Well, Debian calls it amd64. Elsewhere it's also called x86-64, but it's the same thing.
@Tor,
Thanks for the mention about amd64 versus x86_64. Some places on the internet say there is no problem, but others argue there might be some compiler differences. And I don't have anyone locally to turn to for a final opinion.
++++++++++++
In any event, while I have been trying to figure out how I desire to triple-boot my Intel Quad 64bit and moving stuff around with gparted, I have been making a lot of progress with learn VHDL through studying the ep16 Forth files by C. H. Ting.
I have yet to try reading the Verilog source for P1V, but I do intend to learn more from it as to how I might have an 8 CPU Forth machine.
The bottom line here is that documentation always has typos. But if the code runs properly, it is the primary reference. And yes, I have come across a few typos that really needed to be run down in code.
===========
Originally, I thought that Verilog should be the easiest to learn. I had read a comparison of Verilog and VHDL that seemed to imply that. But so far, VHDL with the explanation of eP16 by C.H.Ting has may it rather painless to learn.
The P1V Verilog code will have to make do with my previous knowledge of the Propeller 1, and maybe studying another 32bit CPU in Verilog. I haven't gotten that far.
This thread isn't really staying on the topic of learning VHDL, Verilog, or both.
But I am jumping in here with a quick up date about my problems with Quartus II v15.0.2.
I migrated away from my Debian Jessie installation (which I may have messed up) and installed a separate Fedora 22 partition that now has Quartus II v15.0.2 installed and running. There are no longer any complaints about Curl in the start up. I can't say it is a 100% right, but that problem is gone.
If Quartus II v15.0.2 doesn't give me all I desire, I may try Quartus II v14.1 to see if it runs any better.
So far, I still seem to have a problem with using Megatrands IP codes to create a 2 port RAM in VHDL. Even in the new OS, the software locks up when I go to the second configuration screen. That may delay getting a Forth eP16 running on the BeMicroCV.
I downloaded the eP16 project from http://www.forth.org/cores.html. The paper describing it is very interesting. Sadly I only have MachXO2 boards and XP2 . porting shouldn't be that difficult.
The included mem file says width:32 but the data is 16 bits wide... well, let's see how it goes.
I cannot seem to be able to recreate a block memory with the provided mif file. The wizard just closes itself without producing an error message.
@Ale
The Wizard may just be rejecting that 32 width in the header.
Yes, reading the ram_memory.vhd file indicates that it has a 16bit x 4096 word solution and that the ram_memory.vhd file included what should be a good image of the mem.mif. When I do look at the actual provided mem.mif, it seems the hexadecimal notation is for 16bit words at one per line, so I presume the 32bit in the title is wrong. I suspect you need to change that 32 width to 16.
There seems to be a problem with the UART module not terminating the RTS and CTS signals and the serial function is blocked by CTS being a floating input. One can specify a pull-up resistor to Vcc to resolve the problem, or figure out a way to loop back the CTS to RTS in code.
The code I posted is from Console and is essentially equal to a screen shot -- all that I have so far. When I start Quartus II v15.0.2, I get the two issues with .so files not being found. They may exist and just have the wrong PATH designation. I may need these to get the IP Code to work.
Support for FPGAs in OSx seems non-existent. And it is a bit awkward in Linux. Windows emulation might be the simplest and most direct way to go, but Quartus II demands a 64bit machine. You seem to be using Lattice devices in Diamond IDE which have 32bit solutions, but also no OSx.
Also, the eP16 and eP32 code requires the insertion in the ram_memory.vhd of a Forth dictionary to get started. The mem.mif file needs to be used with a 2-Port Ram module from Megatrends IP code to get an Altera device working. Everything that C. H. Ting provides is targeted for the Lattice XP2 Brevia2 in Diamond IDE.
If you change that from 16bit to 32bit format or require a different 16bit format for Alterea, it will require reformatting to work right. While C. H. Ting claims this has to be done in the 'meta-compiler' (a Forth cross-compiler that is only available in Windows == called weForth.exe), I suspect that one could use data base functions in a spreadsheet to modify the existing mem.mif file
@Ale
Since I had to research what Altera desires for memory initialization format, I took another look at mem.mif.
I am pleased to find that Altera also accepts .mif format. So it seems that if mem.mif is correct for eP16 in Lattice, it will work in Altera.
It certainly seems that the 32 width is a typo, and that it should be changed to 16bit. As I said before, all the following data is obviously hexadecimal and not over 16bits. Lattice Diamond IDE may override the 32 as the storage is specified as 16bits wide. I have no idea if Altera would do the same.
This mem.mif issue is part of a list of errata that I have been accumulating. The errors seem mostly attributable to migration of code and documentation from eP32 to eP16, with the one exception of RTS and CTS not resolved in the UART.
eP16 errors and omissions discovered so far.
1. Fig 6 in the eP16inVHDL.pdf has mention of 5 slots, that should have be 3 slots.
2. The Slot variable in eP16.vhd should have a value of 4, not 6. 6 slots would be needed for a 32bit solution with 6bit code slots. 5 bit code slots in 32bit solution would require a value of 7
3. eP16.vhd declarations refer to eP32. While the code works fine due to local containment and consistency of the error, this is not a 32bit CPU.
4. When one creates i/o assignments, adding two more pins for RTS and CTS with CTS having a pullup to 3.3VDC seems necessary to actually get things running. If one desires to not assign i/o pins, one either has to rewrite the entire UART code to eliminated the RTS/CTS control flow or somewhere add a line of code that loops back the RTS to the CTS.
I am not sure that the internal loopback would be wise. I prefer the pullup and have the flow control available to the outside world.
5. It is very important that the Top File is eP16_in_chip.vhd, as C. H. Ting include the eP32_in_chip.vhd apparently for reference.
++++++
Of course, there may be more errors that I have yet to discover. Let me know if you find anything.
The memory wizard of Diamond 3.5 (with update to 3.5.1.302) just crashes when creating a mem block with a initialization file, any file. I even converted the file to just hex, the wizard crashes anyways. Target VHDL or verilog, it crashes ! I created a simple verilog source with a readmemh directive, the only problem is that without registered reads synopsis seems unable to map it to a memroy block, it is converted into LUTs
module ram_memory(
input wire Clock,
input wire ClockEn,
input wire Reset,
input wire WE,
input wire [11:0] Address,
input wire [15:0] Data,
output reg [15:0] Q
);
reg [15:0] mem [4095:0]/*synthesis syn_ramstyle =block_ram*/;
//assign Q = mem[Address]; // remove comment for async output but then it is not a mem block anymore
always @(posedge Clock)
begin
if (WE) mem[Address] <= Data;
Q <=mem[Address]; // comment out to remove output register, but then it is not a mem block anymore
end
initial
$readmemh("../eP16/mem_hex.mem", mem);
endmodule
hex file converter
#!/usr/bin/python
#
# converts a addr:hex mem file into hex file filling the blanks with zeros
#
fi = open('mem.mif', 'rt')
fo = open('mem_hex.mem', 'wt')
lasta = 0
for line in fi:
if line[0] != '#':
line = line.strip()
ss = line.split(':')
a = int(ss[0], 16)
#d = int(ss[1], 16)
if lasta + 1 < a:
for j in range(lasta + 1, a):
fo.write('0000\n')
fo.write(ss[1] + '\n')
lasta = a
fi.close()
fo.close()[s][/s]
@Ale
Right now, I don't have Lattice Daimond IDE 3.5 installed, so I can't attempt a compile for a Lattice target to follow along.
I am having a similar problem with creating a 2-port RAM in an Altera target, the BeMicroCV.
I am a bit worried that the creation of 2 port RAM modules might not be supported in the free versions of either Lattice or Altera, but I have not confirmed that is true or false.
The questionable mem.mif may just force you to load weForth and to run the metacompiler to generate a fresh mem.mif image. At times, I suspect that C. H. Ting put flaws in the provided code just to force students to work through the entire eP16inVHDL.pdf. Either than, or the publication was rushed.
My previous attempts to compile a Lattice XP2 Brevia2, compiled and loaded -- but appeared not to run. It may be that I did not properly specify i/o or that the CTS float prevented communications. Something was written to the FPGA as the LEDs that were originally lit with a a factory loaded application, all went off.
++++++++++++
I simply need to work through all my problems with loading FPGA IDEs. And I am doing that now. It is rather slow going as I have to rely on downloading rather large files and moving around the same.
It seems that I have to remove and reinstall my Quartus II V15, so I may try a Diamond IDE install before I attempt a Quartus II reinstall.
I never had a problem with lattice diamond or altera's quartus generating any kind of memory block. Maybe it is something related to win10. Diamond 3.1 on win7 has no problems generating dualport ram blocks. I may install that here too in case I didn't erase the installation files...
Comments
http://forums.parallax.com/discussion/110804/zicog-a-zilog-z80-emulator-in-1-cog/p1
http://forums.parallax.com/discussion/116893/ramblade-prop-sram-microsd-addon-to-run-zicog-cpm-propdos-catalina-etc/p1
But I am a bit concerns about the Altera IP Core software, Megatrends is refusing to work in Debian 8.1 Jessie amd64.
Whatever FPGA you desire to use, you will find the IDE to be a merry chase with finicky OS preferences.
++++++++++++++
I mentioned to Heater and Dr_Acula that the Z-80 has been recreated in FPGA. I think it might be possible to combine a P1V image with that to get a complete CP/M machine with SDcard file system on one FPGA board. The P1V would mostly provide terminal video, keyboard, and mouse services... maybe some GPIO.
http://sowerbutts.com/socz80/
I am not sure that some Parallaxians feel this kind of use of FPGA is kosher. They may prefer than the Propeller 1 does it all.
It may be that I just didn't realize how long that might take due to Altera removing the parallel processing from the Free version.
We will see
+++++++++++++++++++
Meanwhile, I am beginning to see how to migrate the eP16 code to eP32. I even have doubts that the eP16 was successful ported from eP32 originally. I have references for both... so putting it back into eP32 may settle everything down.
Right now the GPIO is 16 bit port. I may expand that to a 32 bit port as well if the FPGA will tolerate such. The Lattice XP2 Brevia2 does not have enough i/o pins for 32 bit GPIO.
+++++++++++++++++++
In any event, I don't have Lattice Diamond IDE loaded in any computer at this point, so I am focusing on some how making Quartus II V15.0.2 work well.
http://sowerbutts.com/socz80/
I love this blue sky thinking! Well, interesting you chose that link because Will Sowerbutts wrote the MMU we are using on the CP/M machine we are running on the cyclone IV.
It is similar to the propeller obex, where you grab objects written by lots of different people and join them together. So the z80 core is written by one person, the MMU by another, the SD controller by a third person.
There are pages and pages of discussion on this forum about what people wanted to see on their particular version of the propeller. Now the code is open source, anyone can build these things themselves. Why not a hardware uart in fgpa, and a software uart on a cog... running at the same time.
I guess the big barrier is getting into fpga in the first place. It is a bit daunting to start with, but great fun once you realise how components interact with each other, and very similar in a way to working with real hardware. Data busses, address busses, control signals.
Looking forward to your next update, loopy.
Good housekeeping is important. So be prepared to start over when you learn how sloppy you have been.
................................
Okay, I confess... I am mostly a hardware person. So it seems FPGA comes more easily than bytecode and virtual machines, or LMM. The pleasure is in not having to produce a board, procure parts and bits, and solder the whole together.
Not sure if or when I will ever get around to the Z-80 FPGA as I am really passionate about eForth. The all Propeller version is a bit more exotic than the FPGA version.
I am beginning to think that some people only learn one CPU in a lifetime and then recreate it on everything they use. I have only tried to seriously learn a few - the SX28, SX48, the Propeller, and Microchip 16F84.
+++++++++++
In seeking out bugs and surveying for the change over from 16bit to 32bit at the same time, I think that the conversion to 32 bit may be the easiest task I have to deal with... but ideally it would be easier to get the eP16 working first.
Why is it easy?
Well the eP16 zip files included two Top level files -- one for eP16 and the other for eP32. Those make getting started much easier.
The best part is that the eP16.vhd file has a line near the top that defines a variable as Width:=16. This is obviously a quick change variable to get 32bit without line-by-line changes. It appears one global change does it all.
(If fact, the bug in ep16 may be that the eP16 code doesn't work in 16, but does work in 32bit. There is a 'Slot Code' that should be designated for three 5 bit wide slots in the 16 bit scheme, but I see six 5 bit wide slots (needed for 32bit scheme) in the VHDL configuration.)
More study and more testing is needed to confirm.
Meanwhile I am banging away at trying to get Altera to provide me with an acceptable ram_memory.vhd and I might not really make any progress until I do some serious downloading and reconfiguration of my 64-bit Quad machine.
A. Download a 64-bit Linux Fedora or ArchLinux for RPM friendly install.
B. Download a 64-bit RPM Quartus II V15.0.2
C. Download a 64-bit RPM Diamond IDE and 32-bit RPM Diamond IDE
D. Repartition the 64-bit machine to allow a third OS.
E. Install all of that.
It will be the weekend before I will have time to do all that as I have teaching for the new few days. I may get some of the downloads down by running the machine 24/7 leading into the weekend.
And so........in eP16.
That Top file and the actual CPU file are the challenging ones that change from the 16 bit to the 32 bit change over.
The others will require investigation and modification, but are rather minor tweaks that just confirm you are beginning to comprehend the VHDL way.
ram_memory.vhd also needs to change to 32bit width as well. But if the software support is there, that is rather painless. C.H.Ting discusses how to do this in Lattice Diamond IDE, but the proceedure is similar in Quartus (if only the software lets me in).
Not yet sure how the UART handles change overs, maybe, but it seems to require line-by-line change over of the data_i and data_0 16 bit buses to 32 bit. I may revise my UART files to 16 and 32bit versions designated clearly in their names.
To do these 16 to 32bit correctiosn, one compares the two Top Level files UART entries first and then makes the lower level files into two sets that conform in bus width.
===========
The big hangup remaining is that Altera IP Code two-port RAM in Megatrends software. If that won't budge, it is back to Lattice Diamond IDE (but with a Linux RPM file) and try, try again while I consider what the problem in Quartus II V.15 might be and where my solution lies. If just may be that the Cyclone V support in V15.0.2 has not been completed and the Megatrends IP Cores in some instances won't work.
%%%%%%%%%%%%%%%%%%%
Yes indeed, learning the FPGA IDE is most of the challenge. It is impossible to read all and everything before starting, so I toggle back and forth between blockages in progress.
Altera claims that they fixed this problem in Quartus V15.0, but I have this specific start up problem in V15.0.2
And that may be at the root of my difficulties. I sent off an email. I may try to run the V14.1 patch for the heck of it.
https://www.altera.com/support/support-resources/knowledge-base/solutions/rd01272015_37.html
Until I can get past this, I am uncertain what will happen. Even with this problem, I was able to compile and load P1v to the BeMicroCV. So it is odd, very odd.
Are you actually seeing that specific error? Quote:
Stack Trace:
0x214ed: addbyter + 0xd (curl.so.4)
0x21829: dprintf_formatf + 0x159 (curl.so.4)
0x22a45: curl_mvsnprintf + 0x25 (curl.so.4)
0x125be: Curl_failf + 0x9e (curl.so.4)
0x910f: Curl_resolv_timeout + 0x12f (curl.so.4)
0x415d: clock_gettime + 0x1d (rt.so.1)
Because that patch for 14.1 cannot possibly work for 15.0. I checked, and it appears that Altera has included their own build of libcurl instead of using the system one - just about every Linux distro includes it - (and btw that comment about 'not thread safe' in the link is wrong - Altera was simply using the library incorrectly).
What that patch does will be very 14.1 specific.
The comment also says that it's been fixed for 15.0, which is why I asked about the specific error you see, it would be very strange if that shows up after they claim to have re-done that part of the code or the self-built variant of the libcurl library they use.
(Edit: One thing you *could* try though is to install 14.1, install the patch, and then carefully check exactly which file got updated - if it was *only* a library (a .so.* file) in /some/path/quartus/linux64/, then you could transplant that file to the 15.0.2 version - with backup, of course. Actually, if you could figure out which file was updated maybe there's a way to make the patch yourself even if that didn't work - I see their version of libcurl.so.4 in there, that one can be replaced with either a self-compiled one or a system version. But first it needs to be verified that the error is the one you're actually seeing).
-Tor
Good housekeeping is important. So be prepared to start over when you learn how sloppy you have been.
I think I have finally got my head around the file structures for Altera. Copying the structure Grant Searle uses http://searle.hostei.com/grant/Multicomp/index.html
start with a folder. In this folder, no files, and just two or three sub folders - Grant has Components, Computer and ROMS. In Computer there is the "main" vhdl file, equivalent to the "main" part of a C program. This calls everything and has a .vhd extension. There are some other files in that folder with extensions .qsf, .qwf, .qip - these do things like describe which physical pins on the chip go to which pins in the code.
In the ROMs folder are rom images - things like bootup code, fonts.
In the Components folder are multiple folders, each containing components such as SD card, Uart. These are .vhd files. Component folders will generally just have one file in them, and .vhd files can be edited in a text editor if you want to.
If you copy a project you can copy all of this and it keeps things together.
There is a catch with copying groups of folders and a fix. If you have compiled the project many times, quartus will have created a db and a greybox folder in the main folder, and each time it is recompiled, more files appear in these two folders. The package can grow from a few hundred kilobytes to many megabytes very quickly. But it appears these files in these two folders can all be deleted.
I'm working with someone in another city building a project, and originally we were exchanging the whole package, but now we understand the file structure, Max might send me an email saying he has changed the uart so it has flow control, and he might send me the new uart.vhd file which is only 3kb and I just replace the file in my project. In an old skool way of thinking, he has created a brand new 6850 chip and I throw away all my old 6850 uart chips in my parts drawer and replace them with new ones.
Edit: Ah, I think I got it - it's the layout found in the Multicomp.zip file, right?
You got it!
Another thought. If you start with a complete project, the structure describes all the components and all the pin connections. But you can start with a brand new clean slate - just a main.vhd file. Add one component, and in quartus you tell it where this component is via a dropdown menu. Then do the pin connections (after telling it which chip you are using). So you can rebuild it from just .vhd files, which are only short text files.
Knowing this, you can port projects between cyclone II, III, IV and V boards.
Well I took the slap dash approach before I read your posts. I attempted to force the V14.1 patch into V15.0.2. I need to read, review, and ponder yours and Tors suggestions in regards to fixing the Altera Quartus II.
I fear I am stuck with another night long download to acquire Quartus II v14.0.
V15.0.2.xxx accepted the patch with protest of wrong version, but it did not abate the message. Not sure what Altera is up to. I did send an email begging for advice as I get the same error message (but maybe not the same specifics). I can't seem to roll back the patch, so it appears I need to completely reinstall v15.0.2 anyway. And yes indeed, it appears to only target the /quartus/linux64/.....<curl stuff>.
So what am I to do?
I guess I could install V14.0 and run the patch and use the BeMicroCV. Later I would update to V15.0.2 in order to use my BeMicroCVA9.
Tedious distractions...........
Meanwhile.....
The desktop ran all last night downloading Lattice Diamond IDE 3.5 for 64-bit Linux. It is an RPM file, so I may install Fedora and then install Diamond IDE on the desktop with hopes that it will be more stable than my Windows 7 Starter in 32bit and full hard disk was.
FPGAs certainly have a way of making one get their Administrative chores in order.
New goals...........
Simply to organize two sets of files in two separate Folders to be used to create separate projects in Lattice and Altera ==
eP16 VHDL
eP32 VHDL
I am all ears about how to properly do further management in Altera and Lattice IDEs. I am still a novice.
I think I have identified all that needs to be corrected in eP16 to get a 32bit scheme running, but I certain need that two port RAM memory to do a complete build in the most direct fashion. So far, Lattice is the only one providing a workable solution.
Altera's IP Cores in Megatrends software is freezing up on me when I try to build many of its modules... not just the two port Ram. From what I read, I am supposed to have access to it in the Free version of Quartus II v15.0.x.xxxx
For now and in Lattice........
It is very possible for me to attempt to complete the whole project, including migration to Verilog and melding the P1V architecture with eP32 in Lattice if Altera doesn't come through.
But I might not have the right FPGA to actually physically run the code. I might only manage a simulation. I am a bit unclear if the Lattice XP2 Brevia2 resources are enough.
+++++++++
In any event, youall see what I am doing. I push in one direction until blocked, and then try another.
I am searching to a way to settle into the right Linux to work with both Lattice and Altera IDES. I don't desire to buy a Windows 7 Pro installation just to get the job done.
Well, back when Grant posted his multicomp code one thing he did say was that it wouldn't run on the latest version of Quartus and you had to go back to version 13. I guess by the time a fpga gets down to a decent price on ebay (cyclone II), they are considered obsolete. I'm not entirely sure about that logic - in fact I'd argue they have finally reached a point where they are at an attractive price.
Anyway I went up about $15 to go from cyclone II to IV (interestingly the cyclone Vs may be cheaper than IV if you buy them locally from Arrow etc). So at least IV and V run on the latest version of Quartus.
So then, yes, like you say, a huge download. I did it twice, used up a significant chunk of my monthly download quota (which upset the kids a bit). Second time, kept a backup of the download.
Then tried running it. Two machines, both about 8 years old, ex government boxes, nothing special with speed or specs and both work fine for me, one running win7, one on win10. The win10 one says it is only a 32 bit box and needs 64bit so wouldn't install any further. Nothing to do with the OS (the win10 one had ubuntu on it last week) but I guess it needs relatively new PC hardware, regardless of whatever operating system happens to be running.
I wonder if it almost might be worth writing up a led flashing fpga bit of code? Take the onboard xtal (50mhz on the cyclone II, 25mhz on the cyclone IV and we are using a PLL to double that), divide it down and flash an onboard led. Just as a demo bit of vhdl to test out really simple things like "does my version of quartus run on my PC and my operating system" and "does it compile" and "can you connect the pins up correctly" and "can it download via jtag and AS". In some ways it might be simpler than leaping right in to a microcomputer simulation.
FYI
If you want to use your BeMicro CV-A9 board you will have to somehow get Quartus version 15.0.x working.
Earlier versions don't support the A9 device.
Very, very true....
But I purchased BOTH a BeMicroCV(A2) and a BeMicroCVA9.
And since I have a long history of damaging what I am first learning on, I have kept the more expensive BeMicroCVA9 in reserve for when P2 code becomes available or I learn enough to need it. I have already damaged on i/o pin on the CV.
Altera seems to primarily support Quartus II in Windows and struggles a bit with completing their Linux installation. I am beginning to think that I might have to wait awhile for them to fully clean up V15.0.x.xxxx.
So I am staying with the BeMicroCV for now and may actually install v14.xxx to move ahead with this project. The CVA9 can wait.
QII 15.0.0.145, first try to installl fails, it says that it can't copy some files... why ? there is enough place on both partitions... well...
2nd. try: I copied all extracted files to the /tmp and run it from there.... no dice.
The MD5SUM of the downloaded file is the one on Altera's website
3rd. try, installing as root (I installed previously as user, some files were copied...)
"There has been an error. Error copying file. The application will exit now"
Not promising
4th. try, directly from shared folder... Success !
***
Note: something went/goes wrong when installing from linux...
tar unpacked a wrong file ?
All files (unpacked in linux and in windows) have the same md5sum... strange, why does one of them does not install !?
***
OK, it runs.
I created a sample project and a 8 kBytes Dual ported RAM... everything seems to work..., lets try to compile... it compiles...
I think if you look in the setup.sh file, you will see some specifics that are selected for each of those 3, and the rest of the Linux distros are supposed to generate an 'unsupported' message.
I didn't not see this when I first attempted an install in Debbie Jessie amd64 and had not idea why I had some problems. There are some differences with compiling Linux to amd64 versus the x86-64, but I have no idea if that really causes any trouble or not.
Are you seeing the libcurl error in that link you mentioned before? This one:
If so, which operation triggers it?
If this is really the problem I should be able to figure out a fix, but unfortunately it will probably have to wait until I'm back at my own Debian 64-bit desktop - and that won't happen until mid-November. I can access it remotely from here but I can't connect my DE0 board, obviously. I have a Debian 64-bit notebook where I'm now, but I don't have an FPGA board here (I haven't quite managed to duplicate everything for my two locations).
-Tor
I appreciate that you want to help me with this.
My work and other daily life have been demanding I meet some deadlines and I haven't been able to spend much time with the FGPA projects.
I never did an actual stack track to confirm that the Error message was for the same condition as documented in V14.1 or a new curl problem putting out the the same error message in v15.0.2.
Since my 64 bit machine is all Intel, I began to wonder if the amd64 binary might create problems -- purely my imagination at this point.
My solution has been to start over with Fedora on my 64bit Quad Intel machine as a 3rd boot. And I haven't yet had time to sort out partition space. I intend to install both Lattice Diamond IDE 3.5 and Quartus II v15.0.2 in Fedora, but that takes quite a few Gbytes
I removed everything from the Debian Jessie amd64 (Quartus II v15.0.2)and my W7 (32bit Diamond IDE 3.5)as well. So I don't actually have any FPGA IDEs installed at this point.
Until I get Fedora 64bit working, I can't give you a good reply.
I do intend to install BOTH Quartus II v14.1 and v15.0.2 to evaluate the start up problems. That is where I get the complaints about curl code. Of course that means even more Gbytes of partition. I will start with v14.1
-Tor
Thanks for the mention about amd64 versus x86_64. Some places on the internet say there is no problem, but others argue there might be some compiler differences. And I don't have anyone locally to turn to for a final opinion.
++++++++++++
In any event, while I have been trying to figure out how I desire to triple-boot my Intel Quad 64bit and moving stuff around with gparted, I have been making a lot of progress with learn VHDL through studying the ep16 Forth files by C. H. Ting.
I have yet to try reading the Verilog source for P1V, but I do intend to learn more from it as to how I might have an 8 CPU Forth machine.
The bottom line here is that documentation always has typos. But if the code runs properly, it is the primary reference. And yes, I have come across a few typos that really needed to be run down in code.
===========
Originally, I thought that Verilog should be the easiest to learn. I had read a comparison of Verilog and VHDL that seemed to imply that. But so far, VHDL with the explanation of eP16 by C.H.Ting has may it rather painless to learn.
The P1V Verilog code will have to make do with my previous knowledge of the Propeller 1, and maybe studying another 32bit CPU in Verilog. I haven't gotten that far.
But I am jumping in here with a quick up date about my problems with Quartus II v15.0.2.
I migrated away from my Debian Jessie installation (which I may have messed up) and installed a separate Fedora 22 partition that now has Quartus II v15.0.2 installed and running. There are no longer any complaints about Curl in the start up. I can't say it is a 100% right, but that problem is gone.
If Quartus II v15.0.2 doesn't give me all I desire, I may try Quartus II v14.1 to see if it runs any better.
So far, I still seem to have a problem with using Megatrands IP codes to create a 2 port RAM in VHDL. Even in the new OS, the software locks up when I go to the second configuration screen. That may delay getting a Forth eP16 running on the BeMicroCV.
The included mem file says width:32 but the data is 16 bits wide... well, let's see how it goes.
I cannot seem to be able to recreate a block memory with the provided mif file. The wizard just closes itself without producing an error message.
The Wizard may just be rejecting that 32 width in the header.
Yes, reading the ram_memory.vhd file indicates that it has a 16bit x 4096 word solution and that the ram_memory.vhd file included what should be a good image of the mem.mif. When I do look at the actual provided mem.mif, it seems the hexadecimal notation is for 16bit words at one per line, so I presume the 32bit in the title is wrong. I suspect you need to change that 32 width to 16.
There seems to be a problem with the UART module not terminating the RTS and CTS signals and the serial function is blocked by CTS being a floating input. One can specify a pull-up resistor to Vcc to resolve the problem, or figure out a way to loop back the CTS to RTS in code.
The code I posted is from Console and is essentially equal to a screen shot -- all that I have so far. When I start Quartus II v15.0.2, I get the two issues with .so files not being found. They may exist and just have the wrong PATH designation. I may need these to get the IP Code to work.
Support for FPGAs in OSx seems non-existent. And it is a bit awkward in Linux. Windows emulation might be the simplest and most direct way to go, but Quartus II demands a 64bit machine. You seem to be using Lattice devices in Diamond IDE which have 32bit solutions, but also no OSx.
Also, the eP16 and eP32 code requires the insertion in the ram_memory.vhd of a Forth dictionary to get started. The mem.mif file needs to be used with a 2-Port Ram module from Megatrends IP code to get an Altera device working. Everything that C. H. Ting provides is targeted for the Lattice XP2 Brevia2 in Diamond IDE.
If you change that from 16bit to 32bit format or require a different 16bit format for Alterea, it will require reformatting to work right. While C. H. Ting claims this has to be done in the 'meta-compiler' (a Forth cross-compiler that is only available in Windows == called weForth.exe), I suspect that one could use data base functions in a spreadsheet to modify the existing mem.mif file
Since I had to research what Altera desires for memory initialization format, I took another look at mem.mif.
I am pleased to find that Altera also accepts .mif format. So it seems that if mem.mif is correct for eP16 in Lattice, it will work in Altera.
It certainly seems that the 32 width is a typo, and that it should be changed to 16bit. As I said before, all the following data is obviously hexadecimal and not over 16bits. Lattice Diamond IDE may override the 32 as the storage is specified as 16bits wide. I have no idea if Altera would do the same.
This mem.mif issue is part of a list of errata that I have been accumulating. The errors seem mostly attributable to migration of code and documentation from eP32 to eP16, with the one exception of RTS and CTS not resolved in the UART.
eP16 errors and omissions discovered so far.
1. Fig 6 in the eP16inVHDL.pdf has mention of 5 slots, that should have be 3 slots.
2. The Slot variable in eP16.vhd should have a value of 4, not 6. 6 slots would be needed for a 32bit solution with 6bit code slots. 5 bit code slots in 32bit solution would require a value of 7
3. eP16.vhd declarations refer to eP32. While the code works fine due to local containment and consistency of the error, this is not a 32bit CPU.
4. When one creates i/o assignments, adding two more pins for RTS and CTS with CTS having a pullup to 3.3VDC seems necessary to actually get things running. If one desires to not assign i/o pins, one either has to rewrite the entire UART code to eliminated the RTS/CTS control flow or somewhere add a line of code that loops back the RTS to the CTS.
I am not sure that the internal loopback would be wise. I prefer the pullup and have the flow control available to the outside world.
5. It is very important that the Top File is eP16_in_chip.vhd, as C. H. Ting include the eP32_in_chip.vhd apparently for reference.
++++++
Of course, there may be more errors that I have yet to discover. Let me know if you find anything.
module ram_memory( input wire Clock, input wire ClockEn, input wire Reset, input wire WE, input wire [11:0] Address, input wire [15:0] Data, output reg [15:0] Q ); reg [15:0] mem [4095:0]/*synthesis syn_ramstyle =block_ram*/; //assign Q = mem[Address]; // remove comment for async output but then it is not a mem block anymore always @(posedge Clock) begin if (WE) mem[Address] <= Data; Q <=mem[Address]; // comment out to remove output register, but then it is not a mem block anymore end initial $readmemh("../eP16/mem_hex.mem", mem); endmodulehex file converter
#!/usr/bin/python # # converts a addr:hex mem file into hex file filling the blanks with zeros # fi = open('mem.mif', 'rt') fo = open('mem_hex.mem', 'wt') lasta = 0 for line in fi: if line[0] != '#': line = line.strip() ss = line.split(':') a = int(ss[0], 16) #d = int(ss[1], 16) if lasta + 1 < a: for j in range(lasta + 1, a): fo.write('0000\n') fo.write(ss[1] + '\n') lasta = a fi.close() fo.close()[s][/s]Right now, I don't have Lattice Daimond IDE 3.5 installed, so I can't attempt a compile for a Lattice target to follow along.
I am having a similar problem with creating a 2-port RAM in an Altera target, the BeMicroCV.
I am a bit worried that the creation of 2 port RAM modules might not be supported in the free versions of either Lattice or Altera, but I have not confirmed that is true or false.
The questionable mem.mif may just force you to load weForth and to run the metacompiler to generate a fresh mem.mif image. At times, I suspect that C. H. Ting put flaws in the provided code just to force students to work through the entire eP16inVHDL.pdf. Either than, or the publication was rushed.
My previous attempts to compile a Lattice XP2 Brevia2, compiled and loaded -- but appeared not to run. It may be that I did not properly specify i/o or that the CTS float prevented communications. Something was written to the FPGA as the LEDs that were originally lit with a a factory loaded application, all went off.
++++++++++++
I simply need to work through all my problems with loading FPGA IDEs. And I am doing that now. It is rather slow going as I have to rely on downloading rather large files and moving around the same.
It seems that I have to remove and reinstall my Quartus II V15, so I may try a Diamond IDE install before I attempt a Quartus II reinstall.
It appears that I originally did not have the pathways set for the IP Core software to deliver the files to the right locations.
Something similar may be occuring in Lattice Diamond IDE as neither of these applications are simple enough to do everything right out of the install.
+++++++
I seem to have enough space now to load Lattice Diamond IDE in Fedora 22 as well. So both versions of eP16 can proceed in parallel.
That''s about all for today.