Y
yogesh malekar
Guest
How to avoi multisourcing on the signal,and bad synchronois descrption
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Y
yogesh malekar
Guest
Anybody give me vhdl program for non restoring division algorithm
To burn it on cpld working on 4 MHZ
frequency
To burn it on cpld working on 4 MHZ
frequency
K
KJ
Guest
On Saturday, April 5, 2014 3:20:15 PM UTC-4, yogesh malekar wrote:
> How to avoi multisourcing on the signal,and bad synchronois descrption
Perhaps by asking someone other than you to write the code.
> How to avoi multisourcing on the signal,and bad synchronois descrption
Perhaps by asking someone other than you to write the code.
T
Thomas Stanka
Guest
Am Samstag, 5. April 2014 21:20:15 UTC+2 schrieb yogesh malekar:
> How to avoi multisourcing on the signal,and bad synchronois descrption
The best way is avoid it during code writing. Second best solution is to detect such issues as fast as possible.
Multisourcing can be detected during compile of code, if you use no resolved signal types (only std_ulogic or std_ulogic_vector).
So if you use only unresolved type you know if code can be simulated, it has no multisourcing at all.
For bad synchronous description you could identify all clock domain crosings (CDC) by hand and verify their correct handling. Alternative spend money in license for tools to help in identifying and verifying of CDC.
regards Thomas
> How to avoi multisourcing on the signal,and bad synchronois descrption
The best way is avoid it during code writing. Second best solution is to detect such issues as fast as possible.
Multisourcing can be detected during compile of code, if you use no resolved signal types (only std_ulogic or std_ulogic_vector).
So if you use only unresolved type you know if code can be simulated, it has no multisourcing at all.
For bad synchronous description you could identify all clock domain crosings (CDC) by hand and verify their correct handling. Alternative spend money in license for tools to help in identifying and verifying of CDC.
regards Thomas
G
GaborSzakacs
Guest
Thomas Stanka wrote:
"multi-source" happens when you drive (assign) a signal in more than
one process. Don't do that for synthesis.
"bad synchronous description" is a term used by Xilinx to tell you that
your sequential logic does not match a standard flip-flop template. To
avoid that use the language templates to see what the synthesis tools
expect. For xilinx this is available in the GUI (light bulb icon) as
well as in the XST user guide.
--
Gabor
Am Samstag, 5. April 2014 21:20:15 UTC+2 schrieb yogesh malekar:
How to avoi multisourcing on the signal,and bad synchronois descrption
The best way is avoid it during code writing. Second best solution is to detect such issues as fast as possible.
Multisourcing can be detected during compile of code, if you use no resolved signal types (only std_ulogic or std_ulogic_vector).
So if you use only unresolved type you know if code can be simulated, it has no multisourcing at all.
For bad synchronous description you could identify all clock domain crosings (CDC) by hand and verify their correct handling. Alternative spend money in license for tools to help in identifying and verifying of CDC.
regards Thomas
"multi-source" happens when you drive (assign) a signal in more than
one process. Don't do that for synthesis.
"bad synchronous description" is a term used by Xilinx to tell you that
your sequential logic does not match a standard flip-flop template. To
avoid that use the language templates to see what the synthesis tools
expect. For xilinx this is available in the GUI (light bulb icon) as
well as in the XST user guide.
--
Gabor
D
Daniel Kho
Guest
On Monday, 7 April 2014 22:30:43 UTC+8, Gabor Sz wrote:
Yes, like Gabor said, "multi-source" is a term used when you have multiple drivers to a signal. If you don't intend to have multiple sources for a signal (which is the case for most designs), I recommend the use of the unresolved VHDL types, such as std_ulogic, std_ulogic_vector, or unresolved_unsigned. By declaring signals to be unresolved, and if you accidentally drive them from multiple sources, your simulator must give you an error.
OTOH, if you use resolved types, your simulator will automatically resolve the value of the signal as a function of all the input drivers (resolution function).
However, most synthesis tools (those that I know of) don't honour this though. They still give you an error even for a resolved signal and doesn't automatically resolve the signal based on some function of its inputs. But simulators are very strict in this sense.
-daniel
Thomas Stanka wrote:
Am Samstag, 5. April 2014 21:20:15 UTC+2 schrieb yogesh malekar:
How to avoi multisourcing on the signal,and bad synchronois descrption
The best way is avoid it during code writing. Second best solution is to detect such issues as fast as possible.
Multisourcing can be detected during compile of code, if you use no resolved signal types (only std_ulogic or std_ulogic_vector).
So if you use only unresolved type you know if code can be simulated, it has no multisourcing at all.
For bad synchronous description you could identify all clock domain crosings (CDC) by hand and verify their correct handling. Alternative spend money in license for tools to help in identifying and verifying of CDC.
regards Thomas
"multi-source" happens when you drive (assign) a signal in more than
one process. Don't do that for synthesis.
"bad synchronous description" is a term used by Xilinx to tell you that
your sequential logic does not match a standard flip-flop template. To
avoid that use the language templates to see what the synthesis tools
expect. For xilinx this is available in the GUI (light bulb icon) as
well as in the XST user guide.
--
Gabor
Yes, like Gabor said, "multi-source" is a term used when you have multiple drivers to a signal. If you don't intend to have multiple sources for a signal (which is the case for most designs), I recommend the use of the unresolved VHDL types, such as std_ulogic, std_ulogic_vector, or unresolved_unsigned. By declaring signals to be unresolved, and if you accidentally drive them from multiple sources, your simulator must give you an error.
OTOH, if you use resolved types, your simulator will automatically resolve the value of the signal as a function of all the input drivers (resolution function).
However, most synthesis tools (those that I know of) don't honour this though. They still give you an error even for a resolved signal and doesn't automatically resolve the signal based on some function of its inputs. But simulators are very strict in this sense.
-daniel