EDK : FSL macros defined by Xilinx are wrong

Hi Jim,

A significant difference at the LUT spec level that I DID see ( and I
presume still applies ? ) is that Altera have differing LUT path delays
( all LUT legs are not created equal ), whilst Xilinx treated them
all equal.
Click to expand...
Our LUTs have (significantly) different delays on different inputs.

That means the Altera SW/HW can presumably choose the faster legs, where
that matters, and so shave 100's of ps off the critical path ?
=> Faster P&R on otherwise similar silicon ?
Click to expand...
Yes, the software does take advantage of the variance in LUT delay to
optimize the critical path. This is why using 6-LUTs to implement 4-input
functions is no worse for speed than using a 4-LUT -- the four fastest
inputs of a 6-LUT are basically the same speed as the four inputs of a
4-LUT.

Regards,

Paul Leventis
Altera Corp.
 
Oops, I missed one point (thanks Carolyn!).

- is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra
logic to almost give you a 6 LUT? How badly does that work?
Click to expand...
Yes, the ALM is a universal 6-LUT. It can do some functions of 7-inputs,
and all functions of 6-inputs.

Please refer to http://www.altera.com/literature/hb/stx2/stx2_sii51002.pdf.
Page 2-8 is the diagram you want to stare at closely.

Paul Leventis
Altera Corp.
 
Thanks to the excellent support from Xilinx this problem has
been solved !!!
Turns out the Memec-Insight board had a 100 ohm (yes 100 !)
pull-up on the TDO line. That basically broke everything.

Removing the pullup, got rin of the CRC bit errors and chip-
scope appears to work now as well.

Thanks a lot for going the extra mile, to all the good folks
at Xilinx !

Kind Regards,
rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
 
Hi John,

I experienced some wired results on IO configurations as well. The reason was a
bug in the synplify synthesis tool. But it only happened for INOUT signals. It
resolved the signal connections simply somehow.

akuehn

meg wrote:
Hi,

I experience problems with some "normal" IO's(not dual purpose IO's) on
a Xilinx Virtex2p50ff1517. I observe that these IO change value during
configuration and after configuration these IO are not high impedance
as intended, but either high or low. These IO's are part of a
processor interface where the other IO on this bus is high impedance. I
have checked in FPGA Editor and find that there the "strange" IO's are
implemented exactly as the "normal" IO's (the same signal is driving
the output buffer).

Do any of you have any suggestion to what have gone wrong. Is the chip
damaged or is there something wrong with the configuration procedure. I
tried both slave-serial and JTAG programming but the behaviour is the same.

John
Click to expand...
 
"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag
news:cu9leb$rv5$1@nobel.pacific.net.sg...
Thanks to the excellent support from Xilinx this problem has
been solved !!!
Turns out the Memec-Insight board had a 100 ohm (yes 100 !)
pull-up on the TDO line. That basically broke everything.

Removing the pullup, got rin of the CRC bit errors and chip-
scope appears to work now as well.

Thanks a lot for going the extra mile, to all the good folks
at Xilinx !

Kind Regards,
rudi
Click to expand...
can you download with ChipScope as well after removing the pull-up ?
we can use ChipScope but can not download with it,
well I have not yet removed that pullup resistor

Antti
 
I also had the same problem before. What I did to solve this problem is
to include the system include/lib path BEFORE the project specific
include/lib path. This is accomplished with a custom Makefile and a
snippet of the Makefile is shown below:

#################################################################
# SOFTWARE APPLICATION TESTAPP
#################################################################

TestApp_program: $(TESTAPP_OUTPUT)

$(TESTAPP_OUTPUT) : $(TESTAPP_SOURCES) $(TESTAPP_HEADERS)
$(TESTAPP_LINKER_SCRIPT) \
$(LIBRARIES) __xps/testapp_compiler.opt
@mkdir -p $(TESTAPP_OUTPUT_DIR)
$(TESTAPP_CC) $(TESTAPP_CC_OPT) $(TESTAPP_SOURCES) -o
$(TESTAPP_OUTPUT) \
-IC:/EDK/gnu/microblaze/nt/microblaze/include \
-LC:/EDK/gnu/microblaze/nt/microblaze/lib \
$(TESTAPP_OTHER_CC_FLAGS) $(TESTAPP_INCLUDES) $(TESTAPP_LIBPATH) \
-xl-mode-$(TESTAPP_MODE) \
$(TESTAPP_CFLAGS) $(TESTAPP_LFLAGS)
$(TESTAPP_CC_SIZE) $(TESTAPP_OUTPUT)


