VHD Header Help

Hi All

My intent is to merge some vhd files to get a 7i76e + 7i78 + 7i89 

I saw a post here (from PCW I believe) sayign the count in the 4th column was the number of those modules, so for the stepgens I want (6x or more) I've been putting x06, and same for the encoders (1x spindle + 6x on the DB25 headers), just increasing the built in Qcount. I believe I don't need muxed ones (I have single ended A/B/Z glass scales), finally I then make sure the total number of entries in the whole array was the same as the standard hostmot2 7i76e examples. No ide if this logic is sound or not... 

(HM2DPLLTag,x"00",ClockLowTag, x"01",HM2DPLLBaseRateAddr&PadT,HM2DPLLNumRegs,x"00",HM2DPLLMPBitMask), (WatchDogTag,x"00",ClockLowTag, x"01",WatchDogTimeAddr&PadT, WatchDogNumRegs,x"00",WatchDogMPBitMask),
(IOPortTag,x"00",ClockLowTag, x"03",PortAddr&PadT,IOPortNumRegs,x"00",IOPortMPBitMask),
(QcountTa    x"02",   ClockLowTag,x"06",QcounterAddr&PadT,QCounterNumRegs,x"00",QCounterMPBitMask),  
(StepGenTag,x"02",ClockLowTag, x"06", StepGenRateAddr&PadT,StepGenNumRegs,x"00",StepGenMPBitMask)
(MuxedQcountTag, MQCRev,ClockLowTag, x"01",MuxedQcounterAddr&PadT,MuxedQCounterNumRegs,x"00", MuxedQCounterMPBitMask),
(MuxedQCountSelTag, x"00",ClockLowTag, x"01", NullAddr&PadT,x"00",x"00",x"00000000"),
(SSerialTag,x"00",ClockLowTag,x"01",SSerialCommandAddr&PadT,SSerialNumRegs,x"10",SSerialMPBitMask),  
(LEDTag,x"00",ClockLowTag,x"01",LEDAddr&PadT,LEDNumRegs,x"00",LEDMPBitMask),
(NullTag,x"00",NullTag,x"00",NullAddr&PadT,x"00",x"00",x"00000000"),
(NullTag, x"00", NullTag,x"00",NullAddr&PadT,x"00",    
more null
more null

until I get to the same line number as the examples so same number of modules. 

I think I've made a dud bit file and written it to my 7i76e at some stage, the first time I tried to write it, mesaflash did the erasing, got halfway through the writing "WWWW..." thing and the terminal just hung. Ctrl + C'd the terminal, and I think the 7i76e stopped responding. 
I power cycled the card itself, and now mesaflash can see it and write known good bit files to it, but after I write new bit files and --reload, the --readhmid just returned "None" for all of the channels. 
I've since power cycled a few times and it seems to be writing standard bitfiles again by some miracle.

Can someone explain the header logic or point me to an explanation? 
Can I just keep changing the module count freely and the Xilinx tool will flag if it runs out of space? 
If the Xilinx tool compiles it okay can I be confident it won't brick the board?
How do I know if it's in fallback or normal boot? 
What do the other columns in the header do, do I need to set memory addresses where the modules start or block sizes or anything? I'm wondering if I could be increasing module count and then overflowing the following module or something. 
Does the total number of modules in that array need to be correct / a specific number / does it matter? 

I've skimmed the hostmot2 dataflow vhd file but fallen at the first hurdle: 





This line obviously reads that count but I can't see where NumberOfModules (function? attribute of the an object called "work"?) is defined so I'm lost. As you can tell I don't have a clue how this code works so I'm just a smidge lost  
I've had PCW post a few bitfiles here for me, for which I'm eternally grateful, but I feel bad so I'd prefer to acutally understand what's going on and be able to do it myself (and pass the favour on if it's not potentially harmful to someone elses setup!)

Thanks, 
Kealan

Here's an example:

 

It's a bit tricky because you do need to use muxed encoders for all
encoders (because the 7I89 uses physically muxed encoders)

 

What a legend, flashed and looking good now, thank you . 

I'll get on with the hal mods to get the encoder inputs "wired" up and see

I included the pinout file if you want to use it as a starting point for a different configuration.

Note that having all muxed encoders is a little odd as non-muxed encoder show up as 2
encoders each, with only one being useable so the encoders are:

7I89 0..7
7i76 8 (9)
7I78 10 (11)

Aliased encoder in parens

I keep meaning to add the capability of supporting both encoder types
simultaneously to the driver, but there always seems to be something of
higher priority...