Re: Xilinx ISE Inferred block rams
- From: "John_H" <newsgroup@xxxxxxxxxxxxxxxx>
- Date: Tue, 20 Mar 2007 09:05:06 -0700
"Gabor" <gabor@xxxxxxxxxxx> wrote in message
news:1174398637.932534.169030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 20, 9:28 am, John_H <newsgr...@xxxxxxxxxxxxxxxx> wrote:<snip>
I've seen this harmless warning for way too long though I often get it
for instantiated BlockRAMs where I don't actually read the parity bits
but I write them with zero values so the port isn't undefined.
It's possible the complaint is because the write port is written with
parity bits but the write port output parity bits are unused. Who cares?
O.K., but if it's the write-port parity outputs, why not also complain
(warn) about the write-port data outputs being unconnected?
Because it's an extremely poor warning. It takes one programmer a few
minutes to produce something nonsensical that doesn't get changed through
peer review processes but it takes months and a lot of pain for something to
come out of software. The right thing is to be consistent. It takes one
person too little effort to produce inconsistent messages.
I'd suggest you take a look at the FPGA Editor (or some other technology
view) to see if all your pins are hooked up properly. If your design
truly does not work - as opposed to being a coding/debug problem which
it often is for my development - then there is something wrong with the
synthesis which has to be addressed by the vendor. I often infer
memories with SynplifyPro but haven't used XST for any development.
Also do you see a difference in simulation between behavioral and
post-translate? This could point to a bug in the tools...
I tend to skip the post-translate simulation in favor of live testing except
for special cases. The FPGA tools have done a superb job historically of
producing a target FPGA design that matches the original RTL. While the
ASIC industry needs a significant investment in equivalence checking to make
sure the output from a tool matches the input, I've only come across one or
two instances over the years where the final result isn't a 100% match to
the input code.
It's possible a tool problem is in the way of a good simulation. I'd do a
quick check to see if the "post-translate" results are producing
misconnected hardware or if it looks like the right 18 bits are connected to
the right 18 lines in and out of the BlockRAM. If the physical connections
aren't there, it's probably a synthesis problem. If the physical
connections are there and the warning is its usual bogus self, a mismatch
between RTL and "post-translate" simulation would tend to point to the
simulation models.
If the problem doesn't appear with 16 and 32-bit memories, the troubles
probably aren't with simultaneous read/write operation coming up different
in different simulations but this failure mode would be something else I'd
look for in bad memory simulations if I didn't have the additional
good-inference information.
I'd love to see the warning actually mean something but I've lost any
confidence that it's communicating anything real because of my past
experience with it.
- John_H
.
- References:
- Xilinx ISE Inferred block rams
- From: dlharmon
- Re: Xilinx ISE Inferred block rams
- From: John_H
- Re: Xilinx ISE Inferred block rams
- From: Gabor
- Xilinx ISE Inferred block rams
- Prev by Date: Re: Altera introduces Cyclone III devices, 'ships' 65nm
- Next by Date: Re: How to use the DDR SDRAM instead of Block RAM?
- Previous by thread: Re: Xilinx ISE Inferred block rams
- Next by thread: Re: Xilinx ISE Inferred block rams
- Index(es):
Relevant Pages
|
