JorgeAbarca Posted September 11, 2019 Report Share Posted September 11, 2019 Hi, I am working on a code that gives support to some UPF features. Right now, i am working on the solution to support Level Shifters. Basically my project reads the UPF file, and extracts the relevant information, each port knows to which PowerDomain belongs and the status of it, then they are able to react depends on if the power domain is ON or OFF. Now i am trying to solve how to include the level shifter support, what i have thought is to generate a customized channel, based on sc_signal, but instead of write(_value), write(_value, _domainvoltage). the idea is that the implementation is hidden to the final user (since each port knows the UPF info, it will knows the voltage of the domain). in that way, when a value is read, i will be able to known the domain voltage, and then make some decisions based on that value. What do you think? my strategy would work? i am still working on the code to do that. thanks - Quote Link to comment Share on other sites More sharing options...
David Black Posted September 12, 2019 Report Share Posted September 12, 2019 Is the concern related to power domains being on or off? I would think it might be more productive if your underlying implementations looked for a hierarchical attribute related to power and you organized modules around power domains. Or perhaps you could have a global lookup unordered map of instance names to power domains. In any event, I would not redefine the API of standard channels. Keep in mind that generally sc_signal is a low level primitive and should be somewhat rare in most modeling situations. I would more likely expect this issue to appear in a TLM socket connection. Quote Link to comment Share on other sites More sharing options...
JorgeAbarca Posted September 12, 2019 Author Report Share Posted September 12, 2019 if I think i terms of software and not in Hardware, what I would need is an sc_signal with 1 more attribute. then to do that i can create a new class that inherits from sc_signal, include the attribute (float DomainVoltage) and include a setter and getter. And in my opinion that sounds like a solution, but now i dont know how to read it into my ports. in geneal words i have something like this: //sc_signal_upf CLASS class sc_signal_upf : public sc_signal<T,POL> { float DomainVoltage; public: sc_signal_upf(){} void operator = ( const T& a ){ (*this).write(a); } float getDomainVoltage(){ return DomainVoltage; } }; //port with UPF emplate<typename T> class sc_out_upf : public sc_channel { how can i access the gette rhere ??????? } Quote Link to comment Share on other sites More sharing options...
JorgeAbarca Posted September 13, 2019 Author Report Share Posted September 13, 2019 i am not sure if what i am asking is very basic, probably yes, but to solve this i have had to learn while deliver. does my analysis make sense ? Quote Link to comment Share on other sites More sharing options...
JorgeAbarca Posted September 13, 2019 Author Report Share Posted September 13, 2019 Could you please elaborate more on your suggestion? i can find out the voltage of every power domain, and each port knows the domain where it belongs... but how can I see where the signal comes from ??? I mean, if the ModA has a signal conected to ModB.... how modB can realize that the signal comes from modA? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.