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
Jay wrote: > Why don't you give it a rough cut, then synth, and P&R and see what > you get. If you're a designer of similar caliber to some of the > regular posters on here then you should have a good shot at it. We > run our ECC SDRAM interface at 25MHz, but then again, its a standard > cell design being proto'd in a Vertex 2 6000, not a purpose build FPGA > design. > So far I've manged to push ours to 100MHz or so in an XCV600E-6, no floorplanning or hard macro'ing, just the auto P&R tools. The target/goal, after some floorplanning & much sweat+cursing etc, is 125/133Mhz in a -7. Then, sometime in April, we'll move to the V2 and I'll start similing again.Article: 39301
Philip Freidin wrote: > It's a TROLL, don't encourage it. Is that some sort of Hipcrime variant ?Article: 39302
Hi, Thanks for the quick response; comments embedded below. Austin Lesea wrote: > > RK, It's rk, not RK. It looks funny in big letters. ;-) > The concern is that if you inject enough current below ground, and > forward bias the parasitic SCR structure, you may cause latchup. A few > years ago we were really worried about this for 4K (a customer had done > no signal integrity engineering, and created an SI nightmare for his > company), so we wired 128 outputs through 1 foot of transmssion lines (50 > ohm coax) to 128 inputs in order to provide the horrendous overshoot and > undershoot required. We were slamming > 20 mA on each and every pin, > both above 3.3 Vdc and below 0.0 V by as much as .71 volts (after all, > the diode is clamping as hard as it can, so voltage doesn't tell you > anything at all--you need to know the current). Yup; I was just relaying what I had. Another engineer went to a meeting and brought back a set of viewgraphs. They simply had recorded one parameter of the ground bounce, max voltage. Also, I don't have a physical model of the board so I don't know how long the lines were, how many loads on it, nada. From the cartoon that they showed, it didn't look like it was clamping; it was just a tiny little peak, no flat top. It was not an oscilloscope picture. Based on the XQR400XL data sheet, it didn't seem like there should be a problem in the FPGA, although some people were saying it might have latched up. During transitions, the device pins may undershoot to -2.0 V or overshoot to + 7.0 V, provided this over- or undershoot lasts less than 10 ns and with the forcing current being limited to 200 mA. They didn't have a time scale on the picture or currents. 200 mA on a whole pile of pins is a whole mess of current. Doubt they did that for 10 ns. > No problem. > > It seems that to trigger the SCR latchup, it requires a steady currents > for many tens of nanoseconds, at currents greater than 300 mA for the > entire edge, at a voltage above or below ground by a diode drop. > > These tests were done on 4Kxl and 4Kxla, which had almost identical 0.35u > IO transistor structures. This was, as far as I know, an XQR device, although I'm not sure. Info is sketchy. :-( > Bottom line, don't do that! Yikes! I didn't do anything! > Even if the design doesn't latch up, it will > have incredible jitter, and probably have other problems caused by all of > that ground bounce. Any voltage that causes the diodes to be forward > biased is going to lead to problems, one way or another. As "just an old > engineer" you should be familiar with signal integrity from the days when > being an engineer meant you knew what Ldi/dt meant, and knew how to > calculate the voltage at the end of a transmission line. Yup. I don't like designs that turn on the diodes at all. But that's just me. > Now latching up the SDRAM might well be possible (maybe they didn't have > time to characterize the parasitic SCR structure, or to control the > alphas of the npnp stucture), but don't blame the FPGA! If you hit it > with a hammer, it would break, too. Is it the hammer's fault? I blame no one. Yet. ;-) I just hadn't messed with DRAMs in a while, been using SRAMs, and don't know how susceptible the devices were to latch up. The last few times I did DRAM designs, I was very, Very, VERY careful to have nicely terminated lines, controlled impedance boards, and did not allow the signals to go below ground or above Vcc and didn't have any problems. From what I can tell from the little bit of information that I have, they didn't have terminated signals and were using high-slew outputs from the FPGA. They apparently didn't test the SDRAMs for latchup from driving inputs below ground as part of the failure report. Me, being a bit lazy, don't want to have to set that up and do that. So I was hoping someone here might have some experience with more modern SDRAMs. Thanks! -- rk Just an OldEngineer > > Austin > > > > > rk wrote: > > > Hi, > > > > A friend asked me a question and perhaps someone out there can help. > > There > > was a Xilinx 4036XL hooked up to an SDRAM (no, he didn't know what > > manufacturer and model) and the claim was that groundbounce in the FPGA > > > > from SSO's caused the SDRAM to latchup; this was supposed to explain a > > functional failure that would be cleared by cycling the power. > > > > That sounds a bit odd to me, although I haven't used SDRAM and am not > > familiar with their details. For a low, quiet output, they measured a > > 710 > > mV peak below ground; that doesn't sound too bad, about a diode drop. > > Again, I don't know what's going on inside SDRAM technology so I > > thought > > I'd ask and see if anyone has any experience with this. > > > > Thanks in advance, > > > > -- > > Just an OldEngineerArticle: 39303
In article <ee74ad1.6@WebX.sUN8CHnE>, ls@swissonline.ch says... > I really do not know what is wrong with you guys. Why donīt you just admit that 80% of your applications could be implemented by using 16V8s? I believe a very intelligent guy like Ray Andraka could fill up a ispLSI1032 (have you seen all that complicated stuff on his web page??). But: most of you guys?? Be serios with me, please!! I mean, you guys use a Spartan or even Virtex part and leave 99% of the resources free, donīt you? Then you sell the application and claim that you have spend weeks or month to fill it up. Honest engineers like me do only charge the real work they have done. And this usually fits into a 16V8 and sometimes into a 20V8 and for real big stuff into a 22V10. Why donīt you just admit that I am right? > > And: What do you want to tell me about MP3 players and so. I mean, I can buy a MP3 player at Freys or so and nobody really develops that complicated stuff himself. This usually is the hard work of multiple engineers at Sony or so. > Yeah, you're right. I didn't use more than 10-15% of a Virtex 600E. However, I did use 514 out of 512 I/O (neat eh?) and LVCMOS, LV_PECL, HSTL, and LVTTL I/O levels though. Then there was the that DLL, thingy. Now, go back under your bridge like a good little troll. ---- KeithArticle: 39304
In article <1012949075.213793@busy.neca.nec.com.au>, jamesf@xxxnec.com.au says... > Hi, > > just scored some used, but reusable EPM7064 gate arrays that I would like to > use in some home projects. Unfortunately they are NOT "in circuit > programmable" and require a seperate programmer. > > The Altera web site has no details on programming these devices, but do have > free software for circuit entry etc. > > Can a programmer be built by me for these parts (I don't need high speed or > flexibility)? Obviously my budget doesn't allow for a bought one - unless > extremely cheap (few 10s of $), else I'd just buy one. > > Does anyone know where programming details can be found? Surely such details > are freely available! > > My return address has been corrupted. > To reply either remove the 'xxx', or reply to the group, or email > > james.fenech (at) nec.com.au > > Thanks, > James. > > > > James, While someone will eagerly correct me if I'm wrong, I believe that you are out of luck on doing your own cheap programmer. I was using EPM5xxx/7xxx parts back in the 1990-1995 timeframe. IIRC, the programming of these chips required a shaped-timed pulse (current, voltage, and dV/dT controlled) on multiple pins. The published programming details were quite limited at that time (viewed as semi- proprietary IIRC, and at a later date even the limited programming data was dropped from the Altera documentation [probably because it was not useful to an end-user anyway]). There was no cheap way to programm the chips other than Altera's programmer hardware ($700~ for programmer and chip adapter) or one of the Data-I/O generic Programmers (with adapter and software, $3K~). This was one of the reasons Altera (and everyone else went to ISP in the first place). Maybe your "source" also has an old Altera programmer box stuck in a cabinet gathering dust? Suggest that you consider your salvaged parts as "wall-art" and plan on using ACEX-1K which are ISP and fairly cheap and also have "App Notes" available on how to build your own "cable/programming-adapter" for a PC. Don't be surprised if someone else jumps in to say that you would be better off with Xilinx and their "Free Webpack". Either way, Good Luck!!Article: 39305
On Tue, 5 Feb 2002 12:59:44 -0800, ls_user <ls@swissonline.ch> wrote: >next time i will tell you something about 74LS00īs. Will get some of you with that as well. > >have a nice evening What a sophisticated jokester you are! Here you had us thinking that you were some kind of bozo, when in fact you're a...oh, wait a minute. Bob PerlmanArticle: 39306
James wrote: > > Hi, > > just scored some used, but reusable EPM7064 gate arrays that I would like to > use in some home projects. Unfortunately they are NOT "in circuit > programmable" and require a seperate programmer. > > The Altera web site has no details on programming these devices, but do have > free software for circuit entry etc. > > Can a programmer be built by me for these parts (I don't need high speed or > flexibility)? Obviously my budget doesn't allow for a bought one - unless > extremely cheap (few 10s of $), else I'd just buy one. > > Does anyone know where programming details can be found? Surely such details > are freely available! No, because the support is too costly. It wont work first time, and then what happens... You might find an old programmer that supports the non-isp models, but better is to move to ISP CPLDs In this class of CPLD are Altera 7064S - newer ISP versions of those you have Xilinx CoolRunner XCR3064 Atmel ATF1504AS Atmel have the best 5V support. -jgArticle: 39307
Altera guys can correct me if I'm wrong, but I believe the version of Modelsim that is packaged with Quartus II is a stripped down version that has limitations for the size designs it simulates quickly. If designs are above a certain size, I believe that the simulator slows considerably. Good luck "Paul" <nospam@nospamplease.com> wrote in message news:o1Z78.4838$il3.839543@news6-win.server.ntlworld.com... > I'm investigating ways of improving my development throughput. > > At the moment I'm using Leonardo Altera Edition for synthesis, Altera > Quartus 2 for P&R and Quartus 2's simulator. > Targeting Apex 20KE600-1X devices > > I'm using an Athlon 1GHz with 512MB RAM. > > I'm in the middle of a project and am finding that as the design comes > together, compilation and more especially simulation is becoming a real > problem. > > I realise that the most positive step may be to either use the Modelsim > Altera edition or invest in a full Modelsim license. > > The problem is that Modelsim does appear somewhat more cryptic than using > Alteras offering. Plus I'm mid-project so changing from my *.vwf approach to > modelsim may take time I haven't got. :) > > What I'd like is > > a) How much better is Modelsim than Altera's own simulator especially for > post layout analysis. Since that's like asking about string length, I'd > accept anecdotal evidence based on your own designs :Ž) > > b) Are full versions of Modelsim that much faster than the Altera edition. > > c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual > processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound > or memory bandwidth bound) and does an MP setup provide any noticeable > improvement or are all tools resolutely single threaded. > > d) Any other suggestions. > > I am already trying as best I can to restructure testing to minimise the > issues, but these 10 hour simulation times (when it doesn't crash) are > really non-productive. > > Paul > > Background on the design, though probably of limited additional help: > > Typically my designs use a lot of EABs as FIFOs, a lot of 32bit register > moving about and various high speed memory interfaces 120MHz SDRAM x 2 on > each chip. Logic is relatively simple and I believe I've taken enough > pipelining precautions to limit routing problems. > > I'm trying to simulate passing message packets in, processing them, storing > them, acting upon them etc. To capture a large part of this as the system > comes together I'm finding I need simulations of up to 10ms (though 1ms is > more typical). > > I've simulated at individual block level, so its really only the last level > of testing that > > >Article: 39308
Antonio, The reason is very simple, using clock enable you actually adding a multiplexer in front of every clock enabled flip-flop. There is more logic in every path that ends with a flop. The good news is that you probably have multi cycle paths. You have to tell to the P&R about these paths and then the max clock frequency will rise up again. Nurit dottavio@ised.it (Antonio) wrote in message news:<fb35ea96.0202032328.296fe30@posting.google.com>... > I coudn't understand why for a gated clock project I was fighting to > obtain 150MHz and now with > the clkEnable version of the same I'm fighting to obtain only 70MHz, > to what this is due ?? > All suggest me to use clkEnable if there are situation where clock > enable is not a must, is it > really necessary in my project where I've a master clock from which I > obtain 3 derived clock in > the gated clock version and 3 enable signal (...via a programmable > counter) in the clock enable > version. And to put in my thesis and based on your experience please > add some lines to the following: > > *********************************************************************************************** > Clock Enable Clock Enable Clock Enable Clock Enable Clock Enable Clock > Enable Clock Enable > *********************************************************************************************** > PRO > P1) Immunity to temperature change > P2) Only CLK recognized by synthesizer > > VERSUS > V1) slow (.. I don't know why) > v2) More power dissipated because all the circuit run at f_clk > > > *********************************************************************************************** > Gated Clock Gated Clock Gated Clock Gated Clock Gated Clock Gated > Clock Gated Clock Gated Clock > *********************************************************************************************** > > PRO > P1) Less power dissipated because not all the circuit run at f_clk > P2) > > VERSUS > V1) Derived clock not recognized by synthesizer > v2)Article: 39309
Ciao Luigi, have you already looked at AN39? You can download this PDF document through the Altera's web site. I think you can find what you need. Marco guiducci@cern.ch (Luigi) wrote in message news:<235ed672.0202050639.17879a70@posting.google.com>... > I'm a student and I'm developing a design on an APEX20k. This device > is not really a choice now, I just started to try Quartus. I'll have > the need to add a jtag chain, not attached to the boundary scan one, > but parallel, to be used for some configuration registers I'll have in > the chip. It seems that the apex has a built in port, the tap > controller, a boundary scan registers chain (in silicon?). No way to > add what I need using basically the same jtag port? I could rewrite by > hand all the jtag circuitry, but would this mean I could not use > anymore the pin-dedicated fast input/output registers? > Sorry if i wasn't clear or if it's a stupid question > > LuigiArticle: 39310
Hello, I'm looking for a Virtex 2 method to convert (or approximate) the angle from the rectangular coordinates (x, y) of a point. The x,y coordinates are coded on 16 bits. Thanks for your help YannArticle: 39311
ls_user <ls@swissonline.ch> wrote: > Thank you, John. But: What is a FFT. Why should I wnat to implement something what I do not know? I can do everything I could imagine by using 16V8s and 20V8s and I believe most of you guys could do the same. However, it seems to be the trend to use larger devices. My believe is that most people use large FPGAs and leave all the not used area free. All of them could use 16V8s and save a lot of money. I just want my applications to be functional and have the lowest device cost. Poor stupid FPGA users! I guarantee you that for the application I'm doing, I couldn't fit enough 16V8s on the board (ignoring the power budget). Possibly not a few cubic metres. And do those run at 160+ MHz? Fortunately, the 2V6000 in an 1152 pin BGA package is a little bit more power and density friendly. I'd like to see a board full of PALs running 10 gigabits per sec throughput. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39312
I agree. The cost of a couple of 7064Ss and a homemade ByteBlaster cable is a lot less than an Altera programmer. Victor "Jim Granville" <jim.granville@designtools.co.nz> wrote in message news:3C60C6D5.48CB@designtools.co.nz... > James wrote: > > > > Hi, > > > > just scored some used, but reusable EPM7064 gate arrays that I would like to > > use in some home projects. Unfortunately they are NOT "in circuit > > programmable" and require a seperate programmer. > > > > The Altera web site has no details on programming these devices, but do have > > free software for circuit entry etc. > > > > Can a programmer be built by me for these parts (I don't need high speed or > > flexibility)? Obviously my budget doesn't allow for a bought one - unless > > extremely cheap (few 10s of $), else I'd just buy one. > > > > Does anyone know where programming details can be found? Surely such details > > are freely available! > > No, because the support is too costly. It wont work first time, and then > what happens... > > You might find an old programmer that supports the non-isp models, but > better > is to move to ISP CPLDs > > In this class of CPLD are > > Altera 7064S - newer ISP versions of those you have > Xilinx CoolRunner XCR3064 > Atmel ATF1504AS > > Atmel have the best 5V support. > > -jgArticle: 39313
Clock enabled circuits can get slow because of the high fanout on the clock enable net. You may
need to distribute the clock enables with a tree of flip-flops.
Antonio wrote:
> I coudn't understand why for a gated clock project I was fighting to
> obtain 150MHz and now with
> the clkEnable version of the same I'm fighting to obtain only 70MHz,
> to what this is due ??
> All suggest me to use clkEnable if there are situation where clock
> enable is not a must, is it
> really necessary in my project where I've a master clock from which I
> obtain 3 derived clock in
> the gated clock version and 3 enable signal (...via a programmable
> counter) in the clock enable
> version. And to put in my thesis and based on your experience please
> add some lines to the following:
>
> ***********************************************************************************************
> Clock Enable Clock Enable Clock Enable Clock Enable Clock Enable Clock
> Enable Clock Enable
> ***********************************************************************************************
> PRO
> P1) Immunity to temperature change
> P2) Only CLK recognized by synthesizer
>
> VERSUS
> V1) slow (.. I don't know why)
> v2) More power dissipated because all the circuit run at f_clk
>
> ***********************************************************************************************
> Gated Clock Gated Clock Gated Clock Gated Clock Gated Clock Gated
> Clock Gated Clock Gated Clock
> ***********************************************************************************************
>
> PRO
> P1) Less power dissipated because not all the circuit run at f_clk
> P2)
>
> VERSUS
> V1) Derived clock not recognized by synthesizer
> v2)
--
--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: 39314Well, sussed out my problem with my DPRAM built with BlockRAMs. It's all Xilinx fault. They've owned up to "accidentally" removing the pin polarity option for signals on Coregen BlockRAMs that goes with 3.3. I had built a DPRAM with clka using a -ve clock edge in coregen with 3.1i However, this isn't supported in 3.3, so the PAR tool just didn't connect my clock to the BlockRAM. Wonderful! (NOT). Apparently, pin polarity is back in 4.1, I'll have to wait for our IT support group to install it, but god knows when that'll be; they're useless most of the time when it comes to putting on new s/w. We're usually a t least one release behind what's available in both Xilinx and Mentor tools. Enough whinging, time for some more VHDL; at least the text editor doesn't need upgrading! Regards, NivArticle: 39315
Even with v2, the best method for rectangular to polar conversion is
a CORDIC rotator unless you have very limited resolution
requirements. You can read my paper "a survey of CORDIC algorithms
for FPGA based computers" for (what I am told is) a good explanation
of the CORDIC algorithm. The paper is available at no cost from my
website.
Yann wrote:
> Hello,
>
> I'm looking for a Virtex 2 method to convert (or approximate) the
> angle from the rectangular coordinates (x, y) of a point. The x,y
> coordinates are coded on 16 bits.
>
> Thanks for your help
> Yann
--
--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: 39316
This is an interesting question, since ISE 4.2 is now working it's way
through the manufacturing channel. The following excerpt is from the
"What's New in ISE 4.2" file on the release CD.
XST Enhancements
XST includes the following enhancements:
a.. Preservation of internal buses by using bus<#> naming convention
b.. Preservation of upper and lower case in the final netlist
c.. Support for property lists for buses in the attribute syntax
d.. VHDL Enhancements
a.. Support for concatenation of slices when target is an array of
vectors
b.. Support for constant definitions in processes
c.. Support for signals declaration in a package file
d.. Support for "loop" and "while...loop" statements
e.. Improved run time and memory use for "next," "exit," and "return"
processing in "loop" statements
f.. Support for records in constant declarations
g.. Support for record type in function return
h.. Support for "string" type in functions
i.. Support for unconstrained vectors in component declaration component
j.. Improved attribute calculation through functions
k.. Enhanced multi-dimensional array support
XST supports the Virtex-II PRO device family. XST now also supports the new
CoolRunner-II device family as follows:
a.. Support for inference of a dual edge triggered flip-flop
b.. Support for the following constraints:
a.. DIVIDE_BY
b.. DIVIDER_DELAY
c.. COOL_CLK
d.. DATA_GATE
For syntax examples, see Xilinx Answer Record #13166.
----------------------------------------------------------------------------
----------------------
This is all pretty cool, but it still doesn't support the IEEE
real_math.vhd package (IEEE 1076.2). That will probably be next year.
"Arvin Patel" <apatel@chello.no> wrote in message
news:wkvgddxc2x.fsf@chello.no...
> Does anyone have any experience with the latest version of
> Xilinx XST? I would be interested in any comments on stability
> of the tool and of the quality of results.
>
> Does anyone have any comparisons of XST and Synopsys FPGA Express?
> I have made some tests and it seems that XST gives slightly
> better timing results than FPGA Express.
>
> It seems from earlier postings that many people use Synplify.
>
> Thanks in advance.
> Arvin Patel
>
>
>
>
Article: 39317On Tue, 05 Feb 2002 14:31:49 -0500, Jerry Avins <jya@ieee.org> wrote: snipped) > >Be fair! As I read the original question, my impression was that he >wanted to know of any algorithm texts for which an answer manual is >available. If there is one, he wants it for self study. I don't leave my >car keys in the ignition when I park, but I don't assume that every >passerby is a thief. I should have thought to tell him that many texts >have answers to, say, odd-numbered problems. > >Jerry >-- Jerry, you are kind-hearted. Of course I don't know what's in strut911's heart, but his comment that he wanted solutions manuals for: "almost anything related or of practical use to engineering." seems so odd. To state that he'll evaluate the quality of a textbook by looking at the solutions manuals defies common sense. What if he said: "Send me the keys to your homes, so I can decide what kind of house to buy"? [-Rick-] P.S. Just to be safe Jer, assume that every passerby is a thief, until proven otherwise.Article: 39318
rk <stellare@nospamplease.erols.com.invalid> writes: <snippage> > > I just hadn't messed with DRAMs in a while, been using SRAMs, and don't > know how susceptible the devices were to latch up. The last few times I > did DRAM designs, I was very, Very, VERY careful to have nicely terminated > lines, controlled impedance boards, and did not allow the signals to go > below ground or above Vcc and didn't have any problems. From what I can > tell from the little bit of information that I have, they didn't have > terminated signals and were using high-slew outputs from the FPGA. They > apparently didn't test the SDRAMs for latchup from driving inputs below > ground as part of the failure report. Me, being a bit lazy, don't want to > have to set that up and do that. So I was hoping someone here might have > some experience with more modern SDRAMs. > According to my Micron datasheet (MT48LC64M4A2): PARAMETER/CONDITION SYMBO L MIN MAX UNITS INPUT HIGH VOLTAGE: Logic 1; All inputs VIH 2 VDD + 0.3 V INPUT LOW VOLTAGE : Logic 0; All inputs VIL -0.3 0.8 V And the associated footnote: VIH overshoot: VIH (MAX) = VDDQ + 2V for a pulse width = 3ns, and the pulse width cannot be greater than one third of the cycle rate. VIL undershoot: VIL (MIN) = -2V for a pulse width = 3ns. <more snippage> HTH! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 39319
"Paul" <nospam@nospamplease.com> writes: <snip> > > What I'd like is > > a) How much better is Modelsim than Altera's own simulator especially for > post layout analysis. Since that's like asking about string length, I'd > accept anecdotal evidence based on your own designs :Ž) > I imagine lots, but I've never used Altera's sim in anger > b) Are full versions of Modelsim that much faster than the Altera edition. > Lots on big things. I believe an exponential slowdown can be expected with design size in the AE version. > c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual > processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound > or memory bandwidth bound) and does an MP setup provide any noticeable > improvement or are all tools resolutely single threaded. > I reckon you'd be memory bandwidth bound, esp. on large post-layout stuff. All the benchmarks I;ve seen show AMD being much faster than P4. > d) Any other suggestions. > Hardware emulator :-) Bit expensive though. Alternatively, you sometimes can't beat just configuring a device and hanging scope probes off it. > I am already trying as best I can to restructure testing to minimise the > issues, but these 10 hour simulation times (when it doesn't crash) are > really non-productive. > I bet :-) <snip> HTH! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 39320
Rick Filipkiewicz wrote:
> Philip Freidin wrote:
>
> > It's a TROLL, don't encourage it.
>
> Is that some sort of Hipcrime variant ?
>From http://www.altairiv.demon.co.uk/troll/trollfaq.html#one
troll v.,n. To utter a posting on Usenet designed to attract predictable
responses or flames. Derives from the phrase "trolling for
newbies"; which in turn comes from mainstream "trolling";, a style
of fishing in which one trails bait through a likely spot hoping for a
bite. The well-constructed troll is a post that induces lots of
newbies and flamers to make themselves look even more clueless than
they already do, while subtly conveying to the more savvy and
experienced that it is in fact a deliberate troll. If you don't fall for
the
joke, you get to be in on it.
The following extract is from a broader expansion of the defining
comments given above:
In Usenet usage, a "troll" is not a grumpy monster that lives
beneath a bridge accosting passers-by, but rather a provocative
posting to a newsgroup intended to produce a large volume of
frivolous responses. The content of a "troll" posting generally falls
into several areas. It may consist of an apparently foolish
contradiction of common knowledge, a deliberately offensive insult to
the
readers of a newsgroup, or a broad request for trivial follow-up
postings.
Article: 39321rk wrote: > the claim was that groundbounce in the FPGA > from SSO's caused the SDRAM to latchup; this was supposed to explain a > functional failure that would be cleared by cycling the power. Any CMOS device can latch up if device pins are forced below ground with enough energy. CMOS wells and substrates combine to form unintended n-p-n-p (SCR) structures. If these get triggered you get a a pretty good short from power to ground through the device. This may destroy the chip, or if you are lucky, requires a power cycle to turn off the SCR. To fix this, you need a better ground plane and/or better supply bypassing. > For a low, quiet output, they measured a 710 > mV peak below ground; that doesn't sound too bad, That is above the maximum low value for most devices, another indication an inadequate ground plane. -- Mike TreselerArticle: 39322
hello. i have been given the task of designing a protocol analyzer for my company's proprietary serial bus to help speed up the software design. i guess that means it needs to be finished quickly because software is really struggling right now. i have never designed a protocol analyzer before, but my first instincts are that i will need an fpga, a bunch or RAM (or Block RAM) if the quantity is sufficient, and a microcontroller. the serial bus runs at a max speed of 25 mhz although it can be slower if needed. i think it would be no problem to hit that target in today's FPGAs. my main question would be how to partition the hardware and software to be optimal to the design. my first thoughts were to take the incoming serial data, dump it all to memory when some trigger condition is asserted, and then have software post-process it into the various protocol control or data fields. if it is this easy (i doubt it is), then my fpga requirements would be minimal. however, when i look at the ethernet protocol analyzer my company has, it looks quite a bit more sophisticated than my minimalist design. another idea i had was to forget the microcontroller, and dump the memory contents to a PC when the data acquisition is finished. that way, i can let the PC post-process all the data and put it in a nice, colorful gui. are my ideas too simplistic? strut911Article: 39323
[I posted a similar message earlier, but it seems it didn't get through. My apologies if you see this twice.] Hello, I would like to know if there are efficient methods, easily implementable with high speed in an FPGA, to produce a pseudorandom bitstream with a known and finely, at runtime adjustable density of 1s or 0s. The density would be below 1/8 or 1/32, this excludes densities around 0.5 that are easily obtained with LSFR. If several such bitstreams could be produced that have no correlation amongst each other that would be great. The randomness really is only a requirement as far as the correlation/autocorrelation properties go and that the bandlimited spectrum of the integral of the signal must be white. I have found a few leads on LFSR implementations that yield pink instead of white noise, but AFAIK noone figured out how to obtain arbitrary let alone continuously adjustable frequency responses. Plus the pink noise, to the best of my knowledge, is not obtained from the bitstream, but some code the LFSR outputs. Any hints in which directions I might search? Achim.Article: 39324
Achim Gratz wrote: > I would like to know if there are efficient methods, easily > implementable with high speed in an FPGA, to produce a pseudorandom > bitstream with a known and finely, at runtime adjustable density of 1s > or 0s. How about one LFSR for the basic bitstream and another to pick the bit positions to zero out for the required density setting. -- Mike Treseler
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