Multiple Clocks on single bus

[TheHogs88]

Tried looking for this on here and couldn't find anything. What are the current thoughts on putting all of the clocks in a bus on the top level? This is not a good idea to do right? Can someone explain to me why though?

 

[rickman]

On 6/27/2013 3:41 PM, TheHogs88 wrote:

Tried looking for this on here and couldn't find anything. What are the current thoughts on putting all of the clocks in a bus on the top level? This is not a good idea to do right? Can someone explain to me why though?

I assume by "bus" you mean a vector of signals such as std_logic_vector?

I don't know that it is a *bad* idea, but I don't see any value in it.
If you run a clock (or any other signal) into a module and don't use it,
you will get a warning that you will need to know to ignore. I try to
avoid warnings that are ignored because they mask other warnings that
you should not ignore.

Other than the warnings you might get, I don't see any real advantage or
disadvantage to running a clock bus, but the bus itself has no meaning
to the tools or in the FPGA. They are purely for our convenience in
reading the code. It is still just a bunch of signals whether in a
vector or not.

--

Rick

 

[rickman]

On 6/27/2013 4:03 PM, TheHogs88 wrote:

On Thursday, June 27, 2013 3:59:25 PM UTC-4, rickman wrote:
On 6/27/2013 3:41 PM, TheHogs88 wrote:

Tried looking for this on here and couldn't find anything. What are the current thoughts on putting all of the clocks in a bus on the top level? This is not a good idea to do right? Can someone explain to me why though?



I assume by "bus" you mean a vector of signals such as std_logic_vector?



I don't know that it is a *bad* idea, but I don't see any value in it.

If you run a clock (or any other signal) into a module and don't use it,

you will get a warning that you will need to know to ignore. I try to

avoid warnings that are ignored because they mask other warnings that

you should not ignore.



Other than the warnings you might get, I don't see any real advantage or

disadvantage to running a clock bus, but the bus itself has no meaning

to the tools or in the FPGA. They are purely for our convenience in

reading the code. It is still just a bunch of signals whether in a

vector or not.



--



Rick

I meant more in a record rather than a std_logic_vector. For example a record with a 125Hz signal, 260Hz signal, and 30Hz signal all used throughout the design.

Ok, everything I said above still applies I'm pretty sure. Why do you
want to use a record? Do all the clocks get used in all modules the
record goes to? Any input to a module that doesn't get used gets a
warning. Do you read all the warnings every time you compile? I do.

--

Rick

 

[TheHogs88]

On Thursday, June 27, 2013 3:59:25 PM UTC-4, rickman wrote:

On 6/27/2013 3:41 PM, TheHogs88 wrote:

Tried looking for this on here and couldn't find anything. What are the current thoughts on putting all of the clocks in a bus on the top level? This is not a good idea to do right? Can someone explain to me why though?



I assume by "bus" you mean a vector of signals such as std_logic_vector?



I don't know that it is a *bad* idea, but I don't see any value in it.

If you run a clock (or any other signal) into a module and don't use it,

you will get a warning that you will need to know to ignore. I try to

avoid warnings that are ignored because they mask other warnings that

you should not ignore.



Other than the warnings you might get, I don't see any real advantage or

disadvantage to running a clock bus, but the bus itself has no meaning

to the tools or in the FPGA. They are purely for our convenience in

reading the code. It is still just a bunch of signals whether in a

vector or not.



--



Rick

I meant more in a record rather than a std_logic_vector. For example a record with a 125Hz signal, 260Hz signal, and 30Hz signal all used throughout the design.

 

[KJ]

I meant more in a record rather than a std_logic_vector. For example a record
with a 125Hz signal, 260Hz signal, and 30Hz signal all used throughout the
design.

The bigger question in my mind is why all throughout the design you're using multiple clocks in the first place. On the surface, it sounds like a design destined for a long debug cycle.

But if the multiple clocks really are needed then a record to hold all three still would seem to have the following drawbacks:
- All modules would now be dependent on an external package to define the record simply as a mechanism to bring in three signals. Having such a global package is useful for things that are really design independent (ieee.std_logic_1164 as an example); I doublt that a record for defining three signals would merit that importance. While you might reuse this idea on some other design, it is probably much less likely that you would reuse the actual package that contains this record ever again.
- For those modules that actually only use one of those clocks it is a bit clumsy to bring in a three element record just to use one element. It would likely be cleaner to have the entity bring it in as std_ulogic and then port map that signal to the intended record element.

On the plus side, there could be a little bit less typing and visual clutter, but only when looking at the entity and the top level where the entities are tied together. But the clutter level remains the same when you're looking at the architecture which is where one spends most of the time looking since that is where the logic is described.

Kevin Jennings

 

[Andy]

Are these clocks related (synchronous) to each other? If so, I could see some merit to bundling them together in a single signal/port if they often get used in the same places.

If they are not related, then extreme care must be used when transferring data between them. You want those transfers to be rare and easily identified, neither of which is well served by bundling them together on one signal/port.

In defense of custom aggregate data types, I often define a package of interface types for a project that defines composites (arrays & records), enumerated types, subranges of integer, constants, etc. for use in the design.

For example, I find it extremely useful to define a record with an element for the data (maybe an array/record itself), and another element for a "valid" or "mode" indicator for that data. By bundling data and indicator in the same object, you always have all the information needed to interact with that data, whether you are producing it or consuming it.

Andy

 

[TheHogs88]

Well in the actual design there are about 10-15 clock pins coming into the top level. These pins then get fed into a clock manager entity which branches them out into separate DCMs/PLLs. From the clock manager onward, some clocks are grouped together based on interface (QDR clks, RIO clks).

The input to the top level is just a pads record with records underneath it for each interface (clks, DDR, QDR, RIO, etc.).