Pack registers (from submodule) into IOB for bidirectionnal signal

Hello,

I know that this has been discussed here a few times but I still can't find a definitive answer so here we go again...

What is the best way (with Xilinx flow) to ensure that registers are packed into IOB? In my case I want three registers to be packed into the IOB for a bidirectionnal signal (in, out and oe).

The registers in question are buried in a vhdl module two hierchical levels down. This module is synthesized separately into a ngc file (as most of my other modules) to create an "incremental" flow. I'm not using xst own incremental flow however (i.e. I'm not using a xcf file with -incremental_synthesis flags).

To make matters a little more difficult, I would really like to keep the hierarchy as it makes it much easier to debug with Chipscope.

I read quite a bit about the issue and the standard tricks seem to be:

1- Use the IOB = "true" constraint in the HDL code for the registers 2- Use the flag -iob true for xst (redundant with #1) 3- Use -pr b at the map stage 4- Duplicate the oe registers and use equivalent_register_removal = "NO" to prevent xst from optimizing them away 5- Make sure that the fanout of output registers and fanin of input registers is 1. 6- Run map with the option -ignore_keep_hierarchy to flatten the design. 7- From Xilinx WP231: When using hierarchy: "Place all I/O components including any instantiated I/O buffers, registers, DDR circuitry, SerDes, or delay elements on the top-level of the design. If it is not possible to place them on the top-level, ensure that they are all contained within a single hierarchy."

Now I followed the above tricks except #7. For the moment I'd be happy even if I don't keep hierarchy. The best I could acheive so far is that the input registers are in the IOB. The out and oe registers however are not.

Now maybe if I followed trick #7, I could make it work but it seems very ugly to me. I don't want logic on the top level that is related to a sub module two levels down. Furthermore, using the flag ignore_keep_hierarchy at the map stage should produce the same result, shouldn't it?

Any suggestions?

Thank you.

Patrick Dubois

Reply to
Patrick Dubois
Loading thread data ...

Make sure that the FFs can fit into the IOB. For Virtex, for example, the clock and reset are common between the FFs in the IOB. If the input FF is on clock_foo and the output FF is on clock_blah, then both FFs can not fit into an IOB. If a reset is generated to the FFs, it must be the same reset signal for all FFs that are reset, or again the FFs can not be in the same IOB.

--
Phil Hays (Xilinx, but speaking for myself)
Reply to
Phil Hays

Thank you Phil, I wasn't aware about the reset restriction. All registers share the same clock but they didn't have the same reset. I made modifications and now the out and oe registers have no reset at all and the in register has a reset that is connected as clock enable (so not really a reset). Basicaly the SR line of the IOB is unused.

Well unfortunately the out and oe registers are still not in the IOB...

Could the issue be due to the fact that I'm synthesizing the submodule separately from the top level?

Patrick

Reply to
Patrick Dubois

Your #7 may be the magic key. From the "Virtex4 Synthesis & Simulation Design Guide":

these resources are

these resources

In some sense, IOB packing is a kind of resource sharing. So the packer probably won't work across hierarchy boundaries.

Reply to
David R Brooks

Several months ago, I opened a WebCase with Xilinx regarding packing the OE registers into an IOB. I sent example cases showing how the tools failed to use the OE registers when infering logic. It took a while to convince the Xilinx "support" person that the tools were doing a very poor job on a very obvious and desireable IOB register packing operation.

I know that in previous versions of ISE, you needed to have all the IOB logic in one level of hierarchy if you wanted any chance of automatically usin ghte IOB registers.

John Providenza

David R Brooks wrote:

these resources are

these resources

Reply to
johnp

Thanks David. #7 was indeed the key. Fortunately I didn't have to bring the registers all the way to the top level. All that was needed was to keep everything on the same hierarchical level.

Another trick that I needed is that when synthesizing the top_level, one has to let xst absorb the ngc submodule by using -read_cores optimize (just "yes" won't work) and -sd pointing to the right path. It doesn't work otherwise. Unfortunately this makes the synthesis MUCH slower.

Another observation is that #6 is not needed after all.

Now I'm going to try to keep the hierarchy. Hopefully I won't have to bring the registers to the top...

Patrick

David R Brooks wrote:

these resources are

these resources

Reply to
Patrick Dubois

You seem to have the standard tricks...

Not only redundant, but quite dangerous since this flag appears to apply the IOB=TRUE attribute to every individual register (maybe only every register on a hierarchy boundary) regardless of whether it is anywhere near a pin. And this attribute prevents packing registers into multipliers and who knows what else...

#1 applied ONLY to the registers in question gives much better control

Essential - and again, apply equivalent_register_removal as an attribute ONLY to the registers in question, not as an XST flag...

With both of these as global flags I have seen a 15% slowdown and 20% greater register usage in a design.

- Brian

Reply to
Brian Drummond

Thanks for the good advice Brian. Small details often make a big difference.

Patrick

Brian Drumm> >

Reply to
Patrick Dubois

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.