FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 02-19-2005, 05:48 PM
Antti Lukats
Guest
 
Posts: n/a
Default Antti Lukats: all my past live projects to be published...

Hi all

I re-found once again my own "Rules of Life" what I first published 21 aug
2001

1 No Promises.
2 Keep Promises.
3 Give away what you do not need.
4 Do what you want to do.
5 Be Happy.

In order to comply with Rules [5], [4] and specially [3] from the above
list, I am giving a promise (those braking rule #1) that I will make all
projects of my past live available as public domain. That includs all I can
publish (ie all that IP that belongs to me and is not covered by 3rd party
agreements), with the exception of maybe a few selected projects I am
actually working on at the moment.

In order to comply with [2] first project is made public today at:
http://gforge.openchip.org

there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing a
OPB 2 Wishbone adapter.

There seems to be still ongoing interest in OPB Wishbone wrappers so that
sounded like a good thing to start!

Antti

PS as per rule #2 there is no fixed timeline how fast I will upload the
projects, I started the process and will keep it going but it may take time



Reply With Quote
  #2 (permalink)  
Old 02-19-2005, 06:53 PM
newman5382
Guest
 
Posts: n/a
Default Re: 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

"Antti Lukats" <[email protected]> wrote in message
news:[email protected]
> Hi all
>
> I re-found once again my own "Rules of Life" what I first published 21 aug
> 2001
>
> 1 No Promises.
> 2 Keep Promises.
> 3 Give away what you do not need.
> 4 Do what you want to do.
> 5 Be Happy.
>
> In order to comply with Rules [5], [4] and specially [3] from the above
> list, I am giving a promise (those braking rule #1) that I will make all
> projects of my past live available as public domain. That includs all I
> can
> publish (ie all that IP that belongs to me and is not covered by 3rd party
> agreements), with the exception of maybe a few selected projects I am
> actually working on at the moment.
>
> In order to comply with [2] first project is made public today at:
> http://gforge.openchip.org
>
> there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing
> a
> OPB 2 Wishbone adapter.
>
> There seems to be still ongoing interest in OPB Wishbone wrappers so that
> sounded like a good thing to start!
>
> Antti
>
> PS as per rule #2 there is no fixed timeline how fast I will upload the
> projects, I started the process and will keep it going but it may take
> time
>
>
>



Reply With Quote
  #3 (permalink)  
Old 02-20-2005, 01:30 PM
TonyF
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

Antti Lukats wrote:

> Hi all
>
> I re-found once again my own "Rules of Life" what I first published 21 aug
> 2001
>
> 1 No Promises.
> 2 Keep Promises.
> 3 Give away what you do not need.
> 4 Do what you want to do.
> 5 Be Happy.
>
> In order to comply with Rules [5], [4] and specially [3] from the above
> list, I am giving a promise (those braking rule #1) that I will make all
> projects of my past live available as public domain. That includs all I can
> publish (ie all that IP that belongs to me and is not covered by 3rd party
> agreements), with the exception of maybe a few selected projects I am
> actually working on at the moment.
>
> In order to comply with [2] first project is made public today at:
> http://gforge.openchip.org
>
> there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing a
> OPB 2 Wishbone adapter.


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

Reply With Quote
  #4 (permalink)  
Old 02-20-2005, 02:48 PM
Falk Brunner
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"TonyF" <[email protected]> schrieb im Newsbeitrag
news:Wp%Rd.1219$%[email protected]

> 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



Reply With Quote
  #5 (permalink)  
Old 02-20-2005, 03:11 PM
newman5382
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

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


"TonyF" <[email protected]> wrote in message
news:Wp%Rd.1219$%[email protected]
> Antti Lukats wrote:
>
>> Hi all
>>
>> I re-found once again my own "Rules of Life" what I first published 21
>> aug
>> 2001
>>
>> 1 No Promises.
>> 2 Keep Promises.
>> 3 Give away what you do not need.
>> 4 Do what you want to do.
>> 5 Be Happy.
>>
>> In order to comply with Rules [5], [4] and specially [3] from the above
>> list, I am giving a promise (those braking rule #1) that I will make all
>> projects of my past live available as public domain. That includs all I
>> can
>> publish (ie all that IP that belongs to me and is not covered by 3rd
>> party
>> agreements), with the exception of maybe a few selected projects I am
>> actually working on at the moment.
>>
>> In order to comply with [2] first project is made public today at:
>> http://gforge.openchip.org
>>
>> there is OPB I2C IP-Core that uses the OpenCores I2C Core by implementing
>> a
>> OPB 2 Wishbone adapter.

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


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



Reply With Quote
  #6 (permalink)  
Old 02-20-2005, 03:15 PM
TonyF
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

Falk Brunner wrote:

> "TonyF" <[email protected]> schrieb im Newsbeitrag
> news:Wp%Rd.1219$%[email protected]
>
>
>>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.


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

Reply With Quote
  #7 (permalink)  
Old 02-20-2005, 03:42 PM
TonyF
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

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

Reply With Quote
  #8 (permalink)  
Old 02-20-2005, 04:14 PM
newman5382
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"TonyF" <[email protected]> wrote in message
news:rl1Sd.1774$%[email protected]
> 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


Reply With Quote
  #9 (permalink)  
Old 02-20-2005, 04:47 PM
TonyF
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

newman5382 wrote:

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


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

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


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

Reply With Quote
  #10 (permalink)  
Old 02-20-2005, 04:57 PM
newman5382
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"newman5382" <[email protected]> wrote in message
news:[email protected] ...
>
> "TonyF" <[email protected]> wrote in message
> news:rl1Sd.1774$%[email protected]
>> 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


Reply With Quote
  #11 (permalink)  
Old 02-20-2005, 08:12 PM
Falk Brunner
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"TonyF" <[email protected]> schrieb im Newsbeitrag
news:ZX0Sd.1675$%[email protected]

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



Reply With Quote
  #12 (permalink)  
Old 02-20-2005, 11:43 PM
newman5382
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"Falk Brunner" <[email protected]> wrote in message
news:[email protected]
>
> "TonyF" <[email protected]> schrieb im Newsbeitrag
> news:ZX0Sd.1675$%[email protected]
>
>> > 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




Reply With Quote
  #13 (permalink)  
Old 02-20-2005, 11:54 PM
Falk Brunner
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"newman5382" <[email protected]> schrieb im Newsbeitrag
news:[email protected] ...

> 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



Reply With Quote
  #14 (permalink)  
Old 02-21-2005, 08:41 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

"newman5382" <[email protected]> schrieb im Newsbeitrag
news:[email protected] m...
>
> "newman5382" <[email protected]> wrote in message
> news:[email protected] ...
> >
> > "TonyF" <[email protected]> wrote in message
> > news:rl1Sd.1774$%[email protected]
> >> 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/E...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.













Reply With Quote
  #15 (permalink)  
Old 02-21-2005, 09:34 AM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"Falk Brunner" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
>
> "TonyF" <[email protected]> schrieb im Newsbeitrag
> news:Wp%Rd.1219$%[email protected]
>
> > 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




Reply With Quote
  #16 (permalink)  
Old 02-21-2005, 10:23 AM
Kim Enkovaara
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

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
Reply With Quote
  #17 (permalink)  
Old 02-21-2005, 02:37 PM
Marc Randolph
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

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

Reply With Quote
  #18 (permalink)  
Old 02-21-2005, 03:06 PM
Kim Enkovaara
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

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
Reply With Quote
  #19 (permalink)  
Old 02-21-2005, 03:28 PM
newman5382
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...


"Marc Randolph" <[email protected]> wrote in message
news:[email protected] oups.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


Reply With Quote
  #20 (permalink)  
Old 02-21-2005, 09:32 PM
Erik Widding
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

> 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

Reply With Quote
  #21 (permalink)  
Old 02-21-2005, 09:53 PM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

"Erik Widding" <[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> > 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.


Hi Erik,

YES and NO.

EDK can work as described, YES.
but the IO buffers are NOT inside the PCI logicore netlist!
----------------------------------------------------------------------------
------------------
XPCI_ADB0 : IOBUF_PCI33_3 port map
( O => AD_I0 , IO => AD_IO( 0), I => AD_O0 , T =>
_ADO_B );
----------------------------------------------------------------------------
------------------
PCI IO buffers for Xilinx OPB PCI core are instantiated in the VHDL code
as can be seen above and NOT inside the PCI logicore netlist!

and as of DDR SDRAM core there the _I _O _T is used as normal

DDR_DQ_o => DDR_DQ_o ,
DDR_DQ_i => DDR_DQ_i ,
DDR_DQ_t => DDR_DQ_t ,

Antti















Reply With Quote
  #22 (permalink)  
Old 02-22-2005, 05:44 PM
Erik Widding
Guest
 
Posts: n/a
Default Re: Antti Lukats: all my past live projects to be published...

> > 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.
>
> YES and NO.
> EDK can work as described, YES.
> but the IO buffers are NOT inside the PCI logicore netlist!
> PCI IO buffers for Xilinx OPB PCI core are instantiated in the VHDL

code
> as can be seen above and NOT inside the PCI logicore netlist!
> and as of DDR SDRAM core there the _I _O _T is used as normal


I think you have missed the point. I make absolutely no mention of EDK
IP.

First with respect to the PCI logicore, which if purchased from Xilinx
is provided with an EDF netlist, and a VHDL netlist (or as some would
say "structural VHDL") that instantiates this core netlist, the IO
pins, and a user configurable module. To use this entire package,
without editing any of the IP core from the vendor, which is delivered
as both VHDL and a netlist, one must do as I described. This still
requires some editing of the contraints that are provided by the
vendor, but only for location in the hierarchy.

Secondly, DDR SDRAM was cited as an example because separating out the
tristate buffer from the DDR register is counter to the architecture of
the FPGA. The IO cell in virtex2 contatains a tristate buffer and a
DDR register, each of which only exist in this type of cell. Breaking
off the tristate buffer from the DDR register does not provide for any
sort of meaningful improvement in the hierarchy. Rather, it confuses
the issue. Arguments for breaking the hierarchy at this point that
have been presented in this newsgroup are: using chipscope at the top
level of a hierarchy; or the creation of a vendor agnostic design.
Given that the signal between the DDR register and the OBUF, or the
IBUF and the other DDR register are not observable, as the wires simply
do not exist in the architecture, obviates the first argument. The
fact that the DDR register and the IO buffer are both vendor specific,
and vendor unique, obviates the second argument.

As the FPGAs get more encompassing IO structures, as with V4, it makes
more and more sense to bind the IO structures which will include shift
register, differential pins, etc, into the cores themselves. One is
kidding himself if he believes he can do a high performance and cost
effective design without expressly instantiating specific architectural
elements. The IO structures are no exception.

This is not to say what Xilinx did with the EDK and separating out
tristates did not make sense. It did, when specific IO pin types and
IO structures did not need to be called out from the underlying core.
For example, many people new to FPGAs and the coreconnect bus
architecture have started by using the GPIO module to interface to
their own IP inside the chip. This is a good example of where one may
want to use the same IP for on chip or off chip interconnect, and as
such, not binding the IO pins to the core results in one rather than
two cores being created.



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

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Worlds 1st FPGA Centric Portal goes LIVE!! [email protected] Verilog 0 08-04-2007 01:46 AM
Live Design Ev. Kit with Altera Cyclone Jarek Pawelczyk FPGA 0 01-01-2005 09:49 PM
Newbie Xilinx Question: How to keep past designs? Brad Smallridge FPGA 2 08-11-2004 01:21 AM
Nios II Going Live... Kenneth Land FPGA 58 05-26-2004 04:02 PM


All times are GMT +1. The time now is 06:59 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved