EDK : FSL macros defined by Xilinx are wrong

hi joey,

When you say "when i try to open the file i am not able to", what
happens?
the function returns -1 indicating failure to open the file.

How are you opening the files?
using the mfs_file_open("src.mnt", MFS_MODE_READ);

What flags are you using to generate image.mfs?
$ mfsgen -cvbfs imagemnt.mfs 30 mnt

mfsgen
Xilinx EDK 7.1.2 EDK_H.12.5.1
Copyright (c) 2004 Xilinx, Inc. All rights reserved.

mnt:
des.mnt 3072
src.mnt 3072
MFS block usage (used / free / total) = 14 / 16 / 30
Size of memory is 15960 bytes
Block size is 532
mfsgen done!

Are you using a PPC or microblaze?
PPC

One more thing to try is sticking a small (few chars) txt file in your
file system and see if you can peek at it with XMD to see the correct
values.
created dow.txt with the content "dow TestApp_Memory/executable.elf"

then created the imagefile as below
$ mfsgen -cvbfs dummy.mfs 30 mnt
mfsgen
Xilinx EDK 7.1.2 EDK_H.12.5.1
Copyright (c) 2004 Xilinx, Inc. All rights reserved.
mnt:
dow.txt 35
MFS block usage (used / free / total) = 3 / 27 / 30
Size of memory is 15960 bytes
Block size is 532
mfsgen done!
and then downloaded the image
dow -data dummy.mfs 0x22000000

and then read back the value at 0x22000000 thru XMD as below
XMD% mrd 0x22000000 35 b
22000000: 4D M
22000001: 46 F
22000002: 53 S
22000003: 32 2
22000004: 00
22000005: 00
22000006: 00
22000007: 00
22000008: 02 ☝
22000009: 00
2200000A: 00
2200000B: 00
2200000C: 00
2200000D: 00
2200000E: 00
2200000F: 00
22000010: 00
22000011: 00
22000012: 00
22000013: 00
22000014: 00
22000015: 00
22000016: 00
22000017: 00
22000018: 03 ♥
22000019: 00
2200001A: 00
2200001B: 00
2200001C: 2E .
2200001D: 2E .
2200001E: 00
2200001F: 00
22000020: 00
22000021: 00
22000022: 00
the contents doesn't map to the contents of the file dow.txt

thanx for your patience and help.
Rajashekar

Joseph wrote:

When you say "when i try to open the file i am not able to", what
happens? How are you opening the files? What flags are you using to
generate image.mfs? It may be necessary to use the -s flag (see Answer
Record:19867 on the xilinx site). That flag switches the endianess.

Are you using a PPC or microblaze? My only experience is with the PPC.

One more thing to try is sticking a small (few chars) txt file in your
file system and see if you can peek at it with XMD to see the correct
values.

Let me know how it goes... I know it took me a while to get my file
system working like I wanted it to.

Joey

 

[Nial Stewart]

"Carl Smith" <cdsmith69NOSPAM@gmail.com> wrote in message
news:MPG.1e38bfdf3eafc9fc98968a@news.west.earthlink.net...

OK, I just have to vent a bit.

I'm starting to think it would be better if board layout
programs just shipped with no pre-made components. I just end
up fixing things on nearly every single part I use anyway.
Sometimes I think it would be better if I just did it all
myself.

If I need a new component I don't even check to see if it's available, I
do it myself and get it reviewed. That way you know it's definitely
right (probably).


Nial



-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Thomas Gebauer]

Hi,

i tried to install it on a Debian Sarge with a 2.6.12 kernel but without
success. It complained about a missing libqt_qt.so (or similar). Which
packages are missing?

Thanks in advance.

Thomas

"Dan" <mekmon@gmail.com> schrieb im Newsbeitrag
news:1137628581.049694.49240@g49g2000cwa.googlegroups.com...

