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 61700

Article: 61700
Subject: Re: MICROBLAZE: Using external instruction memory
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 09 Oct 2003 17:08:52 +1000
Links: << >>  << T >>  << A >>
arkaitz wrote:
> Thanks John,
> 
> Now, where can I find some information related to the "elf" extension
> file? If I'm not wrong it's used in Linux, isn't it?

Yes - it's the standard object file format used by Gnu-based compilers (GCC)

> Just another question: I've been looking to the MicroBlaze's manual
> but I haven't found anything about "mb-objcopy". Is it in the manual?

No - it's just part of the gnu tools distributed in EDK.  Get a login on 
a linux box and do "man objcopy" - mb-objcopy is just the cross-platform 
version.  mb-objcopy --help will probably tell you something too.

www.gnu.org has an excellent documentation section - lots and lots of 
details about the linkers and compilers and so on - since mb-gcc and 
friends are direct descendants, 99.99% of that info is still highly 
relevant and useful.

Regards,

John


Article: 61701
Subject: Quartus, JTAG, Programming Hardware
From: Christian Kramer <RemoveThis_chr_kramer@web.de>
Date: Thu, 09 Oct 2003 09:43:33 +0200
Links: << >>  << T >>  << A >>
Hi!

I am using three CPLDs in my design. Each one has its own JTAG 
connector, an I have three Byteblasters connected to LPT1-LPT3 on my PC.
Is there any way to save the configuration, which hardware is to be used 
for programming in the .cdf-file for each design?

When I reopen the .cdf-files the programming-hardware is always the last 
one used - even if it was used in an different project.

Thanks,
Christian



Article: 61702
Subject: Re: Xilinx dedicated multiers vs multipliers in slice fabric
From: "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk>
Date: Thu, 9 Oct 2003 09:31:07 +0100
Links: << >>  << T >>  << A >>
<snip>

> 3: Use of the BlockRAMs.  Since the BlockRAMs and multipliers share
> interconnect, there are limits on when they can be used
> simultaneously.
>
> 4: Pipelined, throughput-optimized performance.  The fixed multipliers
> are unpipelined or single-stage, a LUT multiplier can be much more
> finely pipelined (higher thorughput).

Ok - it is my understanding that there are registers just before and just
after the dedicated multipliers that can be used to speed them up.

But what you are saying is that the LUT multipliers will have a higher max
MHz when both solutions are as pipelined as they can be?

Thanks for your time,

Ken



Article: 61703
Subject: Quartus II simulation question.
From: "Christos" <chris_saturnNOSPAM@hotmail.com>
Date: Thu, 9 Oct 2003 11:39:16 +0200
Links: << >>  << T >>  << A >>
Hi all,

In the vector waveform file that I am creating to enter the inputs for my
simulation I can also enter the outputs and the registers that I would like
to be recorded.
There using the node finder I can enter some combinatorial signals that I
would like to observe.
But after the simulation those signals have been omitted and the warning has
been given :
"Warning: Ignored node in vector source file. Can't find corresponding node
name CFCstatus in design."

So, can someone please explain me how I can check those internal signals?
For example the output of a lpm_compare block which feeds an input of a
counter without inserting in the middle a output pin? (you don't have to use
this example of course).

I thing it doesn't make any difference the version but I am using Quartus II
3.0.

Thanks,
Christos



Article: 61704
Subject: Where is the logic?
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 09 Oct 2003 10:06:52 GMT
Links: << >>  << T >>  << A >>
The following code:

module PROBLEM
(
 input  wire CLK,
 input  wire [9:0] A,
 input  wire [9:0] B,
 output reg  [9:0] OUT
);
wire [9:0] xor2;
XOR2 XOR2_0 (.O(xor2[0]), .I0(A[0]), .I1(B[0]));
XOR2 XOR2_1 (.O(xor2[1]), .I0(A[1]), .I1(B[1]));
XOR2 XOR2_2 (.O(xor2[2]), .I0(A[2]), .I1(B[2]));
XOR2 XOR2_3 (.O(xor2[3]), .I0(A[3]), .I1(B[3]));
XOR2 XOR2_4 (.O(xor2[4]), .I0(A[4]), .I1(B[4]));
XOR2 XOR2_5 (.O(xor2[5]), .I0(A[5]), .I1(B[5]));
XOR2 XOR2_6 (.O(xor2[6]), .I0(A[6]), .I1(B[6]));
XOR2 XOR2_7 (.O(xor2[7]), .I0(A[7]), .I1(B[7]));
XOR2 XOR2_8 (.O(xor2[8]), .I0(A[8]), .I1(B[8]));
XOR2 XOR2_9 (.O(xor2[9]), .I0(A[9]), .I1(B[9]));

always @(posedge CLK) OUT <= xor2;

endmodule


... produces interesting results.  The tools run without a hitch, no error,
and no reports of logic being optimized out.  However, if you look at the
end-product in the Floorplanner the LUTs that are supposed to be there are
nowhere to be found.  Then, it gets interesting, go over to FPGA Editor and
every bit of logic is there as you would expect.  What gives?

This excercise started out as an attempt to build an RLOC'd parameterized
adder.  Logic would not show-up in the Floorplanner so, eventually, I
reduced it to just an XOR clocking out to see what was wrong.

Using ISE6.1i, SP1.  Device is XC2V1000-FG456

...this is turning out to be one hell of a frustrating week!


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"








Article: 61705
Subject: Re: Installing Xilinx 6.1 under Linux
From: "Arthur Sharp" <arthur@nospam.com>
Date: Thu, 9 Oct 2003 22:20:30 +1000
Links: << >>  << T >>  << A >>
> |> The problem is that, in my setup script, it sets the variable WUHOME as
> |> /media/cdrom/data and then it fails, not surprisingly since
> |> /media/cdrom/data is empty !!!
>
> The shell trace shows the same behavior for "my" version... But I think I
know
> why it fails: If I try to start the setup as root, I get the same error.
It
> works as a "regular" user... The cause seems to be a problem with the
> X-server access of the windu-stuff.

Unfortunately, I was doing it as a regular user, not root. I haven't tried
root,
maybe it'll work :-)

Thanks for your help.

Arthur



Article: 61706
Subject: Re: More RPM / RLOC fun
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Oct 2003 08:59:06 -0400
Links: << >>  << T >>  << A >>
I guess to each his own.  Seems you have the placement knowledge problem either way if
stuff is being placed somewhat randomly.  With HSETs, the hierarchy is hidden whenyou get
to the floorplanner.  The RPM gets flattened in the floorplan view and moves as one large
RPM block.  When there are two sets in one block, I use HU_sets, but I also avoid doing
that.  If that happens, it tells me that I probably have not used hierarchy correctly.  My
bottom level entities are simple things like adders, delay queues, registers, etc.  The
stuff that does not have a carry chain has generics on it to set the row and column pitch
so that I can set up the layout in a regular array.  Where it is not a regular array, I
use smaller instances in the next level up.

Goran Bilski wrote:

> Hi Ray,
>
> This is the reason I choose U_SET.
>
> 1. Not everything in a level might not go to the same SET but with H_SET
> EVERYTHING is forced into
>     the same set.
> 2. I need very different floorplanning for different architectures.
> 3. I don't want to have my design hierarchical force to be the floorplan
> hierarchical.
>     I like to divide my design into functional block independent of the
> floorplanning.
>     ex. I have all my register file bits in the same vhdl file even if
> they are spread out in the floorplanning
>     In one of the leafs in a branch of my design, I might need due to
> minimizing the routing delay from a primitive
>     to another primitive in another leaf in a total different branch of
> the design.
>     With H_SET, it a nightmare since I have to know all the relative
> placement of all H_SET
>      from the first leaf to the top and then from the top to the another
> leaf.
>      Whenever I change any of the relative placements, I have to check
> all the cross placement to see
>       if they are effected.
>      With the U_SET approach and all RLOC values in one function, I just
> need to change a value in the function and
>       the placement is changed.
>
> Göran
>
> Ray Andraka wrote:
>
> >Goran,
> >
> >I can't understand why you are working in flatland.  First off, it creates a bunch of
> >
> >extra typing.  If you use H_SETs, there is no need to explicitly declare each set, it
> >
> >is done automatically  for you, and then you can piece together the RLOCs without
> >having to pass placement information into your lower levels.  Using USETs means
> >you need a unique name for each instance of a macro, plus you need to compute the
> >offsets for each and manually (in your code) add them to the RLOCs before applying
> >the RLOCs.  With HSETs, that is all done automatically, so each module is truely
> >standalone.  That means with HSETs you can compile parts of the code and then
> >instance it as a black box in a higher level.  I'm not sure of the motivation for
> >handling
> >all the floorplanning in one place either.  Seems to me that the floorplanning should
> >
> >be with the module, as your layout normally will be the same regardless of where
> >you put it. (I do have some with alternative layouts such as swapped horizontal, in
> >which case I use generics to control the layout.  A simple case is whether the origin
> >
> >is at the top or the bottom of a carry chain, which is illustrated partly below).
> >
> >I handle the different RLOC strings for RC or XY grids by creating both strings and
> >then using a pickstring function to select which gets used. Pickstring has an
> >argument for the family
> >(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
> >string.  In the
> >case of unplaced, it returns the null string.  For 1 it returns the RC string, and
> >for 2 or more the xy string
> >For example:
> > constant rc_str : string := "R" & itoa( origin -(i/2))  & "C0" & ".S" & itoa(slice
> >mod 2);
> > constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
> > constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
> > signal l,d,qr,qs: STD_LOGIC;
> > attribute BEL of U1:label is bel_lut(i mod 2);
> > attribute RLOC   of U1 : label is rloc_str;
> >
> >
> >Is there some advantage of doing this flat that has totally escaped me?
> >
> >
> >--
> >--Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930     Fax 401/884-7950
> >email ray@andraka.com
> >http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> >  temporary safety deserve neither liberty nor safety."
> >                                          -Benjamin Franklin, 1759
> >
> >
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61707
Subject: Initilization of block rams to create rom
From: "Stephen Lohning" <stephen.lohning@oxnee.com>
Date: Thu, 9 Oct 2003 23:07:39 +1000
Links: << >>  << T >>  << A >>
I wish to create a rom for Virtex2 xilinix part.
Which is better/ works using attributes INIT_00 etc in the code
or puting them in the configuration  file.
The code will be written in vhdl.
Any body seen any examples of this being done?
Thanks



Article: 61708
Subject: Re: Installing Xilinx 6.1 under Linux
From: fmadlener@gmx.de (Felix Madlener)
Date: Thu, 9 Oct 2003 13:15:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Arthur Sharp <arthur@nospam.com> wrote:
> Hi,
> 
> I've got Suse 8.1 on my machine and I'm trying to install Xilinx 6.1 sw.
> Admittedly they recommend RedHat, but I can't change the distribution just
> like that.
> 
> Anyway, I follow the instructions:
> cd /media/cdrom
> ./setup
> 
> I get the following error message :
> Wind/U Error (294): Unable to install Wind/U ini file
> (/media/cdrom/data/WindU).
> See the Wind/U manual for more details on the ".WindU" file and the "WINDU"
> environment variable.

We got the same error with Debian. The problem was that the setup
tries to connect to the X-Server with TCP-sockets. However most
distributions have disabled this function. Search the line where your
X server is started and remove the "-nolisten tcp" option. And think
about some firewalling because it's a potential security leak ;-)

> After a while, a window appears saying "Warning : no data files were found
> on CD image.
> The installation will be terminated".
> When I press ok, the installation finishes.

I don't know that error, perhaps it disappears when WindU works.

CU
Felix

-- 
"Let's face it.  The FPGA companies are really software 
companies that happen to have very expensive dongles."

Ray Andraka in comp.arch.fpga

Article: 61709
Subject: Re: Compact FIR filters with multiplier blocks?
From: Tero Rissa <no_spam@nowhere.invalid>
Date: Thu, 9 Oct 2003 13:23:50 +0000 (UTC)
Links: << >>  << T >>  << A >>

I went around the irregularity issue by having sub-multiplier 
block architecture that has have fixed interface to the routing 
and have fixed (yet reasonable) area. Therefore, when the 
coefficients are changed, no place and route is required and 
the latency remains the same (unless you change the number taps). 
The generation of coefficients can done at reconfiguration time 
thanks to symmetry in the FPGA used (Atmel 40K40). Naturally, 
there is the problem of hassling with run-time reconfiguration 
and everything that comes with that...

As part of this work we looked also into common subexpression 
sharing in that particular FPGA family and found it very unlikely 
that benefits could be obtained with similar multiplier-block 
architecture. This is mainly due the fact that it is different 
story to be able to generate the most useful common subexpressions 
that it is to really use them before the routing becomes congested.

http://www.doc.ic.ac.uk/~tpr/papers/rissa_FPT02.pdf

T.Rissa

tpr at doc ic ac uk

Ray Andraka <ray@andraka.com> wrote:
> I agree the multiplier block style filters are more efficient area-wise.  It
> sounds like you have addressed the irregularity issues by using a program
> to do the generation, which I think is pretty much a necessity.  As I thought
> I alluded to, the biggest problem with multiplier block filters is that the
> layout/size is not a constant if you change the coefficients.  This means that
> the fiter coefficients have to be constant and known earlier in the design
> cycle, and necessitates a rerun of synthesis, place and route for any filter
> changes.  Depending on the implementation, it may also mean a change in the
> filter's pipeline latency.  These factors can make them difficult to use on
> some projects.  The filters typically used in my projects often need to be
> adjusted by the customer or late in the project to accommodate minor
> requirements changes.  I prefer to use a filter with reloadable coefficients
> for that reason.



> Ken wrote:

>> Ray,
>>
>> I sent this to Michael via email and he suggested the group would be
>> interested also...
>>
>> My PhD (now drawing to the end) has been on implementing full-parallel
>> Transpose FIR filters using multiplier blocks that you mention (I use
>> techniques/algorithms that exceed the efficiency of CSD in terms of FPGA
>> area).
>>
>> The upshot of my work is that I have written a C++ program that will
>> generate RTL VHDL given the quantised filter coefficients, the type of
>> filter required (singlerate, interpolation, decimation etc.) and the
>> appropriate parameters (input width, signed/unsigned input, number of
>> channels, rate-change factor etc.)
>>
>> The VHDL my program generates exceeds the functionality (at a lower
>> cost) of that provided by Xilinx's Distributed Arithmetic core and Altera's
>> FIR Compiler (also DA).  In fact, my program allows interpolation and
>> decimation factors up to the number of filter coefficients and any number of
>> data channels (for interpolation/decimation filters also).
>>
>> The main point is that, once synthesised and mapped to a specific FPGA, the
>> filters my program generates require far less FPGA area (slices/logic cells)
>> than those generated using Distributed Arithmetic.  The critical path in my
>> filters is just the longest adder carry chain so very high speeds are
>> possible.  E.g. 154MHz for a singlerate filter (25 bit output) in a Xilinx
>> xc2v3000-fg676-5 - obviously the speed will depend on the device
>> family/speed grade and the longest carry chain.  The facility for multiple
>> channels in interpolation/decimation filters (not supported by Xilinx)
>> allows lower than full-parallel sampling rates to be efficiently processed
>> in one filter.
>>
>> As Michael points out in his post, this technique would be very suitable for
>> a
>> Xilinx Spartan-IIE and indeed any FPGA - there are many cases where these
>> filters would be useful even on devices with dedicated multipliers (when
>> they are all in use for example!  ;-)   ).
>>
>> You can find out more at http://www.dspec.org/rsg.asp - there are also
>> datasheets here that provide comparisons with Xilinx and Altera and
>> demonstrate the output of another application (written in java) that
>> generates schematic representations of the filters for use in reports,
>> meetings and thesises!  :-)
>>
>> I hope this information is of use to you - please contact me if you have any
>> questions,
>>
>> Thanks for your time,
>>
>> Ken
>>
>> --
>> To reply by email, please remove the _MENOWANTSPAM from my email address.
>>
>> "Ray Andraka" <ray@andraka.com> wrote in message
>> news:3F54F936.5E694FD1@andraka.com...
>> > The problem with the multiplier block approach is that the
>> > construction is predicated on the specific coefficients.  As
>> > a result it is considerably harder to use for an arbitrary
>> > set of coefficients.  It may reduce area over a straight FIR
>> > filter running at the same clocks per sample, but at a
>> > considerable cost in design time and flexibility.  You also
>> > give up regularity in the structure, which may reduce the
>> > overall performance.   Essentially what the block multiplier
>> > and distributed arithmetic approaches are is a rearrangement
>> > of the bitwise product terms.  The mutliplier block takes
>> > advantage of duplicate terms by adding the inputs before
>> > they are multiplied by the term.
>> >
>> > Michael Spencer wrote:
>> >
>> > > Hello,
>> > >
>> > > Has anyone compared FPGA implementations of full-rate
>> > > digital FIR filters based on the use of Multiplier Blocks
>> > > vs. traditional FIRs with constant coefficient
>> > > multipliers? By full rate, I mean: one output result per
>> > > clock cycle and no interpolation or decimation.
>> > >
>> > > For anyone not familiar, a multiplier block is a network
>> > > of shifters and adders that performs multiplications by
>> > > several coefficients efficiently by exploiting common
>> > > sub-expressions. The multiplier block can be exploited in
>> > > FIR filters by transposing the standard filter so that the
>> > > products of all the coefficients with the current
>> > > input-sample are required simultaneously.
>> > >
>> > > Also, by representing the coefficients in the
>> > > Canonical-Signed-Digit number system (a small number of
>> > > +1 and -1's) along common sub-expression sharing the
>> > > multiplier block can get even smaller.
>> > >
>> > > For example, the multiplier block for a 100 tap FIR filter
>> > > (fp=0.10 and fs=0.12) can be realized with only 61 adds
>> > > (zero explicit multiplications). See filter example #4 in
>> > > "FIR Filter Synthesis Algorithms for Minimizing the Delay
>> > > and the Number of Adders,"
>> > > http://ics.kaist.ac.kr/~dk/papers/TCAD2001.pdf
>> > > If the adder depth is constrained to a maximum of four,
>> > > then the authors' algorithm can do the multiplier block in
>> > > 69 additions.
>> > >
>> > > It would seem that this approach would be very efficient
>> > > in a target such as the Xilinx Spartan-IIE (with no
>> > > dedicated multipliers).
>> > >
>> > > Another question: If we only need one result per K clock
>> > > periods (K ~= 1000 for audio applications), could a
>> > > multiplier block approach realized with, say, bit-serial
>> > > addition be more efficient than some other approach such
>> > > as distributed arithmetic?
>> > >
>> > > Comments welcome. Thanks.
>> > >
>> > > -Michael
>> > > ______________________
>> > > Michael E. Spencer, Ph.D.
>> > > President
>> > > Signal Processing Solutions, Inc.
>> > > Web: http://www.spsolutions.com
>> >
>> > --
>> > --Ray Andraka, P.E.
>> > President, the Andraka Consulting Group, Inc.
>> > 401/884-7930     Fax 401/884-7950
>> > email ray@andraka.com
>> > http://www.andraka.com
>> >
>> >  "They that give up essential liberty to obtain a little
>> >   temporary safety deserve neither liberty nor safety."
>> >                                           -Benjamin
>> > Franklin, 1759
>> >
>> >

> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com

>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759



Article: 61710
Subject: Re: Quartus, JTAG, Programming Hardware
From: "Subroto Datta" <sdatta@altera.com>
Date: Thu, 09 Oct 2003 13:52:13 GMT
Links: << >>  << T >>  << A >>
Hi Christian,

    The Hardware information is stored separately from the cdf, as it is a
function of the programmer not the chain. However your suggestion to have
multiple HW profiles is a good one, and I will pass it on.

- Subroto Datta
Altera Corp.

"Christian Kramer" <RemoveThis_chr_kramer@web.de> wrote in message
news:bm33hk$3vj$1@news.uni-stuttgart.de...
> Hi!
>
> I am using three CPLDs in my design. Each one has its own JTAG
> connector, an I have three Byteblasters connected to LPT1-LPT3 on my PC.
> Is there any way to save the configuration, which hardware is to be used
> for programming in the .cdf-file for each design?
>
> When I reopen the .cdf-files the programming-hardware is always the last
> one used - even if it was used in an different project.
>
> Thanks,
> Christian
>
>



Article: 61711
Subject: Re: Visualizing VHDL
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Oct 2003 09:53:10 -0400
Links: << >>  << T >>  << A >>
Assaf Sarfati wrote:
> 
> Kevin Kilzer <kkilzer.remove.this@mindspring.com> wrote in message news:<qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com>...
> > When you write VHDL (or Verilog for that matter), do you visualize a
> > schematic with wires, gates, flops, latches, muxes, etc., or do you
> > use some other way of thinking about it?
> >
> > Kevin
> 
> I never start writing HDL code until I have visualised the design. I don't
> visualise it in my head - I use a graphics program to draw and save the
> stuff (I use Visio).
> Browsing old design documentations, I'd say that a visualisation is a mix
> of drawing types:
> 
> Data path stuff is drawn as a path - busses are arrows, functions are
> circles, registers are rectangles.
> 
> Control and interface is a combination of state diagrams and annotated
> waveform diagrams (clock cycles, cause/event arrows and various comments).
> 
> For managing pipelines, I usually draw (or write with a spreadsheet program)
> a two-dimentional table, with time as one dimension (clock cycles) and
> the various pipeline stages as the other dimension.
> 
> I almost never visualise a design in schematic form - at the most, I see
> registers, muxes and a combinatorial logic "cloud".
> 
> Hope this helps.

I read all the other posts and this was the solution that is closest to
what I do.  I never think about the coding of the HDL until I have
already done all the planning of my design.  The planning involved
functionaly partioning which is just a drawing with a bunch of boxes
interconnected with arrows for signals.  Then I iteratively break those
boxes down into smaller boxes until I get to the point that I am showing
a fleshed out data path and/or I have the lowest level of my logic with
consists of symbols like registers, adders, muxes and control boxes
(state machines).  At this point my hardware is defined and I can start
to write code which describes this hardware.  

I design FPGAs the same way I design software.  I plan, modularize,
implement and finally test (or simulate in the case of FPGAs).  For
hardware my drawings are often just hand drawn.  If I want to keep them
for documentation, I use Visio.  

But I never code my HDL like I code software.  I use an HDL to describe
the hardware I want compared to software where I code to describe my
solution.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61712
Subject: Re: ....and he left with his marbles.....
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Oct 2003 10:09:55 -0400
Links: << >>  << T >>  << A >>
Brian,

You are pretty much wasting your breath.  There are always people in any
newsgroup who feel they own the truth and have a lock on reality. 
Trying to have a reasonable discussion can be very hard.  But that
effect can be magnified by the issues of posting in a public forum as a
representative of a company.  So don't expect to get the same type of
answers from an FAE in this venue that you would get from another
engineer or that you might get when discussing an issue in private.  

I know I have spent more of my time then I should trying to get
"straight" answers here after the real answer was already clear, even if
it had not been stated outright.  

But I do appreciate the info you have posted in this thread and the
light you have allowed to shine.  



Brian Davis wrote:
> 
> Austin,
> 
>  "Xilinx is always right" is your personal credo, as evidenced
> by this thread and many others.
> 
>  The next time you're about to post a sarcastic, condescending,
> knee-jerk response to a thread based soley on the fact that it
> is somehow critical of Xilinx's parts, tools, or customer support,
> stop to consider whether you can back up your post with an argument
> any more compelling than "because I said so".
> 
> Brian
> 
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > Brian,
> >
> > You are absolutely correct in everything you say*.
> >
> > Please do not bother to reply or acknowledge, as I am not worthy of your
> > attention.
> >
> > Austin
> >
> > *Note: "customer is always right"

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61713
Subject: Re: MICROBLAZE: Using external instruction memory
From: arkagaz@yahoo.com (arkaitz)
Date: 9 Oct 2003 07:11:33 -0700
Links: << >>  << T >>  << A >>
Thanks a lot.

But, I don't understand how can I execute an "elf" file that affects
only to the internal registers of MicroBlaze enabling the timer,
interrupts, etc. but when I create a "hello world" program which
contains only a "print" code-line it doesn't work.

Have you done a flash programmer. How have done it? Via XMD or Serial?

Thanks again.

John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bm30hp$fto$1@bunyip.cc.uq.edu.au>...
> arkaitz wrote:
> > Thanks John,
> > 
> > Now, where can I find some information related to the "elf" extension
> > file? If I'm not wrong it's used in Linux, isn't it?
> 
> Yes - it's the standard object file format used by Gnu-based compilers (GCC)
> 
> > Just another question: I've been looking to the MicroBlaze's manual
> > but I haven't found anything about "mb-objcopy". Is it in the manual?
> 
> No - it's just part of the gnu tools distributed in EDK.  Get a login on 
> a linux box and do "man objcopy" - mb-objcopy is just the cross-platform 
> version.  mb-objcopy --help will probably tell you something too.
> 
> www.gnu.org has an excellent documentation section - lots and lots of 
> details about the linkers and compilers and so on - since mb-gcc and 
> friends are direct descendants, 99.99% of that info is still highly 
> relevant and useful.
> 
> Regards,
> 
> John

Article: 61714
Subject: Re: Input capacitance
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 09 Oct 2003 08:03:45 -0700
Links: << >>  << T >>  << A >>
Rick,

Now you, I can have a discussion with.

Anything that is unlcear or still in doubt about the input C issue that I might explain?

After all, many posts ago I explained why the C was what it was, how it is documented, and made
comment that there are ways to deal with it, but Brian just seems to be stuck, and is unwilling to
grant that there are ways to make it work just fine, and that perhaps there are valid reasons why
the C input can not be 0.5pF.

Do you have, or have you run an IBIS simulation of the ORCA-4 IOB and looked at how its input C
affects the signal?

Austin

rickman wrote:

> Brian,
>
> You are pretty much wasting your breath.  There are always people in any
> newsgroup who feel they own the truth and have a lock on reality.
> Trying to have a reasonable discussion can be very hard.  But that
> effect can be magnified by the issues of posting in a public forum as a
> representative of a company.  So don't expect to get the same type of
> answers from an FAE in this venue that you would get from another
> engineer or that you might get when discussing an issue in private.
>
> I know I have spent more of my time then I should trying to get
> "straight" answers here after the real answer was already clear, even if
> it had not been stated outright.
>
> But I do appreciate the info you have posted in this thread and the
> light you have allowed to shine.
>
> Brian Davis wrote:
> >
> > Austin,
> >
> >  "Xilinx is always right" is your personal credo, as evidenced
> > by this thread and many others.
> >
> >  The next time you're about to post a sarcastic, condescending,
> > knee-jerk response to a thread based soley on the fact that it
> > is somehow critical of Xilinx's parts, tools, or customer support,
> > stop to consider whether you can back up your post with an argument
> > any more compelling than "because I said so".
> >
> > Brian
> >
> > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > > Brian,
> > >
> > > You are absolutely correct in everything you say*.
> > >
> > > Please do not bother to reply or acknowledge, as I am not worthy of your
> > > attention.
> > >
> > > Austin
> > >
> > > *Note: "customer is always right"
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 61715
Subject: Why no synthesis?
From: andres.vazquez@gmx.de (Vazquez)
Date: 9 Oct 2003 08:08:43 -0700
Links: << >>  << T >>  << A >>
Dear Sir or Madame,

I have the following VHDL code for the description of 
a RAM structure with some logic built around.

Why does QuartusII not synthesize it as a RAM structure using
the memory bits of Cyclone?

Thank you for your help.

Kind regards

Andrés Vázquez
G&D System Development


LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

PACKAGE test_ram_package IS

   CONSTANT ram_width : INTEGER := 8;
   CONSTANT ram_depth : INTEGER := 2048;
   
   TYPE ram IS ARRAY(0 to ram_depth - 1) of
std_logic_vector(ram_width-1 downto 0);
   SUBTYPE address_vector IS INTEGER RANGE 0 to ram_depth - 1;

   CONSTANT xram_width : INTEGER := 11;
   CONSTANT xram_depth : INTEGER := 16;
   
   TYPE xram IS ARRAY(0 to xram_depth - 1) of
std_logic_vector(xram_width-1 downto 0);
   SUBTYPE xaddress_vector IS INTEGER RANGE 0 to xram_depth - 1;
   
END test_ram_package;

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_unsigned.ALL;
USE work.test_ram_package.ALL;


ENTITY test_inferred_ram IS
   PORT
   (  reset  : IN   std_logic;
      clock1 : IN   std_logic;
      clock2 : IN   std_logic;
      data   : IN   std_logic_vector(7 downto 0);
      write_address: IN  address_vector;
      read_address:  IN  xaddress_vector;
      write_xaddress : IN xaddress_vector;
      xdata			 : IN std_logic_vector(10 downto 0);
      we     : IN   std_logic;
      q      : OUT  std_logic_vector(7 downto 0)
   );
END test_inferred_ram;

ARCHITECTURE rtl OF test_inferred_ram IS

  
   SIGNAL ram_block : RAM;
   SIGNAL xram_block : XRAM;
   SIGNAL read_address_reg : xaddress_vector;
   SIGNAL writing : std_logic;
   
BEGIN

   PROCESS(clock1, reset)
   BEGIN
   IF reset='1' then
      writing <='0';
   ELSIF clock1'event and clock1='1' then
         writing <= writing;
         IF we = '1' and writing='0' THEN
             writing <= '1';
         ELSIF we='1' and writing='1' THEN
             writing <= '0';
         END IF;
   END IF;
   END PROCESS;

   PROCESS (clock1)
   BEGIN
      IF clock1='1' and clock1'event then
         ram_block  <= ram_block;
         xram_block <= xram_block;
            
         IF we = '1' and writing='0' THEN
            ram_block(write_address) <= data;
	    xram_block(write_xaddress) <= xdata;
			
	 ELSIF we='1' and writing='1' then
	    ram_block(write_address) <= data;
	    xram_block(write_xaddress) <= xdata;
			
         END IF;

      END IF;
   END PROCESS;
END rtl;

Article: 61716
Subject: Re: syncing the CLK0 outputs of two DCMs if they use CLKIN_DIVIDE_BY_2
From: johnp3+nospam@probo.com (John Providenza)
Date: 9 Oct 2003 08:22:17 -0700
Links: << >>  << T >>  << A >>
Austin -

I'm trying to generate three phase adjustable clocks, although my example
only talks about 2 DCMs for two clocks.

The current design uses one variable phase shift DCM to divide down
the input 500MHz (using CLKIN_DIVIDE_BY_2) into a phase adjustable 250MHz. 
Incoming data is coming in sync'd to the 500MHz clock, so this phase 
adjustment lets me tweak the stup/hold time for the incoming data.

In the current design, 2 other DCMs are cascaded off the "primary" DCM
to allow us to create 2 phase adjustable clocks.  No clock manipulation,
just CLKIN leading to CLK0 and CLK180.  We need to adjust these two
phases independently, thus 2 DCMs for these.

Our timing margins are tight, and I'd like to avoid cascading the
jitter from the primary DCM into the 2 secondary DCMs.

I find little information about how the CLKIN_DIVIDE_BY_2 option
effects timing, etc, so any insight is appreciated.

Thanks for your help.

Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F8480BA.4ACBFDD@xilinx.com>...
> John,
> 
> There is no way to synchronize two separate DCM CLKDV outputs in phase,
> nor is there a way to synchronize the CLKDV with the CLKFX phase (where
> they are both say dividing by 1/2) that we are aware of.
> 
> This is a deficiency that we realized, and are planning to fix in
> subsequent generations.
> 
> The logic that generates the sequence has no ability to be reset or
> strobed by a user logic signal to cause them to be in sync.
> 
> Just to help us, why do you do the same thing twice?  If you explain
> what you are doing, perhaps there is another way to do it?
> 
> Austin
> 
> 
> John Providenza wrote:
> 
> > If I have a 500MHz input clock feeding into two DCMs in a Virtex-II
> > with the CLKIN_DIVIDE_BY_2 option set on both of them....
> >
> > The CLK0 output of each of them should be 250MHz, but it seems
> > like they could come up 180 degrees out of phase.
> >
> > Is there any way to have the CLK0 outputs of the two DCMs
> > come up "in phase" without playing tricks with the CLKFB
> > signals between the two of them?
> >
> > Thanks
> >
> > John Providenza

Article: 61717
Subject: Re: Programmimg Altera serial configuration devices
From: "Eric Paillet" <epaillet@antwerpen.be>
Date: Thu, 9 Oct 2003 18:05:31 +0200
Links: << >>  << T >>  << A >>
Schematics (Protel) can be found on this site;

http://www.fuw.edu.pl/~gkasprow/

note that the schematics on the Altera website are for ByteblasterMV, not
ByteblasterII


"Simon Peacock" <nowhere@to.be.found> schreef in bericht
news:3f83e498$1@news.actrix.gen.nz...
> the schematics are on the Altera web site.
>
> "Ben Popoola" <b.popoola@ntlworld.com> wrote in message
> news:oVMgb.20449$4D.10223328@newsfep2-win.server.ntli.net...
> > Hi,
> >     Does anyone have a schematic for the Altera byteblaster II cable or
> > has anyone developed a programmer for programming the ALtera EPCS1/4
> > family of serial configuration devices.
> >
> >     I am designing a board and I want to design the programmer into the
> > system.
> >
> > Regards
> > Ben
> >
>
>



Article: 61718
Subject: Re: syncing the CLK0 outputs of two DCMs if they use CLKIN_DIVIDE_BY_2
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 09 Oct 2003 09:17:37 -0700
Links: << >>  << T >>  << A >>
John,

OK, got it.

The CLKIN_DIVIDE_BY_2 is a simple high speed toggle flip flop at the input of the DCM with a
dummy FF of identical delay in the clock FB path (to allow for proper phase alignement).

This FF has no ability to be synchronized (reset).

I agree that you do not want to cascade DCMs as the p-p jitter does accumulate as the square root
of the sum of the squares which takes away timing margin.

It is possible to multiplex two clocks by passing them to a BUFGMUX element, so taking the CLK0
and CLK180 to the BUFGNUX would allow selection of the "right" clock.  You would have to take the
CLKFB from the CLK2X back to the CLKIN, however (as if you make the CLK180 the feedback, it would
then make CLK180 = CLK0!!!).

Resetting the DCM repeatedly until you get the phase you want is also problematical, as it may
take many resets to accidentally get the "right" phase alignment from two separate DCMs.

Is it possible to change the design so that all you use is the phase shifted version of the
clocks?  The shifted CLK180 used instead of  the non-shifted CLK0?

Austin

John Providenza wrote:

> Austin -
>
> I'm trying to generate three phase adjustable clocks, although my example
> only talks about 2 DCMs for two clocks.
>
> The current design uses one variable phase shift DCM to divide down
> the input 500MHz (using CLKIN_DIVIDE_BY_2) into a phase adjustable 250MHz.
> Incoming data is coming in sync'd to the 500MHz clock, so this phase
> adjustment lets me tweak the stup/hold time for the incoming data.
>
> In the current design, 2 other DCMs are cascaded off the "primary" DCM
> to allow us to create 2 phase adjustable clocks.  No clock manipulation,
> just CLKIN leading to CLK0 and CLK180.  We need to adjust these two
> phases independently, thus 2 DCMs for these.
>
> Our timing margins are tight, and I'd like to avoid cascading the
> jitter from the primary DCM into the 2 secondary DCMs.
>
> I find little information about how the CLKIN_DIVIDE_BY_2 option
> effects timing, etc, so any insight is appreciated.
>
> Thanks for your help.
>
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F8480BA.4ACBFDD@xilinx.com>...
> > John,
> >
> > There is no way to synchronize two separate DCM CLKDV outputs in phase,
> > nor is there a way to synchronize the CLKDV with the CLKFX phase (where
> > they are both say dividing by 1/2) that we are aware of.
> >
> > This is a deficiency that we realized, and are planning to fix in
> > subsequent generations.
> >
> > The logic that generates the sequence has no ability to be reset or
> > strobed by a user logic signal to cause them to be in sync.
> >
> > Just to help us, why do you do the same thing twice?  If you explain
> > what you are doing, perhaps there is another way to do it?
> >
> > Austin
> >
> >
> > John Providenza wrote:
> >
> > > If I have a 500MHz input clock feeding into two DCMs in a Virtex-II
> > > with the CLKIN_DIVIDE_BY_2 option set on both of them....
> > >
> > > The CLK0 output of each of them should be 250MHz, but it seems
> > > like they could come up 180 degrees out of phase.
> > >
> > > Is there any way to have the CLK0 outputs of the two DCMs
> > > come up "in phase" without playing tricks with the CLKFB
> > > signals between the two of them?
> > >
> > > Thanks
> > >
> > > John Providenza


Article: 61719
Subject: Re: Floorplanning, Routing, FPGA Editor
From: "Barry Brown" <barry_brown@agilent.com>
Date: Thu, 9 Oct 2003 09:17:58 -0700
Links: << >>  << T >>  << A >>
Cannot answer your question, but thought I would bring to your attention
Xilinx XAPP636, "Optimal Pipelining of I/O Ports of the Virtex-II
Multiplier", in case you have not seen it.


"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:654hb.12932$ln2.10690@newssvr25.news.prodigy.com...
> In wanting to gain a greater understanding of routing options
(particularly
> as related to making floorplanning decisions) I find myself studing
devices
> in the FPGA Editor.  One question that occured to me is: How accurate a
> representation of the actual device layout does this tool provide?
Example:
>
> I'm looking at an XC2V100-4FG456.  I see that all embedded multipliers
have
> the I/O on the left side only.  Obviously all PIP's are on that side as
> well.  And there are four switch boxes that would seem to be the best
place
> to connect in/out of the multipler.  These switch boxes, in turn, would be
> the way to access the CLB's to the immediate left and right(through their
> own switch boxes).  Double interconnect lines seem to be the best possible
> path.
>
> Are these accurate representations of the geometry?  Accurate enough to
> decide, for example, that the path from a multiplier, through its switch
> box, via a double line, into the CLB to the left is slightly faster than
> using the same double line to go to the CLB on the right?
>
> Can any sort of assumptions be made in terms of ps per unit length from
what
> is seen in FPGA Editor?  What's the cost (delay wise) of going through a
PIP
> FET?
>
> Is this the wrong approach to making floorplanning decisions?
>
> Thanks,
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
>
>



