Forum Discussion
117 Replies
- Altera_Forum
Honored Contributor
Hello Dave,
Is my problem still unclear? Should I re-frame my question? Thanks, Aditya - Altera_Forum
Honored Contributor
I'm guessing bidirectional pins can't be virtual. A virtual pin routes inside the FPGA and never goes to an I/O. A bidir has a tri-state component that only exists in the I/O. I'm not sure how that would be virtual unless the tri-state was ripped out. I'm guessing the virtual assignment is ignored for those I/O.
- Altera_Forum
Honored Contributor
So, if a module [let this be sub-module that connects other modules] has "bidirectional pins" do they automatically get a pin location on the FPGA? What if I want to use the bidirectional pins to connect other modules?
- Altera_Forum
Honored Contributor
There are no internal tri-states. Synthesis can sometimes recode bidirectionals into muxing logic, assuming the solution is obvious. It's generally advised to avoid internal tri-states, since they don't really exist in hardware.
- Altera_Forum
Honored Contributor
Thanks Rysc.
- Altera_Forum
Honored Contributor
Hi Aditya,
--- Quote Start --- Is my problem still unclear? Should I re-frame my question? --- Quote End --- Sorry for the delay in responding, I'm traveling, and only have sporadic internet access. Its not clear to me why you want to use virtual pins. I have never found a need to use them. Its quite possible that the problems you are having are related to trying to use a feature for other than it was intended. Rather than use bidirectional signals in components, you should use three ports; data_out, data_in, and data_oe, and then at the top-level design, use these three signals to implement a tri-state bus. Since these three signals (or ports) are unidirectional, you should be able to make them virtual. Note, these unidirectional ports/signals can be connected to 'fake external devices' internal to the FPGA, where the fake devices can implement what you expect your external device to do. Using these fake devices, you can probably eliminate the need for virtual pins. Cheers, Dave - Altera_Forum
Honored Contributor
Thanks :-)
- Altera_Forum
Honored Contributor
I looked at my private sent message. I said Zero, but I did send you one message, So I am posting it here again since I was not sure whether you had actually received the message.
My message: I used Timing Optimization Advisor[TOA] to tweak my design. The results were not consistent. [some times the teaks seems to work and some times it doesn't. Some times there are variations in the normal cases[with no tweaks] that outperforms the cases with tweaks] Here are my observations: observation 1: Some of the settings after following the TOA suggestions looked like this: restructure multiplexers: OFF state machine encoding: One Hot smart compilation: ON. In spite of this the Fmax did not exceed one of the cases when I hadn't followed the TOA suggestions. observation 2: The compilation time did not change after switching the "Smart Compilation" option to ON. But in one case it reduced from 12min to 8 min. Are these options reliable? Looks like the randomness that occurs during the compilation is very dominant. Am I doing something wrong? Thanks, AA - Altera_Forum
Honored Contributor
--- Quote Start --- I used Timing Optimization Advisor[TOA] to tweak my design. The results were not consistent. [some times the teaks seems to work and some times it doesn't. Some times there are variations in the normal cases[with no tweaks] that outperforms the cases with tweaks] --- Quote End --- I do not use these tools. However, a general recommendation would be to only use them when optimizing individual components, not an entire design. You may have a single poorly designed component that is affecting the entire design. Determine if all components need to run at the same clock rate, or whether the design can be arranged to have slower peripherals separated into another part of the design, and then access those components via a clock-crossing bridge. Cheers, Dave - Altera_Forum
Honored Contributor
Thanks Dave.