I found an Opencore program to generate the VHDL for my hamming SECDED code which will give me the automatic error correction I want, without having to develop my own logic to create the syndrome (indicator of a single bit error and its location), as well apply the syndrome to correct the data.
The only delay came from fighting through the install of g++ on a minGW system I have on a Windows system - since I only use these systems very rarely for specific code or compile requirements, it takes me a while to sort out what is necessary to make it run properly.
In this case, it is the PATH variable which Msys is setting to add /mingw/bin , not c:/mingw/bin, thus confusing Windows and failing to find the compiler and other executables. With that fixed, when I run the g++ compiler, a spurious error asking to ready a specific hard disk (that doesn't exist on this system) which a Google search finds is a packaging error in how the g++ module was set up for installation.
Bypassing the false hard disk error brings me to an error where the module is using a standard library function (strcpy) but the include file is not being accessed. I will look to see what other configuration issue might be behind this new symptom.
Another set of known issues that many have experienced, but the workaround was easy to implement and finally the program was running. I used it to spit out the Hamming encoder/decoder VHDL for 120 bit data and transferred it over to my SAC Interface workstation.
I finished restructuring the data pump logic for the fast SPI link - stepping the data through the Hamming and CRC processes. Once this is ready, I have to make corresponding changes to the VHDL to run in a Nexys2 board, which is the other end of the fast link. Only when both are prepared can I begin testing the fast link.
Bypassing the false hard disk error brings me to an error where the module is using a standard library function (strcpy) but the include file is not being accessed. I will look to see what other configuration issue might be behind this new symptom.
Another set of known issues that many have experienced, but the workaround was easy to implement and finally the program was running. I used it to spit out the Hamming encoder/decoder VHDL for 120 bit data and transferred it over to my SAC Interface workstation.
I finished restructuring the data pump logic for the fast SPI link - stepping the data through the Hamming and CRC processes. Once this is ready, I have to make corresponding changes to the VHDL to run in a Nexys2 board, which is the other end of the fast link. Only when both are prepared can I begin testing the fast link.
No comments:
Post a Comment