1. Home
  2. Field-Programmable Gate Arrays
  3. behavioral vs post-P&R simulation mismatch

behavioral vs post-P&R simulation mismatch

I know this topic has been discussed before, but i am looking for some ideas. My design is synchronous, I use ISE8.2.02 XST and ModelSim, I have a lot of signed logic; I get different results from behavioral and post-Route simulations. I paid attention to the reset condition, in fact the data are ok after the first stage of the circuit. I tried to delay the data compared to the clock with no success. I noticed that at the first rising edge of the clock most signals are x in the post-P&R simulation, while they are defined in the behavioral simulation. Any advice before bringing out every meaningful signal in the implementation process ? Any known bug in the simulation models of the xilinx primitives (multipliers, BRAMs, etc) ?

Tullio

Reply to
tullio
Loading thread data ...

I had some problems using signed logic in Verilog using an older version of XST although I do not remember the version any longer. I introduced a workaround to avoid the bug. I haven't checked wether the bug is still present in the latest version of XST. (Since I was not allowed to open a webcase at the time I discovered this bug I reported the bug on the Xilinx University Program forum but I didn't hear anything back about it.)

The source code and screenshots of the waveforms of behavioral and post-map simulation are available at

formatting link
.

I'm afraid dct_workaround.v and dct.v differ quite a lot, but you can search for "synthesis bug" in dct_workaround.v to see the workaround I did.

/Andreas

Reply to
Andreas Ehliar

I found the problem, it was actually in the signed logic. I had something like:

wire my_wire; reg signed [10:0] power= 11'h688; parameter [10:0] m33dBm = 11'h6F8; // unsigned declaration :( ... assign my_wire = (power >m33dBm);

I did not realize that I had an expression with one signed and one unsigned operand. This is clearly bad practice, but I think the Verilog2001 standard forces a deterministic result to it, with conversion rules. But XST 8.2.02i and ModelSim interpret differently tyhe expression; i think ModeSim is correct (my_wire evaluated to 0 as expected) and XST is wrong (my_wire evaluated to 1 in post-P&R, why ?) The 2 simulations are equal with this declaration:

parameter signed [10:0] m33dBm = 11'h6F8;

PS: Xilinx should give a bonus to users for finding their bugs... Plus I could not find good guidlines on how XST interpret signed logic.

Andreas Ehliar ha scritto:

Reply to
tullio

Opening a service request to Xilinx would be a good first step. Even now that you 'know' the solution, Xilinx doesn't know about it until you let them know through some mechanism.

KJ

Reply to
KJ

KJ ha scritto:

yes i mentioned to a xilinx support guy. Anyway I went on to test the compatibility with the Verilog standard of ISE and ModelSim of other signed syntax. I found another violation of XST. If you do:

output reg [10:0] UregU; ... UregU

Reply to
tullio

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.