Honored Contributor
Honored ContributorHi josyb,
--- Quote Start --- The pictures are a bit small to view, and I'd like to print them out to study your explanation further --- Quote End --- Apologies, I was not aware that the forum will scale them down. --- Quote Start --- The concept of streaming data is exactly that everything comes along with the data. --- Quote End --- That's not true. clock and reset do not come with the data. They are distributed in an independent topology. I would be fine to use the clock- and reset-interface types if only I could extend them to include my own control-signals. --- Quote Start --- In the case of the 'controller concept' you would only need output to input connections between the blocks, given that the 'controller' times it all? --- Quote End --- What would yor suggest for components like "Costas" that do receive two input streams? The realization *can* be very tiny because these inputs streams are in sync. I could of course let the optimizer infer that the control-signals for both inputs are in fact the same. But if I do so, I must at least do a realization that also works with two different control inputs (if I want to keep the component reusable). And I'm not sure that the optimizer will do the same radical simplification that I can do with the knowledge that the control-inputs will always be identical. I do not feel comfortable with that solution. --- Quote Start --- Maybe it would be easiest to design the loop-controller as a hand-coded component (in VHDL, Verilog or MyHDL) and not trying to coerce Qsys to do something it was not really meant for. --- Quote End --- I must admit that I did not look into alternatives deeply. But the QSYS tcl-scripting seemed a very powerful instrument. The controller is an interesting unit. It is in Verilog, but the signals are not formulated as HDL-logic. Instead they are read of an initialized ROM. And the ROM is initialized from a MIF that is generated by the _hw.tcl, dependent on parameters. There are two reasons for this:
