EDIF -> Map & Place -> EDIF ?

Hi,

This may sound like an odd thing to want to do, but is there anyway to take an EDIF file, have it mapped and placed and then turn it back into an EDIF file? Specifically I want to be able to do this targeting a Virtex FPGA.

The reason I want to do this, is that I'm developing a design in JHDL, which seems to provide a nice interface for placing blocks of logic. For example, I can write 'place(blockA, RIGHT_OF, logicB)'. The catch seems to be, that for this to work blockA and blockB have to already have all their internal wires and logic placed. While technically I could do this manually, it is infeasible for the project I'm working on.

So I'm hoping there might be some way I can take advantage of another feature of JHDL, which is the ability to parse and translate EDIF into a JHDL representation. Then perhaps there is some way I can have the EDIF placed for me by external tools.

Is it the case that I'm simply asking for the impossible, wanting to place blocks logic relative to other logic blocks in a reasonably high-level and abstract way when targeting an FPGA?

Thanks, Jake

Reply to
Jacob Bower
Loading thread data ...

Since you are targeting Virtex parts, you can use the Xilinx RLOC attributes to place your logic in a relative way. I know this can be done from VHDL and Verilog, but I know nothing about JHDL. Can JHDL provide attributes in a way that the Xilinx software can understand?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Rickman,

Ultimately, the place functions in JHDL map down to RLOC properties in the EDIF output. I could also explicitly annotate things with EDIF properties if I wanted.

The problem with using RLOCs directly, firstly is that (as far as I understand them anyway) they only let me place individual logic elements like flip-flops for example. They won't let me place a macro-block which contains two multipliers and an adder for example. Not at least without first manually placing all the sub-elements of the multipliers and adder anyway, which brings me back to my original problem.

The second problem is that RLOCs require relative co-ordinates specified in rows, columns and slice. This is useless if I want to say "put large logic A right of large logic B" or even perhaps "put small logic A and the bottom left hand corner of large logic B". In theory this should be possible in JHDL.

At least this is my understanding, please correct me if I am wrong.

- Jake

Reply to
Jacob Bower

Well, you are partly correct.

Everything you want placed has to have RLOCs down to the primitive. RLOCs are hierarchical (unlike most of the rest of the xilinx tools, but that is another story). You can construct larger macros out of smaller ones, by putting an RLOC on a placed macro. I use this capability extensively to build up large placed designs in relatively short time (you can see examples on the gallery page of my website at

formatting link
). The constructed macros are relatively placed within themselves, but the macro will 'float' allowing it to be picked up and placed absolutely either in floorplanning or automatically by the tools. VHDL permits computation of the constants used in attributes, which allows you to use the generate statement to construct macros out of primitives complete with relative placement.

Do>

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

Ray,

designs

at

Unfortunately this again brings me back to the crux of my problem, which is that in future I may have some macro blocks only available to me as EDIF. Manually annotating each primitive in the EDIF with RLOCs, really isn't feasible : ) Is there really no way at all that it is possible to use for example the Xilinx map and par tools to map and relatively place a design and then provide this in an EDIF form (possibly via some transformation utility)? If this really is impossible, is there some automated/programmable way I can modify a placed & routed design from the Xilinx tools, and then re-p&r them to take into account the changes? Thanks,

- Jake

Reply to
Jacob Bower

Hi Jake,

A different approach would be to use the Floorplanner feature which generates a reusable RPM core. You have the option of generating UCF constraints or a fully annotated core in NGC format (a binary file similar to the NGO file). Then as Ray mentioned you can add RLOCs throughout the hierarchy to further manipulate the relative placement.

formatting link

You also made a reference to reusing routing information. The Directed Routing feature in FPGA Editor can do this, also by generating UCF constraints. These two features are not incompatible with each other.

formatting link

Bret

Reply to
Bret Wade

I honestly don't understand your constraints. How do you plan to express your relative constraints if you don't want to put them in the EDIF file? What is your input format? Are you saying that you don't want to add the RLOCs, but rather you want the Xilinx tools to do it and then reproduce your original EDIF file with the RLOCs?

