TBUF and modular design flow on spartan

I have a project where I am trying to use modular design flow. When I do synthesis of one of my modules I see the message in the log.

Number of TBUFs: 61 out of 0 (*)

I think this is causing me problems when I try to do the assemble, because those modules get dropped from the design.

Any suggestions on what I am doing wrong or how to work around it.

Reply to
javaguy11111
Loading thread data ...

Which device are you using? Spartan, XL, II, IIe have TBUF in hardware. Spartan 3, 3e, 3a, 3an, ... do not. Normally synthesis can replace internal tri-state buses with LUTs, but if you try to instantiate TBUF's in a part that doesn't have any you will "overmap" the device as shown in your report.

HTH, Gabor

Reply to
Gabor

The device is a Spartan 3. The project was previously synthesized without using modular design and there is nothing mentioned in that log about problems with TBUF's.

Is this something specific to using modular design flow that is making this occur? Perhaps having to use the -iobuf no option when synthesizing a module.

Reply to
javaguy11111

I think during a normal synthesis run, TBUFs are automatically replaced by logic. I know that at least in Virtex4, there are no internal tristates, so if you describe tristate busses, the tools don't complain but just replace them with logic.

But if you do the modular design flow, the TBUFs become sort of "external ports" that can't be changed automatically, so the synthesis tool tries to keep the TBUFs, and ngdbuild/map stop later because there aren't any in that architecture.

I don't think the "-iobuf"-option will help in that case, since it turns on/off automatic insertion of IO buffers by the tools, but it will not change/remove buffers that you have instantiated manually.

I guess the only thing you can do is have two seperate signals for the two directions and one direction signal as module ports, instead of the tristate-line. Not sure how you would properly constrain the localtion of the module crossings in that case, though.

BTW, I thought the whole modular is deprectaed since ISE8/9, and now there is only "partitions"? Haven't tried that out yet, but maybe you should have a look.

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Reply to
Sean Durkin

Looking at the Xilinx website, it does look like partitions are the replacement for modular design flow. I was wondering why the modular design flow chapter was missing in the 9.1 docs. I was having to use the 8.1 docs.

Unfortunately the documentation for parititions appears to be worse than for modular design flow! I see some references to partitions in the tcl chapter, but that is about it. I see nothing showing how I would use it with area_groups or the floorplanner.

Reply to
javaguy11111

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.