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 142025

Article: 142025
Subject: Re: How do you handle build variants in VHDL?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 22 Jul 2009 18:11:32 +0100
Links: << >>  << T >>  << A >>
On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote:

>On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote:
>> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote:
>> >Unfortunately, the generate statement only allows conditionally
>> >including concurrent statements.
>>
>> so does that mean that, for example, you couldn't use it to conditionally exclude particular case
>> branches in a case structure?
>>
>Generate statements would not be used to conditionally exclude
>particular case branches, they can only exclude concurrent statements
>or instantiation of entities.
>
>I don't see much utility you would get from excluding particular case
>branches at all.  The case conditions by definition must be
>- mutually exclusive
>- cover all cases
>
>Excluding a particular branch condition with an #ifdef would either
>violate the 'cover all cases' rule or force that particular branch to
>now follow the 'when others' default path.  I haven't run across a
>situation where I've ever wanted to code something like that.  In any
>case, you can still use the 'if...then' inside the case branch to
>branch around the code you would like to exclude.  It's roughly the
>same amount of typing so it shouldn't be any extra work one way or the
>other.

The situation that comes to mind is a state machine where some of the cases handle debug
functionality, or servicing peripheral devices which are not present in some variants
 Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle'
state.

>- Pin numbers on physical parts never have a need to 'move'.  
>A given
>board will have a given part which will have pins connected to
>specific other pins on that board.  There will not be any reason to
>vary these pin numbers for a given design while also maintaining the
>old pin numbers.

Yes they will - I have a prototype running on a devboard with a 484BGA with  tons of extra IOs for
debug outputs, and the production board will be the same device  in 144QFP.
It is also quite plausible that changes in production boards need pin allocations to change for
layout reasons, as the board is only 4 layer..

I would ideally like to have a single project and a simple way to flip it between 'devboard' and
'production board' mode, but it seems that this will be far from being as straightforward as it
would be for a similarly 'varianted' microcontroller project.
 

Article: 142026
Subject: Re: building a card reader into a virtex 2 or 5 based FPGA device.
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 22 Jul 2009 18:12:24 +0100
Links: << >>  << T >>  << A >>
On Wed, 22 Jul 2009 12:06:43 +0000 (UTC), Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
wrote:

>Martin Thompson <martin.j.thompson@trw.com> wrote:
>> jleslie48 <jon@jonathanleslie.com> writes:
>
>> > Sorry to start from scratch yet again, but I don't know where to
>> > begin.
>> >
>> > In the past I've had log file info dump out onto  a UART as
>> > necessary.  The UART is slow, and requires an additional device to
>> > capture the datastream.
>> >
>
>> How fast do you need? FTDIs UART-USB (TTL-232R-3V3) cable will go @
>> 3Mbps IIRC.  It's an extra cable, hardly a device though, unless you
>> count the PC as well?
>
>If you go with the FT245 or FT2232 in 245 mode, rate can even be higher, at
>the cost of more pins. Requirements on the PC side are the same.

And the FT2232H/4232H devices will go even faster...

Article: 142027
Subject: Xilinx ISE 11.x lossage
From: Andy Peters <google@latke.net>
Date: Wed, 22 Jul 2009 10:36:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
I installed the full-up Xilinx ISE 11.x tools on a spare machine so I
could give it a test-drive. (We have a site license.)

I checked out a fresh copy of the trunk of a working, shipping design
that was created with ISE 10.1.3. I used 10.1's rather-nifty "Source
Control | Export" feature to boil the binary ISE project file down to
a source-control-friendly tcl script, and as such the only parts of
the project that are in the repository are the VHDL sources, the UCF
and the three tcl scripts created by the Export. With 10.1, this is
sufficient to completely recreate the ISE project file in all of its
bloated glory.

Then I launched ISE 11. I clicked on the "Project | Source Control |
Import ..." menu item, hoping to import the project. Instead of
happiness, I got a dialog box saying that this feature was shitcanned,
and that I should import the project in the previous version to create
the .ISE project file, and then open that project file in 11.x. The
dialog also said something about using the shell to expand the project
file, but I couldn't figure out how to do this.

So, Xilinx: thanks a whole lot for taking one of the few actually
useful features of the Project Navigator and throwing it -- and your
customers who were foolish enough to rely on it -- under the bus.
There's really no reason for this feature to be removed, except that
you wanted to prove how much you hate your customers (as if moving to
FlexLM wasn't enough).

I opened a WebCase, which I suspect will be ignored like every other
WebCase.

-a

Article: 142028
Subject: Re: Strange FPGA behavior
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 22 Jul 2009 11:01:15 -0700
Links: << >>  << T >>  << A >>
maverick wrote:

> Thanks alot all for helping me out with your valuable ideas and
> experiences. Actually, I dont see a timing problem there.

Have you run static timing?
Synchronized all inputs?

> Had it been
> a timing problem, it should have given me the same problem on the
> first FPGA board which is identical.

The asynchronous delays are not identical from board to board
or from synthesis to synthesis.

      -- Mike Treseler

Article: 142029
Subject: Re: How do you handle build variants in VHDL?
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 22 Jul 2009 11:08:34 -0700
Links: << >>  << T >>  << A >>
Mike Harrison wrote:

> I would ideally like to have a single project and a simple way to flip it between 'devboard' and
> 'production board' mode, but it seems that this will be far from being as straightforward as it
> would be for a similarly 'varianted' microcontroller project.

Any way I flip it, some file must be edited.

      -- Mike Treseler

Article: 142030
Subject: gate capacity between old Virtex-II and newer Virtex-4
From: stevem <steve.martindell@gmail.com>
Date: Wed, 22 Jul 2009 12:32:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
I used a Virtex-II  XC2V1000 some time ago. The datasheet says the
capacity is ~1M system gates
with 5,120 slices.

Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has
10,752 slices but no longer
gives the equivalent "system gates" capacity.

Question: how do I compare  the capcity of XC4VLX25 to the XC2V1000 ?

               is the capacity of XC4VLX25  =2X the capacity of
XC2V1000,
               since there are 2X the number of slices?

               I don't need the DSP logic, just need to compare system
gates.

              Note, the developement board I want to buy comes with
the XC4VLX25,
              and I need to make sure this has at least the gate
capacity of the older XC2C1000

    -steve

Article: 142031
Subject: Re: Suzaku SZx30 or similar
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 22 Jul 2009 12:34:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
Larry

The Darnaw1 is an option particularly if you want more I/O. The only
thing on Darnaw1 the I/O does not have 5V protection like the
Craignell/Drigmorn family. Cost wise the Darnaw1 is also more
expensive. The PGA array does cost a reasonable amout in the
manufacture process. If you are going to the trouble of a carrier
board consider the Craignell2 if it has enough I/O for your needs.

The Ethernet Phy module is baed on a DP83848. There isn't much on the
website about this product and I will see if I can get that fixed.
Don't get confused by the Etheret Controller mdule whih is a different
product. The clock is expected to supplied by the host board/FPGA.
Incidentially on Craignell2 it does actually have a 25MHz oscillator
although some documentation suggests 40Mhz.

In reality the Darnaw1 regulators don't normally get very hot. Typical
designs will drop about 1.5W in the dual package. It's mainly a legal
statement but of course there are exceptions and they may get hot in
some circumstances e.g. fault or shorted.

Darnaw1 is 67.5mm x 67.5mm (2.66 inches x 2.66 inches). Note the PGA
is offset to one corner.

Incidentially the new product that's coming uses switching regulators
so heat will be less of a issue.

I'll be at DAC next week if you happen to be there. I'll be there with
the new product Merrick1 hopefully soothing it's 101 FPGAs into some
kind of action.

John Adair
Enterpoint Ltd.

On 22 July, 03:52, "AstroLad" <Astro...@cox.net> wrote:
> John,
>
> The size is probably manageable, but we don't need the extra features.
>
> How about this possibility: Darnaw 1 with the non-PCI Ethernet module. We
> have to make a carrier board for our circuitry anyway. So we put the Darnaw
> on one side, the Ethernet on the opposite side and our circuits wherever
> they will fit. That has the appeal of getting only what we need to keep the
> cost and power down.
>
> A few more questions if you don't mind. I could not find answers on your
> web site.
>
> 1. Size of the Darnaw. I estimate about 2.8" square from the picture.
> 2. Does the Ethernet module have a PHY or a MAC/PHY? What device?
> 3. Does the Ethernet module have an oscillator? I can't tell from the
> Xilinx documentation if the 1200E DLLs can internally handle 800MHz (25MHz
> = (32MHz * 25) / 32). I guess we could put a separate oscillator on our
> board if we have to.
> 4. The Darnaw manual says that the regulators get very hot. Will they
> survive being enclosed in a small volume, say 4"x3"x2", with no airflow?
>
> Thanks for your patience.
>
> Larry
>
>
>
>
>
> >Larry
>
> >The size of the board is about 67.5mm x 96.5mm. It is a lot bigger
> >than the related Craignell2 because it has expansion headers, usb,
> >display, accelerometer that make it bigger.
>
> >The board has our standard dil header arrangement that you can see on
> >several of our boards and we do have a phy module for these headers so
> >you can probably have the configuration you want asumig the size meets
> >the requirement.
>
> >John Adair
> >Enterpoint Ltd.
>
> >On 18 July, 14:25, "AstroLad" <Astro...@cox.net> wrote:
> >> John,
>
> >> Can you give me a few details? Will the new board be the same, or
> roughly
> >> the the same size as the Craignell2? What about Ethernet? We want a
> 10/100
> >> PHY (best), or MAC/PHY. The reason the PHY is best for us is that I
> already
> >> developed a simplified MAC tuned to our processor core. It doesn't
> take
> >> much space and not much support code.
>
> >> Thanks,
>
> >> Larry Dingle
>
> >> >We have a product coming shortly based on our Craignell2 but a
> >> >development board format that might offer an alternative. If you have
> >> >a few weeks then wait and see if suits your application.
>
> >> >John Adair
> >> >Enterpoint Ltd.
>
> >> >On Jul 6, 2:19=A0pm, "AstroLad" <Astro...@cox.net> wrote:
> >> >> Does anyone know of anything similar to the Suzaku SZ030/SZ130?
> It's
> >> just
> >> >> about a perfect fit for a short production run product I'm helping
> a
> >> frie=
> >> >nd
> >> >> with. Perfect that is except the price. What we need is an FPGA as
> good
> >> o=
> >> >r
> >> >> better than a XC3S1000, 1MB or more of RAM (SRAM or SDRAM) and
> 100MB
> >> >> Ethernet. It does not absolutely have to be a Spartan. An Altera
> >> Cyclone =
> >> >of
> >> >> some flavor would do if the price were right. We already have a lot
> of
> >> >> development done using Digilent Spartan boards. We don't need the
> >> >> Microblaze as we have a CPU from OpenCores that is adequate.- Hide
> quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -


Article: 142032
Subject: Re: gate capacity between old Virtex-II and newer Virtex-4
From: Nathan Bialke <nathan@bialke.com>
Date: Wed, 22 Jul 2009 13:14:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

The capacity of the device is entirely dependent on your design, not
"system gates." Take your design and synthesize it on a XC4VLX25 to
see if it will fit. I would be very surprised if it doesn't, but
that's the way you can tell. "System gates" are an entirely marketing
phenomenon, not an engineering metric.

- Nathan

On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote:
> I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the
> capacity is ~1M system gates
> with 5,120 slices.
>
> Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has
> 10,752 slices but no longer
> gives the equivalent "system gates" capacity.
>
> Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the c=
apacity of
> XC2V1000,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to c=
ompare system
> gates.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy co=
mes with
> the XC4VLX25,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least the=
 gate
> capacity of the older XC2C1000
>
> =A0 =A0 -steve


Article: 142033
Subject: Re: How do you handle build variants in VHDL?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 22 Jul 2009 13:16:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 22, 1:11 pm, Mike Harrison <m...@whitewing.co.uk> wrote:
> On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> wrote:
> >On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote:
> >> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote:

> >I don't see much utility you would get from excluding particular case
> >branches at all.  The case conditions by definition must be
> >- mutually exclusive
> >- cover all cases
>
> >Excluding a particular branch condition with an #ifdef would either
> >violate the 'cover all cases' rule or force that particular branch to
> >now follow the 'when others' default path.  I haven't run across a
> >situation where I've ever wanted to code something like that.  In any
> >case, you can still use the 'if...then' inside the case branch to
> >branch around the code you would like to exclude.  It's roughly the
> >same amount of typing so it shouldn't be any extra work one way or the
> >other.
>
> The situation that comes to mind is a state machine where some of the cases handle debug
> functionality,

OK, so what is inherently better about this...

case xyz is
  when Blah =>
    #ifdef DEBUG
      -- Put your debug code here
    #end if
   ...etc...
end case;

Compared to this...
case xyz is
  when Blah =>
    if DEBUG
      -- Put your debug code here
    end if;
   ...etc...
end case;

where 'DEBUG' is some boolean.

If instead you mean being able to put the #ifdef outside the branch
like this...
case xyz is
  #ifdef DEBUG
  when Blah =>
      -- Put your debug code here
    #end if
   ...etc...
end case;

Then, OK the #ifdef lets you make this edit quicker.  But that means
either that you also have to edit the type definition to remove the
'Blah' state or leave it in and let the 'when others' pick it up and
hope that this state bit synthesizes away so it doesn't cost you.  The
other way to code this would be...

if (DEBUG and (xyz = Blah) then
  -- Put debug code here
else
  case xyz is
  ...
  end case;
end if;

I don't see any inherent advantage in the situation you alluded to
where #ifdef-ing the entire 'when xxx' statement versus using other
coding styles...but you and others might disagree...that's fine.

> or servicing peripheral devices which are not present in some variants
>  Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle'
> state.
>
If the peripherals are not there in some variants, then simply not
connecting any of the output signals from the entity that produces the
unneeded signals to any of the top level entity outputs is
sufficient.  The synthesis tool will not produce any logic to
implement anything that doesn't affect an output pin.

> >- Pin numbers on physical parts never have a need to 'move'.
> >A given
> >board will have a given part which will have pins connected to
> >specific other pins on that board.  There will not be any reason to
> >vary these pin numbers for a given design while also maintaining the
> >old pin numbers.
>
> Yes they will - I have a prototype running on a devboard with a 484BGA with  tons of extra IOs for
> debug outputs, and the production board will be the same device  in 144QFP.
> It is also quite plausible that changes in production boards need pin allocations to change for
> layout reasons, as the board is only 4 layer..
>

That would be an example of two different boards with two different
parts...as I mentioned previously either of these two conditions is
not an example of ever having to 'move' a signal, it is an example of
two different designs.

Your situation is describing two different boards that use two
different parts that are intended to implement (I'm guessing) the
exact same function (i.e. the same VHDL logic description).  Taking
that as the premise, you've got two unique designs that you need to
maintain.  The differences between those two design being all related
to physical part differences and not (or possibly not) any logic
differences.  The synthesis process consists of running a tool that
pulls together the following types of information in order to
complete:
- Target device
- Device migration constraints
- Logic description (i.e. the VHDL)
- Pinout constraints
- Timing constraints
- I/O Drive constraints
- Voltage standard constraints

The logic description is the only thing that should be entered into
the VHDL files.  All of the other constraints are inherently device
specific and therefore needed by the synthesis tool (i.e ISPLever),
none of them belong in the VHDL files.  They belong in whatever files
the synthesis tool stores them in.

The fact that you have two different end targets simply means that you
have two different project files.

> I would ideally like to have a single project and a simple way to flip it between 'devboard' and
> 'production board' mode, but it seems that this will be far from being as straightforward as it
> would be for a similarly 'varianted' microcontroller project.- Hide quoted text -
>

If the differences are only in the logic, then this can be handled
pretty simply with a single project file.  Synthesis tools allow you
to set top level generics so to 'switch' between debug and release you
would write your code to work with a generic called 'DEBUG' and then
use the synthesis tool to set it however you want it today.  When you
get outside of logic and into the other constraints that I mentioned
previously, what you really need then is something different from the
synthesis tool, not the VHDL language.

I kind of get the impression though that you'd like to treat all of
these variants as if they were somehow really 'the same' in some
sense.  But in reality, each environment that a design is in (i.e. the
devboard or the production board) will have their own quirks and
require their own individual debug efforts and you'll likely find the
designs will need to be archived properly so having separate project
files and treating them like separate designs (which they really are)
is a long term better approach.

Bottom line is, it's just as easy to open a project file from 'File-
>Open...' as it is to otherwise change some setting from 'Debug' to
'Release'.

Kevin Jennings

Article: 142034
Subject: Re: gate capacity between old Virtex-II and newer Virtex-4
From: gabor <gabor@alacron.com>
Date: Wed, 22 Jul 2009 13:23:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 22, 4:14=A0pm, Nathan Bialke <nat...@bialke.com> wrote:
> Hello,
>
> The capacity of the device is entirely dependent on your design, not
> "system gates." Take your design and synthesize it on a XC4VLX25 to
> see if it will fit. I would be very surprised if it doesn't, but
> that's the way you can tell. "System gates" are an entirely marketing
> phenomenon, not an engineering metric.
>
> - Nathan
>
> On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote:
>
> > I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the
> > capacity is ~1M system gates
> > with 5,120 slices.
>
> > Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has
> > 10,752 slices but no longer
> > gives the equivalent "system gates" capacity.
>
> > Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ?
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the=
 capacity of
> > XC2V1000,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices?
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to=
 compare system
> > gates.
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy =
comes with
> > the XC4VLX25,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least t=
he gate
> > capacity of the older XC2C1000
>
> > =A0 =A0 -steve
>
>

Going from Virtex 2 to Virtex 4, the LUT sizes and LUT to Flip-flop
ratio remains the same.  So probably easiest to count the flip-flops
on the two chips for a rough estimate.  However if your design is
memory (block RAM) or I/O limited you'll need to probe deeper into
the architectural differences.  Also V4 is sufficiently faster that
you may be able to save logic resources by using higher clock
rates and narrower data paths, or more logic levels between
pipeline stages.  As noted, this is a rough estimate YMMV.
Best bet as Nathan pointed out is to port your code and look
at the results.  DON'T look at the "logic elements" column
in the V4 datasheet, this is an inflated number.  Count the flops!

regards,
Gabor

Article: 142035
Subject: Re: gate capacity between old Virtex-II and newer Virtex-4
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 22 Jul 2009 13:24:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote:
> I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the
> capacity is ~1M system gates
> with 5,120 slices.
>
> Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has
> 10,752 slices but no longer
> gives the equivalent "system gates" capacity.
>
> Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the c=
apacity of
> XC2V1000,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to c=
ompare system
> gates.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy co=
mes with
> the XC4VLX25,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least the=
 gate
> capacity of the older XC2C1000
>
> =A0 =A0 -steve

The part number gives you a rough indication of the relative amount of
available logic.
Within one family, this indication is fairly accurate.
Even between Virtex families it may be good enough for a first
evaluation, if you understand that Xilinx dropped two zeros when
moving from Virtex 2 to the newer families Virtex-4, -5, and -6.
That means your XC4VLX25 is roughly equivalent to a XC2C2500.
(When numbers got too large, the French and also the Finns at one time
dropped two zeros from their currency, "vive le nouveau franc")
Peter Alfke

Article: 142036
Subject: Re: How do you handle build variants in VHDL?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 22 Jul 2009 22:45:09 +0100
Links: << >>  << T >>  << A >>
On Wed, 22 Jul 2009 13:16:17 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote:

>On Jul 22, 1:11 pm, Mike Harrison <m...@whitewing.co.uk> wrote:
>> On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> wrote:
>> >On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote:
>> >> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote:
>
>> >I don't see much utility you would get from excluding particular case
>> >branches at all.  The case conditions by definition must be
>> >- mutually exclusive
>> >- cover all cases
>>
>> >Excluding a particular branch condition with an #ifdef would either
>> >violate the 'cover all cases' rule or force that particular branch to
>> >now follow the 'when others' default path.  I haven't run across a
>> >situation where I've ever wanted to code something like that.  In any
>> >case, you can still use the 'if...then' inside the case branch to
>> >branch around the code you would like to exclude.  It's roughly the
>> >same amount of typing so it shouldn't be any extra work one way or the
>> >other.
>>
>> The situation that comes to mind is a state machine where some of the cases handle debug
>> functionality,
>
>OK, so what is inherently better about this...
>
>case xyz is
>  when Blah =>
>    #ifdef DEBUG
>      -- Put your debug code here
>    #end if
>   ...etc...
>end case;
>
>Compared to this...
>case xyz is
>  when Blah =>
>    if DEBUG
>      -- Put your debug code here
>    end if;
>   ...etc...
>end case;
>
>where 'DEBUG' is some boolean.

Assuming this will accept a constant for the boolean, so no logic is generated when it is false, and
the synthesiser doesn't complain too hard that you are including code that synthesises to nothing,
it's close, except in that that the non-used case doesn't take the 'others' branch so there is some
possibility it could get into a state it wouldn't get out of - of course the above could be
augmented to prevent this, so  I'd agree it's pretty much equivalent in practice.
However  if used in the neighbourhood of a complex nested bunch of  If-Then's it would be a little
less clear than a preprocessor style thing which is more immediately obvious as being a compile-time
choice.

>If instead you mean being able to put the #ifdef outside the branch
>like this...
>case xyz is
>  #ifdef DEBUG
>  when Blah =>
>      -- Put your debug code here
>    #end if
>   ...etc...
>end case;

That's more what I was thinking 

>Then, OK the #ifdef lets you make this edit quicker.  But that means
>either that you also have to edit the type definition to remove the
>'Blah' state or leave it in and let the 'when others' pick it up and
>hope that this state bit synthesizes away so it doesn't cost you.  The
>other way to code this would be...

A few extra unused states probably wouldn't be a big deal compared to the logic generated to deal
with them. 

>if (DEBUG and (xyz = Blah) then
>  -- Put debug code here
>else
>  case xyz is
>  ...
>  end case;
>end if;
>
>I don't see any inherent advantage in the situation you alluded to
>where #ifdef-ing the entire 'when xxx' statement versus using other
>coding styles...but you and others might disagree...that's fine.

The point was really  that one construct - #ifdef etc. - could be used for pretty much all aspects
that may be variable - state-machine behaviour, signal sizes, clock dividers, outputting debug data,
pin assignments whatever. This seems a more logical way to do it, as the 'C' guys seem to have
figured out a long tome ago....
I think the problem is that VHDL dates back before FPGAS, and ASICs don't tend to have many
variants...

>> or servicing peripheral devices which are not present in some variants
>>  Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle'
>> state.
>>
>If the peripherals are not there in some variants, then simply not
>connecting any of the output signals from the entity that produces the
>unneeded signals to any of the top level entity outputs is
>sufficient.  The synthesis tool will not produce any logic to
>implement anything that doesn't affect an output pin.

there may be input-only peripherals, and you may want to make sure no logic is generated as that
variant may have alternative functionality that needs the space.  The particular design I'm
considering is going to end up in the smallest EC1 device and so this may be an issue.

>> >- Pin numbers on physical parts never have a need to 'move'.
>> >A given
>> >board will have a given part which will have pins connected to
>> >specific other pins on that board.  There will not be any reason to
>> >vary these pin numbers for a given design while also maintaining the
>> >old pin numbers.
>>
>> Yes they will - I have a prototype running on a devboard with a 484BGA with  tons of extra IOs for
>> debug outputs, and the production board will be the same device  in 144QFP.
>> It is also quite plausible that changes in production boards need pin allocations to change for
>> layout reasons, as the board is only 4 layer..
>>
>
>That would be an example of two different boards with two different
>parts...as I mentioned previously either of these two conditions is
>not an example of ever having to 'move' a signal, it is an example of
>two different designs.

Two different designs that share the same subset of functionality, which should also share the same
source files, to minimise the effort switching between them/.

>Your situation is describing two different boards that use two
>different parts that are intended to implement (I'm guessing) the
>exact same function (i.e. the same VHDL logic description).  Taking
>that as the premise, you've got two unique designs that you need to
>maintain.  
>The differences between those two design being all related
>to physical part differences and not (or possibly not) any logic
>differences.  The synthesis process consists of running a tool that
>pulls together the following types of information in order to
>complete:
>- Target device
>- Device migration constraints
>- Logic description (i.e. the VHDL)
>- Pinout constraints
>- Timing constraints
>- I/O Drive constraints
>- Voltage standard constraints

>
>The logic description is the only thing that should be entered into
>the VHDL files.  All of the other constraints are inherently device
>specific and therefore needed by the synthesis tool (i.e ISPLever),
>none of them belong in the VHDL files.  They belong in whatever files
>the synthesis tool stores them in.

Wherever they belong, the ability to easily switch versions would make things a whole lot easier. 

>The fact that you have two different end targets simply means that you
>have two different project files.
>
>> I would ideally like to have a single project and a simple way to flip it between 'devboard' and
>> 'production board' mode, but it seems that this will be far from being as straightforward as it
>> would be for a similarly 'varianted' microcontroller project.- Hide quoted text -
>>
>
>If the differences are only in the logic, then this can be handled
>pretty simply with a single project file.  Synthesis tools allow you
>to set top level generics so to 'switch' between debug and release you
>would write your code to work with a generic called 'DEBUG' and then
>use the synthesis tool to set it however you want it today.  When you
>get outside of logic and into the other constraints that I mentioned
>previously, what you really need then is something different from the
>synthesis tool, not the VHDL language.
>
>I kind of get the impression though that you'd like to treat all of
>these variants as if they were somehow really 'the same' in some
>sense.  But in reality, each environment that a design is in (i.e. the
>devboard or the production board) will have their own quirks and
>require their own individual debug efforts and you'll likely find the
>designs will need to be archived properly so having separate project
>files and treating them like separate designs (which they really are)
>is a long term better approach.
>
>Bottom line is, it's just as easy to open a project file from 'File-
>>Open...' as it is to otherwise change some setting from 'Debug' to
>'Release'.
>
>Kevin Jennings

I will need to look further into what can be done with the project system - I'm fairly new to this,
need to get something working in a hurry but am conscious that there will be variants in the future.
The IDE and number of files created by my (currently) two source files (VHDL and prefs) is somewhat
bewildering - hopefully when I've got this prototype running I'll have time to sit down with all the
documentation....

It just seems to me from a 'common sense' viewpoint that although the processes of compiling a C
program and syntesising for an FPGA are very different, the requirements for managing variants are
almost identical, so a means of doing it in the same way would seem to be a sensible way to do it.  
A preprocessor which preprocessed all source files in a project, be they VHDL, pin mappings, timing
constraints, memory contents in a uniform fashion just seems to be an obvious way to do it...

Of course I realise that all FPGA tools have a great deal of 'history' dating way before FPGAs, and
everything is now probaly just too ingrained and hard to change to suit the current state of the
art. Sort of like QWERTY keyboards....
 

Article: 142037
Subject: Laser marking / custom graphics on blank FPGA?
From: dowlers <eoindowling@gmail.com>
Date: Wed, 22 Jul 2009 14:59:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

Bit off topic...

Anyone know of a company in the UK that can do laser marking or
printing custom text on an FPGA.

Thanks for your
Best regards,

Eoin


Article: 142038
Subject: Re: Is it possible to encrypt an existing bit file with BitGen?
From: austin <austin@xilinx.com>
Date: Wed, 22 Jul 2009 15:02:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
No,

Bitgen has no option to encrypt (despite the misleading comment in the
user's guide).

All that is required is the binary file itself, none of the
implementation files are required.

The header is unencrypted, and the trailer is unencrypted:  it is only
the bits in the middle which get encrypted by the AES256 algorithm,
which is public.

For those who do not trust us to encrypt the file, they are free to
write their own c program to encrypt the file for them.

When they compare what we do, and what they do, they find we are not
hiding anything.

Good security uses public, approved, verifiable methods:  nothing is
secret or hidden (except your key!).

Bad security is instantly recognizable by comments like "proprietary
algorithm" or "hidden technique."

Relying on obscurity is often a very bad idea:  once discovered, and
revealed, ALL systems become targets!

Austin


Article: 142039
Subject: Re: How do you handle build variants in VHDL?
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 22 Jul 2009 16:14:46 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

> You should also look up GENERATE.  That is how to do actual code
> "defines".  GENERICS only get you parameters.


I found a dusty example in the stacks:
________________________________________________
architecture synth of e3dsu is
-- constant disabled_for_test : boolean := true;
   constant disabled_for_test : boolean := false;
begin
   verify : if disabled_for_test generate
      rx_clk_dis_cooked <= rx_clk_dis_raw;
      bitstream_o       <= bitstream_i;
   end generate verify;

   normal : if not disabled_for_test generate
      overhead : process (rx_clk, reset) is
       -- pipelined cooking logic ...
________________________________________________

I find that leaving in live, but unused
or obsolescent code like this
is sometimes more informative
to my future self, than is tiding up.

It covers some of the whyDidHe, whyDidntHe questions,
and can simplify maintenance.

          -- Mike Treseler

Article: 142040
Subject: Re: How do you handle build variants in VHDL?
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 23 Jul 2009 10:41:00 +1000
Links: << >>  << T >>  << A >>
Mike Harrison wrote:

> Of course I realise that all FPGA tools have a great deal of 'history'
> dating way before FPGAs, and everything is now probaly just too
> ingrained and hard to change to suit the current state of the art. Sort
> of like QWERTY keyboards....

I suspect that you've really hit the nail on the head with this statement
right here. I also suspect you have a software background (as I do), or at
least spend a significant amount of time writing software.

Pre-processors (together with project build tools) are very powerful
tools, as many multi-platform software projects can attest to. Of course,
software has a much longer history of concepts such as cross-platform
development, re-use (at the macro level) and layers of abstraction and
(more recently) emulation/virtualisation.

IMHO the hardware/firmware world (and their tools) have a bit of catching
up to do in this area - not through any fault of the practitioners but
rather due the very nature of the work and the technologies involved. As
we see the line increasingly blur between hardware and software, I'd hope
that cross-pollination benefits both areas of engineering.

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: 142041
Subject: Re: How do you handle build variants in VHDL?
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 23 Jul 2009 10:43:22 +1000
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> I find that leaving in live, but unused
> or obsolescent code like this
> is sometimes more informative
> to my future self, than is tiding up.

So I'm not the only one!!! Good to know! ;)

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: 142042
Subject: Re: How do you handle build variants in VHDL?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 22 Jul 2009 18:19:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 22, 5:45 pm, Mike Harrison <m...@whitewing.co.uk> wrote:
<snip>

> >Then, OK the #ifdef lets you make this edit quicker.  But that means
> >either that you also have to edit the type definition to remove the
> >'Blah' state or leave it in and let the 'when others' pick it up and
> >hope that this state bit synthesizes away so it doesn't cost you.  The
> >other way to code this would be...
>
> A few extra unused states probably wouldn't be a big deal compared to the logic generated to deal
> with them.
>

I disagree that extra states are not a big deal, but not because of
logic resource concerns but due to debug methodology.  Typical
hardware design flows rely (or should rely) on simulation for logic
validation.  You setup a testbench (more VHDL that stimulates all the
inputs and check the outputs) and run a test case (or cases) that
exercises the logic that is under test.  When something is 'not
right', you enter debug mode but that effort typically would not
involve writing or changing code in the thing you're testing (i.e.
adding the 'debug' state in your example).  Instead it mostly involves
eyeballing the time history of signals leading up to the bad thing,
all of this information is available in the simulator [1].  Once you
find the root cause, you change and re-run the sim.

Adding the extra state functionally changes the behaviour of the
design, it delays things by a clock cycle or two, it changes the thing
you're trying to debug.  At worst, this change 'fixes' the problem
that you were trying to find...but you don't know why it 'fixed' it
At best it is not much more than a waste of time because the entire
history of every signal is already available at your disposal, there
really is nothing more needed to debug any functional problem.  The
software methodolgy of adding extra tracing/debug code to home in on
the root cause of the problem is not really the right mindset here.
In simulation you have access to the entire history of every signal.
Software debug typically does not have this entire history at your
fingertips.

There is also debug on real hardware, but the methodology here is to
use logic analyzer resources to get a clue as to what signal(s) seem
to be at the root cause of the problem without functionally changing
the design at all (i.e. you're passively viewing internal design
signals).  There's more to it than that, but again if you put
functional changes in (like your state machine example) in order to
debug a problem...you're probably not debugging in a very effective
manner...and you'll be slogging it for a long time.

[1] Some people prefer to restart and then step through code, I
typically don't, it's a preference thing.

> >I don't see any inherent advantage in the situation you alluded to
> >where #ifdef-ing the entire 'when xxx' statement versus using other
> >coding styles...but you and others might disagree...that's fine.
>
> The point was really  that one construct - #ifdef etc. - could be used for pretty much all aspects
> that may be variable - state-machine behaviour, signal sizes, clock dividers, outputting debug data,
> pin assignments whatever.

Well signal sizes and clock dividers are very easily changable via a
'debug' parameter or any other parameter so those don't really fly
[2], [3].  Changing functional behaviour and outputting debug data are
things that you should eventually come to realize are not needed as I
noted above.  Right now you may not be at that realization point.  You
could 'improve' the language by adding #ifdef, but in the end you'll
likely find that it's not nearly as useful as you once thought.

There probably are some good use cases for #ifdef being more effective
than what is in the language today...I just don't think you've
described one where there isn't a more effective mechanism already
available without it.

[2]
Signal size example:
signal xyz: std_logic_vector(sel(debug, 15, 7) downto 0);
where 'sel' is a function you can write that is basically equivalent
to something like the following in C
x <= debug ? 15, 7;

[3]
signal Timer_Counter: natural range 0 to MAX_TIME / CLOCK_PERIOD;
where 'MAX_TIME' is a parameter that defines whatever you want the
timer to count up to; CLOCK_PERIOD would be the period of the input
clock...both are simply parameters that get passed into and control
the entity.  You could also use the above mentioned 'sel' function to
select between two upper ranges as well.

> This seems a more logical way to do it, as the 'C' guys seem to have
> figured out a long tome ago....

C guys also brought us buffer overruns.

> I think the problem is that VHDL dates back before FPGAS, and ASICs don't tend to have many
> variants...
>

Maybe...but VHDL is derived from Ada which is a software language.
Ada probably has roots that go back to something earlier too, but the
point is that VHDL was birthed from a software language not a hardware
one.

> >> or servicing peripheral devices which are not present in some variants
> >>  Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle'
> >> state.
>
> >If the peripherals are not there in some variants, then simply not
> >connecting any of the output signals from the entity that produces the
> >unneeded signals to any of the top level entity outputs is
> >sufficient.  The synthesis tool will not produce any logic to
> >implement anything that doesn't affect an output pin.
>
> there may be input-only peripherals, and you may want to make sure no logic is generated as that
> variant may have alternative functionality that needs the space.

Not sure what you mean by an 'input-only' peripheral, but the bottom
line is that entity outputs that do not affect any output pins will
get optimized away...take your existing design and connect the clock
input to some entity to '0' or leave it unconnected and run ISPLever
and watch that entire entity disappear.

> The particular design I'm
> considering is going to end up in the smallest EC1 device and so this may be an issue.
>

If paranoid surrounding an entity within a generate statement will do
the trick.

>
>
> >> Yes they will - I have a prototype running on a devboard with a 484BGA with  tons of extra IOs for
> >> debug outputs, and the production board will be the same device  in 144QFP.
> >> It is also quite plausible that changes in production boards need pin allocations to change for
> >> layout reasons, as the board is only 4 layer..
>
> >That would be an example of two different boards with two different
> >parts...as I mentioned previously either of these two conditions is
> >not an example of ever having to 'move' a signal, it is an example of
> >two different designs.
>
> Two different designs that share the same subset of functionality, which should also share the same
> source files, to minimise the effort switching between them/.
>

It's pretty darn easy to switch to (or open in parallel) multiple
projects via 'File->Open'...'specially if they're in the MRU list.
How is that more difficult than changing some other build setting?

Once you've done so (change some build setting), how do you keep track
of how a given file was built?  You can't exactly peruse the binary
output file to check to see how that setting was set.  Now you've
created a configuration management issue, the only way to know how a
particular xyz.bin file was built is to rebuild it.  It's that type of
thing that then evolves into the design suddenly having some magic
read only port that returns some information so you'd know how
something was set during the build.  Yes you can do that...or you can
simply have better configuration management, build procedures and
source file control/archiving...that's how you handle it properly.
Using the GUI to change settings should only be a more convenient
mechanism then directly editing the project file with a text editor.
But the end result of that changed file should be under source control
management.

<snip>
> Wherever they belong, the ability to easily switch versions would make things a whole lot easier.

See above

>
> >Kevin Jennings
>
> I will need to look further into what can be done with the project system - I'm fairly new to this,
> need to get something working in a hurry but am conscious that there will be variants in the future.
> The IDE and number of files created by my (currently) two source files (VHDL and prefs) is somewhat
> bewildering - hopefully when I've got this prototype running I'll have time to sit down with all the
> documentation....
>

Sounds good...just keep in mind that VHDL is used to describe logic.
If you're considering entering 'non-logic' things into those
particular source files, you're probably not going about it quite
right.

> It just seems to me from a 'common sense' viewpoint that although the processes of compiling a C
> program and syntesising for an FPGA are very different, the requirements for managing variants are
> almost identical, so a means of doing it in the same way would seem to be a sensible way to do it.
> A preprocessor which preprocessed all source files in a project, be they VHDL, pin mappings, timing
> constraints, memory contents in a uniform fashion just seems to be an obvious way to do it...
>

OK, but even in the C software world you want to have source file
control, config management practices in place.  All of what I
mentioned above would still apply.

Hope I've given you some things to ponder, good luck on your design.

Kevin Jennings

Article: 142043
Subject: Re: How do you handle build variants in VHDL?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 22 Jul 2009 18:29:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 22, 8:43=A0pm, Mark McDougall <ma...@vl.com.au> wrote:
> Mike Treseler wrote:
> > I find that leaving in live, but unused
> > or obsolescent code like this
> > is sometimes more informative
> > to my future self, than is tiding up.
>
> So I'm not the only one!!! Good to know! ;)
>

No you're not alone, at least three of us now...but then you also said
earlier that you leave in some "obsolete/experimental/irrelevant code
without it passing elaboration"...that's a bit different.  You're not
alone there either, but if I keep something like that around it's
commented out.  I'd much rather it be live code that really does
elaborate and sim.

Kevin Jennings

Article: 142044
Subject: Re: Laser marking / custom graphics on blank FPGA?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 22 Jul 2009 19:36:05 -0700
Links: << >>  << T >>  << A >>
On Wed, 22 Jul 2009 14:59:17 -0700 (PDT), dowlers
<eoindowling@gmail.com> wrote:

>Hi all,
>
>Bit off topic...
>
>Anyone know of a company in the UK that can do laser marking or
>printing custom text on an FPGA.
>
>Thanks for your
>Best regards,
>
>Eoin

Do you want to hide the fact that it's an FPGA? We epoxy pin-fin
heatsinks on top.

ftp://jjlarkin.lmi.net/DSC01786.JPG

John


Article: 142045
Subject: DONE pin does'nt go high in SPARTAN - 3AN
From: saras <saras_rajgiri@yahoo.co.in>
Date: Wed, 22 Jul 2009 23:31:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA ,
it erases , programs and verifiys successfully but at the end, I get
PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go
high..
But if I erase the on -board DSP and then program FPGA, I get
PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is
supposed to be genearated by FPGA..Why DSP has to be erased? All the
required signals for programming like INIT_B , PROG is generated by
another on -board  microcontroller. Please provide some suggestions.

Article: 142046
Subject: Re: DONE pin does'nt go high in SPARTAN - 3AN
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 23 Jul 2009 00:02:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 23, 9:31=A0am, saras <saras_rajg...@yahoo.co.in> wrote:
> hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA ,
> it erases , programs and verifiys successfully but at the end, I get
> PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go
> high..
> But if I erase the on -board DSP and then program FPGA, I get
> PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is
> supposed to be genearated by FPGA..Why DSP has to be erased? All the
> required signals for programming like INIT_B , PROG is generated by
> another on -board =A0microcontroller. Please provide some suggestions.

erasable DSP?

what are you talking about ;)?

what are you programming? the onchip SPI flash?
or loading config via slave serial using onboard MCU?
what is the DSP doing??

a real mystery (to anyone except you)

Antti







Article: 142047
Subject: Re: DONE pin does'nt go high in SPARTAN - 3AN
From: sheri <saras_rajgiri@yahoo.co.in>
Date: Thu, 23 Jul 2009 00:55:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 23, 12:02=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Jul 23, 9:31=A0am, saras <saras_rajg...@yahoo.co.in> wrote:
>
> > hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA ,
> > it erases , programs and verifiys successfully but at the end, I get
> > PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go
> > high..
> > But if I erase the on -board DSP and then program FPGA, I get
> > PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is
> > supposed to be genearated by FPGA..Why DSP has to be erased? All the
> > required signals for programming like INIT_B , PROG is generated by
> > another on -board =A0microcontroller. Please provide some suggestions.
>
> erasable DSP?
>
> what are you talking about ;)?

>>>>>>> >> It is flash based DSP chip, which can be erased using the DSP Jt=
ag debugger.

> what are you programming? the onchip SPI flash?
> or loading config via slave serial using onboard MCU?

>>> >>I'm flashing the onchip SPI flash for now, but will be done by MCU in=
 future.For now it is in dvevelopment stage and I'm using Xilix Jtag cable =
to program the onchip SPI flash.

> what is the DSP doing??

> >>> I donno much about its functinality but I'm using its clock...

> a real mystery (to anyone except you)
>
> Antti


Article: 142048
Subject: Re: Why do both Xilinx and Altera DPS use 18*18?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 23 Jul 2009 08:56:02 +0100
Links: << >>  << T >>  << A >>
Philip <philip.freidin@gmail.com> writes:

> (the following may well be fiction)
<snip>

Brilliant - thanks!

Martin

Article: 142049
Subject: Re: Laser marking / custom graphics on blank FPGA?
From: dowlers <eoindowling@gmail.com>
Date: Thu, 23 Jul 2009 03:09:50 -0700 (PDT)
Links: << >>  << T >>  << A >>

>
> Do you want to hide the fact that it's an FPGA? We epoxy pin-fin
> heatsinks on top.
>
> ftp://jjlarkin.lmi.net/DSC01786.JPG
>
> John


Not really hide but advertise company name. It is a non volotile FPGA -
XP2.
I have found a company - Action Circuits.

Eoin




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