Re: Bus macro in partial reconfiguration

The bus macro doesn't seem to lack anything, but I discovered that if I route the concerned signal to a "pip" further to the left, the design finally routes. So it seems that the PAR needs to have that first part of the path to route the signal.

Another question, are the bus macro really compulsory? If I use a custom bus macro, without TBUFs, just to be sure that the signal passes through the same nets, will it work?

Your help was very useful.

Regards, Amaury Anciaux

Yes, but in this case, even in the final assembly, this signal stays > unrouted. > I attach some example files: the NCD routed designs of the two modules, and > the final assembly. > The signals conerned are controlL and controlL (in module 1 and final > assembly). Other unrouted signals in the modules are normal.

Try the following at the command prompt:

xdl -ncd2xdl bm_v2p_4b.nmc

This converts the bus macro to an XDL-description. Have a look at the .XDL-file this generates. For each net, there should be a section where it specifies which PIPs to use and such. For each net there should be an attribute like this:

cfg "_NET_PROP::IS_BUS_MACRO:" ,

If there isn't, par sometimes doesn't route the corresponding output net. I have no idea why that is... In case this attribute is not set for the fourth bit of your bus macro, it could help to insert it manually in the .XDL-file and convert that back to ncd-format:

xdl -xdl2ncd bm_v2p_4b.xdl

This gives you an .ncd-file which you have to rename to .nmc to be able to use it as a macro.

Don't know if this will help you, but I always had to manually insert the above attribute for all nets in the macros I did myself in FPGA Editor. FPGA Editor always seems to "forget" that, for whatever reason.

BTW, I'm not sure if all of this works satisfactory with ISE6.1/6.2... When using XDL in ISE6, I always get a warning that "this is a new revision ncd, some features might be lost" or something.

As you can see, they are connected to the same TBUF in both bus macros. > BTW, do you know if the T input of a TBUF has to be "1" or "0" to be in high > impedance?

"1" disables the tristate buffer, so "1" for high impedance.

--
Best regards,
Sean Durkin
Reply to
Amaury Anciaux
Loading thread data ...

The tools still seem to have enormous problems with bus macros and all related things... The thing that irritates me most is that in your case it was always the same bit that did not get routed, so that's why I assumed there was something wrong with the macro.

Haven't tried... A colleage of mine once tried implementing a macro with LUTs, i.e. do the routing without longlines and TBUFs, and use the slice's Inputs/Outputs as the macro ports. That only works for CLBs directly adjacent. But he said par always crashed in that case. couldn't wuite cope with those manually routet nets... That was par from ISE5.2, though, maybe it works now in ISE6.

Best regards, Sean Durkin

Reply to
Sean Durkin

route the concerned signal to a "pip" further to the left, the design finally routes. So it seems that the PAR needs to have that first part of the path to route the signal.

bus macro, without TBUFs, just to be sure that the signal passes through the same nets, will it work?

I am sure the given bus macro is not the only solution...you may try build a BM with two registers or only four TBUFs, thus only occupies two slices...but the principle of no-crossing of two adjacent module is compulsory...The TBUF is intended to as a precaution for contention I guess...Am I right?

Kelvin

and

final

high

Reply to
Kelvin

That's what I think too. I tried to make a BM without any component but wires, but it doesn't work, the compiler XDL wants to route only wires that link instantiated components. It's a bit a waste of space to use TBUFs because the majority of the signals won't change of direction in the design, but for now I don't have any other solution.

Amaury

the

a

no-crossing

modules,

macros.

in

Reply to
Amaury Anciaux

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.