Antti Lukats: all my past live projects to be published...

Thanks Antti! You are a very generous person. There is a philosophy that you reap what you sow. It will be interesting how this comes back to you.

-Newman

Just noticed that in your VHDL code you don't use inout ports, resulting in 200% bloating of a normal inout port declaration. I presume this is because XST is too lazy to parse inouts so that we have to do some kind of backend annotation alongside HDL programming, resulting in a not very elegant code.

This is probably the price to pay for such a cheap tool, so I should not really complain. Synplify will allow you to use inouts in sub modules, but it costs much more than XST.

TonyF

"TonyF" schrieb im Newsbeitrag news:Wp%Rd.1219$% snipped-for-privacy@newsfe4-gui.ntli.net...

Nonsense. XST can handle inouts quite good.

Regards Falk

There is a school of thought that all off chip IO should be inferred/instantiated at the top level, and not in sub-modules.

There is a school of thought that all off chip IO should be inferred/instantiated at the top level, and not in sub-modules.

-Newman

Only if they are at the top level. If they are in a sub-module, XST will complain about not finding the *_I, *_O and *_T ports in your sub-module (see my other post).

TonyF

In the end, everything is flattened and becomes top-level, but in your HDL code it is useful to have sub-modules for clarity, code maintenance and reusability. It should be obvious or possible to tell to a synthesis tool that your inout port in your sub-module really is an external port.

TonyF

It is not my HDL code.

Lots of things are judgement calls, and different people will choose differently. If I look at regular HDL (non-EDK) targeted code, if I see that all the primary I/O are defined in the top level, and not buried at some unknown level of the hierarchy, it gives me a warm fuzzy that the other person made some effort for other people to understand the flow of the design.

As far as your complaint about the XST synthesys tool, since I own a bunch of Synplicity stock, I think it would be best for me to not address that issue.

-Newman

The designer's HDL code should not target such low level. An inout is just that, an inout, not much to understand. In Xilinx FPGAs this will be inferred as an IOBUF that will provide the *_I, *_O and *_T ports. With other vendors or ASIC it might be inferred as something else (though equivalent).

I did try my code with Synplify (outside EDK) and I didn't have this problem. Nevertheless I still think EDK/ISE is a nice tool for project management/implementation and great value for money.

TonyF

TonyF, I looked at the code section in question. It appeared to be two IO lines SDA, SCL that were broken out into input, output, and tristate control. I did an I2C design a while back, and I found it convenient to break out the signals in a similar manner.

-Newman

"TonyF" schrieb im Newsbeitrag news:ZX0Sd.1675$% snipped-for-privacy@newsfe4-gui.ntli.net...

???? If you have ionout between modules that go not offside, XST can handle them too. But I wouldnt use inout inside the FPGA, there is no reason to do so and after all it will not translate in "real" tristates in newer FPGA families and uses up more ressources than seperate ins and outs.

Regards Falk

Falk,

From what I have seen, the problem is that platgen.exe (Part of EDK, not XST) is auto generating wrappers for the IP blocks. The auto-generated wrappers breaks out "inout" to *_I, *_O, *_T ports. It also generates a top level file where these signals are fed into instantiated IO blocks at the top level. My guess is that the program that autogenerates these files assumes that the user defined IP blocks conform to the _I, _O, _T convention, and XST complains when it sees incompatible connections..

-Newman

"newman5382" schrieb im Newsbeitrag news:Xn8Sd.104376$ snipped-for-privacy@tornado.tampabay.rr.com...

top

OK, this sounds like a different story. I didnt use EDK yet.

Regards Falk

"newman5382" schrieb im Newsbeitrag news:0s2Sd.104087$ snipped-for-privacy@tornado.tampabay.rr.com...

synthesis

port.

bunch

lines

I hope the above page answers the _I _O _T issue in full :) besides that there could be issues in my code, its old and was first attempt but proved somewhat functional, it has been tested with som real I2C devices (during that testing a bug in opencores i2c core was found)

Antti PS EDK is a 'beastie' there are some things that just have to made the way EDK expects them to be or major problems can occour.

"Falk Brunner" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

yes and no. XST can handle inout, YES , but:

1) for EDK the _I _O _T useage is required to be "EDK compliant" - this issue has nothing todo with XST inout handling 2) inout use with xilinx tools is an issue sometimes: the control port of ChipScope cores is a single port that is kinda inout as one wire has different direction, that causes very often problems, the chipscope cores are delivered as netlist and used with verilog/vhdl wrapper where the inout port is declared as unidir, this works, usually... sometimes it works better when the wrapper is defined as inout. I am just pointing out that there are cases where the 'inout' or not inout is an issue withing the xilinx toolchain

Antti

Usually it is a good style of coding not to use inouts inside the design. Especially if the design should be portable to different architectures and tools.

Usually IO-pads are implemented at the toplevel, especially in ASIC based designs where the IO-ring is generated usually with automatic tools. Also I have seen formal tools to choke with internal inout ports during RTL->gate verification sometimes.

--Kim

should not

modules, but

Is there a good reason for this school of thought?

Using that concept, when I go to take that top level and create a 4x version of it, I can't just create a new top level with a generate statement. Now I have to go edit a completely working design and convert all the inouts to seperate in's and out's. And if that original block is still being used in the original design, I now have two different versions of the exact same thing that I have to maintain.

Have fun,

Marc

Mainly ASICs are the reason. Many ASIC tools expect that the topmost level is used for IO-ring, test structures, plls etc. And that level instiates the real functional logic.

Also in that style it's easier to do technology indenepdent designs. For example if the IO-pads need to instantiated manually they are all in the same place, and only that code needs changes if FPGA vendor is changed. As far as I know DDR style IO-pads can't be inferred easily for example.

And for example in hierarchical ASIC design you can't easily move some cells from the already laid out hard macro to the toplevel etc. So they should be in the topmost level already, which is last one to be completed.

You generate a new toplevel that instantiates 4 versions of the core logic that has still the in and out ports separated. And then just recreate the IO-drivers in the new 4x toplevel. So you have only one functional logic block to maintain, and two different toplevel designs.

--Kim

I/O cells tend to be vendor specific. Grouping vendor specific items into specific areas rather having them scattered through out a design would seem to be a good thing. One reasonable place to collect the external I/O is at the top level. One project that was prototyped as a Xilinx FPGA, but slated for ASIC conversion instantiated I/O at the top level so the I/O cells could be easily swapped out with the vendor's ASIC I/O with a minimum chance of error. I have found that there are issues when you selectively flatten different sub modules when I/O are inferred within sub modules. It used to be that in some ASIC designs, there are test structures that link all the IO cells together, if these cells are scattered through the hiearchy, it is more difficult to chain them together. In addition, I guess there are designs that may or may not have external bidirect busses, and some with internal tristate busses. I personally do not like to see inout in the sub hierarchy if there are no (evil) bidirect busses.

Do what you want to do. If it makes sense to you, and you can justify it, go for it. Skill is knowing how to do it. Leadership is knowing what to do and why.

-Newman

this

Actually EDK can handle tristate buffers declared inside of a pcore. The syntax for the MPD is as follows:

PORT AD = "" , DIR=inout, VEC=[31:0], 3STATE=FALSE, IOB_STATE=BUF

This exists because some IP is very tightly bound to its IO pin type, such as PCI or DDR SDRAM. We requested this feature from Xilinx a few years ago specifically so that we could use the PCI logicore netlist inside of a wrapper in EDK, without hand editing the top level VHDL.

Regards, Erik.

--
Erik Widding
President
Birger Engineering, Inc.

 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234
  (web) http://www.birger.com