Compiling firmware for Mesa 5i20 + 7i48 + 7i44

PCW
Offline
Moderator

16 Aug 2014 11:30 - 16 Aug 2014 11:31 #49916 by PCW

Replied by PCW on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

In this example if i want to change the number of 8 instances of stepgen to 3 instances must edit x"08" to x"03" ?

Yes

Also if i want to change ordering of pins is enough to change the ordering of PinDesc array elements ?
IOPortTag & x"00" & StepGenTag & x"81",	-- I/O 24
		IOPortTag & x"00" & StepGenTag & x"82",   -- I/O 25
		IOPortTag & x"00" & StepGenTag & x"83",   -- I/O 26
		IOPortTag & x"00" & StepGenTag & x"84",   -- I/O 27
		IOPortTag & x"00" & StepGenTag & x"85",   -- I/O 28
or must change and the entries of this array ? What mean the hex numbers x"00", x"81" / x"82" etc ?

You change the pinout by modifying the order and entries in the pindesc array

Take a look at IDROMConst.vhd for the structure definitions and constants

For example those hex constants should really be constants from IDROMConst.vhd:

constant	StepGenStepPin : std_logic_vector(7 downto 0) := x"81";
		constant	StepGenDirPin : std_logic_vector(7 downto 0) := x"82";
		constant	StepGenTable2Pin : std_logic_vector(7 downto 0) := x"83";
		constant	StepGenTable3Pin : std_logic_vector(7 downto 0) := x"84";

Last edit: 16 Aug 2014 11:31 by PCW.

The following user(s) said Thank You: vre

Please Log in or Create an account to join the conversation.

vre
Offline
Platinum Member

17 Aug 2014 06:38 #49956 by vre

Replied by vre on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

So the following code..

IOPortTag & x"00" & StepGenTag & x"81",	-- I/O 24
IOPortTag & x"00" & StepGenTag & x"82",   -- I/O 25
is equal to
IOPortTag & x"00" & StepGenTag & StepGenStepPin,	-- I/O 24
IOPortTag & x"00" & StepGenTag & StepGenDirPin,   -- I/O 25

The manual says that cards provide common grounded or differential signals where can i set the signals in I/O ports to be common grounded or differential ?

The StepGen has the following pins

constant	StepGenTag : std_logic_vector(7 downto 0) := x"05";
		constant	StepGenStepPin : std_logic_vector(7 downto 0) := x"81";
		constant	StepGenDirPin : std_logic_vector(7 downto 0) := x"82";
		constant	StepGenTable2Pin : std_logic_vector(7 downto 0) := x"83";
		constant	StepGenTable3Pin : std_logic_vector(7 downto 0) := x"84";
		constant	StepGenTable4Pin : std_logic_vector(7 downto 0) := x"85";
		constant	StepGenTable5Pin : std_logic_vector(7 downto 0) := x"86";
		constant	StepGenTable6Pin : std_logic_vector(7 downto 0) := x"87";
		constant	StepGenTable7Pin : std_logic_vector(7 downto 0) := x"88";
		constant	StepGenIndexPin  : std_logic_vector(7 downto 0) := x"01";
		constant	StepGenProbePin  : std_logic_vector(7 downto 0) := x"02";

The x81 x82 pins make sense.. what represent the other pins ?

and here

