Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 120025

Article: 120025
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: Brian Davis <brimdavis@aol.com>
Date: 31 May 2007 04:33:20 -0700
Links: << >>  << T >>  << A >>
John_H  wrote:
>
> Brian, I always appreciate a well-considered discussion and hope to look
> at the T-coil references.  Beyond these references I don't know that the
> rest of the discussion does much more than stir the bees nest though I
> do also appreciate the perspective from the curve tracer.
>
 If you really believe "Cin doesn't matter", and that all drivers are
perfectly balanced with ideal back terminations, then best of luck
with
your high speed designs; somehow, I suspect you are more pragmatic.

>
> Austin, I'm sure you want to retort.  Could you let this one go by
> without a response?  It's feeling old.
>
 What I find old is vendor employees continuing to make known
false or misleading claims like "(We) meet all specs and standards",
"Cin doesn't matter",  and "but it's really Cin/2".

 If I occasionally point out the real-world issues on a thread where
the subject comes up, it's only after I've counted slowly backwards
from 200 by two's and deleted most of my original response.

Brian


Article: 120026
Subject: Re: Nexys by Digilen xbd file
From: cs_posting@hotmail.com
Date: 31 May 2007 06:42:41 -0700
Links: << >>  << T >>  << A >>
On May 30, 1:36 pm, austin <aus...@xilinx.com> wrote:
> Heck, we (APD FPGA Lab) have purchased Digilent boards for use here at
> Xilinx in the past!  A lot cheaper than fiddling with making something
> ourselves.
>
> Once a board exists from a vendor, no reason to re-invent the wheel.

Glad to hear a logic company is open to the logical solution.

My comment though was more that for a relatively interesting and
extremely inexpensive board, Nexys seems to have a very small user
base.  Search this newsgroup on it, and there's only a very few
threads - wheras there are many mentions of the S3 kit, S3E, etc
boards.  I was speculating that perhaps the difference there was that
those are Digilent boards which Xilinx promotes, wheras Nexys is
Digilent operating only on its own.

The practical impact of this is that while a user can benefit a lot
from others work on the more popular boards - downloaded project
skeletons, solutions, and general advice, for the less popular boards
they are on their own... or nominated to blaze the trail.





Article: 120027
Subject: Chain of LUTs is being removed during par
From: axr0284 <axr0284@yahoo.com>
Date: 31 May 2007 06:47:22 -0700
Links: << >>  << T >>  << A >>
Hi,
 I want to test what kind of delay is introduced by having an input go
through 1000 LUT1 primitive in a Spartan3E FPGA. I am using ISE 9.1 to
synthesize this but during map, it seems that it is optimizing the
LUTs out although these were instantiated as primitives. Is there any
way to force ISE to keep these. The design is as follows:
[CODE]
library IEEE;
use IEEE.STD_LOGIC_1164.all;

-- Synthesis TRANSLATE_OFF
library SPARTAN3E;
use SPARTAN3E.VPKG.all;
use SPARTAN3E.VCOMPONENTS.all;
-- Synthesis TRANSLATE_ON

entity delay_luts is
	 port(
		 input : in STD_LOGIC;
		 output : out STD_LOGIC
	     );
end delay_luts;

--}} End of automatically maintained section

architecture delay_luts of delay_luts is

CONSTANT number_of_delay : INTEGER := 1000;
component LUT1 is
  generic(INIT : bit_vector := X"0");

  port(
    O : out std_ulogic;
    I0 : in std_ulogic);
end component;

signal internal_signal : STD_LOGIC_VECTOR(number_of_delay-1 downto 0);
begin
	delay_element_first : LUT1
 		generic map(INIT => X"2")
	  	port map(
	    	O => internal_signal(0),
	    	I0 => input
		);

	-- enter your statements here --
	delay : for N in 0 to number_of_delay-2 GENERATE
		delay_element_middle : LUT1
  			generic map(INIT => X"2")
		  	port map(
		    	O => internal_signal(N+1),
		    	I0 => internal_signal(N)
			);
	end GENERATE delay;

	delay_element_last : LUT1
 		generic map(INIT => X"2")
	  	port map(
	    	O => output,
	    	I0 => internal_signal(number_of_delay-1)
		);
end delay_luts;
[/CODE]
Thanks,
Amish


Article: 120028
Subject: Re: PacoBlaze 2.2
From: "dscolson@rcn.com" <dscolson@rcn.com>
Date: 31 May 2007 07:04:33 -0700
Links: << >>  << T >>  << A >>
On May 30, 8:14 pm, Pablo Bleyer Kocik <pabloble...@hotmail.com>
wrote:
> On May 30, 4:14 pm, "dscol...@rcn.com" <dscol...@rcn.com> wrote:
>
> > Pablo,
>
> > I was also wondering if you fixed the issues with the assembler that I
> > wrote to you about last June?
>
> > >From email sent to you.
>
>  Hello Dave.
>
>  Yes, these issues have been fixed. The assembler now accepts bounded
> '()' tokens; just as a visual convenience since they are converted to
> regular arguments. The default format is now hexadecimal. If a name is
> not found in the environment, and if that word is a valid hex number,
> it gets converted to the latter. It's a shame the kcpsm assembler
> treats numbers these way, it is not the default format of most
> assemblers, and usually numbers in a different radix are decorated in
> some way to avoid confusion or a clash with valid labels. KCAsm
> supports binary (%) octal (@), decimal (&), and hexadecimal ($)
> modifiers.
>
>  KCAsm still accepts names only in valid C format - the identifiers
> can't start with a number or symbol different to the underscore (_).
>
>  Please tell me if you find other issues.
>
>  Best regards.
>
> --
> PabloBleyerKocik /"But what... is it good for?"
>  pablo          / -- 1968 Engineer at IBM's Advanced Computing
>   @bleyer.org  / Systems Division, commenting on the microchip

Pablo,

Thanks for the fixes. However, I Just found another "bug" more of a
compatibility issue. KCPSM allows the following renaming of registers
as follows:
first namereg
namereg		s4, 	clkcnt 		; temp register
:
:
later renamed S4. however, KCPSM requires you use the name you renamed
S4 to previously.

namereg		clkcnt,		DIFF0	;

Here is the output of KCasm
I don't know if this one will be an easy one the fix.

C:\clcfpga2\PACOBL~1.2\test>asmkcpsm isp

C:\clcfpga2\PACOBL~1.2\test>java -Dkcpsm=3 -Dbram=18 -Dmodule=isp -jar
c:/clcfpga2/pacoblaze-
2.2/KCAsm.jar isp.psm isp.rmh
Exception in thread "main" java.lang.IllegalArgumentException: Bad
register declaration: name
reg(clkcnt,DIFF0) at line 1358
        at Assembler.parse(Assembler.java:155)
        at Assembler3.<init>(Assembler3.java:55)
        at KCAsm.main(KCAsm.java:48)

C:\clcfpga2\PACOBL~1.2\test>

Best regards

Dave


Article: 120029
Subject: Re: Chain of LUTs is being removed during par
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 31 May 2007 14:07:05 GMT
Links: << >>  << T >>  << A >>
Since it looks like you're instantiating the LUTs, two things:
   1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the 
LUTs; check the constraints guide for the current syntax.
   2) To avoid pulse-width compression (different delays for opposite 
transitions) invert the signal at each LUT so the end result is normal 
but every-other LUT is inverted.


axr0284 wrote:
> Hi,
>  I want to test what kind of delay is introduced by having an input go
> through 1000 LUT1 primitive in a Spartan3E FPGA. I am using ISE 9.1 to
> synthesize this but during map, it seems that it is optimizing the
> LUTs out although these were instantiated as primitives. Is there any
> way to force ISE to keep these. The design is as follows:
> [CODE]
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> 
> -- Synthesis TRANSLATE_OFF
> library SPARTAN3E;
> use SPARTAN3E.VPKG.all;
> use SPARTAN3E.VCOMPONENTS.all;
> -- Synthesis TRANSLATE_ON
> 
> entity delay_luts is
> 	 port(
> 		 input : in STD_LOGIC;
> 		 output : out STD_LOGIC
> 	     );
> end delay_luts;
> 
> --}} End of automatically maintained section
> 
> architecture delay_luts of delay_luts is
> 
> CONSTANT number_of_delay : INTEGER := 1000;
> component LUT1 is
>   generic(INIT : bit_vector := X"0");
> 
>   port(
>     O : out std_ulogic;
>     I0 : in std_ulogic);
> end component;
> 
> signal internal_signal : STD_LOGIC_VECTOR(number_of_delay-1 downto 0);
> begin
> 	delay_element_first : LUT1
>  		generic map(INIT => X"2")
> 	  	port map(
> 	    	O => internal_signal(0),
> 	    	I0 => input
> 		);
> 
> 	-- enter your statements here --
> 	delay : for N in 0 to number_of_delay-2 GENERATE
> 		delay_element_middle : LUT1
>   			generic map(INIT => X"2")
> 		  	port map(
> 		    	O => internal_signal(N+1),
> 		    	I0 => internal_signal(N)
> 			);
> 	end GENERATE delay;
> 
> 	delay_element_last : LUT1
>  		generic map(INIT => X"2")
> 	  	port map(
> 	    	O => output,
> 	    	I0 => internal_signal(number_of_delay-1)
> 		);
> end delay_luts;
> [/CODE]
> Thanks,
> Amish

