EDK : FSL macros defined by Xilinx are wrong

[Benjamin Todd]

Thanks everyone for the help!
I'll let you know when I get something going =)
Ben
"Antti Lukats" <antti@openchip.org> wrote in message
news:dju0f3$gg9$1@online.de...

"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch
schrieb im Newsbeitrag news:djkmeg$mdo$1@sunnews.cern.ch...
I know this isn't exactly comp.arch.cpld...

does anyone know of a COTS solution for programming a (Xilinx) CPLD
without using PC + Windows + Impact etc etc. (a stand alone chunk of
hardware with a way for me to give it a set of bit files and a Program
button would be nice)

small uclinux modules sell for less than 100EUR.
it takes a few hours to get XSVFplayer to work there.
I use it in desing to program the XC9572XL, the mdoule we used was from
www.dilnetpc.com coldfire based,
but the production has not changed to use small fpga linux modules
(microblaze uclinux)
www.hydraxc.com

antti

 

[Jonathan Bromley]

On Tue, 01 Nov 2005 17:28:00 +1100, Mark McDougall
<markm@vl.com.au> wrote:

Warning #1034: X"1F" width 8 truncated to width 5 in assignment.

Here's the deal: The hex notation X"1F" etc was a hack introduced
in VHDL-93 to answer users' concerns that they wanted a simple way
to write hex literals of vector type.

<rant>

The "right" way to do it,
of course, is...

