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 106775

Article: 106775
Subject: memec-avnet reference designs available
From: "Antti" <Antti.Lukats@xilant.com>
Date: 18 Aug 2006 12:44:30 -0700
Links: << >>  << T >>  << A >>
Hi

it seems that almost all resources from old memec RDC restricted access
area are now available for anyone without restriction, also design
files and documentation for Avnet kits.

There is still registration required to gain access, but that is very
simple and memec board serial # isnt required. eg anyone who just
enters email, etc, will gain access to the files from memec RDC and to
avnet boards schematics docs and ref designs.

finding stuff is now little bit more complicated as it is requried to
select the board product and then the 'reference design' button, it
will bring up the download page for that eval board. There seems to be
no single page with overview links (or I did not find it)


Antti


Article: 106776
Subject: Re: Problem Instantiating a DSP48E or RAMB36 for a Virtex5 in ISE 8.2 SP2
From: jeffnewcomb@nci-usa.com
Date: 18 Aug 2006 12:45:28 -0700
Links: << >>  << T >>  << A >>
Jim,

Thanks for the input.
Can you get your code to go through MAP , Place & Route ? My code gives
a fatal error when it tries to MAP under ISE. I copied the the code I
am using from the language template of ISE so I don't think its a
problem with the template.

Jim Wu wrote:
> This is probably caused by something else as I just tried the code
> below and it works fine. Try to check the file encoding and make sure
> there is no weird characters in the file. I have seen problems with
> copying templates from PDF file.
>
> module top(a_in, b_in, p_out);
>     input [15:0] a_in;
>     input [15:0] b_in;
>     output [31:0] p_out;
>
> DSP48E #(
>    .ACASCREG(1),       // Number of pipeline registers between A/ACIN
> input and ACOUT output, 0, 1, or 2
>    .ALUMODEREG(1),     // Number of pipeline registers on ALUMODE
> input, 0 or 1
>    .AREG(1),           // Number of pipeline registers on the A input,
> 0, 1 or 2
>    .AUTORESET_PATTERN_DETECT("FALSE"), // Auto-reset upon pattern
> detect, "TRUE" or "FALSE
>    .AUTORESET_PATTERN_DETECT_OPTINV("MATCH"), // Reset if "MATCH" or
> "NOMATCH
>    .A_INPUT("DIRECT"), // Selects A input used, "DIRECT" (A port) or
> "CASCADE" (ACIN port)
>    .BCASCREG(1),       // Number of pipeline registers between B/BCIN
> input and BCOUT output, 0, 1, or 2
>    .BREG(1),           // Number of pipeline registers on the B input,
> 0, 1 or 2
>    .B_INPUT("DIRECT"), // Selects B input used, "DIRECT" (B port) or
> "CASCADE" (BCIN port)
>    .CARRYINREG(1),     // Number of pipeline registers for the CARRYIN
> input, 0 or 1
>    .CARRYINSELREG(1),  // Number of pipeline registers for the
> CARRYINSEL input, 0 or 1
>    .CREG(1),           // Number of pipeline registers on the C input,
> 0 or 1
>    .MASK(48'h3fffffffffff), // 48-bit Mask value for pattern detect
>    .MREG(1),           // Number of multiplier pipeline registers, 0 or
> 1
>    .MULTCARRYINREG(1), // Number of pipeline registers for multiplier
> carry in bit, 0 or 1
>    .OPMODEREG(1),      // Number of pipeline registers on OPMODE input,
> 0 or 1
>    .PATTERN(48'h000000000000), // 48-bit Pattern match for pattern
> detect
>    .PREG(1),           // Number of pipeline registers on the P output,
> 0 or 1
>    .SEL_MASK("MASK"),  // Select mask value between the "MASK" value or
> the value on the "C" port
>    .SEL_PATTERN("PATTERN"), // Select pattern value between the
> "PATTERN" value or the value on the "C" port
>    .SEL_ROUNDING_MASK("SEL_MASK"), // "SEL_MASK", "MODE1", "MODE2
>    .USE_MULT("MULT_S"), // Select multiplier usage, "MULT" (MREG => 0),
> "MULT_S" (MREG => 1), "NONE" (no multiplier)
>    .USE_PATTERN_DETECT("NO_PATDET"), // Enable pattern detect,
> "PATDET", "NO_PATDET
>    .USE_SIMD("ONE48")  // SIMD selection, "ONE48", "TWO24", "FOUR12
> ) DSP48E_inst (
>    .ACOUT(ACOUT),  // 30-bit A port cascade output
>    .BCOUT(BCOUT),  // 18-bit B port cascade output
>    .CARRYCASCOUT(CARRYCASCOUT), // 1-bit cascade carry output
>    .CARRYOUT(CARRYOUT), // 4-bit carry output
>    .MULTSIGNOUT(MULTSIGNOUT), // 1-bit multiplier sign cascade output
>    .OVERFLOW(OVERFLOW), // 1-bit overflow in add/acc output
>    .P(p_out),               // 48-bit output
>    .PATTERNBDETECT(PATTERNBDETECT), // 1-bit active high pattern bar
> detect output
>    .PATTERNDETECT(PATTERNDETECT),   //  1-bit active high pattern
> detect output
>    .PCOUT(PCOUT),  // 48-bit cascade output
>    .UNDERFLOW(UNDERFLOW), // 1-bit active high underflow in add/acc
> output
>    .A(a_in),          // 30-bit A data input
>    .ACIN(ACIN),    // 30-bit A cascade data input
>    .ALUMODE(ALUMODE), // 4-bit ALU control input
>    .B(b_in),          // 18-bit B data input
>    .BCIN(BCIN),    // 18-bit B cascade input
>    .C(C),          // 48-bit C data input
>    .CARRYCASCIN(CARRYCASCIN), // 1-bit cascade carry input
>    .CARRYIN(CARRYIN),         // 1-bit carry input signal
>    .CARRYINSEL(CARRYINSEL),   // 3-bit carry select input
>    .CEA1(CEA1), // 1-bit active high clock enable input for 1st stage A
> registers
>    .CEA2(CEA2), // 1-bit active high clock enable input for 2nd stage A
> registers
>    .CEALUMODE(CEALUMODE), // 1-bit active high clock enable input for
> ALUMODE registers
>    .CEB1(CEB1), // 1-bit active high clock enable input for 1st stage B
> registers
>    .CEB2(CEB2), // 1-bit active high clock enable input for 2nd stage B
> registers
>    .CEC(CEC),   // 1-bit active high clock enable input for C registers
>    .CECARRYIN(CECARRYIN), // 1-bit active high clock enable input for
> CARRYIN register
>    .CECTRL(CECTRL), // 1-bit active high clock enable input for OPMODE
> and carry registers
>    .CEM(CEM),   // 1-bit active high clock enable input for multiplier
> registers
>    .CEMULTCARRYIN(CEMULTCARRYIN), // 1-bit active high clock enable for
> multiplier carry in register
>    .CEP(CEP),   // 1-bit active high clock enable input for P registers
>    .CLK(CLK),   // Clock input
>    .MULTSIGNIN(MULTSIGNIN), // 1-bit multiplier sign input
>    .OPMODE(OPMODE), // 7-bit operation mode input
>    .PCIN(PCIN),     // 48-bit P cascade input
>    .RSTA(RSTA),     // 1-bit reset input for A pipeline registers
>    .RSTALLCARRYIN(RSTALLCARRYIN), // 1-bit reset input for carry
> pipeline registers
>    .RSTALUMODE(RSTALUMODE), // 1-bit reset input for ALUMODE pipeline
> registers
>    .RSTB(RSTB), // 1-bit reset input for B pipeline registers
>    .RSTC(RSTC),  // 1-bit reset input for C pipeline registers
>    .RSTCTRL(RSTCTRL), // 1-bit reset input for OPMODE pipeline
> registers
>    .RSTM(RSTM), // 1-bit reset input for multiplier registers
>    .RSTP(RSTP)  // 1-bit reset input for P pipeline registers
> );
>
> endmodule
>
> HTH,
> Jim
> http://home.comcast.net/~jimwu88/tools/
> jeffnewcomb@nci-usa.com wrote:
> > I wish this was just a display issue but the ISE does not recognize
> > this as a legal primitive and show a question mark in the sources
> > window for the DSP48E. Synthesis will not complete without errors.
> > Jim Wu wrote:
> > > I think this is just a display issue. If the backend tools know dsp48e
> > > is a primitive, why bother if the text is shown in red or black?
> > >
> > > HTH,
> > > Jim
> > > http://home.comcast.net/~jimwu88/tools/
> > >
> > > jeffnewcomb@nci-usa.com wrote:
> > > > I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not
> > > > recognize the part as a device primitive. Primitives are normal shown
> > > > in red text under ISE but when I block copy the part from the language
> > > > template the DSP48E is shown in black text and ISE does not know it is
> > > > a primitive. I have a V5LX50 selected as the device I am using. I have
> > > > also had the same problem instantiating a RAMB36 and a PLL_ADV. Does
> > > > anyone know how to do this successfully?


Article: 106777
Subject: Re: Problem with "don't care"
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 18 Aug 2006 21:56:08 +0200
Links: << >>  << T >>  << A >>

A.D. schrieb:
> Hi guys!
> I'm experiencing same problems with don't care conditions in
> VHDL (with ISE / ModelSim)...
> I'm wondering if using don't cares in VHDL is a safe
> practice, since it seems that different tools treat them in
> different ways! For example, if I test "1110 0010" against
> "---- 0010" (with if, case, when and so on...) I expect to
> obtain a match, since the four specified bits are the same.
> The ISE (and maybe Synplify) seems to behave as expected
> when synthesizing the design, but ModelSim (behavioral sim.)
> does not recognize the two strings as the same (they are both
> std_logic_vector signals or constants).
> Is there somthing wrong I'm doing? It is better to avoid using
> don't cares at all? Ther is some kind of "workaround" to obtain
> the expected behaviour with ModelSim?!?

In VHDL std_logic ist just an enumeration. So '-' does neither equal '0'
nor '1'.

There are special library function that have the behaviour that you
intend ('-' being equal to both '0' and '1'.)

There is another area where this can hurt you. The often used formulation
if clock'event and clock='1' then ...
to describe a rising edge triggered flip flop will misbehave in
simulation because it will trigger on a change from 'U', 'X', '-' or 'H'
to '1' (whicht it should not) but it won't trigger on a transition
from '0' to 'H' or 'L' to 'H' (which it should).
For simulation you really must use
if rising_edge(clock) then ...
instead.

Kolja Sulimma

Article: 106778
Subject: Re: EDK vs. ISE for image processing
From: "fpganovice" <alecwei@gmail.com>
Date: 18 Aug 2006 13:53:36 -0700
Links: << >>  << T >>  << A >>
Many thanks for your reply, Erik.  How would the VGA module function if
the processor is removed?  I remember there's a C function running on
the processor that initiates the display...


Erik Widding wrote:
> > > Guru wrote:
> > > > Forget about MicroBlaze, you will never get the desired speed. Image
> > > > processing should be done in logic ONLY. Try to figure out how you can
> > > > serialize your processing algorithm to work pixel-to-pixel. This way
> > > > you probably won't even need a DDR.
>
> Without any performance criteria, this is absolutely meaningless
> advice.
>
> fpganovice wrote:
> > quickwayne@gmail.com wrote:
> > > Microblaze is not so fast but why not to design microblaze plus some
> > > hardware accelerators. It could be fast enough and easy to design, I
> > > suppose.
> >
> > This is what I was originally thinking.  I already have a VHDL module
> > for image processing pixel-by-pixel.  So I was thinking of integrating
> > it with the microblaze and use the DDR and VGA controllers that come
> > with the microblaze design.
>
> Processors can be very useful.  Don't overlook the fact that one can
> use the EDK without having a processor in the system.  We do this with
> a lot of our image processing systems.
>
> The automation that this tool provides for mixing and matching IP
> modules with buses can be extremely useful in any data processing
> application.  A reference design for this board employing the
> MicroBlaze processor can be used as a starting point.  The processor
> can be removed, and an OPB bus master interface attached to your
> existing IP can be put in its place.
>
> Xilinx has gone to a lot of effort on the IPIF package, but it has been
> our experience here that if you start with CoreConnect documents from
> IBM it will be easier to just attach your IP directly to the OPB bus
> rather than through the IPIF.  To start, just do single 32bit reads and
> single 32bit writes per bus transaction.  Think of this as a sort of a
> "hello world", to prove that you have the basics of EDK, the PAO and
> MPD files and the OPB bus down.  Then it will be only a minor effort to
> move to burst transfers.  With single reads you moght find that you
> only get 25% bus utilization.  With longer bursts you can easily get
> 90%+.
>
> The other sugggestion I would make relates to the architecture of your
> module.  If you use a BlockRam with a 32bit port to attach to the OPB
> bus, and an 8bit (pixel width) port to attach to you IP, your IP and
> the bus can run asynchronously to each other (i.e. at arbitrary clock
> rates) and your IP does not need to know how to do anything other than
> handle one pixel at a time, even if you perform burst transfers.  The
> state machines that run your OPB interface and you processing IP each
> need to pass a strobe to the other when it has written a burst of
> pixels it wants the other side to handle.  Flow control is easily
> handled this way.
>
> The fifo mode of the Virtex4 BlockRam does not allow for different port
> sizes.  I wish it did.  I remember having a rather heated conversation
> with Peter regarding this at a Xilinx gathering a few years back.  It
> would be particularly nice for all kinds of serial/parallel conversion
> from bit to pixel, pixel to word, or bit to many pixels in parallel,
> etc.  While it might take less resource to do the width conversion and
> use the fifo, than to implement the burst counters and not use the
> fifo, the later does have one added benefit.  One can fit two fifos,
> one in each direction, into a single blockram.
>
> Haven't yet looked at the blockrams in fifo mode in V5 yet - as all of
> our active designs are V4 for the rest of the year.  Anybody care to
> comment if different port widths are supported?
>
>
> Regards,
> Erik.
>
> ---
> Erik Widding
> President
> Birger Engineering, Inc.
>
>  (mail) 100 Boylston St #1070; Boston, MA 02116
> (voice) 617.695.9233
>   (fax) 617.695.9234
>   (web) http://www.birger.com


Article: 106779
Subject: Xilinx ise ml402 bram interface
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 18 Aug 2006 14:36:36 -0700
Links: << >>  << T >>  << A >>
I would like to be able to send and receive data on the fly to a Xilinx V4 
BRAM. I would communicate to the A port while the design under test would 
use the B port. (Or the other way around is OK to). A minimum of hardware 
would be nice. On this dev board there is an RS232 UART port, a USB2 port 
that goes through the Cypress part, an Ethernet port, the JTAG port, all of 
which seem to be OK fine candidates for an interface.

Can somebody tell me what is the easiest non-EDK path for me?

Brad Smallridge
aivision
 



Article: 106780
Subject: Re: Problem Instantiating a DSP48E or RAMB36 for a Virtex5 in ISE 8.2 SP2
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 18 Aug 2006 15:10:43 -0700
Links: << >>  << T >>  << A >>
Yes, it runs through par w/o problem. Below is the map report:
Slice Logic Distribution:
  Either LUT or Flip Flop pair used:          0 out of  28,800    0%
  Both LUT and Flip Flop pair used:           0 out of  28,800    0%

IO Utilization:
  Number of bonded IOBs:                     64 out of     440   14%

Specific Feature Utilization:
  Number of DSP48Es:                          1 out of      48    2%

HTH,
Jim
http://home.comcast.net/~jimwu88/tools/

jeffnewcomb@nci-usa.com wrote:
> Jim,
>
> Thanks for the input.
> Can you get your code to go through MAP , Place & Route ? My code gives
> a fatal error when it tries to MAP under ISE. I copied the the code I
> am using from the language template of ISE so I don't think its a
> problem with the template.
>
> Jim Wu wrote:
> > This is probably caused by something else as I just tried the code
> > below and it works fine. Try to check the file encoding and make sure
> > there is no weird characters in the file. I have seen problems with
> > copying templates from PDF file.
> >
> > module top(a_in, b_in, p_out);
> >     input [15:0] a_in;
> >     input [15:0] b_in;
> >     output [31:0] p_out;
> >
> > DSP48E #(
> >    .ACASCREG(1),       // Number of pipeline registers between A/ACIN
> > input and ACOUT output, 0, 1, or 2
> >    .ALUMODEREG(1),     // Number of pipeline registers on ALUMODE
> > input, 0 or 1
> >    .AREG(1),           // Number of pipeline registers on the A input,
> > 0, 1 or 2
> >    .AUTORESET_PATTERN_DETECT("FALSE"), // Auto-reset upon pattern
> > detect, "TRUE" or "FALSE
> >    .AUTORESET_PATTERN_DETECT_OPTINV("MATCH"), // Reset if "MATCH" or
> > "NOMATCH
> >    .A_INPUT("DIRECT"), // Selects A input used, "DIRECT" (A port) or
> > "CASCADE" (ACIN port)
> >    .BCASCREG(1),       // Number of pipeline registers between B/BCIN
> > input and BCOUT output, 0, 1, or 2
> >    .BREG(1),           // Number of pipeline registers on the B input,
> > 0, 1 or 2
> >    .B_INPUT("DIRECT"), // Selects B input used, "DIRECT" (B port) or
> > "CASCADE" (BCIN port)
> >    .CARRYINREG(1),     // Number of pipeline registers for the CARRYIN
> > input, 0 or 1
> >    .CARRYINSELREG(1),  // Number of pipeline registers for the
> > CARRYINSEL input, 0 or 1
> >    .CREG(1),           // Number of pipeline registers on the C input,
> > 0 or 1
> >    .MASK(48'h3fffffffffff), // 48-bit Mask value for pattern detect
> >    .MREG(1),           // Number of multiplier pipeline registers, 0 or
> > 1
> >    .MULTCARRYINREG(1), // Number of pipeline registers for multiplier
> > carry in bit, 0 or 1
> >    .OPMODEREG(1),      // Number of pipeline registers on OPMODE input,
> > 0 or 1
> >    .PATTERN(48'h000000000000), // 48-bit Pattern match for pattern
> > detect
> >    .PREG(1),           // Number of pipeline registers on the P output,
> > 0 or 1
> >    .SEL_MASK("MASK"),  // Select mask value between the "MASK" value or
> > the value on the "C" port
> >    .SEL_PATTERN("PATTERN"), // Select pattern value between the
> > "PATTERN" value or the value on the "C" port
> >    .SEL_ROUNDING_MASK("SEL_MASK"), // "SEL_MASK", "MODE1", "MODE2
> >    .USE_MULT("MULT_S"), // Select multiplier usage, "MULT" (MREG => 0),
> > "MULT_S" (MREG => 1), "NONE" (no multiplier)
> >    .USE_PATTERN_DETECT("NO_PATDET"), // Enable pattern detect,
> > "PATDET", "NO_PATDET
> >    .USE_SIMD("ONE48")  // SIMD selection, "ONE48", "TWO24", "FOUR12
> > ) DSP48E_inst (
> >    .ACOUT(ACOUT),  // 30-bit A port cascade output
> >    .BCOUT(BCOUT),  // 18-bit B port cascade output
> >    .CARRYCASCOUT(CARRYCASCOUT), // 1-bit cascade carry output
> >    .CARRYOUT(CARRYOUT), // 4-bit carry output
> >    .MULTSIGNOUT(MULTSIGNOUT), // 1-bit multiplier sign cascade output
> >    .OVERFLOW(OVERFLOW), // 1-bit overflow in add/acc output
> >    .P(p_out),               // 48-bit output
> >    .PATTERNBDETECT(PATTERNBDETECT), // 1-bit active high pattern bar
> > detect output
> >    .PATTERNDETECT(PATTERNDETECT),   //  1-bit active high pattern
> > detect output
> >    .PCOUT(PCOUT),  // 48-bit cascade output
> >    .UNDERFLOW(UNDERFLOW), // 1-bit active high underflow in add/acc
> > output
> >    .A(a_in),          // 30-bit A data input
> >    .ACIN(ACIN),    // 30-bit A cascade data input
> >    .ALUMODE(ALUMODE), // 4-bit ALU control input
> >    .B(b_in),          // 18-bit B data input
> >    .BCIN(BCIN),    // 18-bit B cascade input
> >    .C(C),          // 48-bit C data input
> >    .CARRYCASCIN(CARRYCASCIN), // 1-bit cascade carry input
> >    .CARRYIN(CARRYIN),         // 1-bit carry input signal
> >    .CARRYINSEL(CARRYINSEL),   // 3-bit carry select input
> >    .CEA1(CEA1), // 1-bit active high clock enable input for 1st stage A
> > registers
> >    .CEA2(CEA2), // 1-bit active high clock enable input for 2nd stage A
> > registers
> >    .CEALUMODE(CEALUMODE), // 1-bit active high clock enable input for
> > ALUMODE registers
> >    .CEB1(CEB1), // 1-bit active high clock enable input for 1st stage B
> > registers
> >    .CEB2(CEB2), // 1-bit active high clock enable input for 2nd stage B
> > registers
> >    .CEC(CEC),   // 1-bit active high clock enable input for C registers
> >    .CECARRYIN(CECARRYIN), // 1-bit active high clock enable input for
> > CARRYIN register
> >    .CECTRL(CECTRL), // 1-bit active high clock enable input for OPMODE
> > and carry registers
> >    .CEM(CEM),   // 1-bit active high clock enable input for multiplier
> > registers
> >    .CEMULTCARRYIN(CEMULTCARRYIN), // 1-bit active high clock enable for
> > multiplier carry in register
> >    .CEP(CEP),   // 1-bit active high clock enable input for P registers
> >    .CLK(CLK),   // Clock input
> >    .MULTSIGNIN(MULTSIGNIN), // 1-bit multiplier sign input
> >    .OPMODE(OPMODE), // 7-bit operation mode input
> >    .PCIN(PCIN),     // 48-bit P cascade input
> >    .RSTA(RSTA),     // 1-bit reset input for A pipeline registers
> >    .RSTALLCARRYIN(RSTALLCARRYIN), // 1-bit reset input for carry
> > pipeline registers
> >    .RSTALUMODE(RSTALUMODE), // 1-bit reset input for ALUMODE pipeline
> > registers
> >    .RSTB(RSTB), // 1-bit reset input for B pipeline registers
> >    .RSTC(RSTC),  // 1-bit reset input for C pipeline registers
> >    .RSTCTRL(RSTCTRL), // 1-bit reset input for OPMODE pipeline
> > registers
> >    .RSTM(RSTM), // 1-bit reset input for multiplier registers
> >    .RSTP(RSTP)  // 1-bit reset input for P pipeline registers
> > );
> >
> > endmodule
> >
> > HTH,
> > Jim
> > http://home.comcast.net/~jimwu88/tools/
> > jeffnewcomb@nci-usa.com wrote:
> > > I wish this was just a display issue but the ISE does not recognize
> > > this as a legal primitive and show a question mark in the sources
> > > window for the DSP48E. Synthesis will not complete without errors.
> > > Jim Wu wrote:
> > > > I think this is just a display issue. If the backend tools know dsp48e
> > > > is a primitive, why bother if the text is shown in red or black?
> > > >
> > > > HTH,
> > > > Jim
> > > > http://home.comcast.net/~jimwu88/tools/
> > > >
> > > > jeffnewcomb@nci-usa.com wrote:
> > > > > I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not
> > > > > recognize the part as a device primitive. Primitives are normal shown
> > > > > in red text under ISE but when I block copy the part from the language
> > > > > template the DSP48E is shown in black text and ISE does not know it is
> > > > > a primitive. I have a V5LX50 selected as the device I am using. I have
> > > > > also had the same problem instantiating a RAMB36 and a PLL_ADV. Does
> > > > > anyone know how to do this successfully?


Article: 106781
Subject: Re: EDK vs. ISE for image processing
From: "Erik Widding" <widding@birger.com>
Date: 18 Aug 2006 17:52:08 -0700
Links: << >>  << T >>  << A >>
fpganovice wrote:
> Many thanks for your reply, Erik.  How would the VGA module function if
> the processor is removed?  I remember there's a C function running on
> the processor that initiates the display...

For a simple single video buffer (i.e. no shadow or ping-pong like
buffering), you can go into the source code for the VGA module and
modify the reset assignment to the registers that you care about.  If I
wanted to get something working fast I would do (and have done) such
things.

This address could be written over some external interface that has a
bus master connection to the OPB (i.e. PCI).  But with the ML401 board,
there is no easy way to do this.  Our processorless FPGAs usually have
a port such as this.

In more complicated systems, where we have circular buffers of frames
being processed, we set up each IP module in the sequence to read the
address of the last completed buffer from its predecessor.  Given that
you will be using somebody else's VGA module, you could simply have
your module write the address of the next frame to the VGA instead.

Or, rather than distributing intelligence into all of your modules...
You could have a simple state machine that is an OPB master that does
some of the setup/housekeeping tasks.  It might be as simple as a 32bit
wide blockram (as a ROM) where portA is used to present an address on
the bus and portB is used to present the data.  A subrange of portA
could store the microcode for your statemachine as well.  It would only
take a few extra gates to handshake with the bus, and sequence through
the microcode.  It might take as input a single interrupt that tells it
the next frame has been processed.  EDK can be used as a framework to
do cool stuff like this.

In many systems there is a desire for a processor of some sort, as it
just makes life easier to deal with the setup and housekeeping, as you
point out.  Sometimes a state machine is good enough, and much smaller.
 It has been 4 or 5 years since we have put a discrete processor on a
board next to an FPGA, as EDK lets us do all kind of interesting "what
if" architectural trade-offs in real hardware without having to rev
physical hardware.  EDK is an excellent tool for setting up, and
modifying the dataflow in an FPGA - whther or not a processor
(Microblaze, PPC, something else, etc) is present.

I had not meant to suggest that a processor was not a smart choice for
your application.  I only meant to suggest that it wasn't the ONLY
choice.  Your question to me demonstrates that you are clearly thinking
through your options.  Makes me feel that spending an extra few minutes
writing out a more detailed answer is worth while.  Nice way to end a
friday - feeling appreciated.  Good luck as you continue with your
project.


Regards,
Erik.


---
Erik Widding
President
Birger Engineering, Inc.


 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234 
  (web) http://www.birger.com


Article: 106782
Subject: Re: Ultracontroller II: PROM solution in EDK 8.1
From: "louis lin" <louis99.lin@gmail.com>
Date: Sat, 19 Aug 2006 12:31:32 +0800
Links: << >>  << T >>  << A >>

Hi Patrick,

Thank you for your help.
Actually, I patched Answer #23011 before going through the flow
in EDK 8.1i.
I'll try to use uc2.vhd instead of uc2.ngc.

Regards,
louis


"Patrick Dubois" <prdubois@gmail.com>
:1155922197.062518.72270@75g2000cwc.googlegroups.com...
> Hi Louis,
>
> I'm also currently working with the UC2, but on a Virtex-II Pro.
>
> First of all, make sure to replace some files as indicated in Answer
> Record #23011:
> http://tinyurl.com/e7c2g
>
> I also just solved a bug with the UC2 design on the Virtex-II Pro (I
> spent a week on it). It turns out that the file uc2.ngc is buggy. There
> is no error given by Xilinx tools however (which made is quite hard to
> debug), but the resulting bit file cannot be programmed in the FPGA
> (programming fails in Impact). The solution is to not use uc2.ngc at
> all and instead use uc2.vhd, also provided in the reference design. I
> don't know if the reference design for the V4 has the same issue
> though...
>
> Best of luck,
>
> Patrick Dubois
>
>
>
> louis lin wrote:
> > Has anyone tried Ultracontroller PROM solution of V4 in EDK 8.1i?
> >
> > The reference example is built by EDK 7.1i.
> > I went through the flow again in ISE 8.1 SP3 + EDK 8.1i SP2.
> > However, the resultant MCS can't program the XC4VFX12 properly
> > (DONE LED didn't go high).
> >
> > After I got the reference, I only added the -nostartfiles compiler
option to
> > fix
> > the multiple _start problem.
> >
> > Regards,
> > louis
>



Article: 106783
Subject: Re: FFT on an FPGA
From: "David M. Palmer" <dmpalmer@email.com>
Date: Fri, 18 Aug 2006 23:00:18 -0600
Links: << >>  << T >>  << A >>
In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka
<ray@andraka.com> wrote:

> Make no bones about it, floating point arithmetic is expensive in terms 
> of amount of logic.  There are some shortcuts for FFTs that will 
> increase the dynamic range without going to a full floating point 
> implementation.  The most common is to use block floating point which 
> rescales the entire FFT result by a common power of 2 selected so that 
> the largest signal does not overflow.  Block floating point is typically 
> applied after each FFT stage, and is an effective way to limit the word 
> widths without resorting to floating point arithmetic.

Does anybody do the following thing?:  At each step, the adders check
for whether the high order bit of any result is set.  (Just an N-way OR
gate).  If so, then the next step includes a right-shift (for all
elements), otherwise there is no right-shift.  In the end, you get an
FFT result which must be scaled by 2^number-of-right-shifts, but has as
much resolution as is possible given the number of bits (for the
largest-magnitude components).

Sort of similar to floating point, except that there is only one
exponent for all components.

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

Article: 106784
Subject: Re: FFT on an FPGA
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 19 Aug 2006 12:28:45 +0200
Links: << >>  << T >>  << A >>
David M. Palmer schrieb:
> In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka
> <ray@andraka.com> wrote:

> Does anybody do the following thing?:  At each step, the adders check
> for whether the high order bit of any result is set.  (Just an N-way OR
> gate).  If so, then the next step includes a right-shift (for all
> elements), otherwise there is no right-shift.  In the end, you get an
> FFT result which must be scaled by 2^number-of-right-shifts, but has as
> much resolution as is possible given the number of bits (for the
> largest-magnitude components).


See my previous post.
For the last half of inputs you loose M-1 bits of resolution. This
is not much better than just shifting all inputs by M-1 bits to the
right at the beginning.

Floating point with S bits in the significand is not better for summing
up many small values than S bit fixed point.

Kolja Sulimma

Article: 106785
Subject: Re: FFT on an FPGA
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 19 Aug 2006 12:29:50 +0200
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:
> Depending on the use of the result, it may be an option to compress
> the input with a log function. This will decrease the number of bits
> considerably to achieve a certain dynamic range (more or less like
> ulaw / alaw compression used in digital telephony).

Addition on a log scale is rather difficult.

Kolja Sulimma

Article: 106786
Subject: Re: S3 starter kit, command-line
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Sat, 19 Aug 2006 13:14:55 +0200
Links: << >>  << T >>  << A >>
Hmm, If this is the small S3 starter board that you program via USB?? Err, I 
got it from memec for about 100$ a while ago, I don't remember the exact 
name (alas it resides in a cupboard somewhere now), anyways in my case the 
combined flash-processor-usb packed up after about a week using it, the 
documentation was useless, and it looked like a real beast to debug. I had 
the same sort of problem meaning I coundn't get a bitstream into the flash 
without it becoming corrupt, then of course the S3 programming wouldn't 
verify.  It would work by JTAG, directly into the FPGA,  but that was it. 
I'll have a look see if I can find the board - itmight be a batch fault...

Ben

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:44e4dd6b$1@clear.net.nz...
> burn.sir@gmail.com wrote:
>
>> Well, I really had enough of this last night (with Impact crashing
>> every 5 minutes instead of the usual every 20 minutes). Was so -><-
>> close to trash the board and pretend it was bricked :)
>>
>>
>> Somehow, I forced  myself to go back to it when I got home right after
>> work, and tried to read from flash after configuration. I got
>> mismatches like this in few places (above: read, below: original mcs):
>>
>>
>> 7485,7490c7485,7490
>> < :10D3A000000000000000000000000000FFFFFFFF81
>> < :10D3B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
>> < :10D3C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6D
>> < :10D3D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
>> < :10D3E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D
>> < :10D3F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
>> ---
>>
>>>:10D3A000000000000000000000000000000000007D
>>>:10D3B000000000000000000000000000000000006D
>>>:10D3C000000000000000000000000000000000005D
>>>:10D3D000000000000000000000000000000000004D
>>>:10D3E000000000000000000000000000000000003D
>>>:10D3F000000000000000000000000000000000002D
>>
>>
>>
>> The error rate is something like 2-3%. The board is new*, the cable is
>> new. Hell, even the computer I ran this from is shiny new. Everything
>> works just fine when programming the FPGA directly.
>>
>> Does Anyone know what the problem is? Is xilinx flash this unreliable,
>> or am I doing something wrong?
>>
>>
>> regards
>> - Burns
>>
>>
>>
>> * actually its really old, but totally unused. I just haven't cared
>> enough to play with my xilinx boards. Very much thanks to a scary first
>> encounter with ISE...
>
> That looks like it just stopped writing 0's ?
>
> If you read 30 times, do you get the matching 30 results ? - that checks 
> read integrity.
> Can you get the Flash into a device programmer, that can read it.
> That gives a second verify of contents.
>
> Are these errors always at start/finish. ?
> I have seen other devices flash-error on preamble or post-amble
> timing errors.
>
> -jg
>
> 



Article: 106787
Subject: Re: FFT on an FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Aug 2006 13:31:39 GMT
Links: << >>  << T >>  << A >>
Kolja Sulimma <news@sulimma.de> wrote:

>Nico Coesel schrieb:
>> Depending on the use of the result, it may be an option to compress
>> the input with a log function. This will decrease the number of bits
>> considerably to achieve a certain dynamic range (more or less like
>> ulaw / alaw compression used in digital telephony).
>
>Addition on a log scale is rather difficult.

You don't have to. Use a conversion table or bit shifting (like u-law
/ a-law) to convert from lin to log. The fft won't mind the signal it
is processing is converted to a log scale. After fft convert the
result back to linear if required.

The scheme is very simple:

in -> lin to log -> fft -> log to lin -> out

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106788
Subject: Re: FFT on an FPGA
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 19 Aug 2006 16:30:03 +0200
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:
> Kolja Sulimma <news@sulimma.de> wrote:
> 
> 
>>Nico Coesel schrieb:
>>
>>>Depending on the use of the result, it may be an option to compress
>>>the input with a log function. This will decrease the number of bits
>>>considerably to achieve a certain dynamic range (more or less like
>>>ulaw / alaw compression used in digital telephony).
>>
>>Addition on a log scale is rather difficult.
> 
> 
> You don't have to. Use a conversion table or bit shifting (like u-law
> / a-law) to convert from lin to log. The fft won't mind the signal it
> is processing is converted to a log scale. After fft convert the
> result back to linear if required.
> 
> The scheme is very simple:
> 
> in -> lin to log -> fft -> log to lin -> out