Article: 120030
Subject: Re: Nexys by Digilen xbd file
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Thu, 31 May 2007 14:16:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:

: My comment though was more that for a relatively interesting and
: extremely inexpensive board, Nexys seems to have a very small user
: base.  Search this newsgroup on it, and there's only a very few
: threads - wheras there are many mentions of the S3 kit, S3E, etc
: boards.  I was speculating that perhaps the difference there was that
: those are Digilent boards which Xilinx promotes, wheras Nexys is
: Digilent operating only on its own.

The Nexys has to be about my favourite board - compact, dirt cheap (even 
with the S3-1000 part), the same pinout FX2 header as their other boards 
(with 6 extra IOs even) and the key point for me is the Cypres EZ-USB 
device on the board has all the key pins conencted to produce your own 
USB interface using the FPGA and the Cypress part.

Other boards from Digilent are now using the Xilinx USB cable firmware, 
redacting the schematics and (presumably) not connecting the main data 
ports, which is a shame as having a decent on-board USB2 interface is a 
major time/hastle saver for me.  (Thinly disguised whinge about their 
S3E starter board... :-)

Cheers
cds



Article: 120031
Subject: Spartan 3E Starter Kit and EDK 8.2
From: thomas.b36@gmail.com
Date: 31 May 2007 07:28:52 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm trying to build and test a simple project for Spartan 3E Starter
Kit rev D (S3ESK) board using Xilinx EDK tool and using the BSB
wizard. The project is the auto generated peripherals test. These
peripherals are simply a 8 LEDs, 4 DIP Switches, 4 Push Buttons and a
UART lite. The problem is that when I use EDK 8.2 the project compile
and load to the FPGA without any error but it simply does nothing.
But, if I use EDK 8.1 then the test does what it suppose to do (print
on the uart, read  switches state and flash a leds). I've tried it out
on 2 different PC's. I even try to use the BSB but with the "I would
like to create a system from a custom board" option, but it didn't
help.

Is there any known bug related to edk8.2 and S3ESK or I should do some
special steps to get it work with EDK 8.2????


Article: 120032
Subject: Re: Nexys by Digilen xbd file
From: cs_posting@hotmail.com
Date: 31 May 2007 07:30:20 -0700
Links: << >>  << T >>  << A >>
On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter)
wrote:

> The Nexys has to be about my favourite board - compact, dirt cheap (even
> with the S3-1000 part), the same pinout FX2 header as their other boards
> (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB
> device on the board has all the key pins conencted to produce your own
> USB interface using the FPGA and the Cypress part.

Yes... in theory.  But have you gotten it working yet?

It's not a problem with the board, it's just that getting the fx2 all
ready to go is a non-trivial exercise, and most existing open source
projects for it do some wierd things, require oddbal build
environments rather than simply the SDCC complier on its own, want to
do the host side in python, etc...  What happened to good old C and
Makefiles?

I did manage to get the FPGA programmed through the USB using some
modified open source programming tools, but then had to put it back on
the shelf to work on other things before I could get the data
flowing.  Would be great if there were a simple, open, framework for
doing USB data communication (firmware stub + fpga code stub + libusb
host code)


Article: 120033
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 31 May 2007 07:41:29 -0700
Links: << >>  << T >>  << A >>
John,

No, I am tied of the ranting.  Fact is, it works.

Also, there were some customers that had really bad experiences trying
to make their boards work.

Far be it from me to suggest that these folks did something wrong, but I
have to wonder why other customers have this working.

All I can say is that we have demo boards, with network interfaces,
running at DDR rates of 800 Mbs, and on V5, at 1 Gbs.  So, it is more
than a data sheet claim, it is working, proven across PVT, with HDL
code; solutions.

Austin

Article: 120034
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 31 May 2007 14:46:42 GMT
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> John_H  wrote:
>> Brian, I always appreciate a well-considered discussion and hope to look
>> at the T-coil references.  Beyond these references I don't know that the
>> rest of the discussion does much more than stir the bees nest though I
>> do also appreciate the perspective from the curve tracer.
>>
>  If you really believe "Cin doesn't matter", and that all drivers are
> perfectly balanced with ideal back terminations, then best of luck
> with
> your high speed designs; somehow, I suspect you are more pragmatic.
> 
>> Austin, I'm sure you want to retort.  Could you let this one go by
>> without a response?  It's feeling old.
>>
>  What I find old is vendor employees continuing to make known
> false or misleading claims like "(We) meet all specs and standards",
> "Cin doesn't matter",  and "but it's really Cin/2".
> 
>  If I occasionally point out the real-world issues on a thread where
> the subject comes up, it's only after I've counted slowly backwards
> from 200 by two's and deleted most of my original response.
> 
> Brian

Cin matters but - in a properly designed system - it doesn't matter so 
much.  If the impedances in the system - source, transmission line, 
receiver - are crap, then the C will have a huge impact.  Since the 
transmitters will tend to have high C as well in Xilinx transmitters, 
reflections should be expected.

One thing you appear to rely on from previous posts is probing of the 
signal at a point external to the receiver silicon, the only place 
practical to probe.  This will always result in a signal that's worse 
than the actual received signal when high Cs (or other impedance 
mismatches) are involved.

Since these are digital systems, *some* reflections are acceptable. 
Having a signal without extremely well defined highs and lows are 
typically acceptable.  The impact on the time-domain is where the 
interference will often be noted the most and transmission systems with 
much better analog performance (including the C and R termination 
values) are required to maintain a low phase noise.

It really is C/2 for those who are thinking 100 ohm impedance.  It 
really is C for those who are thinking 50 ohm impedance.  Where are 
peoples' minds normally on the impedance for LVDS?  There are no lies here.

I've been impressed with an engineer's approach within my own company to 
try to reduce common-mode artifacts and EMC issues by filtering from the 
midpoint of the differential termination.  It becomes less obvious why a 
well-matched C value is so critical when his termination scheme is 
scrutinized.  I was impressed.

Your real-world issues are flavored by the way you observe your system. 
  The SI results will often provide much better response than your 
practical observations.  That appears to be a thorn in Austin's side in 
the same way his C/2 "claims" are a thorn in yours.

I have always found your responses to be well considered and sincerely 
appreciate your self-editing: a rare talent on a forum like this.

While you may hate the impairments induced by the LVDS transceivers that 
are hampered by a design that supports multiple I/O standards, it 
impresses the hell out of me just how open the data eyes are in the 
chip.  Take a sample of your high-speed data with a carry-chain as a 
delay element and accumulate.  You'll see how good or bad the 
time-domain is.  You can futz with the common-mode, add an offset to the 
differential, or reduce the transmitter swing to see when and how this 
eye starts to break down.

I love that a 600 Mbit link in the "cheap" S3E devices hampered not by 
one but by TWO DCMs can result in an eye that's still half open; I could 
blame just about all of that mess on the DCMs, not the LVDS transceivers.

- John_H

Article: 120035
Subject: Re: Nexys by Digilen xbd file
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Thu, 31 May 2007 14:48:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:
: On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter)
: wrote:

