IOBs in NGC - problem with OBUFT

J

Jake Janovetz

Guest
(I'm not sure why, but Google apparently loses about 50% of my posts,
so I'll try this again)

I have a few modules that I would provide to customers. They are all
quite simple, but by not providing Veriog/VHDL I shelter them from the
implementation details and possible warnings that would come from
synthesis. So, I'd prefer to provide library "objects" in NGC format.

Most of the modules are 'internal' (not requiring IOBs), but one needs
to map to IO pins, including an 8-bit bidirectional bus. If I -don't-
include IOBs in the module, the parent design synthesizes OBUFs for
the bidir bus and completely ignores the inputs. If I manually map
the OBUFTs within the module, I get complaints during parent synthesis
because apparently the parent is adding OBUFs which compete with the
OBUFTs in the module.

I'd prefer a solution which requires as little 'extra' work on the
parent side of things, but would appreciate any suggestions.

Cheers,
Jake
 
In XST use the -iobuf NO parameter to turn off the automatic buffer
insertion.


"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0406171545.68f3e376@posting.google.com...
(I'm not sure why, but Google apparently loses about 50% of my posts,
so I'll try this again)

I have a few modules that I would provide to customers. They are all
quite simple, but by not providing Veriog/VHDL I shelter them from the
implementation details and possible warnings that would come from
synthesis. So, I'd prefer to provide library "objects" in NGC format.

Most of the modules are 'internal' (not requiring IOBs), but one needs
to map to IO pins, including an 8-bit bidirectional bus. If I -don't-
include IOBs in the module, the parent design synthesizes OBUFs for
the bidir bus and completely ignores the inputs. If I manually map
the OBUFTs within the module, I get complaints during parent synthesis
because apparently the parent is adding OBUFs which compete with the
OBUFTs in the module.

I'd prefer a solution which requires as little 'extra' work on the
parent side of things, but would appreciate any suggestions.

Cheers,
Jake
Click to expand...
 
Yes, but there are some pins that I needed to add iobufs on, so this
isn't an option. XST applies that parameter to all i/os, and you
cannot apply selectively.

I ended up having to write a wrapper for my module. The wrapper
contains the I/Os and requires synthesis, but the underlying block
does not.

Jake


"Brannon King" <bking@starbridgesystems.com> wrote in message news:<cav27m$svb@dispatch.concentric.net>...
In XST use the -iobuf NO parameter to turn off the automatic buffer
insertion.


"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0406171545.68f3e376@posting.google.com...
(I'm not sure why, but Google apparently loses about 50% of my posts,
so I'll try this again)

I have a few modules that I would provide to customers. They are all
quite simple, but by not providing Veriog/VHDL I shelter them from the
implementation details and possible warnings that would come from
synthesis. So, I'd prefer to provide library "objects" in NGC format.

Most of the modules are 'internal' (not requiring IOBs), but one needs
to map to IO pins, including an 8-bit bidirectional bus. If I -don't-
include IOBs in the module, the parent design synthesizes OBUFs for
the bidir bus and completely ignores the inputs. If I manually map
the OBUFTs within the module, I get complaints during parent synthesis
because apparently the parent is adding OBUFs which compete with the
OBUFTs in the module.

I'd prefer a solution which requires as little 'extra' work on the
parent side of things, but would appreciate any suggestions.

Cheers,
Jake
Click to expand...
 
You could also allow XST to read in the "module" NGC with
-read_cores option. Xst will read in your NGC to recognize
the logic and infer IO appropriately to the ports that need
IO buffers.

However, your solution of a wrapper is more general and more appropriate.
As it is possible to use this approach in other synthesis tools.
As your customer may prefer a 3rd party synth tool over XST.



Jake Janovetz wrote:
Yes, but there are some pins that I needed to add iobufs on, so this
isn't an option. XST applies that parameter to all i/os, and you
cannot apply selectively.

I ended up having to write a wrapper for my module. The wrapper
contains the I/Os and requires synthesis, but the underlying block
does not.

Jake


"Brannon King" <bking@starbridgesystems.com> wrote in message news:<cav27m$svb@dispatch.concentric.net>...

In XST use the -iobuf NO parameter to turn off the automatic buffer
insertion.


"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0406171545.68f3e376@posting.google.com...

(I'm not sure why, but Google apparently loses about 50% of my posts,
so I'll try this again)

I have a few modules that I would provide to customers. They are all
quite simple, but by not providing Veriog/VHDL I shelter them from the
implementation details and possible warnings that would come from
synthesis. So, I'd prefer to provide library "objects" in NGC format.

Most of the modules are 'internal' (not requiring IOBs), but one needs
to map to IO pins, including an 8-bit bidirectional bus. If I -don't-
include IOBs in the module, the parent design synthesizes OBUFs for
the bidir bus and completely ignores the inputs. If I manually map
the OBUFTs within the module, I get complaints during parent synthesis
because apparently the parent is adding OBUFs which compete with the
OBUFTs in the module.

I'd prefer a solution which requires as little 'extra' work on the
parent side of things, but would appreciate any suggestions.

Cheers,
Jake
Click to expand...

--
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ ` Xilinx hotline@xilinx.com
/ / 2100 Logic Drive http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA
 
Paulo Dutra <paulo.dutra@NOSPAM.com> wrote in message news:<40D73572.803@NOSPAM.com>...
You could also allow XST to read in the "module" NGC with
-read_cores option. Xst will read in your NGC to recognize
the logic and infer IO appropriately to the ports that need
IO buffers.

However, your solution of a wrapper is more general and more appropriate.
As it is possible to use this approach in other synthesis tools.
As your customer may prefer a 3rd party synth tool over XST.
Click to expand...
Paulo-

Interesting option. I hadn't noticed that before. Thanks. As you
said, the wrapper is more general and more appropriate for this
particular issue.

Cheers,
Jake
 
jakespambox@yahoo.com (Jake Janovetz) wrote in message news:<d6ad3144.0406171545.68f3e376@posting.google.com>...
(I'm not sure why, but Google apparently loses about 50% of my posts,
so I'll try this again)

I have a few modules that I would provide to customers. They are all
quite simple, but by not providing Veriog/VHDL I shelter them from the
implementation details and possible warnings that would come from
synthesis. So, I'd prefer to provide library "objects" in NGC format.

Most of the modules are 'internal' (not requiring IOBs), but one needs
to map to IO pins, including an 8-bit bidirectional bus. If I -don't-
include IOBs in the module, the parent design synthesizes OBUFs for
the bidir bus and completely ignores the inputs. If I manually map
the OBUFTs within the module, I get complaints during parent synthesis
because apparently the parent is adding OBUFs which compete with the
OBUFTs in the module.

I'd prefer a solution which requires as little 'extra' work on the
parent side of things, but would appreciate any suggestions.

Cheers,
Jake
Click to expand...
Using .ngc files for sub-modules would be a good solution - not only
in your case !! But problems arises soon after you try it - not only
with the iobufs:
i.e.: how do you want to provide a 'good' simulation-netlist?
backannotating your netlist to a vhdl-netlist using "ngdbuild" and
"netgen" results in a very poor performance of your simulation,
because of the timing-information within that simulation-netlist
driving modelsim 'almost' crazy...
Any tips from "xilinx", how to use this interesting design-flow?

Cheers
Joko
 
Joko wrote:

Using .ngc files for sub-modules would be a good solution - not only
in your case !! But problems arises soon after you try it - not only
with the iobufs:
i.e.: how do you want to provide a 'good' simulation-netlist?
backannotating your netlist to a vhdl-netlist using "ngdbuild" and
"netgen" results in a very poor performance of your simulation,
because of the timing-information within that simulation-netlist
driving modelsim 'almost' crazy...
Any tips from "xilinx", how to use this interesting design-flow?

Cheers
Joko
Click to expand...

There is an unsupported flow now that is better than ngdbuild --> netgen
and there will be a better supported flow soon for this. In the 6.2i
software, there is an executable called ngc2hdl than can transform an
..ngc file to a UNISIM-based structural VHDL or Verilog file. The UNISIM
library does not contain timing and is a bit faster and easier to use
than the SIMPRIM-based structural netlist you would get after ngdbuild.
I mention this is an unsupported flow which means that it is there and
you can use it and if you have any problems you can even file bugs but
we may not be as responsive in answering questions or fixing problems
with this as we would with a standard flow and it is a some-what "use at
your own risk" flow. It is also an undocumented flow at this time
however fairly easy to figure out yourself. To my knowledge there is no
problems with ngc2hdl however it is new and we did not want to open the
flood gates to its use yet so it is not advertised, documented and not
officially supported by Xilinx.

In a future release, we plan to integrate ngc2hdl into netgen so that
you can run netgen directly on the ngc file and get the UNISIM netlist
and at that time it will be officially supported. We will remove
ngc2hdl (which we can do more easily since it was never officially
supported or documented). We also have some enhancements around the
corner for the UNISIM library that should significantly improve its
speed over today and thus give an even faster simulation netlist
although it likely never will be close to the speed of a true behavioral
or RTL model. I do suspect it will be very usable however for IP like
this and should enhance the use of ngc files over what can be done today.

Xilinx is working towards continually improving simulation and this is
only one facet of some of the improvements you will be seeing in future
releases. If you have any ideas for improvements or feedback on
simulation, you can send them directly to me and I guarantee they will
be read and considered. It is my job to do the future planning for
Xilinx simulation and I am always open to hear feedback from users to
assist in my work.


-- Brian Philofsky
-- Xilinx Technical Marketing
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top