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
>Or something else goes wrong, plus the cost of the PROM is comparable to the >cost of a PCI bridge... I wasn't trying to push for or against the PLX type approach. Just pointing out that there are ways to change the configuration when your design gets loaded from a PROM. Board space or layour or something else might make the PLX/bridge unattractive. Another potential disadvantage of the PLX/Bridge is a few more clock cycles if you just want to do a simple read. (Writes can be pipelined.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 71301
> A Xilinx App Note was suggested. Here is an attempt. > Let me know if it makes sense. I think your summary was good, but I also think I understand the problem. (I got bit years ago. It's one of my hot buttons.) The real question is how to get this problem on every designer's mental checklist so that they are thinking about it at the right time. My request for an app-note was actually misleading. I should have asked for support in the tools. They should be smart enough to complain about state machines that don't have some mechanism to come out of reset cleanly. What do ASIC/CPU designers do? My guess is that they don't have a global-reset so their version of this problem is a bit different. This seems like a good open source project. Or maybe a masters thesis. All the info is in the EDIF/netlist. Right? Is the GSR in the netlist? Or would a tool have to add it by magic? Ken's TechXclusive article is good. Thanks. It actually doesn't cover the mechanism I think I would try to use. He holds the whole state machine in reset. That chews up local resources. Many FSMs stay in the idle state until they get poked, for example a memory controller waits for a read or write request. I was thinking of blocking that sort of request signal. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 71302
Rich Webb wrote: > On Wed, 14 Jul 2004 00:29:38 GMT, Pete Harrison > <peter_harrison@ntlworld.com> wrote: > > >>I guess the combination of Wincupl and a 16V8 will be pretty much steam >>technology for most of you but it is a real mystery to me. > > > On the other hand, a 16V8 or 22V10 is often the perfect size. Indeed. I am sometimes frusrated by people expounding the virtues of this or that CPLD etc when you can only get them in SMT multipin packages. Not much good if you just want an address decoder. > > You have your registers on four of the output pins. Route those values > combinatorially to the remaining four outputs so that, for example, > (if ENA reset is "motors off"; flip to !ENA if not so). > > pin [16..19] = Y[3..0]; > ... > Y0 = ENA & Q0; > Y1 = ENA & Q1; > Y2 = ENA & Q2; > Y3 = ENA & Q3; > > (Is there a shorthand notation for that? My CUPL is a bit rusty.) > > If you're already wired to come off of 12..15, move the registered > outputs up a nibble, of course. > > A disadvantage (or maybe an advantage) is that the registers don't > change value if only ENA changes, so going back to the active state will > restore the stepper bits to where they were (if no clk changes...). > This is an excellent advantage in this case as it may make it more likely that the steppers will start up again without a large jump to a new detent. I have just tried this and it works a treat. Luckily, the other outputs are all free in this circuit. I also tried the shortcut: Pin [12..15] = [Q3..0]; /** **/ Pin [16..19] = [Y3..0]; field output = [Q3..0]; field stpctrl = [Y3..0]; /* state machine stuff */ output = ENA & stpctrl; Which works just fine Thank you so much. I have no idea where you are so you will have to make do with a couple of virtual beers (or whatever you prefer) PeteArticle: 71303
You could use a SRL16/DFF (with clock-enable and synchronous clear) combination for this. The input pulse - which is high for one clock cycle -sets the FF output, and a delayed version of this pulse clears it after a number of clock cycles. The depth of the SLR16 sets the length of the output pulse. Note that the output pulse is delayed by one clock cycle with respect to the input pulse. _______ | | +--| SRL16 |------+ | |_______| | | | | ______ | | | | | short pulse -----+--|CE Q|----------- long pulse | | | 1--|D | | | | | CLK--|> | | | | | +--|CLR | | | |______| | | | +-----------------+ Regards, Guy. Johan Bernsp=E5ng wrote: > Hi all, > > What would be the optimal way, in terms of device utilization and > functionality, to exstend the length of the time a signal is asserted > from one clock cycle to four clock cycles. I.e. > [pseduo code:] > if signal_a is asserted then > signal_b is asserted for four clk; > > Is it possible to accomplish the function by utilizing an SRL16, or is > there a better solution? Or should I simply create four delayed versions > of signal_a, and OR them together to form signal_b? > > I'm working with a Virtex-2 device. > > regards > -- > ----------------------------------------------- > Please remove the x's in the email address if > replying to me personally. > > Johan Bernsp=E5ng, xjohbex@xfoix.seArticle: 71304
Hi, I am using Excalibuer FPGA with ARM 922T I need to download my Digital Design and My Embedded Code on to the chip for which the SOPC builder is not recgonizing my .elf generated by ECOS(RTOS). I have tried maniuplating the quartus makefile but no luck .I am abel to down load them independently ie my .elf or my hex file generated for my digital design but not both at the same time.If somebody could throw some light on this i would be greatefull even if they could comment on its feasability. Thanks and Regards, RasquinhaArticle: 71305
On Wed, 14 Jul 2004 00:29:38 GMT, Pete Harrison <peter_harrison@ntlworld.com> wrote: >I guess the combination of Wincupl and a 16V8 will be pretty much steam >technology for most of you but it is a real mystery to me. > >I blew up some 16V8 stepper sequencers the other day and I have to >program up some replacements. All I have is some software to program the >ATF16V8B chips and wincupl. > >This is my first try at this game but I have the state machine working >after many hours of searching and puzzling and it behaves the same as >the original chips. BUT... > >The driver board has an enable input which should turn off the motors. >In the current design, that is done by setting the outputs all high when >ENABLE is active. unfortunately, this only happens if a clock pulse is >applied as (I suppose) it has to get clocked through the output registers. > >Is there a way to make the ENABLE input force the outputs to a >predetermined state with or without a clock pulse? You could do it using the OE pin on pin 11, and use external pullup/pulldowns. If you have enough free output pins, you could also route the state machine outputs back through another 4 cells to provide an asynchronous enable function. Or you could pass the clock through a cell before feeding into pin 1, so you could generate a forced clock pulse when enable gets asserted.Article: 71306
sudrie wrote: > hello <i>am an mcu developper on 8051 .</i>  <i>never use xilinx > fpga</i> <br><br><i>wana build an application and i don't know if an > fpga is the best for my product i try to have the more low cost and "more > compact" but i can't compare (not enought information)!</i> <br><br>My > application request: <br> low cost for end user (i wana put my application > freely on the net (i can program for the end user the chip if they don't > have the programmer) and make the pcb ) <br><br>litle description : > <snip> I would also suggest you to leave your fingers away from FPGAs for your planned design. It appears to be far more cheaper and cost-efficient to use a micro controller with appropriate integrated peripheral devices or perhaps with some external chips. USB, in particular, is quite complex and perhaps you would need to put an MCU into your FPGA to handle it at all. For the case you would need some special hardware features (e.g. when all your ADC samples would need to be processed "somehow" in parallel), then an FPGA + MCU solution might be of interest. Regards, MarioArticle: 71307
After viewing the fitter RAM summary details I can say the following: The filter is a cascaded polyphase FIR. There are three stages, and the first stage is a decimate by 20, so has 20 polyphase arms. Each polyphase arm comprises of a distributed arithmetic unit. The samples are distributed as parallel data to each polyphase arm, and then serialised. My current interface at the input of each polyphase arm uses 3 large registers of size nis*data_width, where nis = number of interleaved streams = 8, and data_width = 32. 3 x 256 = 768, and multiplying this by the number of phase arms across all cascaded stages, this number gets very very large. Because 1FF = 1LE, this takes up heaps of LEs, so I decided to implement these registers in memory. In my data_width = 16 implementation (which fits in the device) these registers are 128 bits in size, and constitute a depth 1, width 128 memory. Clearly depth 1 memories will result in poor use of memory resources. We have M512 = width 18, M4K = width 36, M-RAM = width 144, so I'd expect each register to require 4 x M4Ks, or 8 x M512s. Surprisingly, according to the fitter RAM summary, one of the worst offending 128-bit registers used 54 x M4Ks and 8 x M512s. Regardless of this problem I see that it was a BAD idea to fully parallelise the data in the input interface of each polyphase arm (seemed the easiest way at the time though). Ray Andraka <ray@andraka.com> wrote in message news:<40F4532F.DBB4F364@andraka.com>... > You'll need to provide more details as to how you set up the memory as > well as the filter. If the sample rate is one clock per sample, then it > is not really appropriate to use the memory because you are using only one > location per memory (and wasting the rest). > > What is the ratio of your data rate to the clock? > How many taps is your filter? > > > Wilhelm Klink wrote: > > > I've got an FIR design that runs out of FPGA memory in an ep1s60 when > > I set the data width to 24-bit (The design fits with a data width of > > 16-bit). However only 13% of the total memory is used. I assume the > > problem is that I have lots of smaller memories, and they cannot share > > the same memory blocks (M512, M4K, M-RAM). Can anyone who has > > experienced this problem share their strategies for dealing with this. > > -- > --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, 1759Article: 71308
Last year there was a thread here about using FPGAs at high temperatures with limited life. Makmorbi said: <quote extract> I am about to write a paper on effects on FPGA's at high temperatures. </quote> Peter Alfke said, partly in response; <quote extract> I have helped customers in Texas, France, and Norway with questions about device operation up to 175 degrees C, and many such projects have been very successful, operating for weeks at these elevated temperatures. </quote> What FPGAs were these? I know that for example 3.3V devices usually work, but do the newer lower voltage devices also work? Has anyone worked out a way of reliably fixing BGA packages at these temperatures? Is your paper in the public domain, Makmorbi? Cheers -- Keith WoottenArticle: 71309
Yesterday I wrote:
>
> Should be much better in V2Pro and S3 with the new DCI
> control logic to cleanly stop the DCI updates.
>
Or maybe not- according to the following Answer Record,
there's a 60 mA per bank hit when using LVDCI_33 in a
Spartan 3, so the ~200 mW per bank number still applies.
I'm not sure why it's still so high, as I thought the main
cause of the high overhead with the V2 DCI was that the
FreezeDCI option randomly stopped the DCI update logic at
whatever state it was in, possibly in an active R/2 matching
mode, rather than cleanly stopping it with VRP/VRN inactive.
Answer Record #19628 Spartan-3 - How does DCI affect power consumption?
"In an experiment performed to test current consumption when
using LVDCI, Xilinx found that for every bank that turned
on DCI, the device consumed an extra 60 mA of current"
Brian
Article: 71310Bruce Ray wrote: > Does anybody have experience with the Altium CircuitStudio 2004 product > compared with Altera's MAX+PLUS II Baseline (or other such products) that he > could share? Not yet. But on the way. However these are a different kind of tools. While the Altium tool is concerned with the FPGA on a board, the free webtools, such as MaxPlus2 do not care about the pcb. EG the Altium tool is able to optimally assign the pin such that the routing on the pcb is simple. On MaxPlus2, the pin assignment has to be done manually. ReneArticle: 71311
Hi I want to configure my Virtex-II (Avnet Development Board)using MultiLINX download Cable. I am using Slave Serial Mode. But iMPACT Software do not programme the FPGA and it says "DONE pin did not go low" . I also have two more queries. 1-) System ACE MPM is enabled by default . Should I disable it when using Slave Serial Mode as I am not using System ACE? 2-) Is HSWAP_EN has to do something with the stated problem? Thanks ShehzadArticle: 71312
Where can I find an explanation of the prefix codes in an nm generated symbol table? I see entries such as 'F' which are not described in the standard GNU manuals.Article: 71313
You could use a SRL16/DFF (with clock-enable and synchronous clear)
combination for this. The input pulse - which is high for one clock
cycle -sets the FF output, and a delayed version of this pulse clears
it after a number of clock cycles. The depth of the SLR16 sets the
length of the output pulse. Note that the output pulse is delayed by
one clock cycle with respect to the input pulse.
_______
| |
+--| SRL16 |------+
| |_______| |
| |
| ______ |
| | | |
short pulse -----+--|CE Q|----------- long pulse
| | |
1--|D | |
| | |
CLK--|> | |
| | |
---|CLR | |
| |______| |
| |
+-----------------+
Regards,
Guy.
Article: 71314Hal, > What do ASIC/CPU designers do? My guess is that they don't > have a global-reset so their version of this problem is a bit > different. In ASIC design, we would connect the asynchronous reset to the circuit Ken showed (or one like it). Reset for each clock domain is separately synchronized. Reset would need to settle in a clock period. Routing generally allows this. If not, you work it out (build a fanout tree with buffers or registers). Going back some time, on my first ASIC we had to manually balance the clock tree. See my post. GSR would be generally alot more useful if we could quantify in general that it settles in X to Y amount of time and then apply its output to a circuit like the one Ken shows to stabilize all logic or all control logic. From the difference between Y and X we could calculate how many states we needed to delay "critical" reset so that it occurs last. Four registers is kind of ad-hoc and means something much different for different clocks (20 MHZ vs 200MHZ). Of course, going a step further, since synthesis tools can and do recognize statemachines, and they know the clock frequency of a particular clock, they could automatically do the right thing for Xilinx (insert Ken's circuit). However I like being in control of these type of things and I am not sure I would like this solution. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 71315
Symon, It fails in both post-translation and post P&R simulation as well. Also it is not related to clock rate and fails when single stepped. I also simulated the original code from opencores and that fails in the same way. kevin "Symon" <symon_brewer@hotmail.com> wrote in message news:<2liq3pFd9tdqU1@uni-berlin.de>... > How about trying a post P&R simulation? > Cheers, Syms. > "Kevin White" <kevinjwhite@comcast.net> wrote in message > news:a8425c6f.0407102012.202d7bac@posting.google.com... > > Hi, > > > > Has anybody managed to get the C16 processor from opencores.org to > > function correctly? > > > > I am trying to use it with a Digilent board with a Spartan IIe > > XC2S300E and Xilinx tools version 6.2.03i. > > > > The code required modification to port it to this board and it > > simulates fine with Modelsim but when the code executes it ignores > > even simple instructions such as JUMP. The program counter just keeps > > incrementing. I can see that the instructions are in memory OK. Its > > as if the Xilinx tools are not synthesizing the VHDL correctly. > > > > Any hints will be welcome. > > > > thanks > > > > KevinArticle: 71316
"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10f8r37ibfl3u8d@news.supernews.com>... > Pino, > > Do you have your PLL external output clock tied to the SDRAM clock pin? > (plus all the other sdram pins?) > Did you start with an example like "Thrifty" etc.? > > Ken > Ken is absolutely right about the PLL feeding the SDRAM clock being necessary. One note, though: please take a look at an example design specific to the board you're using (1s10). The reason I say this is that the clock networks on our Nios/Cyclone boards (one PLL for Nios, fed back into a second to drive SDRAM) are slightly different than the Stratix boards (only one PLL required for both an on-FPGA and external SDRAM clock). Also note: be sure to phase shift the external clock to SDRAM. If you open up the example designs and take a look at the PLL you'll see what I mean. This will compensate for board trace delay and should be adjusted if you build your own board which, obviously, will have its own delay. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 71317
Yes, that looks like a good solution. I'll give that a try later. For more ascii art, see: http://projects.c505.com/ascii_index.html. classic rock videos in ascii.. ) Guy Eschemann wrote: > You could use a SRL16/DFF (with clock-enable and synchronous clear) > combination for this. The input pulse - which is high for one clock > cycle -sets the FF output, and a delayed version of this pulse clears > it after a number of clock cycles. The depth of the SLR16 sets the > length of the output pulse. Note that the output pulse is delayed by > one clock cycle with respect to the input pulse. > > _______ > | | > +--| SRL16 |------+ > | |_______| | > | | > | ______ | > | | | | > short pulse -----+--|CE Q|----------- long pulse > | | | > 1--|D | | > | | | > CLK--|> | | > | | | > ---|CLR | | > | |______| | > | | > +-----------------+ > > Regards, > Guy. -- ----------------------------------------------- Please remove the x's in the email address if replying to me personally. Johan Bernsp=E5ng, xjohbex@xfoix.seArticle: 71318
>Or you could pass the clock through a cell before feeding into pin 1, so >you could generate a forced >clock pulse when enable gets asserted. Ding ding ding. Can you say "runt pulse"? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 71319
Brian, LVDCI_33 is 60 mA for the reference resistors. For the whole bank. Wow. Sooooo much current! Face it: setting the reference for the entire bank does take some power (in this case 3.3V X 60 mA or 200 milliwatts. I am pretty sure this is not going to "break the bank." Yes, and if you just had to have all 8 banks use DCI, that would be 8 times as much current. I suggest that you confine the DCI interfaces to those banks that need them, not just for the 200 milliwatts. Freeze DCI has nothing to do with it. The DCI circuit has to solve for 1/2 R, R and 2R, so the average current consumption is higher than it would be for R alone. One trick you can use to cut it in half is to use 100 ohm reference resistors, and use LVDCI_DV2 (divide by two) to get 50 ohm drive. Now you have 100 milliwatts dissipated for the feature of using DCI in the bank. If you are thinking "why did they not use 10X reference resistors? (to lower power per bank)" the answer is very simple: the noise in a typical system would trash a higher impedance reference system, and the feature would have to be abandoned (or fixed) -- sound familiar?. From the first appearance of DCI in Virtex II, it has been a solid feature in every device since. DCI updating is only an issue when you cross between two banks, and even then only with the parallel interfaces where it adds some small amount of jitter. Freezing the updates allowed customers who did not read that they should not go across banks to modify the bitstream, rather than re-design their pcbs. It also allowed the highest speed interfaces to have more timing margin (budget) which makes memory interfacing easier. It is always preferable to provide the customer with solutions that involve changing bits, rather than making new boards (and them failing to place the orders that we desire). Now we have three different DCI options: regular (runs all the time changing +/- one trim), changes only when reguired, and "frozen" after matching (at configuration time). Austin Brian Davis wrote: > Yesterday I wrote: > >> Should be much better in V2Pro and S3 with the new DCI >>control logic to cleanly stop the DCI updates. >> > > Or maybe not- according to the following Answer Record, > there's a 60 mA per bank hit when using LVDCI_33 in a > Spartan 3, so the ~200 mW per bank number still applies. > > I'm not sure why it's still so high, as I thought the main > cause of the high overhead with the V2 DCI was that the > FreezeDCI option randomly stopped the DCI update logic at > whatever state it was in, possibly in an active R/2 matching > mode, rather than cleanly stopping it with VRP/VRN inactive. > > Answer Record #19628 Spartan-3 - How does DCI affect power consumption? > > "In an experiment performed to test current consumption when > using LVDCI, Xilinx found that for every bank that turned > on DCI, the device consumed an extra 60 mA of current" > > > BrianArticle: 71320
Luc Braeckman wrote: > As far as I could discover, this is still a propriatary device, and > therefore you could not use a standard SPI flash instead. If no > competition (read pin/pin compatible replacement) is possible, Altera > could keep up the price as high as they want. > With standard SPI flash, I have the choice of at least 5 different > suppliers, no potentialy delivery problems, and guaranteed lowest > price. Thus driving the total solution cost to a minimum. > > Luc Still unverified by me, but someone pointed here some time ago that EPCS devices are indeed a standard device produced by ST (M25Px0). Anyway, if that's true, Altera has a quite expensive paint... :D RicardoArticle: 71321
Jim Lewis wrote: > > Peter, > Since the Xilinx parts have internal POR, it seems a > shame not to use it. However, since GSR is slow, we > are cautioned against using it due to problems like > these. I don't think the problem with GSR synchronization equals a recommendation to not use the GSR. The point is to use it with "caution" and to take the appropiate design steps. > Is there a way to connect the output of GSR to the > input of the circuit that Ken Chapman suggested in > the section "Strategy for the 0.01% of cases" of his > TechXclusive and leave off the asynchronous reset input. > Would this be a way that I can effectively cause all of > resets (or critical resets) for a clock domain to be > deasserted at the same time without having to > have a redundant external POR? Reread Peter's post. It is a good start and I think you misunderstood some of the points in it. You don't need an external reset and most likely you don't need a sync reset that is "global" to a clock domain. Typically there are subsets of the design which are sensitive to synchronous release of GSR. These circuits are typically FSM, counters and the like. Normally the data path does not care about reset since it will immediately go to the correct state on the next clock. One circuit you can add to any FSM to provide a sync reset is just one or a pair of FFs which work just like a metastability reduction circuit. Have the GSR hold these FFs in the '1' state and wire the D input of the first one to a '0'. The last output will be your sync reset. The sync reset will be held for one or two clock edges after the release of GSR. This will only need to be used by the first two bits of a one-hot FSM, the first changed bit of a gray coded counter, the first bit of a JRC or even the first bit of a binary counter (assuming it starts at 0); and so will not overly complicate them and slow them down. I have done lots of FPGA designs and have never needed anything complex to start the chip up. Just pay attention to the startup and don't assume that all FFs are released at the same time, between FSMs, not just within them. > If this is possible, is there a VHDL coding methodology > that you can recommend? The big missing piece for me > is how do I access the output of GSR? This is something that should be added to Peter's app note. > #1: Explicitly through instantiation? > #2: Implicitly through initializing the VHDL > signals that create the registers? > Although this technique seems possible in XST, > would it also work the same in other synthesis tools? > #3: Put the reset logic in a separate hierarchical > block and explicitly code an asynchronous reset, but > at the next level of the design tie the asynchronous > reset to a constant inactive value? You don't need to access the GSR signal explicitly. If you provide an async reset control that is common to most/all of your sequential logic, I believe the tools will infer the GSR. run_en_reg: PROCESS (sysclk, reset) BEGIN IF (reset = '1') THEN run_en <= '0'; ELSIF (rising_edge(sysclk)) then run_en <= '1'; END IF; END PROCESS; This is what I use. But I only refer to the run_en signal in the FFs that actually need to be released synchronously. > If I have multiple FPGAs and they are all connected > in a serial fashion for configuration, is the internal > POR released at approximately the same time? Approximate is the key word. There is a common sync signal to provide this, but you still have the wide range of delay inside each chip and you need to select what clock is used to control it. > The details of POR and GSR functionality has always been a > little troubling to me, is there a good (really detailed) > application note that you can recommend. You can learn a lot about it by reading how the end of configuration works. But the main thing is to stop assuming that the end of GSR is a synchronous event. On other chips we get used to the reset just working (like magic). In the FPGA we need to give it a little thought, even if it is not really hard. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71322
Hal Murray wrote: > > >Or something else goes wrong, plus the cost of the PROM is comparable to the > >cost of a PCI bridge... > > I wasn't trying to push for or against the PLX type approach. Just > pointing out that there are ways to change the configuration when > your design gets loaded from a PROM. Board space or layour or something > else might make the PLX/bridge unattractive. > > Another potential disadvantage of the PLX/Bridge is a few more clock > cycles if you just want to do a simple read. (Writes can be pipelined.) The design I worked on used a small CPLD along with the PLX chip and allowed the download to come from the main CPU with no PROM. This was used to download different configurations for different modes of operation (selftest vs. record vs. playback). -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71323
On Wed, 14 Jul 2004 11:25:38 -0500, hmurray@suespammers.org (Hal Murray) wrote: >>Or you could pass the clock through a cell before feeding into pin 1, so >>you could generate a forced >>clock pulse when enable gets asserted. > >Ding ding ding. Can you say "runt pulse"? Depends on when you are likely to be using the enable - in most cases it will probably not be a problem, as either the enable will be well seperated from movement signals, and if you are disabling, you probably don't care. Additional terms could be added to the state machine to reduce the risk of false counting if this is an issue.Article: 71324
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:40F5723D.ADC208EC@yahoo.com... > > The design I worked on used a small CPLD along with the PLX chip and > allowed the download to come from the main CPU with no PROM. This was > used to download different configurations for different modes of > operation (selftest vs. record vs. playback). That's exactly what I am doing in most of my PCI designs, but Hal is right in the sense that this is not a universal solution in every case. /Mikhail
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