synthesising VHDL for Xilinx FPGAs using ISE 6.1i

[Ashant]

Hi,

I had posted this message earlier on comp.cad.synthesis ... but the
traffic there is so low that I am not sure if enough people have seen
it.

I have a VHDL model where a number of nodes are talking to each other
as well as a register file, using a common pair of address-data buses
with requests and acks for arbitration. Each node has a single process
with an FSM that governs its working.

The model works correctly in ModelSim, but I face problems when
synthesising. I am using the Xilinx ISE version 6.1i for this. The
synthesis phase completes, but XST throws a lot of warnings like the
one below:

WARNING:Xst:638 - in unit top_entity Conflict on KEEP property on
signal rfile_inst_Mtridata_data_bus<4> and
node2_inst_Mtridata_data_bus<4> node2_inst_Mtridata_data_bus<4> signal
will be lost.

"node2_inst" is an instance of a component called "node2" in an entity
called "top_entity". "data_bus" is an inout std_logic_vector port on
the node2 entity.

I had searched the newsgroups for similar problems and learned about
the "equivalent_register_removal" and "keep" attributes. But the
signal mentioned here, "Mtridata_data_bus" is inferred internally by
the synthesiser, so I have no idea how to set these attributes on this
signal! Setting this attribute for just "data_bus" doesn't seem to
help.

Inspite of these warnings, the synthesis phase finishes, but the
"translate" phase aborts after this error from NGDBUILD:

ERROR:NgdBuild:456 - logical net 'rfile_inst_Mtridata_data_bus<4>'
has both active and tristate drivers

I have no idea how to rectify this error. And this seems to occur only
for the Virtex and Spartan FPGAs ... I tried synthesising for the
CoolRunner CPLD, and everything worked out without any error.

How do I address this from my VHDL code? Or is this a tool or platform
specific problem?

Ashant.

 

[Mario Trams]

Ashant wrote:

snip
ERROR:NgdBuild:456 - logical net 'rfile_inst_Mtridata_data_bus<4>'
has both active and tristate drivers

I have no idea how to rectify this error. And this seems to occur only
for the Virtex and Spartan FPGAs ... I tried synthesising for the
CoolRunner CPLD, and everything worked out without any error.

How do I address this from my VHDL code? Or is this a tool or platform
specific problem?

Hi Ashant,

it is difficult to diagnose this without seeing the code. I would guess
that there is a little mistake in your code.
When you describe busses and you synthesize it for a PLD, this is
usually mapped into a MUX/DMUX structure (PLDs do not have tristatable
drivers).

Most FPGAs (so the Virtex) have tristatable drivers and can handle
real busses.

So you should check first whether the bus you have in your design
is properly described. I.e. under some condition you assign a
value, and under other conditions you assign a 'Z' (for each part
that is driving something onto the bus).

Another explanation could be that these inferred
"rfile_inst_Mtridata_data_bus", etc. signals are the actual
driver controls (enable signals) and are for some reasons set
to "always active". This would also explain the ngdbuild error
you are receiving later.

You say that the synthesis for a CoolRunner CPLD worked fine.
Have you simulated and verified the backannotated design?

Regards,
Mario

 

[Michael Schöberl]

Most FPGAs (so the Virtex) have tristatable drivers and can handle
real busses.

As I remember there are no real tristate signals any more in Xilinx
FPGAs because they were too slow ... real tristate is only in the IOBs

in the FPGA there are structures that *simulate* a tristate behaviour
(for backward compatibility) but they can't be used for
bidirectional busses ...

I guess you described something like a bidirectional tristate bus
and the synthesis-tools can't handle that properly ...


bye,
Michael

 

[Mario Trams]

Michael,

Most FPGAs (so the Virtex) have tristatable drivers and can handle
real busses.

As I remember there are no real tristate signals any more in Xilinx
FPGAs because they were too slow ... real tristate is only in the IOBs

in the FPGA there are structures that *simulate* a tristate behaviour
(for backward compatibility) but they can't be used for
bidirectional busses ...

No, according the data sheets describing the architecture this is wrong.
VirtexII devices have two tristate buffers per CLB and they provide
according tristatable connection lines as well.

It is written in the data sheet:
The 3-state buffer logic is implemented using AND-OR logic rather
than 3-state drivers, so that timing is more predictable and less
load dependant especially with larger devices.
(Virtex-II Functional Description (Module 2), page 20)

Perhaps this has confused you. No matter how Xilinx implemented this
physically, the direct support of tristatable (and hence bidirectional)
busses is there.

Regards,
Mario

 

[Ashant]

Mario Trams <Mario.Trams@informatik.tu-chemnitz.de> wrote:

it is difficult to diagnose this without seeing the code. I would guess
that there is a little mistake in your code.

Well, the code is pretty much clean ... every entity interacting with
the bus has a single process with a case statement that was generated
from an already proven set of FSMs.

But curiously enough, all the VHDL code works now. The only thing I
did was to remove one or two extraneous signals that were declared but
never used by any entity. Is it because the synthesiser's attempts at
optimisation are so aggressive as to cause unexpected problems?

When you describe busses and you synthesize it for a PLD, this is
usually mapped into a MUX/DMUX structure (PLDs do not have tristatable
drivers).

Most FPGAs (so the Virtex) have tristatable drivers and can handle
real busses.

That makes sense. I am new to actual synthesis of hardware, this
continues to be a learning experience for me.

You say that the synthesis for a CoolRunner CPLD worked fine.
Have you simulated and verified the backannotated design?

Pointers for a complete newbie please ... I am aware that you are
supposed to iterate at every stage of the process to smoothen out any
wrinkles that may cause unexpected problems. The build process in ISE
generates tons of information through various reports, but I don't
know how to make proper use of that ... URLs / FAQs / tutes on this
would be most useful.

Thanks,
Ashant.