Odd timing violation

[dgottesm]

I am working on the failed timing report of my design, and so far I am doing good, setting most of the violations as false paths (I know, user beware).
I have reached the last two errors and I don't really know what to do. I have a BRAM in my design, and I have a single register controlling the write_en, and Vivado tells me I have a timing violation and I don't know how to fix it or what the problem is (Ignore the first error in the pictures... I have an idea of how to fix... might be a multicycle)
I suppose that clue #1 is that Vivado lists the violation as an inter-clock path, so I guess that means that the clock of source register of the design, which I know what it is, is not the same as the clock of the BRAM itself, which I don't know. I also see that most of the slack is because of net delay. What can I do to fix this?  

Thanks

 

 

[xc6lx45]

Hi,

>> so I guess that means that the clock of source register of the design, which I know what it is, is not the same as the clock of the BRAM itself, which I don't know.
I think you have an unintended clock domain crossing, since "source clock" and "destination clock" are different.

[dgottesm]

13 minutes ago, xc6lx45 said:

Hi,

>> so I guess that means that the clock of source register of the design, which I know what it is, is not the same as the clock of the BRAM itself, which I don't know.
I think you have an unintended clock domain crossing, since "source clock" and "destination clock" are different.

@xc6lx45

So what should I do?

[xc6lx45]

@dgottesm

false-paths within your design are unusual. I'd comment those out first, otherwise you're hiding warnings that may be useful in showing the bigger picture.

Is it possible that your design has two clocks 54 MHz and 200 MHz (from reading the clk_wiz block names). If so, there may be a serious architectural issue, unless there is some hidden "infrastructure" in bram_controller. But then, I don't know your design at all.

What you should do is first understand and maybe explain where those two clock "wizard" blocks are coming from, and why they show up on the two ends of your path. With clocking, you can't leave anything to chance. It's an annoying part on the learning curve, I know, but you might spend some time with the warnings, can you explain them all? ?

[dgottesm]

29 minutes ago, xc6lx45 said:

@dgottesm

false-paths within your design are unusual. I'd comment those out first, otherwise you're hiding warnings that may be useful in showing the bigger picture.

Is it possible that your design has two clocks 54 MHz and 200 MHz (from reading the clk_wiz block names). If so, there may be a serious architectural issue, unless there is some hidden "infrastructure" in bram_controller. But then, I don't know your design at all.

What you should do is first understand and maybe explain where those two clock "wizard" blocks are coming from, and why they show up on the two ends of your path. With clocking, you can't leave anything to chance. It's an annoying part on the learning curve, I know, but you might spend some time with the warnings, can you explain them all? ?

@xc6lx45

Indeed, there are two clocks in the design. I have simulated the entire design, with a full testbench with full success, so I hope that it doesn't have serious issues. I thought out the design long and hard, so in theory it should work, but I have never synthesized a complicated design before. 

Basically, I have a dual port RAM, and data is being read at a different clock then the write. In the BRAM controller, there are two systems of clocks, one for the read (lets say 250 MHz), one for the write (lets say 25 MHz), but there is some overlap in the systems.

The data is being written at 25 MHz, and there is an target address register (which is synchronous to the 250 MHz clock) sitting at 0. When the distance between the target address register and the write address register is a certain amount, the read address (also synchronous to the 250 MHz clock) reads 5 values, and the target address advances one, closing the distance by one, until the next byte is written, and it continues, until a certain amount of data has been processed, and the whole thing starts again So there is some dependency.

At first, all the paths with violations were because of the reset values after 'a certain amount of data had been written'. I decided that those values would definitively get reset because of the design, so I wasn't so worried, but I did learn that such dependencies made a difference. Now I am dealing with a dual port ram, with two clocks, and I have this violation.

If you want to see the BRAM controller module, I can send it to you privately, and you can tell me if you think it is a serious problem (I am a student, and my adviser isn't much help)

Thanks

[dgottesm]

@xc6lx45

Actually, I see the problem. I made a serious error in the routing on my part. But I still want to hear any insight you have about my design and dealing with multiple clocks...

[xc6lx45]

Typically you have one clock on port A of the BRAM, and another clock on port B. This doesn't flag any timing violations (it's not foolproof if you read and write the same address).

You can build a clock domain crossing with e.g. a state machine if you make sure that data is valid for more clock cycles than some enable line. I suspect this is what you meant.
In this case, metastability is still be an issue: Different parts of the destination clock domain see different values (unlikely but possible after register rebalancing). This can cause logic to enter inconsistent states, "de-rail", therefore use a synchronizer in-between:

(* ASYNC_REG="TRUE" *) reg a = 1'b0
(* ASYNC_REG="TRUE" *) reg a = 1'b0
always @(posedge destination_clk) begin
a <= (input);
b <= a;
(output) <= b;
end

This will a) modify the physical placements of registers to give the second one the sharpest possible edge to minimize metastability, and b) get rid of the warning (instead of false_path, which only suppresses the warning).

But as said, running ports A and B of BRAM at different clocks is OK and does NOT require a synchronizer.

[xc6lx45]

BTW, 250 MHz is a frequency where things start to fall apart if you're not careful (functionally, not meaning hardware damage)

[D@n]

Sounds like you are trying to build an asynchronous FIFO.  There are some tricks you need to take care of to make it work right.  See this article for a discussion and some references.

'Dan

[dgottesm]

4 hours ago, D@n said:

Sounds like you are trying to build an asynchronous FIFO.  There are some tricks you need to take care of to make it work right.  See this article for a discussion and some references.

'Dan

Hi @D@n!

actually, it’s technically not a FIFO, because the it doesn’t send the first out, but 5 other bytes in memory, not in order they were received... I have an algorithm telling me which addresses to read...

[xc6lx45]

Hi @dgottesm,

since you asked for "insights": I don't know your full design but I suspect that you're making a clock domain crossing more complex than necessary. If so: Don't do that. Use a standard design pattern. Think of your poor (hypothetical) colleagues who need to make sense of your work while you're on holiday. Academics love the exotic, industry the pragmatic ?

A FIFO is one choice if throughput matters (and it looks like one superficially - or why would I sacrifice a BRAM otherwise) or if it reduces complexity. I would use plain registers as long as I can get away with it.

And sorry, but I have to ask: Do you really need it? It happens too many times that decisions are driven by solutions looking for a problem... There is no intrinsic value in a clock domain crossing. If you can avoid it, avoid it.