Xilinx XST questions

Black boxing is relatively easy and seems to work.

Synthesise the module on its own - the only change to the normal flow I am aware of is that you MUST turn OFF insertion of IOBs for the module's external connections; obviously you want to connect them internally in the top level design.

Make sure the resulting .ngc file is available to NGDbuild at the "translate" stage; either in the main project directory or somewhere in the cores search path (see "Translate/Properties" if using the GUI)

Instantiate the module in the top level design and add a "box type" attribute set to "black_box" (for syntax see e.g.

Then when you run"Translate", NGDbuild should pick up the module's .ngc file and combine the two.

NOTE - this avoids synthesis optimisations; it is still possible for MAP to perform trimming...

I have typically used this approach to place complex RPMs in the top level of a design.

Hope this helps.

- Brian

Hi Brian

thanks for your answer. A question:

e.g.http://www.xilinx.com/support/answers/9838.htm

Actually, the black-box module is deep in the hierarchy. The hierarchy is something like:

level0: /top-level level1: /top-level/foo level2: /top-level/foo/bar

bar is the black-box module.

Does your answer apply for this case too?

Nikolaos Kavvadias

Hi

and something else. Is it possible to get timing analysis report for a final design which is assembled by:

- the design containing a black-box deep within the hierarchy

- the black box in some format (EDIF, VHDL netlist or even NGC)

I mean is it possible to run final timing analysis (e.g. after par) for the entire design (with the black-box included as proper).

Kind regards Nikolaos Kavvadias

|> |> 1) WHY does the synthesis for some combinations of read/write ports |> (it is fundamental parameter of my microprocessor) and some don't?

xst has a quite good log output during synthesis. It precisely describes what it synthesises at which line, and what gets eliminated for what reason. That may give a clue about the reasons. At least for me, xst was always right and I caused the problem...

yes, i agree ... i had the same feeling and behavior on some of my inference designs ... usually i could fix it by rewriting some pieces of the code (and thus not fulfilling the template) to get it to synthesize the logic i wanted ... although i must say it has improved a lot, nowadays i only get it when i try to do something with RAMB's...

kind regards,

Tim

Is your objective a hardware description for synthesis or or a netlist generator?

Maybe some of the dimensions line up cleanly with the block ram structures while others don't.

Maybe synthesis would do a better job if you gave it the whole problem. Do you prefer to generate the netlist yourself? I can only guess what synthesis will do with very simple designs.

Consider writing a clean hdl description using block ram templates and muxes and compare results with the present design. Some related examples:

Consider a code template rather than a black box. This gives synthesis some flexibility. The main advantage to clean synthesis code is that the synthesis and simulation models are the same thing.

No. Having a hot toddy at the holiday party ;)

-- Mike Treseler

Using a black boxed component with ISE should be as simple as pointing the tools at the macro file (ngc etc.) and having the associate component declaration in your VHDL module above that level. You may find some useful information in our TechiTip

John Adair Enterpoint Ltd. Home of Drigmorn1. The Low Cost FPGA Development Board.

it

caused

i'm afraid i have synthesized the multi-port register file alone as well as in a smaller context, and things there go well.

i'm pretty sure that problems arise due to it being deep in the hierarchy.

Kind regards Nikolaos Kavvadias

Hi,

what i didn't say is that the block RAMs are always matched properly at high-level synthesis time. It is when going down to low-level synthesis that ISE chooses to delete some of them.

Anyway, i now use instantiations as well in my multi-port register file generator. Now, the number of block RAMs is OK (none is deleted in low-level synthesis), still strangely some logic that is otherwise accessible is still being deleted.

So, now it is probably the time that we are stepping onto my problematic code ;). Probably that weren't visible yet although the processor would run properly about 10 firmware applications in both simulator and S3SK environment (S3SK without the big register file).

Still, i believe ISE has problems with elaborating code to an IR. I had to rewrite (either by hand or automatically) 4 times my code in order to see the correct number of BRAMs after low-level synthesis. All 4 cases work in simulation (GHDL).

Kind regards Nikolaos Kavvadias

The generator produces either generic RT-level VHDL code (BRAMs are inferrable) or VHDL code with block RAM instantations. I have a hand- written version with generates, too.

I'm sure that they actually do.

Nice examples, but i have written a really clean description.

This was my hope. I didn't want to mess with black-boxes , especially for something that is deep in the hierarchy. From a mental point of view (expanding and contracting the design port requirements not at the top-level) has problems. It could be doable, only if i was fixing all the affected entity declarations (the generic initial values for the number of read and write ports) throughout the design. I actually did this with Perl scripts, so there is no excuse for XST.

I also believe this in principle.

AAhhh, we don't have holiday parties here. We used to staff ourselves with tons of pork, beef, liver and brains on a January day :)

Kind regards Nikolaos Kavvadias

e.g.http://www.xilinx.com/support/answers/9838.htm

Yes

- Brian

After PAR, the black box IS included as proper. Translate (NGDbuild) does that, as I explained earlier.

- Brian