Article: 61720
Subject: Re: Placing FF's Relative to RAMB4s (xilinx)
From: johnhandwork@mail.com (John_H)
Date: 9 Oct 2003 10:09:53 -0700
Links: << >>  << T >>  << A >>
"Morten Leikvoll" <m-leik@online.nospam> wrote in message news:<rI0hb.29235$os2.423755@news2.e.nsc.no>...
> My design places the FF in front of a RAMB4 on a VirtexE strangely. I have a
> macro and I place all the RAMB4's (6 in total, 2 in each macro) on one
> column by using for example LOC=RAMB4_R0C2:RAMB4_R7C2.
> Now I can not find an easy one to place close to their RAMs without
> specifying for each macro separately. I want to place the FF's in front of
> the data and address inputs as close as possible (delay wise) to these
> RAMB4's. Is there an easy way to do this?

This is fixed for Virtex-II(Pro) and Spartan-3 (see
http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf ) but you're
probably locked in to doing the flop and RAM placement manually for
Virtex-E.  I've gone down this path myself.

Look forward to using the new parts!

Article: 61721
Subject: Re: Input capacitance: "L" vs "X"
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 09 Oct 2003 10:40:39 -0700
Links: << >>  << T >>  << A >>
????

Further,  I downloaded the IBIS files (just broke down and logged into their site but I had to fill
out the long form with all of the required fields to get a username and password.....I just hate
that!  There should always be a way to get around the "salesman at the door" and go direct to what you
want!!!), and ran some simulations taking into account the package stub t-line (critically important
in this case, and described in our guidelines of how to do these simulations in our IBIS
documentation), and the results look acceptable (nice eye opening with pseudorandom data) for both
parts.  Theirs has more L and inductive kicks going on, and ours has more C, and less kicks.  I
naturally prefer our eye as it is far less "spikey" but that is probably my obvious bias.

