fpga4fun.com

Howdy Jef,

The code is a little hard to follow, and I'm not sure what the exact problem you're having is, but those warnings aren't necessarily bad. Unless you write very tight code, it is not uncommon for the tools to find non-obvious ways to optimize the design. Having said that, a moderately common code problem is that an output of a block of logic isn't used even when you think it is, thereby allowing the tool to optimize out something that you don't think it should...

I see that you have some test bench stuff... does that mean the design simulates exactly as you would expect it to run in the real world? If not, that is your first step.

If it simulates correctly, but still doesn't work in the real world, it is possible it is a reset, clocking, or timing problem. Or maybe a meta-stability problem with the reset or start inputs.

I noticed that you have clocks being generated from other clocks, but I don't see that the generated clocks are put onto global clock nets. That could be a large source of your problem. As a general rule, the clock input for ALL the flip-flops in your design should be coming from global clock nets.

Good luck,

Marc

Howdy Jef,

i understand that it is difficult to help me out on this one. Without criticizing you, your first two paragraphs are of no use to me, but ...

To summarized them:

1. You wondered if the "Register X is equivalent to Y" warnings were a problem. My response is that the optimizers do this kind of thing all the time, so it is very possible that it is NOT a problem...UNLESS you have a problem in your design.

2. If your design doesn't work in simulation EXACTLY as you would expect it to, don't bother loading it into the FPGA.

The last paragraph is more than interesting to me, I have heard from those clock banks from time to time, but never thought of using them, everything always seemed to work out fine without them. Maybe time to start using them.
Can you give me a short push in the back and tell me how I can use them?

Sure, although here in a second, I'll propose a better route to take. To get a global clock buffer in Xilinx, just add:

Code: Select all

  gclk_1  : BUFG port map (I => unbuffered_clk_in, O => global_clk_out);


after your BEGIN statement. You may need to add a Xilinx library and/or a component declaration (*) to the top of your .vhd file as well, if you don't have it already. I see in your synth results that clk is already on a global clock buffer - the tools will do that for you sometimes.

The gotcha to generating a clock with flops and then putting it onto the global clock network is that it incurs extra delay, so the maximum frequency of your design is likely to go down considerably (2 or 4 ns easily, and possibly quite a bit more). If the design can't live with that kind of slow-down, you might be able to use a DCM to remove most of the delay, but now it's a kludge on top of another kludge.

A better solution than adding a bunch of BUFG's and DCM's is to use only one clock for the whole design. Instead of feeding all your xclk's and sync's into the clock inputs of the flip-flops, feed them into the clock enable of the flop. Then make sure all your clock inputs come from the single clk signal. This is a little more radical change to your design since you'll have to modify the xclk's and sync(s) to be a single "clk" cycle wide (rather than 50% duty cycle), but it will result in fewer problems in the long run - and it'll be easier to reach higher clock frequencies).

Good luck,

Marc

(*) BUFG component declaration goes before the BEGIN statement, and is simply

Code: Select all

COMPONENT BUFG IS
    PORT (
      I : IN  std_logic;
      O : OUT std_logic);
  END COMPONENT BUFG;


Howdy Jef,

The fact that the clk is implemented correctly is probably because of my ucf file, which I will upload on my site together with the new vhdl code. In the end of the ucf file i write:
NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 9 ns HIGH 50 %;
now, don't ask me why I do it, I've learned it that way, and it always seemed to work out.

That looks correct.

I assume I should do something like that with the xclk signal as well, i did some experiments but nothing seemed to work.

So now I return to this thread. xclk is in fact a 25 MHz clock which I need for the vga monitor. (FPGA runs at 100 MHz) I now know I'm not doing it as it should be done, what is the easiest and most comprehensive way for me to do this correct?

To be honest, I did not attempt to follow the code all the way through to see what the xclk's (and hsync!) are doing or the speed(s) at which they are running - I just noticed that you are using general purpose routing for clock inputs to flops.

For only 25 MHz (40 ns), there should be plenty of spare time to get onto a global clock net. So rather than worrying about DCM's or rewriting your code to use clock enables, just put the xclk's and hsync on global clock nets as I described originally.

The reason for using global clock nets is to reduce the skew. You'll see from your Clock Report that clk has a skew of only 562 ps, while the others have skews ranging from 1.17 to 3.2ns. 3.2ns is a ton of skew and can lead to erratic results due to the clock reaching some flops many nanoseconds before it reaches other flops.

I saw your post on c.a.f... yes, a third (very good) solution would be to take the input clock into a DCM, then use the CLK0 and CLKDV (configured as /4) outputs. This will give you a nice clocks for both clk and xclk - so you don't have to generate the clocks manually, and they will all be phase aligned to each other, so moving between domains will not be a problem. I did not suggest this originally because you have a third derived clock (hsync) which you can not generate from the DCM. You will still need to put hsync on a global buffer, but since we now know the speeds involved, we know that it is unlikely the prop delay is going to get in your way.

Have fun,

Marc

P.S. I envy your ~10 minute start to finish compile times! I'm lucky when my 2VP40 design takes less than 3 hours.

Howdy Jef,

Jef Patat wrote:

mrand wrote:I did not suggest this originally because you have a third derived clock (hsync) which you can not generate from the DCM. You will still need to put hsync on a global buffer, but since we now know the speeds involved, we know that it is unlikely the prop delay is going to get in your way.

Well, the hsync and vsync signals are not really internal synchronize signals, they are directly fed to the output pins and then straight to the monitor.

Perhaps we are talking about two different things, but http://docent.hogent.be/~bmee221/vgacontroller.vhd appears to show hsync being used as an internal clock. Not only that, but the vcnt is generated by the hsync domain (in process "C") and then goes to the xclk domain (process rgb_refresh) - so you are transfering data from one clock domain to another.

Well, I understand, but I still think it sucks, I tried to implement incremental design, another thing I should learn, but that was a big fiasco, didn't work out at all.

Incremental design can be challenging (although less so than dynamic reconfiguration). I'd recommend waiting till you get a few other experiences under your belt before tackling those two. Trying to change too much at once with this kind of stuff will drive you insane!

Marc