...
use ieee.numeric_std.all;
...
signal vec: std_logic_vector(4 downto 0);
...
vec <= std_logic_vector(to_unsigned(#16#1F#, vec'length));

but that's kinda clumsy, and for some reason no-one ever
gets around to writing this rather trivial procedure:

procedure copy_int_to_slv_signal (
signal v: out std_logic_vector;
n: in natural
) is
begin
v <= std_logic_vector(to_unsigned(n, v'length));
end;

so that I can now write

copy_int_to_slv_signal(vec, #16#1F#);

</rant>

So the VHDL-93 writers gave in to popular opinion, but tried
to do it without adding too much hidden magic. Consequently
they invented a rewriting rule such that the hex literal X"1F"
is simply macro-substituted with the string literal "00011111"
(each hex digit is replaced with four binary digits in the string).
This of course allows type-compatibility of a hex literal with
any vector whose element type includes the literals '0' and '1',
correctly matching BIT, STD_LOGIC_VECTOR and UNSIGNED among others.
But it forces any hex literal to have a multiple of four bits.

Note that std_logic_textio similarly requires all its
std_logic_vector objects to be a multiple of four bits when
reading or writing in hex.

It really isn't a big deal. Program your way around it by
building a sensible set of application-specific utility
functions and procedures.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Mark McDougall wrote:

Mike Treseler wrote:

I can tolerate
foo(4 downto 0) <= "11111"; -- or
foo(4 downto 0) <= "1" & x"F";
to get compile time width checking
on all vectors.

Warning #1034: X"1F" width 8 truncated to width 5 in assignment.

Yes.
Your example has a width mismatch.
Those above do not.
Try it and see.

-- Mike Treseler

 

[zcsizmadia@gmail.com]

There are more CRCs in a ethernet packet:

1. PHY level. The very last 4 bytes. In linux ifconfig will show you
the number of packet errors on a NIC. Ethereal won't detect it because
the network driver throws away the packet if it's bad. Some driver
won't even generate interrupt for bad packets, in that you cannot see
the error unless you recompile the driver and enable interrupts for bad
packets.

2. CRCs in IP headers. ethereal will detect it.

Zoltan

 

[Mike Treseler]

ashwin wrote:

One of the member in this group recommended not to see the data
coming out of the ETHERNET phy , since its at 125 mhz and its not
being detect correctly using a scope.

Yes. Look on the data side, not the line side.
Scrambling will make an idle link look the
same as a busy one.

-- Mike Treseler

 

[Gavin]

I run tethereal for all my packet analysis. Two options to use:
tethereal -x -i eth0 (or whatever your interface is) - complete data
dump
tethereal -V -i eth0 (or ...) - protocol level dump

I believe tethereal will give you invalid FCS (CRC) packets.

A sample ethernet packet from 08:00:46:63:ca:e3 with destination
00:13:20:0a:25:db is here. The first byte on the wire is given first -
so transmit the MAC address bytes from left to right. Bits 0-3 go first
on the wire, 4-7 afterwards

0000 08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10 ..Fc....
..%...E.
0010 00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
..t>.@.@..S...@..
0020 11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
..+.......e.F.I..
0030 0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
...6.......\T(..o
0040 69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
i.p.....)..S....
0050 e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
..F....m...c.YwJu
0060 e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
........:....A...
0070 13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
......0C..b...1.d
0080 43 9b C.

It is probably best to start out broadcasting packets for your tests -
send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
Also it is worth writing ethernet rx before tx - make sure you can
receive packets with the correct FCS from the wire, and then you can
get your tx to work with your known working rx code.

Anyway, a packet to your destination address from MAC address
01:23:45:67:89:a0 with total packet length including MAC addresses and
FCS, with other content 00, is...

00 01 80 3f 6c e6 01 23
45 67 89 a0 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 75 78 03 93

 

[ashwin]

Hello Gavin,
Thanks for sending an ethernet packet which includes my destination
address.
Does the last 4 bytes represent CRC of all the data.
You didnt inlude the length/type, 2 bytes , which comes after source
address. I guess we need to compute the crc for that also.

Please check and advice

thanks
ashwin



Gavin wrote:

I run tethereal for all my packet analysis. Two options to use:
tethereal -x -i eth0 (or whatever your interface is) - complete data
dump
tethereal -V -i eth0 (or ...) - protocol level dump

I believe tethereal will give you invalid FCS (CRC) packets.

A sample ethernet packet from 08:00:46:63:ca:e3 with destination
00:13:20:0a:25:db is here. The first byte on the wire is given first -
so transmit the MAC address bytes from left to right. Bits 0-3 go first
on the wire, 4-7 afterwards

0000 08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10 ..Fc....
.%...E.
0010 00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
.t>.@.@..S...@..
0020 11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
.+.......e.F.I..
0030 0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
..6.......\T(..o
0040 69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
i.p.....)..S....
0050 e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
.F....m...c.YwJu
0060 e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
.......:....A...
0070 13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
.....0C..b...1.d
0080 43 9b C.

It is probably best to start out broadcasting packets for your tests -
send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
Also it is worth writing ethernet rx before tx - make sure you can
receive packets with the correct FCS from the wire, and then you can
get your tx to work with your known working rx code.

Anyway, a packet to your destination address from MAC address
01:23:45:67:89:a0 with total packet length including MAC addresses and
FCS, with other content 00, is...

00 01 80 3f 6c e6 01 23
45 67 89 a0 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 75 78 03 93

 

[Gavin]

Ethereal will happily receive the above packet - it will tell you all
sorts of errors about it, though... Don't worry about the length etc
until you can get a blank packet correct. If you can do that, then you
should have the FCS code all working, and you are at a different debug
level.
The last 4 bytes are FCS.

 

[Jeremy Stringer]

Gavin wrote:

It is probably best to start out broadcasting packets for your tests -
send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
Also it is worth writing ethernet rx before tx - make sure you can
receive packets with the correct FCS from the wire, and then you can
get your tx to work with your known working rx code.

I'd second that - the lazy way to work this out is to instrument the
image on the rx side (ie using something like chipscope), transmit some
packets on the network, and see if it matches what you expect. It can
be easy to to get caught out. You can then write a simple state machine
to dump the data you saw on the rx side out the tx side.

The rx side is easier to get working first, since you can:
a) Get your crc code right first by checking crcs on recieved packets
(quite likely to be correct)
b) You can then simulate a loopback situation to check that your rx crc
code and tx crc code match
c) It forces you to recheck your assumptions on nybble/byte ordering,
since if what you expected was different from what you recieved from the
packet, then you're probably wrong

Also, if your crc code is incorrect, it's easier if you have a 'golden'
source, as you can then run simulations or a c program using a known
good piece of code (from a bsd kernel or something like that) to see
where you went wrong. It helps to localise the error if you are using a
known good source.

My 2c,
Jeremy

 

[Mark McDougall]

Mike Treseler wrote:

Yes. Your example has a width mismatch. Those above do not. Try it
and see.

Not quite sure what point you're making here Mike?!?

Anyway, to kill the thread, let's agree to disagree. I come from a
software background, which might explain why I'm lazy and spoilt with
feature-rich languages and powerful pre-processors.

Regards,
Mark

 

[I. Ulises Hernandez]

Hello,

I developed a wee Gigabit MAC but with quite a different setup, Virtex 2 Pro
(with my MAC + Internal MGT - 16 bit wide @ 62.5MHz) + Copper SFPs (with
embedded Marvell 88E1111 in SGMII mode) <=> PC

I did use Ethereal, and noticed that crc errored packets were filtered out,
not sure if it was the SFP, the PHY in the PC or the PC driver, I'm positive
that packets were not getting to Ethereal at all. I also noticed that
packets smaller than 64 bytes were also filtered out and I am pretty sure it
was the Driver in my PC.

For testing I used a ping frame...

--=============================================--
--IP DA (192.168.0.85 : c0.a8.00.55)
--IP SA (192.168.0.33 : c0.a8.00.21)
--Header Length & IPv4 = x"4500"
--IP Datagram = x"0800"
--SA = 12.34.56.78.9a.bc (it doesn't really matter)
--DA = 00.0d.88.b5.88.71 (change it to yours, it doesn't really matter in
promiscous mode)
--=============================================--

constant C_GBE_DATA : word32_array(18 downto 0) :=
(
X"68697071",
X"64656667",
X"77616263",
X"73747576",
X"6f707172",
X"6b6c6d6e",
X"6768696a",
X"63646566",
X"04006162",
X"485c0100",
X"00550800",
X"0021c0a8",
X"96b3c0a8",
X"00002001",
X"003c8247",
X"08004500",
X"56789abc",
X"88711234",
X"000d88b5"
);

Bytes go out like: 00 - 0d - d8 - b5 - 88 - 71 ...

FCS for the packet above => X"257eaf61"

On thing I recommend is using loopback if your PHY supports it, and also the
internal CRC if the PHY provides one (just for testing) before trying to
send packets to your PC.

Regards,
--
Ignacio Ulises Hernandez
" I'm not normally a praying man, but if you're up there, please save me,
Superman!" - Homer Simpson ;O)




"ashwin" <achiluka@gmail.com> wrote in message
news:1130865877.899697.324060@g44g2000cwa.googlegroups.com...

Hello everyone,

I am sending an ethernet packet(64 bytes) from the fpga to the PC
in order to test the ETHERNET PHY chip onboard.
The interface from the fpga to the ethernet PHY for the data is 4
bits.

My PC mac address is 00-01-80-3F-6C-E6

a)So should i send the LSBs first like
in this order, 6,E,C,6,F,3,0,8,1,0,0,0 or the MSBs first


b) I have installed ethereal software on my PC and i am unable to
detect the ethernet packet in it.
1) I am pretty sure my CRC is wrong for whatever data i have, so
can ethereal still detect even when crc is wrong?