As you can see, the system include/lib path is hardcoded and appears
BEFORE any other path. I know this is a hack, but it solves my problem
for now! :)

To invoke this makefile, use: "make -f Makefile TestApp_program" et
voila~!

Let me know if this helps you or if you need more help... :)


Jung Ko
 
This week the Actel FAEs came in to tell us about a problem with the
pro-ASIC plus chip. It seems the flash retention rate is much lower
than expected when using designer prior to 6.1 due to a load balancing
issue across transistors. Unfortunately, they don't have a write-up of
this problem on their website yet.
 
Hi Ann,

I'm not sure what you are trying to do, but maybe the techXclusives article
on reconfiguring block RAMs below will help.

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=krs_blockRAM

Philip Nowe
www.dulseelectronics.com

"Ann" <ann.lai@analog.com> wrote in message news:ee8b8e5.11@webx.sUN8CHnE...
Hi Gabor,

Did you remember how to do it? Do you have example code? I don't
understand the inputs and outputs in the example that I posted above. Is
it true that all I need is to put an instance of BSCAN in the code?
Click to expand...
 
Here's one more reference on the ALM. It was published at last year's FPL
conference.

Mike Hutton, Jay Schleicher, David Lewis, Bruce Pedersen, Richard Yuan,
Sinan Kaptanoglu, Gregg Baeckler, Boris Ratchev, Ketan Padalia, Mark
Bourgeault, Andy Lee, Henry Kim and Rahul Saini, "Improving FPGA Performance
and Area Using an Adaptable Logic Module", Proc. 14th International
Conference on Field-Programamble Logic, Leuven, Belgium, pp. 135-144, Sept
2004. LNCS 3203.


Paul Leventis
Altera Corp.



"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
news:joGdnWYVqLWB35XfRVn-vw@rogers.com...
Hi Glen,

I do wonder if the optimal LUT size has changed over the years.
Is there work showing the optimal LUT size as a function of silicon
resources needed to implement such LUTs?

Elias Ahmed & Jonathan Rose from the Unversity of Toronto published "The
Effect of LUT and Cluster Size on Deep-Submicron FPGA Performance and
Density". See http://www.eecg.toronto.edu/~jayar/pubs/ahmed/fpga00.pdf.
Elias's M.A.Sc. thesis was on clustering and optimal lut sizes. This
paper contains many references to previous work in the area and is
probably a good starting point. The paper's conclusion is that a LUT size
between 4 and 6 is and cluster sizes of between 3 and 10 LEs are best from
a balanced area-delay perspective. If you want higher speed, larger LUTs
are better. One suggested area of future research is finding a way to
reduce logic levels without the area cost of large LUTs -- and this is
what we have done in Stratix II with the ALM. Figure 12 is particularly
interesting.

I think Guy Lemieux had some work in this area from his PhD -- not sure if
its published anywhere yet.

At the FPGA 2005 conference in two weeks, the Stratix II logic
architecture and some experimental results will be presented in a paper by
David Lewis et al.

Regards,

Paul Leventis
Altera Corp.
Click to expand...
 
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com...
Dave Colson wrote:
Hi,


Would like to hear about any experiences that other people have had with
the
Actel
Flash parts.

I am meeting with a sales rep and FAE on these products tomorrow, opps,
today. My main concern is that they are not slated to be out until Q4
although I was told possibly Q3 (meaning end of Sept). I also want to
hear some real pricing instead of the "as low as xxx in quantity".

I was told that the larger parts would be out first. So if you want a
$1.50 part you will need to wait until '06, I expect.

The data sheet talks about being 5 volt tolerant, but they aren't. They
just do the same game of using resistors like the Virtex, etc. parts.

I don't see the pulldown on the TRST as being much of a bug myself. My
experience has been that every part handles the JTAG signals in
different, often incompatible ways. But if you use the spec'd pull ups
or downs and use their cable the JTAG should work just like TI DSPs and
Xilinx FPGAs.

I'll let you know what I find out from the FAE.
Click to expand...
Please do so!

The first part out is 600E that was known already at Electronica 2004 (that
is nov 2004)
hm are you saying no parts will be available til Q4 ? that would be pitty!

