Xilinx ngdbuild error: ... both active and tristate drivers
Andreas Purde
after I managed it that my code passes the Synopsys stuff I get the
following error message from Xilinx ngdbuild for every signal which is
driven from more than one process:
ERROR:NgdHelpers:336 - logical net "whatever" has both active and
tristate drivers
Any idea on how to avoid this?
Thank you.
Andreas
Joel Kolstad
news:3A266F19...@eikon.tum.de...
> after I managed it that my code passes the Synopsys stuff I get the
> following error message from Xilinx ngdbuild for every signal which is
> driven from more than one process:
I didn't see your original post, but you're going to have to insure that all
your processes give some indication to Synopsys that you're creating a true
tri-state driver, I believe. E.g.,
process(Clk,Reset)
begin
if Reset='1' then
signal <= 'Z';
elsif rising_edge(Clk) then
signal <= 'Z';
if Whatever then
signal <= somethingElse;
end if;
end if;
end process;
That should have enough 'Z's in it to get it through Synopsys' head that you
really, really are dealing with tri-state drivers.
If you've already done this, then could you re-post your original code?
---Joel Kolstad
Muzaffer Kal
wrote:
>Hi again,
>
>after I managed it that my code passes the Synopsys stuff I get the
>following error message from Xilinx ngdbuild for every signal which is
>driven from more than one process:
>
>ERROR:NgdHelpers:336 - logical net "whatever" has both active and
>tristate drivers
If I am parsing this correctly, it is trying to tell you that not all
your drivers are tri-state. This is certainly a problem. I'd check all
the drivers' inferrence and make sure that no tri-state controlls are
being optimized to be always on. Another way to find this out is to
run gate-level simulations and watch for conflict on the related bus.
This is not a guaranteed test; you might not be able to generate a
case which would cause a conflict but it is quicker than reading all
the code. If you can't see the problem with simulation, you have to
look at the gate-level netlist and try to figure out where "active"
drivers are coming from.
Muzaffer
FPGA DSP Consulting
http://www.dspia.com
Andreas Purde
> "Andreas Purde" <pu...@eikon.tum.de> wrote in message
> news:3A266F19...@eikon.tum.de...
> > after I managed it that my code passes the Synopsys stuff I get the
> > following error message from Xilinx ngdbuild for every signal which is
> > driven from more than one process:
>
> I didn't see your original post, but you're going to have to insure that all
> your processes give some indication to Synopsys that you're creating a true
> tri-state driver, I believe. E.g.,
>
> process(Clk,Reset)
> begin
> if Reset='1' then
> signal <= 'Z';
> elsif rising_edge(Clk) then
> signal <= 'Z';
> if Whatever then
> signal <= somethingElse;
> end if;
> end if;
> end process;
>
> That should have enough 'Z's in it to get it through Synopsys' head that you
> really, really are dealing with tri-state drivers.
>
> If you've already done this, then could you re-post your original code?
>
> ---Joel Kolstad
In this case it was my fault - my version never would have worked. It does not
make much sense if one process never sets a 'Z' state - at least with the
standard resolution function.
Thank you for your help.
Andreas
Andreas Purde
> On Thu, 30 Nov 2000 16:15:37 +0100, Andreas Purde <pu...@eikon.tum.de>
> wrote:
>
> >Hi again,
> >
> >after I managed it that my code passes the Synopsys stuff I get the
> >following error message from Xilinx ngdbuild for every signal which is
> >driven from more than one process:
> >
> >ERROR:NgdHelpers:336 - logical net "whatever" has both active and
> >tristate drivers
>
> If I am parsing this correctly, it is trying to tell you that not all
> your drivers are tri-state. This is certainly a problem. I'd check all
> the drivers' inferrence and make sure that no tri-state controlls are
> being optimized to be always on. Another way to find this out is to
> run gate-level simulations and watch for conflict on the related bus.
> This is not a guaranteed test; you might not be able to generate a
> case which would cause a conflict but it is quicker than reading all
> the code. If you can't see the problem with simulation, you have to
> look at the gate-level netlist and try to figure out where "active"
> drivers are coming from.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com
Thank you for help - but in this case it was my fault. It does not make
much sense if one process never sets the 'Z' state.
Andreas