Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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, JohnArticle: 61701
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, ChristianArticle: 61702
<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, KenArticle: 61703
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, ChristosArticle: 61704
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
> |> 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. ArthurArticle: 61706
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: 61707I 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? ThanksArticle: 61708
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.fpgaArticle: 61709
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, 1759Article: 61710
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: 61711Assaf 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 FAXArticle: 61712
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 FAXArticle: 61713
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, > > JohnArticle: 61714
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 FAXArticle: 61715
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: 61716Austin - 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 ProvidenzaArticle: 61717
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
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 ProvidenzaArticle: 61719
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
"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
???? 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 FAXArticle: 61722
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? > > JakeArticle: 61723
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:
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