Most vendors dont admit silicon bugs! You need to prove their silicon is
faulty
then in some case with long delay they might agree yes there is a problem.

Antti
 
Hi,

"Dave Colson" <dscolson@rcn.com> wrote:
It bothers me that Actel will not admit problems with their devices. Xilinx
has no problem with admitting problems with devices and then publishing
a work around to the problem until a permanent fix to the silicon is
implemented.
Click to expand...
I'm not sure, but I think, the fact that Actel has mostly highpriced
devices means that the applications were the fpgas are used, are also
high valued.
This means that systematically failure tend to be more expensive for
Actel.

Would like to hear about any experiences that other people have had with the
Actel
Flash parts.
Click to expand...
I use some for prototyping and I am very satisfied with. The only wish
I had are 5V IO Buffer. Unfortunately there seems to be no
reprogrammable device with 5V IO and sufficient cells on market to do
prototyping for Asics with 5V IO.

bye Thomas
 
Thanks for Norm's request for clarification about the form in which
Samplify's sampled data compression is available.

While Samplify Systems is targeting the high-speed data acquisition and
signal processing markets that usually use DSP chips (from TI,
Freescale, Analog Devices, etc.) and FPGAs (from Xilinx and Altera), we
are happy to discuss other embedded target environments in which C
source code might be required.

Samplify is a low-MIPS algorithm that runs at 10+ Msamp/sec compression
and decompression rate using a 2 GHz Pentium. If your sampling rate
requirements are at lower sampling rates (lower than 2 Msamp/sec, for
example), or if you have non-realtime (offline) compression
requirements, please contact Samplify Systems at info@samplify.com to
discuss a port of Samplify compression to your particular target
environment.

Thanks,
Al

Norm Dresner wrote:
Since you've chosen to post this message in comp.arch.embedded, you
are
obviously aware that most of us here don't use Windows [in fact most
of the
readers of this NG don't even use Intel x86 architecture CPUs] -- you
are
aware of it, aren't you???

Anyway, since you've chosen to advertise this in a newsgroup
dedicated to a
very large variety of CPU architectures and operating systems, I'd
like to
know when you'll have a generic version (preferably source code)
available ?

Norm
Click to expand...
 
http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/fig26.htm
I build one according to this schematic and it works well with XC95144XL.
Click to expand...
thank you for your experience sharing. Do you know which version this cable
is? (II, III, IV ?) Does it make some difference in IMPACT?
 
Hi John,

I was able to both convert to pdf and to send directly to the printer
from the printing wizard in ChipScope. I've installed service pack 3 for
ChipScope 6.3, I don't know if that has anything to do with it... Might
be worth a try if you havn't.

I can email you some of my waveforms as pdf:s if that makes you happier.. =)

/Johan


John Williams wrote:

Hi,

I'm trying to print a waveform from ChipScope Pro 6.3 under Windows.

I have a waveform window open, and a printer selected, however when I
try to select the "Print" option from the File menu, nothing happens.
It's quite strange - after the mouse hovers on the "Print" menu item for
about a quarter of a second, a small gray square (maybe 3x3 pixels?)
appears next to it. No amount of clicking can cause the Print wizard
to launch.

Anyone seen this and know a workaround?

Thanks,

John
Click to expand...

--
-----------------------------------------------
Johan Bernspĺng, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------
 
517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:

Can anyone tell me embedding of SUBJ? I've tried a lot of
methods(recommendations in G.704(1998&1995); i've read the theory of
CRC calculating and made some entities but CRC from my E1 tester
doesn't match with mine. I've tried another tester - no changes).

There's nothing wrong with the G.704 specification, and there's
nothing wrong with the E1 testers.

You have a bug.

You might need to tell us something about your implementation before
we can help.

Regards,
Allan
I know :) But there is also the G.706 recommendnation and there is
Click to expand...
another algorithm. there is {CRC computed by G.704} XORed with {CRC
computed with Sa4(new) bits XORed with Sa4(previous) bits}.

i've also tried to divide the initial SMF(with C bits set to
zero)complemented with 4 zero bits by the 10011 polynom using XOR
rules and insert the residue of division into C bits as shown in
G.704.

I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
i didn't foget to reset triggers after SMF and set C bits to zero when
fed it to this scheme.
 
517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:

Can anyone tell me embedding of SUBJ? I've tried a lot of
methods(recommendations in G.704(1998&1995); i've read the theory of
CRC calculating and made some entities but CRC from my E1 tester
doesn't match with mine. I've tried another tester - no changes).

There's nothing wrong with the G.704 specification, and there's
nothing wrong with the E1 testers.

You have a bug.

You might need to tell us something about your implementation before
we can help.

Regards,
Allan
can you place a verilog or any HDL text(or schematic as a picture) realizing
Click to expand...
the CRC4 algorithm?
 
On Fri, 18 Feb 2005 14:33:36 +0300, "Michael Polovykh"
<kefir@rissa.ru> wrote:

517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:

Can anyone tell me embedding of SUBJ? I've tried a lot of
methods(recommendations in G.704(1998&1995); i've read the theory of
CRC calculating and made some entities but CRC from my E1 tester
doesn't match with mine. I've tried another tester - no changes).

There's nothing wrong with the G.704 specification, and there's
nothing wrong with the E1 testers.

You have a bug.

You might need to tell us something about your implementation before
we can help.

Regards,
Allan
I know :) But there is also the G.706 recommendnation and there is
another algorithm. there is {CRC computed by G.704} XORed with {CRC
computed with Sa4(new) bits XORed with Sa4(previous) bits}.

i've also tried to divide the initial SMF(with C bits set to
zero)complemented with 4 zero bits by the 10011 polynom using XOR
rules and insert the residue of division into C bits as shown in
G.704.

I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
i didn't foget to reset triggers after SMF and set C bits to zero when
fed it to this scheme.
Click to expand...
A useful technique is to work through the algorithm on paper (or a
spreadsheet, etc.). That way, you separate your understanding of the
algorithm from any bugs you might have in your implementation.
It's only a 4 bit CRC, so it shouldn't take to long to do by hand.

(See this recent c.a.f thread for an example:
http://groups-beta.google.com/group/comp.dcom.sdh-sonet/browse_frm/thread/972c354699ba8391
)

Regards,
Allan
 
517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:8klb11hi4jqsnkaci10im0s5ih31tm8at8@4ax.com...
On Fri, 18 Feb 2005 14:33:36 +0300, "Michael Polovykh"
kefir@rissa.ru> wrote:

517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:

Can anyone tell me embedding of SUBJ? I've tried a lot of
methods(recommendations in G.704(1998&1995); i've read the theory of
CRC calculating and made some entities but CRC from my E1 tester
doesn't match with mine. I've tried another tester - no changes).

There's nothing wrong with the G.704 specification, and there's
nothing wrong with the E1 testers.

You have a bug.

You might need to tell us something about your implementation before
we can help.

Regards,
Allan
I know :) But there is also the G.706 recommendnation and there is
another algorithm. there is {CRC computed by G.704} XORed with {CRC
computed with Sa4(new) bits XORed with Sa4(previous) bits}.

i've also tried to divide the initial SMF(with C bits set to
zero)complemented with 4 zero bits by the 10011 polynom using XOR
rules and insert the residue of division into C bits as shown in
G.704.

I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
i didn't foget to reset triggers after SMF and set C bits to zero when
fed it to this scheme.

A useful technique is to work through the algorithm on paper (or a
spreadsheet, etc.). That way, you separate your understanding of the
algorithm from any bugs you might have in your implementation.
It's only a 4 bit CRC, so it shouldn't take to long to do by hand.

(See this recent c.a.f thread for an example:
http://groups-beta.google.com/group/comp.dcom.sdh-sonet/browse_frm/thread/972c354699ba8391
)

Regards,
Allan
Click to expand...
Where can I take the shot bit consecution with true crc4 to compare with CRC
computed by myself?
 
Thanks glen for the response, but what about making the program stop completely and pop up a message that says something like "ERROR", is there a way to implement that? I have tried using "disable" but that won't compile, I think it was unsupported or something. Thanks, Ann
 
"AL" <ann.lai@analog.com> wrote in message news:ee8bf07.1@webx.sUN8CHnE...
Thanks glen for the response, but what about making the program stop
completely and pop up a message that says something like "ERROR", is there a
Click to expand...
way to implement that? I have tried using "disable" but that won't compile,
I think it was unsupported or something. Thanks, Ann

What program?
Verilog describes the layout of hardware. I suppose you could connect all of
your I/O pins to ground (or use tri-state and disconnect them), but you
can't stop electrons moving in the wires!

Alun Harford
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top