Definitely not. Log is not linear.

log(a+b) <> log a + log b

The spectrum of log(sin(x)) constains frequencies that sin(x) does not
because sin is not an eigenfunction of log.

Scaling the spectrum will not make these extra frequencies vanish.

Kolja Sulimma




Article: 106789
Subject: Re: FFT on an FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Aug 2006 14:51:36 GMT
Links: << >>  << T >>  << A >>
Kolja Sulimma <news@sulimma.de> wrote:

>Nico Coesel schrieb:
>> Kolja Sulimma <news@sulimma.de> wrote:
>> 
>> 
>>>Nico Coesel schrieb:
>>>
>>>>Depending on the use of the result, it may be an option to compress
>>>>the input with a log function. This will decrease the number of bits
>>>>considerably to achieve a certain dynamic range (more or less like
>>>>ulaw / alaw compression used in digital telephony).
>>>
>>>Addition on a log scale is rather difficult.
>> 
>> 
>> You don't have to. Use a conversion table or bit shifting (like u-law
>> / a-law) to convert from lin to log. The fft won't mind the signal it
>> is processing is converted to a log scale. After fft convert the
>> result back to linear if required.
>> 
>> The scheme is very simple:
>> 
>> in -> lin to log -> fft -> log to lin -> out
>
>Definitely not. Log is not linear.
>
>log(a+b) <> log a + log b
>
>The spectrum of log(sin(x)) constains frequencies that sin(x) does not
>because sin is not an eigenfunction of log.
>
>Scaling the spectrum will not make these extra frequencies vanish.

