Dangling all pins, DIA0 through DIA31

A

aleksa

Guest
I'm creating a dual-port ROM, both sides are the same: 7-bit address,
32-bit data.
Very simple ISE 13.3 project can be downloaded from here:
http://www.mediafire.com/?xmf55vwdb14qvbf
ďťżďťżďťżďťżďťżďťżďťżďťż
Both Implementing and Generating the bit file gives warning like this
one:
PhysDesignRules:812 - Dangling pin <DIA0>
all the way from DIA0 to DIA31.

I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
but am not sure if that applies here.

Am I doing something wrong here?

Testing on XC3S50A.
 
AFAIC, this is a bug and should be fixed.
I'm creating a ROM, not a RAM.
 
On 2012-02-10 11:41, aleksa wrote:
I'm creating a dual-port ROM, both sides are the same: 7-bit address,
32-bit data.
Very simple ISE 13.3 project can be downloaded from here:
http://www.mediafire.com/?xmf55vwdb14qvbf
ďťżďťżďťżďťżďťżďťżďťżďťż
Both Implementing and Generating the bit file gives warning like this
one:
PhysDesignRules:812 - Dangling pin<DIA0
all the way from DIA0 to DIA31.

I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
but am not sure if that applies here.

Am I doing something wrong here?

Testing on XC3S50A.
I think this is probably OK. Have you simulated your design and/or seen
that it works as you expect in hardware?

I have often seen similar warnings for unused address lines on block
RAMs for Microblaze or PPC designs. The ROM and RAM are made from the
same Block RAM primitives, so the same connection lines are there, even
if not implemented.

Maybe somebody else will chime in with a more concrete answer though.

Steve
 
On Feb 10, 1:33 pm, sbattazzo <sbatta...@gmail.com> wrote:
On 2012-02-10 11:41, aleksa wrote:





I'm creating a dual-port ROM, both sides are the same: 7-bit address,
32-bit data.
Very simple ISE 13.3 project can be downloaded from here:
http://www.mediafire.com/?xmf55vwdb14qvbf
ďťżďťżďťżďťżďťżďťżďťżďťż
Both Implementing and Generating the bit file gives warning like this
one:
PhysDesignRules:812 - Dangling pin<DIA0
all the way from DIA0 to DIA31.

I'm aware of this page:http://www.xilinx.com/support/answers/31378.htm
but am not sure if that applies here.

Am I doing something wrong here?

Testing on XC3S50A.

I think this is probably OK. Have you simulated your design and/or seen
that it works as you expect in hardware?
No, I haven't simulated it, it is too simple. (did you get the file?)
And I haven't tested it with real hardware, bc that was just a test.

Maybe someone has 13.4 and has time to test it there? (synthesize and
implement)

I have often seen similar warnings for unused address lines on block
RAMs for Microblaze or PPC designs. The ROM and RAM are made from the
same Block RAM primitives, so the same connection lines are there, even
if not implemented.

Maybe somebody else will chime in with a more concrete answer though.

Steve
 
aleksa <aleksazr@gmail.com> wrote:

I'm creating a dual-port ROM, both sides are the same: 7-bit address,
32-bit data.
Very simple ISE 13.3 project can be downloaded from here:
http://www.mediafire.com/?xmf55vwdb14qvbf
=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF
Both Implementing and Generating the bit file gives warning like this
one:
PhysDesignRules:812 - Dangling pin <DIA0
all the way from DIA0 to DIA31.

I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
but am not sure if that applies here.

Am I doing something wrong here?
No. Open pins should generate a warning. Just tie them to '0'.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
No. Open pins should generate a warning. Just tie them to '0'.
OK.

But ISE should do that automatically, because there are
other input pins in the BRAM that I'm not using,
and ISE is not complaining about those pins.

Anyone knows how do I do that in specifically this project?
 
I've created a similar project, just replacing ROM with RAM.
http://www.mediafire.com/?nlpnn3xs5z940ox

1. synthesize, implement
2. comment and uncomment lines 46, 47
3. synthesize, re-implement

it seems it has something to do with the WEA signal
 

Welcome to EDABoard.com

Sponsor

Back
Top