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 111000

Article: 111000
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "VC" <chopra_vikram@excite.com>
Date: 26 Oct 2006 12:31:15 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> Can anyone tell me what I need to drive a Camera Link
> output directly from a V4? I have tried LVCMOS25 and I
> can see differential signals at the outputs but at the
> end of a 2 meter cable I see only DC differential levels
> as if the signals are dampened somehow.
>
> Brad Smallridge
> aivision

I think the Camera Link requires a LVDS I/O standard.

You may find the following link useful -
http://www.alacron.com/downloads/vncl98076xz/CameraLink20v113.pdf

Hope this helps.


Article: 111001
Subject: Re: Survey on Quartus SOPC/Nios-II
From: "Antti" <Antti.Lukats@xilant.com>
Date: 26 Oct 2006 13:09:00 -0700
Links: << >>  << T >>  << A >>
bart schrieb:

> Chris wrote:
> > Nope won't work.  I talked to Lattice today.  There is no internal osc to
> > use, and they did not recommend using a bunch of gates.  Moreover there is
> > no extra flash space either - zip.  This is not the first time.  Overall I
> > am very disappointed with what they put out in their MachXO and XP  NV
> > families.  They lack a lot of little features that would make them so much
> > more powerful.  I guess they have heard that from others too, he told me
> > that they were coming out with a 'revised' new XP line next year.  XP-II I
> > think he said.
> >
> > Chris.
>
> Hello Chris,
>
> I spoke with our Director of Applications, Bertrand Leigh on this topic
> and confirmed that the application will work.
>
> Antti is correct, you CAN build an internal ring oscillator based on
> stacked inverters for a coarse frequency oscillator inside the XP or
> EC/ECP type devices.  This is a proven method that has worked at
> Lattice and at other users. XO and ECP2/M device families have built-in
> oscillator based on the configuration oscillator that is accessable
> from the FPGA fabric after configuration.
>
> For Flash write back both options are available -- PERSISTENT=ON for
> sysConfig port and through JTAG.
>
> We will follow up with the person you spoke to on our technical support
> line and let them know about this application. Sorry if they caused any
> confusion.
>
> Hope this helps.
> Bart Borosky, Lattice Semiconductor

thanks Bart,

there are many ways to make a ring-oscillator, depends on the needs I
have one version that I call fgpa_safe  it is basd on 4 FF that use
only set  reset pins. This thing always delivers an "useable" clock for
given FPGA and works any synthesis tool, eg does not get optimized
away.

there can different other methods, which may be better but may require
special trick to fool the optimizer and may require LOC contraints to
get better repeated frequency. invertor chain may run too high
simetimes, as example for V4 special care has to be taken to get the
inverter chain frequency to be low enough to be useable.

in most cases the fgpa_safe oscillator is sufficient, is sure has large
difference in frequency as it will be routed by different paths each
time.

Antti


Article: 111002
Subject: Re: DDR SDRAM access with MPMC2, Databus Width
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 26 Oct 2006 17:21:09 -0400
Links: << >>  << T >>  << A >>
> Any other suggestions?

I believe The MPMC2 zip has two projects using 16-bit memory:
v4fx12lc_ddr_idpp_100mhz
v4fx12mm_ddr_idpp_100mhz

I found this info in the release notes... Take a look at these cores...

/Mikhail



Article: 111003
Subject: a new spartan3E 1600 starter kit available ?
From: rponsard@gmail.com
Date: 26 Oct 2006 14:41:19 -0700
Links: << >>  << T >>  << A >>
see
http://www.digilentinc.com/Products/Detail.cfm?Prod=S3E1600&Nav1=Products&Nav2=Programmable


Article: 111004
Subject: Re: Semantics or examples for Xilinx xgpio driver under Linux?
From: Neil Steiner <neil.steiner@vt.edu>
Date: Thu, 26 Oct 2006 18:17:34 -0400
Links: << >>  << T >>  << A >>
Ah, I see.  The functionality is supported through ioctl() and struct 
ibm_gpio_ioctl_data.  A little strange, but okay.

Article: 111005
Subject: Re: Quartus DSP Blocks
From: "Subroto Datta" <sdatta@altera.com>
Date: 26 Oct 2006 16:12:04 -0700
Links: << >>  << T >>  << A >>
Hi Richard,

You can set the "DSP Block Balancing" synthesis setting to "Logic
Elements".  In the QSF, it looks like this:
set_global_assignment -name DSP_BLOCK_BALANCING "LOGIC ELEMENTS". That
should prevent DSP blocks from being used.

Hope this helps,
Subroto Datta
Altera Corp.




On Oct 26, 12:04 am, "rnbrady" <rnbr...@gmail.com> wrote:
> Hi
>
> I'm compiling my design using Quartus II and using a Cylclone II EP2C35
> device.  The fitter reports currently says it's using 34 /70 embedded
> 9-bit multiplier blocks. I'd like to see how much extra logic it uses
> if I tell it not to use the embedded multipliers, but I can't seem to
> turn them off.
>
> Under the synthesis settings I can set "maximum DSP block usage" from
> -1 to 0 but this has no effect. Any tips?
> 
> Thanks,
> Richard


Article: 111006
Subject: Re: a new spartan3E 1600 starter kit available ?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Fri, 27 Oct 2006 00:12:20 GMT
Links: << >>  << T >>  << A >>
<rponsard@gmail.com> wrote in message 
news:1161898879.404939.234850@b28g2000cwb.googlegroups.com...
> see
> http://www.digilentinc.com/Products/Detail.cfm?Prod=S3E1600&Nav1=Products&Nav2=Programmable


Woo Hoo !  _And_ it apparantly has Stepping 1 silicon.  Thanks for the 
heads-up. 



Article: 111007
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "bart" <bart.borosky@latticesemi.com>
Date: 26 Oct 2006 17:21:58 -0700
Links: << >>  << T >>  << A >>
> I think the Camera Link requires a LVDS I/O standard.
>
> You may find the following link useful -
> http://www.alacron.com/downloads/vncl98076xz/CameraLink20v113.pdf
>
Lattice has a reference design available for this 7:1 source
synchronous LVDS interface (also known as Channel Link, Flat Link, and
Camera Link).

Lattice's 7:1 LVDS Video Interface Reference Design has been optimized
for use with the LatticeECP2/M family of FPGAs.  The reference design
implements standard 7:1 LVDS interfaces using the LatticeECP2/M I/O
structure.  Transmit and receive interfaces are fully and efficiently
implemented by specifically taking advantage of dedicated LVDS I/O, the
generic DDR I/O interface, 2x gearing, and PLL clocking of edge and
system clocks.  The entire design has been tested using a 7:1 LVDS
Display Demo system at speeds of 595MHz.

Detailed Information about the Reference Design and source code is
available here:
http://www.latticesemi.com/products/intellectualproperty/referencedesigns/71lvdsvideointerfaceforec.cfm

Hope this helps.
Bart Borosky, Lattice


Article: 111008
Subject: Re: What should I do with std.textio.all of ModelSim
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 27 Oct 2006 01:10:24 GMT
Links: << >>  << T >>  << A >>
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1161885433.411222.205690@m73g2000cwd.googlegroups.com...
>
> Hi Mike,
> It has nothing to do with compile order.
Based on what I've seen on this thread it appears to me that it probably 
does have to do with the compile order.

> My son is not an vhdl writer,
> but knows many thing unregular. He just happend to get the thing done
> right, many times I asked for his help and he got things done.
>
> I tried following several options without success:
> 1. Put textio.vhd in the project top position;
> 2. Compile all by clicking manu icon;
> 3. Compile by clicking manu icon with textio.vhd selected;
>
> My son put textio.vhd at the last position in project file list, select
> textio.vhd, then clicked manu compile/compile-selected and compiled
> textio.vhd only. After that he compiled all files and succeeded.
>
> If the compile position is concerned, his position is wrong, because
> textio.vhd would be called before all files, but he did it.

My earlier suggestion was a band-aid since it appeared that 'something' had 
recreated textio for you and done so using the wrong style ('87).

The problem though seems to have to do with the 'bram64_512' module that is 
in your current project since earlier in the thread you said that after 
deleting the textio from the library it reappeared after compiling 
'bram64_512'.  This would imply that 'bram64_512' is creating it's own 
version of the textio package that is at the root of what you're fighting.

The problem that you need to hunt down is what exactly what source file(s) 
in your project is(are) creating textio (and why?) and then why is it 
compiling it '87 syntax.  The way to attack that is to clean textio out of 
the library and then compile each file in your project one at a time.  Do 
this for each since for all you know textio might be in more than one of 
your source files.  The other way would be to do a text search through each 
source file and find where the package is being created....but if the 
project list is relatively short, clicking to compile and then looking at 
the library result works too.

KJ 



Article: 111009
Subject: Re: What should I do with std.textio.all of ModelSim
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 26 Oct 2006 19:26:48 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

> The problem though seems to have to do with the 'bram64_512' module that is 
> in your current project since earlier in the thread you said that after 
> deleting the textio from the library it reappeared after compiling 
> 'bram64_512'.  This would imply that 'bram64_512' is creating it's own 
> version of the textio package that is at the root of what you're fighting.

I have just added an item to my list of
advantages to inferring block ram from a
code template :)

     -- Mike Treseler

Article: 111010
Subject: Re: What should I do with std.textio.all of ModelSim
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 26 Oct 2006 20:17:46 -0700
Links: << >>  << T >>  << A >>

KJ wrote:
> "Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
> news:1161885433.411222.205690@m73g2000cwd.googlegroups.com...
> >
> > Hi Mike,
> > It has nothing to do with compile order.
> Based on what I've seen on this thread it appears to me that it probably
> does have to do with the compile order.
>
> > My son is not an vhdl writer,
> > but knows many thing unregular. He just happend to get the thing done
> > right, many times I asked for his help and he got things done.
> >
> > I tried following several options without success:
> > 1. Put textio.vhd in the project top position;
> > 2. Compile all by clicking manu icon;
> > 3. Compile by clicking manu icon with textio.vhd selected;
> >
> > My son put textio.vhd at the last position in project file list, select
> > textio.vhd, then clicked manu compile/compile-selected and compiled
> > textio.vhd only. After that he compiled all files and succeeded.
> >
> > If the compile position is concerned, his position is wrong, because
> > textio.vhd would be called before all files, but he did it.
>
> My earlier suggestion was a band-aid since it appeared that 'something' had
> recreated textio for you and done so using the wrong style ('87).
>
> The problem though seems to have to do with the 'bram64_512' module that is
> in your current project since earlier in the thread you said that after
> deleting the textio from the library it reappeared after compiling
> 'bram64_512'.  This would imply that 'bram64_512' is creating it's own
> version of the textio package that is at the root of what you're fighting.
>
> The problem that you need to hunt down is what exactly what source file(s)
> in your project is(are) creating textio (and why?) and then why is it
> compiling it '87 syntax.  The way to attack that is to clean textio out of
> the library and then compile each file in your project one at a time.  Do
> this for each since for all you know textio might be in more than one of
> your source files.  The other way would be to do a text search through each
> source file and find where the package is being created....but if the
> project list is relatively short, clicking to compile and then looking at
> the library result works too.
>
> KJ

Hi KJ,
I have two files written by myself containing textio.vhd file.

All other blocks, like bram64_512 module, are generated by Xilinx
CoreGenerator and their vhdl files don't contain explicitly
'std.textio.all;'

When I first changed my two files to include write() and writeline()
functions, everything went well. Suddenly one day textio.vhd problem
burst from blue.

Your suggestion is of valuable. My son finished the last touch to
finish the job.

Thank you. 

Weng


Article: 111011
Subject: Re: What should I do with std.textio.all of ModelSim
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 26 Oct 2006 20:19:18 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> KJ wrote:
>
> > The problem though seems to have to do with the 'bram64_512' module that is
> > in your current project since earlier in the thread you said that after
> > deleting the textio from the library it reappeared after compiling
> > 'bram64_512'.  This would imply that 'bram64_512' is creating it's own
> > version of the textio package that is at the root of what you're fighting.
>
> I have just added an item to my list of
> advantages to inferring block ram from a
> code template :)
>
>      -- Mike Treseler

Hi Mike,
How do you infer a block ram? I would like to learn the technique.

Thank you.

Weng


Article: 111012
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "Rob" <robnstef@frontiernet.net>
Date: Fri, 27 Oct 2006 03:19:44 GMT
Links: << >>  << T >>  << A >>
Brad,

The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR 
type) cable.  I currently have a design using a V2PRO30 that drives 5m of 
cable.  The differential pins are driven by the below module.

Take care,
Rob


module diff_outbuf_single(in, p_out, n_out);
    input in;
    output p_out;
    output n_out;

  OBUFDS inst1 (
      .O(p_out),   // Diff_p output(connect directly to top-level port)
      .OB(n_out), // Diff_n output (connect directly to top-level port)
      .I(in)    // Buffer input
    );

endmodule


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:12k1op3ddh0iea@corp.supernews.com...
> Can anyone tell me what I need to drive a Camera Link
> output directly from a V4? I have tried LVCMOS25 and I
> can see differential signals at the outputs but at the
> end of a 2 meter cable I see only DC differential levels
> as if the signals are dampened somehow.
>
> Brad Smallridge
> aivision
>
> 



Article: 111013
Subject: Re: ISE 8.2 freeze
From: scott moore <nospam@nowhere.com>
Date: Thu, 26 Oct 2006 20:49:32 -0700
Links: << >>  << T >>  << A >>
rponsard@gmail.com wrote:
> is that a known bug ?
> 
> ISE 8.2 / win XP seems to freeze while synthesing design (no more mouse
> or menu/button action event response... looks like a threading bug)
> 
> at the end of computation, it comes back to normal execution.
> 

If it completes the operation, its a feature, not a bug. Many, or even
MOST windows apps don't multithread their user interface. In fact,
Windows isn't particularly good at it, there are known issues with two
threads trying to access the GUI at once.

Scott Moore

Article: 111014
Subject: Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
From: Zara <me_zara@dea.spamcon.org>
Date: Fri, 27 Oct 2006 08:15:14 +0200
Links: << >>  << T >>  << A >>
I quit.

A brand new project, with only a dcm, a debug module, 16K ram, an uart
and  intc will not work (problems writing BRAM).

Will continue using 8.1 for a long time, I suspect

Article: 111015
Subject: Re: Jumps in FPGA implemented integrator
From: "Thomas Stanka" <usenet_10@stanka-web.de>
Date: 26 Oct 2006 23:19:47 -0700
Links: << >>  << T >>  << A >>
Hi Helen,

Helen schrieb:
> Many thanks for your input!  Yes you are right, compout is driven
> outside the FPGA and is not synchronous.  I have tried out your
> suggestion (see below), and it does definitely improve things (removes
> most of the jumps :-), but I still have something going wrong as there
> are still some occasional jumps in the data.  I have staggered the
> integrator sum to a falling edge of the clock. (see below).  Is this
> what you meant by 2-stage shift register?

No *g*

> Is there anything else I can
> try?

Yes.

Two stage shift register means two FF in serial clocking in the signal
with your clock and you use the 2nd register. This should do for most
cases, but could be improved by using 3 FF (as below).

process (Clk, Rst)
signal Compout_Reg_Sr : std_ulogic_vector(2 downto 0); -- shift
if Rst=RESET_ACTIVE then
  Compout_Sr <= (others => '0');   -- all bits to '0'
elsif Rising_edge(Clk) then
  Compout_Sr <= Compout_Sr(1 downto 0) & Compout;
  if Compout_Sr(2)='1' then
     -- do something
   end if;
end if;

This helps you eliminating effects of metastability (should be no
problem for a 8MHz clk anyway), and allows you to have stable signal
crossings between two timing domains.
You should use such technique for every asynchronous signal when
changeing clock domains.

bye Thomas


Article: 111016
Subject: Xilinx Virtex-4 Clock Multiplexer Inputs
From: "Elmo Fuchs" <maerchenprinz@arcor.de>
Date: Fri, 27 Oct 2006 08:36:20 +0200
Links: << >>  << T >>  << A >>
Hi all,

I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke 
the Virtex-II series they now offer the possibility to route various clock 
signals to several domains on the FPGA and select them locally by specific 
clock multiplexer inputs.
Because of the restricted amount of available pins on the device I selected 
(Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input 
on each side of the FPGA, thereby saving clock multiplexer inputs which I 
can use as normal GPIOs, and use an external clock multiplexer instead for 
my 3 clocks.
Has anyone made experience with such or similar solution? Has anyone used an 
external clock multiplexer device for frequencies up to 500 MHz, yet? Is 
there any recommendation which chip I could use for this application in 
terms of jitter, etc.? And by the way... is my approach advisable, at all?

Any comments are appreciated.

Regards Elmo 



Article: 111017
Subject: Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
From: "Antti" <Antti.Lukats@xilant.com>
Date: 27 Oct 2006 00:18:43 -0700
Links: << >>  << T >>  << A >>
Zara schrieb:

> I quit.
>
> A brand new project, with only a dcm, a debug module, 16K ram, an uart
> and  intc will not work (problems writing BRAM).
>
> Will continue using 8.1 for a long time, I suspect

quit? your life?

EDK 8.2 does work
I have done maybe over 50 EDK systems with 8.2
- all of them work

if your system doesnt there is something wrong
and you should figure out what it is, not quitting.

Antti


Article: 111018
Subject: Re: Jumps in FPGA implemented integrator
From: "Helen" <h.obrien@ic.ac.uk>
Date: 27 Oct 2006 00:23:06 -0700
Links: << >>  << T >>  << A >>

Thanks Thomas - I will try this!


Article: 111019
Subject: Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
From: Zara <me_zara@dea.spamcon.org>
Date: Fri, 27 Oct 2006 10:09:16 +0200
Links: << >>  << T >>  << A >>
On 27 Oct 2006 00:18:43 -0700, "Antti" <Antti.Lukats@xilant.com>
wrote:

>Zara schrieb:
>
>> I quit.
>>
>> A brand new project, with only a dcm, a debug module, 16K ram, an uart
>> and  intc will not work (problems writing BRAM).
>>
>> Will continue using 8.1 for a long time, I suspect
>
>quit? your life?
>
>EDK 8.2 does work
>I have done maybe over 50 EDK systems with 8.2
>- all of them work
>
>if your system doesnt there is something wrong
>and you should figure out what it is, not quitting.
>
>Antti


No, it was a figure of speech. Whta I really mean is that I will stop
investigation while I am completing the current phase of my project.
As soon as some 40something boarsd are delivered; I will resume
trying.

As a sapnish adage goes "Last to be lost is Hope" ;-)

Regards,

Zara

Article: 111020
Subject: Have you experience to program the APA series using FlashPro Lite?
From: "kypilop" <kypilop@gmail.com>
Date: 27 Oct 2006 01:26:51 -0700
Links: << >>  << T >>  << A >>
I have flashpro-lite programmer of actel. But, in use, very
uncomportable because i don't know how to solve the error..... Any one
have the error books?
This is the errors i faced...

programmer 'FPL31LPT1' : Scan Chain...
Error: programmer 'FPL31LPT1' : Signal Integrity Failure
       Integrity Check Pattern Not Found.
       Integrity Check Pattern :
       550FAAF000FF0000FFFF
       IrScan Error.
       TDO stuck at 0
       Chain Analysis Failed.
Error: programmer 'FPL31LPT1' : Data Bit length : 8272
Error: programmer 'FPL31LPT1' : Compare Data  :
0000............................00000
Error: programmer 'FPL31LPT1' : Scan Chain FAILED.
Error: Failed to run programming.

Well.... Do you know what is the problem and solution? Plz, let me know
your experiences...


Article: 111021
Subject: Re: Xilinx Virtex-4 Clock Multiplexer Inputs
From: "mkaras" <mkaras@CarouselDesign.com>
Date: 27 Oct 2006 01:33:31 -0700
Links: << >>  << T >>  << A >>

Elmo Fuchs wrote:
> Hi all,
>
> I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke
> the Virtex-II series they now offer the possibility to route various clock
> signals to several domains on the FPGA and select them locally by specific
> clock multiplexer inputs.
> Because of the restricted amount of available pins on the device I selected
> (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input
> on each side of the FPGA, thereby saving clock multiplexer inputs which I
> can use as normal GPIOs, and use an external clock multiplexer instead for
> my 3 clocks.
> Has anyone made experience with such or similar solution? Has anyone used an
> external clock multiplexer device for frequencies up to 500 MHz, yet? Is
> there any recommendation which chip I could use for this application in
> terms of jitter, etc.? And by the way... is my approach advisable, at all?
>
> Any comments are appreciated.
>
> Regards Elmo

What I find amazing is that you feel the need to sacrifice a chip's
normal clock architecture just for the sake of gaining a few more I/O
pins. If you are so tight on your design fit that you are approaching
nearly 100% I/O utilization on the FPGA then you better begin looking
at another approach.

First off let me describe the issues of designing to the limit of a
part. It is always wise to reserve some number of I/O pins on a design.
These are needed for several very important reasons. One is the need to
allow for some additional expansion in case you discover the need for
bring a bit more of the outside world in or to bring out some controls
for other devices or logic. With new designs it is very often that even
with the best design intentions one can end up overlooking the need for
additional stimulous going in or status coming out. Second there the
the huge benefit of having some extra I/Os on test points that you can
temporarily connect into internal parts of the FPGA circuit to support
the debug and design validation process. Big FPGAs with lots of complex
embedded circuitry can be a challenge to debug and the visibility pins
will be a godsend if and when you need them. Lastly there is a common
habit formed by FPGAs that once you lock the pins and commit to the PC
board connectivity subsequent changing of the internal logic definition
in a big way can sometimes make it next to impossible to keep the same
pin allocation. A few spare pins on each side or within each I/O block
of the chip can often allow a re-fit to work if you free one or two
I/Os from their previously locked pins.

When considering how to move away from a design that is targeting
nearly 100% utilization you can consider a number of approaches. Look
at partitioning the design in a manner that you could put it into pair
of smaller devices. On the other hand there is also the possibility to
move to a larger FPGA device as well. A third thing to look at is if a
considerable number of I/O pins can be saved by using some simple fixed
logic devices at the periphery of the chip. A simple example is the
parallel to serial conversion strategy that could be implemented with
cheap shift registers to support many slow GPIOs with a few I/O pins at
the FPGA. It is relatively easy to design FPGA logic that can free run
a shift in or shift out process to keep the external GPIO states in
synch with internal nodes with a modest latency.

Good Luck
- mkaras


Article: 111022
Subject: Re: Have you experience to program the APA series using FlashPro Lite?
From: Alan Myler <amyler@eircom.net>
Date: Fri, 27 Oct 2006 09:46:44 +0100
Links: << >>  << T >>  << A >>
kypilop wrote:

> I have flashpro-lite programmer of actel. But, in use, very
> uncomportable because i don't know how to solve the error..... Any one
> have the error books?
> This is the errors i faced...
> 
> programmer 'FPL31LPT1' : Scan Chain...
> Error: programmer 'FPL31LPT1' : Signal Integrity Failure
>        Integrity Check Pattern Not Found.
>        Integrity Check Pattern :
>        550FAAF000FF0000FFFF
>        IrScan Error.
>        TDO stuck at 0
>        Chain Analysis Failed.
> Error: programmer 'FPL31LPT1' : Data Bit length : 8272
> Error: programmer 'FPL31LPT1' : Compare Data  :
> 0000............................00000
> Error: programmer 'FPL31LPT1' : Scan Chain FAILED.
> Error: Failed to run programming.
> 
> Well.... Do you know what is the problem and solution? Plz, let me know
> your experiences...
> 


I've had similar symptoms with Flashpro (not -Lite) when the APA was
dead or when there was a physical disconnect on the board between the
Flashpro header and the JTAG pins on the APA (error in pcb schematic).

Can you try another board?




Article: 111023
Subject: Re: Survey on Quartus SOPC/Nios-II
From: "Chris" <nospam@nospam.com>
Date: Fri, 27 Oct 2006 01:59:09 -0700
Links: << >>  << T >>  << A >>
> Antti is correct, you CAN build an internal ring oscillator based on
> stacked inverters for a coarse frequency oscillator inside the XP or
> EC/ECP type devices.  This is a proven method that has worked at
> Lattice and at other users. XO and ECP2/M device families have built-in
> oscillator based on the configuration oscillator that is accessable
> from the FPGA fabric after configuration.

Yes I saw that the XO does have an internal osc.  That is good.  But the
XO2280 has 1/3 the RAM as the 3E-100.   Not sure the XO2280 has enough to do
what I need.  I need 32bit wide True Dual Port.  That burns up 2 banks.  The
3E-100 only needs one bank.  Not sure I can get the instruc space that I
need using a Micro8 on the XO2280.  I can run 3 PicoBlaze on the 3E-100 no
problem.

> For Flash write back both options are available -- PERSISTENT=ON for
> sysConfig port and through JTAG.

Yes that is what I thought too, but what good is it since the local FAE told
me there is no spare flash space.  If there is spare flash area for user
data, please let me know.  The datasheet gives little info on this.

Thanks,  Chris.



Article: 111024
Subject: Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
From: "Tim" <tim@rockylogiccom.noooospam.com>
Date: Fri, 27 Oct 2006 11:13:31 +0100
Links: << >>  << T >>  << A >>
Zara wrote

> As a sapnish adage goes "Last to be lost is Hope" ;-)

It's Pandora. When she opened the box all the misfortunes of mankind flew 
out, leaving only Hope. Of course, you can argue that hope (9.1?) is the 
worst of all evils ;-)





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