Just run some numbers on the error being introduced versus the savings
in logic.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106790
Subject: xc2vp30-6ff1152
From: "zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl>
Date: Sat, 19 Aug 2006 17:24:17 +0200
Links: << >>  << T >>  << A >>
I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is not 
on the list in Project Properties. Should I have any library? I can't find 
it.

Thanks,
Wojtek 



Article: 106791
Subject: Re: xc2vp30-6ff1152
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 19 Aug 2006 18:49:10 +0200
Links: << >>  << T >>  << A >>
"zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl> schrieb im Newsbeitrag 
news:1156001058.926841@pdp...
> I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is not 
> on the list in Project Properties. Should I have any library? I can't find 
> it.
>
> Thanks,
> Wojtek
>
you are not trying with WebPack? this part is not supported by the free 
tools

antti 



Article: 106792
Subject: Re: xc2vp30-6ff1152
From: "zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl>
Date: Sat, 19 Aug 2006 18:56:11 +0200
Links: << >>  << T >>  << A >>

Użytkownik "Antti Lukats" <antti@openchip.org> napisał w wiadomości 
news:ec7fe6$fum$1@online.de...
> "zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl> schrieb im Newsbeitrag 
> news:1156001058.926841@pdp...
>> I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is 
>> not on the list in Project Properties. Should I have any library? I can't 
>> find it.
>>
>> Thanks,
>> Wojtek
>>
> you are not trying with WebPack? this part is not supported by the free 
> tools
>


ok, thanks...

and do you know if ucf file is the same for all V2P family?

I have error:

"LOC constraint W32 on P_IO_DQ<10> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'."

I used xc2vp2-6ff672
Is it possible to be correct for xc2vp30-6ff1152 ?

 zlotawy 



Article: 106793
Subject: Anyone use XC3Sprog?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 19 Aug 2006 17:05:09 GMT
Links: << >>  << T >>  << A >>
I'm trying to use xc3sprog to program a XCF3s1500fg456 using a parallel 
cable III.  I get the following error:

$ ./xc3sprog pci_7seg.bit
Release 0.5
Cannot find device having IDCODE=05045093

I noticed the following line in devlist.txt:

05045093        8       XCF02S

I get the following fro bitparse:

Created from NCD file: pci_7seg.ncd
Target device: 3s1500fg456
Created: 2006/ 8/11 13:49:16
Bitstream length: 5214784 bits


I sent an email to the author of xc3sprog several days ago, but I've not 
heard anything back...

Phil


Article: 106794
Subject: Re: FFT on an FPGA
From: "David M. Palmer" <dmpalmer@email.com>
Date: Sat, 19 Aug 2006 11:18:14 -0600
Links: << >>  << T >>  << A >>
In article <44e6e7e0$0$6994$9b4e6d93@newsspool1.arcor-online.net>,
Kolja Sulimma <news@sulimma.de> wrote:

> David M. Palmer schrieb:
> > In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka
> > <ray@andraka.com> wrote:
> 
> > Does anybody do the following thing?:  At each step, the adders check
> > for whether the high order bit of any result is set.  (Just an N-way OR
> > gate).  If so, then the next step includes a right-shift (for all
> > elements), otherwise there is no right-shift.  In the end, you get an
> > FFT result which must be scaled by 2^number-of-right-shifts, but has as
> > much resolution as is possible given the number of bits (for the
> > largest-magnitude components).
> 
> 
> See my previous post.
> For the last half of inputs you loose M-1 bits of resolution. This
> is not much better than just shifting all inputs by M-1 bits to the
> right at the beginning.

You only lose low order bits if you need high-order bits.

> Floating point with S bits in the significand is not better for summing
> up many small values than S bit fixed point.

It all depends on what you are doing.

If you are searching for tones in noisy data, where the strengths of
the tones and the noise aren't determined at design time, then
shift-if-you-need-it is a good strategy because you don't care about
the noise in frequency space, only the strongest signal.  It gives you
overall dynamic range between, but not within, measurements.

If you are trying to filter out an interfering frequency to see what's
underneath it, then losing everything below 2^-n of the largest
frequency tone is sub-optimal.  If you use floating point with too few
bits in the significand, then there will be significance loss in a
complicated pattern in frequency space.

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

Article: 106795
Subject: Speed vs Area Optimisation
From: "FlyingPenguin" <mikyt84@gmail.com>
Date: 19 Aug 2006 11:45:47 -0700
Links: << >>  << T >>  << A >>
Hi! I'm a newbie at designing circuits on FPGA and I have found out
something I cannot understand very well.  I've written the VHDL
description of some Linear Feedback Shift Registers and I have
synthesised them with Xilinx's xst using different optimisations: for
Speed and for Area.  I've noticed that, even if the Speed optimisation
leads in many cases to a faster circuit, sometimes it produces a slower
circuit than the Area optimisation. Though, this is quite infrequent.
The real problem, is with the Area optimisation, that, according to
xst's Synthesis Report, often produces a circuit with more flipflops,
used slices, and bonded IOBs than Speed optimisation. The only
unchanged or lower values are the number of BELs and LUTs used.  How
can this be? Am I looking at the wrong values to see whether the area
has been reduced or not? Or is it a problem with some XST parameter?
Thanks in advance to everyone who will answer!  FlyingPenguin


Article: 106796
Subject: Re: Speed vs Area Optimisation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 19 Aug 2006 12:39:44 -0700
Links: << >>  << T >>  << A >>
FlyingPenguin wrote:

> The real problem, is with the Area optimisation, that, according to
> xst's Synthesis Report, often produces a circuit with more flipflops,
> used slices, and bonded IOBs than Speed optimisation. The only
> unchanged or lower values are the number of BELs and LUTs used. 

This is a gray area.
Maybe some otherwise unused flops were
called up to save some more valuable LUTs.

Area/Speed settings are hints rather
than constraints and as you have seen,
they don't always work.

I have found that the effect of changing
this setting is small and the the default
AUTO setting is as good as any
on the average.

        -- Mike Treseler

Article: 106797
Subject: Re: Hardware book like "Code Complete"?
From: "vijayvithal jahagirdar" <jahagirdar.vs@gmail.com>
Date: 19 Aug 2006 14:06:57 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> > Many hands make light work. Get a couple of dozen of
> > experienced designers, a bunch of proof reading fact
> > checkers and one decent editor and you  got yourself
> > an open source book writing project.
> >
> > Put it out on sourceforge for free and make it useful for any
> > digital designer at any stage in their career or hobby.Do
> > a really good job and it can become the "bible" of the
> > industry that everyone has in the library.
> >
> Certainly an interesting idea.
> >
> > Do we have the critical mass to pull something like this off?
> >
> Always a big question...the other important question is finding the
> 'leader' to prod this along to get it going in the first place.
>
> KJ
A few months ago a similar Idea was posted on an ASIC and Digital
design community at Orkut. The basic Idea was
a) To collect class notes/Presentation on a particular topic and expand
it to a book or
b) A person will come up with the book outline and others will submit
articles on specific topics and flesh it out
The final goal being to get a set of books on hardware design. You can
check the details at http://edaindia.com/books/

Regards
 H.H.I Tracy 
....


Article: 106798
Subject: Warningmessage in ISE
From: "Raymond" <raybakk@yahoo.no>
Date: 19 Aug 2006 14:11:08 -0700
Links: << >>  << T >>  << A >>
Hi there

When I synthesis my design I get some warning messages.

A strange on is this: <<WARNING:Xst:647 - Input <clk> is never used.>>

It is declared in the Entity:
entity RS232 is
    Port (
				reset			: in std_logic;
				clk 			: in  STD_LOGIC;
				rx 				: in  STD_LOGIC;
				PData 		: out  STD_LOGIC_VECTOR (7 downto 0);
				PDataAcc 	: out  STD_LOGIC);
end RS232;

It is used in a process:
SmallClkPros : process(clk, reset)
		begin
...
...
end process SmallClkPros;

Why do I get this warning?

Raymond


Article: 106799
Subject: Re: S3 starter kit, command-line
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 20 Aug 2006 09:14:42 +1200
Links: << >>  << T >>  << A >>
Benjamin Todd wrote:

> Hmm, If this is the small S3 starter board that you program via USB?? Err, I 
> got it from memec for about 100$ a while ago, I don't remember the exact 
> name (alas it resides in a cupboard somewhere now), anyways in my case the 
> combined flash-processor-usb packed up after about a week using it, the 
> documentation was useless, and it looked like a real beast to debug. I had 
> the same sort of problem meaning I coundn't get a bitstream into the flash 
> without it becoming corrupt, then of course the S3 programming wouldn't 
> verify.  It would work by JTAG, directly into the FPGA,  but that was it. 
> I'll have a look see if I can find the board - itmight be a batch fault...

sounds fairly similar to the OP's - here is one idea : do Xilinx publish 
any FLASH cycle limit guarantees, on these ? - could just be a small 
number....
  [ The OP could just live with a 2-3% failure.... :) ]

-jg




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search