Clocked ports, sampling on rising clock

[MaxFlashrom]

Did you get the clock output in a pin, the reference clock ?

I'm not sure I understand your question correctly. I think you're asking whether I managed to output the reference clock directly to an output pin, as this is what you tried to do in one of your examples. I found that I could not make this work. I could output half the reference frequency by using another clock block, so a maximum of 200MHz with the code below.

Code: Select all

#define REFDIV_REGNUM 8

out port clk_out_port = XS1_PORT_1I;
clock ref_clk = XS1_CLKBLK_REF;
clock div_clk = XS1_CLKBLK_1;

int main(void) {
//write_sswitch_reg(get_core_id(), REFDIV_REGNUM, 0x01); // 200 MHz reference clock
	write_sswitch_reg(get_core_id(), REFDIV_REGNUM, 0x00); // 400 MHz reference clock

	//configure_port_clock_output(clk_out_port, ref_clk); // This did not work

	configure_clock_ref(div_clk, 1); // divide by 2. Using a value of 0 here fails to produce any output.
	configure_port_clock_output(clk_out_port, div_clk);
	start_clock(div_clk);

	while(1);
}

I suspect that when directing a clock to a pin that it's clocked out with the reference clock rather than with system clock or just being multiplexed to the pin directly. I slowed the reference clock right down and it still won't output it directly. Trying to clock a clock out with itself is not going to work.

I found that changing the XN file to include

Code: Select all

ReferenceFrequency="400MHz"

did not work: it was just ignored. Only values up to half the System Frequency were accepted(200MHz here). Programming the divisor directly, as above did allow 400MHz to be programmed. One can see how the compiler has interpreted the XN file by looking at what

xobjdump --recources <binfile.xe>

reports.

Max.

[ale500]

Ops, that was bad wording. And yes, I meant to output the reference clock to a pin. I was under the impression that you could output the reference clock to a pin. Well, if it runs fast enough then we can a clock block and output ref_freq/2. I wanted to do some testing with 100 MHz sampling.

[rubenc]

Would this also work for input?

if you put a 6.25Mhz Signalclock
would you be able to read
0x00000000
and then
0xFFFFFFFF

Disregarding the syncronization, I mean,
it might also be
0x00000FFF
and
0xFFFFF000

etc..

[MaxFlashrom]

Would this also work for input?

if you put a 6.25Mhz Signalclock
would you be able to read
0x00000000
and then
0xFFFFFFFF

Disregarding the syncronization, I mean,
it might also be
0x00000FFF
and
0xFFFFF000

etc..

It may be possible to sample input ports at faster than 60MHz if they're not bieng used for an internal clock block.
I mentioned that a reference clock of 400MHz did produce 400/64 = 6.25MHz when outputing 0xffffffff, 0x00000000 in a loop. Of course if you really only wanted to sample a 6.25MHz clock without this massive oversampling then raising the Reference clock is not necessary any. What you're driving at however, is if one were to output 0xaaaaaaaa in a loop that should produce a 200MHz clock, so what about an input port, could that read a 200MHz 50% duty cycle clock in the same way?

I.e if you apply a 200MHz clock to a pin, raise the reference clock to 400MHz, could one actually read in 0xaaaaaaaa, or 0x55555555 ? Strictly one must sample at GREATER than twice the frequency(not twice the frequency: if one samples at a frequency, f, at 2f ,only twice the frequency, this is aliased with 0HZ ie. DC)
In practice one would want a bit of wiggle-room for jitter/ avoiding edges. There's only one way to find out: loop a hardware port back to an input port, clock the input port faster than the output port, and see what you can read. Clocking the ports from the same clock is not a true test though as, in general, the clock for and the bit stream won't be synchronous for the input but stream. You need two independently clocked Xcores to test it properly.

Max.