Altera_Forum
Honored Contributor
Honored ContributorQSYS feature-request: timing interface type
Hi all,
given the version 15's interface-types, it is unnecessarily difficult to distribute control signals in a (nested) QSYS component and thus implement serial data processing. Streaming data-paths resemble directed graphs, while the distribution of control-signals should have tree-topology. Imagine a component with two streaming-sinks that requires the two streams to be in sync (same valid-signal f.e.). I would like to propose a new interface-type, that will ease streaming designs. == timing-interfaces == The new QSYS interface-type "timing" is asymmetric, there are sources and sinks, much like the avalon_steaming interface-type. Only output signals are allowed on sources, only input signals on sinks. The interface-type will allow 1:N connections, like the clock- and reset-types do. On the other hand, signal-roles should be completely free as in conduit interfaces. Roles on source an sink need not match completely, an error is only raised, if a sinks signal is missing on the source or has different width. Every sink has the opportunity to use any signal it needs and silently ignore everthing else (so you will not need to change the sinks definition once you introduce additional signals). HDL-generation for this new interface-type would be straightforward, no big problem. == implications for streaming == Control-Signals for multiple synchronous streaming-connections can be distributed in a tree-topology. It is more efficient not to have logic interpreting these signals in every component and simply distribute a bit-counter and lsb/msb-signals for a serial stream. And QSYS can do some useful checking ... Avalon interfaces refer to "associatedClk" and -Rst for good reasons. The streaming variant would be even more useful if there was a property to make a reference to a timing. That would allow serial data transfer with implicit synchronization. So I suggest an "associatedTiming"-property for avalon_streaming, that is checked to reference the same timing for source and sink. But how is the reference made? For avalon_streaming sources and sinks, it should have the form <timing_sink_iface>.<id>, where <timing_sink_iface> is the name of a timing-sink on the same component. The timings are looked up in the connected timings-sources "declaredTimings" property, which is of type STRING[]. Two timings match, if they reference the same <id> on the same interface on the same instance. If they do not match, an error is raised. == namespace issues == There will be no namespace clashes, timings defined by foreign IP will be different, even if the same id is used (as it is defined on an interface inside that IP). == multiple timings from one source == A timing-source can provide multiple timings at once, the declaredTimings-property is a list therefore. The relation of the delived signals to these timings is up to the developer and is not restricted. It should even be possible to declare a timing without generating any signals. If such a STRING has the form iface.id (that is: contains one dot), it should reference a timing of another timing-sink <iface> on the same component, so it is possible to pass a timing through. == relation to clock and reset == If you think about it, reset- and clock-signals integrate very neatly with that concept. To some extent, they are timing-signals too. They could be integrated as mandatory roles in the the timing-source. That would of course break each and every existing QSYS-design, but let's spend a few thoughts on this, it will also explain the concept.... Clock and reset would then always be routed together in one connection. Having them separate is nonsense anyway for synchronized resets, because associatedClk is checked and will throw errors. The distiction between different synchronizations of the reset-signal could be made with different "declaredTimings". The clock/reset-source should always export "reset". If it provides synchronous deassert, the it should *add* "reset-sync-deassert", if it provides synchronous assert, then add "reset-sync-assert", if it provides synchronization for both edges, then add "reset-sync-both" to the declaredTimings. Timing-receivers could reference the behaviour they need to make sure, it is provided. The clock-bridge would by default pass the reset-properties it receives on its input. _hw.tcl-commands to enumerate the declaredTimings on an timing-sink should make that possible. == standards for ip == Is there any benefit in standards for the usage of timing-interfaces in foreign IP? In most cases, signals passed via timing interface will not be of much use. Signals named startofpacket, endofpackt, valid, empty and also ready could be interpreted the same way as in avalon_streaming. Passing these signals in a timing_interface would make sure that the signals are identical for multiple streams (in some way a complement to the beatsPerCycle-property which does the opposite by introducing multiple control signals for one streaming interface). In case of the ready-signal, which travels from sink to source, the component with the streaming source would have to implement a timing sink and vice versa. If you need consolidated versions of valid and ready for example, you would need timing-interfaces in both directions. A special case, since you can only reference *one* timing in my proposal. == migration scenario for clock and reset == A migration scenario for existing designs would not be trivial though. You would disallow interface types "clock" and "reset" after "require qsys 16.0" and allow the new "timing"-type. But you must expect to wire up a nested QSYS 15 component in a QSYS 16 system and vice versa. The automatic insertion of a bridge would be necessary. Have a good time, Andreas
