EDK : FSL macros defined by Xilinx are wrong

[Benjamin Todd]

Ah, the board is already in the pre-series stage, there are a couple of
reasons why we chose a 9500 CPLD (yes I know, very old!)...
5V internal = only one PSU needed & whole board at 5V which is excellent for
reliability,
our radiation campaigns showed that it's highly immune to soft-errors (TID
was much more effective),
It's active almost as soon as it is powered up whereas FPGAs must wait
whilst they are being programmed. And we simply don't need the complexity of
an FPGA.
Don't get me wrong, we use all manner of Xilinx stuff in the lastest project
(95288 95144XL XC2C128 XC2S400 XC3S1000) just depends on the exact nature of
the application.
I think I might investigate the Microprocessor alternative, just then have
to figure out how to get the .bit file into some flash near the
microprocessor in a reliable and easy manner.
Ah well.
Ben

"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> wrote in
message news:djrarf$a2r1@cliff.xsj.xilinx.com...

OK. Fair enough. And you could use SystemACE to do all that except for
programming the CPLD. Why use a CPLD and not just a small, cheap FPGA
like a Spartan3 or a variant?


Benjamin Todd wrote:
As also indicated, an interesting question to ask is why do you want to
configure your CPLD every time you power up? Is your design pattern
changing all the time? Is this some sort of demo board?


Not exactly, maybe i'm being a little ambitious...

I'm just doing some research into making a test apparatus for some
designs using various CPLDs. The idea was to make a discrete piece of
hardware that the UUT would be plugged into, and then a little report
saying whether it passes or fails - this needs to be rugged, and
industrialised.

Using boundary scan I can only verify about half the board, and the less
critical half at that, so i'm wondering whether I could use one bit file
to run a sequence of test vectors in conjunction with the external
tester, and then once all the interconnects are established as correct,
load the proper bit file.

I guess you're wondering why I don't just go for a PC running impact...
well i'm trying to avoid having to maintain a PC with the manufacturer,
including the OS, the test software etc etc.

Ben

 

[Antti Lukats]

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
news:djqr4n$h7b1@xco-news.xilinx.com...

Antti,

But "partially faulty" yet 99.999% tested (much better than an ASIC is
able to be tested) means that any faults which are not being used, don't
matter.

Every Altera FPGA sold has a redundant column to replace a faulty one.
So, every one they sell could have a fault. But it isn't used. And it
does not affect reliability (as shown by their product qual tests).

Easypath has also been fully qualified by the reliability testing that
is required of any device.

Austin

Hi Austin,

relax -I did not mean to say the easypath are bad or faulty, sure they are
fully tested and OK, just they have nothing in common with ASICs.

as of faulty bits - I would welcome if Xilinx would actually sell 'known bad
silicon'. That is devices that have either known failures or some % of fails
per chip. Such silicon could be sold 'as is'. Saying that this batch has say
no more than 3% of LUTS failing, and there are no more than 0.1 interconnect
bads... its up to the customer to test the chip and to develop methods how
to to use it. I bet Xilinx marketing doesnt like the idea. Idea itself IS
GOOD. With proper tools and sw technologies the 'faulty' FPGAs could still
be used for many applications.

Antti

 

[dp]

Benjamin,
I have made/written tools to program some of the Coolrunner
CPLDs, I have them running on either a CPU32 (683xx) or
PPC based system. Please feel free to contact me directly
if you think I might be of some help.

Regards,
Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

 

[Udo]

Hello Peter,

many thanks for your fast answer and greetings from Germany.
I have forgotten one question - Virtex-4 doesn't have internal
tristate buffers anymore. Why?

Udo

 

[Paul Marciano]

Brian Philofsky wrote:

If you re-write the code to use these attributes, you will likely get
what you want out of the synchronization circuit:

module test(input clk, input in_sig, output reg out_sig);

