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 93225

Article: 93225
Subject: Re: Inverter Chain Synthesis Problem
From: backhus <nix@nirgends.xyz>
Date: Fri, 16 Dec 2005 08:08:07 +0100
Links: << >>  << T >>  << A >>
Davy schrieb:
> Hi,
> 
> Thank you for your help :-)
> 
> Do you think what's the best way to generate delay smaller than a clock
> period?
> 
> Best regards,
> Davy
> 
Hi Davy,
unfortunately you didn't tell why you want to create such a delay.
That would help to give you useful help.

One solution may be to feed the signal into a DFF that is clocked by the 
falling edge of your clock signal (assuming that the rest of your 
circuit uses the rising edge). Thus you get a delay of half a clock period.

Another way could be constraints. While max_delay constraints are 
available I'm not sure about min_delay constraints.

The problem with combinatorical delays in FPGAs is that they are 
somewhat meaningless, since the routing delays between the LUTs are much 
higher and (unless propperly constrained) not predictable. So this 
approach is probably the worst choice, sice it is wasting LUTs for no 
reason.

Have a nice synthesis

    Eilert

Article: 93226
Subject: Interfacing externally clocked data to an FPGA (Spartan 3)
From: "Bart" <bart_trzynadlowski@yahoo.com>
Date: 15 Dec 2005 23:15:08 -0800
Links: << >>  << T >>  << A >>
Hi,

First time poster here. I'm using Xilinx's cheap Spartan 3 Starter Kit
Board to create a simple VGA "controller" (framebuffer output) that I
want to interface to 8051 and Z80 systems I've constructed myself
(breadboard projects.)

I'm having serious trouble implementing writes to the on-board SRAM
because there appears to be some sort of conflict with the display
refresh which causes data to occasionally be misplaced in the frame
buffer (several dozen pixels per frame.)

After a couple weeks (!!) of debugging and experimentation (too much
stuff to list in this first post), I believe I've narrowed the problem
down to one of the following issues:

1. Writes are supposed to pre-empt reads in my VHDL state machine.
Perhaps there is some sort of conflict. If there is, it is not obvious.
My state machine is pretty tight and unless the toolchain is
synthesizing glitchy logic, there should be no problem.

2. Data is input from the external CPU (Z80 or 8051) via a simple 5-bit
port: 3 bits of color data, an address pointer reset bit, and a clock
bit. The Z80 will write a 0 and then a 1 to the clock bit and on the
rising edge of this pin, the FPGA is to latch the data and initiate a
write. It appears that the transition from low-to-high may be
problematic for the FPGA or once a write is complete, the internal
signal is not deasserted quickly enough (but this really shouldn't
cause any problems -- it would just write over and over again to the
same spot.)

I've tried to sync the input pin clock to the FPGA's 50MHz clock (which
my state machines run off of) but no luck there.

3. My 2-cycle write sequence to SRAM might be wrong. But I doubt it
because I've verified it against working code and I've synthesized
simpler circuits which prove that RAM is being read and written
correctly.


I've tried a number of things including adding a pin to disable the
display (thus stopping all reads) which the Z80 can control. Even when
the display is off and I write to the FPGA, these bad pixels appear.
It's not physical noise, that's almost for sure. The pixels are always
colored the same as in the image -- in fact, they're often missing from
the image and moved somewhere else.


Here's some of the relevant VHDL (I hope the formatting is preserved,
I'm using Google Groups):

(Please note how I am clearing the sram_do_write signal -- I think this
may be part of the problem but there's no easy way to rectify it.)

process(input)
	begin
		if input(4)'event and input(4) = '1' then
			if input(3) = '1' then	-- reset address
				write_addr <= "000000000000000000";
			else
				sram_data_write(2 downto 0) <= input(2 downto 0);
				sram_write_addr <= write_addr;
				write_addr <= write_addr + 1;
				sram_do_write <= '1';
			end if;
		end if;

		if sram_state = SRAM_WRITE then
			sram_do_write <= '0';
		end if;
	end process;


	--
	-- SRAM State Machine
	--
	process(clk_50mhz, sram_do_write, sram_do_read, sram_write_addr,
sram_read_addr)
	begin
		sram_oe <= '0';

		if clk_50mhz'event and clk_50mhz = '1' then
			case sram_state is
			when SRAM_WAITING =>
				sram_read_done <= '0';
				sram_write_done <= '0';
				if sram_do_write = '1' then	-- write requested
					sram_addr <= sram_write_addr;
					sram_ce <= '0';
					sram_we <= '0';
					sram_io_t <= '0';

					sram_state <= SRAM_WRITE;
				elsif sram_do_read = '1' and sram_do_write = '0' then	-- read
requested
					--
					-- Address in sram_addr and data will be read to
					-- sram_data_read.
					--
					sram_addr <= sram_read_addr;
					sram_ce <= '0';
					sram_we <= '1';
					sram_io_t <= '1';

					sram_state <= SRAM_READ;
				else
					sram_ce <= '1';
					sram_io_t <= '1';
				end if;
			when SRAM_READ =>
				sram_ce <= '1';
				sram_we <= '1';
				sram_io_t <= '0';

				sram_data_read_buf <= sram_data_read;
				sram_read_done <= '1';	-- finished reading
				sram_state <= SRAM_WAITING;
			when SRAM_WRITE =>
				sram_ce <= '1';
				sram_we <= '1';
				sram_io_t <= '0';

				sram_write_done <= '1';
				sram_state <= SRAM_WAITING;
			end case;
		end if;
	end process;


Any suggestions would be greatly appreciated!


Article: 93227
Subject: ISE 8.1i on Fedora Core 4 (64-bit)
From: Eric Smith <eric@brouhaha.com>
Date: 15 Dec 2005 23:39:32 -0800
Links: << >>  << T >>  << A >>
In general, ISE 8.1i seems to install and work just fine on my Athlon 64
system running Fedora Core 4 (64-bit).

ISE Simulator does not seem to get installed, though.  I'll try
installing on a 32-bit system later and see if that gets it.

And unfortunately there still aren't 64-bit cable drivers for use with
the Parallel Cable IV or the Platform Cable USB.  I started trying to
build them myself from the Xilinx "sources" and the Jungo demo kit, but
Xilinx supplies the core of the XPC4 driver as a binary archive, and
they don't supply a 64-bit version of that.

Sigh.

Could we have some 64-bit cable drivers, pretty please?

It's nice being able to run Project Navigator and do everything up
through the programming file generation on my main development machine,
instead of needing a second machine with very old software (RHEL3) for
that.  But it looks like I'll still need a second machine to run Impact.

I'm considering buying Chipscope, but I think I'll hold off until
there are 64-bit cable drivers.

Article: 93228
Subject: Re: Interfacing externally clocked data to an FPGA (Spartan 3)
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 16 Dec 2005 08:44:38 +0100
Links: << >>  << T >>  << A >>
"Bart" <bart_trzynadlowski@yahoo.com> schrieb im Newsbeitrag 
news:1134717308.862664.31090@o13g2000cwo.googlegroups.com...
> Hi,
>
> First time poster here. I'm using Xilinx's cheap Spartan 3 Starter Kit
> Board to create a simple VGA "controller" (framebuffer output) that I
> want to interface to 8051 and Z80 systems I've constructed myself
> (breadboard projects.)
>
[snip]

generic advice, if in such trouble as you are then it is usually VERY 
helpful to "look" into the FPGA, so get the ChipScope eval, add the ILA to 
some of the signals and look whats actually happening.

you can use one DCM to get say 150MHz and use that ILA clock so you would 
see several samplings per each system clock sample

Antti 



Article: 93229
Subject: Get Start for XtremeDSP Developement Board -IV
From: chengwelsion@gmail.com
Date: 15 Dec 2005 23:44:50 -0800
Links: << >>  << T >>  << A >>
Dear Sir,

There have a Xilinx/Nallatech Virtex4 development board beside me, on
which there has 2 ch ADC (105MSPS), 2ch DAC, FPGA Vritex4
XC4VSX35-10FF668.

There have poor examples from Nallatech, and I really don't like the
interface FUSE. I am using the USB port to communicate with this board,
and if I want to configure the FPGA chips through USB, FUSE seems the
only way? (or I write the dirver for USB interface). Is it possible to
configure through JTAG directly in ISE?

 I plan to make the board running, for example, a simple signal
generator, or digital filter. Can you give me some detailed instruction
on it? I am not good at HDL, good example start from ISE is very
helpful. Thanks 

wilson


Article: 93230
Subject: Re: ISE 8.1i on Fedora Core 4 (64-bit)
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 15 Dec 2005 23:50:37 -0800
Links: << >>  << T >>  << A >>
Hi Eric,
Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full
speed?

Mehdi


Article: 93231
Subject: Re: ISE 8.1i on Fedora Core 4 (64-bit)
From: Eric Smith <eric@brouhaha.com>
Date: 16 Dec 2005 00:24:26 -0800
Links: << >>  << T >>  << A >>
GaLaKtIkUs wrote:
> Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full
> speed?

I didn't try.  I set up a system running CentOS 3.5 32-bit (though it's
64-bit hardware), and 7.1i worked fine on that, including cable drivers
(after I compiled them).

So now I have a Belkin 4 port USB-and-DVI KVM switch, and go back and
forth between that and my main development machine (FC4 64-bit).  That
KVM switch is a total piece of crap, buy the way, so don't buy one.
(Details below for the curious.)

Now that I'm using 8.1i, I might try installing FC4 32-bit on that
machine instead.  Aside from the cable drivers and ISE simulator, 8.1i
installed beautifully on FC4 64-bit, with none of the hassles for
different versions of shared libraries and special environment variable
settings that were needed for 7.1i.

But I *really* would much rather be able to program from my main
development machine.  I briefly considered trying to reverse-engineer
the ioctl_3.a file, but I suspect that would violate the ISE license
agreement, and anyhow, life's too short.

It's hard to believe that there are any significant trade secrets in
ioctl_3.a; maybe Xilinx can be convinced to give out the source for it.

Eric


Belkin 4-port USB-and-DVI KVM problems:

1)  mechanical - can't plug the DVI cable onto port 1 of the KVM due
    to lip of plastic housing, effectively making it a 3-port KVM

2)  electrial - rather than having four DVI receivers, a mux, and
    a DVI driver, the KVM uses *relays* to switch the DVI signals.
    This results in enough signal degradation that I occassionally
    get twinkling pixel streaks.  Ugh.

3)  firmware (?) - the KVM sporadically loses key events.  Sometimes
    pressing a key does nothing, and sometimes a key up event is lost,
    so the key starts repeating even though it's been released.

I wouldn't have gotten the KVM switch at all, since I can use X over
the network easily enough, but while I was trying to get drivers working
I was rebooting the machine frequently and needed to see the screen
during the boot process.

Article: 93232
Subject: Re: ISE 8.1i on Fedora Core 4 (64-bit)
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 16 Dec 2005 09:32:31 +0100
Links: << >>  << T >>  << A >>
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag 
news:qhr78da1qd.fsf@ruckus.brouhaha.com...
> GaLaKtIkUs wrote:
>> Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full
>> speed?
>
> I didn't try.  I set up a system running CentOS 3.5 32-bit (though it's
> 64-bit hardware), and 7.1i worked fine on that, including cable drivers
> (after I compiled them).
>
> So now I have a Belkin 4 port USB-and-DVI KVM switch, and go back and
> forth between that and my main development machine (FC4 64-bit).  That
> KVM switch is a total piece of crap, buy the way, so don't buy one.
> (Details below for the curious.)
>
> Now that I'm using 8.1i, I might try installing FC4 32-bit on that
> machine instead.  Aside from the cable drivers and ISE simulator, 8.1i
> installed beautifully on FC4 64-bit, with none of the hassles for
> different versions of shared libraries and special environment variable
> settings that were needed for 7.1i.
>
> But I *really* would much rather be able to program from my main
> development machine.  I briefly considered trying to reverse-engineer
> the ioctl_3.a file, but I suspect that would violate the ISE license
> agreement, and anyhow, life's too short.
>
> It's hard to believe that there are any significant trade secrets in
> ioctl_3.a; maybe Xilinx can be convinced to give out the source for it.
>

Xilinx is trying to keep the Cable IV internals as secret so thats
why they dont release in source code anything that could
include information how to talk to the cable IV in high speed
mode.

And that is also the reason why there Cable IV support
is as shit as it is. On my main computer where all ECP
port cable from other vendors work properly, well
Cable IV works in Cable III emulation mode only.
Its an WinXP machine so the problems are not
only on linus

BTW the Cable IV PLD is non protected and resoldering
a few 0 ohms on the PCB makes Impact able to read
back the JEDED file from the XC3384, and I have a
tool that converts the JEDEC to synthesizeable VHDL :)

Antti
























Article: 93233
Subject: Re: Hello PPl, is there a way of locking a design (NGC) to a particular
From: David Brown <david@westcontrol.removethisbit.com>
Date: 16 Dec 2005 09:38:10 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
>> And you only really have to elevate it above the cost of bribing one of 
>> your employees :)
>>

But you don't want to make it so hard that your competitors resort to 
rubber-hose cryptanalysis.

> Jim,
> That's a key insight! I read Kevin Mitnick's books recently. Although the 
> security breaches he writes about involved an amount of technical 
> engineering knowledge, the social engineering undertaken was usually the key 
> to unlock the first door!
> Cheers, Syms. 
> 
> 

"The Art of Deception" should be required reading for anyone involved in 
security.

Article: 93234
Subject: Re: Simulating CRC32 according to IEEE Std. 802.3
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 16 Dec 2005 00:52:03 -0800
Links: << >>  << T >>  << A >>
Hi Sudhir,

thank you for detailed answer.

If I do that the manner you describe I also get that residuum when
using the easics-module (CRC-Reset Value (OTHERS =3D> '1')).

But I wonder what the IEEE Std. 802.3 (section 3.2.8 Frame Check
Sequence field)

means when claiming
a)The =EF=AC=81rst 32 bits of the frame are complemented.

Do you have any idea ?

Rgds
Andr=C3=A9


Article: 93235
Subject: Re: Xilinx DCM Shuts down at 75degree centigrade
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 16 Dec 2005 01:24:11 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Ages ago, IC manufacturers used to specify a max ambient temperature
> (70 degr.C for commercial parts). We soon found out that this makes no
> sense for programmable parts. The FPGA manufacturer does not know what
> the user implements inside the chip (what clock frequency, what
> utilization) and how the chip is cooled. The only reasonable
> specification that we can guarantee is the max junction temperature. So
> we pioneered the Tj max 85 degr.C specification for all commercial
> parts.
> The user is the only person who then can evaluate whether the chip is
> operating within these guaranteed limits, and can modify the design or
> the cooling to bring it within specification.
> It would be nice if the FPGA-manufacturer could guarantee operation at
> a given ambient temperature, but that is inherently impossible,
> especially for parts where the user can program the logic and choose
> the clock speed.
> As a rule of thumb, no package without a heatsink has a thermal
> resistance (junction-to-ambient) below 10 degr.C per Watt. ( the very
> biggest get down to 8 degr./W), and a heatsink is needed when power
> exceeds a few watts.
> Peter Alfke, Xilinx Applications

For all the VLSI devices I have used in the last few years, the maximum
temperature ratings were die temperature, not ambient for the reasons
you specify. As VLSI power dissipation is very dependent on operating
mode, ambient ratings are pretty meaningless not only for programmable
parts, but for the majority of VLSI. Things become quite difficult when
the mfr has neglected to put a thermal sensing diode (really a
transistor) on the die somewhere.

I suggest the OP grab the rather useful power dissipation calculator
from the Xilinx website and then apply it using the Theta J-A for the
device he is using.

Cheers

PeteS


Article: 93236
Subject: Re: Simulating CRC32 according to IEEE Std. 802.3
From: allanherriman@hotmail.com
Date: 16 Dec 2005 02:38:09 -0800
Links: << >>  << T >>  << A >>
ALuPin@web.de wrote:
> Hi Sudhir,
>
> thank you for detailed answer.
>
> If I do that the manner you describe I also get that residuum when
> using the easics-module (CRC-Reset Value (OTHERS =3D> '1')).
>
> But I wonder what the IEEE Std. 802.3 (section 3.2.8 Frame Check
> Sequence field)
>
> means when claiming
> a)The =EF=AC=81rst 32 bits of the frame are complemented.

It means exactly what it says.  You invert the first 32 bits of the
frame.

I listed a number of CRC properties in this thread:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b14d0fc4=
3dbc1/cf1e7d94dedc5733#cf1e7d94dedc5733
Property 3 says:
" Initialising the register to all ones is equivalent to initialising
the register to all zeros and  *inverting the first N bits of the
message*."

Regards,
Allan


Article: 93237
Subject: verification tools?
From: "burn.sir@spam-me-not-gmail.com" <burn.sir@gmail.com>
Date: 16 Dec 2005 03:08:47 -0800
Links: << >>  << T >>  << A >>
hello group!   (and sorry for the cross-posting)

I am working on a complex FPGA prototype and have already a feeling
that the usual "testbench verification" wont help very much here. I
have worked with formal verification in past and think this is a great
opportunity to introduce the team to FV.

I couldn't get the management to pay for new verification software, so
i decided to ask the experts (you guys) if any good but "free"
verification tools are available. I am even interested in academic type
of software (=working but user unfriendly). For example, i could go for
SMV if i could figure out a way to feed it VHDL or compiled netlists.

Of course, it does not have to be "formal" verification. I could go
with any tool available as long as it gets the job done. So please help
me find the right tool for this job. You may also take this as a great
opportunity for you guys to promote your software or share your
experiences with the world!

regards, Burns


Article: 93238
Subject: Re: Simulating CRC32 according to IEEE Std. 802.3
From: "Reiner Huober" <reiner@huober.de>
Date: 16 Dec 2005 04:21:19 -0800
Links: << >>  << T >>  << A >>
>It means exactly what it says.  You invert the first 32 bits of the
>frame.

Note that you get the same results if you initialize the CRC register
with all ones and do not complement the first 32 bits, due to the
properties of the CRC algorithm.

Inverting the first 32 bits (or equivalently using a start valuie of
0xFFFFFFFF) detects erroneous 0s inside the start sequence (first 32
bits). If you initialize with 0 and have additional 0s at the
beginning, standard CRC will not detect it (CRC uses polynom division,
dividing 0 always gives 0).

Hubble.


Article: 93239
Subject: Re: Simulating CRC32 according to IEEE Std. 802.3
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 16 Dec 2005 05:45:01 -0800
Links: << >>  << T >>  << A >>
Hi Allan, hi Reiner,

thank you for your responses. They have shed some light on my problem.

I have simulated the test design with respect to your considerations
and they
are correct.=20

Thanks again for your help.

Rgds
Andr=E9


Article: 93240
Subject: Re: Simulating CRC32 according to IEEE Std. 802.3
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 16 Dec 2005 06:11:54 -0800
Links: << >>  << T >>  << A >>
Hi Sudhir,

>The result in the CRC register after the last byte has gone through
>is called the residue, and in the
>    case of 802.3 it is 0xC704DD7B

Yes, the simulation shows that.

Rgds
Andr=E9


Article: 93241
Subject: Re: Inverter Chain Synthesis Problem
From: John_H <johnhandwork@mail.com>
Date: Fri, 16 Dec 2005 14:32:04 GMT
Links: << >>  << T >>  << A >>
Davy wrote:
> Hi,
> 
> Thank you for your help :-)
> 
> Do you think what's the best way to generate delay smaller than a clock
> period?
> 
> Best regards,
> Davy

If you have a steady clock in the right frequency range for your device, 
you can use a PLL, DLL, or DCM to get a different delay than 1.0 or 0.5 
clock periods.

The DCM especially allows you to set up a shifted clock with 1/256th of 
a clock resolution (or about 50 ps, whichever is greater) of delay. 
This precisely delayed clock can give you the precision control over 
skew that today's designers need.

If you're in Virtex-4 devices, the inputs have per-pin controllable 
delays that are calibrated to give you 78 ps delay resolution on 
unclocked signals.

So - is your device able to supply the fun stuff?  More application 
details can bring out the info on the "best" feature set to use.

Article: 93242
Subject: Re: Avnet hav2 s3e starter kit?
From: John_H <johnhandwork@mail.com>
Date: Fri, 16 Dec 2005 14:46:38 GMT
Links: << >>  << T >>  << A >>
Alex Gibson wrote:

> According to 
> <http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D27812%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html>
> 
> The spartan 3e starter kits are available  yet xilinx says they are not ?
> 
> Alex 

If you hit the "Buy Now" button the following info pops up:

     * Lead Time (weeks): Call
     * Status: NCNR, Backorder

Maybe Xilinx is doing it better by saying "Notify me when available" in 
blace of "Add to Cart."

There's still no information on the Avnet site beyond the one-page 
product brief.  At least it *looks* like an S3E board!  Now if I could 
read those connector part numbers....

Since - at the moment - the Xilinx link 
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=DO-SPAR3E-DK
is dead, there may be an imminent update.

Article: 93243
Subject: Re: Avnet hav2 s3e starter kit?
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 16 Dec 2005 15:52:22 +0100
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag 
news:irAof.3$Ht4.2@trnddc08...
> Alex Gibson wrote:
>
>> According to 
>> <http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D27812%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html>
>>
>> The spartan 3e starter kits are available  yet xilinx says they are not ?
>>
>> Alex
>
> If you hit the "Buy Now" button the following info pops up:
>
>     * Lead Time (weeks): Call
>     * Status: NCNR, Backorder
>
> Maybe Xilinx is doing it better by saying "Notify me when available" in 
> blace of "Add to Cart."
>

the avnet 100e board is still in stock, surprisingly the stock
count have increased from 18 to 83 ??
with lead time of 26 weeks...!?

> There's still no information on the Avnet site beyond the one-page product 
> brief.  At least it *looks* like an S3E board!  Now if I could read those 
> connector part numbers....
>
> Since - at the moment - the Xilinx link 
> http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=DO-SPAR3E-DK
> is dead, there may be an imminent update.
we need to wait then :(

antti 



Article: 93244
Subject: Re: Avnet hav2 s3e starter kit?
From: "Brian Davis" <brimdavis@aol.com>
Date: 16 Dec 2005 07:37:22 -0800
Links: << >>  << T >>  << A >>
John_H wrote:
>
> There's still no information on the Avnet site beyond the one-page
> product brief.  At least it *looks* like an S3E board!  Now if I could
> read those connector part numbers....
>

 The high speed connnector is the same one as used on the
Digilent/Xilinx XUPV2P board:
  http://www.xilinx.com/univ/xupv2p.html
  http://www.digilentinc.com/info/XUPV2P.cfm

 The softtouch connector footprint routing pictured in the Avnet
datasheet appears to indicate there's provision for at least some
differential pairs to the connector, have to wait for the released
schematics and layout files to be sure.

Brian


Article: 93245
Subject: How to simulate Virtex-4 PPC, MAC, etc. ?
From: "acetylcholinerd@gmail.com" <acetylcholinerd@gmail.com>
Date: 16 Dec 2005 08:06:35 -0800
Links: << >>  << T >>  << A >>
Hello! Having finished a board design with a Virtex-4FX and with
promising leads on the silicon, I sat down to begin my HDL coding...
when I discovered that the simulation models for the Virtex-4 PPC and
MAC components are only available in encrypted form. After poking
around a bit on the net and usenet, it seems that only the really
high-end simulators can support these encrypted models. Has anyone
found an inexpensive HDL simulator which supports these encrypted
models, or any other way to design with the cool features of the Virtex
2-pro and Virtex-4FX? 

Thanks, 
   ...Eric


Article: 93246
Subject: Re: Interfacing externally clocked data to an FPGA (Spartan 3)
From: "johnp" <johnp3+nospam@probo.com>
Date: 16 Dec 2005 08:43:16 -0800
Links: << >>  << T >>  << A >>
Bart -

Have you checked the quality of the input(4) signal?  If it is slow or
has noise, glitches, etc the ram write address could get incremented
multiple times for each write operation.

Also, you mentioned trying to synchronize the sram_do_write signal
to the 50MHz clock - you must do that!  Otherwise, you've got an async
signal feeding into your state machine - just a matter of time before
it screws up.

Hope this helps!

John Providenza


Article: 93247
Subject: Re: Inverter Chain Synthesis Problem
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Fri, 16 Dec 2005 09:13:49 -0800
Links: << >>  << T >>  << A >>
Davy wrote:
> Hi,
> 
>   I work on Xilinx ISE, and my synthesis tool is XST and synplify.
>   I use verilog to write a Inverter Chain (delay ) like out =
> ~(~(~(~...in)).
>   But the circuit be synthesised cancel all the invorter.
> 
>   How to synthesis out all the inverter chain I want?
> 
> Any suggestions will be appreciated!
> Best regards,
> Davy
> 

For synplify tools,

wire [3:0] inv_chain/*synthesis syn_keep=1*/;

assign inv_chain[3:0] = ~{inv_chain[2:0], din};
assign dout = inv_chain[3];

I'm not use what XST uses in equivalence to syn_keep. It might be the same.

Like other ppl pointed out, you shouldn't expect to use invertor chains 
for any precision timing control. There are just too many uncertainties 
in FPGA. But if you just want to insert some combinational delay to 
solve some racing conditions, it might come in handy.

cheers,

jz

Article: 93248
Subject: Re: Xilinx floating point core 1.0
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Fri, 16 Dec 2005 17:19:01 -0000
Links: << >>  << T >>  << A >>
Hi kl31n,

> My design requires me to acquire data from an ADC and then,
> after some processing to do a division between a couple
> floating point numbers every 200ns.

> The performances of the core aren't big enough to use just
> one, so I implemented a core which feeds several dividers
> (made with the Xilinx core) and then I reserialize it all.

What exactly is your performance requirement? How often do you need to start
a new divide operation? How long can you afford to wait for the result?

The Xilinx speed-optimized floating-point divider will run at well over
250MHz and allows you to initiate a new divide on every cycle (i.e. every
4ns) if you wish.

> The design works fine till I pass numbers with a period
> down to 260ns, going for lower periods the results get weird

I'm afraid I don't understand what you mean by "pass numbers with a period
down to 260ns", could you explain your circuit to me?

     -Ben-



Article: 93249
Subject: Re: Interfacing externally clocked data to an FPGA (Spartan 3)
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 16 Dec 2005 19:17:52 +0100
Links: << >>  << T >>  << A >>

I would suggest to try to get a simplified system to run at first.
Use internal SRAM as frame buffer. This will not be enough for full
screen, but that does not matter at first, considering the magnitude of
your difficultied.

The internal SRAM is dual ported so you can write with one state machine
and read with another, using different clocks. If you still see
problems, it is very likely that the quality of the input signal is the
problem.

If not, you have a problem with synchronization or SRAM access. Try to
think of a design change that can separate the two.

Kolja



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