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
I have it from the man himself: Steve Knapp has not been kidnapped. He is not even on vacation, he is at work here at Xilinx. He encountered problems in accessing the newsgroup, probably due to a paranoid firewall. I suggested to him my solution, use google: http://groups.google.com/group/comp.arch.fpga/ Peter AlfkeArticle: 87976
Brad, email a pdf or jpeg or other "readable" format of the schematic detail of the config only (FPGA + wires to prom). I can quickly have omeone look at it, and see if they can spot what you are doing wrong. 'DONE does not go high' is the #1 complaint we get, and after 20 years, you would think that whatever could go wrong, has gone wrong, and this would be simple. Unfortunately, it is somethign simple, that was overlooked. And even though you are a bright smart engineer, no amount of you looking at it will catch it (obviously because you missed it already). Don't stress, just get another set of eyes to look it over, Austin AustinArticle: 87977
has anyone used any of the extreme dsp development or evaluation boards which use the v4 sx35 (i think) how are the interfacing tools ? drivers (linux/windows)? detailed schematics? Reference designs? thanks for your help -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 87978
On Thu, 4 Aug 2005 11:57:51 +0100, "Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote: >>>I brought the question of async vs. sync reset to the group awhile ago, >>>and someone told me (they should harp in here to get credit), that with >>>an async reset you may have metastable issues when your reset goes >>>inactive, which sort of defeats the purpose of having a reset. So this >>>sold me on sync resets, end of story. >> >> Actually this is a false compromise. There is a perfectly safe way of >> synchronizing the reset to your local cock(s) so that there is no >> chance of metastability regardless of the reset release time. This way >> you can continue to use async resets. > > >If you generate a synchronous reset signal then connect that to the asynch >reset input of the registers in your design, can you be sure that the tools >include this path in the timing analysis? > >It be a reasonable assumption of those designing the timing analysis tools >that anything going to an asynchronous input doesn't need to be included. The Reset to Clock path of a flop is very similar to Input to Clock path and in all libraries I have used it is a timing check which is included in the flop description. The release time of the reset is checked against the clock pulse. By supplying a registered reset, you are allowing to STA tool to do a better job because now it has an availabitlity number for reset with respect to clock which can be checked. Of course this assumes that your cell library has the reset to clock timing checks.Article: 87979
The german-impaired of us could maybe use that explanation too ;) -- Brian Sean Durkin wrote: > Monica schrieb am 03.08.2005 11:28: > >>Hallo, >> >>I am a newbie evaluating xilinx tools & FPGAs for our project.Our >>company traditionally uses altera.We have bought a j83 ac modulator >>IPcore from Xilinx.In the ISE I have implemented the design. >> >>Now the manual says I must import the EDIF netlist generated by ISE >>into a new project and use it as blackbox. >> >>I couldnt find any importing button in ISE to import EDIF netlist. >> >>I read some answers on xilinx website and this news groups.They simply >>say "import the netlist into ISE project". >> >>can anybody help me how to do it?What is file extension for EDIF >>netlist? > > Du musst im HDL-Code für das Toplevel den Core wie jede andere Entity > deklarieren und instanziieren. Durch die Instanziierung merkt ISE, dass > dieser Core gebraucht wird. Wenn für diese Entity kein HDL-Quellcode im > ISE-Projekt vorhanden ist, wird sie im "Project Workspace" mit einem > Fragezeichen vorne markiert, und ISE versucht dann bei der > Implementierung, eine Netzliste dafür nachzuladen. Dabei durchsucht es > das aktuelle Verzeichnis und das, das im Projekt als "Macro Search Path" > angegeben ist (den kann man in den Properties für den > "Translate"-Schritt einstellen, das ist der Suchpfad für Netzlisten von > IP-Cores), dort muss dann das EDF-File liegen. > > Also: EDIF-Netzliste ins Projektverzeichnis kopieren, Core im Toplevel > instanziieren, den Rest macht ISE. > > cu, > Sean >Article: 87980
On Thu, 4 Aug 2005 10:45:04 -0700, "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote: >Hmm. I have to admit that I didn't think of this. So you can register >your reset at the IO pin and then have that synced output drive the >internal global reset? Is that right? > >>> Actually this is a false compromise. There is a perfectly safe way of >>> synchronizing the reset to your local cock(s) so that there is no >>> chance of metastability regardless of the reset release time. This way >>> you can continue to use async resets. > In a way yes and it's safe to do. You don't register the reset signal though. Assume you have an active low reset. You connect input of a flop to 1 and connect its async reset input to the reset io pin, a second flop takes the output of the first as input and it's also async reset by the io pin. These are clock by your local clock (of course you have to make sure that for every clock domain in your design, you repeat this process). So now when reset io is on, both flops are reset which also resets your design. When reset io goes high, the first flop can get upset if it's close to the clock edge but the second flop is perfectly happy as its input doesn't change at the same clock. On the next clock it sees the high value on its input (as the first flop is not being reset anymore) and propagates it to its output (as it's not being reset either). This works very nicely if the library has the reset to clk path characterized and timed.Article: 87981
Hi Austin, austin wrote on 04/08/05 21:11: > 'DONE does not go high' is the #1 complaint we get What's #2? :) For me the biggest complaint is the drivers for the Parallel Cable IV. The same cable works fine on one PC, but is detected as a Parallel Cable III on another, no matter what settings you use for the parallel port, and no matter what kind of board you hook it up to. Most of the time it's slow as hell, taking a minute or so to program a bigger V2P, which makes rapid prototyping not so rapid anymore... After spending a few days trying out different cables with different PCs and all ISE-releases and Service Packs I could get a hand on, and doing a *LOT* of research, I found that the problem is definitely that Jungo windriver-parallel-port-thingie you ship with ISE. On their website it just says that with "some parallel port chips" it simply doesn't work well, mostly "Intel based chips" (and these are so rare to come by these days...), and that's that... We're starting to switch to USB platform cables, but there's still a whole bunch of parallel cables in use which would be okay if only that driver worked on more machines... cu, SeanArticle: 87982
Actually, this syntax was ok: port map (... P => unsigned(S) ...) While this was not: port map (... unsigned(A) => B ...) I don't understand why they haven't fixed this... Is there any sort of option to toggle VHDL-93 syntax? I can't find any mention of it in the XST user guide... If you don't mind, could you explain the wrapper workaround? I made the changes manually myself, but that involved creating a duplicate signal to perform the type conversion on. This is quite sloppy imo, and I dislike having to tailor my code to a specific tool. Thanks a bunch.Article: 87983
Brian Dam Pedersen wrote 04/08/05 21:31: > The german-impaired of us could maybe use that explanation too ;) OK, here we go: All you have to do is declare and instantiate the core in your toplevel HDL-file like every other component. That way ISE knows that this entity is needed, and if there's no HDL-source for this component it's displayed with a question mark in the "Project Workspace". In the implementation phase, ISE searches the project folder for an EDIF netlist for the core you instantiated (so the filename should match the component name in your HDL), so all you have to do is put the netlist there for ISE to find it. Alternatively, you can set the "Macro Search Path" in the "Translate"-properties to a different folder and put the netlist there (in case you have a general repository for cores for all your projects). To sum it up: 1. Instantiate the core you want to use in your HDL-code 2. Put the EDF-file in the project folder or in the folder specified in the "Macro Search Path"-option. cu, SeanArticle: 87984
Hi Antti, Thanks for the advice. Luiz Carlos P.S. Your "OTOH" took me some time to decode!Article: 87985
Jim Thompson wrote: > On Thu, 4 Aug 2005 07:59:08 -0400, "Clay S. Turner" > <Physics@Bellsouth.net> wrote: > Yes, But certainly not the one who made P4's slower than P3's, for > numerical operations. Isn't that clock for clock? My understanding was that they had to make architectural changes in order to be able to run the things at a higher frequency.. JEremyArticle: 87986
Hi Peter, > Ben, I started out with "all in the FPGA". Then I found out that the > $5.- LCD diplay has its own built-in micro, and the 1 ppm oscillator > costs more than the FPGA, as do case and power supply together. As does > the pc-board with the regulators. Oh, no sweat, really. It's just that the description you initially gave gave me the distinct impression that you said you could do the <100ps jitter timing across this range with just a good oscillator and a Spartan alone - which after a lot of thinking caused me in the end to conclude that you either are 1) hiding something 2) a true elite Black Hat FPGA haxxor 3) lying your ass off Turns out the answer is 1 - the external programmable PLL and a good PCB. > That's were I became pragmatic and decided to design something useful > first, FPGA-centric second. This reinforces my idea that answer 2 might not be that wrong ;-) Best regards, BenArticle: 87987
Hi Paul, > I am currently using the evaluation open-core FIR compiler and NCO > compiler in the design and when I use these I am not able to perform > incremental synthesis. Does anyone know if you can perform incremental > synthesis with these cores once the cores are licensed? as synthesis steps > are taking upwards of 20-30 minutes at the moment and it is becoming quite > painful not having incremental systhesis. You _should_ be OK with the licensed cores as well. The only difference between the licensed and the unlicensed version is the Big Counter that will shut the core down after an hour. Better yet, in Quartus II 5.0 (out since June - why are you still on 4.2?) you should also be able to do incremental P&R of your design. This last bit may or may not cost you a bit of performance as the design optimization is hindered by the fitting boundaries, but it should save you loads of time between iterations. Best regards, BenArticle: 87988
Here is part of the secret: The Spartan3 actually reduces the jitter down from the fundamental +/- 3 ns ( from the 160 MHz clocking of the DDS accumulator) to 300 ps. I then use the external PLL to multiply the frequency to max 640 MHz, and also to reduce the jitter to 85 ps. The secret sauce in Spartan3 is a hidden (undocumented) mode in the DCM that makes the DCM multiply the frequency without phase-locking the output to the input. (I do not care about phase-lock) Unfortunately (and unavoidably), this also introduces frequency wander, where many long periods (long by max 85 ps) follow each other, until they are followed by many short (by max 85 ps) periods. This wander is non-critical for testing memory interfaces or microprocessors, but cannot be tolerated as telecom references, since it looks like slow frequency drift. Next step: eliminate the wander while also reducing cycle-to-cycle jitter. There is more than hope... We learned a lot, and we have excellent instrumentation, from Tektronix and LeCroy... BTW: option #3 is not acceptable. Peter AlfkeArticle: 87989
geoffrey wall wrote: > has anyone used any of the extreme dsp development or evaluation boards > which use the v4 sx35 (i think) > how are the interfacing tools ? drivers (linux/windows)? detailed > schematics? Reference designs? > > > thanks for your help > > > The boards are great, we got a few of them as well as from the previous versions. We have chosen for the Extreme DSP kit, because it's really plug and play. You don't need to develop a PCI controller and driver before doing experiments with your own application. It's a piece of cake making a programmers interface from an application running on the PC controlling the card over USB or over PCI. I haven't seen schematics, but I didn't need them as the user manual provide enough information. The manuals, reference designs, driver, Software an the Nallatech support are of a high quality level. The dissatisfiers are: the slow response to single writes over USB, the slow configuration over USB (it takes about 2 minutes to program the SX35 .... amazing). Further I don't like the cooler that is mounted on the SX35. The chip is "cool" but practical it isn't. The pricing could also be somewhat better. Further, Nallatech has an own philosophy about providing Software/drivers updates etc. You need password to retrieve the information from their website. RoelArticle: 87990
Peter Alfke wrote: > Here is part of the secret: > The Spartan3 actually reduces the jitter down from the fundamental +/- > 3 ns ( from the 160 MHz clocking of the DDS accumulator) to 300 ps. I > then use the external PLL to multiply the frequency to max 640 MHz, and > also to reduce the jitter to 85 ps. > > The secret sauce in Spartan3 is a hidden (undocumented) mode in the DCM > that makes the DCM multiply the frequency without phase-locking the > output to the input. (I do not care about phase-lock) Unfortunately > (and unavoidably), this also introduces frequency wander, where many > long periods (long by max 85 ps) follow each other, until they are > followed by many short (by max 85 ps) periods. This wander is > non-critical for testing memory interfaces or microprocessors, but > cannot be tolerated as telecom references, since it looks like slow > frequency drift. So, this mode is about to become documented, and user accessable ? > Next step: eliminate the wander while also reducing cycle-to-cycle > jitter. There is more than hope... We wait for V2.0 :) -jgArticle: 87991
Marketing decided NOT to document this mode, and after detecting the hard-to-quantify wandering behavior, I gave up fighting for the release. It obviously works, but is not easy to test and support. I accept that the Southern Hemisphere will wait for V2.0, hopefully (your) early summer... Peter AlfkeArticle: 87992
I had the similar problem. My solution is to change the C3 value to 68pF and R11 value to 47 ohm. this will solve your problem.Article: 87993
jjlindula@hotmail.com wrote: > Hello, to be brief SE involves requirements analysis, risk managment, > controlling your design processes, interface control, supportability, > realiability, maintainability, reproducability, peer reviews and > technical reviews, test planning, integration planning. SE is used to > manage a project to control costs, schedule, and performance. I"m still > learning all the areas and probablity left out a ton of stuff. > Although, I'm more interested in the technical side of SE, rather than > counting the money stuff. Depends how much time, money, and resources you've got and what you are working on. On military projects for example (I've worked on several) you've usually got plenty of all three. In this case you would (and are required to) do a lot more paperwork stuff like requirements analysis, risk management, supportability, integration planning etc. But to real design engineers this sort of stuff adds no real value, i.e. you aren't using your time to produce anything useful. A commercial project on the other hand with limited budget, time and resources, where you are expected to produce miracles, you just need to get the job done. Any formal process that doesn't add value in getting the job done is simply ignored. Of course you always keep one eye on the important side stuff like requirements, testing, maintainability etc, but you couldn't care less about formal risk management and integration planing for example. Peer reviews are valuable in ANY situation. Often these are informal like "I'll check the schematic over while I'm on the can". Dave :)Article: 87994
Thanks Jonathan,
I have now got it working more or less that way I would like, I will auto
generate all the various mif files ahead of time and then select the correct
one using the following method (which is a variation on your suggestion).
module nco(clk, clk_en, reset, phi, sin, cos);
parameter ACC = 18;
parameter PHA = 17;
parameter AMP = 12;
localparam [7:0] PHA1 = "0" + (PHA % 10);
localparam [7:0] PHA2 = "0" + ((PHA / 10) % 10);
localparam [15:0] PHA_NUM = {PHA2,PHA1};
localparam [7:0] AMP1 = "0" + (AMP % 10);
localparam [7:0] AMP2 = "0" + ((AMP / 10) % 10);
localparam [15:0] AMP_NUM = {AMP2,AMP1};
--- skipped various lines to get to interesting bit----
defparam sin_lut.INIT_FILE = {"sin_lut_",PHA_NUM,"_",AMP_NUM,".mif"};
This seems to be working fine,
I have tried a number of different approaches to get it down to fewer lines
such as
localparam [15:0] PHA_NUM {("0" + ((PHA / 10) % 10)),("0" + (PHA % 10))};
and
'define NUM(a) {("0" + ((a / 10) % 10)),("0" + (a % 10))}
then using
defparam sin_lut.INIT_FILE = {"sin_lut_",`NUM(PHA),"_",`NUM(AMP),".mif"};
but neither of these approaches work, which is a shame as the solution I
have seems unnecessarily large and messy.
Thanks again for your help
Regards,
Paul Solomon
Article: 87995I'm a digital ASIC engineer looking for some *beginner* (not reference/advanced!) books on Orthogonal Frequency Division Multiplexing (OFDM.) Well, hopefully such a book exists? The book I already have "Multi-carrier Digital Communications: Theory and Applications of OFDM" (by Bahai, Saltzberg, and Ergen) seems a bit beyond me. It's a great reference for researchers, but as you've probably guessed, it's difficult for math-challenged engineers like myself to put that into practice.Article: 87996
in that case is there any better procedure/tool with which i can analyse timing issues better than simulation. Please suggest any books/materials on this topic. I agree that the real silicon is the best model. But how can we analyse it if there is some problem in the timings ??? Thanks for your advice Sumesh V SArticle: 87997
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message news:1123142445.607473.191750@g14g2000cwa.googlegroups.com... > > Fred Marshall wrote: >> <jjlindula@hotmail.com> wrote in message >> news:1123083687.394543.131660@g49g2000cwa.googlegroups.com... >> > Hello, to be brief SE involves > >> controlling your design processes - isn't there a VP Engineering to set >> policy? Isn't there a way to communicate what's working and not working? >> It must be a really overdone project to need a *person* dedicated to >> this. > > In R&D, there is no such thing as "policy" or "corporal memory". > I have never met a "scientist" or "researcher" who did acknowledge > that skill and competence were personal attributes, that each > person have to make an effort to gain for themselves or communicate > to others. "What do you mean I can do better? I am a professor at > [insert your favourite university or R&D organization here], for > crying out loud!" > >> reproducability - I think you mean produceability. > > Not necessarily. Some attention to reproduceable results would keep > certain not entirely all that good techniques from enetering the scene. > Remember, R&D is all about "publish or perish." Making a second check > of those "brilliant" results might lose a much cited paper. > > "Never measure twice." > >> Just part of good >> engineering with adequate discussion with the manufacturing folks. Not a >> special discipline / position. > > The common R&D argument is that "we do this only once, there is no need > > to build a system around this activity." > >> integration planning - the system guru takes the lead and, unless the >> guru >> does it all alone (which is common) then it's a group activity. > > Again, since an R&D activity usually is done only once, or a couple > of times at most, no one see the need for systematic planning. > > These are the factors that in my experience separate R/D from > engineering. > In R&D, stuff like the above are generally considered "waste of time > and > talent". > >> To make a point: >> It is told that a Japanese company licensed the production of an American >> engine. They took the original drawings and began production. But they >> couldn't build engines with those drawings! Why? Because at that time, >> the >> Japanese built all the parts to exceptional tolerances so there could be >> virtually 100% interchangeability. And, because at that time, the >> Americans >> had built the parts to looser tolerances and were willing to do some >> mixing >> and matching of parts, they didn't recognize that the dimensions in the >> drawings were "wrong" - that is, a working engine could not be assembled >> out >> of a set of parts that were perfect according to the drawings. I don't >> know >> if the story is true but it's sure interesting..... > > Heh, that's my average experience when I try to make some algorithm or > technique work, be it from an academic paper or an in-house technical > report: The documentation doesn't work. Either there are typos, the key > > tricks are left out or "documentation" is taken to mean "a short > general description of a concept". I don't think I have ever > implemented > a technique based on a single document "and the references therein". > > I always had to go to other literature, and more often than not, do the > > complete derivations myself to make sure I got it right. > > Rune Rune, It's clear that you're heavy on the "R" in R&D. I'm heavy on the "D" in R&D in these descriptions but I've also done "R" and there are different objectives to be sure. Reproducibility is important in "R" and early stages of "D". Producibility is important in "D". Reproducibility should be a foregone conclusion at this stage. et cetera FredArticle: 87998
> I'm a digital ASIC engineer looking for some *beginner* > (not reference/advanced!) books on Orthogonal Frequency > Division Multiplexing (OFDM.) Well, hopefully such a book exists? You probably dont need a whole book, if you are just looking for an introduction! There are some very good introductory papers on OFDM, have a search on IEEEXplore... PorterboyArticle: 87999
HI, SE (System Engineering as well as Software Engineering) is always a problematic field. I don't think, that you will find a project that uses all possibilities nor a (sucessfully finished) project that ignores every aspect of SE. I think the most companies use a more or less golden middleway. We use any point mentioned above but in some cases a bit weaker than my old SE teacher would like. We did this whole effort only for ASICs in the past but actually changed to use these techniques in every design. Of course this leads to a overhead of paperwork especially for small projects but pays when it comes to products (not very funny if a bug rise after the last chance of repair is gone and therefore need a rebuild). bye Thomas
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