EDK : FSL macros defined by Xilinx are wrong

[server]

message unavailable

 

[Austin Lesea]

All,

Here is the answer:

"Hi,

Yes this is a bug. This issue is being fixed for the next EDK release
(8.2i). Also, your patches seem correct."

Austin

Austin Lesea wrote:

Sylvain,

I got it.

I will find out what happened, and report back.

Thanks,

Austin

Sylvain Munaut wrote:

Can anyone @Xilinx can confirm they read this and will take
care of it ?


Sylvain Munaut wrote:

Hi everyone,

I hope someone @Xilinx will read this.

In the new EDK 8.1 the FSL access macros have changed
name. And they also introduced _interruptible versions.
Theses are defined in
${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h

The definitions for getfsl_interruptible and
cgetfsl_interruptible are correct. But the ones for
putfsl_interruptible and cputfsl_interruptible are
incorrect. For example putfsl_interruptible is :

#define putfsl_interruptible(val, id) \
asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
"addic\tr18,r0,0\n\t" \
"bnei\tr18,1b\n" \
: "=d" (val) :: "r18")

and it should be :

#define putfsl_interruptible(val, id) \
asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
"addic\tr18,r0,0\n\t" \
"bnei\tr18,1b\n" \
:: "d" (val) : "r18")

Obviously val is a input in the case of a 'put' and not
an output.


Another related question : In my code, when a replace all
non _interruptible versions by their _interruptible counter
parts, it doesn't behave as excpected anymore ...
Does theses version require some hw support ?



Sylvain



PS: I know I should submit a webcase but when I try to login
I just get "Server Error" ... and so I obviously can't even
submit a webcase about my problem of being unable to log in
into the webcase ...

 

[Allan]

Nope, that didn't do it either. I've tried some iterations of this
theme with no success. Where would I find the libraries you mentioned
to take a look at?

 

[Eric Smith]

"aymmmm@gmail.com" <aymmmm@gmail.com> writes:

The final stage is to interface the Spartan-3 to a USB Bluetooth dongle
to support wireless voice and/or data communications modulated with
DSSS (IS-95 CDMA).

I need to interface the USB dongle to the PS/2 port of Spartan-3 using
a PS/2-to-USB converter.

Sorry, it's not going to work. USB-to-PS/2B converters only support
PS/2 keyboards, mice, and similar devices on USB hosts. They don't let
PS/2 hosts talk to arbitrary USB devices such as Bluetooth dongles.

 

[Peter Alfke]

I do not understand your design, but take my word for it: Reading the
Xilinx BlockRAM content absolutely requires a clock edge. Nothing
happens in the address decoder without a clock edge. In many cases this
is a desirable feature, in some cases it is not desirable, but it is a
fact: You need a clock, not only for writing, but also for reading.
Peter Alfke, Xilinx Applications

 

[Sylvain Munaut]

Austin Lesea wrote:

All,

Here is the answer:

"Hi,

Yes this is a bug. This issue is being fixed for the next EDK release
(8.2i). Also, your patches seem correct."

Austin

GReat, thanks for the followup.


Sylvain

 

[Kolja Sulimma]

Ben Jones schrieb:

Hi Fred,
You
can do it without any square-roots or even multiplies (except by 2).
Not even that because

2(x+1) + 1 = (2x+1) + 2
You need a total of two adders and one comparator per ordinate.

Kolja Sulimma

 

[Kolja Sulimma]

radarman schrieb:

Where I work, we aren't allowed to directly connect FPGA or CPLD pins
directly to external connectors, save for on-board test points (like
Mictor connectors). Everything goes through external buffers or
registers. Yes, it does add latency, but it does protect
hard-to-replace BGA's from damage.

Of course, I work on military hardware, and reliability is a major
factor. While most things are replaced at LRU (chassis) level, there
are some systems where the customer is allowed to replace individual
boards. Usually, this happens in a customer repair facility, and is
done by military technicians, but still - it pays to go the extra mile.

