First, it is generally a bad idea to generate a clock with anything other than dedicated clocking resources (the MMCM/PLL and associated clock buffers) - this is not an SDC/XDC thing, but an FPGA architecture thing - take a look at this post on why fabric generated clocks are generally not the best idea.
But from an XDC/SDC point of view it is legal to define a generated clock where the clock is generated by logic (given the caveats mentioned in the post).
In most cases there is an actual cell that is doing the transformation of the clock. This cell can be
- an MMCM/PLL
- The tools take care of automatically generating clocks on MMCM/PLL outputs - you don't need a manually generated clock
- a gated clock buffer like a BUFGCE, BUFHCE
- When the CE is asserted with a known pattern, the output of the BUFGCE/BUFHCE can be represented as a generated clock
- This is a supported and recommended mechanism of generating a derived clock
- some flip-flop
- Again, this isn't recommended, but is legal
When you do a create_generated_clock, it is preferred to specify the Master pin (i.e. the -source option) as close to the generating cell as possible
- For a BUFGCE/BUFHCE this would be the "I" pin of the BUFGCE/BUFHCE
- For a fabric generated clock this would be the "C" pin of the flip-flop generating the clock
However, it is acceptable to put any point upstream from that that carries the source clock. In this case, you could use
- The clk_in1 pin of the MY_RTL_MODULE
- get_pins MY_RTL_MODULE/clk_in1
- The clk_out_100MHZ pin of the clk_wiz_0
- get_pins clk_wiz_0/clk_out_100MHZ
- The net between then
- get_nets <name_name_of_net
- Any other net/pin along this path
- The actual flip-flop is presumably somewhere in MY_RTL_MODULE
- This could also be done as a scoped XDC constraint file for the MY_RTL_MODULE (rather than specifying it at the top level XDC)
The object to which it is attached would normally be
- The O pin of a BUFGCE/BUFHCE
- The Q pin of the flip-flop generating the clock
But can also be something directly downstream of this
- The MY_CLOCK_OUT pin of the MY_RTL_MODULE
- If MY_CLK_48MHZ is an output port of the FPGA, then that can be used
As for the Derive from Source Clock Waveform (the relationship between the source clock and the generated clock), this depends on how the clock is generated. The obvious question is "how are you going to generate 48MHz from 100MHz? There is no simply relationship between these two, how are you going to create this clock.
The only way digital logic can create a clock like this is with some kind of dithering - the ratio is 2.08333x, so you could do something that has one output edge every 2nd or 3rd input edge in the exact right ratio between them to generate the clock you want. But if you do this, it isn't a "true" clock - you cannot describe this as a 48MHz clock. Since there are some periods where the subsequent edges of the clock are 2 100MHz clocks apart, this will have the behavior of a 50MHz (not 48MHz clock) - any downstream logic that uses this will have to be budgeted to allow for the 20ns period between subsequent edges - this would be Divide source clock frequency by 2 (-divide_by 2). If (somehow) you did manage to generate a true 48MHz clock (again, not possible with digital logic), then you could specify Multiply=12 Divide=25 (-multiply_by 12 -divide_by 25) - the tools would accept this.
But, again, this is not recommended. If you are going to do some kind of dithering of the clock, rather than have the clock generated by the output of a flip-flop, you could use a BUFHCE/BUFGCE and control the enable with the appropriate profile - enabled every 2nd or 3rd source clock in the appropriate pattern. Take a look at this post on using a BUFGCE/BUFHCE to generate a clock.
Avrum
