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
On Feb 27, 1:02 pm, "AG" <a...@tb.fr> wrote: > Hi, > > I am trying to evaluate the power consumption of one of my design. But > the powerplay power analyser keeps telling me that the metric > confidency is low, because much of the toggle rates are vectorless > estimated (not computed based on real signal activities). > Though, all the toggle rates should come from my VCD file (value > change dump file) that I fill with Modelsim simulation. In the > powerplay power analyser's report, I can see each signal, and wether > its toggle rate has been estimated, or computed using the vcd file. > Here is an exemple of what I can read : > > mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0] > Combinational cell Simulation file1mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0]~feeder > Combinational cell Vectorless estimation > > I can trace back the first signal in my design, even in modelsim with > a > > find signals *pipe_1_z_oreg* > > But I don't find any signal with "feeder" in the name. If someone > could explain me why Quartus adds "ghost" signals with ~feeder at the > end, it would help. I have the same problem with RTL or gate level > simulation. Quartus 6.0 or 6.1. > > many thanks in advance, > > Alexandre. Hi Alexandre, The ~feeder cells are wire LUTs that Quartus introduces to allow either faster delivery of the data to the register or extra routing flexibility. In a gate level simulation, these extra node will be simulated, and you should get high confidence from the Quartus PowerPlay Power Analyzer. You should be able to see both the original signal and the ~feeder signals in the ModelSim simulation if you have compiled the gate level netlist (.vo or .vho). This netlist is output by the Quartus EDA Netlist Writer. In this gate-level flow, if all of the appropriate simulation signals are dumped to the VCD file (and you can use the Quartus generated TCL script for this purpose), you should obtain a high confidence rating in the PowerPlay Power Analyzer. If you are using RTL level simulation (where you are compiling your source code in ModelSim as opposed to using the gate-level netlist produced by Quartus), then these ~feeder signals will not be simulated. Actually, in an RTL level simulation, the Quartus PowerPlay Power Analyzer will only retrieve register and I/O signal activities, and the signal activities for the remaining combinational nodes will be filled in by vectorless estimation. This may be the issue you are having. I hope this helps, and please let me know if you have further questions, MeghalArticle: 116476
On Feb 24, 6:22 pm, Michael Gernoth <m...@gernoth.net> wrote: > Hello, > Please report back if this library is useful and works for you. > Maybe this helpsXILINXto decide that they do not need to use windrvr > for easy USB access, as most parts of my library are only there to > provide a compatible replacement for windrvr functions and are not > needed when directly accessing libusb from within an application > program. Brilliant! Seems to work for me. I can't test it fully right now because impact complains with "ERROR:iMPACT:583 - '2': The idcode read from the device does not match the idcode in the bsdl File." when I try to download to my ml403 board (which happens when I use the kernel driver too). But it correctly scans the JTAG chain and reports back the number/type of devices. I wasn't able to get it to work on an x86_64 system, but in a i386 chroot I had no problems. Have you passed on your utility to anyone at Xilinx? Cheers, g.Article: 116477
Under ISE 7.1, I did a simple UART module that has a "terminating character" generic, which is of type character. (When the receiver sees that terminating character, it asserts a "got terminator" output flag.) XST compiled it and the design works well. I moved to 9.1, and now XST hates the code and craps out: ========================================================================= * Design Hierarchy Analysis * ========================================================================= Analyzing hierarchy for entity <atesttop> in library <work> (architecture <toplevel>) with generics. BAUDDIV = 27 Analyzing hierarchy for entity <processor> in library <work> (architecture <proc>) with generics. BAUDDIV = 27 ERROR:Xst - Xst_HdlConst_Utility::BitVector2Const : invalid type (char). ERROR:Xst - Xst_Graph2Hdl::CreateConstSource : not implemented yet for no-type. ERROR:Xst:2683 - Unexpected error found while building hierarchy. --> ========================================================================= So ... why the step backwards? Arrrrrrgh. -aArticle: 116478
On Mar 9, 12:53 pm, "Andy Peters" <goo...@latke.net> wrote: > Under ISE 7.1, I did a simple UART module that has a "terminating > character" generic, which is of type character. (When the receiver > sees that terminating character, it asserts a "got terminator" output > flag.) XST compiled it and the design works well. > > I moved to 9.1, and now XST hates the code and craps out: > > ========================================================================= > * Design Hierarchy > Analysis * > ========================================================================= > Analyzing hierarchy for entity <atesttop> in library <work> > (architecture <toplevel>) with generics. > BAUDDIV = 27 > > Analyzing hierarchy for entity <processor> in library <work> > (architecture <proc>) with generics. > BAUDDIV = 27 > ERROR:Xst - Xst_HdlConst_Utility::BitVector2Const : invalid type > (char). > ERROR:Xst - Xst_Graph2Hdl::CreateConstSource : not implemented yet for > no-type. > ERROR:Xst:2683 - Unexpected error found while building hierarchy. > --> > ========================================================================= > > So ... why the step backwards? > > Arrrrrrgh. > > -a Replying to myself: OK, so I went through and removed all of the generics of type character, and in the module where the generic is actually used, I created a constant of type character. XST accepts that and the code built. So, once upon a time (7.1i) you could use a character type as a generic. Now (9.1i), you can't. Still a step backwards. Arrrrgh. -aArticle: 116479
Not being able to find the silly text on the Avnet website, I googled
and found this "Model Release"
MODEL RELEASE
For good and valuable consideration, receipt of which I hereby
acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
subsidiaries, assigns, licensees, and designees, the irrevocable right
to use my name, picture, likeness and/or photograph, and biographical
information (collectively the "Materials") in all forms and media now
known or hereafter developed, and in all manners, including composite
or distorted representations,
........and so on, ad nauseam.
I believe this has nothing to do with the seminar, but I cannot attack
the issue unless I can pinpoint it to the registration.
Which I have been unable to do.
Peter Alfke
On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
> As the Bard of Avon wrote in Henry VI:
> "JACK CADE.
> I thank you, good people:- there shall be no money; all shall eat and
> drink on my score; and I will apparel them all in one livery, that
> they may agree like brothers, and worship me their lord.
>
> DICK.
> The first thing we do, let's kill all the lawyers."
>
> Peter Alfke, speaking for himself ;-)
> =============================
> On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > I've been to these before and found them useful so I was registering to
> > attend until I came to this bit:
>
> > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > licensees, and design irrevocable right to use my name, picture, likeness
> > and/or photograph, and biography information ( collectively the "materials")
> > in all forms and media now known or hereby developed, and in all manners,
> > including composite or distorted representations, for marketing, trade,
> > editorial, and any other purposes whatsoever. I waive any right to approve
> > any uses that may be created in connection therewith, or the use to which
> > Materials may be applied. I agree that the Materials, the negatives, and
> > other originals shall constitute Avnet's sole property, with full right of
> > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > and designees, and all persons acting under its permission or anyone from
> > any and all claims whatsoever in connection with the use of the materials. I
> > have read the release and am fully familiar with its contents.
>
> > I choked on that so I'll stick with Lattice for another design or two.
>
> > Michael Kellett
>
> >www.mkesc.co.uk
Article: 116480Thanks for all your help. The problem has been fixed. The reason is that EDK didn't take the modified VHDL code. I need to remove the content in synthesis or implementation directory ( i removed both, but probably we just remove the content under the implementation directory). And another thing is the EDK won't copy the files under the directory.. user defined core....-> netlist to the implementation directory automatically as said in the manual. I I have to copy them manually. Probably I made another stupid mistake? Bill, I added the BUFG for the locked signal because I found in the Modelsim simulation, sometimes the generated clocks can't sample the locked signal at its first rising edge but sometimes they can. I used the following code in my program: NextStateProc : Process(ClkX3, DCMLocked) is begin if(DCMLocked='0') then CLKState <= CLK0; elsif(rising_edge(ClkX3)) then CLKState <= NextClkState; end if; end process NextStateProc; There are other DCMs in my system to generated different clock frequency and use such kinds of code for different states. They are all synchronized. Although the generated clock shouldn't be able to sample locked as high at its first rising edge because locked signal is also synchronized with the input clock as said in the manual, sometime they can. So I add the global buffer to solve the problem and it worked. Daniel said something about "instantiating costs a few extra lines but after that, you'll never have to worry about them mysteriously disappearing again.". I am sorry I don't understand how to do the instantiation, so I just set up the environment variables. Would you please talk more about that? Again, Thanks for all your response, RebeccaArticle: 116481
Is there anyone on this list looking for side work who lives in Western NC or possibly Eastern TN, North Western SC? Please enquirer directly to Rick at ashevillecommunity dot org. Include resume' and salary requirements. If you can't make a drive to Asheville in a few hours then I am not interested and you need not reply. This will be contract work as needed. There currently is a CPLD project that needs to be done and others are coming up this year. RickArticle: 116482
I can confirm that.
Click on "register now", "EMEA", "register now" and enter your name
and email and select "Wiesbaden".
I can also confirm that selecting the button is required to register.
Kolja Sulimma
On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
> Not being able to find the silly text on the Avnet website, I googled
> and found this "Model Release"
> MODEL RELEASE
> For good and valuable consideration, receipt of which I hereby
> acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> subsidiaries, assigns, licensees, and designees, the irrevocable right
> to use my name, picture, likeness and/or photograph, and biographical
> information (collectively the "Materials") in all forms and media now
> known or hereafter developed, and in all manners, including composite
> or distorted representations,
> ........and so on, ad nauseam.
>
> I believe this has nothing to do with the seminar, but I cannot attack
> the issue unless I can pinpoint it to the registration.
> Which I have been unable to do.
> Peter Alfke
>
> On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > As the Bard of Avon wrote in Henry VI:
> > "JACK CADE.
> > I thank you, good people:- there shall be no money; all shall eat and
> > drink on my score; and I will apparel them all in one livery, that
> > they may agree like brothers, and worship me their lord.
>
> > DICK.
> > The first thing we do, let's kill all the lawyers."
>
> > Peter Alfke, speaking for himself ;-)
> > =============================
> > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > I've been to these before and found them useful so I was registering to
> > > attend until I came to this bit:
>
> > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > licensees, and design irrevocable right to use my name, picture, likeness
> > > and/or photograph, and biography information ( collectively the "materials")
> > > in all forms and media now known or hereby developed, and in all manners,
> > > including composite or distorted representations, for marketing, trade,
> > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > any uses that may be created in connection therewith, or the use to which
> > > Materials may be applied. I agree that the Materials, the negatives, and
> > > other originals shall constitute Avnet's sole property, with full right of
> > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > and designees, and all persons acting under its permission or anyone from
> > > any and all claims whatsoever in connection with the use of the materials. I
> > > have read the release and am fully familiar with its contents.
>
> > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > Michael Kellett
>
> > >www.mkesc.co.uk
Article: 116483
Thanks, I found it, and I have sent a very strong letter (including
the word "crazy") to three layers of Xilinx management. Let's see
whether it helps. This is not only silly, it is stupid.
Let's assume that it gets removed, pronto!
Shakespeare was right.
Peter Alfke
P.S. See you in Wiesbaden, Kolja.
=========================================================
On Mar 9, 3:09 pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> I can confirm that.
>
> Click on "register now", "EMEA", "register now" and enter your name
> and email and select "Wiesbaden".
>
> I can also confirm that selecting the button is required to register.
>
> Kolja Sulimma
>
> On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > Not being able to find the silly text on the Avnet website, I googled
> > and found this "Model Release"
> > MODEL RELEASE
> > For good and valuable consideration, receipt of which I hereby
> > acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> > subsidiaries, assigns, licensees, and designees, the irrevocable right
> > to use my name, picture, likeness and/or photograph, and biographical
> > information (collectively the "Materials") in all forms and media now
> > known or hereafter developed, and in all manners, including composite
> > or distorted representations,
> > ........and so on, ad nauseam.
>
> > I believe this has nothing to do with the seminar, but I cannot attack
> > the issue unless I can pinpoint it to the registration.
> > Which I have been unable to do.
> > Peter Alfke
>
> > On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > As the Bard of Avon wrote in Henry VI:
> > > "JACK CADE.
> > > I thank you, good people:- there shall be no money; all shall eat and
> > > drink on my score; and I will apparel them all in one livery, that
> > > they may agree like brothers, and worship me their lord.
>
> > > DICK.
> > > The first thing we do, let's kill all the lawyers."
>
> > > Peter Alfke, speaking for himself ;-)
> > > =============================
> > > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > > I've been to these before and found them useful so I was registering to
> > > > attend until I came to this bit:
>
> > > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > > licensees, and design irrevocable right to use my name, picture, likeness
> > > > and/or photograph, and biography information ( collectively the "materials")
> > > > in all forms and media now known or hereby developed, and in all manners,
> > > > including composite or distorted representations, for marketing, trade,
> > > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > > any uses that may be created in connection therewith, or the use to which
> > > > Materials may be applied. I agree that the Materials, the negatives, and
> > > > other originals shall constitute Avnet's sole property, with full right of
> > > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > > and designees, and all persons acting under its permission or anyone from
> > > > any and all claims whatsoever in connection with the use of the materials. I
> > > > have read the release and am fully familiar with its contents.
>
> > > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > > Michael Kellett
>
> > > >www.mkesc.co.uk
Article: 116484John McCaskill wrote: > After all, hafnium is only half as good as unobtanium Sure, but it's considerably less than half as expensive.Article: 116485
Hi People, I have generated a duap port RAM using a Xilinx Core generator . Port A is 32 x 32 and Port B is 8 x 128 The 32 bit port , Port A , is interpreting the addresses in the row order 00 01 02 . . . 1F I had expected the 8 bit port to also interpret the addresses in the row order. I have done the simulation of the DPRAM and this was it responded as expected. 03 02 01 00 07 06 05 04 ......................... 7F 7E 7D 7C But now comes the weird part . I implemented my design on a Xilinx Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in the column order ,. I have observed this using debug data as well as using Chip Scope Pro, i.e. 60 40 20 00 61 41 21 01 62 42 22 02 63 43 23 03 . 7F 5F 3F 1F Are there any synthesis constraints that can prevent this from happening . All the documents and application notes say that the 8 bit port also should be addressed in the row ordering fashion. Could any one suggest why I might be having this problem Thank You VenuArticle: 116486
Have you read chapter 10 in the Cyclone Device Handbook? "Implementing Double Data Rate I/O Signaling Cyclone Devices" You are using a Cyclone and not Cyclone2, correct? "nfirtaps" <lloyd.rochester@gmail.com> wrote in message news:1173457175.663323.155840@j27g2000cwj.googlegroups.com... > On Mar 8, 9:27 pm, "Rob" <robns...@frontiernet.net> wrote: >> If your input clock is not on the global clock network you will be >> fighting >> with clock skew to the flops. When your clock edges are happening with >> respect to the data at the flops becomes an utmost concern for you. >> >> "nfirtaps" <lloyd.roches...@gmail.com> wrote in message > > > >> >> news:1173383894.763347.110110@64g2000cwx.googlegroups.com... >> >> >I am trying to deserialize a DDR signal in my Cyclone. For reasons I >> > won't go into the DDR clock comes in off a general purpose I/O pin. I >> > need a way of deserializing this signal, and want to increase the >> > frequency of the DDR clock by 2 so I can use rising edge flip-flops. >> >> > 1.) Can I somehow drive a PLL with a general purpose I/O >> > 2.) Is there another way of deserializing the DDR signal. >> >> > Currently I have a the DDR clock coming in my fpga and I not the clock >> > so I can sample the DDR signal on the rising egde. >> >> > Thanks > > As for the clock not being part of the global clock network, Quartus > gives me the following message "Info: Automatically promoted signal > "dco" to use Global clock in PIN 29" so I guess my clock is put into > the global network. >Article: 116487
Venu, on a single-port memory you can scramble the address lines anyway you want. But with two ports you must be more careful in order to be consistent. Look at Table 2-12 in the BlockRAM section, it's on page 210 in my printed copy. That should help you untangle the address lines. Peter Alfke, from home. ============================== On Mar 9, 10:44 pm, "Venu" <get2v...@gmail.com> wrote: > Hi People, > > I have generated a duap port RAM using a Xilinx Core generator . > Port A is 32 x 32 and Port B is 8 x 128 > > The 32 bit port , Port A , is interpreting the addresses in the row > order > 00 > 01 > 02 > . > . > . > 1F > > I had expected the 8 bit port to also interpret the addresses in the > row order. I have done the simulation of the DPRAM and this was it > responded as expected. > > 03 02 01 00 > 07 06 05 04 > ......................... > 7F 7E 7D 7C > > But now comes the weird part . I implemented my design on a Xilinx > Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in > the column order ,. I have observed this using debug data as well as > using Chip Scope Pro, i.e. > > 60 40 20 00 > 61 41 21 01 > 62 42 22 02 > 63 43 23 03 > . > 7F 5F 3F 1F > > Are there any synthesis constraints that can prevent this from > happening . All the documents and application notes say that the 8 bit > port also should be addressed in the row ordering fashion. Could any > one suggest why I might be having this problem > > Thank You > VenuArticle: 116488
Peter's reference may point you to the same conclusion you started with. The only thing I could see as a problem would show up in simulation as well: using bit-reversed addresses such as "reg [0:10] Addr8;" with confusion for bits 0,1. (The sample dimensions are for an 18 kbit BlockRAM.) If you use [10:0] style addressing, you're correct that a write to address 9'h0 on the 32-bit side of 32'h12345678 should give you read values on the first 4 addresses on the 8-bit side of address 11'h0: 8'h78 address 11'h1: 8'h56 address 11'h2: 8'h34 address 11'h3: 8'h12 If your target is BlockRAM, consider instantiating the BlockRAM primitive rather than the Coregen module to see if the problem clears up. The RAMB16_S9_S36 primitive would give you the aspect ratios you need. If your target is distributed memory, there's a slight chance that the Coregen isn't "doing the right thing" since the asymmetric ports may be rarely used with the CLB SelectRAM. You could also check the post-route simulation to see if it matches the live silicon. - John_H Venu wrote: > Hi People, > > I have generated a dual port RAM using a Xilinx Core generator . > Port A is 32 x 32 and Port B is 8 x 128 > > The 32 bit port , Port A , is interpreting the addresses in the row > order > 00 > 01 > 02 > . > . > . > 1F > > > I had expected the 8 bit port to also interpret the addresses in the > row order. I have done the simulation of the DPRAM and this was it > responded as expected. > > 03 02 01 00 > 07 06 05 04 > ......................... > 7F 7E 7D 7C > > > But now comes the weird part . I implemented my design on a Xilinx > Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in > the column order ,. I have observed this using debug data as well as > using Chip Scope Pro, i.e. > > 60 40 20 00 > 61 41 21 01 > 62 42 22 02 > 63 43 23 03 > . > 7F 5F 3F 1F > > Are there any synthesis constraints that can prevent this from > happening . All the documents and application notes say that the 8 bit > port also should be addressed in the row ordering fashion. Could any > one suggest why I might be having this problem > > > Thank You > VenuArticle: 116489
How can I get a ddr sdram controller for the MT46V16M16TG -75 micron chip. I want a controller without the plb or opb interface. I tried open cores.org but it says that the repository is empty with no files pertaining to the ddrsdram controller core. Could someone give me right pointers? Thanks, D.Article: 116490
<dhruvakshad@gmail.com> wrote in message news:1173559475.001130.307290@v33g2000cwv.googlegroups.com... > How can I get a ddr sdram controller for the MT46V16M16TG -75 micron > chip. > I want a controller without the plb or opb interface. I tried open > cores.org but it says that the repository is empty with no files > pertaining to the ddrsdram controller core. > Could someone give me right pointers? > Thanks, > D. > Easiest way is to download data sheet from Micron site and put it together yourself. I recently put together a controller for the Micron MT48H4M16LF mobile SDRAM which will be similar. Took about a day to put together via schematics and simulated. I imagine a Verilog/VHDL whizz could do it a lot quicker.Article: 116491
Rest assured that the offensive paragraph will be killed.
I don't know what happens to the offending lawyer... ;-)
Peter Alfke, from home
On Mar 9, 3:43 pm, "Peter Alfke" <p...@xilinx.com> wrote:
> Thanks, I found it, and I have sent a very strong letter (including
> the word "crazy") to three layers of Xilinx management. Let's see
> whether it helps. This is not only silly, it is stupid.
> Let's assume that it gets removed, pronto!
> Shakespeare was right.
> Peter Alfke
> P.S. See you in Wiesbaden, Kolja.
> =========================================================
> On Mar 9, 3:09 pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
>
> > I can confirm that.
>
> > Click on "register now", "EMEA", "register now" and enter your name
> > and email and select "Wiesbaden".
>
> > I can also confirm that selecting the button is required to register.
>
> > Kolja Sulimma
>
> > On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > Not being able to find the silly text on the Avnet website, I googled
> > > and found this "Model Release"
> > > MODEL RELEASE
> > > For good and valuable consideration, receipt of which I hereby
> > > acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> > > subsidiaries, assigns, licensees, and designees, the irrevocable right
> > > to use my name, picture, likeness and/or photograph, and biographical
> > > information (collectively the "Materials") in all forms and media now
> > > known or hereafter developed, and in all manners, including composite
> > > or distorted representations,
> > > ........and so on, ad nauseam.
>
> > > I believe this has nothing to do with the seminar, but I cannot attack
> > > the issue unless I can pinpoint it to the registration.
> > > Which I have been unable to do.
> > > Peter Alfke
>
> > > On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > > As the Bard of Avon wrote in Henry VI:
> > > > "JACK CADE.
> > > > I thank you, good people:- there shall be no money; all shall eat and
> > > > drink on my score; and I will apparel them all in one livery, that
> > > > they may agree like brothers, and worship me their lord.
>
> > > > DICK.
> > > > The first thing we do, let's kill all the lawyers."
>
> > > > Peter Alfke, speaking for himself ;-)
> > > > =============================
> > > > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > > > I've been to these before and found them useful so I was registering to
> > > > > attend until I came to this bit:
>
> > > > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > > > licensees, and design irrevocable right to use my name, picture, likeness
> > > > > and/or photograph, and biography information ( collectively the "materials")
> > > > > in all forms and media now known or hereby developed, and in all manners,
> > > > > including composite or distorted representations, for marketing, trade,
> > > > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > > > any uses that may be created in connection therewith, or the use to which
> > > > > Materials may be applied. I agree that the Materials, the negatives, and
> > > > > other originals shall constitute Avnet's sole property, with full right of
> > > > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > > > and designees, and all persons acting under its permission or anyone from
> > > > > any and all claims whatsoever in connection with the use of the materials. I
> > > > > have read the release and am fully familiar with its contents.
>
> > > > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > > > Michael Kellett
>
> > > > >www.mkesc.co.uk
Article: 116492On 2007-03-10, Venu <get2venu@gmail.com> wrote: > > I have generated a duap port RAM using a Xilinx Core generator . > Port A is 32 x 32 and Port B is 8 x 128 I saw a problem recently where the behavior of the narrower port changed depending on which coregen was used. I know one of the IP modules was called "Dual Port something" and the other was more general and included dual port support. If that's not enough to put you on the trail I can try to find the exact names. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 116493
It looks to me that you use the second bit position in the upper nibble (you call it 20) as your least significant bit... I am sure this is just an address-bit ordering problem. Please tell us when you got this straightened out. Peter Alfke, from home ========== On Mar 9, 10:44 pm, "Venu" <get2v...@gmail.com> wrote: > Hi People, > > I have generated a duap port RAM using a Xilinx Core generator . > Port A is 32 x 32 and Port B is 8 x 128 > > The 32 bit port , Port A , is interpreting the addresses in the row > order > 00 > 01 > 02 > . > . > . > 1F > > I had expected the 8 bit port to also interpret the addresses in the > row order. I have done the simulation of the DPRAM and this was it > responded as expected. > > 03 02 01 00 > 07 06 05 04 > ......................... > 7F 7E 7D 7C > > But now comes the weird part . I implemented my design on a Xilinx > Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in > the column order ,. I have observed this using debug data as well as > using Chip Scope Pro, i.e. > > 60 40 20 00 > 61 41 21 01 > 62 42 22 02 > 63 43 23 03 > . > 7F 5F 3F 1F > > Are there any synthesis constraints that can prevent this from > happening . All the documents and application notes say that the 8 bit > port also should be addressed in the row ordering fashion. Could any > one suggest why I might be having this problem > > Thank You > VenuArticle: 116494
dhruvakshad@gmail.com wrote: > How can I get a ddr sdram controller for the MT46V16M16TG -75 micron > chip. > I want a controller without the plb or opb interface. I tried open > cores.org but it says that the repository is empty with no files > pertaining to the ddrsdram controller core. > Could someone give me right pointers? > Thanks, > D. I read a few reports about that controller, it seemed to be a rather low-performance option. You could look into Xilinx's MIG, that could help to get you started - I started building my own 200MHz DDR controller to interface with a 256MB PC3200 DIMM and I use an MIG design as a reference when I need inspiration. Again, I am not using the MIG either since I have seen mixed feedback about it. I too would be interested in hearing about existing open-source, preferably high-bandwidth, DDR controllers. Right now, I am expecting the my controller to consume about 44 of 144 BRAMs (ouch!) and at least 3000 of 13.6k slices on my XC2VP30-7. Things would be much simpler if I had V5s instead. I am doing this mostly because I have always been pretty far from IOBs in my previous FPGA/ASIC jobs. Since knowledge of DDR/DDR2 is often a must for the jobs I am interested in, I decided to try building a full-blown DDR controller - I'll most likely downscale it for actual use though. Since your device is only 16bits wide, things should be much simpler and you should have many more options than I do. If you browse OpenCore's CVS directory, you will find many SDR-SDRAM controllers that may be nearly suitable for your application - you should be able to modify one of the many SDR controllers for DDR operation by doing little more than changing the IOB FFs and widening data buses as necessary. Note: they appear to all be verilog. BTW, all DDR-SDRAM devices are pretty much the same, there should be no need to request one for a specific device. All you need to do is connect a generic DDR controller to a suitable clock and modify the controller to match the CAS/RAS and other latency requirements of your specific device for the selected operating frequency.Article: 116495
On Thu, 8 Mar 2007 10:42:14 -0800, "davide" <davide@xilinx.com> wrote: >Steve, > >Can you tell me a little bit more about what device you are targeting and >the version of WebPACK you are using. Are you using any multiplier blocks >or doing any multiplication operations and pipelining the output? > >-David I just installed 9.1 (was using 7.1). I got the same warning. Spartan II, no multipliers, no pipelining. Dan > > > >"Steve Battazzo" <thesteveman_ice9@yahoo.co.jp> wrote in message >news:m6KdnZIfoIUuVnLYnZ2dnUVZ_rmdnZ2d@comcast.com... >> At the XST-synthesize stage, I'm getting this weird warning: >> "Property use_dsp48" is not applicable for this technology. >> I don't have anything in my code that I know of that calls for any such >> thing.. it doesn't affect the program actually running on my board, but >> I'm curious anyway. >> >> Anyone know what this means? >> >> Thanks, >> >> Steve >Article: 116496
Hi, I have a PCB design with a FPGA and other devices that require a clock input. Is it a good idea to first feed a single clock into the FPGA and then through the FPGA distribute this clock to the other devices? BenArticle: 116497
Ben Popoola wrote: > Hi, > I have a PCB design with a FPGA and other devices that require a clock > input. Is it a good idea to first feed a single clock into the FPGA and > then through the FPGA distribute this clock to the other devices? a) Do the other devices need their clocks before the FPGA is finished Config ? b) Is added jitter on the clock a significant concern ? c) Do you have power save modes, where the FPGA is deprecated ? If not, then is _is_ nice and flexible to route the clocks thru the FPGA, as ytou can do what you like with them later.... -jgArticle: 116498
I have had similar requirements (updating state variables, or some such) where I used dual-port RAM; I use one port for the read, and the other (delayed a clock) for the modify-write. The pipeline needs to be managed properly, but it can save tremendously on registers (assuming that only one index needs to be updated at a time. If all entries need concurrent access--well, a memory won't cut it. For my application(s), typically TDM processing of multiple channels, it works well.) JTW "news reader" <newsreader@google.com> wrote in message news:esrs16$anh$1@reader01.singnet.com.sg... > > "Utku Özcan" <utku.ozcan@gmail.com> wrote in message > news:1173384869.194349.20140@q40g2000cwq.googlegroups.com... >> >> Hi "news reader", my humble perls in between.. >> >> news reader schrieb: >> >>> In the design I have 256 3-bit registers, every time I need to read or >>> write 16 of them (data_o0, 1, ...15). >>> The read/write address is not totally random. >> >> It seems that you have an algorithm that handles a deterministic >> distribution of the values to be accessed. Therefore you think you can >> implement it with logic only. >> >> I assume you are modeling an algorithm for a special matrix operation. >> > > It's not matrix, but the memory access is intensive, must accomplish r/w > in > single clock cycle, so register is used instead of memory. > > >>> For example, assuming that I arrange the register into a 16X16 matrix, >>> data_o0 accesses among the zeros row or column. data_o1 may access from >>> 20 of the >>> registers, but not 256, data_o2 may access from 30 of the variables, >>> etc. >> >> The values do not give us much info. data_ox (x = 1, 2, ...) is >> accessing which elements and in which distribution? >> > > In each clock cycle, 16 addresses are generated, and 16 data are > read/written. However, > each of the 16 data is read/written only to n/256 addresses (0<n<255). > > >>> If I code such that every output reads from the 256 registers, the final >>> logic will be overkill and highly redundant. >> >> You think that the distribution of elements can be accessed with pure >> logic. >> Therefore you tried to model your logic to cover every case, or you >> want to do it so. >> >>> If I use case statements to list each of the senarios, the RTL code may >>> end >>> up 500 kilobyte. >> >> This is reasonable then. >> > > > By means of case statement, I use 32 case statements, in each case > statement there > are less than 256 choices. Some have only 20, 30 choices, etc. > > >>> Will design compiler synthesize a 500KB design efficiently? >> >> What means "efficience" for you? Speed or minimum logic? >> If minimum logic, then please share with us the algorithm you are >> trying to implement. >> >>> Will NCVerilog compile and simulate it efficiently? >> >> NCVerilog does not care about logic implementation. It defines the >> behaviour of the system, no matter how the objects are linked. >> > > > For example in read operation, > --------------------- implementation A------------------ > input [7:0] addr_i0, addr_r1, ...addr_r15; > output [2:0] dat_o0, dat_o1, ...dat_o15; > > reg [2:0] mymemory[0:255]; // Main memory > > dat_o0 <= mymemory[addr_i0]; > dat_o1 <= mymemory[addr_i1]; > .... > dat_o15 <= mymemory[addr_i15]; > --------------------- End A------------------ > > --------------------- implementation B------------------ > > case (addr_i0) // I can calculate these options through simulations. > 8'd0 : dat_o0 <= mymemory[0 ]; > 8'd5 : dat_o0 <= mymemory[5 ]; > 8'd54 : dat_o0 <= mymemory[54 ]; > 8'd122: dat_o0 <= mymemory[122]; > 8'd125: dat_o0 <= mymemory[125]; > ... > 8'd166: dat_o0 <= mymemory[166]; > 8'd233: dat_o0 <= mymemory[233]; > default: dat_o0 <= mymemory[0 ]; > endcase > > > > case (addr_i1) > 8'd0 : dat_o1 <= mymemory[0 ]; > 8'd7 : dat_o1 <= mymemory[7 ]; > 8'd9 : dat_o1 <= mymemory[9 ]; > 8'd13 : dat_o1 <= mymemory[13 ]; > 8'd25 : dat_o1 <= mymemory[25 ]; > 8'd57 : dat_o1 <= mymemory[57 ]; > 8'd124: dat_o1 <= mymemory[124]; > ... > 8'd133: dat_o1 <= mymemory[133]; > 8'd155: dat_o1 <= mymemory[155]; > 8'd277: dat_o1 <= mymemory[277]; > default: dat_o1 <= mymemory[0 ]; > endcase > > ... > case (addr_i15) > ... > --------------------- End B------------------ > > In terms of hardware implementation, is it certain that implementation B > saves hardware > compared to A? Will the large chunks of RTL codes causes a DC or NCVerilog > to > choke up? > > > >>> Are there any neater techniques to attack this problem? >> >> Since you have not given much data, I think you can implement this >> stuff with a RAM. >> Why don't you use a RAM? Then you can define the RAM addresses to >> model your matrix. You will generate addresses to define the positions >> for your matrix which mimics your algorithm. >> > > I used registers instead of RAM due to the memory throughput. > > > >> Utku. >> > >Article: 116499
Daniel S. wrote: > dhruvakshad@gmail.com wrote: >> How can I get a ddr sdram controller for the MT46V16M16TG -75 micron >> chip. >> I want a controller without the plb or opb interface. I tried open >> cores.org but it says that the repository is empty with no files >> pertaining to the ddrsdram controller core. >> Could someone give me right pointers? >> Thanks, >> D. > > I read a few reports about that controller, it seemed to be a rather > low-performance option. You could look into Xilinx's MIG, that could > help to get you started - I started building my own 200MHz DDR > controller to interface with a 256MB PC3200 DIMM and I use an MIG design > as a reference when I need inspiration. Again, I am not using the MIG > either since I have seen mixed feedback about it. I too would be > interested in hearing about existing open-source, preferably > high-bandwidth, DDR controllers. > > Right now, I am expecting the my controller to consume about 44 of 144 > BRAMs (ouch!) and at least 3000 of 13.6k slices on my XC2VP30-7. Things > would be much simpler if I had V5s instead. I am doing this mostly > because I have always been pretty far from IOBs in my previous FPGA/ASIC > jobs. Since knowledge of DDR/DDR2 is often a must for the jobs I am > interested in, I decided to try building a full-blown DDR controller - > I'll most likely downscale it for actual use though. > > Since your device is only 16bits wide, things should be much simpler and > you should have many more options than I do. If you browse OpenCore's > CVS directory, you will find many SDR-SDRAM controllers that may be > nearly suitable for your application - you should be able to modify one > of the many SDR controllers for DDR operation by doing little more than > changing the IOB FFs and widening data buses as necessary. Note: they > appear to all be verilog. > > BTW, all DDR-SDRAM devices are pretty much the same, there should be no > need to request one for a specific device. All you need to do is connect > a generic DDR controller to a suitable clock and modify the controller > to match the CAS/RAS and other latency requirements of your specific > device for the selected operating frequency. DDR controllers should simply meet the requirements of the JEDEC spec (you can find it at Micron). As you want to get faster things get more complex of course. There are two primary differences between SDR and DDR: 1. The clock is complementary and should have very low skew between the pair. In addition, clocking at the SDRAM is based on the differential voltage between the clock pair rather than VIL/VIH. 2. The strobes (DQS rather than DQM) are driven by the SDRAM during reads (with interesting timing that has to be accounted for at the controller).i.e. the strobes are bidirectional. The interesting timing is that the strobes are driven coincidentally with the data during reads, and that has to be offset at the controller to capture the data successfully. Most controllers assert the strobe during writes at roughly 50% of the data window. Delay units in the FPGA are a godsend for this sort of thing. Starting with a SDR controller, the spec and a typical device data sheet it shouldn't be too hard a task to do a DDR controller. How well it performs depends on the device and implementation, of course. Cheers PeteS
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