Getting a net's clock frequency symbolically in verilog?

[lurk101]

I have developed a library component with the usual clock input. The component's logic needs to know at what frequency its clock is running at, which of course is unknown at component creation time. Is there a way, in Verilog, to extract a port or a net's frequency at design synthesis time once the block has been connected to an actual clock? To express the frequency as a wire?

[zygot]

43 minutes ago, lurk101 said:

The requirement could be based on something as basic as needing to report the operating frequency of a given component to software via a mapped register interface.

That's not the same thing. If you want an example of an HDL design that uses a programmable clock module to change the operating frequency on the fly and a way to measure the clock frequency in HDL and software as it's running see the source code for this project:  https://forum.digilentinc.com/topic/2898-differential-pmod-challenge/

I think that I'll wait for the original poster of this question to explain what it is that he means.

I'm really arguing that the idea that you need to create a solution to a problem without some a priori knowledge of the clock frequency is wrong, and unnecessary. But so far no one has provided me with an example of such a project worth discussing.

 

[lurk101]

@zygotCorrect. The answer seems to be NO, and I got it fairly early on in this thread. The powers that be will just need to change their requirement.

As it was explained to me it stems from the architect's desire to minimize the number of hard-coded dependencies between all components of a finished product, including hardware and software.

Thanks all

[zygot]

3 hours ago, lurk101 said:

Hypothetical: I have a component which implements a generic sha3-256 hash function in a 24 stage pipeline generating one hash per clock. The component is implemented as an AXI slave controlled and queried via a register mapped interface. This generic component could be used at any frequency depending on the underlying implementation, but it needs to report back to software its operating frequency so that the software can estimate the expected hash rate. This required to decouple software from the hardware implementation.

It seems to me that by the time you are writing software you have already committed to clock frequencies for your AXI bus and know the frequency of the clock that is driving the AXI bus and IP logic. Voila, you have enough information needed to estimate the hash rate. I don't see how, by the time you have a configuration file you don't have all of the information that you need. As for de-coupling the software from the IP execution rate I don't know the exact requirements but suspect that you will need to add some additional complexity to your IP if knowledge of hash execution time is a security issue. This wouldn't be excessively difficult for a bad actor to work out. You still haven't convinced me that not knowing the IP clock rate yields anything. It certainly has costs, even if you figure out how to do that by, perhaps using a programmable clock module. 

I think that you got your answer which is no. It's probably not the answer that you want so you will have to work out a different approach that uses the tools properly. By the way, the project that I provided a link to might be interesting as it does "pick" a median clock frequency for the one run time variable clock as a timing constraint and demonstrates a way to test how much margin is in the final implementation for changing the frequency at run time. Also, you can have a design with a variable frequency, within limits, and a known clock for estimating the rate of the variable clock rate. I'm fairly sure that there is a better and more robust way to do what you want to do.

A lot of people submit questions looking for answers and think that they have no interest in participating in a discussion. When the question is out of the norm a bit of discussion might just shine a light on the shadows where the gremlins are lurking. I'm not suggesting that you be gracious, just willing to to be open minded and willing to consider the responses at it applies to your goal.

[asmi]

<duplicate>

[asmi]

29 minutes ago, lurk101 said:

Further: Here's an example of a component that adjusts itself at synthesis time. The ZYNQ7 Processing System component adjusts its number of external interrupt inputs at synthesis (or is it validation?) time according to the number of incoming signals (the width of the incoming concat component output bus). When first added and connected the block design shows a mismatch between the input signal and port widths, but this is somehow corrected at synthesis and the block diagram updated with the correct widths.

This is done by Vivado's IPI during diagram validation (which is what I alluded to in my first response) - basically it can adjust values of certain block parameters based on some external criteria. This functionality does not require any support from synthesis as by the time it starts, all parameter values have been adjusted to what they should be.

