MMCM Clock: Simulation works, Synthesis fails?

[Allan_Adams]

I'm having a problem with synthesizing a project built around a fast clock for a Cmod A7.  The code attached (main file RAD_counter, based on Mike Field's "fast_freq_counter", thanks Mike!) creates a 450MHz clock from the on-board 12MHz clock using two MMCMs (12->250, 250->450).  It then uses the fast clock to modulate a signal input via pin; this modulated signal is sent into a fast counter to  approximate area under the curve of  the input signal.  A second pipeline counts edges in the  original input signal. Both counts are output over a single 16-bit bus using a 2-state mux.

The code behaves precisely as expected in the Vivado simulator.

Synthesis, however, fails: the synthesizer claims that the output from  the  clock is not used and leaves the pin dangling;  the rest of the modulated-signal chain then simply disappears. 

I'm new to FPGAs & VHDL -- this is my first significant project -- so no doubt I'm making a very simple mistake.  That said, I've spent a  lot of time trying to track it down (including replacing the MMCM code with IP  from the clock wizard, rewriting basically every file in the project from scratch) and no luck.   If anyone has guidance (for this problem, for debugging in general) I'd very much appreciate it.

Thanks,

Allan

 

 

sampler_gray4.vhd RAD_Testbench.vhd RAD_Counter.xdc RAD_counter.vhd rad_clock.vhd prescaler_3.vhd output_mux.vhd gray_to_bin_4.vhd counter_gray4.vhd accumulator.vhd

[Gra]

Hi Allan,

I think the first thing you should do with the project is stop gateing HAM_IN with a clock. (cycles_raw <= HAM_IN and clk_cycles).

 

Kind Regards Graham

 

[Allan_Adams]

Hi Graham, 

Thanks, and agreed that's ugly.  Originally had it as below, treating the signals as signals and clocks as clocks, same results (sim fine, synth not).  Went to simple AND while tearing code apart trying to understand behavior.  

Best,

Allan

  ham_process : process(clk_cycles)
  begin
    if rising_edge(clk_cycles) then
      HAM_OUT <= HAM_IN;
    end if;
    if falling_edge(clk_cycles) then
      HAM_OUT <= '0';
    end if;
  end process ham_process;

[Gra]

Hi Allan

Ugly is fine, but it will mess with the syntheses quite a lot, using a clock buffer with an enable would do the trick.

 

Kind Regards Graham

[Gra]

Hi Allan

Also,  It did pass Synthesis after I added

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets HAM_IN_IBUF];

into the xdc (not a recommended thing to do)

Kind Regards Graham

[Allan_Adams]

Hi Graham,

Thanks! Curiously, when I add that line I get the same result as before: synthesis completes, but the entire fast clock pipeline is missing form the synthesized result.  I wonder why the difference?

Best,

Allan

[Gra]

Hi Allan,

Just had to pop out and walk the dog...

I've updated your file, attached. I've put some schematics on there so you can see the changes I made, don't forget to take that line out of the xdc too.

Does that make it do what you wanted it to do?

I've just noticed your "counter process" too, synthesis may just take that as an instruction to invert CLK_4_RAW, possibly clock it with CLK_IN, is that bit working?

 

Kind Regards Graham

 

 

RAD_counter.vhd

[zygot]

I was going to ignore this post. But then I thought that perhaps I could make a point that reading though Vivado synthesis and implementation errors and warnings is a more fruitful exercise, in terms of learning how to write HDL, than having someone offer "fixes" to get through bitgen. Getting a bitsteam and what you interpret as a successful simulation is not a guarantee that the HDL, or even the concept is good. So, I decided to download the code and try and build the project to see what Vivado synthesis might be complaining about. When the Vivado 2016.2 placer exited with errors I had to re-read the thread again as I thought that you didn't get past synthesis; I got through synthesis using your update code. I then started looking at the code.

In general modern FPGA devices have two classes of signals; clocks and logic. This is important because the timing analysis for synthesis, implementation and bitgen rely on this. If you want design an SPI interface where the SCLK period is a few orders of magnitude greater than the combined delays of the logic resources, and Vivado doesn't classify SCLK as a clock it's OK to use logic derived signals as clocks for connected devices external to the FPGA. When you try to use logic derived signals as clocks in your HDL then this becomes a problem for a lot of reasons. When you use clocks as logic inputs this can be a problem.

As to the CLOCK_DEDICATED_ROUTE FALSE constraint, occasionally, poor pin planning make having to use this constraint in order to use a particular FPGA external device interface work. It should not be a way to overcome design errors.

I'm all for clever ideas and inventive designs but if you are going to break the rules, written or not, then you had better be able to understand the ramifications of what you are doing, and figure out what the tools have inferred from your code, and be able to verify your hardware implementation. It's very easy to mistakenly think that your design is doing what you think that it's doing in hardware when it isn't.

[Allan_Adams]

Hi Zygot,

Thanks, and apologies if I wasn't clear at the beginning -- the code passed synthesis, but the synthesized circuit is clearly not what I was intending.  Not asking for help getting to a bitstream, I'm hoping to understand what's wrong with the design, and any insight / criticism much appreciated.  Have spent several days reading documentation and scanning synthesis warnings & errors trying to figure it out myself.

