Let’s say I wanted to implement a typical control register in a device where some of the bits are “go” bits that execute commands and hence want to be fairly short duration pulses, while other bits are “mode” bits that stay in one state until changed. The first kind wants to use a TriggerIn, while the second calls for a WireIn. Obviously I could also implement the first kind by using a WireIn and writing the bit first to a 1 then back to a 0, giving me a pulse, but I don’t like that because of the unnecessary overhead.
Can I assign one each WireIn and TriggerIn endpoint to the same address, and for each bit position in my register use ep_dataout(i) or ep_triggerout(i) in my code? That would let me define a single register where each bit can be defined as a pulse or a level. Is it kosher to superimpose two endpoints at the same address?
Thanks.
Hello-
You’ve nailed the purpose of the WireIn and TriggerIn endpoints but you won’t be able to superimpose them on the same endpoint addresses since they use different update mechanisms.
Might I ask why you’d like to do this? If it is for efficiency, you wouldn’t gain much (if any) by doing so. The synth/P&R tools will eliminate unused logic anyhow. And you’d need additional logic or configuration space somewhere to be able to tell the difference between a trigger and a wire.
The other disadvantage to using a WireIn as a “go” bit is that it is asynchronous. Unless you add logic to detect only the rising edge of such a signal, your signal could trigger an action multiple times. Thus the design of the TriggerIn.
[QUOTE=Opal Kelly Support]Hello-
You’ve nailed the purpose of the WireIn and TriggerIn endpoints but you won’t be able to superimpose them on the same endpoint addresses since they use different update mechanisms.[/QUOTE]
Hmm, I thought somewhere I saw you mentioning putting two endpoints at the same address, but I guess they must have been the same kind of objects.
[QUOTE=Opal Kelly Support]
Might I ask why you’d like to do this? If it is for efficiency, you wouldn’t gain much (if any) by doing so. The synth/P&R tools will eliminate unused logic anyhow. And you’d need additional logic or configuration space somewhere to be able to tell the difference between a trigger and a wire.[/QUOTE]
My rationale was, if I need a separate WireIn for level signals and TriggerIn for edge triggers, now my device register map has increased because I need separate addresses for the two. If I need one “go” bit and 15 regular bits, now all of a sudden I need a second register address just for the one “go” bit, instead of combining them into one.
I wouldn’t have to tell the difference between a trigger and a wire, I know which register bits are which. For example, myreg(1) s going on with the unused part of the endpoint address space? Future goodies?
— Begin quote from jadwin79
Hmm, I thought somewhere I saw you mentioning putting two endpoints at the same address, but I guess they must have been the same kind of objects.
— End quote
Yes, you can map two TriggerIns to the same trigger endpoint address. This can come in useful if you want to deliver a trigger to two different clocks simultaneously. For example, a single RESET trigger could be used to reset one or more clock domains in your design this way.
You can also do two WireIns to the same wire endpoint address. Sometimes, it may be useful to pass TI_* through the hierarchy of your design and use local instantiations of the endpoint modules. Using this technique, you can have two instantiations at two locations within your hierarchy. Not quite as useful as the above, though.
— Begin quote from jadwin79
I forgot that WireIn and TriggerIn have distinct address spaces so this isn’t possible anyway the way things stand now. No big deal, I’ll adapt to the Way It Must Be Done. By the way, what’s going on with the unused part of the endpoint address space? Future goodies?
— End quote
It was set aside for future expansion but, at the moment, nothing is planned for it.