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
We have prototyped one, and we're in the process of testing. It would still be useful to see what the Altera part looked like. For instance, I just tracked down a PDF from the development kit. It implies that they pulled down/up certain lines which, while logical to do, is not part of the reference design.Article: 87326
Hi Some trial and error (one match function == 2) for 4 bit counter case, now counter value is "0010" at time 0 (position=0). So it seems problem is solved. Thankyou again for comment and nice pointer. RegardsArticle: 87327
anytimeArticle: 87328
Has anyone activated this yet? i found this ddr controller on the xilinx website: memory interface generator (MIG). it was on demos on demand as well. it is a simple program that supposedly generates everything you need. it seems neat, hdl seems ok. though it's done on ML461 board and it gives wrong .ucf files even for ML461 itself (there is another sample code of pretty much same controller there (xapp709) so i compared it with the generated one). can someone please help me with the pinouts here. i've figured out data and address pins (well, i think i have) and now i am left with controls. thanksArticle: 87329
You guys are awesome. Thanks. I will try these ideas tonight!Article: 87330
Hello, I'm interested in how individuals or design groups manage complexity in their design projects. What things do you do or things the group does that can take complex tasks and break them into simpler or more manageable tasks? It may sound like a weird question, but there must be some guidelines, best practices, or habits used to achieve success in designing/developing a complex project. I'm sure there must be some individuals out there that are constantly taking complex tasks and just about every time have success with it. Short of speaking, I want to know what's the secret to their success. All comments are welcomed, even the most obvious suggestions. As an engineer, I'm constantly trying to improve my design processes. Thanks everyone, joeArticle: 87331
<jjlindula@hotmail.com> wrote in message news:1121970065.257771.127820@g43g2000cwa.googlegroups.com... > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. What things do you do or things > the group does that can take complex tasks and break them into simpler > or more manageable tasks? It may sound like a weird question, but there > must be some guidelines, best practices, or habits used to achieve > success in designing/developing a complex project. I'm sure there must > be some individuals out there that are constantly taking complex tasks > and just about every time have success with it. Short of speaking, I > want to know what's the secret to their success. All comments are > welcomed, even the most obvious suggestions. If there was a fairly simple answer to this question - a lot of talented people would become not-so-talented very quickly. What makes large complex design projects a challenge other than the engineering complexity is the fairly strong influence of several external factors....like, engineering resources available, their talents, budget, time, skill of project manager(s), etc. This makes for such a complex set of inter-related things that it's really really hard to talk about one while ignoring the others. The secret to the success of these individuals you speak of (I'm yet to meet one) is a good understanding of all the factors (and probably a few more that I can't think of). Quite a bit of this comes from experience...so I'd imagine this person to have participated and/or managed several complex projects before being able to consistently succeed. In short, I think some level of success can be achieved by removing whatever it is that makes a task 'complex'. So whatever one can do to break down the tasks so that they aren't 'complex' anymore should be an excellent start. By doing this, you expose the complexity of the task to yourself (and maybe a few select others) and all others involved get to deal with a fairly straightforward and simple task - thereby reducing risk which I think is fairly key to this. Cheers Bhaskar P.S - I can easily see a counter argument where someone might say that risk should be divided equally among several people rather than 1 person taking on all the risk (thereby reducing risk :-)) - I don't know which option is better - I'd say "it depends" :-) > As an engineer, I'm constantly trying to improve my design processes. > > Thanks everyone, > joe >Article: 87332
Peter Alfke wrote:
>Ray, pretty clever.
>But more difficult to understand, or to modify.
>And what do I do with the unused port?
>
>But nevertheless, hats off to a smart solution...
>Peter
>
>
>
Why is it difficult to understand or modify?
It is just a counter that gets loaded with (delay-2) and then counts
down until it becomes -1, and then reloaded. The load value can be
changed at any time, and takes effect the next time the counter reaches
the terminal count of -1 (this downcounter has the advantage of not
requiring any decoding, and of having an easily adjusted modulus). The
counter output becomes the address to the memory. I think it is pretty
straightforward to comprehend, do you find it otherwise? The only
difference is just being a little clever in the counting and taking
advantage of the read before write capability of the memory.
As far as modifying it, I'm not sure I see the difficulty there
either: The modulus is easy to change, and in particular can be easily
changed dynamically. You can easily change the width of the counter for
different aspect ratios on the memory, say for instance if you wanted to
delay a 9 bit signal by a delay not to exceed 2048 clocks. Beyond that,
I'm not sure what modifications you'd want to make, or for that matter
what modifications that wouldn't be as difficult in the two port scheme
you offered.
As far as the unused port goes, you can leave it unused if you want, or
if the depth of the shift register is less than half the memory depth,
you can set the high order address bit to 0 on the shift register side
and to '1' on the spare port and then you can use the spare port side as
a 9K bit memory for anything your heart desires. Unfortunately, the
tools can't figure that out for you so you have to instantiate and
initialize (and initialize if needed) the memory. You can also use the
second side if you need a wide shift register delay, like you might use
for a digital filter.
--
--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: 87333
Hierarchical design. Every complex design or algorithm is an aggregate
of simpler subsystems. By using hierarchy, you get a fairly simple
representation at every level in the design, and with the exception of
the leaf nodes, the design is an exercise of defining and then stitching
together the sub-blocks. The designs at the leaf nodes are simple
designs (if they aren't then they should also be broken into sub-modules).
With a proper definition of each block, the blocks can be broken out
into independent designs with the responsibility of meeting the
interface specifications falling on whoever designs that block.
--
--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: 87334jjlindula wrote: > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the best case possible for incremental design. You build a prototype, see if it works, tweak it a little, and repeat over many iterations. > What things do you do or things > the group does that can take complex tasks and break them into simpler > or more manageable tasks? Sort feature requests by business priority and implement the most important ones first. > It may sound like a weird question, but there > must be some guidelines, best practices, or habits used to achieve > success in designing/developing a complex project. I'm sure there must > be some individuals out there that are constantly taking complex tasks > and just about every time have success with it. Short of speaking, I > want to know what's the secret to their success. All comments are > welcomed, even the most obvious suggestions. Write unit tests for each tiny feature, as you write the feature. -- Phlip http://www.c2.com/cgi/wiki?ZeekLandArticle: 87335
Hello I compiled the stapl player for our testsystem. One function is to calculate the checksum of the JAM file. Regards Ralph "Alex Rast" <ad.rast.7@nwnotlink.NOSPAM.com> schrieb im Newsbeitrag news:969A1220Eadrastnwnotlinkcom@216.168.3.44... > at Wed, 20 Jul 2005 18:48:51 GMT in <1121885331.639515.18250 > @g44g2000cwa.googlegroups.com>, daniel.leu@gmail.com (Daniel Leu) wrote : > > >All the details are in the specification: > >www.jedec.org/download/search/jesd71.pdf > > > > Well, the spec says *what* the STAPL composer would do but gives no > implementation thereof. (Nor is it the job of a specification to supply an > implementation to go along with it) What I was hoping for was to find some > sort of software tool to help generate custom STAPL files so that it > doesn't become a DIY job. For simple stuff one can always simply create a > STAPL file manually using a text editor but for anything more elaborate > than the very most basic operations I think a tool would be much preferred. > Either way, though, there's still the pesky CRC at the end and to do this > with a manually-generated file you need something like a hex editor so you > can calculate the CRC. > > > -- > Alex Rast > ad.rast.7@nwnotlink.NOSPAM.com > (remove d., .7, not, and .NOSPAM to reply)Article: 87336
Hi Austin, THanks for the reply. I am using a Virtex I and NOT a Virtex II. I only have DLLs and NOT DCMs so what you have suggested won't work for me. Do you know of a way to create a arbitrary delay using a combination of DLLs and other delay elements like buffers. My concern is having the backend take out "unnecessary" buffers. I am using app. note 132, which is a very good starting point and implmenents in HW very easily. I need that next step to get the delays specified in the MIPS R3000 timing diagrams. Thanks, JOhn On 21 Jul 2005, austin wrote: > Page 80: > > http://direct.xilinx.com/bvdocs/userguides/ug002.pdf > > Discusses the DCM, and the fixed phase offset feature. > > To get 0, 90, 180, 270 use 0 offset. > > To get anything else, set the offset to the desired fractional value (8 > bits describe the N/256 of a period shift). > > For example, 45 degree offset would be 32. 32/256= 1/8 period. 1/8 > period = 45/360, or 45 degrees. Then CLK0, CLK2X, CLKDV are all 45 > degrees offset, and CLK90 is 135 degrees, CLK180 is 225 degrees, and > CLK270 is 315 degrees offset. > > You will end up using BUFG's for all clocks to make sure the skew > between clocks does not cause you any concerns. > > Use two DCMs both driven by the same CLKIN source to get more than 4 > separate phases with offsets (drive in parallel). > > It is suggested do not place them in tandem, as that increases the > jitter. If jitter is not a concern, then use in tandem is OK for the > DLL part of the DCM (however do not drive the second DCM input CLKIN > from the CLKFX of a first DCM -- that is not guaranteed to work, but > CLKIN of the second DCM from CLK0, CLK90, CLK180, CLK270, CLK2X, CLKDV > is OK). > > Austin > > John D. Davis PhD Candidate Computer Systems Lab Office # 1.650.723.6891 Stanford University Fax # 1.650.725.6949Article: 87337
jjlindula@hotmail.com wrote: > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. Good question. This is a little like teaching a correspondence course on backing a trailer down a winding driveway and parking it in a tight spot. The student can only really learn the thing by trial and error, but here's my list anyway. *Tools* 1. _Source/version control_ Without this, development often moves backward instead of forward. 2. _Text Editor_ that knows the language and can quickly browse the design, run make and and fire off test cases or simulations. This edit/compile/test loop will be run thousands of times during a project. *Process* 1. Acquire tools, requirements and sample data. This is the hardest part. 2. Prove the point on the sample data first, then fill in the stubbed out functions and procedures. Find the top of the tree before working out the shape and color of the leaves. 3. Code using the design rules taught by previous sore experience. 4. Use hierarchy only as needed in your own code. There will be plenty of hierarchy required just to hook together modules by others and for reused/purchased modules. Overuse of hierarchy makes design intent difficult to understand from the code level. * Regression * Once a module works in the system, collect the best test cases and construct a pass/fail regression test or test bench. Rerun this test before committing any edits to the module. *Update Design Rules* Before the project is out of short term memory, update the design rules to cover any new lessons learned. -- Mike TreselerArticle: 87338
Using 6.1.03i. Pondering whether or not to spend the money to update to latest revision. The devices we are using are fully supported by what we currently have. No real issues at all. That being the case, what would be the most significant reasons that would justify an upgrade today? Thanks, -MartinArticle: 87339
Brad Smallridge wrote: > Hello Group, > > What is the best way to count 64 incoming simultaneous > bit signals to determine the number of 1s (in VHDL)? > I have clock cycles to spare but the result must be pipelined > so that each clock cycle produces a new count. In case you haven't found it yet, VHDL code for 30 bits (without pipelining, that should be easy to add as a bunch of registers at the end, which XST or Synplify may apply register re-timing to) was posted at: http://groups-beta.google.com/group/comp.arch.fpga/tree/browse_frm/thread/d838401f654184a8/bc0f119b852d8a5b?rnum=11&hl=en&q=counting+ones&_done=%2Fgroup%2Fcomp.arch.fpga%2Fbrowse_frm%2Fthread%2Fd838401f654184a8%2Fef8589c7332f93f9%3Fq%3Dcounting+ones%26rnum%3D1%26#doc_7480e49da22bae56 Should be straightfoward to extend to 64 bits. If it's not too much trouble, can I ask what is the application? I thought the circuit was neat, but wonder how folks use it. JohnArticle: 87340
Pete Fraser wrote: > I'm just about to start a small ML401 design,and am not > sure if I should use EDK 6.3 or EDK 7.1. > > Has anyone (Antti?) been able to get the reference design > working with 7.1, or should I stick to 6.3? > > Thanks FWIW I have 6 fully working Microblaze designs under EDK6.2 (not 6.3). These are for various Virtex-II and Spartan-3 eval boards and our production hardware. Under 7.1, several (2 or 3, I forget) of the 6 either fail to route or have large timing errors. Each time a new 7.1 SP comes out, I give it a try on these working designs. So far, I am still with 6.2. I would like to upgrade, as 7.1 has some nice new features, but not until it's more mature.Article: 87341
Martin, Generally speaking, if there is no reason to change, then change is probably not worth it. Any change has to be requalified (by you), and that can be expensive. However, the new tools also do a better job of routing, and placing, and you may get a whole speed grade improvement by using the newer tools (even with an older family part). If you are presently using a faster than slowest speed grade part, or you can use more speed to better advantage, then upgrading to the latest and best tools have benefit. AustinArticle: 87342
jjlindula@hotmail.com wrote: > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. What things do you do or things > the group does that can take complex tasks and break them into simpler > or more manageable tasks? It may sound like a weird question, but there > must be some guidelines, best practices, or habits used to achieve > success in designing/developing a complex project. I'm sure there must > be some individuals out there that are constantly taking complex tasks > and just about every time have success with it. Short of speaking, I > want to know what's the secret to their success. All comments are > welcomed, even the most obvious suggestions. > > As an engineer, I'm constantly trying to improve my design processes. Howdy Joe, In addition to the excellent suggestions that others have already posted about design steps, tools, resouces, etc, I believe it is pretty important to: 1. Have VERY well defined requirements 2. Have a good understanding of the requirements 3. Have requirements that don't change a lot over the course of the project 4. Have at least a few engineers with enough foresight to anticipate likely changes to the requirements so that minor alterations don't result in a complete redesign 5. Start with known good designs (or parts of them) whenever possible 6. Have engineers you trust to get the job done and let them do the work A few notes on some of these: On #6: Don't waste the engineers' precious hours each day by constantly looking over their shoulder (or dragging them into hour long status meetings every day). Other posters have mentioned aspects of #5, but I'd like to expand on it: starting with a known good design (or hierarchical block) not only saves time and effort during the initial design, but pays off even more when debug time comes around. If parts of a design are known to be good, debugging efforts can first focus on the newer stuff that isn't as trusted. It also provides a base of commonality for higher level stuff (like software). With regards to #4, I'm not saying that all the engineers on a project need to be experienced. But probably 1 in 5 (or so) should be, in my opinion. #4 can also can directly feed into #5. A well designed unit can be reused for many other applications, saving absolutely HUGE amounts of time in the future(*). Said another way, blocks should be as generic as possible so they will be more likely to be easily reused. BTW, you haven't defined what a succesful project is. If part of the definition is on-time delivery, there may be fewer "successful" complex projects than you think :-) Have fun, Marc (*) Very simple example: As long as it does NOT use more resources, rather than creating three different cores for 512x6, 128x8, and 256x9 memories, create one that is 512x9 and use it in all three instances, tieing off unused inputs.Article: 87343
methi wrote: > I am trying to delay a pulse by N ticks where N takes a maximum value > of 3454...N is a variable here.... How wide is the pulse? Answer in clock ticks, please. I think we're assuming that the pulse exactly one clock tick wide. -aArticle: 87344
austin wrote: > Martin, > > Generally speaking, if there is no reason to change, then change is > probably not worth it. > > Any change has to be requalified (by you), and that can be expensive. > > However, the new tools also do a better job of routing, and placing, > and you may get a whole speed grade improvement by using the newer > tools (even with an older family part). > > If you are presently using a faster than slowest speed grade part, or > you can use more speed to better advantage, then upgrading to the > latest and best tools have benefit. Howdy Austin, Not knowing which device(s) he is using, I don't think that can be said any longer: http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=21382 (which implies to me that higher speed and/or density designs in the older families [Virtex, Virtex-E, Spartan-II and Spartan-IIE] probably should stick with 6.3). Best regards, MarcArticle: 87345
Brandon wrote: > I'm new to FPGA synthesis and XST, so I could use some help. > > I'm synthesizing an entity for the first time, and I'm receiving > warnings and errors related to the time type in my models. I realize > that they are not synthesizable. I'm okay with the warnings because I > have them in there for functional simulation only. > > Here is the output from XST in Foundation 7.1: > > <SNIP> > > WARNING:Xst:828 - "/../../../../work/toplevel.vhd" line 28: Constant > <TPDREG> of type Time is ignored. > WARNING:Xst:1537 - "/../../../../work/toplevel.vhd" line 93: Generic > <tpdreg> of type Time is ignored. > > Analyzing generic Entity <component_g> (Architecture <structural_ar>). > ERROR:Xst:834 - "/../../../../work/component_g.vhd" line 58: Generic > <tpdreg> has not been given a value. > --> > > </SNIP> > > It seems to me like XST is ignoring the time types and then later > complaining about a generic of type time in the component > instantiation, the value of which, is propogated from a higher level. > Any thoughts? It's sorta weird that the top-level entity is being synthesized before the lower level entity. Also, according to page 295 of the XST User Guide v7.1i, "Generic parameters may be declared in the entity declaration part. XST supports all types for generics including integer, boolean, string, real, std_logic_vector, etc." but then, on page 314 under the heading "VHDL Language Support," we're told that in the entity header, Generics are supported for integers only, and further down, under "Physical Types," we're told that TIME is ignored. You may be best off using "synthesis translate_off" and "synthesis translate_on" pragmas around the generics you don't want XST to see. -aArticle: 87346
John, I would be surprised if the difference between 5 and 6 ns, or between 10 and 12 ns really matters. Do you have a feel for the specification tolerances? Peter AlfkeArticle: 87347
JJ, I hope you realize that 3 BRAMs is all you need. Nobody would suggest to replicate them. For what?? Peter AlfkeArticle: 87348
Ray, I agree 100% with you. Sorry for the flip remark. It's easy to change the count modulus. And the read-before-write feature in all the newer Xilinx BlockRAMs is a real bonus. I owe you one... Peter AlfkeArticle: 87349
Gary, your algorithm works out on the trusty calculator, but Allan, your algorithm "does not compute" :) Am I missing something or could you walk me through this? Y1 = (X + X<<1) Y2 = (Y1 + Y1<<4) Y3 = (Y2 + Y2<<8) Because I don't see how this ever gets smaller than X, assuming X is the number I'm trying to divide by 5. Thanks, Shanon
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