* Impact does not work out of the box with kernel
version 2.6.15.1. I had to download linuxdrivers2.6.tar.gz
and compile it. Furthermore, I had to edit the configure
script in windrvr and make sure that UDEV was not used.
(The udev interface seems to have changed in later 2.6.x
series. The relevant symbols are also GPL-only now, so I don't
think a binary only module can be distributed using UDEV in later
2.6.x kernels.)
I wrestled similarly with windrvr. It apparently uses some class_simple
functions removed Jun. 20 2005. I subscribe to the LKML and was easily
able to reverse patch it.

Project manager and some other window were converted to QT I think. All
other windows use the hideous WindU lib, so you can start the ise
executable without fooling with DISPLAY but you still need it set to
":0" for all those secondary programs. Other than the subpar hotkey
junk, the interface is much more natural.

Everything much more usable now. (Gentoo, 2.6.14-gentoo-r4 w/
class_simple unpatch, WebPack 8.1, Spartan-3 starter kit w/ parallel
cable III).

 

[JL]

Sorry, I didn't mention that you'll find the aforementioned option in
Xilinx FPGA Editor.

 

[Noway2]

I agree, my trust in the pre packaged libraries is 0%. I always use a
datasheet and enter the symbol and footprint patterns and then I like
to double check it the part against a 1:1 print.

 

mail@deeptrace.com wrote:

Is there an easy to disable timing analysis between two unrelated
clocks in ISE 7.1? I don't want to have to put in specific ignores for
all of the paths. I know that there are no timing errors since one
clock is only used to write the registers, and the other clock only
uses the contents of the registers when they are stable. Something
like ignore all analysis for CLKX to CLKY would be ideal.

TIMESPEC "TS_a_to_b" = FROM "clk_a" to "clk_b" TIG;
TIMESPEC "TS_b_to_a" = FROM "clk_b" to "clk_a" TIG;

The TIG timespec basically means 'timing path ignore'. This should do
the trick for you.

cheers,
aaron

 

Exactly what I wanted. I didn't realize that it was OK to have a
FROM/TO with just named clock nets. I tried it and it got rid of a
slew of non-errors.

Thanks,
Chris

 

[Ivan]

Hi,

nice info...
can someone tell me if the USB cable works on Linux?

Ivan

Andreas Ehliar wrote:

I just installed ISE 8.1 on Linux and these are my first
impressions:

* Project Navigator finally feels like a native Linux
program. Previous versions often felt unresponsive and
slow. With this version I no longer feel an immediate
urge to build everything with Makefiles. This is great!

* Impact does not work out of the box with kernel
version 2.6.15.1. I had to download linuxdrivers2.6.tar.gz
and compile it. Furthermore, I had to edit the configure
script in windrvr and make sure that UDEV was not used.
(The udev interface seems to have changed in later 2.6.x
series. The relevant symbols are also GPL-only now, so I don't
think a binary only module can be distributed using UDEV in later
2.6.x kernels.)
I also had to install fxload to download the firmware to the
programming cable and make sure /proc/bus/usb was mounted.

All in all, I got it to work, but I really wish that Xilinx
could remove the dependence on windriver. It is a real nuisance
if you have to upgrade your kernel for whatever reason since you
will need to recompile the kernel module in that case. If you
happen to use parallel cable III or IV you can use XC3Sprog instead.
You have to modify the program somewhat if you want to use it with
Virtex-II FPGA:s. (You have to make sure that it recognizes the FPGA.)
I haven't tested V2P or V4 FPGA:s with it though.


* Test benches seem to be handled much more sanely in Project
Navigator. You can now for each source file decide if it should
be used for simulation, synthesis or both.


/Andreas

 

[Duane Clark]

JL wrote:

Yes, I feed a clock output pin.

I tried with BUFG and BUFGCE and they don't work. I guess the reason is
that they are only used to distribute the clock signal to synchronous
elements, not to output pads.

