--- Quote Start ---
Hi josyb,
Apologies, I was not aware that the forum will scale them down.
--- Quote End ---
--- Quote Start ---
That's not true. clock and reset do not come with the data. They are distributed in an independent topology.
--- Quote End ---
I maybe should have said: "Everything comes along with the data, except clock and reset which are distributed globally"
--- Quote Start ---
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 End ---
--- Quote Start ---
What would you suggest for components like "Costas" that do receive two input streams? The realization *can* be very tiny because these inputs streams are in sync.
--- Quote End ---
I have a simple Qsys component to combine two streams into one, and I have written several components that accept two (or more) input streams. No sweat.
--- Quote Start ---
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.
I must admit that I did not look into alternatives deeply. But the QSYS tcl-scripting seemed a very powerful instrument.
--- Quote End ---
You mention Verilog, but if you'd step up to SystemVerilog, or VHDL - what I use(d)- you could use a struct (SV) or record (VHDL) to encapsulate your control signals making adding/deleting of a control signal quite easy, because every component picks what it is interested in.
--- Quote Start ---
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:
- I need very strange address-sequences for some RAMs (in the controlled components), that are hard to formulate as logic, but easy to precompute in TCL.
- The generated signals also include some bitserials constants. These are results of trigonometric functions, the input parameters depend on component-parameters. Again, very easy to precompute in TCL.
--- Quote End ---
I am a big Qsys fan too, but lately I have begun coding in myhdl (
http://www.myhdl.org) and there you can have the elaboration (like generating the addresses you mention) alongside the RTL code. Together with a self-checking testbench too.
--- Quote Start ---
Of course, all that is doable with QSYS 15, I do not really need that "enhancement". But when I look at my design, I feel that I could have done better, if QSYS had these features.
And I have seen other posts with people asking about 1:N conduits, so I will not be the only one to benefit from that.
I'm sure that Altera themselves will continue to develop and improve QSYS, just wanted to put a "vote" for customizable 1:N connect.
--- Quote End ---
I think that Qsys is quite complete. The addition of 'distributed control' like you propose would add considerable complexity both to the view as to the implementation.
Regards,
Josy
Honored Contributor
