Polishing the component

[PiWy_2406846]

Hello,

   

finally I am at the component's interface polishing stage (see the attached project). I want to setup the symbol parameters correctly and provide the user as much information as I can, so here are my questions:

   

1. The component has the 'clock' terminal, which currently can be manually configured as NCO_CLOCK_FREQUENCY. I want it to work automatically, so how do I infer the frequency of the clock routed to this pin? The Cypress ADC component somehow can do it in external clock mode -- the sample rate is derived from the connection.

   

2. From NCO_CLOCK_FREQUENCY and NCO_DEFAULT_FREQUENCY I can derive NCO_MIN_FREQUENCY and NCO_MAX_FREQUENCY. I would like to display their values to the user (in read-only mode), but if I move their definitions to the 'Formals' section, there is a problem. For some unknown reason Creator enforces parameter definitions in alphabetic order, so the MIN/MAX params are defined after NCO_DEFAULT_FREQUENCY, which derails its validators. How to work this issue around (without renaming the params, of course, as it is not very elegant)?

   

3. NCO_DEFAULT_DDS_INCREMENT is also calculated as an uint16. How do I extract its high/low bytesin Verilog to compute datapath registers' initialization values? Currently I provide two more auxiliary params, but I don't like this solution:

   

.d0_init_a(NCO_DEFAULT_DDS_INCREMENT_LO),
.d1_init_a(NCO_DEFAULT_DDS_INCREMENT_HI),

   

4. In MainsNCO.c I refer to the values of some hardware flags, e.g. the Count7 start flag or define the following FIFO flags:

   

    #define FIFO0_CLR   0b00000001
    #define FIFO1_CLR   0b00000010
    #define FIFO0_LVL   0b00000100
    #define FIFO1_LVL   0b00001000
 

   

I believe they are already defined somewhere, so there is no need to twiddle with their bit encodings, but I am unable to find them. What would be their names and, more importantly, how do you find them? (I think it is the 'where is ResourceMeter' kind of question, but anyway 🙂 ).

[odissey1]

        Piotr, 1. To access external clock frequency you need to add a customizer file to the component. I don't have specific example, and suggest to take look on the Cypress SAR_ADC component, which reads external clock frequency. Creating customizer is tedious process, as IDE won't locate errors in the file. I strongly advise to backup the project before starting with customizer. There is a catch - actual clock frequency might differ from the nominal value, e.g. 24MHz might be actually 23.8765 MHz or 25MHz, it's all depends on master clock and closest divider values. 2. One way to get parameters lined-up in the Dialog list, is to give them some unique names that are alphabetically consecutive, some prefix may help: abc_Frequency abc_Frequency_max abc_Frequency_min 3. parameter [15:0] val16 = 0; localparam [7:0] hi = val16[15:8]; localparam [7:0] lo = val16[7:0]; or ocalparam [7:0] hi = (val16>>8)&0xFF; localparam [7:0] lo = (val16)&0xFF; .d0_init_a(lo), .d1_init_a(hi),   

[PiWy_2406846]

Odissey,

   

1. I'll gladly learn something new, thank you for the food for google! I am fully aware that the actual frequency might differ, I need only the declared one.

   

2. The problem is that

   

   abc_Frequency_max
   abc_Frequency_min

   

should be computed before abc_Frequency, because they are used in its validator:

   

    (abc_Frequency >= abc_Frequency_min) && (abc_Frequency < abc_Frequency_max)

   

The prefix makes them appear together, but their relative order is wrong merely because of a descriptive name. For some reason Creator does not perform topological sorting of parameter dependencies, which is easy to implement. Two sets of prefixes would be required here, but this solution does not scale up. IMO let Cypress do it properly in the next version of the tool.

   

3. Didn't know you can do it on constants too, thanks! 🙂