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 110250

Article: 110250
Subject: Re: Virtex-II Pro Platform FPGA : Assembling the modules
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Thu, 12 Oct 2006 15:27:47 -0700
Links: << >>  << T >>  << A >>
Dear Jens, Finally, I can use the ISE 8.1i. But, there is a problem, that is I can only found the ISE SP3 version. And after I update to SP3, I can not install the partial reconfiguration implementation tools any more :((. Do you have ISE SP1 for ISE 8.1i? Thank you very much, Thang Nguyen

Article: 110251
Subject: Re: New Electronic Design Web site
From: ElectronicDesignNet <webmaster@ElectronicDesignNet.com>
Date: Thu, 12 Oct 2006 18:33:03 -0400
Links: << >>  << T >>  << A >>
In article <1160689402.959973.55670@k70g2000cwa.googlegroups.com>,
 "jacko" <jackokring@gmail.com> wrote:
> i would be interested in construction contractors, who build to design
> and ship. didn't try the distributors list, as i have no built design
> yet. does such a service exsist?

I might be able to get some ideas for you, but I would need to know a 
little more about what it is you want to build, and what the contractor 
would need to do (i.e. what they are given, and what do they produce).

Thanks,

Patrick
Webmaster
http://www.ElectronicDesignNet.com

Article: 110252
Subject: Re: Glitches in post-layout (PAR) simulation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 12 Oct 2006 15:34:43 -0700
Links: << >>  << T >>  << A >>
Manny wrote:
> Actually static timing did pass. As far as I could infer, these
> glitches are due to long routing propagation delays and only consitute
> negligible time (1ns) relative to the clock period. So they are pretty
> much clock independent.

Maybe, but it might be worth a sim run to check it.

Are the glitches on a registered output?
Are all tb and uut clock inputs on exactly the same signal?

> In my testbench, I added an explicit intertial
> delay (2ns) when assigning my output signal. Now everything is ok but I
> still get warning messages in simulation. Was wondering whether it'll
> have any noticeable impact when running in hardware?

If it does, the problem is confirmed.
If it doesn't, nothing is confirmed.

      -- Mike Treseler

Article: 110253
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Peter Alfke" <peter@xilinx.com>
Date: 12 Oct 2006 15:54:57 -0700
Links: << >>  << T >>  << A >>
Manny, you claim that your design is fully synchronous. I take it that
all flip-flops are clocked by a common clock. On the signals between
these flip-flops you can (and probably will) have glitches as a result
of logically combining signals with different routing delays. That is
perfectly ok, as long as you manage to met all set-up time
requirements.
When you use a combinatorially decoded signal as output, you will see
the glitch, and you either can live with it, or you need to synchronize
the output with a flip-flop. That will definitely eliminate the glictch
(at the expense of a one-clock-period delay).
peter Alfke, Xilinx Applications.
====================
Manny wrote:
> Actually static timing did pass. As far as I could infer, these
> glitches are due to long routing propagation delays and only consitute
> negligible time (1ns) relative to the clock period. So they are pretty
> much clock independent. In my testbench, I added an explicit intertial
> delay (2ns) when assigning my output signal. Now everything is ok but I
> still get warning messages in simulation. Was wondering whether it'll
> have any noticeable impact when running in hardware?
>
> Cheers,
> -Manny
>
> Mike Treseler wrote:
> > Manny wrote:
> > > Anyway, it
> > > seems that when running post-PAR simulation I end up having a periodic
> > > pattern of 1ns wide glitches in my output signal every like 4 or
> > > slightly less sampling periods. My design is fully synchronous.
> >
> > What happens if you slow down the clock?
> > Did static timing pass?
> > 
> >      -- Mike Treseler


Article: 110254
Subject: Which Xilinx FPGA/board?
From: "rohit.nadig@gmail.com" <rohit.nadig@gmail.com>
Date: 12 Oct 2006 16:17:48 -0700
Links: << >>  << T >>  << A >>
Dear Comrades,

I am trying to implement a large design on a Xilnx FPGA (over 500,000
gates). Spartan 3E seems like the best bet, but I wanted to ask around
before I ordered a board. I am considering a board by digilent
(http://www.digilentinc.com/).

Can you please suggest:

  - A good starter board
  - A good FPGA with lotsa real estate for my big design

My budget is about $500

Thanks a bunch,
Rohit


Article: 110255
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Manny" <mloulah@hotmail.com>
Date: 12 Oct 2006 16:25:24 -0700
Links: << >>  << T >>  << A >>
As a matter of fact, it's a registered output. This is the weird thing
about it. There should be not glitches. My testbench is:

        real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
-- *** Test Bench - User Defined Section ***
   	tb : PROCESS
   	BEGIN
        wait until (reset = '1');

        for i IN 0 TO 2091 loop
			filter_in <= real2hex(filter_in_force(i), 16.0);
			real_in <= hex2real(filter_in, 16.0);

			table_in <= filter_in_force(i);
			table_out <= filter_out_expected(i);

			wait until (clk_sampling = '0');
		end loop;
   	END PROCESS;
-- *** End Test Bench - User Defined Section ***

filter_out is an already registered output. Is it because I've taken
real_out outside of the main testbench process? In my output assignment
process, I've defined a temp variable in which I'm storing the
glitching signal. I then wait for a handshaking signal before assigning
temp to the output (synchronously). Still with all this, 1ns-wide
glitches are visible on my output signal.

Thanks a lot, 
-Manny


Article: 110256
Subject: Re: Which Xilinx FPGA/board?
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 12 Oct 2006 16:47:57 -0700
Links: << >>  << T >>  << A >>
rohit.nadig@gmail.com wrote:
> I am trying to implement a large design on a Xilnx FPGA (over 500,000
> gates). Spartan 3E seems like the best bet, but I wanted to ask around
> before I ordered a board. I am considering a board by digilent
> (http://www.digilentinc.com/).
>
> Can you please suggest:
>
>   - A good starter board
>   - A good FPGA with lotsa real estate for my big design
>
> My budget is about $500

Your request is like asking what is the best cheese (a question of
taste).

ML401 exceeds your specs at the target price: http://xilinx.com/ml401

The most complete list is on http://fpga-faq.org/FPGA_Boards.shtml

Tommy


Article: 110257
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Peter Alfke" <peter@xilinx.com>
Date: 12 Oct 2006 16:50:29 -0700
Links: << >>  << T >>  << A >>
On a clocked flip-flop (without any strange asynchronous inputs) there
can never be a 1 ns glitch.
You have either done something very strange, or you have a defective
part (unlikely)
Flip-flop outputs do not glitch, if clocked correctly.
Could it be that you have a bad clock with glitching edges?
Peter Alfke
===============
Manny wrote:
> As a matter of fact, it's a registered output. This is the weird thing
> about it. There should be not glitches. My testbench is:
>
>         real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
> -- *** Test Bench - User Defined Section ***
>    	tb : PROCESS
>    	BEGIN
>         wait until (reset = '1');
>
>         for i IN 0 TO 2091 loop
> 			filter_in <= real2hex(filter_in_force(i), 16.0);
> 			real_in <= hex2real(filter_in, 16.0);
>
> 			table_in <= filter_in_force(i);
> 			table_out <= filter_out_expected(i);
>
> 			wait until (clk_sampling = '0');
> 		end loop;
>    	END PROCESS;
> -- *** End Test Bench - User Defined Section ***
>
> filter_out is an already registered output. Is it because I've taken
> real_out outside of the main testbench process? In my output assignment
> process, I've defined a temp variable in which I'm storing the
> glitching signal. I then wait for a handshaking signal before assigning
> temp to the output (synchronously). Still with all this, 1ns-wide
> glitches are visible on my output signal.
> 
> Thanks a lot, 
> -Manny


Article: 110258
Subject: Re: Glitches in post-layout (PAR) simulation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 12 Oct 2006 16:51:00 -0700
Links: << >>  << T >>  << A >>
Manny wrote:
> As a matter of fact, it's a registered output. This is the weird thing
> about it. There should be not glitches. My testbench is:

Your testbench should be generating
a constant clock, say clk_s, and
waiting on the same clock *edges* like this:

   wait until rising_edge(clk_s);

Your uut clock should be  port mapped to
the same clk_s.

See the testbench here for details:

 http://home.comcast.net/~mike_treseler/

     -- Mike Treseler

Article: 110259
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Manny" <mloulah@hotmail.com>
Date: 12 Oct 2006 17:23:33 -0700
Links: << >>  << T >>  << A >>
Ok. I've just checked the netlist 'cause you guys got me worried.
Everything is alright. That is, my output port is being clocked by the
system's clock properly. The best explanation I could come up with is
that individual output port bits have sort of delay mismatch and this
is basically what's being manifested as glitches. I presume that after
constraining things a bit tighter now, the glitches should be gone.
What I meant to ask after all is the following: though post-PAR
simulation shows glitches on the output, it doesn't necessarily mean
that running design in hardware will fail? isn't it the case?

Thanks a lot,
-Manny


Article: 110260
Subject: OT: Internships?
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 12 Oct 2006 17:26:30 -0700
Links: << >>  << T >>  << A >>
Hi guys,

I am currently in the process of looking for an internship position
that will potentially start in May and end on Sept the following yr (16
months, but can be 12 months or 8 months). Now I am not asking you guys
to do anything at all really. I am living in the Toronto, Ontario,
Canada area and would like to stay there since I don't think I could
stomach the costs of relocating temporarily (that is if I manage to
secure a position, also its not fun living off Kraft Dinner either!).

I am currently assembling a list of companies that I will "cold call"
or e-mail to inquire about what opportunities they have.

I am simply asking you if you work with a company that does embedded
design (or some other technical stuff) work in Toronto or know of a
company in Toronto that does this kind of work and would let me know?


Thanks,

Isaac


Article: 110261
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Oct 2006 17:29:36 -0700
Links: << >>  << T >>  << A >>
Manny, you said that the output was registered.
Now you imply that there might be gating between the register and the
real output.
A registered output will not glitch.
A combinatorial output is very likely to glitch.
Make up your mind...
Peter Alfke
==============
Manny wrote:
> Ok. I've just checked the netlist 'cause you guys got me worried.
> Everything is alright. That is, my output port is being clocked by the
> system's clock properly. The best explanation I could come up with is
> that individual output port bits have sort of delay mismatch and this
> is basically what's being manifested as glitches. I presume that after
> constraining things a bit tighter now, the glitches should be gone.
> What I meant to ask after all is the following: though post-PAR
> simulation shows glitches on the output, it doesn't necessarily mean
> that running design in hardware will fail? isn't it the case?
> 
> Thanks a lot,
> -Manny


Article: 110262
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Manny" <mloulah@hotmail.com>
Date: 12 Oct 2006 17:39:50 -0700
Links: << >>  << T >>  << A >>
Peter, from now on I should stop using the word glitch. There is no
gating and the design is synchronous. What I meant to say is the
following: starting from the flipflops, there are non-uniform delays
among the output of flipflops until reaching the output buffer pad
(routing-caused). Now I figured it out. I shouldn't be reading my
output as:
      real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
I should even "synchronize" my testbench i.e. sampling my output from
within a process rather than allowing instantaneous propagation to be
reflected in simulation.  

Thanks a lot for reasoning with me. 
-Manny


Article: 110263
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Manny" <mloulah@hotmail.com>
Date: 12 Oct 2006 17:46:01 -0700
Links: << >>  << T >>  << A >>
I've just did this:

   	tb : PROCESS
   	BEGIN
                 wait until (reset = '1');

                 for i IN 0 TO 2091 loop
			filter_in <= real2hex(filter_in_force(i), 16.0);
			real_in <= hex2real(filter_in, 16.0);
                        real_out <= hex2real(filter_out, 16.0)*4.0;

			table_in <= filter_in_force(i);
			table_out <= filter_out_expected(i);
                        hex_out <= real2hex(filter_out_expected(i),
16.0);

			wait until (clk_sampling = '0');
		end loop;
   	END PROCESS;

Basically, I relocated my "real_out <= hex2real(filter_out, 16.0)*4.0"
and everything is working smoothly now.

On a different note, is there a chance that I'd be able to fit a whole
RAKE receiver on a fusion device?

Thanks a lot, 
Cheers,
-Manny


Article: 110264
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Oct 2006 17:57:31 -0700
Links: << >>  << T >>  << A >>
Manny, I have nothing to do with Actel. They are our competitor.
I just helped you as a Good Samaritan.
Peter
======================
Manny wrote:
> I've just did this:
>
>    	tb : PROCESS
>    	BEGIN
>                  wait until (reset = '1');
>
>                  for i IN 0 TO 2091 loop
> 			filter_in <= real2hex(filter_in_force(i), 16.0);
> 			real_in <= hex2real(filter_in, 16.0);
>                         real_out <= hex2real(filter_out, 16.0)*4.0;
>
> 			table_in <= filter_in_force(i);
> 			table_out <= filter_out_expected(i);
>                         hex_out <= real2hex(filter_out_expected(i),
> 16.0);
>
> 			wait until (clk_sampling = '0');
> 		end loop;
>    	END PROCESS;
>
> Basically, I relocated my "real_out <= hex2real(filter_out, 16.0)*4.0"
> and everything is working smoothly now.
>
> On a different note, is there a chance that I'd be able to fit a whole
> RAKE receiver on a fusion device?
> 
> Thanks a lot, 
> Cheers,
> -Manny


Article: 110265
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Manny" <mloulah@hotmail.com>
Date: 12 Oct 2006 18:07:16 -0700
Links: << >>  << T >>  << A >>
Peter, don't worry. I'd most probably end up supplementing a fusion
with a spartan-3L. I think there is a no way in the world to fit
complex DSP operations solely in soft fabric. It would be nice to boot
up the spartan from the fusion's embedded flash and probably use their
ADC also. It's just that the application is power critical and I'm not
sure about how well spartan-3L would perform as a battery-powered
device.

Cheers,
-Manny


Article: 110266
Subject: Re: LatticeMico32 extremly poor performance without caches
From: avionion@gmail.com
Date: 12 Oct 2006 18:18:00 -0700
Links: << >>  << T >>  << A >>
As mentioned  by Antti, its not issue of uncompressing tar.gz or zip
files, i am unable to get anything downloaded. just read the mesage
that i get whenever i click on any link. i even wrote to webmaster, but
its about a month ,and with 2 reminds, still no response from
webmaster.
Jon Beniston wrote:
> avionion@gmail.com wrote:
> > Hi Antti
> > i am unable to get any download from lattice website and get the
> > following message:
> > "The file you have attempted to retrieve is not available at this time.
> >
> > We apologize for the inconvenience.
> >
> > If you continue to experience this difficulty, please contact the
> > Webmaster"
> > i have an account with lattice website as well. i am unable to download
> > any zip or exe file but  pdf files open correctly. anyone else facing
> > this problem? any solution to it?
>
> The file you download is a tar.bz2, not zip or exe. You need to extract
> it with:
> 
> tar xjf src.tar.bz2
> 
> Cheers,
> Jon


Article: 110267
Subject: Re: OT: Internships?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Oct 2006 19:30:20 -0700
Links: << >>  << T >>  << A >>
Isaac, you have made it clear that you do not want to relocate, but you
have said nothing about your education, experience, or skills. Don't
you think that matters?
Peter Alfke, from home

Isaac Bosompem wrote:
> Hi guys,
>
> I am currently in the process of looking for an internship position
> that will potentially start in May and end on Sept the following yr (16
> months, but can be 12 months or 8 months). Now I am not asking you guys
> to do anything at all really. I am living in the Toronto, Ontario,
> Canada area and would like to stay there since I don't think I could
> stomach the costs of relocating temporarily (that is if I manage to
> secure a position, also its not fun living off Kraft Dinner either!).
>
> I am currently assembling a list of companies that I will "cold call"
> or e-mail to inquire about what opportunities they have.
>
> I am simply asking you if you work with a company that does embedded
> design (or some other technical stuff) work in Toronto or know of a
> company in Toronto that does this kind of work and would let me know?
> 
> 
> Thanks,
> 
> Isaac


Article: 110268
Subject: Re: OT: Internships?
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 12 Oct 2006 21:11:07 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> Isaac, you have made it clear that you do not want to relocate, but you
> have said nothing about your education, experience, or skills. Don't
> you think that matters?
> Peter Alfke, from home
>
> Isaac Bosompem wrote:
>> * snip *



Hi Peter,

Yes that is important information. I apologize for not including it.

I am currently in my 3rd year of Electrical Engineering undergrad at
Ryerson University in Toronto, Ontario, Canada. The internship (if
acquired) is slated to start right after this academic year.
This effectively delays my graduation by 1 yr, but I think that is a
really small price to pay for the experience.


Here is a rudimentary list of my skills, a more thorough one will be
submitted w/ my resume:

Programming Languages: C, Java, Visual Basic, Assembly, Win32
programming, Python

Compilers/Environment: GNU tools, Microsoft Visual Studio

Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430,
ARM7, HC11, Renesas SuperH series

proemulator.sf.net

I ported my Z80 emulator to this app some time ago. My M68000 emulator
is working and is tested to be quite accurate, but the author no longer
maintains it or updates it so I decided against porting it (even though
I can still get into the CVS).


Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack

I designed a simple VGA frambuffer 320x240x2-bit and a simplistic
16-bit CPU in VHDL.


Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.)
Here all I did was some school projects. Simple stuff: VCO's, FET amps,
etc.

Operating Systems: Linux, MS-DOS, Windows (effective w/ all).
Been doing installs on all OS's for quite some time now. Used MS-DOS
while I was growing up (had it first running on a 16Mhz 386SX).

Most the stuff I have learned was from buying products containing the
previously mentioned items and playing around with them and their
associated tools and reading my dads old college books (he studied
electronics engineering technology at NAIT. They did extensive course
work in digital electronics).

I really do not have any related engineering experience. I did work for
GO Transit this past summer,  a major transportation company here in
Ontario, as general help. I was called on one day to look over some
computer scans of microfilm schematics of the trains (and electrical
systems) to make sure they were up to par.

I would like to shadow some teams in the engineering sector to get a
feel of what you guys do in the industry. I would like to see how you
guys solve problems, tackle issues or shortcomings you come up in
development and the like. I'd also like to learn from the people
working in this industry in general since they have a wealth of
knowledge and experience. Sometthing I think can be invaluable to me in
my career.

They have some listings at my school, but they are not exactly what I
am interested in. Thanks for listening to my story!

Any companys you know of in Toronto?
I know Altera has some offices here. Might try and get a hold of them
later on. 

-Isaac


Article: 110269
Subject: Re: OT: Internships?
From: CBFalconer <cbfalconer@yahoo.com>
Date: Fri, 13 Oct 2006 01:02:41 -0400
Links: << >>  << T >>  << A >>
Isaac Bosompem wrote:
> 
... snip ...
> 
> I am currently in my 3rd year of Electrical Engineering undergrad
> at Ryerson University in Toronto, Ontario, Canada. The internship
> (if acquired) is slated to start right after this academic year.
> This effectively delays my graduation by 1 yr, but I think that is
> a really small price to pay for the experience.

I am surprised to see Ryerson classified as a university.  In my
student days it was a first class technical school, but definitely
not a university.  No deprecation intended, my student days
preceded transistors.

... snip impressive list of student achievements ...

-- 
 Some informative links:
   <news:news.announce.newusers
   <http://www.geocities.com/nnqweb/>
   <http://www.catb.org/~esr/faqs/smart-questions.html>
   <http://www.caliburn.nl/topposting.html>
   <http://www.netmeister.org/news/learn2quote.html>
   <http://cfaj.freeshell.org/google/>



Article: 110270
Subject: Re: Glitches in post-layout (PAR) simulation
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Oct 2006 22:29:24 -0700
Links: << >>  << T >>  << A >>
Manny, I think I have already shown that  am not too parochial...
For complex DSP you are better off with Virtex-4 or -5 devices that
have many poweful and fast multiplier-accumulator blocks.
All high-performance FPGAs have fairly high leakage current, so make
sure that you use the smallest possible device = least leakage.
Peter Alfke, from home.

On Oct 12, 6:07 pm, "Manny" <mlou...@hotmail.com> wrote:
> Peter, don't worry. I'd most probably end up supplementing a fusion
> with a spartan-3L. I think there is a no way in the world to fit
> complex DSP operations solely in soft fabric. It would be nice to boot
> up the spartan from the fusion's embedded flash and probably use their
> ADC also. It's just that the application is power critical and I'm not
> sure about how well spartan-3L would perform as a battery-powered
> device.
> 
> Cheers,
> -Manny


Article: 110271
Subject: Re: VGA timing
From: icegray@gmail.com
Date: 12 Oct 2006 23:47:15 -0700
Links: << >>  << T >>  << A >>


> You can try:
>    http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html

This calculator is very good. Thanks for it.
Also do you have any idea for polarization???


Article: 110272
Subject: Re: Which Xilinx FPGA/board?
From: "John Adair" <g1@enterpoint.co.uk>
Date: 12 Oct 2006 23:48:35 -0700
Links: << >>  << T >>  << A >>
Rojit

I will of course suggest one of our boards - Raggedstone1 - either
RS1-400 (400,000) circa $95 or RS1-1500 (1,500,000) circa $270 ($165
student). If want to run this board on the bench then add the PCI I/O
adaptor to give 50 5V tolerant I/O at $30 (with board purchase).
Shipping is $19 (low cost) or if you are in a hurry FEDEX (usually next
day to the US, EEC etc if we get order by about 10.00am GMT) $38.

The RS1-1500 has a XC3S1500 which is about the biggest Spartan device
supported under ISE Webpack except perhaps a XC3S1600E but that's a
close call.

Other things we have to consider is our OVERCOAT option where for your
budget we can might just about do a small array of Raggedstone1's. This
can increase your effective size of the logic you have available but of
course is split between several devices. This a build to order option
and does have a lead time although we are looking at having a small
stock of these on the next build run within the next few weeks.

There are other offerings in our product range that will probably reach
into your price bracket and do brouse our website for their details. If
you are are a student look at our University Access Program (UAP)
webpage for details on board discounts. Big green button on our index
page is the way in.

John Adair
Enterpoint Ltd.

rohit.nadig@gmail.com wrote:
> Dear Comrades,
>
> I am trying to implement a large design on a Xilnx FPGA (over 500,000
> gates). Spartan 3E seems like the best bet, but I wanted to ask around
> before I ordered a board. I am considering a board by digilent
> (http://www.digilentinc.com/).
>
> Can you please suggest:
>
>   - A good starter board
>   - A good FPGA with lotsa real estate for my big design
> 
> My budget is about $500
> 
> Thanks a bunch,
> Rohit


Article: 110273
Subject: Re: An implementation of a clean reset signal
From: "Eli Bendersky" <eliben@gmail.com>
Date: 13 Oct 2006 00:20:38 -0700
Links: << >>  << T >>  << A >>
Analog_Guy wrote:
> >
> >Eli Bendersky wrote:
> >
> > What does this technique lack to be the perfect solution for resets in
> > FPGA designs ? It seems that it evades all the common disadvantages of
> > conventional sync and async resets.
> >
> >
> The only thing I see that this technique lacks is the ability to filter
> (for noise, glitches)
> the incoming reset signal.  This approach can filter on the LO-HI
> transition of reset,
> but not on the HI-LO assertion.
>
> So, if there is any noise or glitching on the reset input resulting in
> a HI-LO transition, all
> logic in the FPGA is instantly reset (i.e. asynchronous reset).  Most
> designs I work with
> use some form of analog circuitry to provide the main reset to the
> FPGA.
>
> I do like the fact that reset will be applied even in the absence of a
> clock.  However, I have not yet implemented this technique because I am
> not sure how to provide filtering on the HI-LO transition of the input
> reset signal without requiring a clock.  Can anyone help with this?
> What are your ideas?

This isn't different from the "normal" async reset, however, where the
reset signal isn'f filtered. The solution usually used is an external
reset circuit (they come packed in nice tiny ICs these days) that
provides a clean reset signal of 200 ms (or whatever you set it to)
whenever there's a problem with the supplies, and as a byproduct, when
the power is going up.

Eli


Article: 110274
Subject: Re: longest webcase record -- understandably so
From: "colin" <colin_toogood@yahoo.com>
Date: 13 Oct 2006 00:50:24 -0700
Links: << >>  << T >>  << A >>
Jim

Unfortunately we haven't purchased the jtag debugger option where you
can manually tri-state and read the state of pins so injecting my own
levels is not easy. However your quite right, it is fast coming to this
and I am going to end up with adding a couple of 0R resistors so that I
can remove them and drive the net myself.

Colin

Jim Granville wrote:
> colin wrote:
>
> > Jim
> >
> > I'm using a coolrunner II (which I said in my first email).
> > I think they are the only CPLDs that support SSTL but if anyone knows
> > of another familly then I'd love to take a look.
> >
> > I'm fairly certain that the IO config isn't removed during boundary
> > scan because I can read the functional state of pins using JTAG and so
> > can chipscope for FPGAs.
>
> Failing a definitive reply from Xilinx, you could always just test it ?
> IP threshold is a fairly easy thing to check, especially if you have
> all the read-pathway working.
> 
> -jg




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