Your code in the loop
Some of a model is never going to be a block. Write it in C or Python and wire it in.
Two blocks, your source
The library has a C block and a Python block. You write the body; you declare the ports it needs; it runs inside the simulation loop like anything else on the canvas, reading its inputs and writing its outputs once per sample.
They are the escape hatch for the parts of a model that resist being drawn: a lookup against a protocol you already have in C, a bit of numerical work you have already written and trust, an algorithm still in flux that you do not want to freeze into a block yet.
What they cost you at export time
Everything else in the library exports to all ten targets. These two do not, and cannot: a C body is C, and a Python body is Python. The C block exports to C; the Python block exports to Python. Every other target has nothing to translate your source into.
That is worth knowing before a model gets large. If a subsystem has to reach an FPGA, keep your hand-written code out of that subtree — or promote it to a real block once it settles, which is what the Block Wizard is for.
They travel with the project
The source you type is part of the model, carried in the project file and in the diagram's recipe form, so a model with user code in it is still one thing to save, share and script.
See also: Block Wizard — build your own library · Code export
See it run on your own model.
Download the application from the customer portal, or read the documentation first — the manual, every block with its measured response, and the full command reference are public.