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 Oct 25, 4:18 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > tago...@gmail.com wrote: > > Hello all > > > Does anyone have a Signetics data sheet / data book with this part? > > > Thank you > > Did you mean the 82S101 ? > Google has more luck with that more correct part number :) > > -jg IIRC, Signetic's P/N was 82f101, for an equivalent part to the 82s101 from someone else? But, Jim is right, you will probably get more hits on 82s101... AndyArticle: 125501
"motty" <mottoblatto@yahoo.com> wrote in message news:1193402186.653906.267270@19g2000hsx.googlegroups.com... > Thanks for the help guys. It appears to work when the AddrReq comes > before the data push. I guess the IP needs to 'get ready' for one 64- > bit entity using the req. And it does not work the other way around. > The documentation (release notes) is misleading in the fact that it > basically says that the safest way to do things is to push data then > do the addr req. They should say next to that 'don't do this with 64- > bit double-word writes though'. Maybe my reading comprehension needs > adjustment. I've just checked my code. I am using 4-word cache-line transfers and I am asserting AddrReq after the data has been pushed in, but my memory is 32-bit wide... /MikhailArticle: 125502
"Ray Andraka" <ray@andraka.com> wrote in message news:fonUi.949$6e6.111@newsfe16.lga... > Jonathan Bromley wrote: > >> - speed/density/power: cutting-edge ASIC will always win on >> all three of these, but the configurability and low NRE of >> FPGA may well win for many applications > > This is only true when working in the same feature size. FPGAs tend to be > on the bleeding edge of process where ASIC starts usually lag behind by at > least one or two process generations. Generally speaking, a lag of 2 > generations puts a reasonably carefully executed FPGA design pretty much > on par with an ASIC design in terms of the speed/power/density. > > Another factor to consider for FPGAs is that design errors do not restart > the design cycle clock the way an ASIC error can. I'd add that IOs for new FPGAs easily outperform IOs for ASICs at a feature size that allows a reasonable NRE. For the 0.18 and 0.15 micron ASICs, the IOs just don't compete with FPGAs! With all the discussion on how ASICs can perform better than FPGAs, I was lulled into a false sense of adequacy. Compromising on I/O just sucks. Go Go FPGAs!Article: 125503
> I think your test is a difficult one since you are looking for > failures due to discharge by random radiation effects. Slowing down > the refresh and finding one or few cells that tend to discharge more > quickly than the rest as a few others have suggested does not really > apply to the problem. No, I'm looking at the retention. How does radiation effect the retention characteristics of the DRAM. As mentioned in another reply, it makes sense to change DRAM refresh rates at different temperatures. Does this help in a radiation environment? > > You haven't specified what kind of radiation you are testing for (high > energy cosmic rays, background radiation, BETA radiation, Nuclear > power plant radiation(monitoring or robotic device?), or nuclear bomb) > This is not a simple test rig. The programming of the refresh rate is > a minor problem. The problem, if I understand your description > correctly, is We are using gammas for this test. Following students will use other radiation sources. > > The supplier of your memory may be able to give some advice on this > test setup. (or are you working for the memory manufacturer?) I think > you do not need to change the refresh rate dynamically. You should be > able to do test runs at a fixed refresh rate, get the failure rate, > reboot with a new refresh rate and start again. Depending on the > radiation source you may need to replace the memory modules in a > controlled way, to deal with the cases of permanent damage by the > radiation. Not working for the mfg. I wish I was, then I'd have more resources. I'm working for a university (as in, I'm a student). > > I'm not trying to be offensive with this final question/comment, but I > take it your background is computer science only, right? You may need > to get someone with a background in physical sciences (a physicist) to > help design the experiment. (I have a BS in physics, but nuclear > physics is not one of my strong points.) > I have a nuclear engineer helping me with this. Actually, it's the other way around since this isn't really related to the deliverables for my thesis.Article: 125504
On Oct 26, 9:09 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Mon, 22 Oct 2007 22:44:56 -0700, sendt...@gmail.com wrote: > >Hi, > > >I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera > >DE2 board. I've gotten the hardware interface squared away (thanks > >everyone for your help!). > > >Now it's the tricky stuff. Any one have an idea how I can change the > >refresh rate while the RAM is in operation? > > If you roll your own controller (easy enough for SDR SDRAM) or can > understand the core you are given, you can find what controls the > refresh rate; invariably a counter. > > Replace the counter with an absurdly long one (say 32 bits), whose count > length is controllable from a register accessible to whatever host CPU > (NIOS in this case). > > It's either a reloadable down counter, which reloads and generates a > refresh cycle when it hits zero; in which case you reload it from the > register; or an up-counter which refreshes and resets to zero when a > comparator triggers; in which case the register holds the comparator > value. > > Then you have direct control of the refresh rate without messing with > clock frequencies etc. > > - Brian Actually that sounds like a good idea. I'll look into that, thanks. -EricArticle: 125505
Hi all, In our design, we have a sensitive circuitry that we think may be affected by the bulk of the circuit (mainly two state machines). In order to isolate it in a section of the FPGA (Virtex-II Pro XC2VP30), we tried using the RLOC and RLOC_ORIGIN attributes. We did manage to group the sensitive circuitry, and move it all the way to the bottom-left corner of the chip. However, when we do that, the rest of the CLBs also move with them. Although we tried to use the RLOC attribute for the rest of the circuit, they are somehow not recognized. The reason might be that the files are in different hierarchy levels, and the Xilinx Floorplanner doesn't recognize the U_SET. How do you suggest we go about doing this isolation? What can be going wrong with the RLOC attribute? Since this is the first time we've ever used them, I suspect we might be missing something out. I would appreciate any help, Sincerely, Berk -- Posted via a free Usenet account from http://www.teranews.comArticle: 125506
Andy wrote: > On Oct 25, 4:18 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>tago...@gmail.com wrote: >> >>>Hello all >> >>>Does anyone have a Signetics data sheet / data book with this part? >> >>>Thank you >> >>Did you mean the 82S101 ? >>Google has more luck with that more correct part number :) >> >>-jg > > > IIRC, Signetic's P/N was 82f101, for an equivalent part to the 82s101 > from someone else? > > But, Jim is right, you will probably get more hits on 82s101... Signetics 'owned' the N82S pefix, and I note someone very recently 2nd sourced the N82S123 bipolar prom http://www.eeproductcenter.com/memory/brief/showArticle.jhtml?articleID=202602063 -jgArticle: 125507
Antti wrote: > ok, so what you see "once in a blue moon" I see at least every hour... > > I switched from 7.1 to 7.2 maybe its better now So you should know if it is better fairly quickly :) Perhaps it's also device dependant ? -jgArticle: 125508
MikeShepherd564@btinternet.com wrote: >>...At 120 Hz, it should be easy for you to stagger the output timing >>of the various triac drivers without materially affecting the dimming >>quality > I don't understand how he can do this. For a given brightness, > doesn't this fix when he has to switch on the triac? > (There's no choice about when to switch off: it won't switch off > until the current falls to zero at the end of the half-cycle). If you stagger in nanoseconds it won't have a large effect on the light output, which may be in the 100 microsecond range. (A half cycle is 8.333ms, one hundredth is 83.33 microseconds.) Even so, you can stagger them between cycles and average to the desired value. That would be more true for large light bulbs (such as use in theaters) than for small christmas lights. -- glenArticle: 125509
On 26 Okt., 16:14, Patrick Dubois <prdub...@gmail.com> wrote: > Hi, > > Is it possible to run XMD remotely using CableServer? This is the only > missing item that would enable me to work completely remotely from my > desk (instead of being in the lab, where we can't drink coffee ;) > One alternative is to use Remote Desktop to control the lab computer > but I'd really like to avoid having to install the complete Xilinx > toolset on the lab computers. > > Another gizmo I found is a USB to ethernet converter (to control the > platform cable usb remotely). Not sure if it would work though:https://www.ramelectronics.net/html/usb_server.html > > Thanks for any pointers. > > Patrick XMD is actually itself a server, so it can sure be accessed over network the gizmo you mention would not work, check the list of supported devices AnttiArticle: 125510
>>>...At 120 Hz, it should be easy for you to stagger the output timing >>>of the various triac drivers without materially affecting the dimming >>>quality >> I don't understand how he can do this. For a given brightness, >> doesn't this fix when he has to switch on the triac? >> (There's no choice about when to switch off: it won't switch off >> until the current falls to zero at the end of the half-cycle). >If you stagger in nanoseconds it won't have a large effect >on the light output, which may be in the 100 microsecond range. >(A half cycle is 8.333ms, one hundredth is 83.33 microseconds.) >Even so, you can stagger them between cycles and average to >the desired value. That would be more true for large light >bulbs (such as use in theaters) than for small christmas lights. Staggering sub-millisecond sounds like a good idea (up to the point where the largest brightness error is unacceptable). Averaging over several half-cycles would need some experiment. Perhaps it could work for very high-power bulbs (those with a lot of thermal inertia), but for domestic bulbs (say 100W), the flicker would soon become visible (well before it reaches the level where the same error in "constant" brightness would cause a problem). MikeArticle: 125511
"Berk Birand" <dont@email.me> wrote in message news:Xns99D59E71F8A4Bdontemailme@66.150.105.47... > Hi all, > > In our design, we have a sensitive circuitry that we think may be affected > by the bulk of the circuit (mainly two state machines). In order to > isolate > it in a section of the FPGA (Virtex-II Pro XC2VP30), we tried using the > RLOC and RLOC_ORIGIN attributes. We did manage to group the sensitive > circuitry, and move it all the way to the bottom-left corner of the chip. > However, when we do that, the rest of the CLBs also move with them. > What do you mean by "sensitive circuit"?Article: 125512
"Berk Birand" <dont@email.me> wrote in message news:Xns99D59E71F8A4Bdontemailme@66.150.105.47... > Hi all, > > In our design, we have a sensitive circuitry that we think may be affected > by the bulk of the circuit (mainly two state machines). What makes it a 'sensitive circuit'? What is the 'bulk'? > In order to isolate > it in a section of the FPGA (Virtex-II Pro XC2VP30), we tried using the > RLOC and RLOC_ORIGIN attributes. We did manage to group the sensitive > circuitry, and move it all the way to the bottom-left corner of the chip. Why isolate it? Have you diagnosed a problem? If so, what is it? Explain why isolation would help. > However, when we do that, the rest of the CLBs also move with them. > Your 'sensitive circuit' no doubt communicates with other stuff inside that FPGA. Those things will tend to want to move, which can drag yet other stuff as well. > Although we tried to use the RLOC attribute for the rest of the circuit, > they are somehow not recognized. The reason might be that the files are in > different hierarchy levels, and the Xilinx Floorplanner doesn't recognize > the U_SET. > > How do you suggest we go about doing this isolation? What can be going > wrong with the RLOC attribute? Since this is the first time we've ever > used > them, I suspect we might be missing something out. > First off, I'm guessing that what makes your 'sensitive circuit' sensitive is timing problems. If that is the case then no amount of manual placement will help you get to a robust solution. Symptoms of timing problems are: - Flaky behavior (i.e. sometimes it works, sometimes it doesn't). - Apparent sensitivity to temperature (it works when it's cold, not after running for a bit....or vice versa). If this is what you are classifying as 'sensitive' then I would suggest first look at the static timing analysis report and fix all the problems. Also check that all FPGA inputs are properly synchronized to the proper clock before using them. You made mention of 'two state machines'. Are ALL of the inputs to those state machines synchronized to the state machine's clock? A common error is using a signal as input to that state machine that is not synchronized to the clock...because it doesn't change very frequently, or some other such nonsense. Inevitably the timing of that signal violates the setup time and the state machine goes into the wrong state. Checking async inputs and clock domain crossings are just a subset of timing analysis (albeit common problems). If by 'sensitive circuit' you're instead seeing that this sensitive area works when the rest of the design is somewhat quiescent but then when there is a 'lot' of activity the design seems to flake out, then this tends to point to power supply problems where the PCB design has not provided an adequate power delivery system with its power planes and bypass capacitors. Solutions here range toward the relatively simple (addding bypass caps) to 'oh @#$%%' where you have to add a power/ground plane or cobble something together with copper tape and hope. Bottom line is that unless I've managed to guess correctly at what your 'sensitive circuit' is sensitive to, you're going to need to provide some more information about this sensitivity. Going about a solution of trying to do manual placement without a proper understanding of the root cause problem is simply asking for a lot of pointless work. Going down that path often results in things magically appearing to 'work'....only to find out that it 'works' for that board, but not on another. You've got a broken system, debug that and get to the root cause before attempting fixes. Broken systems can be debugged, ones that magically start to 'work' can not and always come back to bite you later. KJArticle: 125513
On Oct 26, 6:39 am, "Nevo" <nev...@hotmail.com> wrote: > Yes, this is on my list of concerns. For the time being I plan on solving > the problem by using the "don't do that!" method. I started *way* too late > to be ready for a Christmas light show so I won't be able to really fix this > problem this year. > > "Chris Maryan" <kmar...@gmail.com> wrote in message > > news:1193371715.999672.227300@y42g2000hsy.googlegroups.com... > > > Not really answering your question, but... Sink or source, 128 x 7mA > > is a lot, your FPGA may not be able to handle it. You probably need > > something a bit more efficient or maybe an extra level of transistors > > to give current gain. Nevo; Perhaps you could play (uh,experiment) with with a microprocessor development board (PIC, AVR, etc) to get ideas on what works and doesn't work to control your Christmas lights. You could probably get something working sooner than designing an FPGA project from scratch. -Dave PollumArticle: 125514
On Oct 26, 10:51 am, fpgabuilder wrote: > + Others? On an FPGA your logic will probably run half as fast as the block memories while on an ASIC it is the other way around. This could lead to different design styles. -- JecelArticle: 125515
Vagant <vladimir.v.korostelev@rambler.ru> writes: > It's nice blog. > I just wonder how much of the material in this blog is applicable for > Spartan3E-1600E Microblaze Development Kit which I've got? Probably all of it that doesn't concern the PowerPC core in the Virtex-4 FX he's using.Article: 125516
"Berk Birand" <dont@email.me> wrote in message news:Xns99D59E71F8A4Bdontemailme@66.150.105.47... > Hi all, > > I would appreciate any help, > Sincerely, > Berk > Hi Berk, Search for PROHIBIT in the xilinx constraints guide. It won't help fix your problem, but what the hey. Cheers, Syms.Article: 125517
I am simulating an EDK system and want to use some internal signals at the testbench level (without routing them up to external ports). I thought that you could simply do this by assigning signals using hierachry nomenclature. For a specific example, I want to use the clk0 output of a DCM as a clock at the testbench level. I have tried the following: wire clk_150_mhz = system_tb.system.dcm_1.dcm_1.clk0 In ModelSim PE I get an error that clk0 could not be found in the hierarchy. wire clk_150_mhz = ".system_tb.system.dcm_1.dcm_1.clk0" ModelSim does NOT give an error, but the signal is always static 0. The dcm clock is definitely toggling, by the way. wire clk_150_mhz = "/system_tb/system/dcm_1/dcm_1/clk0" Same as above. This is supposedly the correct hiearchy. I compiled and vsim'ed the design without trying to connect the lower level signal so I could get a working simulation. I then added the dcm_1 clk0 signal waveform to the window and the hierarchy was system_tb/system/dcm_1/dcm_1/clk0. So what am I missing? This should be simple and I am grinding my gears here! Thanks in advance!!Article: 125518
On 26 Okt., 14:51, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > When it comes to designing for fpgas or asics there are a lot of > guidelines/rules that need to be followed consistently between the > both. [..] > Some that come to mind are - > > + Number of logic levels between flops > + Uniform delay through a lut vs different delays through nand gates. > Asic delays highly dependent on the synthesizer and coding style? > FPGAs more forgiving about how the combinatorial logic is coded? I have a different experience. The points above are more a question of how hard you squeece a technology than a question between ASIC and FPGA. You can have relaxed designs in both where you don't have to bother and you can have designs on the edge of the technology in both. The only major difference for the points above I would agree is when it comed to adders because nearly every actual fpga provides fast carry logic which I haven't seen in ASIC so far. This means that in ASIC you have a lot faster adders than ripple carry while in fpga you will use the ripple carry in most cases. > + Asynchronous resets in fpgas ???? > + Clock gating not as efficient in fpga therefore use flop enables. This is one of the most important changes. I have designs which are implemented in asic and fpga and this is one of the most important changes. > + Others? Whenever I have a relaxed design, I code in a way that fits for all. If i need to squeeze the last out of the technology, my code depends on the choosen tech-lib and wouldn't even be easy portable between different technologies of the same vendor, so why bother between asic and fpga? bye ThomasArticle: 125519
On Fri, 26 Oct 2007 22:32:18 -0700, motty <mottoblatto@yahoo.com>
wrote:
>I am simulating an EDK system and want to use some internal signals at
>the testbench level (without routing them up to external ports). I
>thought that you could simply do this by assigning signals using
>hierachry nomenclature. For a specific example, I want to use the
>clk0 output of a DCM as a clock at the testbench level. I have tried
>the following:
>
>wire clk_150_mhz = system_tb.system.dcm_1.dcm_1.clk0
Your design and testbench are all in Verilog, right?
>In ModelSim PE I get an error that clk0 could not be found in the
>hierarchy.
Apart from the missing semicolon at the end of the
wire assignment, this is perfectly valid Verilog; so
I suspect ModelSim is right, and you have made some
small error in the hierarchical name. Case sensitivity?
> wire clk_150_mhz = ".system_tb.system.dcm_1.dcm_1.clk0"
>ModelSim does NOT give an error, but the signal is always static 0.
Yeah. The string is a very wide Verilog constant; because its
last character is '0', whose ASCII code is an even number,
your single-bit wire will be jammed to zero.
The leading '.' would be wrong in any case.
>wire clk_150_mhz = "/system_tb/system/dcm_1/dcm_1/clk0"
>Same as above.
Same reason: you've assigned a 34-character string,
which is an 8*34-bit constant vector, to the wire.
Its LSB happens to be zero, so that's what you get.
The slashes would never work in a Verilog hierarchical name.
>This is supposedly the correct hiearchy. I compiled and vsim'ed the
>design without trying to connect the lower level signal so I could get
>a working simulation. I then added the dcm_1 clk0 signal waveform to
>the window and the hierarchy was system_tb/system/dcm_1/dcm_1/clk0.
>
>So what am I missing? This should be simple and I am grinding my
>gears here!
That all sounds correct. Sanity check: this is *really* all in
Verilog, right? Every level of the hierarchy? And that
hierarchical path really is starting from the very top of your
hierarchy?
Here's another thought: Can you, temporarily, patch the code
of the lowest level of the hierarchy - the place where
"clk0" lives? If so, put this code right next to the
declaration of "clk0" (or, if it's a port, somewhere
inside the module that has it as a port):
initial $display(" The signal I want is at %m ");
The %m formatter will display the full Verilog hierarchy
path to that point in the design. Add ".clk0" to the
end of that name, and that's your signal name.
If all else fails, look at the ModelSim docs for "SignalSpy".
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
>Thanks in advance!!
Article: 125520Jonathan Bromley wrote: (snip) > I've seen many different variants on this: block refresh > during frame blanking, for example. They all seemed > pretty unpleasant to me at the time, and still seem so > now - although, of course, no-one needs to do that sort > of dirty trick any more (do they? please?) I have seen ATX style motherboards for PCs with built-in video that use a part of the main memory. I don't know how they do the access, though. -- glenArticle: 125521
Nevo wrote: > Each opto will draw a maximum of 7mA. The FPGA will be sinking the current > from the opto, not sourcing current. I was just yesterday wondering how much current newer FPGAs can sink. I was figuring if I could direct drive a floppy disk interface without TTL buffers. I didn't look it up yet, though. -- glenArticle: 125522
Assuming a scenario that I have a bit file built for a particular FPGA, but i don't have a that FPGA device to download it to, Is there a way to check it works on that particular FPGA? Thanks in advance WaterArticle: 125523
On 27 Okt., 12:51, Walters <hps...@gmail.com> wrote: > Assuming a scenario that I have a bit file built for a particular > FPGA, but i don't have a that FPGA device to download it to, Is there > a way to check it works on that particular FPGA? > > Thanks in advance > Water noArticle: 125524
>Nevo; >Perhaps you could play (uh,experiment) with with a microprocessor >development board (PIC, AVR, etc) to get ideas on what works and >doesn't work to control your Christmas lights. You could probably get >something working sooner than designing an FPGA project from >scratch. >-Dave Pollum We're drifting a little from the topic, but... To avoid visible flicker at any brightness, the jitter between the supply waveform and the triac switching point must be no more than a few microseconds. (Remember that the supply is asynchronous to the processor clock, so you must detect its "crossing zero" on every half cycle and start some kind of timer - hardware or software - at that point, then drive the triac for a short time when the timer expires). Without hardware support (and even driving only one triac), you need very tight microcontroller code to achieve only this. The rest of the code (with which you're trying to experiment) would be severely distorted by the needs of this triac driver. For this reason, it's probably best to develop the triac timing logic in "hardware" (probably an FPGA) right from the start, so the micro can be devoted to the high-level control, for which it will then have plenty of time to control several channels via the FPGA Mike
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