Multiple Clocks on single bus

Discussion in 'VHDL' started by TheHogs88, Jun 27, 2013.

  1. TheHogs88

    TheHogs88 Guest

    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?
    TheHogs88, Jun 27, 2013
    1. Advertisements

  2. TheHogs88

    rickman Guest

    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.
    rickman, Jun 27, 2013
    1. Advertisements

  3. TheHogs88

    TheHogs88 Guest

    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.
    TheHogs88, Jun 27, 2013
  4. TheHogs88

    rickman Guest

    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.
    rickman, Jun 27, 2013
  5. TheHogs88

    KJ Guest

    I meant more in a record rather than a std_logic_vector. For example a record
    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 actualpackage 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 entitiesare 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 lookingsince that is where the logic is described.

    Kevin Jennings
    KJ, Jun 28, 2013
  6. TheHogs88

    Andy Guest

    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, Jun 28, 2013
  7. TheHogs88

    TheHogs88 Guest

    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 itfor each interface (clks, DDR, QDR, RIO, etc.).
    TheHogs88, Jun 28, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.