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

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

Hi, read my comments below.

> -----Original Message-----
> From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
> Behalf Of Mathias Johansson
> Sent: 31. januar 2002 20:01
> To: ethmac@opencores.org
> Subject: [ethmac] modelsim problems and BD-(mis)understanding
>
>
> Hello all,
>
> Today we finaly were ready to simulate our mixed-mode
> VHDL/Verilog-design,
> featuring the beloved Eth-core :-)
>
> However, beeing somewhat of a newbe using Modelsim (5.3 or something), we
> got into some trouble. The whole project compiles fine, but when
> we choose
> "Load Design" and select our testbench, the tool complains about
> components
> not found. Primarily the Generic_Tpram wants 2 instances of
> RAMB4_s16_s16,
> this is fine, I know there are behavioural models of this
> somewhere in the
> synopsys or Xilinx libraries, suppose it's just a matter of
> digging out the
> right code and compile into work-library. (Or should I expect
> more troubles
> than that?)

You're right. That is enough. If you don't use Xilinx FPGA (delete that
define
from eth_defines.v file), you won't need anything.

>
> But, a greater concern is the eth_wishbonedma.v-file. It instantiates
> 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
> stupid newbe
> misstake, we'd really like to get going with our simulations. :-)
>

This file is in the cvs. Perhaps you forgot to download it. It's function is
to
synchronize signals when going from one clock domain to another. I'm working
on
host interface (wishbone interface) that won't need DMA at all. It will
contain
both slave and master wishbone interface. That version won't need
eth_sync_clk1_clk2
file at all. Synchronization will be done in a bit different way.

> On another note while we´re at it: I don't fully understand the
> block-ram/BufferDescriptor buffer in the Eth-core. What exactly is stored
> there? Buffer Descriptors, right? Who writes them there, CPU or DMA core?
> Shouldn't BD's be in main memory together with packet data? Like this:
> (Addrs 0x123456): [BD-1] 16 bytes;[PACKET1 DATA];....
> [BD-n][PACKET-n DATA]
>

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.
At this moment things are like this:
CPU writes buffer descriptors (that are located in the ram within the core).
These buffer descriptors do NOT contain any pointers to the buffers. It is
enough
to put a DMA_RQ and DMA should know which data to provide (it contains it's
own
descriptors that need to be also programmed by the CPU). This DMA was
written having
in mind that ethernet core might be on the other side. I can write more here
but
it is really confusing and that is the reason I'm working on interface that
won't need
DMA at all.

So, here I'll write how things are going to be (I was planning to finish it
already but
I have some delay. I think it will be finished perhaps on Monday or max. few
days later):
- Buffer Descriptors (BD) will still be located within the core. The main
reason is that
  together with ethernet core other cores will be used and I don't want to
use WISHBONE
  resources to check if some buffer is ready to be send.
- BD are 2 times 32-bit big. First 16-bit is reserved for settings and
status, next 16-bits
  for length of the data, last 32-bits for pointer to the buffer that
contains the data.
- Checking if the BD is ready will occur internally. After a valid buffer is
detected, pointer
  would be read (again internally).
- Data is read from the memory pointed by the 32-bit pointer. Data is
read-in from that memory
  to the internal 8-word buffer. After buffer is full transmission starts.
Similar things happen
  when receiving frames.

> Or should we store ONLY packed data in system memory, and let CPU
> write the
> BD's to eth-core? Which adress is the "base address" of BD's?
> If I've understood this alternative correctly: the DMA then reads
> the next
> BD from the eth-buffer as needed, right, but the buffer says data
> should be
> read from system ram?

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.

>
> Thanx Igor, for a core which seems very well done. We're looking
> forward to
> getting it to work :-)

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

>
> Best regards,
> Mathias & Torbjörn

Best 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