You can read more about it in UG994, chapter 6 "Propagating Parameters in IP Integrator". Obviously this is the IPI-specific feature not available outside of it.

[lurk101]

Further: Here's an example of a component that adjusts itself at synthesis time. The ZYNQ7 Processing System component adjusts its number of external interrupt inputs at synthesis (or is it validation?) time according to the number of incoming signals (the width of the incoming concat component output bus). When first added and connected the block design shows a mismatch between the input signal and port widths, but this is somehow corrected at synthesis and the block diagram updated with the correct widths.

This led me to believe there were perhaps some Verilog accessible net or port attributes that might be used in logic.

[lurk101]

2 hours ago, zygot said:

You didn't bother to read the project material that I've referenced, but OK I don't care if you don't.

Since you are the OPI, if you can't describe this mysterious generic application with no known frequencies then there's not much point in having a discussion about an unknown application with unknown requirements.  Measuring an unknown clock period using a known clock period isn't difficult or particularly innovative.

I've been doing logic design for a long time and have never needed to address a problem the way you seem to want to. The way that synthesis and place and route works is based on constraints based on known frequencies and delays so the idea of designing a frequency and tool agnostic IP component makes no sense to me. If you look at the Mig tool it handles a wide range of operating frequencies and components but works best with lots of pertinent timing information like PCB trace delays. You can't design an external memory controller without specifying the clock frequencies involved and expect it to work for any external memory design scenario on any board using any components. There are good reasons why what you are describing isn't normal or best practice.

Give me something worth discussing or figure it out for yourself. Let us know how you make out with that, if you care to share the details once you've figured out the new IP paradigm. But in the mean time the regular approach to FPGA development works just fine if done correctly.

Lots to unpack there.

Yes, I did look at the links you provided, and it is indeed it is trivial to measure one clock frequency using another known clock. But that's the problem, at component design time there are no "known" clocks.

Ok, Your CV has been noted.

I wasn't really looking for a discussion, but rather an answer... but since you asked:

Hypothetical: I have a component which implements a generic sha3-256 hash function in a 24 stage pipeline generating one hash per clock. The component is implemented as an AXI slave controlled and queried via a register mapped interface. This generic component could be used at any frequency depending on the underlying implementation, but it needs to report back to software its operating frequency so that the software can estimate the expected hash rate. This required to decouple software from the hardware implementation.

[zygot]

16 minutes ago, lurk101 said:

The component is generic, intended for use  in various designs and at various frequencies. I don't care how and who generates the fixed frequency input cock, I just need to know its frequency.

You didn't bother to read the project material that I've referenced, but OK I don't care if you don't.

Since you are the OPI, if you can't describe this mysterious generic application with no known frequencies then there's not much point in having a discussion about an unknown application with unknown requirements.  Measuring an unknown clock period using a known clock period isn't difficult or particularly innovative.

I've been doing logic design for a long time and have never needed to address a problem the way you seem to want to. The way that synthesis and place and route works is based on constraints based on known frequencies and delays so the idea of designing a frequency and tool agnostic IP component makes no sense to me. If you look at the Mig tool it handles a wide range of operating frequencies and components but works best with lots of pertinent timing information like PCB trace delays. You can't design an external memory controller without specifying the clock frequencies involved and expect it to work for any external memory design scenario on any board using any components. There are good reasons why what you are describing isn't normal or best practice.

Give me something worth discussing or figure it out for yourself. Let us know how you make out with that, if you care to share the details once you've figured out the new IP paradigm. But in the mean time the regular approach to FPGA development works just fine if done correctly.

[lurk101]

21 minutes ago, zygot said:

That's not the same thing. If you want an example of an HDL design that uses a programmable clock module to change the operating frequency on the fly and a way to measure the clock frequency in HDL and software as it's running see the source code for this project:  https://forum.digilentinc.com/topic/2898-differential-pmod-challenge/

I think that I'll wait for the original poster of this question to explain what it is that he means.

 