(* ASYNC_REG="TRUE", SHIFT_EXTRACT="NO", RLOC="X0Y0" *) reg [1:0] ss;

always @(posedge clk)
begin
out_sig <= ss[1];
ss <= { ss[0], in_sig };
end

endmodule

I just tried to instantiate the above module multiple times (for
different async inputs), like this:

module tsync(input clk, input in1, input in2, output out1, output
out2);
test t1(.clk(clk), .in_sig(in1), .out_sig(out1));
test t2(.clk(clk), .in_sig(in2), .out_sig(out2));
endmodule


And I got a MAP error in XST:

Section 1 - Errors
------------------
ERRORack:679 - Unable to obey design constraints (MACRONAME=hset,
RLOC=X0Y0)
which require the combination of the following symbols into a single
SLICE
component:
FLOP symbol "t1/ss_0" (Output Signal = t1/ss<0&gt
FLOP symbol "t1/ss_1" (Output Signal = t1/ss<1&gt
FLOP symbol "t2/ss_0" (Output Signal = t2/ss<0&gt
FLOP symbol "t2/ss_1" (Output Signal = t2/ss<1&gt
There are more than two registers. Please correct the design
constraints
accordingly.


Rookie mistake, I'm sure... but I'm stuck!! Help!


Regards,
Paul.

 

[Kunal]

Tristate buffers on metal lines slow them down and are being phased out
of Xilinx devices. If you do need multiple drivers on a single line use
a mux instead, they are much faster. I found 2 good threads on the same
topic

Thread 1
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/33e442048fb99734/d520d67ab735e3cc?q=tristate+buffers&rnum=6#d520d67ab735e3cc

Thread 2
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/8eefcd483fbc8f4a/54eb3278571e1601?q=tristate+buffers&rnum=2#54eb3278571e1601

Kunal

 

[David Tweed]

Emtech wrote:

This is for an RGB LED demo display application.

1. There will be mixing of colours done at say 3ms intervals for
each colour to stay ithin the 10ms and take avantage of
persistance of vision.
2. Bits accuracy in the duty cycle is not very important since
the PWM is only for brightness control.
3. The outputs must at least be synchronized to the colour mixing
intervals, i.e. 3ms intervals. In other words, the PWM will
further divide the 3ms intervals to control brightness.
4. These will only be used in an RGB LED display application
hence the only real importance is the 10ms refresh limit.

Thank you for your input.

Very interesting. Earlier this year I did a PWM design to control
RGB LEDs for a medical testing device. The client wanted a total
of 61 RGB LEDs, or 183 channels of PWM output, with 16-bit
resolution and 1 ms refresh period (Yes, this means a 65.536 MHz
clock). I divided this up into three Xilinx Spartan-3 FPGAs with
63 PWM output channels each in order to avoid BGA packages and
simplify the overall PCB layout. Each FPGA drives 20 or 21 RGB
LED chips.

IIRC, it didn't quite fit into an XC3S50, so we ended up using
the XC3S200. A design with less resolution or fewer channels
would easily fit into the smaller chip.

The PWM hardware is driven entirely by the contents of a single
block RAM, and uses one of the RAM's ports to read out the data.
This gives a great deal of flexibility as to how the system
controller gets the intensity values into the RAM via its other
port, using anything from a conventional parallel bus interface
to a synchronous or asynchronous serial interface.

-- Dave Tweed

 

The answer to your question is NO.

The PIPE specification is not part of the PCI Express Base
Specification. It is not even governed by the PCI-SIG. It is a
"suggestion" from Intel for a logical interface between the MAC and the
PHY, in the physical layer of a PCI Express component. I think the
idea is to suggest that people designing PHY functions use a common
interface, to foster portability between PHY vendors/implementations.

As you note, it describes the logical behavior of such an interface and
doesn't discuss anything else. At the time it was written, I don't
think they were even contemplating external PHY devices like the
Philips PX1011a. However, you can imagine that someone wanting to do
an external PHY would probably take the PIPE specification as a
reasonable starting point for their interface behavior. What
electricals to use? Whatever you want, as long as it works and you
think your potential customers will be satisfied. Philips used SSTL2,
as you point out, which seems to work well with, say, a Spartan3 FPGA
from Xilinx.

So, then, if you are using an external PHY, you need to evaluate your
options and then select one -- and design to the specifications in the
vendor's data sheet.

Eric Crabill
Xilinx, Incorporated

 

[Kunal]

My 2 cents:
The first two cases are identical. The only difference is that you are
naming the nets coming out of the registers in the second case. So no
difference in terms of logic resources used.
In the third case, the implementation tools have simply optimized away
the logic since you didnt use them. Tha can be only the only
explaination in the reduction from 51 LUTs to 4!

 

[comcast]

in the "XtremeDSP for Virtex-4 FPGAs User Guide", on
Page 56 are in Table 1-13 some interesting functions
mentioned, like AND and XOR and so on.
Does anyone know how these functions are accomplished?

AND function: result is 1 when all the input bits are 1, otherwise the
result is 0. So if you add 1 to the input, what will you get (hint: carry
out)?

XOR:
a = 0, b = 0, result = 0
a = 0, b = 1, result = 1
a = 1, b = 0, result = 1
a = 1, b = 1, result = 0

if you add a and b, you get

a = 0, b = 0, result = 00
a = 0, b = 1, result = 01
a = 1, b = 0, result = 01
a = 1, b = 1, result = 10

result(0) is what you need.

HTH,
Jim

 

[Antti Lukats]

"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag
news:43626d62$1@clear.net.nz...

Austin Lesea wrote:
Antti,

Selling known bad parts is an interesting concept.

No one has figured out how to do that.

?! - So Xilinx have no errata, on any devices ? Wow ?
I'd say pretty much everyone sells bad silicon.

As to selling 'bad by device' [unknown bad parts],
that too has been done in Russia.

NAND flash that maps bad sectors in the FAT, is also
'bad by device', so this is not a new, or novel, idea.

The risk to Xilinx is of the parts being relabeled, and
sold as genuine, plus all the traffic on how to get
these bad xilinx devices to limp along.
ie bad for the brand, plus imagine if someone
(like Antti) actually got really good at this, and found
that a large chunk of sales switched to the low yield
El-Cheapo parts - not good for Xilinx's shareholders
either....

So I cannot see it happening, but not for technical reasons.
Easypath is the closest Xilinx will get.

-jg

Hi Jim

your knowledge still amazes me !

to put thing stright I am not from russia and have nothing todo with them.
same for my home country that happened to be occupied by russia for some
time. But actually I did enjoy that times as it allowed to travel for
virutally free all round the russian territories.

and yes, the russian fabs did sell bad silicon. namly 16kbit, 64kbit and
256kbit DRAMs chips did have special markings indicating if
1) full array is OK
2) lower or upper half is OK
3) single quarter of array is OK

re device re-branding, I guess that is mostly popular in some far east
countries that are known to have relabelled intel CPUs at least.

the bad devices idea there are many levels of bad. and different used for
bad silicon.

1 like testing of the soldering process.
2 boundary scan test
3 power supply testing

all those can be done with very badly damaged silicon.
large altera Stratix devices cost 9,000 USD a piece, I imagine it would be
way reasonable to buy bad silicon to pre test a board that is going to be
used for a device that cost almost 10K USD a piece.

Antti

PS some posts make me smile, thanks Jim

there isnt a smile on face most of the time
specially when I am in thinkmode...
what is most of the time,
and then I look like: http://www.truedream.org

 

[backhus]

Hi,
Kunal said it right before.
The first two cases are identical. The third has no outputs, therefore
optimizes away the register.
Mow, if you want 48 Outputs and (just a guess) 22 other I/Os +1 Clock
have a look at the used IOBs:

In the first two cases there are 70 IOBs used. (Too much for that small
chip anyway)
In the third case 48 outputs,are gone leaving 22 used I/Os. This fits
into your chip, but all the output registers and their associated logic
are gone.

so first of all you need a chip with more pins so the design fits. The
number of LUTs is quite irrelevant in this case, because you are using
only 5% of the chipsize for logic. And for the observed "reduction" in
LUTS: 81 remuved LUTS divided by 48 controlled FFs gives less than two
LUTs per FF. This is a quite good ratio.

My recommendation: Read the FPGAs datasheet and understand the SLICE and
IOB structure and how the ressources are used by your synthesizer.
Understand how to read a synthesis report.

have a nice synthesis

Eilert

himassk schrieb:

Command;

reg [47:0]Command;

Selected Device : 3s50vq100-5

Number of Slices: 51 out of 768 6%
Number of Slice Flip Flops: 4 out of 1536 0%
Number of 4 input LUTs: 89 out of 1536 5%
Number of bonded IOBs: 70 out of 63 111%
Number of GCLKs: 1 out of 8 12%

_________________________________________________________________
reg [47:0]Command;


Selected Device : 3s50vq100-5

Number of Slices: 4 out of 768 0%
Number of Slice Flip Flops: 4 out of 1536 0%
Number of 4 input LUTs: 8 out of 1536 0%
Number of bonded IOBs: 22 out of 63 34%
Number of GCLKs: 1 out of 8 12%

 

[Falk Brunner]

anupam schrieb:

fifo_data <= X"AA4F";

This representation gives an error " expecting an expression of type
std_logic_vector"
Remember ,my fifo_data is a std_logic_vector.

regards,
Anupam Jain

AFAIK this works only if the bus width is a integer multiple of four.

Regards
Falk

 

Anupam,
X"AA4F" should work, which simulator do you use? I believe this
is a VHDL-93 feature and it is amazing that even in 2005 end (almost 13
years!!) some tools require a Mode-93 kind of switch to their
compilers.

Your compiler may need a -V93 or some thing similar.

HTH
Ajeetha
www.noveldv.com

 

[John_H]

"Marco" <marcotoschi@nospam.it> wrote in message
news:dk5abq$7la$1@nnrp.ngi.it...

Hallo,
How may I realize an integrator into a FPGA?

Many Thanks
Marco

Just know that you can't realize an ANALOG integrator into an FPGA which is
what you would need for your Sigma Delta converter pursuit.

 

[Adam Megacz]

Jim Granville <no.spam@designtools.co.nz> writes:

The marketdroid that wrote the link above, decided eBEAM
might scare off some customers, so better to use words
like "configurable logic" & "unprecedented flexibility and time to market".

By the way, am I the only one who finds 90% of the material that
companies publish on their products to be utterly content-free and
useless?

It seems like the problem is much worse in the FPGA space than other
parts of the computing world. That's extremely surprising, especially
because the marketing certainly isn't aimed at average end-users.

- a

 

[Mark McDougall]

Falk Brunner wrote:

fifo_data <= X"AA4F";
AFAIK this works only if the bus width is a integer multiple of four.

Yes, it does, which is *really* annoying!!!

Why they dont allow something like...
foo(4 downto 0) <= X"1F";
is beyond me!?!

Regards,
Mark

 

[Mike Treseler]

Mark McDougall wrote:

Yes, it does, which is *really* annoying!!!

A dog barking all night or
an IRS audit is *really* annoying.

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.

-- Mike Treseler

 

[Kunal]

A FPGA which you cant reconfigure ( Not reliably atleast) is
"ASIC-like" to me. Anyway i wouldn't to get into a discussion of
semantics. I said it would lower unit cost, nothing else.
I just showed him the links, he can take it from there.

Kunal

 

[Mark McDougall]

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.

Regards,
Mark