2)i used the scope , and i am able to see some data going from
fpga to the ethernet PHY. But the nothing gets detected in the PC. What
could be the reason?

One of the member in this group recommended not to see the data
coming out of the ETHERNET phy , since its at 125 mhz and its not
being detect correctly using a scope.


3)Can anyone compute the crc check for whole ethernet packet for which
my destination addres is as above? Data doesnt matter,it can be any
value.?Source address also doesnt matter, since it is fpga mac address.

4) Can anyone guide me on hardware implementation of crc using
vhdl

 

[Jan Panteltje]

On a sunny day (2 Nov 2005 07:56:39 -0800) it happened air_bits@yahoo.com
wrote in <1130946999.695784.287900@g14g2000cwa.googlegroups.com>:

Project released a beta based on an enhanced TMCC, and is looking for
help
to bring FpgaC up to a production stable level.

Home page at http://fpgac.sourceforge.net/
Project page at http://sourceforge.net/projects/fpgac

Interesting.

here is something to think about from the libc.info from gcc C.
maybe you already support these?
I recently found out it is better to use these in C then 'int' and 'short',
as some programs I wrote stopped working when compiled on AMD 64....
(header file structures with 'int' and 'short' and 'BYTE' ).

Integers
========

The C language defines several integer data types: integer, short
integer, long integer, and character, all in both signed and unsigned
varieties. The GNU C compiler extends the language to contain long
long integers as well.

