Hey Team.
Do we have any examples of fairly simple project where a Snickerdoodle (or similar Zynq board) provides and/or consumes a MRCC clock signal? Are there any issues to be careful of?
Hi Jason,
If you’re looking for an example project, the piSmasher uses the MRCC pins on snickerdoodle’s FPGA headers for various Ethernet and HDMI clocks. There are some Vivado project available here: https://github.com/krtkl/piSmasher-testing/tree/master/piSmasher_4.1
You’ll only need the SRCC/MRCC if you’re feeding a clock into the FPGA. The only thing that comes to mind re: ‘words of caution’ is that you want to be careful not to attach it to a pin with a voltage higher than that of the bank. An easy way to ensure this is to have a clock source VCC that’s common with the bank’s VIOref’s.
Hope that helps,
Cousins
Thanks Ryan. I’ve just looked at the hdmi-pass-through project there. That has been helpful. I do have some new questions though.
You mention that outgoing clocks really don’t need SRCC/MRCC. Are you making the point that for most protocols the outgoing clock usually has a single destination so doesn’t need special routing so that the clock arrives at every latch at the same time? (It just needs to be in sync with any exported data line that it’s supporting/clocking.) But an incoming clock could be feeding multiple latches and they will probably need to use a clock tree to ensure all those latches experience the rising edge at the same time? Is that your point? Or are you saying something beyond that?
I have read that outgoing clocks should use ODDR. I don’t yet understand what that is and why this is important.
I have experimented with an outgoing clock design. I started with the basic RavvenLabs Blink design which produces a 1Hz square wave with from the 50MHz FCLK0. That IP also has a RESET_N input fed from Zynq’s FCLK_RESET0_N. It works great.
But when I enhance that design by connecting FCLK_CLK0 also to a JA1.38 (IO_L13P_T2_MRCC_35) something goes awry. My logic analyzer shows a 50MHz signal on JA1.38 as I’d expect, but the “led” output of the blink IP is no longer 1Hz signal. It’s now 50MHz. Enhancing the design a bit further to expose the RESETN signal, my logic analyzer is showing that to be a 50Mhz signal as well. In other words it appears connecting FCLK0 to JA1.38 has caused the reset signal from the Zynq to oscillate. I’ve scanned the web several days looking for an explanation, but I’m finding none. What do you think might be causing that?
The commit that is failing can be found here.
https://github.com/jasonnet/vhdl-projects/tree/failedWithClockOut/sbUtopia
The previous commit does not create a port on the FCLK0 pin and has no problem.
Hi Jason, do you have a tcl script for recreating the project? Or a zipped Vivado project you can share? That would be a bit easier.
Re: the clock questions, you can use ODDR for clocks but that likely isn’t necessary.
Talking about this with the guys: The DDR I/O registers basically take 2 bits on every clock and then output them on the rising and falling edge of that clock. So if you tie those inputs to static 1 and static 0, then feed ODDR the internal clock, the output pin will have a copy (or it’s inverse). Since ODDR is used with DDR memory, it’s basically on every I/O pin…
On the other hand, if internally you generate a x2 clock, you can just use a simple toggle flip flop to generate the desired clock at the pin. Given that the internal clocks can be 600MHz, it’s unlikely (unless you are generating an LVDS clock which uses OSERDES instead of ODDR) that you actually need ODDR, but there is no harm in using it if you know how to since it does make for lower jitter.
-Cousins
Taking a closer look at the project, it appears the issue is the reset is being used incorrectly. Suggest inserting a processor reset block instead..
Thanks Ryan.
Blink is the design from the RavvenLabs site. I’m not sure why it includes reset support at all, and why it triggers on reset+clock instead of just clock. I have modified the vhdl to do reset level tests only and no reset triggers, but the reset line is still toggling.
begin
–process(clk,reset_n)
process(clk)
begin
if (clk’event and clk = ‘1’) then
if (reset_n = ‘0’) then
count_sig = 0;
output_sig = ‘0’;
elsif (count_sig = max_count) then
count_sig = 0;
output_sig = not output_sig;
else
count_sig = count_sig + 1;
end if;
end if;
end process;
blink_out = output_sig;
end beh;
Further eliminating use of fclk_reset0_n gives us:
begin
process(clk)
begin
if (clk’event and clk = ‘1’) then
–if (reset_n = ‘0’) then
– count_sig <= 0;
– output_sig <= ‘0’;
–elsif (count_sig = max_count) then
if (count_sig = max_count) then
count_sig <= 0;
output_sig <= not output_sig;
else
count_sig <= count_sig + 1;
end if;
end if;
end process;
blink_out <= output_sig;
end beh;
Yet a variant of the original problem still occurs. The logic of the blink module is clearly driving blink_out the way it should, but it can’t seem to hold it here. If it’s trying to hold it low, there are brief (2-4ns) moments every 20ns where the logic analyzer (500MSamp/sec) says the signal was briefly high. And if the module is trying to hold blink_out high, randomly the signal will go low for 2ns. At the same time this is happening… FCLK_reset0_N stays mostly high, but randomly occasionally (99.9% duty cycle) drops for 2ns. When this happens, if the logic was trying to hold blink_out high, there’s a good chance that blink_out will drop low for a 2ns sample or two.
And if I disconnect the FCLK0 signal from the logic analyzer probes, the logic analyzers reports blink_out, fclk_reset0_n, fclk1, and fclk_reset1_n signals are perfectly behaved. So actually having the l.a. probe on FCLK0 seems to be necessary to reproduce the problem.
As just alluded to, I can monitor FCLK1 and FCLK_RESET1_N on the logic analyzer and they behave just fine. (Exception: If the “0” circuit is misbehaving, the “1” signals will show anomalies, but not to the degree that the “0” is.) So it seems the “0” circuit (which has the blink component) is more prone to these problems.
If the blink component is modified to not accept a reset_n input, the problem still occurs. So it seems that although the blink component might contribute to the problem, it doesn’t seem like its use of reset contributes to the problem.
For my edification, my question for you is:
Q1: Regarding reset being used incorrectly, what principle is violated by this use of reset? Ex. “Unless documented otherwise, treat all reset signals as asynchronous and in need of synchronizing before use” or “If a vhdl process needs to trigger on both a reset and a clock, this suggests that the designer knows the reset is asynchronous, which is a behavior that is not well handled by triggering on both”.
I’ve started to read to try to understand what a processor reset block is and why it’s needed in general and in this particular case. My quick reading so far elicits more questions.
Q2: This module seems to be trying to resolve the problem of external resets being asynchronous and bouncy/noisy. Is the FCLK_RESET0_N asynchronous? or noisy by design? Where would I have read about that behavior in FCLK_RESET0?
Q3: Why would the FCLK_RESET0_N begin to flip at all? This is indicating an underlying problem, right? Where would I have read about that?
Thanks.
J.
Hi Jason,
Sorry for the delay. Looking into your project, a few things come to mind:
There is a comment “- - process(rst,clk)” which has apparently removed the sensitivity to rest. If you’re using the reset from the PS, you probably want an asynchronous reset but it’s coded like a synchronous reset. Strange things can happen when you handle resets incorrectly in terms of behavioral sim not matching implementation. That’s the main reason for a reset block.
Looking at the VHDL (it wasn’t totally clear if this was from Dr. Kaputa’s project or something you generated), it looks like you’ve inferred a latch.
You should probably define count_sig, count_sig_next, output_sig, and output_sig_next (unless there’s some reason not to?).
In the third conditional “count_sig <= count_sig + 1” there’s no output_sig <= [something]…and what’s likely being inferred is output_sig <= output_sig, which would be a latch. That’s likely what’s messing things up.
It’s a little hard to figure out specifically why it’s not all behaving, but if you look at the schematic view is should make it pretty clear for a simple circuit like this.
Let me know if that helps track down the problem…
-RC
Thanks for the thoughts about use of the reset line.
And also the other thoughts. I have experiment with your suggestions, but so far there’s little improvement.
The problem happens even when the VHDL is essentially just
I really suspect it’s something REALLY dumb that’s the problem. Perhaps it’s something you’ll not be able to reproduce due to some unwritten step I’ve taken.
It seems to me that the behavior changes somewhat if I move the (longish) leads in 3-space. Ex. The reset signal stops toggling, but blink_out above remains glitchy.
I’ve tested improving the grounding of the logic analyzer leads. But that has not helped.
I’ll keep on digging in to this looking for loose connections, wrong pin errors, shorts, etc.
Thanks for your help.