: > The Nexys has to be about my favourite board - compact, dirt cheap (even
: > with the S3-1000 part), the same pinout FX2 header as their other boards
: > (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB
: > device on the board has all the key pins conencted to produce your own
: > USB interface using the FPGA and the Cypress part.

: Yes... in theory.  But have you gotten it working yet?

Yup.  Mind you I'm only using it for a high speed data interface and not 
trying to get the JTAG working - from my viewpoint the board has a 
perfectly good JTAG header on it and Digilent do cheap and functional 
USB2 JTAG cables...

: It's not a problem with the board, it's just that getting the fx2 all
: ready to go is a non-trivial exercise, and most existing open source
: projects for it do some wierd things, require oddbal build
: environments rather than simply the SDCC complier on its own, want to
: do the host side in python, etc...  What happened to good old C and
: Makefiles?

I looked at using open source code and SDCC, but couldn't face it.  Why 
make life complicated...

Cypress provide some decent example projects for use with the Keil tools, 
and a download of a limited version of uVision / C51 etc. with commercial 
and code size restrictions.   Using those tools you can get things running 
quite rapidly by modifying the example projects.  The EZ-USB device isn't 
the simplest thing in the world though.  I'd not be comfortable 
distributing any code built with SDCC as everyone seems to use the 
fx2regs.h file written and (C) by Keil.  (Nothing to stop someone 
producing their own from the monumental tech. ref manual)

: I did manage to get the FPGA programmed through the USB using some
: modified open source programming tools, but then had to put it back on
: the shelf to work on other things before I could get the data
: flowing.  Would be great if there were a simple, open, framework for
: doing USB data communication (firmware stub + fpga code stub + libusb
: host code)

Again I used their CyUsb windows driver as there was then example code to 
work from.  Even if you want to end up with a FOSS stack it's worth 
starting with the Keil tools and CyUsb / MSVC as otherwise there are to 
many unknowns and pitfalls.

---
cds

Article: 120036
Subject: Re: ISE/EDK Kubuntu linux installation issues
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 31 May 2007 10:53:08 -0400
Links: << >>  << T >>  << A >>
Thanks a lot Ken!

> Depending what version of Kubuntu you're running, you may have other 
> troubles.  For example, if you get errors referencing GLIBC you need
> to set the environment variable LD_ASSUME_KERNEL=2.4.7 (this is not a
> problem in recent releases of ISE/EDK).

I am running Kubuntu 7.04, 32-bit version and the 9.1 version of the Xilinx 
tools. I don't recall seeing this error...

> Getting a download cable to work is also a treat.  I recommend ignoring 
> the Xilinx drivers and use the userspace driver from:
>
> http://www.rmdir.de/~michael/xilinx/

That's really a great advice! I was just in the middle of the process of 
trying to install Xilinx drivers :) Hopefully I haven't broken anything yet 
by half-working scripts :)

> I have it working for impact, chipscope analyzer, and XMD, at least
> in all modes I actually use.  I can elaborate further all the fun I
> had getting it to work on a 64-bit system, if that's something you'll
> need (post here but CC my email to be sure I see it; I don't check
> every day).

It's interesting. I was told in the past by Xilinx that EDK wasn't working 
on 64-bit systems... Have they fixed it in 9.1 or have you found a 
workaround?

> In any case, it works great on my Linux boxen which is a relief since
> EDK does not get along with my laptop at all (multiple applications
> built on top of Cygwin are not playing nice at all).
>
> Good luck, and drop me a note if you need more help.

Thanks again,
/Mikhail 



Article: 120037
Subject: Re: Xilinx Seminars in Wiesbaden, Berlin, Hannover
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 31 May 2007 15:21:42 GMT
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:f3khoi$siu13@cnn.xilinx.com...
> Hans,
>
> Like the joke here about attending UC Berkeley in the late 1960's
> ("summer of love"):  "if you can remember it, you weren't here."
>
> By the way, I was (for a short time) a counselor for the BCIPD (Berkeley
> Committee for Information on Psychedelic Drugs):  one of the great
> crimes, and wastes of good minds was the abuse of both legal, and
> illegal drugs by the youth of that time.  These poor souls are now
> cluttering up the mental hospitals, or wandering the streets, and have
> become a burden to society.
>
> Not that I have any solution to this (continuing) problem, but I at
> least had the chance to talk to people and try to convince them not to
> turn their brains into soup.
>
> I am also fortunate I survived.
>
> Austin

Hi Austin,

I wasn't serious, most people associate Amsterdam with drugs which is 
obviously a distorted view. To be honest, I was actually quite a boring 
non-smoking, non-drinking, non-drug taking nerd that spend most of his time 
studying and playing with his AppleII+............. oh well, at least I 
ended up with a great job :-)

Drugs (mainly alcohol here in the UK) it is indeed a serious problem but I 
am afraid that even if there was a solution nobody would take notice of it,

Regards,
Hans.
www.ht-lab.com



Article: 120038
Subject: Re: Chain of LUTs is being removed during par
From: axr0284 <axr0284@yahoo.com>
Date: 31 May 2007 08:31:29 -0700
Links: << >>  << T >>  << A >>
On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote:
> Since it looks like you're instantiating the LUTs, two things:
>    1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the
> LUTs; check the constraints guide for the current syntax.
>    2) To avoid pulse-width compression (different delays for opposite
> transitions) invert the signal at each LUT so the end result is normal
> but every-other LUT is inverted.


Thanks for the answer. I used the following to force ISE to keep the
LUTs:
attribute keep : string;
attribute keep of internal_signal: signal is "true";

I am this "pulse width compression" and I am wondering why that
occurs. Is it possible to give me a more in depth explanation or point
me to some website that has the info. Thanks.
Amish


