Open GoogleCodeExporter opened 9 years ago
Thanks for reporting this issue Jeff.
Can you please try again with the latest SVN version of Odin II? The Odin II
trunk should be stable, and I believe this bug has already been corrected.
Original comment by andy16...@gmail.com
on 30 Apr 2012 at 12:53
Original comment by jeffrey....@gmail.com
on 30 Apr 2012 at 3:09
I have updated to the latest versions of ODIN and VPR.
The bug still exists.
Original comment by jeffrey....@gmail.com
on 7 May 2012 at 11:04
[deleted comment]
On closer examination, I believe this is correct, strictly speaking. But bear
with me for a moment while I explain and then I'll ask for your recommendation.
For example:
.names top^memory_controller_out~8
0
.names top^memory_controller_out~9
0
Depending, these are probably added during padding, and *should* be
unconnected. The new version probably names them more descriptively. Knowing
that, what do you suggest it outputs instead? I would be just as happy to
output nothing for unconnected output pins, if that's legal.
The second case is correct as well. We can output something else in the BLIF if
you want, but this seems like something ABC would easily catch.
What do you think?
Original comment by andy16...@gmail.com
on 7 May 2012 at 11:22
OK. I guess what ODIN is doing is fine. I had originally flagged this as a
VPR issue, and I think that still holds true.
I don't think VPR should be mapping unconnected signals to LUTs.
The second case, where signals are merely a name change, also seems like it
should not be using LUTs.
Original comment by jeffrey....@gmail.com
on 7 May 2012 at 11:27
The 1st case (unconnected) needs to be fixed in VPR.
The 2nd case (wire, name change) is already handled in VPR.
Original comment by jeffrey....@gmail.com
on 10 May 2012 at 4:17
I also came across the following lines in diffeq1.pre-vpr.blif:
.names vcc
1
Is this something that we are automatically inserting to specify a constant
'1'?
Currently VPR is mapping this to a LUT, which should be fixed.
Original comment by jeffrey....@gmail.com
on 18 May 2012 at 7:02
I'm going to merge in Jeff Rudolphs fixes for constant output pads. He gives
the user the option of whether or not to remove constants. This choice is
actually quite important. How often have we, as digital designers, set a
particular output pad to a constant gnd or vcc (to turn on an LED on a
development board, for example) for testing on small projects? I'm sure pretty
often. At the same time, we also rely on the CAD tools to warn us when an
output is constant when it is not supposed to be. So giving the same choice to
the user is pretty useful.
Constants such as vcc and gnd are not so easy to handle. They can only be
removed if the architecture can programmably set pins to gnd or vcc. If not,
then a LUT will need to get consumed to act as a constant 0 or constant 1. VPR
already has code in place that will handle constants with LUTs (ie. timing
analyzer does not treat delays from constants as part of the timing path).
Furthermore, what if some blocks in your architecture support gnd/vcc and
others do not?
For these reasons, I'm actually changing this to a VPR enhancement and taking
over ownership for it.
Original comment by JasonKai...@gmail.com
on 5 Jun 2012 at 8:01
Original issue reported on code.google.com by
jeffrey....@gmail.com
on 30 Apr 2012 at 4:50Attachments: