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 147900

Article: 147900
Subject: Graphical User Interface project on Spartan-3 FPGA
From: "Simon Piekert" <currypieker@arcor.de>
Date: Tue, 1 Jun 2010 09:46:36 +0200
Links: << >>  << T >>  << A >>
I am a student of Electronics and I am going to do semester work on the 
topic "Implementation of Graphical User Interfaces on an Embedded Platform". 
We are allowed to choose a project of our own so this is why I am currently 
looking for suitable project ideas. The work shall be implemented on a 
Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU.

As most important features the board brings a Spartan-3A FPGA, a 50 MHz 
crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 
serial port, PS/2-style mouse/keyboard port, a VGA video output port and 
some push-buttons and switches.

I am not looking for an already finished solution to but I want to work it 
out for myself. And first of all I want to learn some more things about 
Microblaze programming on FPGA. The project must fit in the above mentioned 
topic so if someone did something similar or has ideas how to combine the 
GUI topic with FPGA Hardware / Software Co-Design then please send me 
details of this.

Thanks in advance. Any ideas on this subject are really appreciated.

Simon



Article: 147901
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 1 Jun 2010 03:20:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 3:46=A0am, "Simon Piekert" <currypie...@arcor.de> wrote:
> I am a student of Electronics and I am going to do semester work on the
> topic "Implementation of Graphical User Interfaces on an Embedded Platfor=
m".
> We are allowed to choose a project of our own so this is why I am current=
ly
> looking for suitable project ideas. The work shall be implemented on a
> Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU=
.
>
> As most important features the board brings a Spartan-3A FPGA, a 50 MHz
> crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232
> serial port, PS/2-style mouse/keyboard port, a VGA video output port and
> some push-buttons and switches.
>
> I am not looking for an already finished solution to but I want to work i=
t
> out for myself. And first of all I want to learn some more things about
> Microblaze programming on FPGA. The project must fit in the above mention=
ed
> topic so if someone did something similar or has ideas how to combine the
> GUI topic with FPGA Hardware / Software Co-Design then please send me
> details of this.
>
> Thanks in advance. Any ideas on this subject are really appreciated.
>
> Simon

Keep in mind that most low-cost development boards have low-
functionality VGA ports.  You can have red green and blue each
completely on or completely off, no 256 shades of gray per channel.
You can get several colors out of this but it's not much for a GUI.

Article: 147902
Subject: Re: Block RAM unusually long setup time ?
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 1 Jun 2010 03:34:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
You're still concerned about this?  Maybe you don't yet understand the
issues from how Gabor explained the situation.

FPGAs have flexible routing resources able to implement generic logic
interconnects.  The placement and routing of logic will determine
explicitly how fast the FPGA can possibly run.  The earliest days of
FPGA place & route may have seen a stronger attempt at getting "best
times" but runtimes were miserable and results were often short of
complete.  A competing tool adopted a "just enough" approach to place
& route, coming up with solutions which meet "at least" the
constraints given to the tools.  The quality of results improved
significantly and Xilinx eventually bought the technology.

The "just enough" philosophy results in placements and routes that
meet the constraints given to the tool but do not strive to improve
upon those numbers.  If the clock period is such that the registers
feeding the BlockRAM don't need to have the minimum achievable delays,
they typically won't.  If you expect to have small setup and hold
times from I/O pins to the BlockRAM, there's a fundamental disconnect:
the setup and hold times are "internal times" for the FPGA and do not
include the system level implementation of the I/O pins and global
clock buffers.  If implementing with I/O pins, the tools will try
their best to meet the setup and hold constraints the user provides
but no better and will often adjust the input delays of the various
pins (including the clock) to help attain those numbers.

Understanding the timing models means getting to know the chip better
at the silicon level.  If you understand I/O, clocking, CLBs, and
routing, you're well on your way to interpreting timing results
properly.  Being able to take the internal timing numbers for an FPGA
and apply those before you design takes a higher level of undestanding
often acquired from reading the FPGA user guide, app notes, and
running through timing analysis with the timing details turned on in
the logic path analysis.

The tool tries to give the user what's needed, not what's "best."
Even then there are limits based on what *can* be implemented within
the constraints of placement and routing.

Article: 147903
Subject: Re: Block RAM unusually long setup time ?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 1 Jun 2010 08:26:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 12:06=A0am, Sharath Raju <brshar...@gmail.com> wrote:
> On May 29, 1:16=A0am, Sharath Raju <brshar...@gmail.com> wrote:
>
>
>
>
>
> > On May 28, 7:05=A0pm, Gabor <ga...@alacron.com> wrote:
>
> > > On May 28, 9:47=A0am, Sharath Raju <brshar...@gmail.com> wrote:
>
> > > > I am afraid I forgot to include the code in the previous email:
>
> > > > DBR : Core512 port map (
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 -- Ram A
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ena =3D> ENA,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enb =3D> ENA,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wea =3D> WE,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web =3D> WE,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssra =3D> SSR,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssrb =3D> SSR,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clka =3D> CLOCK,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clkb =3D> CLOCK,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addra =3D> addr_1,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addrb =3D> addr_2,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 douta =3D> DOUT(71 =
downto 36),
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doutb =3D> DOUT(35 =
downto 0),
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dina =3D> DIN(71 do=
wnto 36),
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dinb =3D> DIN(35 do=
wnto 0)
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 );
>
> > > > -- Address Declaration
> > > > addr_1 <=3D '0' & ADDR(7 downto 0);
> > > > addr_2 <=3D '1' & ADDR(7 downto 0);
>
> > > > The code isn't much. Essentially, I am trying to pretend to have a =
256
> > > > locations X 72 bits deep memory, whereas the BLOCK RAM is physicall=
y a
> > > > 512 locations X 36 bits wide.
>
> > > > On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote:
>
> > > > > Hello,
>
> > > > > We are working on a project which involves using BLOCK RAMs. Sinc=
e we
> > > > > were new to Block RAMs, I (my colleague actually) instantiated a =
BLOCK
> > > > > RAM in VHDL using Xilinx's Block RAM IP core.
>
> > > > > The question is regarding timing:
>
> > > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device
> > > > > specifies the best case (setup + hold) time to be less than 1 ns,=
 and
> > > > > the maximum frequency of operation to be 280 MHz. Worst case figu=
res
> > > > > are not specified.
>
> > > > > =A0However, we checked the static timing report and found the set=
up
> > > > > times for the data, address and control signals to be approximate=
ly 4
> > > > > ns.
>
> > > > > Why is there such a substantial difference ?
>
> > > The static timing report includes clock to output delays
> > > of the driver as well as routing delays in addition to
> > > the actual Tsu of the RAM itself. =A0This should be broken
> > > into individual parts and well described in the timing
> > > report. =A0Generally speaking, you should always assume
> > > that routing delays will constitute a significant
> > > portion of your timing budget for any path. =A0According
> > > to Xilinx, the tools target 60% / 40% as a goal for
> > > logic delay / routing delay.
>
> > > HTH,
> > > Gabor
>
> > Thanks gabor .. shall check the static timing report in more detail
> > for the routing and clock to out delays.
>
> I checked the timing report..It explicitly mentions the setup time to
> be about 4ns.
>
> Here is a section of the report:
>
> Data Sheet report:
> -----------------
> All values displayed in nanoseconds (ns)
>
> Setup/Hold to clock CLOCK
> ------------+------------+------------+------------------+--------+
> =A0 =A0 =A0 =A0 =A0 =A0 | =A0Setup to =A0| =A0Hold to =A0 | =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0| Clock =A0|
> Source =A0 =A0 =A0| clk (edge) | clk (edge) |Internal Clock(s) | Phase =
=A0|
> ------------+------------+------------+------------------+--------+
> ADDR<0> =A0 =A0 | =A0 =A00.792(R)| =A0 =A00.598(R)|CLOCK_BUFGP =A0 =A0 =
=A0 | =A0 0.000|
> ADDR<1> =A0 =A0 | =A0 =A01.335(R)| =A0 =A00.164(R)|CLOCK_BUFGP =A0 =A0 =
=A0 | =A0 0.000|
> ADDR<2> =A0 =A0 | =A0 =A00.574(R)| =A0 =A00.773(R)|CLOCK_BUFGP =A0 =A0 =
=A0 | =A0 0.000|
> ADDR<3> =A0 =A0 | =A0 =A01.590(R)| =A0 -0.040(R)|CLOCK_BUFGP =A0 =A0 =A0 =
| =A0 0.000|
> ADDR<4> =A0 =A0 | =A0 =A00.729(R)| =A0 =A00.648(R)|CLOCK_BUFGP =A0 =A0 =
=A0 | =A0 0.000|
> ADDR<5> =A0 =A0 | =A0 =A02.400(R)| =A0 -0.688(R)|CLOCK_BUFGP =A0 =A0 =A0 =
| =A0 0.000|
> ADDR<6> =A0 =A0 | =A0 =A02.837(R)| =A0 -1.037(R)|CLOCK_BUFGP =A0 =A0 =A0 =
| =A0 0.000|
> ADDR<7> =A0 =A0 | =A0 =A03.441(R)| =A0 -1.521(R)|CLOCK_BUFGP =A0 =A0 =A0 =
| =A0 0.000|
>
> The complete report can be accessed here:http://sites.google.com/site/brs=
harath/DBR.twr?attredirects=3D0&d=3D1
> and here is the source:http://sites.google.com/site/brsharath/512x36.vhd?=
attredirects=3D0&d=3D1- Hide quoted text -
>
> - Show quoted text -

This report is for external IO (your ADDR<*> ports) timing relative to
an external clock (CLOCK_BUFGP).  These paths are variable depending
on where the IOs are placed, where the BlockRAM are placed and the net
delays between the two.  These paths are not the same as the data
sheet values for the BlockRAM that specify the internal component
timing.

Ed McGettigan
--
Xilinx Inc.

Article: 147904
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 01 Jun 2010 08:58:09 -0700
Links: << >>  << T >>  << A >>
On 5/29/2010 5:22 PM, Symon wrote:
> On 5/29/2010 9:57 AM, Michael Kellett wrote:
>> "Symon"<symon_brewer@hotmail.com> wrote in message
>> news:htpkq7$435$1@news.eternal-september.org...
>>> You can't meet the SI requirements of modern sub-ns rise time silicon's
>>> I/O in 'easy to solder' packages. It's because of the loop area.
>>>
>>> BGAs "are harder to probe" made me laugh! I bet you still have a logic
>>> analyser!
>>>
>>> One way to prevent yourself becoming an extinct dinosaur is to splash
>>> the
>>> cash on some decent stimulation tools. Your competitors have.
>>>
>>> Syms.
>> Lighten up Syms !
>>
>> For serious work with hardware I need a logic analyser and a scope !! (if
>> you can suggest a "stimulation tool" substitute I'm listening).
>>
>> I'm totally with Rick on this one - TQFP easy to hand solder, easy to
>> probe,
>> check, modify etc.
>> Most of my designs are one or two off, weirdo interfaces for
>> production line
>> test systems - the largest production run I've ever done with an FPGA was
>> about 100 off.
>>
>> I can see the appeal of BGA for mass production but I'm convinced that
>> TQFP
>> is cheaper to prototype in low pin counts. A serious FPGA (>20K LUT)
>> in 100
>> pin TQFP would be very nice.
>> But I accept that the number I might buy wouldn't make the supplier very
>> rich.
>>
>> Michael Kellett
>>
> Hi Michael,
>
> Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh,
> how light do you want? And then you talk about serious work. Talk about
> bringing the mood down! :-)
>
> Anyway, I have a 'scope too. I use it a fair bit, but not as much as
> LTSpice. I don't have a logic analyser. I have used Chipscope as a last
> resort, but a simulator like ModelSIM is my preferred tool for catching
> logic bugs. My spectrum analyser is far more useful than a logic
> analyser could be.
>
> Here's the skinny. You're correct that TQFPs are easier to hand solder
> than BGAs. Also, they are easier to probe. That's just as well because
> the SI of a TQFP because of the leads' loop area is poor enough that you
> may well need to probe them. I would have thought that the kind of ATE
> type equipment you are making needs to have good SI? When I design test
> equipment, I would not even consider a leaded part. Especially as, in a
> pinch, you can reflow a BGA with a toaster oven.
>
> Anyway, I don't know your specific circumstances, and I'm sure you have
> excellent reasons for choosing the parts you do. I would just like to
> point out that there are some jolly good incentives for ditching leaded
> parts, and that some investment in decent simulation tools and a toaster
> oven is the way forward!
>
> Cheers, Syms.
>

The logic analyzer's not because you don't understand what your FPGA is 
doing.  The logic analyzer's because you don't understand what the 
complex ASSP your FPGA is hooked up to is doing, because the data sheet 
is both 800 pages long and woefully incomplete.  And so you take your 
best guess at how it behaves, throw together a simulation model of it, 
and crank out your logic, but then you put it on the copper and use the 
LA to find out that you vastly misunderstood the bus interface because 
the translation from Japanese to English by way of Sanskrit wasn't clear.

Simulate, but verify.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 147905
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Marc Jet <jetmarc@hotmail.com>
Date: Tue, 1 Jun 2010 10:26:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
> I would love to ditch the FPGA
> and go 100% software, but there is one interface that makes that
> impossible I think.  The app configuration data (not FPGA
> configuration) comes over a serial port that has timing requirements
> for read that you can't meet with software.

In the past I have found that more often than not, software can be
very powerful when it's combined with a little bit of hardware.

For example, a single 74-type gate chip can convert a micro without
SPI interface into a working SPI slave.  It requires 100% dedication
of the software into the job, and dedicating a few I/O pins as well.

Of course, wonders can't be done with these tricks.  But you can get
gate latency out of software loops, and possibly also reduce the
software IO bandwidth.

Post more about your specific problem (here or in comp.arch.embedded)
if you think that there's not too much missing to reach the timing
goal.

Article: 147906
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 01 Jun 2010 17:57:26 GMT
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.com> wrote:

>On 5/29/2010 5:22 PM, Symon wrote:
>> On 5/29/2010 9:57 AM, Michael Kellett wrote:
>>> "Symon"<symon_brewer@hotmail.com> wrote in message
>>> news:htpkq7$435$1@news.eternal-september.org...
>>>> You can't meet the SI requirements of modern sub-ns rise time silicon's
>>>> I/O in 'easy to solder' packages. It's because of the loop area.
>>>>
>>>> BGAs "are harder to probe" made me laugh! I bet you still have a logic
>>>> analyser!
>>> in 100
>>> pin TQFP would be very nice.
>>> But I accept that the number I might buy wouldn't make the supplier very
>>> rich.
>>>
>>> Michael Kellett
>>>
>> Hi Michael,
>>
>> Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh,
>> how light do you want? And then you talk about serious work. Talk about
>> bringing the mood down! :-)
>>
>> Anyway, I have a 'scope too. I use it a fair bit, but not as much as
>> LTSpice. I don't have a logic analyser. I have used Chipscope as a last
>> resort, but a simulator like ModelSIM is my preferred tool for catching
>> logic bugs. My spectrum analyser is far more useful than a logic
>> analyser could be.
>>
>> Here's the skinny. You're correct that TQFPs are easier to hand solder
>> than BGAs. Also, they are easier to probe. That's just as well because
>> the SI of a TQFP because of the leads' loop area is poor enough that you
>>
>> Anyway, I don't know your specific circumstances, and I'm sure you have
>> excellent reasons for choosing the parts you do. I would just like to
>> point out that there are some jolly good incentives for ditching leaded
>> parts, and that some investment in decent simulation tools and a toaster
>> oven is the way forward!
>>
>> Cheers, Syms.
>>
>
>The logic analyzer's not because you don't understand what your FPGA is 
>doing.  The logic analyzer's because you don't understand what the 
>complex ASSP your FPGA is hooked up to is doing, because the data sheet 
>is both 800 pages long and woefully incomplete.  And so you take your 
>best guess at how it behaves, throw together a simulation model of it, 
>and crank out your logic, but then you put it on the copper and use the 
>LA to find out that you vastly misunderstood the bus interface because 
>the translation from Japanese to English by way of Sanskrit wasn't clear.
>
>Simulate, but verify.

My idea. Simulation doesn't catch mistakes and/or shortcomings in
models. I do a lot of verification using a LA and many times I find
potential problems even though the system (software + hardware) seems
to be working fine.

Besides, SI is not an issue for all designs. A TQFP package is OK for
many mainstream applications.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 147907
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: "Michael Metzner" <haselnussbaer@gmx.net>
Date: Tue, 1 Jun 2010 20:39:00 +0200
Links: << >>  << T >>  << A >>
maybe this is interesting for you

http://www.genode-labs.com/produkte/fpga-graphics

"Simon Piekert" <currypieker@arcor.de> schrieb im Newsbeitrag 
news:4c04bad5$0$6892$9b4e6d93@newsspool2.arcor-online.net...
>I am a student of Electronics and I am going to do semester work on the 
>topic "Implementation of Graphical User Interfaces on an Embedded 
>Platform". We are allowed to choose a project of our own so this is why I 
>am currently looking for suitable project ideas. The work shall be 
>implemented on a Xilinx Spartan-3A/3AN Starter Kit Board, making use of the 
>Microblaze CPU.
>
> As most important features the board brings a Spartan-3A FPGA, a 50 MHz 
> crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 
> serial port, PS/2-style mouse/keyboard port, a VGA video output port and 
> some push-buttons and switches.
>
> I am not looking for an already finished solution to but I want to work it 
> out for myself. And first of all I want to learn some more things about 
> Microblaze programming on FPGA. The project must fit in the above 
> mentioned topic so if someone did something similar or has ideas how to 
> combine the GUI topic with FPGA Hardware / Software Co-Design then please 
> send me details of this.
>
> Thanks in advance. Any ideas on this subject are really appreciated.
>
> Simon
>
> 



Article: 147908
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 01 Jun 2010 20:08:04 +0100
Links: << >>  << T >>  << A >>
On 6/1/2010 4:58 PM, Rob Gaddi wrote:
>
> The logic analyzer's not because you don't understand what your FPGA is
> doing. The logic analyzer's because you don't understand what the
> complex ASSP your FPGA is hooked up to is doing, because the data sheet
> is both 800 pages long and woefully incomplete. And so you take your
> best guess at how it behaves, throw together a simulation model of it,
> and crank out your logic, but then you put it on the copper and use the
> LA to find out that you vastly misunderstood the bus interface because
> the translation from Japanese to English by way of Sanskrit wasn't clear.
>
> Simulate, but verify.
>

Instead of using chipscope in an FPGA, you layout the board with a 
connector for your LA?  You probe these signals, possibly differential, 
going at 100's of MHz, maybe GHz? Doesn't that mean that your SI is 
compromised by having to provide physical access to the signals, so you 
have more chance of failure?

Crikey.

Why doesn't borrowing a demo board from your ASSP vendor not solve your 
interface debugging problems?

Cheers, Syms.

Article: 147909
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Tue, 1 Jun 2010 12:25:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 1:26 pm, Marc Jet <jetm...@hotmail.com> wrote:
> rickman wrote:
> > I would love to ditch the FPGA
> > and go 100% software, but there is one interface that makes that
> > impossible I think.  The app configuration data (not FPGA
> > configuration) comes over a serial port that has timing requirements
> > for read that you can't meet with software.
>
> In the past I have found that more often than not, software can be
> very powerful when it's combined with a little bit of hardware.
>
> For example, a single 74-type gate chip can convert a micro without
> SPI interface into a working SPI slave.  It requires 100% dedication
> of the software into the job, and dedicating a few I/O pins as well.
>
> Of course, wonders can't be done with these tricks.  But you can get
> gate latency out of software loops, and possibly also reduce the
> software IO bandwidth.
>
> Post more about your specific problem (here or in comp.arch.embedded)
> if you think that there's not too much missing to reach the timing
> goal.

Sure, I don't mind sharing.  I am pretty sure I've explored the
solution space though.  This interface has two parallel data bits as
input which are used for data and address.  There is a separate single
output for data output.  A strobe provides the clock and a command
signal indicates the last clock of the transaction into the
peripheral.  The transaction consists of N 2 bit "chunks" of data
followed by M 2 bit "chunks" of address and a single "chunk" of
command.  During the command "chunk" the two data bits indicate if the
transaction is a read or a write.  After the command "chunk" all
following strobes clock read data out on the output bit, both for
reads and writes.  A read transaction does not require the data
phase.  The number of "chunks" used for the address for a write is
implied by the peripheral.

The timing problem is that the data in is on the rising edge and the
data out is also on the rising edge with the master accepting on the
falling edge.  The first output bit is actually during the command
cycle.  So the first output bit has to be presented in less than a
clock cycle from the command flag being asserted and less than 30 ns
from the rising edge of the clock in the command "chunk".  In the FPGA
I use the address to drive a mux to select the data for read and
output the lsb directly because of the short timing.  The rest of the
addressed register is loaded into an output register to be shifted
out.

The software would have about 100 ns from the last address "chunk"
being clocked, 60 ns from the command flag going high and much less
than 30 ns from the command being clocked to driving the first output
bit.  I doubt it can be done at 62.5 MIPs.

Rick

Article: 147910
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: -jg <jim.granville@gmail.com>
Date: Tue, 1 Jun 2010 18:11:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 7:25=A0am, rickman <gnu...@gmail.com> wrote:
>
> The software would have about 100 ns from the last address "chunk"
> being clocked, 60 ns from the command flag going high and much less
> than 30 ns from the command being clocked to driving the first output
> bit. =A0I doubt it can be done at 62.5 MIPs.

What's the data rate ?

We have done a number of systems, where a smallish CPLD takes the ns-
level stuff, and dual-edge etc and converts it into a more micro-
compatible form.

Sometimes that has been parallel, and sometimes SPI/SSC

-jg

Article: 147911
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: Chris Abele <ccabele@yahoo.com>
Date: Tue, 01 Jun 2010 21:25:39 -0400
Links: << >>  << T >>  << A >>
On 6/1/2010 6:20 AM, John_H wrote:
> On Jun 1, 3:46 am, "Simon Piekert"<currypie...@arcor.de>  wrote:
>> I am a student of Electronics and I am going to do semester work on the
>> topic "Implementation of Graphical User Interfaces on an Embedded Platform".
>> We are allowed to choose a project of our own so this is why I am currently
>> looking for suitable project ideas. The work shall be implemented on a
>> Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU.
>>
>> As most important features the board brings a Spartan-3A FPGA, a 50 MHz
>> crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232
>> serial port, PS/2-style mouse/keyboard port, a VGA video output port and
>> some push-buttons and switches.
>>
>> I am not looking for an already finished solution to but I want to work it
>> out for myself. And first of all I want to learn some more things about
>> Microblaze programming on FPGA. The project must fit in the above mentioned
>> topic so if someone did something similar or has ideas how to combine the
>> GUI topic with FPGA Hardware / Software Co-Design then please send me
>> details of this.
>>
>> Thanks in advance. Any ideas on this subject are really appreciated.
>>
>> Simon
>
> Keep in mind that most low-cost development boards have low-
> functionality VGA ports.  You can have red green and blue each
> completely on or completely off, no 256 shades of gray per channel.
> You can get several colors out of this but it's not much for a GUI.

Looks to me like the "Xilinx Spartan-3A/3AN Starter Kit Board" has 
simple four bit resistor DAC for each color, which is to say sixteen 
shades for each of R, G, B or 4096 possible colors.  Not amazing, but 
probably adequate for a student's GUI project.

Article: 147912
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: backhus <goouse99@googlemail.com>
Date: Tue, 1 Jun 2010 23:07:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 1 Jun., 09:46, "Simon Piekert" <currypie...@arcor.de> wrote:
> I am a student of Electronics and I am going to do semester work on the
> topic "Implementation of Graphical User Interfaces on an Embedded Platform".
> We are allowed to choose a project of our own so this is why I am currently
> looking for suitable project ideas. The work shall be implemented on a
> Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU.
>
> As most important features the board brings a Spartan-3A FPGA, a 50 MHz
> crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232
> serial port, PS/2-style mouse/keyboard port, a VGA video output port and
> some push-buttons and switches.
>
> I am not looking for an already finished solution to but I want to work it
> out for myself. And first of all I want to learn some more things about
> Microblaze programming on FPGA. The project must fit in the above mentioned
> topic so if someone did something similar or has ideas how to combine the
> GUI topic with FPGA Hardware / Software Co-Design then please send me
> details of this.
>
> Thanks in advance. Any ideas on this subject are really appreciated.
>
> Simon

Hi Simon,
are you intending to use the VGA interface at all?
(for embeded systems, not all LCDs provide VGA input and over the net
it's totally irrelevant (e.g. X11))

As for a starting point you might consider this:
http://www.petalogix.com/resources/documentation/petalinux/userguide/ReferenceDesigns/XilinxBoards

There once was a downloadable version, ready to use with sources etc.
I'm not sure if this is still available.
But since it's linux there must be sources available.

Have a nice synthesis
 Eilert

Article: 147913
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: backhus <goouse99@googlemail.com>
Date: Tue, 1 Jun 2010 23:10:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Simon,
the mentioned link is for the Spartan 3E Starter kit.
I missed that you are using the S3A/AN Starter kit.
Sorry.

Have a nice synthesis
  Eilert

Article: 147914
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: "David L. Jones" <altzone@gmail.com>
Date: Wed, 2 Jun 2010 16:17:27 +1000
Links: << >>  << T >>  << A >>
Simon Piekert wrote:
> I am a student of Electronics and I am going to do semester work on
> the topic "Implementation of Graphical User Interfaces on an Embedded
> Platform". We are allowed to choose a project of our own so this is
> why I am currently looking for suitable project ideas. The work shall
> be implemented on a Xilinx Spartan-3A/3AN Starter Kit Board, making
> use of the Microblaze CPU.
> As most important features the board brings a Spartan-3A FPGA, a 50
> MHz crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a
> RS-232 serial port, PS/2-style mouse/keyboard port, a VGA video
> output port and some push-buttons and switches.
>
> I am not looking for an already finished solution to but I want to
> work it out for myself. And first of all I want to learn some more
> things about Microblaze programming on FPGA. The project must fit in
> the above mentioned topic so if someone did something similar or has
> ideas how to combine the GUI topic with FPGA Hardware / Software
> Co-Design then please send me details of this.
>
> Thanks in advance. Any ideas on this subject are really appreciated.
>
> Simon

How about implementing a game around the GUI system, like chess or
something?
I implemented Tom Kerrigan's TSCP Chess on a Spartan 3 pretty easily:
http://www.alternatezone.com/images/NanoChess.jpg
(it evetually had graphic pieces and nicer buttons)
http://www.tckerrigan.com/Chess/TSCP

Just an idea.

Dave.

-- 
================================================
Check out my Electronics Engineering Video Blog & Podcast:
http://www.eevblog.com




Article: 147915
Subject: Re: Graphical User Interface project on Spartan-3 FPGA
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 2 Jun 2010 08:39:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga David L. Jones <altzone@gmail.com> wrote:
...
> How about implementing a game around the GUI system, like chess or
> something?
> I implemented Tom Kerrigan's TSCP Chess on a Spartan 3 pretty easily:
> http://www.alternatezone.com/images/NanoChess.jpg
> (it evetually had graphic pieces and nicer buttons)
> http://www.tckerrigan.com/Chess/TSCP

> Just an idea.
http://www.fpgaarcade.com/


-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 147916
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Wed, 2 Jun 2010 08:41:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Sym,

You write without knowing anything about me.  I have a very high rate
of success on the board because of the extensive simulations I run.
But you can never eliminate the need to probe real hardware.

As to the SI issues, sure, you can get very high speed signals out of
an FPGA.  You can also drive static signals and everything in
between.  Many of my designs work very well in QFP packages and have
no need for special SI approaches.  When I am running a 32 MHz clock,
1 ns edge rates are not needed, so I slow them down to help prevent SI
problems.

Oh, yeah, I "do* have a logic analyzer and it comes in very useful.  I
was able to use it recently to find a configuration problem where my
customer had missed an aspect of how to properly initialize the
digital PLL used in the FPGA.  No amount of simulation would have
caught that!

Rick

Article: 147917
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Wed, 2 Jun 2010 08:59:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 9:11=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 2, 7:25=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > The software would have about 100 ns from the last address "chunk"
> > being clocked, 60 ns from the command flag going high and much less
> > than 30 ns from the command being clocked to driving the first output
> > bit. =A0I doubt it can be done at 62.5 MIPs.
>
> What's the data rate ?
>
> We have done a number of systems, where a smallish CPLD takes the ns-
> level stuff, and dual-edge etc and converts it into a more micro-
> compatible form.
>
> Sometimes that has been parallel, and sometimes SPI/SSC

The strobe the clocks the data is 33 ns high and 67 ns low.  So the
clock rate is 10 MHz with two data/addr bit input or 1 data bit output
on each strobe.

The problem with using a small CPLD is that the register set is up to
32, 8-bit registers.  With a 100 ns address to output time, there is
little chance of the read being done unless a copy of all registers
exists in the CPLD.  Also, some of the bits to be read are real time
status bits.  If the processor can get an interrupt, read the address
and write the readback data to the CPLD, then it could work, but it
has to happen in 100 ns.  If they had just used a standard SPI
interface it would have been a lot easier...

Rick

Article: 147918
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: Marc Jet <jetmarc@hotmail.com>
Date: Wed, 2 Jun 2010 09:01:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
The description is somewhat vague about the timing.  From what I
understand, the main problem is the short response latency. In fact
the problem sounds very much like a job for a small CPLD.

Your micro runs at 62.5 MIPS (16ns instruction cycle)?  If it's a fast
small micro with no pipeline, then that's a good start.

Given that the protocol samples on the falling edge, does it offer you
valid inputs already at the falling edge too?  If so, then you seem to
have <130ns from when the LSB of address is known to data out.  And
you seem to have <190ns from when ADR<MSB to 2> is known.  190ns would
be 11 instructions, which looks okay.

In a 74xx type solution, I'd dedicate 4 micro outputs to offer all 4
possible data bits to a 74 MUX which uses the 2 address LSBs to select
the correct data bit.  This relaxes the software latency constraint
considerable.  I'd store the "memory content" in an array indexed by
ADR<MSB to 2> and store the 4 possible data LSBs in that byte
(correctly ordered for the output port).  Then the software loop has
11 instructions to assemble ADR<MSB to 2>, do the 1 byte lookup, and
write it to the output port.

This solves only one detail of the problem.   Maybe it inspires you to
find a solution for it all.

Best regards

Article: 147919
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Wed, 2 Jun 2010 11:50:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 12:01=A0pm, Marc Jet <jetm...@hotmail.com> wrote:
> The description is somewhat vague about the timing. =A0From what I
> understand, the main problem is the short response latency. In fact
> the problem sounds very much like a job for a small CPLD.
>
> Your micro runs at 62.5 MIPS (16ns instruction cycle)? =A0If it's a fast
> small micro with no pipeline, then that's a good start.
>
> Given that the protocol samples on the falling edge, does it offer you
> valid inputs already at the falling edge too? =A0If so, then you seem to
> have <130ns from when the LSB of address is known to data out. =A0And
> you seem to have <190ns from when ADR<MSB to 2> is known. =A0190ns would
> be 11 instructions, which looks okay.
>
> In a 74xx type solution, I'd dedicate 4 micro outputs to offer all 4
> possible data bits to a 74 MUX which uses the 2 address LSBs to select
> the correct data bit. =A0This relaxes the software latency constraint
> considerable. =A0I'd store the "memory content" in an array indexed by
> ADR<MSB to 2> and store the 4 possible data LSBs in that byte
> (correctly ordered for the output port). =A0Then the software loop has
> 11 instructions to assemble ADR<MSB to 2>, do the 1 byte lookup, and
> write it to the output port.
>
> This solves only one detail of the problem. =A0 Maybe it inspires you to
> find a solution for it all.
>
> Best regards

Thanks for the advice.  That's an interesting approach.  There is a
bit more to it than that, but it sounds potentially doable depending
on the instructions required.  The protocol was never intended for
software, so no provision was made for the response time of software.
In fact, register 0 only uses a 4 bit address while the others can be
longer depending on the target.  All this is pretty easy in hardware,
but not so much in software.  So this is not the only issue.

The other issue is that the XMOS device is only an improvement over an
FPGA in that it can include a lot more logic in a small package.  The
power consumption is higher if all eight threads are running.  I don't
know what happens to power if only some are idling.  Since you can't
slow the clock while any one thread has to run at high speed, I should
think that would limit the power reduction you can achieve.

Rick

Article: 147920
Subject: Job experience? How?
From: "Socrates" <socconf@n_o_s_p_a_m.gmail.com>
Date: Wed, 02 Jun 2010 14:23:11 -0500
Links: << >>  << T >>  << A >>
Hello,
I am a third year student, but interested in FPGAs and linking my future
with this area of electronics. To have a point of view of my future, I've
browsed some job search pages using "FPGA" in search field. However almost
all of the offers are for "FPGA seniors", experience not less that ~5
years. How can I gain this experience if it is almost impossible to get
employed?

FPGA course in my uni is only on major degree studies, so I am doing a
"self-education" and learning FPGA design by myself, however PACMAN
implementation or something like that only gives experience on the syntax
itself, but not the real problems encountered every day. I have some
opinions:
- Search for intern programs at various companies that use FPGAs (its also
very hard to find, because many companies ask if You are eligible to work
in USA. If not - chances are minimum (I am from Lithuania, EU)).
- Try to find a job when you get paid by pay-per-module (however, I did not
find anything like this).
- The last chance I think I could do is to contact the company itself, ask
for the ability to work for free, since I need experience and if everything
goes OK, maybe they will employ me in the future. But how long the student
could work qualitatively without being paid if the task is really hard and
takes a long time? The result could end up with nothing: no experience and
no work done.

Tell me Your opinions :)

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

Article: 147921
Subject: Re: How good are Actel tools
From: "jb" <julius@n_o_s_p_a_m.orsoc.se>
Date: Wed, 02 Jun 2010 14:23:22 -0500
Links: << >>  << T >>  << A >>
>
>Can anyone confirm or dispute it the relative quality of Actel tools?
>Am I mistaken about them?
>
>Rick
>

I've not used a wide range of FPGA tool suites, just the other major two,
but I have found that Actel's, have been the worst yet. 

I don't do very large of complex designs, just stuff for single FPGAs, and
don't really play with the complex features of the suite, so I can't
comment on those areas (where they might actually impress).

The silver lining is that they are in bed with Synplify/Synopsys so you get
that for synthesis, but the pain starts with their layout backend tool.

I run everything Ubuntu GNU/Linux, and prefer batch-mode to a GUI
interface. This in itself is a fair challenge, you must export
LD_LIBRARY_PATHs whenever you run any of their tools (not so bad, I
guess.... but why the need?!) They're painful to use, too, in whenever you
launch a tool, there's about 5 minutes of it sitting there doing nothing,
as far as I can tell. This is really productive when all you need to do is
check if changes to a PDC are OK.

A place-and-route run always leaves my machine reeling for memory
afterwards, it somehow manages to chew through a couple of gig of RAM and
even make things start swapping. I'm convinced there's several memory
holes, but don't have the will to run this behemoth in valgrind.

Their tools take far longer than any other vendors for the same size design
on a similar-sized FPGA, and then you have the issue of any net with fanout
> ~10  resulting in large net delays, so their performance is always
underwhelming.

So on the whole I find using the Libero/Designer suite is never the
highlight of my day.

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

Article: 147922
Subject: Re: Job experience? How?
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Wed, 02 Jun 2010 16:38:32 -0400
Links: << >>  << T >>  << A >>
On Wed, 02 Jun 2010 14:23:11 -0500, "Socrates"
<socconf@n_o_s_p_a_m.gmail.com> wrote:

>Hello,
>I am a third year student, but interested in FPGAs and linking my future
>with this area of electronics. To have a point of view of my future, I've
>browsed some job search pages using "FPGA" in search field. However almost
>all of the offers are for "FPGA seniors", experience not less that ~5
>years. How can I gain this experience if it is almost impossible to get
>employed?
>
>FPGA course in my uni is only on major degree studies, so I am doing a
>"self-education" and learning FPGA design by myself, however PACMAN
>implementation or something like that only gives experience on the syntax
>itself, but not the real problems encountered every day. I have some
>opinions:
>- Search for intern programs at various companies that use FPGAs (its also
>very hard to find, because many companies ask if You are eligible to work
>in USA. If not - chances are minimum (I am from Lithuania, EU)).
>- Try to find a job when you get paid by pay-per-module (however, I did not
>find anything like this).
>- The last chance I think I could do is to contact the company itself, ask
>for the ability to work for free, since I need experience and if everything
>goes OK, maybe they will employ me in the future. But how long the student
>could work qualitatively without being paid if the task is really hard and
>takes a long time? The result could end up with nothing: no experience and
>no work done.
>
>Tell me Your opinions :)

Get some development boards and actually build a few things. Over here,
http://digilent.us/ and http://www.knjn.com/ are two sources, although I
see that KNJN does have an EU outlet now, over at
http://www.knjn.com/eu/ShopBoards_USB2.html

At any rate, build a few real things and not just syntax exercises.
Document some of the successes (and problems, with how you solved them!)
on a blog that you could point potential employers to.

As regards experience, yes employers would love to get somebody with a
few years but those folks are not always available. If you enjoy
"playing with" FPGAs enough that you work with them for the fun and the
challenge then that may be enough to get an employer to take a look.

Once you have done a few personal projects, go ahead and apply to some
of those "5 years experience" positions. Be honest about what you've
done and are doing; you're likely to get at least some positive
responses.

-- 
Rich Webb     Norfolk, VA

Article: 147923
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: -jg <jim.granville@gmail.com>
Date: Wed, 2 Jun 2010 14:29:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 3, 3:59=A0am, rickman <gnu...@gmail.com> wrote:
>
> The problem with using a small CPLD is that the register set is up to
> 32, 8-bit registers. =A0With a 100 ns address to output time, there is
> little chance of the read being done unless a copy of all registers
> exists in the CPLD. =A0Also, some of the bits to be read are real time
> status bits. =A0If the processor can get an interrupt, read the address
> and write the readback data to the CPLD, then it could work, but it
> has to happen in 100 ns. =A0If they had just used a standard SPI
> interface it would have been a lot easier...

 If this interface is so incompatible with SPI that you need 32 bytes
of local memory, then you are bumped into the 'smallest CPLD with RAM'
territory,  - and the choice there is not great. Maybe Actel or
SiliconBlue ?

I've hit this wall myself, and it raises a point:

 Rather than the uC+CPLD the marketing types are chasing, I would find
a CPLD+RAM more useful, as there are LOTS of uC out there already, and
if they can make 32KB SRAM for sub $1, they should be able to include
it almost for free, in a medium CPLD.

-jg

Article: 147924
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: rickman <gnuarm@gmail.com>
Date: Wed, 2 Jun 2010 15:05:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 5:29=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 3, 3:59=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > The problem with using a small CPLD is that the register set is up to
> > 32, 8-bit registers. =A0With a 100 ns address to output time, there is
> > little chance of the read being done unless a copy of all registers
> > exists in the CPLD. =A0Also, some of the bits to be read are real time
> > status bits. =A0If the processor can get an interrupt, read the address
> > and write the readback data to the CPLD, then it could work, but it
> > has to happen in 100 ns. =A0If they had just used a standard SPI
> > interface it would have been a lot easier...
>
> =A0If this interface is so incompatible with SPI that you need 32 bytes
> of local memory, then you are bumped into the 'smallest CPLD with RAM'
> territory, =A0- and the choice there is not great. Maybe Actel or
> SiliconBlue ?
>
> I've hit this wall myself, and it raises a point:
>
> =A0Rather than the uC+CPLD the marketing types are chasing, I would find
> a CPLD+RAM more useful, as there are LOTS of uC out there already, and
> if they can make 32KB SRAM for sub $1, they should be able to include
> it almost for free, in a medium CPLD.
>
> -jg

I won't argue with that for a moment.  But deciding what to put in a
part and which flavors to offer in what packages is decided in the
land of marketing.  As much as I whine and complain, I guess I have to
assume they know *something* about their jobs.  I am just very, very
frustrated because my designs always seem to be limited by the
available devices.  In some areas they produce a thousand variations
on a theme, I suppose because it is easy.  In other areas, like FPGAs,
we are told it is exquisitely expensive to add any additional features
and the variations seem to be limited to a small focused range.

I haven't looked at SiBlue in quite a while.  I wasn't even aware that
they were shipping product.  I have looked at Actel, but they tend to
have the same limitations in combining "more than a CPLD" in CPLD type
packages... they just don't have the same top-heavy product line which
would make you think they would branch out more at the low end.  When
I get more free time, I'll take another look at both of these.

One more complaint... selection guides are your friend.  I wish more
companies understood how useful a good, ***simple***, PDF file
selection guide can be.  We all know what the salient features of PLDs
are.  It is actually rather easy to put them all in a simple set of
tables showing the important aspects including package types and I/O
counts.  Yet this info can be hard to find on most PLD vendor's web
sites.

Rick



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