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

"TonyF" <not@valid.address> schrieb im Newsbeitrag
news:ZX0Sd.1675$%F6.1428@newsfe4-gui.ntli.net...

> > Nonsense. XST can handle inouts quite good.
>
> 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).

???? 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 Brunner" <Falk.Brunner@gmx.de> wrote in message 
news:37s7tfF5h3oanU1@individual.net...
>
> "TonyF" <not@valid.address> schrieb im Newsbeitrag
> news:ZX0Sd.1675$%F6.1428@newsfe4-gui.ntli.net...
>
>> > Nonsense. XST can handle inouts quite good.
>>
>> 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).
>
> ???? 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" <newman5382@yahoo.com> schrieb im Newsbeitrag
news:Xn8Sd.104376$JF2.1558@tornado.tampabay.rr.com...

>   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..

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

Regards
Falk

"newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag
news:0s2Sd.104087$JF2.54716@tornado.tampabay.rr.com...
>
> "newman5382" <newman5382@yahoo.com> wrote in message
> news:GP1Sd.96890$qB6.89122@tornado.tampabay.rr.com...
> >
> > "TonyF" <not@valid.address> wrote in message
> > news:rl1Sd.1774$%F6.772@newsfe4-gui.ntli.net...
> >> newman5382 wrote:
> >>
> >>> There is a school of thought that all off chip IO should be
> >>> inferred/instantiated at the top level, and not in sub-modules.
> >>>
> >>
> >> 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
>
> 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

http://wiki.openchip.org/index.php/EDK:Using_Tristate_Ports

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" <Falk.Brunner@gmx.de> schrieb im Newsbeitrag
news:37rj4hF5ea8fvU1@individual.net...
>
> "TonyF" <not@valid.address> schrieb im Newsbeitrag
> news:Wp%Rd.1219$%F6.1075@newsfe4-gui.ntli.net...
>
> > 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
>
> Nonsense. XST can handle inouts quite good.
>
> Regards
> Falk

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

TonyF wrote:

> 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.

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

newman5382 wrote:
> >
> > 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.
>
> 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

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

Marc Randolph wrote:

> newman5382 wrote:

>>There is a school of thought that all off chip IO should be
>>inferred/instantiated at the top level, and not in sub-modules.
 >...
> 
> Is there a good reason for this school of thought?

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.

> 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.

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

"Marc Randolph" <mrand@my-deja.com> wrote in message 
news:1108993065.915981.200990@o13g2000cwo.googlegroups.com...
> newman5382 wrote:
>> >
>> > 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.
>>
>> 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
>
> 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
>

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 

> 1) for EDK the _I _O _T useage is required to be "EDK compliant" -
this
> issue has nothing todo with XST inout handling

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