The C integer types were intended to allow code to be portable among
machines with different inherent data sizes (word sizes), so each type
may have different ranges on different machines. The problem with this
is that a program often needs to be written for a particular range of
integers, and sometimes must be written for a particular size of
storage, regardless of what machine the program runs on.

To address this problem, the GNU C library contains C type
definitions you can use to declare integers that meet your exact needs.
Because the GNU C library header files are customized to a specific
machine, your program source code doesn't have to be.

These `typedef's are in `stdint.h'.

If you require that an integer be represented in exactly N bits, use
one of the following types, with the obvious mapping to bit size and
signedness:

* int8_t

* int16_t

* int32_t

* int64_t

* uint8_t

* uint16_t

* uint32_t

* uint64_t

_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account

 

[Brian Dam Pedersen]

Keep away from gated clocks until you know how a clocked system works. I
would recommend to start at http://www.answers.com/sequential%20logic
for an introduction.

-- Brian

mice wrote:

My head is spinning...
One should only use one of the edges in a clock domain, right?

But if I have a memory read set up at "posedge clk".
verilog ex.

always @(posedge clk)
ram_adress<=8'h00;

Where do I do the acual reading of the result of this if I'm not
allowed to use the negedge of the clock?
Having another "always @(posedge)" for the reading doesn't make any
sense to me.
Could any kind soul explain this to me? Please.

Also I've searched the forums regarding gated clocks, but couldn't
find any info about it (thought I did a while ago, but it seems to be
lost).
How do I go about creating a clock with half of the frequency of the
clock coming in to the fpga?
This is how I do it now, and that's not right, is it?
[code:1:faaa777181]
reg px=1'b0;
always @(posedge clk)
begin
px<=px+1'b1;
end
assign pixelClock=px;
[/code:1:faaa777181]
Also, I create more clocks in the same way, with different phases
(using both the pos- and negedge).

If someone could point me in the right direction I would be very
pleased.