I thought in military applications reliability is more important than
cost. For standard buffers I would argue that you get a much higher
failure rate with the buffers than without. You have three times the
number of solder joints and much more parts after all.
Also, many buffer chips are less robust then FPGA pins. Some don't
even have protection diodes.
Of course if you use special ESD protection buffers all this changes.
But some passive protection to the FPGA pin might give you the same effect.

The other factor is that every board costs so much, that they are
almost never thrown away, and instead reworked. It is much simpler to
replace a buffer chip than a BGA.

With the right tools it is not really more complicated to replace a bga
or an SOIC. Local IR-heating, pulling the chip, cleaning the board,
placing a new chip, local IR-heating again.
Cleaning takes longer because there are more pads. But that's about it.
I doubt that the cost of replacing the BGA is more than 5% of the cost
of isolating the defect.

Kolja Sulimma

 

[Simon Peacock]

It is probable that the buffer, although offering more pins to cause faults
(Military boards will be x-rayed and each solder joint inspected don't
forget) offer a level of protection that FPGA pins can't.
A typical "Interface" buffer chip has a higher drive strength, better ESD
Protection thru bigger geometry and the "real" outside connections have ESD
diodes and the proper interface for the conditions, including current limit,
voltage control, hot-pugging support etc.

Simon


"Kolja Sulimma" <news@sulimma.de> wrote in message
news:444a64d2$0$11079$9b4e6d93@newsread4.arcor-online.net...

radarman schrieb:
Where I work, we aren't allowed to directly connect FPGA or CPLD pins
directly to external connectors, save for on-board test points (like
Mictor connectors). Everything goes through external buffers or
registers. Yes, it does add latency, but it does protect
hard-to-replace BGA's from damage.

Of course, I work on military hardware, and reliability is a major
factor. While most things are replaced at LRU (chassis) level, there
are some systems where the customer is allowed to replace individual
boards. Usually, this happens in a customer repair facility, and is
done by military technicians, but still - it pays to go the extra mile.

I thought in military applications reliability is more important than
cost. For standard buffers I would argue that you get a much higher
failure rate with the buffers than without. You have three times the
number of solder joints and much more parts after all.
Also, many buffer chips are less robust then FPGA pins. Some don't
even have protection diodes.
Of course if you use special ESD protection buffers all this changes.
But some passive protection to the FPGA pin might give you the same
effect.

The other factor is that every board costs so much, that they are
almost never thrown away, and instead reworked. It is much simpler to
replace a buffer chip than a BGA.

With the right tools it is not really more complicated to replace a bga
or an SOIC. Local IR-heating, pulling the chip, cleaning the board,
placing a new chip, local IR-heating again.
Cleaning takes longer because there are more pads. But that's about it.
I doubt that the cost of replacing the BGA is more than 5% of the cost
of isolating the defect.

Kolja Sulimma

 

[Terry Brown]

John,

You will now spend most of your time creating "workarounds" for Xilinx
8.1.

I finally gave up and went back to 6.3 yesterday.

Various 8.1 problems I have seen:

1. The "humongous project file bug"--in this one, your ise project grows
to perhaps gigabytes in size, takes forever (20-30 minutes) to load and
then doesn't work. The "workaround" is to blow away the project file
and start over. Hmm . . . why am I doing this again? This appears to be
fixed by service pack 3.

2. Coregen doesn't run--crashes and wants to talk with Microsoft. This
is better in service pack 3--at least I could run it from the gui,
although it still crashed if I tried to run it separately.

3. The "multipass par fools you" bug. In this one, you run a multipass,
find a seed that gives good results, copy the files back, then run par
only to find that the timing is now awful.

4. The "can't really run these apps" bug. I normally use my own control
app to run the tools from the command line, parse the error file and use
timingan.exe if necessary. Now timingan.exe won't run--nothing happens.
Still runs if I execute it from the ISE gui. The same is true--at
times--of all the gui apps like fpga_editor.exe and such. They won't even
run from Windows Explorer--brief hourglass, then nothing. No log files,
nothing. They still run from the gui.

5. The "oops the bitfile is too big" bug. Run fpga_editor independently
(when it works), define probes, generate bitfile from the probes dialog.
The bitfile for a 2vp30 is now 35 bytes too long and won't load properly.
Run fpga_editor from the gui, do the same thing and all is well.

