Simulation and Verification

[murtaza5152]

I am using the latest version of ISE 14.1 and it seems that the bug is still not fixed. Address 0 read still reads out undefined value!

Any fix for that?

[graces]

---

murtaza5152 wrote:
I am using the latest version of ISE 14.1 and it seems that the bug is still not fixed. Address 0 read still reads out undefined value!

Any fix for that?

---

Would you please open a webcase with Xilinx Technical Support? A CR needs to be filed if it's confirmed a sim library bug.

[murtaza5152]

I tried initializing the BRAM using a .mif file. Read to address 0 works fine in one case, but reads out 'U' in the other. i am baffled!?

[murtaza5152]

Hi,

Has anyone come across this bug in ISE 14.1? I cannot believe that such a big bug hasn't been rectified through so many versions of ISE. Also, I am wondering if people just happily continue reading out "UNDEFINED" value from address 0 through all these years!?!??!?!

Regards,

Murtaza

[bassman59]

---

murtaza5152 wrote:

Hi,

Has anyone come across this bug in ISE 14.1? I cannot believe that such a big bug hasn't been rectified through so many versions of ISE. Also, I am wondering if people just happily continue reading out "UNDEFINED" value from address 0 through all these years!?!??!?!

Regards,

Murtaza

---

I can't believe people actually instantiate BRAMs instead of inferring them through all these years.

[murtaza5152]

Hi bassman59,

I didnt mean to be sarcastic / rude. We have used coregen to generate BRAMs and facing issues reading out the address 0 after initializing using a MIF file. Do you know a fix/ workaround that we could use?

Your help is very much appreciated.

Thanks.

[bassman59]

---

murtaza5152 wrote:

Hi bassman59,

I didnt mean to be sarcastic / rude. We have used coregen to generate BRAMs and facing issues reading out the address 0 after initializing using a MIF file. Do you know a fix/ workaround that we could use?

Your help is very much appreciated.

Thanks.

---

I did not detect any sarcasm or rudeness in your post. I just detected the frustration that comes with using the tools and models in the standard way and they fail for no apparent reason.

 I will admit that mine was intentionally snarky.

But seriously: write code that infers the memories.

Without seeing the code that the tools generated for you, I cannot guess at the source of the problem.

[murtaza5152]

Hi bassman,

Inferring  memories is sometimes cumbersome. Coregen on the other hand is easier to use for generating BRAM with customizable bitwidths , depth and other options to generate MIF files etc. In the structural design, we just generate the BRAMs and interface them with the rest of the design. What fazes me is the lack of solution to such an apparent problem!

..and yes, you sensed me frustration right. You really don't expect yourself to be debugging issues that are present for an *extended* period of time - something that should be rectified by Xilinx and not the users.

Best,

-M

[bassman59]

---

murtaza5152 wrote:

Hi bassman,

Inferring  memories is sometimes cumbersome. Coregen on the other hand is easier to use for generating BRAM with customizable bitwidths , depth and other options to generate MIF files etc. In the structural design, we just generate the BRAMs and interface them with the rest of the design. What fazes me is the lack of solution to such an apparent problem!

..and yes, you sensed me frustration right. You really don't expect yourself to be debugging issues that are present for an *extended* period of time - something that should be rectified by Xilinx and not the users.

Best,

-M

---

That frustration with the tools is the main reason I avoid CoreGen and any other magical code generators if at all possible.

[murtaza5152]

True, but its kind of unfortunate if we are limited to use the tools that are meant to make life easier, isnt' it ? :)