Article: 120039
Subject: Re: Spartan 3E Starter Kit and EDK 8.2
From: Pablo <pbantunez@gmail.com>
Date: 31 May 2007 08:36:41 -0700
Links: << >>  << T >>  << A >>
On 31 mayo, 16:28, thomas....@gmail.com wrote:
> Hi,
>
> I'm trying to build and test a simple project for Spartan 3E Starter
> Kit rev D (S3ESK) board using Xilinx EDK tool and using the BSB
> wizard. The project is the auto generated peripherals test. These
> peripherals are simply a 8 LEDs, 4 DIP Switches, 4 Push Buttons and a
> UART lite. The problem is that when I use EDK 8.2 the project compile
> and load to the FPGA without any error but it simply does nothing.
> But, if I use EDK 8.1 then the test does what it suppose to do (print
> on the uart, read  switches state and flash a leds). I've tried it out
> on 2 different PC's. I even try to use the BSB but with the "I would
> like to create a system from a custom board" option, but it didn't
> help.
>
> Is there any known bug related to edk8.2 and S3ESK or I should do some
> special steps to get it work with EDK 8.2????

Use ISE flow to implement this. I don't know why but I had the same
problem in virtexIIPro.
Another option is to look the bitgen.ut.


Article: 120040
Subject: Re: Chain of LUTs is being removed during par
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 31 May 2007 15:50:36 GMT
Links: << >>  << T >>  << A >>
axr0284 wrote:
> On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote:
>> Since it looks like you're instantiating the LUTs, two things:
>>    1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the
>> LUTs; check the constraints guide for the current syntax.
>>    2) To avoid pulse-width compression (different delays for opposite
>> transitions) invert the signal at each LUT so the end result is normal
>> but every-other LUT is inverted.
> 
> 
> Thanks for the answer. I used the following to force ISE to keep the
> LUTs:
> attribute keep : string;
> attribute keep of internal_signal: signal is "true";
> 
> I am this "pulse width compression" and I am wondering why that
> occurs. Is it possible to give me a more in depth explanation or point
> me to some website that has the info. Thanks.
> Amish

I don't have references, only experience.  The Tphl and Tplh numbers for 
a digital element (Time of Propagation for High-to-Low or Low-to-High 
transitions) are slightly different given the nature of asymmetric slew 
rates, DC logic levels, and switch points.  It's only noticeable in 
high-speed logic or when many elements are chained together.  In your 
case, a 4 ns pulse traveling through your 1k LUT chain will probably 
either come out as no pulse or as 10s of ns.

If you search for tphl and tplh, you might find hits on data sheets that 
specify the two values or a difference between the two.

Article: 120041
Subject: Re: Chain of LUTs is being removed during par
From: Peter Alfke <peter@xilinx.com>
Date: 31 May 2007 09:17:04 -0700
Links: << >>  << T >>  << A >>
Among the many thousands of tests performed on every chip before it
leaves the factory, are propagation delay tests of highly concatenated
LUTs. So, you are in good company...
Peter Alfke, Xilinx Applications


On May 31, 8:50 am, John_H <newsgr...@johnhandwork.com> wrote:
> axr0284 wrote:
> > On May 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote:
> >> Since it looks like you're instantiating the LUTs, two things:
> >>    1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the
> >> LUTs; check the constraints guide for the current syntax.
> >>    2) To avoid pulse-width compression (different delays for opposite
> >> transitions) invert the signal at each LUT so the end result is normal
> >> but every-other LUT is inverted.
>
> > Thanks for the answer. I used the following to force ISE to keep the
> > LUTs:
> > attribute keep : string;
> > attribute keep of internal_signal: signal is "true";
>
> > I am this "pulse width compression" and I am wondering why that
> > occurs. Is it possible to give me a more in depth explanation or point
> > me to some website that has the info. Thanks.
> > Amish
>
> I don't have references, only experience.  The Tphl and Tplh numbers for
> a digital element (Time of Propagation for High-to-Low or Low-to-High
> transitions) are slightly different given the nature of asymmetric slew
> rates, DC logic levels, and switch points.  It's only noticeable in
> high-speed logic or when many elements are chained together.  In your
> case, a 4 ns pulse traveling through your 1k LUT chain will probably
> either come out as no pulse or as 10s of ns.
>
> If you search for tphl and tplh, you might find hits on data sheets that
> specify the two values or a difference between the two.



Article: 120042
Subject: Re: Ise Flow with PowerPC
From: Joseph Samson <jsamson@the-company-name.com>
Date: Thu, 31 May 2007 12:31:39 -0400
Links: << >>  << T >>  << A >>
Pablo wrote:
> Hi, I am very interesting in how could I use ISE to create a PowerPC
> model. 