Cheers!
((mice

 

[Symon]

"mice" <miti0200@student.miun-dot-se.no-spam.invalid> wrote in message
news:edudncK3N_3AafXeRVn_vQ@giganews.com...

My head is spinning...
One should only use one of the edges in a clock domain, right?

But if I have a memory read set up at "posedge clk".
verilog ex.

always @(posedge clk)
ram_adress<=8'h00;

Where do I do the acual reading of the result of this if I'm not
allowed to use the negedge of the clock?
Having another "always @(posedge)" for the reading doesn't make any
sense to me.
Could any kind soul explain this to me? Please.

Dear Rodents,

I sold my soul long ago, and even then it wasn't kind! However, I'll try and
help. OK, it's important your clock has very little skew. This means it
arrives at all the FFs at the same time. Fogs provide a special low skew
feature for this purpose. Look for BUFG on Xilinx's website. Also, it's
important that your FFs have short hold times. You'll find FPGAs' FFs are of
this type. This means you can use the rising edge of your clock to clock all
the FFs in your design, without getting race conditions and the like. The
delay from one FF to the next is enough to meet the hold condition, provide
your skew is low enough. If your clock is too fast, or the delays too long,
you won't meet the setup condition, but that's another subject...
HTH, Syms.

 

[Symon]

Fogs = FPGAs. Bloody spell-checker.

 

[Jochen]

Hi seb_tech_fr

May I use a DCM, and look at the LOCKED signal?

Would not help: you'd need 3 valid input clock-cycles before releasing
DCM's reset (at least for Spartan3) - so knowing that you have 3
valid input clocks means, that you already know that the clock is
valid.

Perhaps, you could build a statemachine: periodically reset the DCM for
some ns and waiting for some ms for the DCM to lock (have a look
at the datasheet for worst case timing) and re-apply a reset if DCM
hasn't locked yet (but you would need a reference-clock for the
statemachine)...

But if you have a reference-clock, you could use this clock for one
counter that periodically resets a second counter driven by your
input-clock: define your input clock as valid as soon (as long) as the
second
counter is within a specific boundary just before he sees the very next
reset..


Hope, I didn't describe my idea too complex...

Cheers
Jochen

 

[Andy Peters]

mice wrote:

My head is spinning...
One should only use one of the edges in a clock domain, right?

But if I have a memory read set up at "posedge clk".
verilog ex.

always @(posedge clk)
ram_adress<=8'h00;

Where do I do the acual reading of the result of this if I'm not
allowed to use the negedge of the clock?

The question you're asking is, "when is the read data word available?"
If it's a synchronous RAM, then your answer has to be "on the next
rising edge of the clock." If it's an asynchronous RAM, then the
answer is, "do a timing analysis," but the usual method is to choose a
clock frequency such that the read data word is available on the next
rising clock edge.

Having another "always @(posedge)" for the reading doesn't make any
sense to me.
Could any kind soul explain this to me? Please.

It's actually the simplest way to do it. Of course you could read the
data (from an async RAM) on the falling edge of the clock, but you have
to ensure that the data are valid at that time.

Also I've searched the forums regarding gated clocks, but couldn't
find any info about it (thought I did a while ago, but it seems to be
lost).
How do I go about creating a clock with half of the frequency of the
clock coming in to the fpga?

In a modern FPGA, use one of the built-in clock divider/multiplier
blocks. They're free and they work.

-a

 

[Peter Alfke]

This is easy if you have a continuously-running clock somewhere.
If you don't, you can easily detect when the clock starts for the first
time after power-on ( have the clock advance a 2-bit counter that you
had reset during power-on.)
But if you also want to detect if the clock has diappeared later on,
you need some timing element somewhere.
There is no mystery, it's all very logical, and your sharp Gallic
analytical mind will understand that...
Cheers
Peter Alfke, Xilinx

 

Jan Panteltje wrote:

Interesting.
here is something to think about from the libc.info from gcc C.
maybe you already support these?
I recently found out it is better to use these in C then 'int' and 'short',
as some programs I wrote stopped working when compiled on AMD 64....
(header file structures with 'int' and 'short' and 'BYTE' ).

The native types, including long long as 64 bit, are in the parser and
emit the expected word length. The current net list generator only
builds signed values which are width+1 in size. Properly implementing
unsigned is part of the next pass work at bring FpgaC inline with
expected normal C implementations.

One of the interesting parts of FpgaC is that

int VeryWideInt:512;

will build a 512 bit plus sign integer ... which doesn't make a very
fast counter, as the carry tree is pretty slow, but you get the
precision asked for.

typedef is also currently missing from FpgaC's parser, and will be
added soon so that standard header files can also be imported into an
FpgaC project.

 

[Eric Smith]

Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com> writes:

If the number we presented is not satisfactory, we have several
ideas to reducing the LUT count such as:

* Using multiplexer instead of internal tri-state buffers for
configuration register part of the PCI IP core

Will that help? Don't the synthesis tools translate use of tri-state
buffers into multiplexers on most of the newer Xilinx FPGAs anyhow,
since the parts don't have actual tri-state buffers?