IOBs in NGC - problem with OBUFT

(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

Reply to
Jake Janovetz
Loading thread data ...

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

Reply to
Brannon King

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

Reply to
Jake Janovetz

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:

--
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
 Click to see the full signature
Reply to
Paulo Dutra

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

Reply to
Jake Janovetz

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

Reply to
Joko

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

Reply to
Brian Philofsky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.