<snip>

> But I cannot see the complete vhdl code. For example I cannot see the
> code from the dcm_module, the code from the util_vector_module, etc.
> 
> I know that quite a lot designers use this ISE Flow, but how can they
> see the complete project in vhdl.

The VHDL for the EDK IP is not available. You can go to 
$XILINX_EDK/hw/XilinxProcessorIPLib/pcores to see the IP that can be 
instantiated from EDK. There are VHDL wrappers that instantiate black 
boxes. In some cases (plb_ethernet) there is encrypted VHDL.

---
Joe Samson
Pixel Velocity

Article: 120043
Subject: Re: Ise Flow with PowerPC
From: Pablo <pbantunez@gmail.com>
Date: 31 May 2007 09:42:00 -0700
Links: << >>  << T >>  << A >>
On 31 mayo, 18:31, Joseph Samson <jsam...@the-company-name.com> wrote:
> Pablo wrote:
> > Hi, I am very interesting in how could I use ISE to create a PowerPC
> > model.
>
> <snip>
>
> > But I cannot see the complete vhdl code. For example I cannot see the
> > code from the dcm_module, the code from the util_vector_module, etc.
>
> > I know that quite a lot designers use this ISE Flow, but how can they
> > see the complete project in vhdl.
>
> The VHDL for the EDK IP is not available. You can go to
> $XILINX_EDK/hw/XilinxProcessorIPLib/pcores to see the IP that can be
> instantiated from EDK. There are VHDL wrappers that instantiate black
> boxes. In some cases (plb_ethernet) there is encrypted VHDL.
>
> ---
> Joe Samson
> Pixel Velocity

So the only thing I could edit is the system_stub.vhd and the
system.vhd with inputs and outputs. Cores couldn't be edited. Correct
me?


Article: 120044
Subject: Re: Xilinx Seminars in Wiesbaden, Berlin, Hannover
From: austin <austin@xilinx.com>
Date: Thu, 31 May 2007 09:55:41 -0700
Links: << >>  << T >>  << A >>
Hans,

I too, was a boring, slide rule toting Engineering "nerd."