6. The "can't do anything even in the gui" bug. In this one, you can't
run any processes anywhere. The ISE gui runs, but if you try to run a
process (map, par, whatever), all the wheels spin briefly, then show
errors for the process, but no log files are created. Forcing run with
"rerun" doesn't work--nothing works. The "workaround" is again to blow
away the project file.

Bottom line is that even after three (3!) service packs, the 8.1 tools are
unusable for real work. It was taking me most of a day to discover
the next "workaround" so I could build bits when it should take an hour.
After struggling to get timing closure on Friday, I gave up, went back to 6.3,
ran multipass and had perfect timing bits in an hour and a half.

We are looking at upgrading our board to use a Virtex-4, but that may
require using version 8 of the tools and I think we'll evaulate Altera
seriously now--at least then maybe I could get some work done.


Terry Brown


On Fri, 21 Apr 2006 09:16:19 -0700, johnp wrote:

I found a work-around - I delete the bulk of the files from my
working directory including the .ise file and now ISE starts
up. I copied in an older 6.1 .npl file and told ISE to convert it
to the newer 8.1 project file.

John Providenza

 

[Fred]

"Fred" <fred@nowhere.com> wrote in message
news:4448b5a2$0$209$db0fefd9@news.zen.co.uk...

I would like to use a FPGA to create some simple test patterns. One of
which is a circle with a variable diameter. I'm not sure where to start.
Can this be realistically be done in an FPGA using minimal resources?

I greatly appreciate the responses here. It's made life a great deal
easier!

Many thanks again.

 

[chakra]

any suggestions in this regard?

 

[Andrew FPGA]

Thank you for the comments guys, it would appear they confirm my
intuition.

 

[vssumesh]

Hello John_H,
Thank you very much for your idea. It saved almost 20K LUTs.
Actually i want a circuit equivalent to 16 port RAM. But as you pointed
is not avilable in lx60. What i am thinking now is to time multiplex
the full operation. 8 port first then the next eight ports. This will
need only 64 RAMs. Thank you once again for your brilliant idea.
regards
Sumesh V S

 

[vssumesh]

bad news...... will use multiplied clock for extra edge
requirement.....
regards
Sumesh

 

[vssumesh]

Why the PAR is showing unroutable design..... why it is not giving
output with a large delay.....

 

[Peter Alfke]

I suggest you step back and re-implement your design in a more
conventional fashion.
Unless you do something very unconventional or extremely fast, there is
no need for using latches.
Try to build your design with fli-flops and one common clock, or
perhaps with a few, but be aware of the difficulties and dangers of
multiple clocks.
Peter Alfke, Xilinx Applications

 

[David Quińones]

Hello Guru

The FIFOs can be expanded, isn't it? There's a lot of resources availables to do this. And I need a very high transmisión speed and the results showed in the xapp807 are reception bandwith.

I'm watching a webcast at www.techonline.com about to learn to use the ultracontroller-II with the TEMAC. I will inform about the evaluation of the UCII + TEMAC.

Best regards boys

 

[vssumesh]

Mine is actually a demux. A 8 bit data goes to any of the 256
locations. Thus a statement like below will create latch.
reg [256*8-1:0] out;
out[ind*8+7:ind*8] = in;
this can be converted to FFs by following statement

always@ (posedge clk4x)
out1[ind1*8+7:ind1*8] = in1;

clk4x because to reduce size i am using TD multiplexing. The output
goes to another FF which latches on the +ve edge of the clk. so how
this can be possible. I think i have to phase shift the clk4x advance
it wrt to the clk by a small amount. These are my problems in using
FFs.

I tried the FF type (not given important to functionality). But found
that that design is also not routing. The LUT is 88% FF is 33% Slice is
96%. Now only 20 or less latches in the design ( most of then are part
of the complicated case statements). If that too is also a problem will
avoid that.
regards
Sumesh V S

 

[David Quińones]

Hi

It's no bad the webcast at www.techonline.com. There is a presentation with voice and you can save it in pdf format and the transcription of the voice too.

We will follow informing...