Perhaps you could explain your intended tool flow more clearly. Like Denzel Washington said in "Philadelphia", "explain it to me like I'm a 6 year old". :)

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

I have not used RLOCs in quite a while, but if they still work the way they used to, you can specify a group of logic and associate that to any rectangular area with an RLOC without specifying how any of the internal logic will be placed. The area does not even have to be a "tight" fit and IIRC, other logic can fit into any of the holes that result. An RLOC can be as specific or as lax as you choose to make it and it can be applied to a single element or to any group.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Bret,

Yes! this seems to be what I want to do thanks.

The only thing missing is annotating the EDIF file directly with the constraints generated by the Floorplanner in UCF format. I think I can probably manage writing a tool to do this though.

Thanks,

- Jake

Reply to
Jacob Bower

Rickman,

My problem was that I _do_ want the constraints in the EDIF file, but I wanted this automated for an arbitrary EDIF design which came with no RLOCs. So perhaps to clarify further what I really wanted was:

EDIF (no RLOCs) -> Map & Place -> EDIF (with RLOCs)

I can then use the EDIF with RLOCs in JHDL to place other components in a high-level/abstract way relative to the pre-placed design that was in the EDIF.

It looks like Bret Wade has now given me the missing link I need to achieve this in the form of the Xilinx floorplaner (See rest of the thread).

Thanks,

- Jake

Reply to
Jacob Bower

I'm glad you liked the idea. I'm not yet clear on why the RLOCs need to be annotated back into the EDIF netlist. An easier option would be to just copy the UCF constraints to an NCF file with the same name as the EDIF file. From a Xilinx tool perspective, that is identical to the constraints being in the netlist.

Bret

Reply to
Bret Wade

Bret,

My goal is to place some macro-blocks of logic near some other logic components, and I want to do this in a programmable/abstract way. In JHDL I can do this using an intuitive sounding function called place(). So I can do: place(a, IN_THE_MIDDLE_OF, b) for example. But in order to implement this, the JHDL system has to know the bounding boxes for a and b. The only way it can know this, is if a and b are already relatively placed. One way to achieve this would be to write everything in JHDL by hand and do all the placements for a and b (and their sub components) manually, but this would be tedious and restricts me to only using logic elements written entirely in JHDL.

Fortunately JHDL has an EDIF parser which will load in an EDIF file and turn it into JHDL logic. So this way I can make use of the Xilinx tools to do a thorough and reasonable job of placing all the large pieces of logic I can't be bothered to place manually, but still use the JHDL placement stuff. Then when I'm done with my complete system with the autogenrated RLOCs and the ones which I inserted manually (using place()), I can then get JHDL to spit out another EDIF which I can then turn into a FPGA bitfile.

So I need to annotate the EDIF file with the UCF file, as the JHDL EDIF parser does not support external annotations from a UCF file, and won't be able to do the relative placements if it doesn't have these details represented internally.

To be even more precise, having looked at the source code, it doesn't look like JHDL interprets the RLOCs either. But hopefully I can add this functionality, or I might even just get it to read the UCF and then annotate the JHDL representation of the logic anyway.

- Jake

Reply to
Jacob Bower

It doesn't work very well ... yet. I have a couple of webcases open on that, and hopefully Xilinx are working to fix some of the problems.

This MAY be possible. The floorplanner writes an UCF for the RPM, and (assuming that UCF works) can invoke "NGCbuild" to back-annotate the placement information into the proprietary NGC file from the XST synthesis tool. There is an "NGC2EDIF" tool which I have used to verify that the resulting NGC tool contained valid placement info from the above process

- its EDIF output did - while trying to debug the above approach.

So if you can convert from EDIF to NGC in the first place, there is the basis for a loop. I haven't tried the EDIF flow so can't comment, though it's interesting that NGC2EDIF is present but NGD2EDIF is now unsupported.

- Brian

Reply to
Brian Drummond

Brian,

Hmm, I'll just have to see in that case.

That could certainly save me some effort, so I'll investigate this.

Thanks,

- Jake

Reply to
Jacob Bower

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.