Eclypse Z7 Trigger on ZMOD

[orenderj]

I am using the DDR streaming example and trying to understand the trigger scheme and get it to work. It seems that regardless of the value that I place into LevelTriggerAcquisition (&Pipe, GainTestRelays, 0b00011, 0x0100, 0x0100); that the hardware will trigger. I removed the manual trigger up in the leveltrigger function as well. Is there an example demonstrating the use of the trigger block? For example, I'd like to trigger on the rising edge of a waveform as a test. I'm not following the flow of the trigger setup in terms of waiting for idle, setting up, start, etc. 

 

[artvvb]

Hi @orenderj

The intended case would be to be able to use LevelTriggerAcquisition (&Pipe, GainTestRelays, 0b00010, 0x0000, dont_care);, as an example, to trigger an acquisition on a rising 0 V level on channel 1. The third argument, the trigger enables, is used to mask out unwanted triggers in hardware, so the manual trigger shouldn't be happening when it's disabled - I'm currently investigating this.

There is currently a bug where the trigger generator incorrectly treats the stream data bits 0 to 15 as channel 1 and bits 16 to 31 as channel 2 instead of vice versa. I'm working on fixing this in hardware. A software workaround should be to switch the trigger enable bits and trigger levels being passed to LevelTriggerAcquisition.

The trigger enables are ordered as follows:

• bit 0: manual
• bit 1: ch1 rising
• bit 2: ch1 falling
• bit 3: ch2 rising
• bit 4: ch2 falling

Note the level triggers use a signed comparison to check whether the level is between two consecutive samples (or equal to the most recent sample). A code snippet from the sources: `ch1_rising  = (ch1 >= ch1_level) && (ch1_prev < ch1_level)`.

In the meantime, I've added some state diagrams here which may help to explain the mechanism: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/eclypse_platform_manual#trigger_detector

In terms of when to set configuration regs, assert start, and wait for idle, the main thing is to start the detector last of all the modules in the input pipeline, since it acts as a final gate in front of the DMA. In general, set the config regs for the entire pipeline, start up the stuff upstream of the trigger detector, start the DMA transfer, start the detector. Then, wait for the trigger to fire, indicated by the DMA transfer completing and the detector going idle. Also, the "trigger enable"s should be considered config regs for these purposes.

Thanks,

Arthur

[orenderj]

Thanks @artvvb. I actually found that using the WaveForms SDK and the Eclypse Z7 that I can capture the samples that I need to bring into a custom C# application, but I'd really like to be able to do the same thing with your trigger example code as I can modify the block design quite easily and insert some signal processing modules along the way. The trigger code is very useful in theory, but I havent been able to get it to work. The manual trigger always fires even if I'm basically at 0v and have a terminator on the SMA with a rising edge trigger way above my signal. If you expect some bug fixes soon, I'll continue using the SDK to get me going, but if not, I'll take your information from the post above and try and get things working. Thanks again!

[orenderj]

Hi @artvvb,

Just following up on this. I tried your fixes and I'm still lost. I check the ILA and have some questions. The zero volt trigger you mentioned above works. I can slowly lower my signal from 1V down to 0V and it will trigger. When any values in the trigger level settings other than zero are applied, they dont seem to be the trigger value. It seems to still be zero. I can set UserRegisters_WriteReg(LevelTriggerPtr->BaseAddr, USER_REGISTERS_OUTPUT0_REG_OFFSET, Levels); to anything from 0x0000 to 0xFFFF for each channel u16 in that u32. If I check the ILA, the trigger fires on bit 3 showing a falling edge channel 1. My trigger was set to some high value, although Im still not sure what that unit is. Is it ADC counts? Signed millivolts?

Anyway, If you see the two virtual busses from the AXI stream, the values are ranging from 0x0000 to 0xFFFF and I am inputting a -20 to 20mV sine wave. 

Wondering if you can elaborate slightly on the trigger value settings and I think that if I can understand that, I'll be in the clear.

Thanks again!

[artvvb]

Hi @orenderj

Found the bug that is causing the issues you are seeing. The register that the levels are sent to hardware through was written, however, an additional register write which is required to trigger the "UserRegisters" module to pass that register value through its CDC handshake mechanism to the trigger generator was omitted, causing the levels at the trigger detector to never be updated from the default 0. To correct this, UserRegisters_IssueApStart should be called after the WriteReg call. Here's a snippet from the corrected LevelTriggerAcquisition with the surrounding context:

	// Configure the trigger
	TriggerSetPosition (TrigPtr, BufferLength, TriggerPosition);
	TriggerSetEnable (TrigPtr, TrigEnable);

	u32 Levels = ((u32)(Ch1Level) << 16) | (Ch2Level);
	UserRegisters_WriteReg(LevelTriggerPtr->BaseAddr, USER_REGISTERS_OUTPUT0_REG_OFFSET, Levels);
	UserRegisters_IssueApStart(LevelTriggerPtr); // ADD THIS LINE

	AxiStreamSourceMonitorSetSelect(TrafficGenPtr, SWITCH_SOURCE_SCOPE);

To answer the question about the data format:

The stream data consists of two signed 16-bit values, one for each channel. Channel 1 is bits 31:16 and Channel 2 is bits 15:0. These are the output of the calibration modules in the ZmodScopeController. The 14-bit ADC samples are padded prior to going through the calibration module.

The trigger levels are encoded the same way as the data: essentially 14-bit twos-complement ADC data, padded up two bits.

There's some more information on the calibration scheme in the ZmodScopeController's User Guide, pages 6-10. Figure three may be particularly helpful.

This function, which I've quickly tested with a 0.5V level trigger, should let you calculate the raw levels:

u16 VoltsToTriggerLevel (float data, u8 resolution, u8 gain) {
	#define IDEAL_RANGE_ADC_LOW 25.0f
	#define IDEAL_RANGE_ADC_HIGH 1.0f
	float vMax = gain ? IDEAL_RANGE_ADC_HIGH : IDEAL_RANGE_ADC_LOW;
	return (u16) (data * (float)(1 << (resolution - 1)) / vMax) << (16 - resolution);
}

It's effectively the inverse of the data to raw floating point volt conversion functions, plus a two bit pad.

Thanks,

Arthur

[orenderj]

Ah, youre awesome! Thank you so much for digging into this.