fpga4fun.com

Hi, Mariusc,

Could You send me the project files You are using. My ISE full version throws million error mesages when I try to convert it and adapt to xilinx.

does sync1 work? Does it reach all 1's state?
It needs to for sync2 to start.

2N2222 are just fine.
Anyway this 48MHz oversampling business is not so great, I'll try to improve it.

Mariusc,

No I received some other error message when I included Coregen fifo and dpram, but that is an ISE bug I think. So I simply cut the fifo and dpram, an I am trying to adapt interface to FTDI245BM chip ( fifo-usb from WWW.ftdichip.com) which I have in the form of a ready-made module (www.dlpdesign.com)

Stijena

Mariusc,

I have problems with opening Your rar file. Could You post it as a zip?

Stijena

ok, so you need to debug the logic before "sync1". You are not able to extract the bits.
"new_bit_avail" should toggle at 10MHz, in sync with each incoming "Manchester decoded" bit.
Also make sure your diff input circuit works fine and that it outputs a square signal during the preamble (output ratio 50%).

Marius,

I tried to sinthesize the project You sent me (with no alterations), and I have some 50 warnings of unconnected internal signals or some signals being constant. The problem is as I suppose some sintax issue in ISE. I don't have enoug knowledge to solve the problem, but all warnings do have implications in the sinthesized design. I looked into the fpga interconnections, and constants are really tied to gnd or vcc; according to warnings.

Conclusion: design does not reflect the source


Predrag

PS: The files one You sent me contain only receive part.

no each family has its own set of output options. Newer families tend to support more standards.

Happy to hear that, the receiver part is not the easiest to get working in its current form.
Feel free to send the html once you have your page ready, we'll find a nice place for it.

Jean,

Why did You use 48MHZ clock for the manchester decoder. Could You explain the math more precisely.

Stijena

I wanted a frequency high enough to over-sample the Manchester encoded signal (50ns pulses).
I went through my stock and found a 48MHz. I drew a few timing diagrams and it seemed good enough with its 21ns period. I tried and it worked... No complex math involved!
You should be able to use a faster clock too. A slower clock may work but it will become unreliable if you go too low.

Jan,

Are You going to post some update on this 10base t topic

I had "allmost" full success with it so maybe Your new code could solve my problems.

I used a big cpld instead fpga (for the beginning, later I will transfer it on fpga). TXpart is working fine, and I also added possibility to send also ARP reply packets.

For the RX part, I took off the fifo and uart part, and am sending byte wide output to the FTDI245bm chip. I changed the manchester decoder to the one mentioned in xl17-30.pdf of xilinx (that is a schematic, but i translated it to verilog). The original didn't work properly.
For testing I use loopback between TX and RX both internal (no pins used), and external through ferrite trafo (salvaged from a NIC card).

The results are the same (erratic) so my analog part is ok.

All packets are identical, with lost or extra bits in same place of all packets. So there is a problem with framing which I cannot find.

My rx frequency is 67 MHz, and xiinx manchester decoder according to the article) tolerates everything from 50 - 120 MHz.

The question is : did You revise that part of the code, or any other.

Stijena

I'm still tied up with PCI these days. I should have more time for Ethernet in a few weeks...