For the moment, the only solution I found to work is the FDDRCPE
suggested by Symon. I just wonder if there is anything simpler than
that.

Easier? Really, it is not that hard is it

Anyway, you probably want to use the DDR method. There is no direct
connection from the clock net to the output PADs, so what ends up
happening if you don't use the DDR method is that the clock signal gets
routed over some local routing paths. And the delay to the pad then
depends on the pin getting routed to, and even can vary from one PAR
session to the next.

Assuming you are also outputting some other signals (usually the case),
you now have the problem of having an unpredicatable relation between
the output clock and the other signals.

With the DDR method, the delay will never vary, regardless of the pin or
PAR session. And the relation to other signals will be fixed; that is,
one edge of the clock will almost exactly match the data transition, and
the other edge will always fall almost exactly in the middle of the data.

 

[Antti Lukats]

"John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag
newsine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU...

Is your library for the CRC generation available to others.

JOhn

hi John

I just sent per email to you an updated version (tested with Virtex) of
bit2frames application
that is based on our bitsream library, if you can verify that the tool works
and is able to process
and properly calculate the CRC in your bitstreams then well we can give the
source out too,

ah one more adivce make sure not to use compression whrn working with
data2mem, but
I guess you are not using it anyway.

the bit2frames I just sent is also not tested with compressed Virtex
bitsreams yet

Antti

 

[John_H]

Of course it's ridiculous!

Marketing loves to make engineers hate the company. They want to make the
*managers* look past their feeble engineers for approving brand X versus
brand A (forgetting, of course, that most engineers have the lattitude to
push for one brand due to the *engineering* tradeoffs).

There are times when you need to shoot the engineer to ship the product
(just one more tweak is *not* okay!) but thankfully the engineers get to be
pissed off at marketing until they skew the preference toward the "other"
brand's mismarketing BS.

Ah, what a wonderful world. What would it be like, after all, if we have to
pull our hair out with our CAD tools (PC, synth, P&R, sim) but didn't have
to get the least bit upset about choosing the part in the first place?

- John_H


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:1137702911.352529.98730@g47g2000cwa.googlegroups.com...

As we have all known for some time, Xilinx has had a habit of padding
the logic cell counts in their data sheets to account for
"effectiveness". This factor is 1.125 or 9 LCs per CLB in the newest
parts. I still find this very odd, but mainly annoying because when I
want the true LC count, I have to calculate it myself.

Anyone else find this to be a bit ridiculous?

 

[Jim Granville]

Peter Alfke wrote:

Rickman, why do you ask?
Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

How about you try and introduce the meaning of UNITS to them ?

ie let them use LCeq for the marketing DOCS, and also have an absolute,
physical count, of LC = X * Y on the die.

As a radical idea, they could even publish the formula
LCeq = LCactual * MarketingsIdeaOfLevelPlayingFieldFactor


That way, everyone is happy

The problems occur when one dept trys to use a std unit,
but hijack it to mean something else. In the end no one knows
where they are.... and everyone is annoyed.

-jg

 

[rickman]

Peter Alfke wrote:

Rickman, why do you ask?\

I asked because I wanted to hear the the opinion of others. I read a
recent Spartan 3 data sheet and noticed that there is now a footnote
explaining they they are padding the number. I just find this pretty
absurd. You compared it to car makers measuring horsepower, but that
is a measurement that has parameters. Countings LCs is counting and
adding a 12.5% fudge factor is marketing, not measurement. It would be
more like a car maker saying his engines are 9 equivalent cylinders!

But mainly it is frustrating to always have to calculate the correct
number myself. At least marketing has not gotten to my calculator yet.

Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

That is silly for you to state this as a fact when it is just your
opinion. Have you ever had a customer ask you to adjust your LC counts
so they can compare them to the competition? Who says it is "a more
meaningful metric"? Your marketing, that's who!

It is one thing to accept that your company lets marketing inflate the
numbers, but please don't insult me by trying to justify it.

