Tuesday, April 27, 2010

Build gvim 7.2 x64 and create installer for Windows 7, Vista, XP

Update with new installer and changes for building 7.3:

I've been getting kinda tired of not having a decent installer for gvim 7.2 on my Vista x64 system. I have figured out all of these steps, and I'm sharing them with you. You can download the actual installer from:

http://nkcorner.com/gvim72.exe (64 bit only, includes all patches up to and including 7.2.411)

This version is built exactly as I've shown below. The printing works in Windows, and so do the context menus. It also installs to the Program Files directory as it should. This is only tested on Vista x64.

Here are the steps: (I'm sure they can be somewhat simplified and I'd be happy to hear about that.)

Create a folder called building, eg c:\building

Download these files:
Unzip them using 7-zip or alternative program.
Each of these archives contain a vim72 folder, extract them all into c:\building\vim72 folder.

Download these files, and extract them to c:\building\patches

Download these files into c:\building\patches

Download and install these programs:
Optionally install make, although we will be bypassing the make with a manual command due to incorrect syntax in the Makefile when running on Windows.

Add "C:\Program Files (x86)\GnuWin32\bin\" to your path variable and reopen any command prompts.

Download and extract diff.exe from:
Copy diff.exe to c:\building\

Download and install Windows SDK for AMD64:
If this link doesn't work, then go to
and download the GRMSDKX_EN_DVD.iso (which is the AMD64 version)

Download this package and copy upx.exe to c:\building\vim72\nsis

Open a command prompt and run
C:\Windows\System32\cmd.exe /E:ON /V:ON /T:0E /K "C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\SetEnv.cmd" /release
Use this command prompt for building as it is now set to 64 bit release.

Install patches by changing directory to c:\building\vim72 and running these commands in this order:
patch --binary -p0 < ..\patches\7.2.001-100
patch --binary -p0 < ..\patches\7.2.101-200
patch --binary -p0 < ..\patches\7.2.201-300
patch --binary -p0 < ..\patches\7.2.301-400
patch --binary -p0 < ..\patches\7.2.401
patch --binary -p0 < ..\patches\7.2.402
patch --binary -p0 < ..\patches\7.2.403
patch --binary -p0 < ..\patches\7.2.404
patch --binary -p0 < ..\patches\7.2.405
patch --binary -p0 < ..\patches\7.2.406
patch --binary -p0 < ..\patches\7.2.407
patch --binary -p0 < ..\patches\7.2.408
patch --binary -p0 < ..\patches\7.2.409
patch --binary -p0 < ..\patches\7.2.410
patch --binary -p0 < ..\patches\7.2.411

Change directory to c:\building\vim72\src, and build using this command:
nmake -f Make_mvc.mak OLE=yes
nmake -f Make_mvc.mak OLE=yes GUI=yes
(First command produces vim.exe and second one produces gvim.exe)

Change directory to c:\building\vim72\runtime\doc and run
sed -e "s/[ \t]*\*[-a-zA-Z0-9.]*\*//g" -e "s/vim:tw=78://" uganda.txt | uniq >uganda.nsis.txt
This is the line that should be run from the Makefile in this directory, but Windows make.exe has trouble with it.

Change directory to c:\building\vim72\nsis and open gvmi.nsi in a text editor (preferably not notepad or wordpad...)
At line 22 change (comment out)
!define HAVE_NLS
#!define HAVE_NLS
(I don't have a 64-bit libintl.dll)

Replace all instances of PROGRAMFILES with PROGRAMFILES64
(Forces the default installation directory to be the Program Files directory instead of Program Files (x86).)

At line 248 change
   File /oname=vim.exe ${VIMSRC}\vimd32.exe
   File /oname=vim.exe ${VIMSRC}\vimw32.exe
(The check for WINNT isn't working on my Vista x64 system... so I force it)

Copy all files and directory from c:\building\vim72\runtime to c:\building\vim72

Rename these files:
c:\building\vim72\src\gvim.exe -> c:\building\vim72\src\gvim_ole.exe
c:\building\vim72\src\vim.exe -> c:\building\vim72\src\vimw32.exe
c:\building\vim72\src\install.exe -> c:\building\vim72\src\installw32.exe
c:\building\vim72\src\uninstal.exe -> c:\building\vim72\src\uninstalw32.exe

Copy and rename this file:
c:\building\vim72\src\xxd\xxd.exe -> c:\building\vim72\src\xxdw32.exe

Change directory to c:\building\vim72\nsis and run:
"c:\Program Files (x86)\NSIS\makensis.exe" gvim.nsi

Nachum Kanovsky
FPGA & Embedded Software Expert

Friday, April 23, 2010

Modelsim, scripts getting locked?

So I was working a lot with Modelsim yesterday simulating DDR2 cores, but I kept having to change the script. But Modelsim wouldn't let me!!! So here's the key, when Modelsim is running a script and you interrupt it while it's running, it may show:
and then you're just screwed! OK OK, type 'abort' and hit enter. This will finally end the script and allow you to modify your script without closing down Modelsim. Shockingly 'quit -sim' doesn't work, nor are there any menu options that help.

Perhaps this'll save someone else problems.

Lattice DDR2 cores - read_data_valid doesn't come up...?

So as is usual, I'm suspicious of crummy simulation models and that's of course the reason why Lattice's ECP3 DDR2 (6.7 and 7.0 beta) cores don't give read_data_valid during simulation... They output the data, but not the read_data_valid signal.

After 2 hours of debugging, I found that it was all in the module hookup. read_tap_delay! The signal that they don't bother documenting, or explaining was causing the problem. I accidentally hooked up read_tap_delay to 2'b0 instead of 6'b0 (shame on me). This killed it. I guess I learn 2 things here, first that lack of documentation doesn't indicate lack of importance! and second that 2'b0 doesn't translate in all situations to fill the port with zeroes!

On the other hand, I finally took the plunge and hooked up Micron's DDR2 model. I have to say that it was the easiest model ever to hook up! Just define sg3 and x16 and voila, it's done. OK OK, there were two small snafus...

Lattice provides their cores with a simulation model, if you try to swap out their DDR2 model (also Micron's), then there is at least one problem. They have a file where they define x8 for all cores. I don't know why, I'd guess it's got something to do with Micron's old model. Anyhow for those of you swapping models for simulation, be aware of that. It will explain why Micron's model suddenly insists on a data bus of incorrect size even though you defined everything properly!

Lattice doesn't include negative differential ports in their top level definition, so if you have a clk_p and clk_n, all that appears in the top level netlist is clk_p, and the lpf file (constraints file) indicates the differential nature and automatically connects the differential pair. (Yes, pairs are fixed in the ECP3 and many other Lattice FPGAs.)

So now I have a DDR2 model requiring clk_n and dqs_n. clk_n is simple, just:
wire clk_n;
assign clk_n = ~clk_p;
easy shmeezy

On the other hand, dqs_n is an experience in learning. To save you the time that you've probably already spent trying to figure this out, here it is:
wire dqs_n;
assign dqs_n = (dqs_p === 1'bz) ? 1'bz : ~dqs_p;

Yes yes, the 3 equal signs are necessary. Shockingly a part of the language I'd never needed to use before, now comes in handy.

Live to learn another day,