As I walked across campus, the Alameda County Sheriffs ("Blue Meanies)
would be drinking their coffee with their dough nuts, remarking "good
day for a riot, isn't it?"

Go read "People's Park" on Wikipedia for a fairly well written
historical account of those days.

Austin

Article: 120045
Subject: Re: Problems to simulate (behavioural) in XPS
From: ferorcue <le_marq@hotmail.com>
Date: 31 May 2007 10:01:22 -0700
Links: << >>  << T >>  << A >>
On May 29, 12:17 pm, "CTU FEE Jan Krakora"
<krak...@control.felk.cvut.cz> wrote:
> To specify the problem, I thought the "Fatal: (vsim-3348)" one. Sorry Jan

hi Jan,

I still have the problem. I am using linux (debian) and the people
from xilinx told me today, that debian it is not supported, Only Red
Hat Enterprise 3. But this is very weird because I am using it, and it
works normally, the only think that is not working is the simulation
in modelsim.

I told one of my supervisors and he told me that he thinks that our
problem is not a problem of operating system or EDK, he thinks that it
is a problem of Modelsim. But I dont know how to solve it.

I will continue trying to solve the problem, if you get a solution,
please let me know


Article: 120046
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: Brian Davis <brimdavis@aol.com>
Date: 31 May 2007 10:23:45 -0700
Links: << >>  << T >>  << A >>
Austin wrote:
>
> No, I am tied of the ranting.
>
 And I am tired of your marketing misdirections.

>
> Also, there were some customers that had really bad experiences trying
> to make their boards work.
>
> Far be it from me to suggest that these folks did something wrong,
> but I have to wonder why other customers have this working.
>
 My boards work great, because I know when and how to be cautious
when driving FPGA inputs from fast logic.

 When's the last time YOU actually designed a PCB?

 The boards I've had problems with have been various
Xilinx sanctioned "high speed" boards, with terminators
hanging off big stubs, or similar mistakes [1].

>
> All I can say is that we have demo boards, with network interfaces,
> running at DDR rates of 800 Mbs, and on V5, at 1 Gbs.  So, it is more
> than a data sheet claim, it is working, proven across PVT, with HDL
> code; solutions.
>
 But where are your simulations and real-world test data [2] ?

 Take a look at XAPP774 and the associated board schematics
for TI's ADS5273 EVB combo <sbau091.pdf> and <sbau093a.pdf>

 Where are the IBIS sims or real-world plots of input signal
timing and margin when driving the FPGA?

 As I pointed out last spring, driving 10 pF Cin from an
ADS5273 without back termination is a recipe for disaster [3].

 And if you ever have the technical integrity to post a link
to your 'works fine' IBIS simulation, I'd be happy to explain
the mistakes you made when you penned these nasty remarks [4]:
>
> I don't know about anyone else, but it works fine, and posts
> like this of sims poorly done are not helpful to anyone.
>
> I am sorry I took your posting seriously enough to do a real
> simulation and show that there is no problem (which I knew
> already from the customers that are using our parts successfully).
>

Brian

[1] Big stubs on ML450 HyperTransport interface
 http://groups.google.com/group/comp.arch.fpga/msg/3654e1982a62ea81

[2] V4 thread looking for real-world measurements
 http://groups.google.com/group/comp.arch.fpga/msg/3dc2fc501b48d9b7

[3] updated ADS5273 simulation, IBIS vs. simple SPICE model
 http://groups.google.com/group/comp.arch.fpga/msg/5a8720eec942612e

[4] Austin's attacks on my ADS5273 simulation
 http://groups.google.com/group/comp.arch.fpga/msg/33e48c977fa78001
 http://groups.google.com/group/comp.arch.fpga/msg/6b33bab4a35999bf


Article: 120047
Subject: Re: Nexys by Digilen xbd file
From: Stephen Williams <spamtrap@icarus.com>
Date: Thu, 31 May 2007 10:41:08 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cs_posting@hotmail.com wrote:
> On May 31, 9:16 am, christopher.saun...@durham.ac.uk (c d saunter)
> wrote:
> 
>> The Nexys has to be about my favourite board - compact, dirt cheap (even
>> with the S3-1000 part), the same pinout FX2 header as their other boards
>> (with 6 extra IOs even) and the key point for me is the Cypres EZ-USB
>> device on the board has all the key pins conencted to produce your own
>> USB interface using the FPGA and the Cypress part.
> 
> Yes... in theory.  But have you gotten it working yet?
> 
> It's not a problem with the board, it's just that getting the fx2 all
> ready to go is a non-trivial exercise, and most existing open source
> projects for it do some wierd things, require oddbal build
> environments rather than simply the SDCC complier on its own, want to
> do the host side in python, etc...  What happened to good old C and
> Makefiles?

I have a demo board of my own that I put together that uses an
EZ-USB-FX1/2. I've got it to talk USB using the default device
and sdcc. The source code is really quite simple. I'll put a
snapshot here:

<ftp://ftp.icarus.com/pub/steve/mmc-20070531.tar.gz>

It's also available via anonymous CVS if you are interested.
The FX1/2 connection to the USE is common, so that part of the
code should be directly applicable.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGXwi0rPt1Sc2b3ikRAsBPAJ9oT1W+VXYKEZ02y3hH6R4dFQLmPgCfeHDl
zg7gaVonzZJ2rB3lXBgoOQ4=
=aSDu
-----END PGP SIGNATURE-----

Article: 120048
Subject: Re: Xilinx Seminars in Wiesbaden, Berlin, Hannover
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 31 May 2007 17:42:57 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:

>Avnet picked Eindhoven as the preferred site in the Netherlands.

They probably didn't want to drive too far themselves. Eindhoven is a
bit of a technology hotspot due to Philips but it is in the east part
of the country. Most people and companies are located in the west part
of the country. Most major events are therefore either located in
Amsterdam or Utrecht.

>But the X-Fest seminar there was a month ago...
>But the traditional European FPGA conference will be in Amsterdam in
>August.

Allright!

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 120049
Subject: Re: PacoBlaze 2.2
From: Pablo Bleyer Kocik <pablobleyer@hotmail.com>
Date: 31 May 2007 11:00:25 -0700
Links: << >>  << T >>  << A >>
On May 31, 10:04 am, "dscol...@rcn.com" <dscol...@rcn.com> wrote:
> Pablo,
>
> Thanks for the fixes. However, I Just found another "bug" more of a
> compatibility issue. KCPSM allows the following renaming of registers
> as follows:
> first namereg
> namereg         s4,     clkcnt          ; temp register
> :
> :
> later renamed S4. however, KCPSM requires you use the name you renamed
> S4 to previously.
>
> namereg         clkcnt,         DIFF0   ;
>

 Thanks, Dave. I will look into that.

 Regards.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search