Am I alone in regard to finding this annoying?

 

Peter Alfke wrote:

Rickman, why do you ask?
Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

Actually Pete I don't think it is. It's a very arbitrary number where
apples,
dead tires, horse shit, and tree stumps are all given numerical values
which
have absolutely no relation to particular customers needs, and declared
equal
in decsion tree wieghting in ways certain customers would never do the
wieghting.

If the company would then derate the part for being unable route a
fully used
device, or power a fully used device, or cool a fully used device there
might,
maybe, in a long shot be a justification for the bloat factor.

The reality is that certain applications do not do arrithmentics, do
not need much
if any carry chain, or multipliers, or even very many F5/F6 muxes, but
do need a
lot of LUT's.

Being clear up front that you are offering 2 cases of applies, 4 dead
tires, no horse
shit, and one stump to sit on while eating your apples is a whole lot
clearing than
tring to figure out just how much shit you get for 37.

Old School math ...
John

 

[Joseph]

Well Raj,

I don't know what else to say. For the little text file, I would try
and make a really small image with just the text file so you can
examine the entire memory range where the file lives. The actual text
can be buried pretty deep.

Looking at your code from above vs mine:

mfs_init_fs(MFS_NUMBYTES, MFS_BASE_ADDRESS, MFSINIT_ROM_IMAGE);
mnt1 = mfs_file_open("1_1_0.mnt", MFS_MODE_READ);
xil_printf("\n%d\n",mnt1); // receiving -1 for mnt1 : the file opening
was unsuccessful

___________________

mfs_init_genimage(53200, (char *) MFS_BASE_ADDRESS, MFS_INIT_TYPE);
xilmfs_result = mfs_change_dir("my_fs");
xilmfs_result = mfs_get_current_ dir_name(dirname);


