Is it easy to modify this PCI Bridge core to not bridge to a wishbone
interface? I want to connect my project directly into the PCI bus
without worrying about creating the bus controller, and I don't want
to pay Xilinx $2000 to use their IP for only 1 project for a year;
thats out rageous.

To me it is a total waste of space on the chip if you go
PCI->Wishbone->End Device, after all you need two wishbone bus
interfaces back to back.

If anyone has any tips for modifying the PCI bridge core to do what
I'm looking for, I'd really like to hear your suggestions!

Thanks

Dan

Me too actually!

I am working on just using the pci controller myself so if anyone has any
useful tips now that i am starting, please do tell.

Thank you

On Sun, 1 Aug 2004, Daniel R Guisinger wrote:

Dan,



$2000 is More than reasonable for a PCI core, in fact, it's peanuts,
especially given how much development work went into it. If you were a
developer of PCI cards, and used their PCI core that took hundreds of
manhours of development time to implement, in a product that you sold a
thousand of and made $300,000 for, the cost of the core insignificant. It's
not their fault or responsibility that you only want to use it for one
project that is not (I gather from what you've said) of any commercial
value. What incentive do they have to simply "give" it to you? They give a
LOT of IP away. Aren't the development tools for most of their parts
readily available for free on the web?

If it is not worth the $2k to you (and I certainly understand that, if you
are simply wanting to use it for a personal project), of course, that's
fine...but, so you get a prospective as to how much work it is to develop a
PCI core (and you are fortunate that there are now MANY examples out there
that you could copy from, when the Xilinx PCI core was first PCI core
developed, there were NO other examples to copy, it had to be done from
scratch), I suggest you consider spending the time to develop one of your
own...which would probably take you about 1/20th the time it took to develop
the Xilinx PCI core in the first place. That might give you a better idea
of how much work goes into developing such a thing, and it certainly would,
IMO, be a very beneficial educational experience if you want to design FPGA
code as a profession.

Now, as far as modifying the OpenCores PCI core to not use the Wishbone
interface, I suggest you simply download a copy of the core, and look at it.
Also helpful is the PCI spec, as it has the PCI protocol defined in it.
Between those two, you could figure out rather easily how much work it is to
do what you want (which is undefined from your post). BUT...keep in mind,
that ANY PCI core is going to have to have a back end interface, so whether
it's Wishbone or one of your own definition, it HAS to have one. The
back-end has to say when it's taken data, and when data is available to be
taken, and where the data comes from and goes to.

My suggestion would be to simply use the Wishbone interface. It will
probably be far less work in the long run.

Regards,

Austin

I wasn't seeking someone to respond like a complete ass and treat me like a little kid. I said $2000 PER PROJECT PER YEAR, yes, Xilinx charges a recurring fee license, is out rageous. If it were a matter of throwing Xilinx a 1-time $2000 fee I'd probably do it. And yes I do pay for subscriptions, I pay for MSDN. But you know what, thats because I want updates. I'm free to use it from Microsoft as long as I want without paying more as long as I'm satisfied with the version I already own. So I have plenty of ground to stand on when I say I disagree with Xilinx's licenses. At that rate one could easily pay to have someone custom code it within a matter of 2-3 years subscription. And yes, I have the PCI specs, and I have read through the PCI bridge source; however the core is quite large, knowing what needs to be changed once Wishbone is pulled off is difficult at first glance. So back to the original question, is there any kind person out there looking to have a constructive conversation on how to remove the wishbone interface from the PCI Core and what steps are needed to make it work once WB has been removed? -Dan ----- Original Message ----- From: Austin Franklinaustin@d...> To: Date: Mon Aug 2 04:03:59 CEST 2004 Subject: [pci] PCI Core without Wishbone Interface?

I don't need to waste my time giving advice to some ungrateful sod, when I
could be doing work that I get paid quite well for, or I could be spending
time with my family. It's behavior like yours that makes me not want to
bother. So, do your self a favor and don't behave so inappropriately. I
was hardly being disrespectful to you, and certainly didn't deserve your
entirely disrespectful reply.

Then don't reply AT ALL. Both your replies are totally insulting and have no
place on a list like this.

John

Dan,



If you took my reply as treating you like a little kid, I was not, and it's
not me whose being the "complete ass" here. It was treating you like
someone who, along with asking a question about the Wishbone core, IMO,
unreasonably "complained" about the price of buying a piece of, IMO,
reasonably inexpensive IP. This, to me, means you don't understand what is
involved in creating and supporting such a thing, and I was suggesting that
if you wanted to do FPGA work as a professions (it appears that FPGA coding
is not your profession, please correct me if I am wrong) you would benefit
from a better understanding, and suggesting a way for you to achieve that.
If that is not your goal, that's of course fine, then my suggestion doesn't
apply.

I don't need to waste my time giving advice to some ungrateful sod, when I
could be doing work that I get paid quite well for, or I could be spending
time with my family. It's behavior like yours that makes me not want to
bother. So, do your self a favor and don't behave so inappropriately. I
was hardly being disrespectful to you, and certainly didn't deserve your
entirely disrespectful reply.



That's your opinion, and I disagreed. I'm entitled to disagree, like it or
not. Someone can disagree with you and that doesn't necessitate your above
comment.



They have BOTH one use licenses and unlimited use licenses:

"There are site- and project-based versions of the license that vary only in
the scope of usage of the core. The site version permits unlimited use of
the core within a specific company site, while the project version limits
use to within a single project (which may include more than one site)."

It appears to me that you buy the one use license, and you can use it for
that one project ad-infinitum.

Also, you might consider looking into the PCI eval kits from Avnet and other
sources, and it comes with the core, and they are reasonably cheap. The
core is in the form of a netlist and a constraints file. As long as the
technology is the same, the core should be able to be re-used in another
part, with a new constraints file. But, the obvious thing is to just buy a
board that you can make good recurring use of for your projects, as changing
the constraints file (placement and pinout) may not make timing in a new
implementation.



Believe me, I was being kind, and I DID give you a constructive suggestion,
and did answer your question. I suggest you go back and see what I said.

You also failed to mention what you needed...target, burst, master etc., and
what your back end needs to interface to. Without that, it is difficult to
ascertain what would work for you.

There is nothing wrong with asking (and I did not begrudge you that at all),
but you did more than simply ask this question, and you know that.

Austin

Austin, Then we can agree to disagree. I'm not looking for a fight. I wasn't trying to be a jerk right back; however felt you unfairly targetted me in the first one just because you and I disagree on what is a fair price to pay for something. I actually am working on a Verilog project right now for FPGA that does pipelined codec conversion (G.726, GSM, etc); so whether you beleive it or not, I do know how complicated it is to get timing correct... one end of my design connects to a T1 controller with both a PCM Highway and a Intel style bus, both of which I've had to design and test against published transactional timing diagrams. My point on the Xilinx license is this: They sell hundreds of licenses a year easily. The one project license is $2000, the unlimited license is $7000. That I don't disagree with. But that is still a one year license. Each year you have to renew, I talked to their rep. I disagree with forcing someone to renew a license, even if all they are doing is continuing to produce a previous year's work. That is my major disagreement. I don't like hidden fees. What will it cost to make a project complete? With Xilinx its a moving number based on how long you plan on producing it. Say I have a need for a 2.1 compliant card, and never needed an upgrade to 2.2. Where is the justification for paying for a continous update when things worked fine before. But enough with arguing over what is just and injust as far as licenses go, on to what this whole thread was about because I'm sure we'd both like to put this behind us. In regards to your question, its for a PCI card, so it needs to be both target and master (target for configuration mainly). It needs mastering and burst capabilities to transfer from a 512K onboard cache to system memory. The back end bus is actually all custom, thats why I'm not in need of a wishbone interface; i'm not connecting to a previously designed core. Everything here is custom designed, and space on the 400K gate is becoming a luxury. Therefore, it makes more sense to tie into the PCI bus without worrying about two wishbone controllers (well, 4 really if you double up masters and slaves). I guess really what its doing is besides for configuration registers, its transfering data back and forth between the on-board buffer memory and system memory. Not a complicated design, it needs to generate a system interrupt at 1KHz (we are plugging into an open source PBX system called Asterisk which uses the interrupts for timing conferencing as well as knowing when a frame of data has been transfered) Sorry about the earlier remarks, I didn't take your previous comment as you expected and lashed back at you. -Dan ----- Original Message ----- From: Austin Franklinaustin@d...> To: Date: Mon Aug 2 07:08:57 CEST 2004 Subject: [pci] PCI Core without Wishbone Interface?

Dan,



I believe that your information is in error. I believe that once you buy a
version of the core, for your one project use, you have unlimited use of
that core, and only your ACCESS to the core on the Xilinx web site is
"terminated" after one year, not your ability to use what you already have.
I *may* be wrong, and I will find out.



As a note, though target is basically the same as configuration, there are
differences. You may also need the target to program the DMA (see below).



Most PCI cores (including the Xilinx one), though they provide master
capability, they do not provide the DMA. The DMA is typically "custom", so
keep in mind, you may have to provide that logic as well.



What OS you are using may influence your DMA architecture. I have typically
made scatter/gather DMA engines (the PLX-9080 offers a rather good DMA
architecture IMO), with the DMA linked list table kept in on-board memory,
and that increases speed significantly. NT typically only gives you 4k
transfers at a time, so for 512k, you would need 128 entries.

Also, what is your data rate? Do you need to run 33 or 66, and 32 or 64
bits? Keep in mind, the timing requirements for 66MHz PCI are difficult,
and you will need a rather fast speed grade. What technology FPGA are you
considering? Sounds like a Virtex 400?



Apology accepted.

Regards,

Austin

Ok, great to know.



Ok, yeah, we were targetting Linux primarly, but wanted to be able to operate on
Windows as well. Our competitor's board doesn't do the codec work and transmits in
4-dword blocks (seems inefficient to me, *shrug*) using bus mastering and bursting.




We are targetting a Spartan 3 - 400 on a 33MHz bus. Part of the memory is actually
being used for internal buffers, the buffer that transfers will probably more likely be
128K tops....64K down and 64K up. The total transfer per second in each direction is
16.384mbps (bits).

Hi Dan,


operate on


I don't now what the DMA driver requirements are for Linux, with respect to
amount of contiguous memory the driver can acquire. If you (or anyone else)
knows, I'd like to hear about it. As I mentioned, for Windows, you are only
guaranteed 4k blocks, so you need to accommodate this in your DMA, and keep
in mind the physical memory to logical memory mapping. Given your data rate
you stated below, it sounds to me like your driver could reprogram a very
simple DMA for each 4k block (signaled by using an interrupt, to do the
reprogramming of the address/length), instead of making a linked-list
scatter/gather DMA, which is quite a bit more work. Just watch out for
buffer copying in a driver, it *really* slows things up. You want to move
the data as little as possible.

Is there a driver available for the OpenCore PCI core? Also, is there any
DMA support for it well? The DMA is really the critical thing for the
driver IMO.



Spartan 3 does not work with 5V I/O without using something like
QuickSwitches, and for a 3.3V bus, you need to do some things, and there is
a rather extensive Xilinx application note on this. I'd suggest using a
3.0V (yes, 3.0V) regulator for the VCCO on the banks that are on the PCI
bus...all this is covered in the application work.



Quite slow, obviously. You could just about get away with a good target
burst implementation, but on an x86 machine, you are at the mercy of the
system PCI bridge, as to how it implements the transfer...as the x86 it self
will only do a 4 qword xfer as a burst, and the bridge may simply execute
that as four PCI target accesses, instead of combine them into one burst,
and you really have little control over that...though there are some
"switches" (not literally, but programmable, in the system PCI bridge chip
that turn this on/off on *some* chip sets) that you can get at, I'd not
recommend messing with that though. But given your data rate of 2M
bytes/second, using a target is certainly an option IMO, though a bit
buss-hoggy, so keep that in mind, as I don't know what else you have going
on simultaneously. Unless you need to do 2M in EACH direction
simultaneously, then, obviously, it's 4M bytes/second...still possibly
do-able with a decent target implementation.

I'm currently doing a superset of what you have outlined, with two 128M
buffers on a PCI-X 133 64 bit bus, except that my data comes from a hard
disk, so I have to keep that bus bandwidth in mind as well...though
typically, PCI-X busses are on different PCI busses, so the disk controller
shouldn't effect my card's PCI bus bandwidth, but it could effect the system
memory bandwidth. I have to transfer from disk to memory, then from memory
to the card, hopefully, using the same memory, as to avoid any buffer
copying. I've really got no choice but to use a scatter/gather DMA, and
keep the DMA table in on-board memory. For the two 128M buffers, that would
take 2 x 128M x 8 bytes/entry (4 address, 4 length) or around 256k bytes per
128M buffer scatter/gather table for 4k buffers.

I hope I've answered some of your questions (or future questions) on a PCI
interface, and given you some *useful* advice. I would be interested to
know how it works out for you.

Regards,

Austin