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 152300

Article: 152300
Subject: Re: die's in different packages
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 4 Aug 2011 21:28:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 1, 7:09=A0am, "sharanbr" <sharanb@n_o_s_p_a_m.hcl.com> wrote:
> >Sharan wrote:
> >> can someone tell me if there is any differences in the die for the
> >> following 2 devices in virtex-7
>
> >> XC7VX415TFFG1158 and XC7VX415TFFG1927
>
> >> Both these devices are listed as having same logic resources.
> >> XC7VX415TFFG1158 has 35 X 35 mm package
> >> XC7VX415TFFG1927 has 45 X 45 mm package
>
> >> Can I assume that the only difference is the package and the
> >> underlying die is going to be the same?
>
> >> TIA
>
> >I'm not in the V7 camp yet, but to date that is the way
> >Xilinx handles chip products. =A0For each family and gate
> >size there is one die, which has different bond-outs
> >depending on the package. =A0If it's a small die in a
> >large package you end up with non-connected package pins.
> >A large part in a small package ends up with unbonded
> >IOB's. =A0But open the parts in the FPGA editor and you
> >see the exact same diagram with just different labels
> >on the IOB's. =A0In fact on the smaller packages you
> >can use the unbonded IOB's as extra resources if you
> >run out of fabric flops for example.
>
> >-- Gabor
>
> Thanks, Gabor.
>
> Also, can you tell why certain devices are in a specific package while
> another device with more supported pins is in a smaller package.
>
> For example (example only, nothing specific to Virtex-7)
> v7vx1140t - min package is 45 x 45 mm package & supports 480 pins
> v7vx585T =A0- min package is 35 x 35 mm package & supports 600 pins
>
> I am not sure why a 480 pin needs 45X45 mm package while 600 pins is put =
in
> a 35X35 mm package
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com- Hide quoted text -
>
> - Show quoted text -

Trying again, as the first post doesn't seem to have gone through (at
least on google groups).

The 7VX1140T will be available in two packages the FLG1928 and the
FLG1930 both of these are 45x45mm 1.0mm pitch packages.

The 7VX1140T-FLG1928 supports 0 GTX lanes, 96 GTH lanes and 480 IO
The 7VX1140T-FLG1930 supports 0 GTX lanes, 24 GTH lanes and 1100 IO

The 7VX585T will be available in two packages the FFG1157 (35x35mm)
and the FFG1761 (42.5x42.5mm) both of these are 1.0mm pitch packages.

The 7VX585T-FFG1157 supports 20 GTX lanes, 0 GTH lanes and 600 IO
The 7VX585T-FFG1761 supports 36 GTX lanes, 0 GTH lanes and 850 IO


Your original comparison was only for the Select I/O pins which is why
it seemed odd to you.  Each of the GTX/GTH (MGT) lanes takes 4 pins
for the TX/RX and for each quad block of MGTs there are 2 reference
clocks (4 pins) plus additional power and ground pins.

Ed McGettigan
--
Xilinx Inc.

Article: 152301
Subject: Re: Regarding process time calculation
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 05 Aug 2011 08:38:56 +0100
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> writes:

> Most of my experience with this has been as an amused observer, rather 
> than an appalled participant.  It stemmed from a corporate rule "thou 
> shalt make the synthesis tool happy about timing" and a rather aggressive 
> design group from out of state that was known to have scripts that would 
> do synthesis runs over and over until one happened to meet timing, then 
> stop and ship that file 'upstairs'.

Ahh, I can see where that might cause hassle.  

I'm not a fan of stochastic timing closure... I tend to fix timing
problems by grovelling through the tmiing reports on the failing paths
and fixing something in the RTL to make life easier for the tools
(I tend not to push silicon right to it's limits, so I can get
away with that!)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 152302
Subject: Re: Regarding process time calculation
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 05 Aug 2011 08:50:16 +0100
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Martin Thompson <martin.j.thompson@trw.com> wrote:
>
> (snip on timing of processors and FPGAs)
>
>> More usefully (again IMHO) there are statistical methods for measuring
>> execution time and its variability down various code paths, which can be
>> used to provide arbitrarily high levels of confidence as to the
>> likelihood of missing a real-time deadline, as well as showing what to
>> optimise to improve the worst-case - this sometimes means using what
>> might be regarded in mainstream compsci as "inefficient" algorithms, as
>> they have better bounds on worst-case performance, even at the expense
>> of average performance.  I ought to stop now, I'm no doubt "rambling to
>> the choir" as well as getting off-topic :)
>
> Sounds right to me.  Now, isn't that also true for FPGAs?

The statistics or the algorithms?

Certainly, FPGAs often suit different algorithms.

And yes, the statistics is also there... I should've made that clear at
the start - I put "worst-case" in quotes without explaining what i
meant.  Sorry about that.

>
>>>> In hardware, the tools know everything they need to about the timing 
>>>> of the chips and can give you a "cast-iron" statement as to how 
>>>> fast things will be in the worst-case.
>
>>> They might do some rounding up in the timing, to be sure.
>
>> I'm not sure what you mean by that:  The tools "know" worst-case 
>> timings for the various silicon paths and add them all up.  
>> Rounding doesn't come into it.
>
> Consider that some timings might be Gaussian distributed with
> a tail to infinity.  Also, that it is really difficult to get
> the exact timings for all possible routing paths.  

Indeed.  It's a little easier for the FPGA, especially in a highly
pipelined design as the timing paths are broken up much more - so there
are less "long chains of logic and routing" than their might be "chains
of control flow through software".  

As you say, it's a very simialr problem, but the FPGA is much more
constrained.

> As with the
> real-time processor, you don't really want worst-case, but
> just sufficiently unlikely to be exceeded times.

Indeed, and because the FPGA vendors give us a timing analyser that
people are going to have a reasonably high level of trust in, they
define "unlikely to be exceeded" pretty conservatively.  Of course, if
your system is pushing the edges in some sense (esp. criticality of
operation) the prudent engineer will allow more margin etc.

>
> Some of the distributions won't quite be Gaussian, as some of
> the worst-case die are rejected.  Consider, though, that there
> are a finite number of electrons on a FET gate, ever decreasing
> as they get smaller.  
>
> Some of the favorite problems in physics class include determining
> the probability of all the air molecules going to one half of
> a room, or of a person quantum-mechanically tunneling through
> a brick wall, running at a given speed.   Both have a very low,
> but non-zero, probability.
>

I think we're in violent agreement.  My point really was (and I shouln't
have used the phrase "worst-case" without qualification) that getting an
arbitrarily high confidence of "meeting timing" is readily-available
with FPGA tools, but in the software domain, it's only just starting to
be an automatable task, and that out-of-the-box commercial compilers
(AFAIK) are of no assistance in that respect.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 152303
Subject: Re: Regarding process time calculation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 5 Aug 2011 08:11:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Martin Thompson <martin.j.thompson@trw.com> wrote:
(snip)

> Ahh, I can see where that might cause hassle.  

> I'm not a fan of stochastic timing closure... I tend to fix timing
> problems by grovelling through the tmiing reports on the failing paths
> and fixing something in the RTL to make life easier for the tools
> (I tend not to push silicon right to it's limits, so I can get
> away with that!)

After my previous post, I was thinking about how FPGA companies
have an incentive to quote faster devices, and so want the timing
reports to be fast, without an excessive margin.

There are always process variations, and for the user voltage
and temperature variations.  For most, it shouldn't be so hard
to stay within the voltage range, though maybe not so hard to
miss by a little.  (Slightly defective power supply.)

Temperature is a little harder to control.  If one is too close
on timing, and the temperature is a little high, the design
could fail.

-- glen

Article: 152304
Subject: Re: image storing into BRAM
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 05 Aug 2011 09:21:51 +0100
Links: << >>  << T >>  << A >>
valtih1978 <do@not.email.me> writes:

> I remember there was a picoBlaze-related program that could update BRAM in a
> compiled bitstream with any userdata.

Data2MEM is the tool I think you're thinking of.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 152305
Subject: Re: image storing into BRAM
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Fri, 05 Aug 2011 04:11:30 -0500
Links: << >>  << T >>  << A >>
>valtih1978 <do@not.email.me> writes:
>
>> I remember there was a picoBlaze-related program that could update BRAM
in a
>> compiled bitstream with any userdata.
>
>Data2MEM is the tool I think you're thinking of.
>
>Cheers,
>Martin
>
>-- 
>martin.j.thompson@trw.com 
>TRW Conekt - Consultancy in Engineering, Knowledge and Technology
>http://www.conekt.co.uk/capabilities/39-electronic-hardware
>

I do hope the OP enjoys reading The Fine Data2mem Manual (UG437, for those
of a curious turn of mind).
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152306
Subject: QuartusII Ver11.0 programmer problems?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 5 Aug 2011 16:34:49 +0100
Links: << >>  << T >>  << A >>
I have a client who is trying to use the QuartusII Ver 11.0
stand alone programmer to program a Cyclone IV board, and is having
problems and his machine isn't seeing the programmer (It's an Entner
EEBlaster but it also can't see a Terasic blaster so I'm confident
that isn't the problem).

Version 9.0 of the programmer can see it OK but can't drive the Cyclone IV
on his board.

Has anyone seen any problems like this before and have any recommendations?


Thanks for any pointers,


Nial Stewart

----------------------------------------------------------
Nial Stewart Developments Ltd        Tel: +44 131 516 8883
32/12 Hardengreen Business Park      Fax: +44 131 663 8771
Dalkeith, Midlothian
EH22 3NX
www.nialstewartdevelopments.co.uk



Article: 152307
Subject: Re: Regarding process time calculation
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 05 Aug 2011 10:34:50 -0500
Links: << >>  << T >>  << A >>
On Fri, 05 Aug 2011 08:38:56 +0100, Martin Thompson wrote:

> Tim Wescott <tim@seemywebsite.com> writes:
> 
>> Most of my experience with this has been as an amused observer, rather
>> than an appalled participant.  It stemmed from a corporate rule "thou
>> shalt make the synthesis tool happy about timing" and a rather
>> aggressive design group from out of state that was known to have
>> scripts that would do synthesis runs over and over until one happened
>> to meet timing, then stop and ship that file 'upstairs'.
> 
> Ahh, I can see where that might cause hassle.
> 
> I'm not a fan of stochastic timing closure... I tend to fix timing
> problems by grovelling through the tmiing reports on the failing paths
> and fixing something in the RTL to make life easier for the tools (I
> tend not to push silicon right to it's limits, so I can get away with
> that!)

Interestingly enough, the engineering group that I was with (which was a 
short walk away from the production line) felt exactly the way you did -- 
they would go as far as look for the worst possible path, and if it 
passed timing, but barely, they'd look for things sticking out and fix 
them.

The other group consistently got rewarded for "getting done" quickly, and 
somehow no one ever kept track of the number of times that their work was 
what was stalling production (while we fixed it in our "spare time", 
because we were closer).

-- 
www.wescottdesign.com

Article: 152308
Subject: Re: Regarding process time calculation
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 5 Aug 2011 16:43:01 +0100
Links: << >>  << T >>  << A >>
> The balance has stemmed from folks taking the Xilinx speed grades at face
> value, and using what the synthesis tool says (using Xilinx's defaults)
> at face value.  Once the group learned that you have to force a bit of
> margin into the process (and the group thinks that a design that fails to
> synthesize once out of ten is a problem, as opposed to thinking that a
> design that succeeds once out of twenty is 'shippable') then those
> problems went away.


Tim, are talking about synthesis or the timing analysis after P&R?


Nial 



Article: 152309
Subject: Re: Regarding process time calculation
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 05 Aug 2011 11:41:53 -0500
Links: << >>  << T >>  << A >>
On Fri, 05 Aug 2011 16:43:01 +0100, Nial Stewart wrote:

>> The balance has stemmed from folks taking the Xilinx speed grades at
>> face value, and using what the synthesis tool says (using Xilinx's
>> defaults) at face value.  Once the group learned that you have to force
>> a bit of margin into the process (and the group thinks that a design
>> that fails to synthesize once out of ten is a problem, as opposed to
>> thinking that a design that succeeds once out of twenty is 'shippable')
>> then those problems went away.
> 
> 
> Tim, are talking about synthesis or the timing analysis after P&R?

Sorry -- muddled thinking working in concert with mostly being an 
observer.

Timing analysis after P&R, yes.

-- 
www.wescottdesign.com

Article: 152310
Subject: Re: QuartusII Ver11.0 programmer problems?
From: "scrts" <mailsoc@[remove@here]gmail.com>
Date: Sat, 6 Aug 2011 17:17:28 +0300
Links: << >>  << T >>  << A >>

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:9a2gthFnv8U1@mid.individual.net...
>I have a client who is trying to use the QuartusII Ver 11.0
> stand alone programmer to program a Cyclone IV board, and is having
> problems and his machine isn't seeing the programmer (It's an Entner
> EEBlaster but it also can't see a Terasic blaster so I'm confident
> that isn't the problem).
>
> Version 9.0 of the programmer can see it OK but can't drive the Cyclone IV
> on his board.
>
> Has anyone seen any problems like this before and have any 
> recommendations?
>
>
> Thanks for any pointers,

Hello,
I had problems when installed very old FTDI drivers. Altera programmer gets 
frustrated when any FTDI chip is connected, but works if drivers are new. 
Tell the customer to unplug all the USB<->UART devices firstly or better to 
unplug everything from the USB, except the programmer.

Regards,
Tomas D. 



Article: 152311
Subject: FPGA
From: "ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com>
Date: Sun, 7 Aug 2011 04:00:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all

I want to do a project with a FPGA. The FPGA that I choos is ALTERA
Cyclone III.I think that there is no analog input in that. Of course,
I know that I can use an external ADC(A/D) but I cannot do it because
my inputs and outputs are too much.

can everyone tell me a FPGA from this family (ALTERA) that have analog
inputs and output?

Regards

Article: 152312
Subject: Re: FPGA
From: "Phil Emmup" <phile@hotnots.rot>
Date: Sun, 7 Aug 2011 12:25:19 +0100
Links: << >>  << T >>  << A >>

"ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com> wrote in message 
news:1a84ac7b-ee97-45b5-9bf7-10343d9571b4@g4g2000yqb.googlegroups.com...
> Hi all
>
> I want to do a project with a FPGA. The FPGA that I choos is ALTERA
> Cyclone III.I think that there is no analog input in that. Of course,
> I know that I can use an external ADC(A/D) but I cannot do it because
> my inputs and outputs are too much.
>
> can everyone tell me a FPGA from this family (ALTERA) that have analog
> inputs and output?
>
> Regards

AFAIK none of the Altera Cyclone or Stratix series have 'analog' I/O.

The only combo devices I am aware of and have tried to use are the Actel 
Fusion series. The downside is the analog portion tends to have low usable 
bandwidth (like 1MHz), and the ADC's of low resolution (12bits max) and low 
sample rate (600kHz) so for most of my applications are a) expensive, and b) 
unusable.

Your best bet if you have limited I/O resource ( and even with plenty of I/O 
resource!) is to use ADC's and DACs with serial I/O. You can get some pretty 
decent fast ADC's now with LVDS DDR outputs which will easily interface with 
your Cyclone III.

The trouble with trying to make FPGA's a real total SOC solution is you 
always end up with a very expensive compromise with lots of spare unusable 
expensive resource which you have paid for. The same applies (IMHO) with 
embedding processors in an FPGA. Why pay $200 for an integrated solution 
when a $20 FPGA and a separate $2 processor fits the bill?  Same applies to 
trying to integrate analog devices on to an FPGA.

Just my opinion

Phil





Article: 152313
Subject: RS232
From: "ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com>
Date: Sun, 7 Aug 2011 05:25:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all

I am using Altera DE0 Cyclone III board.

I am confused about the RS232 connection in DE0 Cyclone II. my
question is that:

There are some connection in FPGA board related to the RS232. Dose it
mean that there is a transceiver in the DE0 board or I should connect
it to a tranceiver?

Regards

Article: 152314
Subject: Re: RS232
From: "Phil Emmup" <phile@hotnots.rot>
Date: Sun, 7 Aug 2011 14:29:07 +0100
Links: << >>  << T >>  << A >>

"ECS.MSc.SOC" <mahdiyar.sarayloo@gmail.com> wrote in message 
news:11e1075b-601d-4229-8345-5b02cc64a8ed@y16g2000yqh.googlegroups.com...
> Hi all
>
> I am using Altera DE0 Cyclone III board.
>
> I am confused about the RS232 connection in DE0 Cyclone II. my
> question is that:
>
> There are some connection in FPGA board related to the RS232. Dose it
> mean that there is a transceiver in the DE0 board or I should connect
> it to a tranceiver?
>
> Regards

1) Download the manual here:-
http://tinyurl.com/cannot-be-arsed

2) Turn to page 37 and read section 4.8

3) If you want further info on the ADM3202 then Google and search yourself.

4) Don't give up the day job.

Phil 



Article: 152315
Subject: Newbie PCB
From: "linobi" <linobi@n_o_s_p_a_m.msn.com>
Date: Mon, 08 Aug 2011 06:52:10 -0500
Links: << >>  << T >>  << A >>
Hi there!

I need some advice. I want to make a circuit to drive a VGA monitor. I've
done it with the FPGA trainer boards with Xilinx chips, but now I want to
design a custom board that host only the necessary circuitry to do so and
not depend on eval boards with lot of stuff I don't need.

I've got already a bit experience on designing PCBs, I get pretty much
along with the EagleCad, I've build mostly boards with microcontrollers and
simply stuff. But now for what I see, handling FPGA is a completely
different thing.

For what I've been reading, FPGA need a lot of requirements, 50-ohms
impedance for some clock traces, copper layer thickness, lots of different
power planes,... heck, there is even some excel spreasheet from altera to
calculate power supply stage decoupling caps =S

Now I realize this might be a project beyond my current training, however,
I want to give it a shot. I just need the basics: voltage regulators,
configuration ROM, 50MHz clock, downloading cable interface; and of course,
the VGA dac and some extra broke out pins to interface a microcontroller.

Now, my question is... from the two FPGA biggest names, Altera and Xilinx,
which one do you think would be easier to implement? Like in the
programming interface, in meeting the power requirements, clock sources,
etc...
I mean, it's not that I want to start a flame war, I suppose there must be
one superior in this particular aspect, or maybe not, and both are equally
easy/difficult to use.

And of course, as a last thought, if you thing I better should stick with a
demo board and leave this for the future when I get to study more about
transmision lines, advanced CAD tools, etc...

Regards 

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152316
Subject: elf of jpeg code to the microblaze
From: "system85" <bouthaina.damak@n_o_s_p_a_m.gmail.com>
Date: Mon, 08 Aug 2011 06:52:40 -0500
Links: << >>  << T >>  << A >>
Hello 
I want to compile rhe jpeg code for the microblaze processor.
So i download the gnu tool for the microblaze ( i follow this
http://xilinx.wikidot.com/mb-gnu-tools)
I use a ubunto machine
to compile i use the command: mb-linux-gcc timer.cpp jpge.cpp jpgd.cpp
tga2jpg.cpp
So that i obtain the file a.out.
So what is the command to use now to have the executable file.
Thanks in advance.




	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152317
Subject: Re: elf of jpeg code to the microblaze
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 08 Aug 2011 11:26:50 -0500
Links: << >>  << T >>  << A >>
On Mon, 08 Aug 2011 06:52:40 -0500, system85 wrote:

> Hello
> I want to compile rhe jpeg code for the microblaze processor. So i
> download the gnu tool for the microblaze ( i follow this
> http://xilinx.wikidot.com/mb-gnu-tools) I use a ubunto machine
> to compile i use the command: mb-linux-gcc timer.cpp jpge.cpp jpgd.cpp
> tga2jpg.cpp
> So that i obtain the file a.out.
> So what is the command to use now to have the executable file. Thanks in
> advance.

You need to call the compiler with a flag to the linker to use a linker 
command file that is specific to the Microblaze installation that you 
have in your FPGA.  It needs to call out ROM and RAM areas, and specify 
whatever segments your code and libraries need to have specified.

The best way to get this is to probably start with an example project 
that uses the tools, then figure out how to rip out the c files that are 
in there and replace them with your own.

-- 
www.wescottdesign.com

Article: 152318
Subject: Re: Newbie PCB
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 8 Aug 2011 17:50:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
linobi <linobi@n_o_s_p_a_m.msn.com> wrote:

> I need some advice. I want to make a circuit to drive a VGA monitor. I've
> done it with the FPGA trainer boards with Xilinx chips, but now I want to
> design a custom board that host only the necessary circuitry to do so and
> not depend on eval boards with lot of stuff I don't need.

So one of the smaller FPGAs in the series...

> I've got already a bit experience on designing PCBs, I get pretty much
> along with the EagleCad, I've build mostly boards with microcontrollers and
> simply stuff. But now for what I see, handling FPGA is a completely
> different thing.

I believe that some of the smaller ones have simpler to work
with packages.  BGA is likely not easy for a first try.
(I haven't tried, so I can't really say.)

> For what I've been reading, FPGA need a lot of requirements, 50-ohms
> impedance for some clock traces, copper layer thickness, lots of different
> power planes,... heck, there is even some excel spreasheet from altera to
> calculate power supply stage decoupling caps =S

VGA doesn't need the top speed, but you still need to do some for
both decoupling and impedance.   Series termination is not so hard,
and should work for VGA speeds.  What else will your FPGA do besides
drive a VGA?  I can imagine a while graphical terminal, which should
fit in a fairly small one.

> Now I realize this might be a project beyond my current training, however,
> I want to give it a shot. I just need the basics: voltage regulators,
> configuration ROM, 50MHz clock, downloading cable interface; and of course,
> the VGA dac and some extra broke out pins to interface a microcontroller.

Also some data input source?

(snip)

> And of course, as a last thought, if you thing I better should stick with a
> demo board and leave this for the future when I get to study more about
> transmision lines, advanced CAD tools, etc...

You should know a little about impedance matching before you do 
much electronics at all these days.  

-- glen

Article: 152319
Subject: Re: Newbie PCB
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 08 Aug 2011 13:10:10 -0500
Links: << >>  << T >>  << A >>
On Mon, 08 Aug 2011 06:52:10 -0500, linobi wrote:

> Hi there!
> 
> I need some advice. I want to make a circuit to drive a VGA monitor.
> I've done it with the FPGA trainer boards with Xilinx chips, but now I
> want to design a custom board that host only the necessary circuitry to
> do so and not depend on eval boards with lot of stuff I don't need.
> 
> I've got already a bit experience on designing PCBs, I get pretty much
> along with the EagleCad, I've build mostly boards with microcontrollers
> and simply stuff. But now for what I see, handling FPGA is a completely
> different thing.
> 
> For what I've been reading, FPGA need a lot of requirements, 50-ohms
> impedance for some clock traces, copper layer thickness, lots of
> different power planes,... heck, there is even some excel spreasheet
> from altera to calculate power supply stage decoupling caps =S

The copper layer thickness requirement comes from current supply 
requirements.  50 ohms impedance on clock traces _hopefully_ only applies 
if you're going fast.

> Now I realize this might be a project beyond my current training,
> however, I want to give it a shot. I just need the basics: voltage
> regulators, configuration ROM, 50MHz clock, downloading cable interface;
> and of course, the VGA dac and some extra broke out pins to interface a
> microcontroller.
> 
> Now, my question is... from the two FPGA biggest names, Altera and
> Xilinx, which one do you think would be easier to implement? Like in the
> programming interface, in meeting the power requirements, clock sources,
> etc...
> I mean, it's not that I want to start a flame war, I suppose there must
> be one superior in this particular aspect, or maybe not, and both are
> equally easy/difficult to use.
> 
> And of course, as a last thought, if you thing I better should stick
> with a demo board and leave this for the future when I get to study more
> about transmision lines, advanced CAD tools, etc...

I don't know about which is better, but I would hazard a guess that if 
you're just running a 50MHz clock then you can get by with a lot less 
precision in the board than if you're trying to run right at the limit of 
the part.  The biggest clock issue I'd be concerned with would be 
reflections causing false clocks, and that can be cured by putting your 
oscillator as close to the FPGA as you can get it, and/or terminating the 
clock line.

I would recommend using a leaded package, as those can, with only 
moderate difficulty, be soldered by hand.  If you're willing to forgo 
being able to use all the pins, you may even be able to use a two-layer 
board, although it's probably smarter to go with at least a four-layer 
board with ground and power planes.

I think you could do this with EagleCad, if you're careful and know what 
you're doing.

-- 
www.wescottdesign.com

Article: 152320
Subject: Re: Newbie PCB
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 08 Aug 2011 13:10:25 -0500
Links: << >>  << T >>  << A >>
The best thing you could do is to have a look at some of the schematics and
gerber files from the Xilinx boards. Getting a schematic that is
functionally correct shouldnt be too much of a problem but you need to be a
bit more carefull with the pcb. The lower the frequency you use the easier
things will be, so you may be better off sticking to around 50MHz for your
first board. BGAs are not hard to work with, however you can forget about
soldering them yourself. So if you plan to do the soldering yourself then
use a non BGA package. I mainly use Xilinx devices but I doubt there is too
much difference between them and Altera.

Jon
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152321
Subject: Re: Newbie PCB
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 8 Aug 2011 18:52:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
maxascent <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:

> BGAs are not hard to work with, however you can forget about
> soldering them yourself. 

I believe I have heard stories about people doing BGA in a
toaster oven.  No idea about the success rate, though.

-- glen

Article: 152322
Subject: Re: Newbie PCB
From: "linobi" <linobi@n_o_s_p_a_m.n_o_s_p_a_m.msn.com>
Date: Mon, 08 Aug 2011 18:12:27 -0500
Links: << >>  << T >>  << A >>
Yes, I think I've seen some videos in Youtube where people does BGA rework
even with hot air. But no, definitely no; I'll stick with some QFP package
I can do by hand, so preferably one without pad. 

The thing is I noticed the 50-ohms impedance for the JTAG clock in the
Spartan-6 Configuration guide, and then I found the excel spreadsheet for
decoupling caps for the Cyclone IV power requirements. That's when I
started wondering which one would give me somewhat of a bigger error
margin. I'll go either with a Spartan 6 or 3A, or a cyclone IV, tqfp 100 or
144 max

Yes, I'll try to follow from some schematics I found, but on the other
hand, I don't think is very easy to mimic PCB routing, maybe just for
isolated parts like the VGA dac.

Thanks everyone, this is a really nice place to ask for help.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152323
Subject: Re: image storing into BRAM
From: GrizzlySteve <sbattazzo@gmail.com>
Date: Mon, 8 Aug 2011 23:16:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your question is very, very vague. It's not even clear what you're
asking, though if I were to take a wild guess, I'd say you want to
know how to get the data from the PC and store it in the BRAM.

This is very open-ended and depends on a lot of things, there are many
ways you can do it.. no single answer here.

What communication protocol would you like to use? RS232, USB,
something else?
You need something in the FPGA that can receive your data stream.

Then, you can either write a state machine which takes the data that
you've received and figures out where to put it, or you could put a
soft CPU in there and write an embedded program that could do the same
thing.
My full answer to this would also depend on what FPGA vendor you're
using, and what other hardware and interfaces are on board, assuming
you are using some already existing dev board or something of that
sort...

Supposing I was using a Xilinx FPGA to do this, I might go with a
Picoblaze soft microcontroller and a simple UART or similar. If I want
data faster than a UART can provide (sometimes I do), then I might use
an FTDI chip FT245, which works just like a serial port on the host PC
side, but gives the data to your device in parallel, 8-bits, and
several times faster than the best you can probably do with a UART. If
I still need something faster, then maybe I'd go for a Cypress FX2 USB
controller, which many FPGA dev boards happen to have on board. That'd
be overkill for what you're doing, but a good learning experience
anyway, if you happen to be using a board that has this.

Anyway, be more specific about what you have to work with and what
you're trying to do, and I'm sure I or somebody else here would be
happy to point you in the right direction.

Steve

Article: 152324
Subject: ISE bug?
From: "Andrew Holme" <ah@nospam.com>
Date: Tue, 9 Aug 2011 20:24:40 +0100
Links: << >>  << T >>  << A >>
I'm still using ISE 8.2i.  Yes, I know.  But it's served me well and I live 
by the "if it works don't upgrade it principle."

"Served me well" until now that is.  I may have found a bug.  My FPGA works 
sometimes.  Then I make certain innocent, harmless, neutral changes in an 
un-related area ... things stop working.  Not an uncommon experience for 
FPGA engineers, I know.

I've possibly traced it to a high speed (200 MHz) counter which is reloaded 
using data from another clock domain .  That data is stable when the counter 
reloads; but the point where it changes relative to the counter clock is 
uncontrolled.

I've checked the counter implementation using FPGA editor and noticed 
something curious about the LUT equations.  When it works I get:

<F>=((A1*A4)@A2); bel <vco_fa[0]/Mxor_d_Result1>.

when it doesn't work I get:

<F>=((~A2*(A1*A4))+(A2*(~A1+~A4))); bel <vco_fa[0]/Mxor_d_Result1>.

for the same LUT, which is bit 0 of the counter.

A1 is the reload control
A2 is counter Q[0]
A4 is the load input from another clock domain.

The above two boolean expressions are equivalent; but why does FPGA Editor 
dump them in different formats and how do I verify what is actually in the 
LUT?

I'm wondering if a glitch is coming through the LUT when A4 changes

TIA





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