There are clearly some differences for you to investigate (if you
haven't already). First what is difference between mfs_init_fs and
mfs_init_genimage (I am not sure, don't have documentation open)? And
did you ever do an mfs_change_dir before trying to open a file within
it? You need to do so. That is why I do an mfs_get_current_dir_name
to see if I am in the correct directory. I don't remember even
how/what these functions do at the nuts and bolts level, but I do know
that my system did eventually work, so I know these functions do the
trick.

OK, looked it up: mfs_init_fs: Initialize the memory file system.
This function must be called before any file system operation. Use
mfs_init_genimage instead of this function if the filesystem is being
initialized with an image generated by mfsgen.

I remember that this has to do with the actual pointer to the file
system, it needs to be adjusted properly. Try that with the correct
'cd' call before opening a file.


Keep me posted! Good luck!
Joey

 

[Andreas Ehliar]

On 2006-01-19, Ivan <gmivan@terra.es> wrote:

Hi,

nice info...
can someone tell me if the USB cable works on Linux?

Perhaps my posting wasn't clear on the issue, but I used the
USB programming cable in Linux. (At least insofar as I got
impact up and running with the USB cable, I haven't tested
it much so I can't say that it is rock solid as yet.)

/Andreas

 

[Adrian Knoth]

Thomas Gebauer <th.gebauer@gmx.de> wrote:

i tried to install it on a Debian Sarge with a 2.6.12 kernel but without
success. It complained about a missing libqt_qt.so (or similar). Which
packages are missing?

I haven't tried it, yet, but I think such a package does not
exist. It is either provided by ISE itself (set the environment
variables correctly) or is an aliased version of something else
(i.e. symlink libqt-mt.so to libqt_qt.so and run ldconfig or
set LD_LIBRARY_PATH).

I think I'll find some time to try it today, but don't rely on this


--
mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver

Darf ich bitten - oder tanzen wir zuerst?

 

[Jan Panteltje]

On a sunny day (Fri, 20 Jan 2006 10:53:31 +1300) it happened Jim Granville
<no.spam@designtools.co.nz> wrote in <43d00a4b@clear.net.nz>:

Peter Alfke wrote:
Rickman, why do you ask?
Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

How about you try and introduce the meaning of UNITS to them ?

ie let them use LCeq for the marketing DOCS, and also have an absolute,
physical count, of LC = X * Y on the die.

As a radical idea, they could even publish the formula
LCeq = LCactual * MarketingsIdeaOfLevelPlayingFieldFactor


That way, everyone is happy

The problems occur when one dept trys to use a std unit,
but hijack it to mean something else. In the end no one knows
where they are.... and everyone is annoyed.

How about 'feel gates'?

After all my 10W PC speakers are 1000 'music watts'.
And this FPGA has a 10 giga gates equivalent feel power?

A. Nonymous.

 

[Ray Andraka]

Keith O'Conor wrote:

Hi,
I'm trying to figure out the best way to sort a large amount
(thousands) of floats or fixed-point data on an FPGA. With this amount
of data, it needs to be stored in RAM because it obviously won't fit in
registers, but this means that there can only be one access to that RAM
every clock cycle. Since any sorting algorithm will need access to at
least two pieces of data to compare, I can't figure out how to
parallelize the sorting. Has anyone got any experience in this area? I
would really appreciate any advice.

Thanks,
Keith

Sorting floats is no different than sorting fixed point, that is the

reason for using excess code N for the exponent.

To accomplish the sort efficiently, you partition the data, storing and
the sorting subsets of the full data set on the FPGA and then merging
the results. That way you don't have as many accesses to the off-chip
ram to deal with.

 

[Austin Lesea]

Marc,

See below,

Austin

jetmarc@hotmail.com wrote:

Hi,

I'm considering a VirtexIIPro device for a security sensitive
application. This
device offers bitstream encryption. I'm am worried about what parts of
it are accessable after the bitstream has been loaded, eg through the JTAG
interface. Can any of the FPGA state or RAM cells be read, written or
verified?

Once in encrypted mode (key loaded, key BBRAM bit set to use key) ICAP
is completely disabled. Readback is completely disabled. JTAG readback
is completely disabled. The 405 PPC JTAG is not part of the pinned out
JTAG access. So if you don't want anyone to get to it, you don't
connect it to any pins.

Can the PPC405 component be put into DEBUG mode, and

instructions be read or injected?

Only if you have control of the bitstream/program. If you don't want to
allow that kind of attack, use a decryptor in the fpga logic to decrypt
instructions fetched from off chip. Or place all instructions on chip.

Can an attacker start a partial

reconfiguration with a non-encrypted chosen bitstream, to modify the
device configuration in a promising way? Eg can he overwrite the BRAM
interface cells to dump RAM contents to I/O pins, etc?

Once in encrypted mode, all you can do is erase the entire
configuration, and load a new one. There is no partial configuration
allowed (that is disabled in this mode).

Attempting to readback the keys once programmed and in encrypted mode
zeros them.



I had once placed out here the challenge to crack V2 Pro: we have a USB
board with a secure bitstream, battery, and a V2 Pro device. We passed
out all we made to interested parties.

That was over a year ago now.

No one has been able to tell me the key. Or to hack the bitstream
(modify the function in any way, other than just erase it).

Just because a bunch of motivated students who crack smart cards in
their junior year by using differential power analysis can't crack it of
course does not make it bulletproof.

Other "agencies" and "contractors" have also looked at V2 Pro (I am
told). And so far, we have heard nothing. That means they can't break
it yet either.

As you may be aware, the latest recommendation is to use AES for new
products. I believe the reason is that Triple DES has been shown to
have a search space of 2E112, and with a huge array of FPGAs, you could
actually search that space....?

So, we have the new Virtex 4, with 256 bit AES. 128 bit AES is
considered by the real purists to be only marginally better that triple
DES, and hence, not worth using.

One step ahead.