Cheers,

AA

[Gra]

Hello Allan,

Your post said you were new to FPGAs and VHDL, despite this you had figured out that the tool was dropping parts of your design during syntheses, and you knew which parts it was dropping too. That's impressive for someone new to this, its fundamental, and that's why I assumed you were probably an experienced engineer working in a new area.

I guess you know this...  There is a principle that is used by the educated and experienced, its called "see one, do one, teach one".

That's what I did, I simply showed you how I'd do something on the FPGA, I think you'll take a look at it, and quickly learn what you need to know, to understand why I've done it that way

I think we both know it wasn't a "fix" I uploaded (and I don't think you were trying to get someone to simply fix your project).

I showed you how I'd instantiate a primitive that would allow you to control the clock without pushing it out of the clocking circuits, and that the input should be registered. aka "see one"

Kind Regards Graham

[Allan_Adams]

Hi Graham,

I’m grateful to you for your guidance and suggestion!  That xdc line was very helpful indeed, as understanding why it worked the way it did taught me a lot (as you anticipated). I’ll post an updated code later today; the current version simulates correctly both behaviorally and post-synthesis, and the synthesized circuit now looks like what I intended with the VHDL. The timing analysis still puzzles me, but hardly a surprise, there’s so much more to learn...

Thanks again!

Allan

[Allan_Adams]

Attached is an updated code that does a better job of disentangling clocks from signals.  Synthesized circuit now appears to do what was intended, and both behavioral and synthesized simulations appear to do what they're intended to do.

So far so good, but it's still a kludge, and my understanding remains fragmentary.  Any advice or suggestions for improvement (conceptual, technical, aesthetic) would be greatly appreciated!

Archive_Oct_20_17_30.zip

[zygot]

11 hours ago, Allan_Adams said:

Any advice or suggestions for improvement (conceptual, technical, aesthetic) would be greatly appreciated!

Not infrequently my advice is anything but appreciated; but I don't see that as a reason not to offer it if it seems appropriate. You've chosen a rather challenging project to learn all of the aspects that your request mentions. No problem, everyone has their own slightly different environment in which they thrive.

Vivado Document Navigator offers a lot of vendor documentation. It can't hurt to to see what Xilinx has to say does it? Read about FPGA architecture and how the tools work. Familiarize yourself with the datasheet for your device. Read about constraints. Read about HDL support for synthesis and preferred syntax for inferring common digital structures. Read a few interesting application notes. Most aren't perfect but do contain key concepts. There's too much information for most people to digest in a sitting but just skimming though the pertinent documents will establish a map for where to look when trying to solve particular problems later on. Regardless of the mastery of digital design and HDL concepts that one has understanding how the tools work ( are supposed to work ) for a particular programmable logic vendor is basic. Other vendors have useful documents as well. Altera has had some good concept related documents though Intel seems to have maded finding them very hard.

[Gra]

Hi Allan,

I see you've got the right idea about the clock paths, and you've been re-formatting your hdl syntax too, it now looks much more like that recommend by Xilinx. 

If you are not doing so already, I'd recommend you take a look at the constraints, and note that there is a sequence that they should be in, its like this...

Constraints Sequence

## Timing Assertions Section
# Primary clocks
# Virtual clocks
# Generated clocks
# Clock Groups
# Bus Skew constraints
# Input and output delay constraints

## Timing Exceptions Section
# False Paths
# Max Delay / Min Delay
# Multicycle Paths
# Case Analysis
# Disable Timing

## Physical Constraints Section
# located anywhere in the file, preferably before or after the timing constraints
# or stored in a separate constraint file

I think the Xilinx video on the constraints wizard is worth watching, and the wizard topic help is good.
https://www.xilinx.com/video/hardware/using-vivado-timing-constraint-wizard.html

Just to add, when possible, I like to keep a circuit in mind when I'm writing HDL, then keep an eye on the RTL schematic to check it's building what is expected.
This usually works well, but it can be a little buggy (much better than it was). If the RTL schematic looks strange, check the technology schematic before you try to fix it.
This technology schematic is normally a true representation of what you'll get.  As an example of this I'll upload a couple of pictures from your design (see the slow clock).  

Primitives. I'd also recommend getting familiar with the primitives in the device you are using. One advantage is you can use your hdl to infer rather than instantiate what you want, another is you can improve performance.

Hope thats helpful,  Kind Regards Graham

[zygot]

@GraNice post!

[Allan_Adams]

Graham, thanks for the guidance!  Hadn't realized the constraint sequence was germane.  Ran the wizard yesterday; its suggestions and questions led me not to a new constraint file but (better) to reading more Xilinx documents. ?  Will check out the video too.

It's been pretty magical to see the RTL schematics recapitulate the drawings in my lab notebook upon which the VHDL was originally based.  It's been correspondingly striking to see the synthesized circuits depart from expectations, sometimes in very surprising ways.  Those departures have been VERY educational (and eg led to the original post).  

Much to learn!

AA