RE: [ethmac] modelsim problems and BD-(mis)understanding

["Igor Mohor" <igorm@opencores.org>]

Hi, Mathias,

please read my comments below.

> -----Original Message-----
> From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
> Behalf Of Mathias Johansson
> Sent: 2. februar 2002 21:09
> To: ethmac@opencores.org
> Subject: RE: [ethmac] modelsim problems and BD-(mis)understanding
>
>
> At 11:12 2002-02-02 +0100, you wrote:
> {snip}
> > > several components "eth_sync_clk1_clk2", which does not exist in our
> > > work-library. Is this also a standard component (from which
> > > library in that
> > > case?), or where can we find this model? I hope this is just a
> >
> >This file is in the cvs. Perhaps you forgot to download it. It's
> function is
> Oups, found it. You're right, we used an old download. Stupid newbe
> misstake after all.. :-)
>
> {snip}
> >Ok, here we go again :) From all those replies I got I realized that this
> >section
> >is the most confusing one. And you're right, it is.
>
> Indeed! :-) We'd hoped to get a grasp of all of this, when simulation
> began. However, as trouble stopped our progress, I felt I had to
> ask. Thank
> you for the explaination, I think I understand it now.
>
> >it is really confusing and that is the reason I'm working on
> interface that
> >won't need
> >DMA at all.
> >
> >I really suggest you hold your horses for few days so I can
> finish what I'm
> >doing. If you
> >still want to deal with DMA, I'll be happy to answer you what
> you asked. But
> >you don't want
> >to do that. If you do, then you need DMA engine that brings additional
> >variables in the design.
> >It's your decision after all.
>
> We'll certainly look out for the new version, it sounds like a good idea.
> We have already done a kind of a "packet" out of the Eth and
> DMA-cores, to
> be integrated with the GPL Leon-CPU. This means we'll have a "black
> box"-component in our project, and I think it could be a good idea to try
> out both variants, as they will look the same from the CPU's
> point of view
> anyway. The DMA could ofcourse be used as a general DMA-core in
> the system
> as well, but if the new ethernet MAC works fine, we'll reconsider it's
> usefulness. (Btw, for our purposes, a core using ARM's AMBA bus would be
> cool too :-) But hey, our approach is to use a kind of Wishbone-AMBA
> brigde, which should be good enough. After all, if all the work had been
> done already, there would be nothing left for us to do...

Acctually the difference between DMA on non-DMA host interface is that DMA
interface has only one WISHBONE hook (WISHBONE slave) and a lot of other
stuff.
Non-DMA on the other hand has both. And nothing of the unnecessary stuff (I
hope so).
If there are other cores in the design then perhaps DMA core is needed.

>
> One question though: when there will be two versions of the
> interface, will
> you support/update them both or will the DMA-version be dropped
> and become
> obsolete? Perhaps it's not that much of a challange to support both
> versions, as only the wb-interface module will be different. (or..?)

Well, at the moment I'm thinking of droping the DMA version. I'll put two
files on cvs with two different names and you'll set in the defines which
one to use.

>
> { }
> >I'm glad to hear this. Believe me that's exactly what I'm trying to do
> >(besides all the rest that
> >keeps me busy so much :) . I already got some replies that
> people put some
> >parts of this core to
> >hardware (transmit part or anything else). There are many teams that are
> >working on it. I hope I
> >won't be the last one to send a packet over the internet :)
>
> Our secondary goal is sample scale ASIC-implementation, so if everything
> works out, we might set up a box so you can ping your own core!
> Sweet huh? :-)

Oh, yes, please do that.

>
> Thank you very much for your reply, we may report on our progress
> if anyone
> is interested.
>
> Regards,
> Mathias

Regards,
	Igor

>
> --
> To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml