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 143975

Article: 143975
Subject: Re: Need some help creating a ring oscillator on a Spartan-3AN
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 5 Nov 2009 10:48:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 8:41=A0pm, "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote:
> "Sam Kerr" <stk...@purdue.edu> wrote in message
>
> news:alpine.WNT.2.00.0911020916180.1072@stkerr-Vista...
>
> > I'm trying to create a ring oscillator for my FPGA design but I've run
> > into some problems. Namely, it doesn't seem like any oscillation is
> > occurring. I've hooked up the output signal to LEDs and the serial port=
,
> > but neither of these shows any oscillations.
>
> Here you might find useful reference design:
>
> A. Maiti, R. Nagesh, A. Reddy, P. Schaumont, "Physical Unclonable Functio=
n
> and True Random Number Generator: a Compact and Scalable Implementation,"
> 19th Great Lakes Symposium on VLSI (GLSVLSI 2009), May 2009.http://rijnda=
el.ece.vt.edu/schaum/papers/2009glsvlsi.pdf
>
>
>
> > A few things I think might be happening is that the oscillation is so f=
ast
> > I just can't see it, the oscillation is too fast for the board, it's
> > getting optimized out during synthesis, or (probably) my Verilog file i=
s
> > implemented incorrectly.
>
> Constraining inverter's output signals with 'KEEP' attribute will do the
> job.
> Also, the oscillation frequency for 3 INVs can reach 450-500MHz (when
> implemented in V5).
>
> Regards,
> Krzysztof

I was able to measure ring oscillator frequency of 975MHz in V4 :)
(but that signal would not travel long in V4 fabric)

Antti



Article: 143976
Subject: Re: Need some help creating a ring oscillator on a Spartan-3AN
From: "Krzysztof Kepa" <nospam_blondikk@poczta.fm>
Date: Thu, 5 Nov 2009 20:51:59 +0100
Links: << >>  << T >>  << A >>

"Antti" <antti.lukats@googlemail.com> wrote in message 
news:db41b833-0e92-421b-90d8-0ebc9f557571@j4g2000yqe.googlegroups.com...
On Nov 5, 8:41 pm, "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote:
>> Also, the oscillation frequency for 3 INVs can reach 450-500MHz (when
>> implemented in V5).
>>
>I was able to measure ring oscillator frequency of 975MHz in V4 :)
>(but that signal would not travel long in V4 fabric)
>
>Antti

Nice, was it on purpose?
I mean I'm just curious whether it required manual routing or simply 'just 
happened' ?;)

Regards,
Krzysztof




Article: 143977
Subject: Does anyone ever use placement?
From: "Steve Ravet" <steve.ravet@arm.com>
Date: Thu, 5 Nov 2009 13:56:22 -0600
Links: << >>  << T >>  << A >>
Do any of you advanced users ever use the floorplanning tools to do 
placement?  I'm not talking about placing clock buffers or other individual 
items, I'm talking about ASIC style floorplanning for units and sub-units. 
I've asked AE's about that and the response is always to let the tool do 
placement.  So I'm asking experts:  Do you ever floorplan, and if so why? 
To speed up map?  To help with timing?  Thanks for any insight,

--steve



Article: 143978
Subject: Re: Need some help creating a ring oscillator on a Spartan-3AN
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 5 Nov 2009 12:27:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 9:51=A0pm, "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote:
> "Antti" <antti.luk...@googlemail.com> wrote in message
>
> news:db41b833-0e92-421b-90d8-0ebc9f557571@j4g2000yqe.googlegroups.com...
> On Nov 5, 8:41 pm, "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote:
>
> >> Also, the oscillation frequency for 3 INVs can reach 450-500MHz (when
> >> implemented in V5).
>
> >I was able to measure ring oscillator frequency of 975MHz in V4 :)
> >(but that signal would not travel long in V4 fabric)
>
> >Antti
>
> Nice, was it on purpose?
> I mean I'm just curious whether it required manual routing or simply 'jus=
t
> happened' ?;)
>
> Regards,
> Krzysztof

on purpose yes :)

just "fabric" speed measurement experiments, and trying out different
primitives to be used as on-chip oscillators
I think i did use RLOCs at least, the 975mhz travels to closest Flip
flop that divides by two, the clock is otherwise
unuseable in V4, ah yes, this was done when i did write my FPGA
Frequency Meter IP cores and JTAG software
well, that software and IP cores still could be used but as it was
depending on LPT based JTAG adapter so it
not much useful now, well at least not with that mode that it was
used, where it was possible to measure
clocks connected to FPGA without having any known reference (JTAG
timing was used as reference)

Antti







Article: 143979
Subject: Re: Does anyone ever use placement?
From: Gabor <gabor@alacron.com>
Date: Thu, 5 Nov 2009 13:04:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 2:56=A0pm, "Steve Ravet" <steve.ra...@arm.com> wrote:
> Do any of you advanced users ever use the floorplanning tools to do
> placement? =A0I'm not talking about placing clock buffers or other indivi=
dual
> items, I'm talking about ASIC style floorplanning for units and sub-units=
.
> I've asked AE's about that and the response is always to let the tool do
> placement. =A0So I'm asking experts: =A0Do you ever floorplan, and if so =
why?
> To speed up map? =A0To help with timing? =A0Thanks for any insight,
>
> --steve

My approach is let the tools run, and if they fail miserably
(generally only a matter of meeting timing, not completing
routing) then see how I can help them along.  I had a fairly
full Virtex 2 design and had some issues with timing.  This was
before Xilinx picked up PlanAhead and I tried the PlanAhead tool
from HierDesign.  I found that at least in my case PlanAhead
actually made matters worse than just letting the tools place
anything anywhere.  I imagine there are some more highly-
structured designs where this would not be the case.  About
the only other thing I do is place block RAM's when I find that
the tools are not placing them efficiently.  My experience has
been that the general FPGA fabric is best placed by the tools.

I should also note that my designs are generally for boards
that already exist so the pins are locked down.  I normally
assign pins myself except for things like DDR memory, where
I let the MIG core guide the pin placement, and even then
I restrict the banks to help in PCB layout.  Also my experience
is limited to Xilinx and Lattice parts.

Regards,
Gabor

Article: 143980
Subject: Re: Cyclone IV announced
From: Torfinn Ingolfsen <tingox@gmail.com>
Date: Thu, 05 Nov 2009 22:30:11 +0100
Links: << >>  << T >>  << A >>
Torfinn Ingolfsen wrote:
> Downloading as I write this.
> I run Ubuntu (which is not on the supported os list), but I'll try 
> anyway and report how it goes.

Installation worked, with a couple of fixes:
- the installation script is using csh, which isn't installed on Xubuntu 
(I'm usin Xubuntu 9.10) per default. I fixed it by installing tcsh (I 
used synaptic).
- I used 'sudo quartus_free/install' after unpacking to run the install 
script. I took all default values when installing.

> If it works in Ubuntu at all, I'll try it out to see how it works.

So far I have only tested that it (quartus) starts up, and that the 
menus work etc.
It does. Cool!
-- 
Torfinn Ingolfsen,
Norway

Article: 143981
Subject: Re: Does anyone ever use placement?
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 05 Nov 2009 23:18:35 GMT
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> wrote:

>On Nov 5, 2:56=A0pm, "Steve Ravet" <steve.ra...@arm.com> wrote:
>> Do any of you advanced users ever use the floorplanning tools to do
>> placement? =A0I'm not talking about placing clock buffers or other indivi=
>dual
>> items, I'm talking about ASIC style floorplanning for units and sub-units=
>.
>> I've asked AE's about that and the response is always to let the tool do
>> placement. =A0So I'm asking experts: =A0Do you ever floorplan, and if so =
>why?
>> To speed up map? =A0To help with timing? =A0Thanks for any insight,
>>
>> --steve
>
>My approach is let the tools run, and if they fail miserably
>(generally only a matter of meeting timing, not completing
>routing) then see how I can help them along.  I had a fairly
>full Virtex 2 design and had some issues with timing.  This was
>before Xilinx picked up PlanAhead and I tried the PlanAhead tool
>from HierDesign.  I found that at least in my case PlanAhead
>actually made matters worse than just letting the tools place
>anything anywhere.  I imagine there are some more highly-
>structured designs where this would not be the case.  About
>the only other thing I do is place block RAM's when I find that
>the tools are not placing them efficiently.  My experience has
>been that the general FPGA fabric is best placed by the tools.

I had to do that once but I used the constraints to force the location
of a block RAM. That improved timing considerably.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 143982
Subject: Re: Does anyone ever use placement?
From: rickman <gnuarm@gmail.com>
Date: Thu, 5 Nov 2009 16:28:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 2:56 pm, "Steve Ravet" <steve.ra...@arm.com> wrote:
> Do any of you advanced users ever use the floorplanning tools to do
> placement?  I'm not talking about placing clock buffers or other individual
> items, I'm talking about ASIC style floorplanning for units and sub-units.
> I've asked AE's about that and the response is always to let the tool do
> placement.  So I'm asking experts:  Do you ever floorplan, and if so why?
> To speed up map?  To help with timing?  Thanks for any insight,

Floorplanning is a major PITA, not from the perspective of the tools
not being easy to use (although I don't make any claims to the
contrary either) but just from a development perspective.  To use
floorplanning you need to add a fairly messy/complex step to your
process in order to get a design you can test.  This has to be
repeated each time you make a change, at least on the part changed.  A
small change to an HDL design can often result in much larger changes
to the implementation due to optimizations.

I can't say any of this for certain since I have not needed to
floorplan for almost a decade and I am sure the tools are better.  I
believe at least Xilinx has some incremental compile feature which
should help to minimize the extent of changes due to a design change.
That would help, but it still remains a messy proposition.

I know there are some people who use floorplanning regularly, Ray
Andraka for one.  He started with FPGAs back when we used schematic
for entry.  He had built up a large library of schematic functional
blocks with hierarchical placement properties which allowed him to
floorplan an entire design.  I believe he resisted HDL for some time
because he thought he would loose this investment.  After his
customers insisted that he use VHDL (government I believe) he looked
at it with a critical eye, tried some test cases with support from
Xilinx (his is mainly a Xilinx house) and found he could use the same
placement features by instantiating the same sort of functional and
primitive elements.  So I believe this has worked out very well for
him, especially since HDL also adds a lot of benefit from being text
based rather than requiring a particular product for the schematics.

The bottom line, yes, you can do projects with floorplanning which
will help with both fitting and speed in a design, especially if it
has repeating units.  But it is a long row to hoe and works best if
you will be using this process repeatedly to amortize the learning
curve costs as well as take advantage of design reuse that is
possible.  But if your project doesn't *require* it, why bother?

Rick

Article: 143983
Subject: Re: CPLD + MCU SoC from Cypress, free samples too!
From: rickman <gnuarm@gmail.com>
Date: Thu, 5 Nov 2009 17:16:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 6:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
> both free samples and 49$ starterkit available, my should be airborn
> right now somewhere between Paris and my place.
>
> The CPLD is small, 190MC, but it still much more then the 16MC
> availabel in ADI's ADuCs or ST's uPSD devices.
>
> PSoC 5, Cortex based devices will probably only be available next year
>
> Antti

You didn't say what product this is.  I assume it is the 8051 version
of the new PSOC?  Do they call that the PSOC 3?

I don't know what is going on with Cypress.  They have been saying the
PSOC whatever will be out "next year" since 2006.  Fool me once, shame
on you, fool me twice, shame on me!  I guess they may finally be
shipping PSOC 3.  I can't find a while paper on the PSOC 3/5
anywhere.  Is that because they don't have one or because it is hidden
behind all the video and flash stuff on their site?  I guess it is
also too much to ask for a selection guide rather than having to read
through all the data sheets just to find out what combinations of
features they are offering.  Bah!

I see one version of the PSOC 5 has the high resolution ADC while
*all* of the PSOC 3 with the 8051 CPU have the high resolution ADC.  I
don't see where any of them have two channels or comparable DACs.

I'm actually guessing you aren't talking about the PSOC 3.  You
describe a 190 cell CPLD, but the PSOC digital blocks are not
generically programmable.  They have predefined function blocks and I
don't believe they offer detailed info on rolling your own function
blocks.  I guess this has changed from the PSOC 1 tools.  But it
appears you have to use their graphical tool rather than an HDL.

Jeeze!  They can't even make a table of contents that works.  It
points to some file called "001-55036-1.pdf".  I guess that's why it's
preliminary...

Rick

Article: 143984
Subject: Re: CPLD + MCU SoC from Cypress, free samples too!
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 5 Nov 2009 21:01:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 3:16=A0am, rickman <gnu...@gmail.com> wrote:
> On Nov 5, 6:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > both free samples and 49$ starterkit available, my should be airborn
> > right now somewhere between Paris and my place.
>
> > The CPLD is small, 190MC, but it still much more then the 16MC
> > availabel in ADI's ADuCs or ST's uPSD devices.
>
> > PSoC 5, Cortex based devices will probably only be available next year
>
> > Antti
>
> You didn't say what product this is. =A0I assume it is the 8051 version
> of the new PSOC? =A0Do they call that the PSOC 3?
>
> I don't know what is going on with Cypress. =A0They have been saying the
> PSOC whatever will be out "next year" since 2006. =A0Fool me once, shame
> on you, fool me twice, shame on me! =A0I guess they may finally be
> shipping PSOC 3. =A0I can't find a while paper on the PSOC 3/5
> anywhere. =A0Is that because they don't have one or because it is hidden
> behind all the video and flash stuff on their site? =A0I guess it is
> also too much to ask for a selection guide rather than having to read
> through all the data sheets just to find out what combinations of
> features they are offering. =A0Bah!
>
> I see one version of the PSOC 5 has the high resolution ADC while
> *all* of the PSOC 3 with the 8051 CPU have the high resolution ADC. =A0I
> don't see where any of them have two channels or comparable DACs.
>
> I'm actually guessing you aren't talking about the PSOC 3. =A0You
> describe a 190 cell CPLD, but the PSOC digital blocks are not
> generically programmable. =A0They have predefined function blocks and I
> don't believe they offer detailed info on rolling your own function
> blocks. =A0I guess this has changed from the PSOC 1 tools. =A0But it
> appears you have to use their graphical tool rather than an HDL.
>
> Jeeze! =A0They can't even make a table of contents that works. =A0It
> points to some file called "001-55036-1.pdf". =A0I guess that's why it's
> preliminary...
>
> Rick

Rick, I agree on many accounts, something is badly wrong with Cypress,
ok some explanations: I was talking PSoC 3, yes, and it
HAS VERILOG programmable general purpose CPLD module!
I have tested the software and it uses cypress warp compiler
the missing "selection" guide is really PITA, I was trying to compare
the PSoC 1 versions, and just did give up!

Ok, from my point, Cypress could drop ALL their products and just
keep PSoC 3 :)

See actually initially it was like that, PSoC was done by separate
company (owned by cypress), for some reason that was changed
later and PSoC was taken back to mother company

Antti











Article: 143985
Subject: OK Xilinx users, it's time I was let in on the joke...
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 06 Nov 2009 17:14:21 +1100
Links: << >>  << T >>  << A >>
I've had it up to the eyeballs with Xilinx tools now. I'm seriously ready
to go postal in the lobby of Xilinx HQ. I don't expect perfection but this
really is beyond a joke.

Can someone please put me out of my misery, and finally admit that you
have _all_ been having me on for the past few years now! :O ...that it has
all been an elaborate hoax instigated by someone I offended in a past
life. ...that a team of engineers has been working for years to produce an
IDE that crashes randomly, and steadfastly refuses to launch tools on
Tuesday mornings and Friday afternoons? ...working for years on a
synthesizer that removes random bits of logic, or sits spinning in an
infinite loop on an entity that works in another project? ...that corrupts
my project file bi-monthly.

And worst of all - _you_ lot, telling me that Xilinx actually works, and
that you _can_ use it for more than flashing LEDs on the Spartan starter
kit. And I was gullible enough to believe you! :O :(

I've seen the light. You _cannot_ convince me that it is possible to
produce a commercial product in silicon using these tools. Period.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 143986
Subject: Re: Does anyone ever use placement?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Fri, 06 Nov 2009 08:41:35 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> I can't say any of this for certain since I have not needed to
> floorplan for almost a decade and I am sure the tools are better.  I
> believe at least Xilinx has some incremental compile feature which
> should help to minimize the extent of changes due to a design change.
> That would help, but it still remains a messy proposition.

My biggest problem is that the Xilinx placer is horribly bad. It seems
to place everything at random and then just hopes that it might be
able to meet the timing and route the mess. Of course if you have
time just run all the different seeds for the placement, one of them
might be good enough guess ;) Manual placement of the memories usually
helps a lot.

My own feeling is that the Altera placer is better than the Xilinx
altough it also has some problems with the different size memories
(M144k vs M9k etc.).

Fortunately there are physical synthesis tools for FPGAs from
3rd parties, they at least make reasonable placement for the FPGA
tools to start their work.



--Kim

Article: 143987
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 5 Nov 2009 23:13:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 8:14=A0am, Mark McDougall <ma...@vl.com.au> wrote:
> I've had it up to the eyeballs with Xilinx tools now. I'm seriously ready
> to go postal in the lobby of Xilinx HQ. I don't expect perfection but thi=
s
> really is beyond a joke.
>
> Can someone please put me out of my misery, and finally admit that you
> have _all_ been having me on for the past few years now! :O ...that it ha=
s
> all been an elaborate hoax instigated by someone I offended in a past
> life. ...that a team of engineers has been working for years to produce a=
n
> IDE that crashes randomly, and steadfastly refuses to launch tools on
> Tuesday mornings and Friday afternoons? ...working for years on a
> synthesizer that removes random bits of logic, or sits spinning in an
> infinite loop on an entity that works in another project? ...that corrupt=
s
> my project file bi-monthly.
>
> And worst of all - _you_ lot, telling me that Xilinx actually works, and
> that you _can_ use it for more than flashing LEDs on the Spartan starter
> kit. And I was gullible enough to believe you! :O :(
>
> I've seen the light. You _cannot_ convince me that it is possible to
> produce a commercial product in silicon using these tools. Period.
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

Mark,

you are taking it one level higher than I, I think i have said in
public
years ago that Xilinx has totally lost control over its software
development
and that their tools would come "completly unuseable" by the time 40nm
FPGA's come out to the market (unless they FIX their software
development flow!)

well Xilinx 40nm FPGA's are not yet on stock at digikey, so based on
that
and on my prediction Xilinx has still time to reach the complete
useless
status with their software

Antti

Article: 143988
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: luudee <rudolf.usselmann@gmail.com>
Date: Thu, 5 Nov 2009 23:43:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 1:14=A0pm, Mark McDougall <ma...@vl.com.au> wrote:
> I've had it up to the eyeballs with Xilinx tools now. I'm seriously ready
> to go postal in the lobby of Xilinx HQ. I don't expect perfection but thi=
s
> really is beyond a joke.

...

> I've seen the light. You _cannot_ convince me that it is possible to
> produce a commercial product in silicon using these tools. Period.
>
> Regards,
>
> --
> Mark McDougall, Engineer


Hi Mark,

I know these things can be really frustrating, but since IDE/EDK
11 I must say I have been quite happy. I should note that I am
a Linux user, and don't have the traditional Windows crap to deal
with.

I am now using 11.3, and my only concern is when they will force
me use the software SDK next release ... that's something I don't
look forward too ...

Perhaps if you can try to describe your problem in greater detail,
somebody might have a suggestion. Could you be running out of
memory or disk space ?

Cheers,
rudi

Article: 143989
Subject: Re: Does anyone ever use placement?
From: Kastil Jan <ikastil@stud.fit.vutbr.cz>
Date: Fri, 6 Nov 2009 09:02:03 +0100
Links: << >>  << T >>  << A >>
Hi,
   I do not know if I am an advanced user, but I have a few experiance with 
floorplanning tool. I tried use a PlanAhead tool to meet timing of the 
design in Virtex5 110 and failed misserably. But during this time I gained 
a few experiance, some of them comes from reading I did, others I 
discovered by my own.

First, you should floorplan complete and optimized design. Floorplanning 
is a complex issue, such as optimalization and it is much more harder to 
do both at the time.

Design should be modular. Meaning that if you have a design, where every 
unit communicates with every other on the high frequency (which is exactly what 
we had). Than you will not be able to floorplan very effectively (you can 
at least place some critical components). If you have such modules, that 
the problems are inside the module, than your floorplanning will help. 
PlanAhead also allows you to run map and par only on the problematic 
module, which can decrease time of the work.

Be carefull with the LOC (placing of the part). Once I tried to LOC all 
components of the component in the design that was placed to ensure 
repeatibility of the map and par. The result was that map failed saying 
that LOC constrains are incorect.

A few times I met a strange situation, where correct LOC (on LUT, 
register, ..) made the path worse. Let me explain: There was a 
time critical path. After some time, map a par found the solution for this 
path that met the timing. So I LOC its parts in the design and run map and 
par. I was surprised, that the path did not met the timing again. So 
LOCking of the critical path is surely not a right way.

This is my personal experience from the ISE10.1 and ISE11.2.

If you want to decrease time of the implementation run, you could look at 
the guided map or partitions.

Jan


On Thu, 5 Nov 2009, Steve Ravet wrote:

> Do any of you advanced users ever use the floorplanning tools to do
> placement?  I'm not talking about placing clock buffers or other individual
> items, I'm talking about ASIC style floorplanning for units and sub-units.
> I've asked AE's about that and the response is always to let the tool do
> placement.  So I'm asking experts:  Do you ever floorplan, and if so why?
> To speed up map?  To help with timing?  Thanks for any insight,
>
> --steve
>
>
>

Article: 143990
Subject: BRAM reconfiguration problem using OPB_HWICAP on Virtex 4
From: "ulegat" <uros.legat@ijs.si>
Date: Fri, 06 Nov 2009 02:45:51 -0600
Links: << >>  << T >>  << A >>
Hello!

I am trying to use partial reconfiguration to change the contents of BRAM
belonging to USER IP. I am able to read the BRAM FRAME, but not able to
write (details about frame contents below). 


XPS 10.1 (lin64) OPB_HWICAP 1.10a, FPGA Virtex 4(xc4vlx25)

 

Here is the example:

 

Buffer after  frame read:

 

XHwIcap_DeviceReadFrameV4(&hwicap,1,2,2,1,0);

 

Target BRAM content was initialized with all 1s. Which can be seen from
buffer words 93 to 102.

So the buffer is read ok!

 

NO| Buffer word contents

  

  0   30008001
  1   0000000d
  2   ffffffff
  3   ffffffff
  4   30008001
  5   00000007
  6   20000000
  7   20000000
  8   30008001
  9   00000004
 10   20000000
 11   20000000
 12   20000000
 13   30002001
 14   00508041
 15   28006053
 16   20000000
 17   20000000
 18   00000000
 19   00000000
  .

  .
  .

 72   49cf8943
 73   fa0eebe8
 74   c20eb84d
 75   63db694d
 76   0000991d
 77   4d938a80
 78   e6e4cf41
 79   df21db17
 80   55d627a6
 81   0070978d
 82   00000000
 83   49cf8943
 84   fa0eebe8
 85   c20eb84d
 86   63db694d
 87   0000991d
 88   4d938a80
 89   e6e4cf41
 90   df21db17
 91   55d627a6
 92   0070978d
 93   ffffffff
 94   ffffffff
 95   ffffffff
 96   ffffffff
 97   0000ffff
 98   ffffff80
 99   ffffffff
100   ffffffff
101   ffffffff
102   00ffffff
103   00000000

 

 

For example that I want to change one word of BRAM contents

I changed word 99 to of the frame buffer to 0f0f0f0f. 

 

Buffer after  frame write

XHwIcap_DeviceWriteFrameV4(&hwicap,1,2,2,1,0);

 

 

   0    30008001
   1    0000000d
   2    ffffffff
   3    ffffffff
   4    30000001
   5    0000defc
   6    20000000
   7    20000000
   8    30012001
   9    10042fdd
  10    30018001
  11    0167c093
  12    30002001
  13    00508041
  14    30008001
  15    00000001
  16    20000000
  17    30004052
  18    00000000
  19    00000000
  .

  .

  .
  72    49cf8943
  73    fa0eebe8
  74    c20eb84d
  75    63db694d
  76    0000991d
  77    4d938a80
  78    e6e4cf41
  79    df21db17
  80    55d627a6
  81    0070978d
  82    00000000
  83    49cf8943
  84    fa0eebe8
  85    c20eb84d
  86    63db694d
  87    0000991d
  88    4d938a80
  89    e6e4cf41
  90    df21db17
  91    55d627a6
  92    0070978d
  93    ffffffff
  94    ffffffff
  95    ffffffff
  96    ffffffff
  97    0000ffff
  98    ffffff80
  99    0f0f0f0f
 100    ffffffff
 101    ffffffff
 102    00ffffff
 103    00000000

 

 Now I want to check if the word 99 is realy reconfigured i read the same
frame again.

 

 

Buffer after  frame read:

 

XHwIcap_DeviceReadFrameV4(&hwicap,1,2,2,1,0);

 

   0      30008001
   1      0000000d
   2      ffffffff
   3      ffffffff
   4      30008001
   5      00000007
   6      20000000
   7      20000000
   8      30008001
   9      00000004
  10      20000000
  11      20000000
  12      20000000
  13      30002001
  14      00508041
  15      28006053
  16      20000000
  17      20000000
  18      00000000
   .

   .

   .
  72      49cf8943
  73      fa0eebe8
  74      c20eb84d
  75      63db694d
  76      0000991d
  77      4d938a80
  78      e6e4cf41
  79      df21db17
  80      55d627a6
  81      0070978d
  82      00000000
  83      49cf8943
  84      fa0eebe8
  85      c20eb84d
  86      63db694d
  87      0000991d
  88      4d938a80
  89      e6e4cf41
  90      df21db17
  91      55d627a6
  92      0070978d
  93      ffffffff
  94      ffffffff
  95      ffffffff
  96      ffffffff
  97      0000ffff
  98      ffffff80
  99      ffffffff
 100      ffffffff
 101      ffffffff
 102      00ffffff
 103      00000000

 

The word 99  was not configured!!!

 

 I tried to reconfigure LUT contents in the same way and succeeded. 

Maybe my bitgen options are incorect, or BRAM content is protected?

 

BITGEN:

 -b
-g ActiveReconfig:Yes
-g CclkPin:PULLUP
-g TdoPin:PULLNONE
-g M1Pin:PULLUP
-g DonePin:PULLUP
-g DriveDone:No
-g StartUpClk:JTAGCLK
-g DONE_cycle:4
-g GTS_cycle:5
-g M0Pin:PULLUP
-g M2Pin:PULLUP
-g ProgPin:PULLUP
-g TckPin:PULLUP
-g TdiPin:PULLUP
-g TmsPin:PULLUP
-g DonePipe:No
-g GWE_cycle:6
-g LCK_cycle:NoWait
-g Security:NONE
#-m
-g Persist:No

 

 

Hope to get some answers,

 

Legat
		   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 143991
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: "HT-Lab" <hans64@ht-lab.com>
Date: Fri, 6 Nov 2009 09:21:50 -0000
Links: << >>  << T >>  << A >>

"Mark McDougall" <markm@vl.com.au> wrote in message 
news:7JmdnUcpQOJNI27XnZ2dnUVZ_qadnZ2d@westnet.com.au...
> I've had it up to the eyeballs with Xilinx tools now. I'm seriously ready
> to go postal in the lobby of Xilinx HQ. I don't expect perfection but this
> really is beyond a joke.
>
> Can someone please put me out of my misery, and finally admit that you
> have _all_ been having me on for the past few years now! :O ...that it has
> all been an elaborate hoax instigated by someone I offended in a past
> life. ...that a team of engineers has been working for years to produce an
> IDE that crashes randomly, and steadfastly refuses to launch tools on
> Tuesday mornings and Friday afternoons? ...working for years on a
> synthesizer that removes random bits of logic, or sits spinning in an
> infinite loop on an entity that works in another project? ...that corrupts
> my project file bi-monthly.
>
> And worst of all - _you_ lot, telling me that Xilinx actually works, and
> that you _can_ use it for more than flashing LEDs on the Spartan starter
> kit. And I was gullible enough to believe you! :O :(
>
> I've seen the light. You _cannot_ convince me that it is possible to
> produce a commercial product in silicon using these tools. Period.
>
> Regards,
>
> -- 
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

Yep, using EDA software is like using a small leaking boot trying to cross a 
violent river. All EDA software has bugs and some of them are intelligent enough 
to strike when you stress level is at its maximum. Unfortunately this will never 
change since software is getting more complex, market pressure is increasing, 
engineers expectations are increasing, weather is getting worse, mentality to 
produce quality work is diminishing, more complex devices, more annoying TV 
commercials etc etc.

The only mild remedy against this whirlpool of misery is good technical support. 
Luckily I found that Xilinx has good support so logs those bugs, make sure they 
fix them, use gotomeeting/webex/etc to show what is happening if you can't send 
out any code. If they don't respond than splash out on 
newsgroups/facebook/linkin/blogs/twitter or whatever the communication flavour 
of the month is. I am sure that no EDA vendor can handle a constant stream of 
bad publicity.

As they say, life is a bitch and then you have to use EDA tools......

Hans
www.ht-lab.com 



Article: 143992
Subject: Re: CPLD + MCU SoC from Cypress, free samples too!
From: -jg <jim.granville@gmail.com>
Date: Fri, 6 Nov 2009 01:47:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 6:01=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> ok some explanations: I was talking PSoC 3, yes, and it
> HAS VERILOG programmable general purpose CPLD module!
> I have tested the software and it uses cypress warp compiler
> the missing "selection" guide is really PITA, I was trying to compare
> the PSoC 1 versions, and just did give up!

The PSoC3 has some nice looking features, and I see it has an errata,
so real silicon is edging closer....


> Ok, from my point, Cypress could drop ALL their products and just
> keep PSoC 3 :)

Not at the prices they are indicating at the moment!
You have to really need a good portion of all the resource,
to be able to justify the costs.

That's always been the achilles heel  of such 'System on Chip' pitches
-

-jg
.



Article: 143993
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: Oscar Almer <o.almer@gmail.com>
Date: Fri, 6 Nov 2009 13:01:19 +0000
Links: << >>  << T >>  << A >>
On Fri, 06 Nov 2009 17:14:21 +1100
Mark McDougall <markm@vl.com.au> wrote:

> I've had it up to the eyeballs with Xilinx tools now. I'm seriously
> ready to go postal in the lobby of Xilinx HQ. I don't expect
> perfection but this really is beyond a joke.
> 
> Can someone please put me out of my misery, and finally admit that you
> have _all_ been having me on for the past few years now! :O ...that
> it has all been an elaborate hoax instigated by someone I offended in
> a past life. ...that a team of engineers has been working for years
> to produce an IDE that crashes randomly, and steadfastly refuses to
> launch tools on Tuesday mornings and Friday afternoons? ...working
> for years on a synthesizer that removes random bits of logic, or sits
> spinning in an infinite loop on an entity that works in another
> project? ...that corrupts my project file bi-monthly.
> 
> And worst of all - _you_ lot, telling me that Xilinx actually works,
> and that you _can_ use it for more than flashing LEDs on the Spartan
> starter kit. And I was gullible enough to believe you! :O :(
> 
> I've seen the light. You _cannot_ convince me that it is possible to
> produce a commercial product in silicon using these tools. Period.
> 

I, at least, gave up on the ise wrapper about a year and a half ago -
it just didn't do it, anymore. Instead I drive the flow (xst, map, par,
etc) from a single makefile, and a short one at that - maybe 20 lines. 

The things I know im missing out on is 1. the pretty XML reports and 2.
COREgen etc hook-ins. The former I can survive without, as its
easier to grep through plain text reports anyway, and the latter I
typically only need to run once anyway, at which point I suffer ise
long enough to move the generated files somewhere sensible. 

Just my experience. 

//Oscar


Article: 143994
Subject: Re: Does anyone ever use placement?
From: Ben Jones <benjjuk@gmail.com>
Date: Fri, 6 Nov 2009 05:25:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 5, 7:56=A0pm, "Steve Ravet" <steve.ra...@arm.com> wrote:
> Do any of you advanced users ever use the floorplanning tools to do
> placement? =A0I'm not talking about placing clock buffers or other indivi=
dual
> items, I'm talking about ASIC style floorplanning for units and sub-units=
.
> I've asked AE's about that and the response is always to let the tool do
> placement. =A0So I'm asking experts: =A0Do you ever floorplan, and if so =
why?
> To speed up map? =A0To help with timing? =A0Thanks for any insight,
>
> --steve

I think floorplanning is undersupported in most current FPGA tools
(certainly in the Xilinx tools), but sometimes it's a necessity. In
fact, I'd say that anyone doing a non-trivial FPGA design (and is
there any other kind?) should at least be aware of the impact that
placement decisions will have on their design. And this goes double
for anyone using hard blocks such as DSPs and processors and EMACs and
so on. In the end, your design is not being turned into software, but
hardware - a real, physical thing that has a real physical layout. As
you point out, ASIC people fully realise that layout is important (and
hard). I fail to see why FPGA design is really that different.

To my mind there are two aspects to placement/floorplanning. One is
the "low-level tweaking" aspect, where you might have to fiddle around
making sure that a few critical elements are placed properly relative
to one another so that timing isn't compromised. Or you might be
trying to do a very dense design, with no wasted space, and use
placement constraints to force certain logic functions to share a
resource. This sort of placement is fiddly, time-consuming, error-
prone, and often needs to be re-done when a design undergoes changes -
and worse, you can easily make your design bigger and/or slower if
you're not 100% sure of what you're doing. This is the placement job
that you'd really hope the FPGA tools would do well, because it seems
ideally suited to automation based on the software's intimate
knowledge of the device architecture and design rules. It's similar to
the argument for high-level languages versus assembly language in the
software domain.

Most of the time, the tools do an OK job of the low-level mapping.
When they don't, it's often very hard to persuade them to do it
differently. This is often a source of great frustration if you're
trying to push the boundaries of what's possible in a device. I
personally think there are three occasions on which this sort of
dabbling-in-black-magic is warranted:

1) When designing a common component that will be re-used often within
a design, and within other designs. So the pain can be amortized over
many projects.

2) When the component in question is the "key" to the success of a
particular design. The commercial viability of your product might
hinge on the ability to do (say) a very fast pipelined 72-bit addition
operation. So the pain can be justified.

3) When you've finished your design and it doesn't meet timing because
the tools are misbehaving. In this case, the pain can be partially
mitigated by ranting about your problems on usenet. :-)

But there's a whole other kind of placement, too, which is device-
level floorplanning. That is, rather than being concerned about the
details of which LUT goes where, you're thinking about whether the DDR
controller should go on the left- or the right-hand side of the chip.
Taking into account the locations of other devices on your PCB, you
must decide which Ethernet MAC to use. Or which PowerPC, and then,
where to put all its peripherals. Or you have two filter blocks that
use DSP slices, and you want to ensure that they both take them from
the same column. Or you have two blocks with very complex internal
routing and you want to make sure the tools keep their areas
completely separate to improve runtime and avoid congestion.

This is the sort of problem that I think is very hard to solve
automatically. It's a bit like town planning. You wouldn't just say "I
need 10,000 houses, four schools, 50 shops and restaurants and a
hospital" and expect some piece of software to come up with an optimal
solution. You at least need to give it some constraints. Some idea of
the geography. Some idea of what ought to be near to what. Tools like
planahead are supposed to help with this sort of thing, but there are
plenty of other ways.

For example, I have seen a design go from <130MHz to >200MHz simply
from adding a few area-group constraints to guide the placement
algorithm into making sensible decisions. Usually you don't get much
run-time improvement out of the mapper - if anything, constraint
processing tends to slow the tools down - but that's usually re-couped
in the routing stage, because the problem the router has to solve is
far better defined when the functional sub-blocks are nicely separated
out, rather than tangled together in spahetti.

Depending on what you're trying to achieve with an FPGA, you might
never ever need to touch a placement constraint at all. But as devices
get bigger and bigger I think more and more users are going to hit the
limits of the tools, and will start to require an awareness of the
true physical nature of their designs in order to complete them
successfully. When that happens, I'm also hoping we'll see an
improvement in the actual mechanics of influencing placement decisions
- both low-level and high-level - within the various design suites.

Cheers,

        -Ben-

(It seems that, thanks to quantitative easing, my $0.02 is now trading
at around $0.22.)

Article: 143995
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: Curt Johnson <curt.johnson@dicombox.net>
Date: Fri, 06 Nov 2009 07:54:47 -0800
Links: << >>  << T >>  << A >>
Mark McDougall wrote:
> I've had it up to the eyeballs with Xilinx tools now. I'm seriously ready
> to go postal in the lobby of Xilinx HQ. I don't expect perfection but this
> really is beyond a joke.
> 
> <snip>
> 
> I've seen the light. You _cannot_ convince me that it is possible to
> produce a commercial product in silicon using these tools. Period.
> 
> Regards,
> 

If it is any solace, the Mentor schematic capture and PCB routing tools 
are much worse. In addition to continuous license issues, crashes, 
version compatibility problems, and file corruption, they produce 
unreliable output. I now have to manually check every trace on a 10 
layer PCB with multiple BGA packages ever since we discovered that the 
tools can randomly delete nets from a fully routed board without warning.

At lease ISE only causes frustration and project delays. I've never had 
to scrap thousands of USD worth of materials because of them.

Curt

Article: 143996
Subject: Re: Does anyone ever use placement?
From: rickman <gnuarm@gmail.com>
Date: Fri, 6 Nov 2009 08:21:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 1:41=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> rickman wrote:
> > I can't say any of this for certain since I have not needed to
> > floorplan for almost a decade and I am sure the tools are better. =A0I
> > believe at least Xilinx has some incremental compile feature which
> > should help to minimize the extent of changes due to a design change.
> > That would help, but it still remains a messy proposition.
>
> My biggest problem is that the Xilinx placer is horribly bad. It seems
> to place everything at random and then just hopes that it might be
> able to meet the timing and route the mess. Of course if you have
> time just run all the different seeds for the placement, one of them
> might be good enough guess ;) Manual placement of the memories usually
> helps a lot.
>
> My own feeling is that the Altera placer is better than the Xilinx
> altough it also has some problems with the different size memories
> (M144k vs M9k etc.).
>
> Fortunately there are physical synthesis tools for FPGAs from
> 3rd parties, they at least make reasonable placement for the FPGA
> tools to start their work.

I wasn't aware that any of the third party tools did *any* placement.
I thought they just produced a net list of the primitives and let the
Xilinx place and route tools do all of that.  Am I mistaken?

I don't disagree that the placer is nowhere near optimal.  But I have
done enough hand placement to realize that unless you have a very
regular design that you can clearly see the optimal placement, it can
be very hard to do a good job yourself.  Of course you can spot the
bad placements the tool does, but it is very often true that if you
optimize one thing, you will mess up something else.  Of course, the
point is that you optimize the parts that have trouble meeting timing
and allow the portions with lots of slack to get worse.  For the tool
to know which parts these are would require iterating through
placement *and* routing which I don't think they do.  Am I wrong about
that?  I guess that is where the multiple seeds come in.

Don't mention Altera to me.  Although their current tool might be a
lot better, I had to do a project using Max Plus II and it totally
sucked!  Not only was it not so good at the P&R thing, it would claim
a design was passing timing analysis when it would fail on the bench.
We spent tons of time trying to get that blivet* to work using cold
spray and a chip heater.

* A blivet is 10 pounds of $#!? in a 5 pound bag or in this case an
FPGA using 90% of the logic.

Rick

Article: 143997
Subject: Re: OK Xilinx users, it's time I was let in on the joke...
From: rickman <gnuarm@gmail.com>
Date: Fri, 6 Nov 2009 08:28:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 10:54=A0am, Curt Johnson <curt.john...@dicombox.net> wrote:
> Mark McDougall wrote:
> > I've had it up to the eyeballs with Xilinx tools now. I'm seriously rea=
dy
> > to go postal in the lobby of Xilinx HQ. I don't expect perfection but t=
his
> > really is beyond a joke.
>
> > <snip>
>
> > I've seen the light. You _cannot_ convince me that it is possible to
> > produce a commercial product in silicon using these tools. Period.
>
> > Regards,
>
> If it is any solace, the Mentor schematic capture and PCB routing tools
> are much worse. In addition to continuous license issues, crashes,
> version compatibility problems, and file corruption, they produce
> unreliable output. I now have to manually check every trace on a 10
> layer PCB with multiple BGA packages ever since we discovered that the
> tools can randomly delete nets from a fully routed board without warning.
>
> At lease ISE only causes frustration and project delays. I've never had
> to scrap thousands of USD worth of materials because of them.

The reason for using commercial tools is supposed to be the great
support and the lack of serious bugs...  so if you don't like your
expensive layout tools, why use them?  I used FreePCB on my last
project and found it very suitable.  I am sure there are some things
that you need to do manually that expensive tools might do
automatically, but hand checking all the nets is not one of them.

Not trying to be smart, this is a serious question.

Rick

Article: 143998
Subject: Re: CPLD + MCU SoC from Cypress, free samples too!
From: rickman <gnuarm@gmail.com>
Date: Fri, 6 Nov 2009 08:35:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 4:47=A0am, -jg <jim.granvi...@gmail.com> wrote:
> On Nov 6, 6:01=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
> > ok some explanations: I was talking PSoC 3, yes, and it
> > HAS VERILOG programmable general purpose CPLD module!
> > I have tested the software and it uses cypress warp compiler
> > the missing "selection" guide is really PITA, I was trying to compare
> > the PSoC 1 versions, and just did give up!
>
> The PSoC3 has some nice looking features, and I see it has an errata,
> so real silicon is edging closer....
>
> > Ok, from my point, Cypress could drop ALL their products and just
> > keep PSoC 3 :)
>
> Not at the prices they are indicating at the moment!
> You have to really need a good portion of all the resource,
> to be able to justify the costs.
>
> That's always been the achilles heel =A0of such 'System on Chip' pitches

Where did you find prices?

Rick

Article: 143999
Subject: Re: CPLD + MCU SoC from Cypress, free samples too!
From: rickman <gnuarm@gmail.com>
Date: Fri, 6 Nov 2009 08:39:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 6, 12:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Nov 6, 3:16=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Nov 5, 6:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > both free samples and 49$ starterkit available, my should be airborn
> > > right now somewhere between Paris and my place.
>
> > > The CPLD is small, 190MC, but it still much more then the 16MC
> > > availabel in ADI's ADuCs or ST's uPSD devices.
>
> > > PSoC 5, Cortex based devices will probably only be available next yea=
r
>
> > > Antti
>
> > You didn't say what product this is. =A0I assume it is the 8051 version
> > of the new PSOC? =A0Do they call that the PSOC 3?
>
> > I don't know what is going on with Cypress. =A0They have been saying th=
e
> > PSOC whatever will be out "next year" since 2006. =A0Fool me once, sham=
e
> > on you, fool me twice, shame on me! =A0I guess they may finally be
> > shipping PSOC 3. =A0I can't find a while paper on the PSOC 3/5
> > anywhere. =A0Is that because they don't have one or because it is hidde=
n
> > behind all the video and flash stuff on their site? =A0I guess it is
> > also too much to ask for a selection guide rather than having to read
> > through all the data sheets just to find out what combinations of
> > features they are offering. =A0Bah!
>
> > I see one version of the PSOC 5 has the high resolution ADC while
> > *all* of the PSOC 3 with the 8051 CPU have the high resolution ADC. =A0=
I
> > don't see where any of them have two channels or comparable DACs.
>
> > I'm actually guessing you aren't talking about the PSOC 3. =A0You
> > describe a 190 cell CPLD, but the PSOC digital blocks are not
> > generically programmable. =A0They have predefined function blocks and I
> > don't believe they offer detailed info on rolling your own function
> > blocks. =A0I guess this has changed from the PSOC 1 tools. =A0But it
> > appears you have to use their graphical tool rather than an HDL.
>
> > Jeeze! =A0They can't even make a table of contents that works. =A0It
> > points to some file called "001-55036-1.pdf". =A0I guess that's why it'=
s
> > preliminary...
>
> > Rick
>
> Rick, I agree on many accounts, something is badly wrong with Cypress,
> ok some explanations: I was talking PSoC 3, yes, and it
> HAS VERILOG programmable general purpose CPLD module!
> I have tested the software and it uses cypress warp compiler
> the missing "selection" guide is really PITA, I was trying to compare
> the PSoC 1 versions, and just did give up!
>
> Ok, from my point, Cypress could drop ALL their products and just
> keep PSoC 3 :)
>
> See actually initially it was like that, PSoC was done by separate
> company (owned by cypress), for some reason that was changed
> later and PSoC was taken back to mother company
>
> Antti

I thought they had a selection guide for the PSOC 1 series.  I used to
have one.  In general I have found Cypress to be very marketing driven
with engineering being the whipping boy.  The PSOC 3/5 thing started
when an eval board for one of the old PSOCs was shown to the CEO and
he saw a non-cypress part on it.  Being told it was there because
Cypress didn't do such a good job at analog, he said to make the new
chips with "no excuses".  Maybe they have done that, but as you say,
at a price.  The original PSOC series were cheap, but very, very
limited.  They really only shined when you could use the same function
blocks for multiple purposes and that really doesn't happen very
often.  Software lets you time multiplex the CPU, but the peripherals
are much harder to multiplex that way.

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