So, the actual Cload of the input is buried in the IBIS spice2ibis tables (not listed in the file
anywhere), so one has to infer it by examining the responses.  The files do list the package C, which
is silly, as the package is a transmission line (which we have accounted for in our recommendations of
how to use IBIS).  Further, their estimation of Lpkg must be wrong, as it is 10-12nH, which is clearly
not possible (unless you do not care about high speed signals at all).  Of course, series 10nH will
sure make the input look less capactive! so maybe this is how they have "less C" by resonating it out.

Austin

Austin Lesea wrote:

> Rick,
>
> Now you, I can have a discussion with.
>
> Anything that is unlcear or still in doubt about the input C issue that I might explain?
>
> After all, many posts ago I explained why the C was what it was, how it is documented, and made
> comment that there are ways to deal with it, but Brian just seems to be stuck, and is unwilling to
> grant that there are ways to make it work just fine, and that perhaps there are valid reasons why
> the C input can not be 0.5pF.
>
> Do you have, or have you run an IBIS simulation of the ORCA-4 IOB and looked at how its input C
> affects the signal?
>
> Austin
>
> rickman wrote:
>
> > Brian,
> >
> > You are pretty much wasting your breath.  There are always people in any
> > newsgroup who feel they own the truth and have a lock on reality.
> > Trying to have a reasonable discussion can be very hard.  But that
> > effect can be magnified by the issues of posting in a public forum as a
> > representative of a company.  So don't expect to get the same type of
> > answers from an FAE in this venue that you would get from another
> > engineer or that you might get when discussing an issue in private.
> >
> > I know I have spent more of my time then I should trying to get
> > "straight" answers here after the real answer was already clear, even if
> > it had not been stated outright.
> >
> > But I do appreciate the info you have posted in this thread and the
> > light you have allowed to shine.
> >
> > Brian Davis wrote:
> > >
> > > Austin,
> > >
> > >  "Xilinx is always right" is your personal credo, as evidenced
> > > by this thread and many others.
> > >
> > >  The next time you're about to post a sarcastic, condescending,
> > > knee-jerk response to a thread based soley on the fact that it
> > > is somehow critical of Xilinx's parts, tools, or customer support,
> > > stop to consider whether you can back up your post with an argument
> > > any more compelling than "because I said so".
> > >
> > > Brian
> > >
> > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > > > Brian,
> > > >
> > > > You are absolutely correct in everything you say*.
> > > >
> > > > Please do not bother to reply or acknowledge, as I am not worthy of your
> > > > attention.
> > > >
> > > > Austin
> > > >
> > > > *Note: "customer is always right"
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 61722
Subject: Re: Spartan 3 pinout typo?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Thu, 9 Oct 2003 11:51:04 -0700
Links: << >>  << T >>  << A >>
You are correct.  The pin name and pin number in the data sheet is correct
as is the PQ208 footprint diagram.  As you described, the "_0" suffix
indicates that the pin belongs to I/O bank 0.

The mistake in the data sheet is strictly the bank indication in the pinout
table.  This is being corrected as I write and should be posted on
www.xilinx.com by no later than early next week.

Please accept my apologies for any inconvenience this might have caused.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC

"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0310082043.43d07d9a@posting.google.com...
> Hi folks-
>
> This isn't a significant note, but it seems there is a slight typo in
> the PQ208 package pinout for the Spartan 3.  Namely, Bank 1 includes
> the following that I believe should be listed as Bank 0:
>
> IO_L32N_0/GCLK7
> IO_L32P_0/GCLK6
>
> Although the suffix (_0) indicates they belong in Bank 0, I wanted to
> make sure they follow Bank 0 power supplies.  Also, the table at the
> end of the listing puts two GCLKs in Bank0 and two in Bank1, so that
> seems to reinforce the typo.
>
> Correction?
>
>    Jake



Article: 61723
(removed)


Article: 61724
Subject: Re: Quartus II simulation question.
From: tel2003@pathfinder.gr, tel2003@popmail.com, tel4@ath.forthnet.gr
Date: Thu, 09 Oct 2003 22:30:17 +0300
Links: << >>  << T >>  << A >>
PCB Quartus 2003

Altera Quartus II 2.2

       11 104

ALTERA QUARTUS II V3.0

       12 814

for more info, please send e-mail




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