On 2023-07-11 Stef wrote in comp.arch.fpga:=20I haven't used Lattice tools, so I don't know the answer to your question. =
=20
But the question remains valid: how to define multi-cycle constraints?=20
It is a bit absurd to require passing timing for a 200MHz clock when=20
some of these counters only run at a few kHz.=20
=20
On Thursday, July 13, 2023 at 7:18:37 AM UTC-4, Stef wrote:
On 2023-07-11 Stef wrote in comp.arch.fpga:I haven't used Lattice tools, so I don't know the answer to your question. However, your complaint "...a bit absurd to require passing timing for a 200MHz clock when some of these counters only run at a few kHz" is very wrong. Every bit in a counter will depend on all of the lower/less significant bits. In other words, bits 7-1 will depend on bit 0. Bit 0 will be toggling at a 200 MHz rate so the logic for computing bit 7 will have to operate at that speed as well. 5 ns after the counter is at 11111111 all bits will be flipping to 00000000. To see these logic paths, just take a look at the post-fit logic and you'll see that what I described is correct.
But the question remains valid: how to define multi-cycle constraints?
It is a bit absurd to require passing timing for a 200MHz clock when
some of these counters only run at a few kHz.
So the entire premise of your question is not correct. Even if you do find out how to add multi-cycle constraints in your tool, you'll want to be careful. The tools don't know that the constraint you entered is not correct which means it won't report a valid timing problem because of this error. You could end up scratching your head trying to figure out why things are acting flaky (i.e. an actual timing problem) when the tool says that the timing is correct. As far as I know, there is no 'error checking' to see that user supplied constraints are in fact correct.
Kevin Jennings
On 7/14/23 6:30 AM, KJ wrote:=20=20
The OP said that it was a counter with enable, and the enable only=20
occured every N cycles, so your statement isn't true.=20
=20
The enable -> counter-ff needs to meet the requirement, but that signal=
will tend to feed the last part of the logic, so shouldn't be a problem,==20
the timing limitation being the carry chain from a low bit to a high bit.
On Friday, July 14, 2023 at 7:23:17 AM UTC-4, Richard Damon wrote:
On 7/14/23 6:30 AM, KJ wrote:
The OP said that it was a counter with enable, and the enable only
occured every N cycles, so your statement isn't true.
The enable -> counter-ff needs to meet the requirement, but that signal
will tend to feed the last part of the logic, so shouldn't be a problem,
the timing limitation being the carry chain from a low bit to a high bit.
What I said in the earlier post is accurate, but you are making assumptions about the enable signal logic path that might not be accurate. The enable signal could be just another logic signal that feeds into logic that generates the D input of the flip flops of the counter. Or, IF the part has a D-FF primitive with a dedicated Clock Enable input, AND that clock enable input is actually used by the tool then the enable-->counter FF path would be separate from the D input logic. There might be tool specific, non-portable ways to implement this but you're still going to have to depend on the tool to do what you think is right.
If the enable signal is just another input to the logic that feeds into the D input of the flip flops of the counter then there are no guarantees that the signal will 'tend to feed the last part of the logic' as you mentioned (although it might).
Since the OP said he rewrote the counter logic and timing now works, presumably he simplified the logic that went into determining when the counter should increment. A simple way to accomplish this is to make sure there is an actual discrete enable signal by syncing to the clock before using that signal to enable the counter.
In any case, this doesn't address the OP's question about how to specify multi-cycle constraints in the Lattice tools so this is all a tangent but good discussion.
On Friday, July 14, 2023 at 7:23:17 AM UTC-4, Richard Damon wrote:
On 7/14/23 6:30 AM, KJ wrote:
The OP said that it was a counter with enable, and the enable only
occured every N cycles, so your statement isn't true.
The enable -> counter-ff needs to meet the requirement, but that signal
will tend to feed the last part of the logic, so shouldn't be a problem,
the timing limitation being the carry chain from a low bit to a high bit.
What I said in the earlier post is accurate, but you are making assumptions about the enable signal logic path that might not be accurate. The enable signal could be just another logic signal that feeds into logic that generates the D input of the flip flops of the counter. Or, IF the part has a D-FF primitive with a dedicated Clock Enable input, AND that clock enable input is actually used by the tool then the enable-->counter FF path would be separate from the D input logic. There might be tool specific, non-portable ways to implement this but you're still going to have to depend on the tool to do what you think is right.
If the enable signal is just another input to the logic that feeds into the D input of the flip flops of the counter then there are no guarantees that the signal will 'tend to feed the last part of the logic' as you mentioned (although it might).
Since the OP said he rewrote the counter logic and timing now works, presumably he simplified the logic that went into determining when the counter should increment. A simple way to accomplish this is to make sure there is an actual discrete enable signal by syncing to the clock before using that signal to enable the counter.
In any case, this doesn't address the OP's question about how to specify multi-cycle constraints in the Lattice tools so this is all a tangent but good discussion.
Kevin Jennings
Yes, it is possible to generate code that the enable signal doesn't end==20
up on the fast path, but any compiler that does that without being=20=20
forced into is very bad, as the natural equations would become a mux on=
the enable selecting between the current results and the incremented valu=e.=20
=20=20
The one way that I can think of to put the enable on the slow path is to=
make the equations D <=3D Q + enable, and if that is how you wrote it, yo=u=20
deserve the slowness.
On Friday, July 14, 2023 at 7:56:37 PM UTC-4, Richard Damon wrote:
Yes, it is possible to generate code that the enable signal doesn't end
up on the fast path, but any compiler that does that without being
forced into is very bad, as the natural equations would become a mux on
the enable selecting between the current results and the incremented value. >>
The one way that I can think of to put the enable on the slow path is to
make the equations D <= Q + enable, and if that is how you wrote it, you
deserve the slowness.
Here's another way putting the enable on the slow path can happen...read the OP's last post. What he did to get the tool to use the clock enable is to change logic that was already inside the outer if statement looking at the clock enable. He changed "if filter_count < count_max" to "if filter_count = count_max" and "if filter_count > 0 then" to "if filter_count = 0 then". Using equals instead of less than and greater than typically reduces the amount of logic that goes into the D input but will have no logical impact on whether a clock enable input to a FF could be used. The outermost "elsif rising_edge(clk) and clk_enable = '1' then" is unchanged between his two approaches.
By your measure, it seems Synplify used by Lattice is "very bad".
@Stef
Here are a couple of multicycle path statements from a working Quartus FPGA design. The only notable difference I see from what you posted is the use of get_keepers instead of get_cells as you had. If I recall correctly, Quartus uses Synopsys (or at least the same syntax).
set_multicycle_path -setup -end -from [get_keepers {*Avalon_Reset_n_Sreg[*]}] 2
set_multicycle_path -hold -end -from [get_keepers {*Avalon_Reset_n_Sreg[*]}] 2
On another design, that uses an FPGA from Efinix, their tool Efinity is way more limited. In that design you can only specify multi-cycle paths between clock domains but it doesn't look like you use get_* at all.
set_multicycle_path -from Afe_AdcClk_ext -to Afe_ClockX4 -setup -end 2
Maybe give get_keepers a shot just to see if that is the syntax you need to use to get rid of the error "...was not applied to the design because none of the '-to' objects specified by the constraint exist in the design". Whether or not using multi cycle is useful in this situation (which as you found it was not), it is still useful to be able to use multicycle when it is appropriate (like a single signal crossing clock domains).
Kevin Jennings
@Stef
Here are a couple of multicycle path statements from a working Quartus FPGA design. The only notable difference I see from what you posted is the use of get_keepers instead of get_cells as you had. If I recall correctly, Quartus uses Synopsys (or at least the same syntax).
set_multicycle_path -setup -end -from [get_keepers {*Avalon_Reset_n_Sreg[*]}] 2
set_multicycle_path -hold -end -from [get_keepers {*Avalon_Reset_n_Sreg[*]}] 2
On 7/14/23 6:30 AM, KJ wrote:=20=20
On Thursday, July 13, 2023 at 7:18:37=E2=80=AFAM UTC-4, Stef wrote:=20
On 2023-07-11 Stef wrote in comp.arch.fpga:=20
=20
But the question remains valid: how to define multi-cycle constraints?=
=20It is a bit absurd to require passing timing for a 200MHz clock when=
on. However, your complaint "...a bit absurd to require passing timing for =some of these counters only run at a few kHz.=20I haven't used Lattice tools, so I don't know the answer to your questi=
=20
ind out how to add multi-cycle constraints in your tool, you'll want to be = careful. The tools don't know that the constraint you entered is not correc==20
So the entire premise of your question is not correct. Even if you do f=
=20=20The OP said that it was a counter with enable, and the enable only=20
Kevin Jennings
occured every N cycles, so your statement isn't true.=20
=20
The enable -> counter-ff needs to meet the requirement, but that signal=
will tend to feed the last part of the logic, so shouldn't be a problem,==20
the timing limitation being the carry chain from a low bit to a high bit.
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 6 |
Nodes: | 8 (0 / 8) |
Uptime: | 34:20:36 |
Calls: | 45 |
Files: | 21,492 |
Messages: | 63,312 |