1. Home
  2. Field-Programmable Gate Arrays
  3. synthesising VHDL for Xilinx FPGAs using ISE 6.1i

synthesising VHDL for Xilinx FPGAs using ISE 6.1i

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 and node2_inst_Mtridata_data_bus node2_inst_Mtridata_data_bus 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' 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.

Reply to
Ashant
Loading thread data ...

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

Reply to
Mario Trams

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

Reply to
Michael Schöberl

Michael,

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

Reply to
Mario Trams

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?

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

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.

Reply to
Ashant

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.