I am the OP! I think you're missing the point. The component is generic, intended for use  in various designs and at various frequencies. I don't care how and who generates the fixed frequency input cock, I just need to know its frequency. Sure, measure it on the fly, but then I'd need a known reference clock to measure it against.

[lurk101]

30 minutes ago, zygot said:

Oh... so perhaps the question is whether or not one should try to design a 'universal' component or module IP that covers any possible use case.  I would think that the answer to that question is no. But you and I are engaging in speculation; unless you know more than I do about what @W.Dis trying to accomplish.

It is a simple requirement. Questioning it doesn't answer the question.

The requirement could be based on something as basic as needing to report the operating frequency of a given component to software via a mapped register interface.

[lurk101]

46 minutes ago, asmi said:

That's the essence of the question - how do you find out what that "known" frequency is if you're designing a component which is meant to connect to external clock which you have no control over?

Indeed, that is exactly the question, better expressed.

Yes, I presently use a module parameter to manually specify the component's input clock frequency. There doesn't seem to be a way to automate this!

[zygot]

12 minutes ago, asmi said:

That's the essence of the question - how do you find out what that "known" frequency is if you're designing a component which is meant to connect to external clock which you have no control over?

Oh... so perhaps the question is whether or not one should try to design a 'universal' component or module IP that covers any possible use case.  I would think that the answer to that question is no. But you and I are engaging in speculation; unless you know more than I do about what @W.Dis trying to accomplish.

[asmi]

11 minutes ago, zygot said:

Perhaps someone slipped me some decaf this morning because to my way of thinking counting the clock cycles of a known frequency is knowing elapsed time. 

That's the essence of the question - how do you find out what that "known" frequency is if you're designing a component which is meant to connect to external clock which you have no control over?

[zygot]

54 minutes ago, asmi said:

Think of DDR3 refresh for example - you are supposed to do it every X us, so you will need to calculate at synthesis time how many clock cycles that is - because as you know, the logic itself has no concept of time and can only count clock cycles.

Perhaps someone slipped me some decaf this morning because to my way of thinking counting the clock cycles of a known frequency is knowing elapsed time. I've done more than a few SDRAM controller and DDR designs and that's how refresh intervals are determined. This doesn't involve a any mystery. Perhaps, DDR isn't the best example. I really can't think of a design case that couldn't be handled by normal static generic or parameter HDL statements.

 

[asmi]

33 minutes ago, zygot said:

If I'm reading this right you want to dynamically change the clock frequency post configuration while the design is running.

He's not talking about that, but rather he wants to know the frequency connected clock is running at synthesis time. This is often needed to calculate a timebase if you have some logic which is supposed to work with real time as opposed to number of cycles. Think of DDR3 refresh for example - you are supposed to do it every X us, so you will need to calculate at synthesis time how many clock cycles that is - because as you know, the logic itself has no concept of time and can only count clock cycles.

 

Unfortunately, there is no such way in generic Verilog/SystemVerilog to know the frequency, so usually you would provide a parameter (generic in VHDL terms) which would indicate the frequency, and do all your calculations based on that. From what I read, there are some tricks in Vivado IPI to get it passed along during validation phase, but I never used them myself and use the parameter method while assuming the user of component is knows what he is doing.

[zygot]

6 hours ago, lurk101 said:

The component's logic needs to know at what frequency its clock is running at, which of course is unknown at component creation time

If I'm reading this right you want to dynamically change the clock frequency post configuration while the design is running. Dynamic clock switching is of course supported by modern FPGA devices, but there are limits as to what you can do with dynamic clock adjustment or switching. Since the clock rate is a central part of the timing analysis that determines synthesis and place and route a fixed, or at least median, clock rate is needed to get the optimum results from those tools. Except for partial reconfiguration there's no way to alter resource implementation. I suppose that the key to whether or not your idea is practical depends on what you want to do exactly.

Can you explain how your design concept is supposed to work?