constant ModuleID : ModuleIDType :=( 
--'TAG,  VERSION,  CLOCK,  INSTANCES,  BASE ADDRESS,  NUMBER OF REGISTERS,  STRIDES,  MPBITMASK'
		(WatchDogTag,	x"00",	ClockLowTag,		x"01",	WatchDogTimeAddr&PadT,		WatchDogNumRegs,		x"00",	WatchDogMPBitMask),

What is the VERSION and STRIDES entries ?

Sorry for the silly questions but iam trying to do it corrrectly and don't brick the card.

Please Log in or Create an account to join the conversation.

PCW
Offline
Moderator

17 Aug 2014 08:56 - 17 Aug 2014 08:57 #49959 by PCW

Replied by PCW on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

The other stepgen output pins are for table mode, in addition to the normal
step/dir, cw/ccw and quadrature modes, the stepgen module can support
up to 8 wide and 16 deep arbitrary data table driven sequences on the output pins

Each hardware module has a version number in case the driver needs to change
its behavior on a per version basis or warn of bugs at a particular version level

The strides constant sets the register and instance strides so the driver
knows how to address the registers and per channel instances of registers

(normally I just copy/paste this info from another pinout file, there is no reason to change these
unless you are changing an existing module)

You cannot brick the card with any changes in the pinout files, but you can easily make
a configuration that wont fit in the FPGA (too many resources used) or a bitfile that causes the driver to complain and exit because its has some inconsistency.

Last edit: 17 Aug 2014 08:57 by PCW.

The following user(s) said Thank You: vre

Please Log in or Create an account to join the conversation.

vre
Offline
Platinum Member

18 Aug 2014 11:38 - 18 Aug 2014 14:50 #49987 by vre

Replied by vre on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

Ok i made a bit file but when iam loading the driver this error occurs

[   84.936494] hm2: loading Mesa HostMot2 driver version 0.15
[   97.092426] hm2_pci: loading Mesa AnyIO HostMot2 driver version 0.7
[   97.092468] hm2_pci: discovered 5i24 at 0000:01:05.0
[   97.093021] hm2/hm2_5i24.0: inconsistent Module Descriptor for UART Transmit Channel, not loading driver
[   97.093024] hm2/hm2_5i24.0:     Version = 0, expected 0
[   97.093025] hm2/hm2_5i24.0:     NumRegisters = 4, expected 4
[   97.093027] hm2/hm2_5i24.0:     InstanceStride = 0x00000040, expected 0x00000010
[   97.093029] hm2/hm2_5i24.0:     MultipleRegisters = 0x0000000F, expected 0x0000000F
[   97.093031] hm2/hm2_5i24.0: inconsistent Module Descriptor!
[   97.093033] hm2/hm2_5i24.0: failed to parse Module Descriptor 5
[   97.093037] hm2_5i24.0: board fails HM2 registration
[   97.093051] hm2_pci: probe of 0000:01:05.0 failed with error -22

the pin file

(UARTTTag,		x"00",	ClockLowTag,	x"01",	UARTTDataAddr&PadT,			UARTTNumRegs,			x"10",	UARTTMPBitMask),
(UARTRTag,		x"00",	ClockLowTag,	x"01",	UARTRDataAddr&PadT,			UARTRNumRegs,			x"10",	UARTRMPBitMask),
....
IOPortTag & x"00" & UARTTTag & UTDataPin,			-- I/O 70
IOPortTag & x"00" & UARTRTag & URDataPin,			-- I/O 71

If i remove completelly UART loads fine.
Also GND pins in p2/p3/p4 connectors are indepedent or are connected alltogether in the card ?
Because iam planing to not use ribbon cable with 1 wire per GND pin but 1 wire for all GND pins.

Last edit: 18 Aug 2014 14:50 by vre.

Please Log in or Create an account to join the conversation.

PCW
Offline
Moderator

18 Aug 2014 20:54 #49997 by PCW

Replied by PCW on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

Pretty sure you will have to use master to use the UART module. Theres an issue with strides in that there are only 2 available in the current IDROM format and 3 are needed if you combine the UART with say SSerial. I _think_ master has a workaround for this.

1 wire for ground is likely to work poorly both because of ground inductance and crosstalk, especially if high speed signals are conveyed in the cable.

Please Log in or Create an account to join the conversation.

vre
Offline
Platinum Member

19 Aug 2014 05:54 #50026 by vre

Replied by vre on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

I don't have sserial this is all the modules in pin file

--		TAG,			VERSION, CLOCK,				INSTANCES, BASE ADDRESS,				NUMBER OF REGISTERS,	STRIDES, MPBITMASK
		(WatchDogTag,	x"00",	ClockLowTag,		x"01",	WatchDogTimeAddr&PadT,			WatchDogNumRegs,		x"00",	WatchDogMPBitMask),
		(IOPortTag,		x"00",	ClockLowTag,		x"03",	PortAddr&PadT,					IOPortNumRegs,			x"00",	IOPortMPBitMask),
		(QcountTag,		x"02",	ClockLowTag,		x"04",	QcounterAddr&PadT,				QCounterNumRegs,		x"00",	QCounterMPBitMask),
		(PWMTag,		x"00",	ClockHighTag,		x"01",	PWMValAddr&PadT,				PWMNumRegs,				x"00",	PWMMPBitMask),
		(StepGenTag,	x"02",	ClockLowTag,		x"03",	StepGenRateAddr&PadT,			StepGenNumRegs,			x"00",	StepGenMPBitMask),
		(UARTTTag,		x"00",	ClockLowTag,		x"01",	UARTTDataAddr&PadT,				UARTTNumRegs,			x"10",	UARTTMPBitMask),
		(UARTRTag,		x"00",	ClockLowTag,		x"01",	UARTRDataAddr&PadT,				UARTRNumRegs,			x"10",	UARTRMPBitMask),
		(LEDTag,		x"00",	ClockLowTag,		x"01",	LEDAddr&PadT,					LEDNumRegs,				x"00",	LEDMPBitMask),

I don't want to use ribbon cable for 2 reasons
* it is prone to short in the points where the connector punches the cable and fpga is very sensitive to shorts
* wires are parallel and crosstalk can happen
The GND are shorted alltogether in the card ? Because if they are shorted and make star topology with 25 GND wires
reflection of signals in 25 GND branches is problem or not ?
25 twisted pairs (from cat5/6 cable) would be ok ?

Please Log in or Create an account to join the conversation.

PCW
Offline
Moderator

19 Aug 2014 06:35 #50028 by PCW

Replied by PCW on topic Compiling firmware for Mesa 5i20 + 7i48 + 7i44

don't want to use ribbon cable for 2 reasons
* it is prone to short in the points where the connector punches the cable and fpga is very sensitive to shorts
* wires are parallel and crosstalk can happen
The GND are shorted alltogether in the card ? Because if they are shorted and make star topology with 25 GND wires
reflection of signals in 25 GND branches is problem or not ?
25 twisted pairs (from cat5/6 cable) would be ok ?

Shorts in the connector should be very rare if the proper tooling and IDC connectors are used (or you get cables from us)

Shorts to GND or other FPGA signals are unlikely to damage the FPGA
(shorts to voltages outside the range of 0 to ~7V (setup for 5V tolerant mode) will, naturally)

The parallel signals include interleaved grounds which results in a controlled impedance, minimal
crosstalk and excellent signal integrity (we can send multiple 10 MHz signals over 15 Feet with good results if properly terminated)
(Note that the SCSI bus and other parallel buses use this scheme)

If you are not using master (which should avoid the UART complaint in the driver)
you can edit the top level file and change the constant InstStride1 to 16

The following user(s) said Thank You: vre

Please Log in or Create an account to join the conversation.

Moderators: PCW, jmelson

Time to create page: 0.064 seconds