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
Alex Ungerer wrote: > > Hello, > > I am not sure if this is the right NG, but since it concerns memory > driven by an FPGA, here goes. > > My question is about burst writes to SDRAM memory (be it standard, DDR > or DDR2). > > Is it possible to sustain a burst write for an undefined number of > words? Here is my setup: > I have some incomming flow of data arriving at a constant speed of, > say 250 MWords/s, which needs to be written to memory in a sequential > order, until a Stop signal ends the burst. The length of the flow can > be as long as several times the size of the memory, in that case the > latter data overwrites the old one. > > Do SDRAM require dedicated refresh cycles, even if the write cycles > will access in turn every possible location in the memory? > > Alternatively, would there be a way of refreshing a bank while writing > into another one, without interrupting the 250 MWrd/s data flow? > > If this is technically possible, do SDRAM Controller IPs available > from FPGA vendors (i.e. Xilinx, Altera) support sustained writes with > no gaps in data flow? > > Any pointers to litterature, memory types, SDRAM controller IPs, would > be appreciated. Looks like you have several different answers to your question. The data sheet I looked at says you can do this. "Precharging one bank while accessing one of the other three banks will hide the precharge cycles and provide seamless, high-speed, random-access operation." I did something very much like this once and had a printed app note (that's how long ago it was...) from Micron that described the operation of SDRAMs pretty well. I can't find an electronic version, but most of the info in the Micron data sheet which is not too bad. That Asian data sheets are not nearly as good, but they all work the same other than initialization details and they all are compatible with some basic init sequence. The way to make this work without gaps is to overlap the precharge and read/write commands with the current command. So just make sure you set things up enough so that you meet all the timing specs, and there are a lot of them!!! If your clock speed varies it will be a lot harder to design. BTW, you didn't say if you needed to do this on reads as well? Doesn't the unit play back too, or does it go directly into a PC? -- 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: 75651
David Dye wrote: > > Finally, we still charge for ChipScope Pro because we consider it a > "value-added" product above and beyond the scope of the ISE toolset, > like other tools like EDK, PlanAhead, and System Generator. It is not a > required tool (even though you consider it a "*MUST* Have" -- thanks for > the endorsement!), and I expect we will follow this model for forseeable > future. Hmmm, haven't you see the AOL commercials? We want it free too! -- 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: 75652
Gunther, To connect two fpgas together, one should use the proper standard. LVDCI works, as does LVCMOS 6 mA (no external resistors required) with no simulations (as they are both 50 ohms and will match almost any pcb trace well enough). Any other standards require some SI engineering. The Virtex II family uses 0.35u IO, and they are intrinsically protected by the ESD structures. You can not break them with overshoot and undershoot. But you can create functional problems, and even change BRAM and config bit contents if you slap the substrate silly with currents! The Virtex II Pro, S3, and V4 families uses faster 0.25u transistors, and the reliabily is affected if the IO pin is forced to a voltage below ground (> 4.05V stress on the pmos output transistor = Vcco - undershoot < 4.05V). This is detailed in the data sheet under the abs max stresses. Not paying attention to signal integrity is just playing 'Russian Roulette' with more than one chamber loaded -- very risky business. Austin Gunter Knittel wrote: > Austin, > > thanks very much for your answer. It's in a sense good to know that > the simulation seems to be accurate - despite the fact that we then > have to worry more about signals and spend more real estate for > terminations. > What makes me wonder, though, is that the simulations also said that > one cannot even connect two FPGAs directly without violating > undershoot limits - this doesn't reflect reality. > What I really would like to know is whether or not I can damage > the 2V4000 chip with strong over/undershoot. You said that the > clamp diodes will withstand that stress, but what about the > MOS transistors? The voltage across the gate oxide might become > too large if excessive current causes a large voltage drop across the > clamp diodes. I couldn't find anything on this topic in the VII-docs. > Can you shed some light on this? > > Thanks very much > Gunter > > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:cmtdif$ru81@cliff.xsj.xilinx.com... > >>Gunter, >> >>The protection diodes are clamping the overshoot and undershoot. They >>will not be damaged, but your signal integrity is terrible, you will have >>excessive jitter, and that may lead to bit errors, and other behavior that >>you will not like at all. >> >>I doubt the simulation is pessimistic, as I get the same results, and >>often worse when too strong a driver is used unterminated. >> >>I suggest a small series resistor at the driver to better match the lines. >>Perhaps somewhere from 22 ohms to 43 ohms. Simulate until you have the >>best choice for the slow/weak and fast/strong IBIS model corners. >> >>Oh, and thank you for using IBIS before you built the board. We are happy >>(and you are happy) when you fix problems before the board layout. >> >>Austin >> >>Gunter Knittel wrote: >> >> >>>Hi, >>> >>>I'm planning to use ALVCH-Transceivers located 4-8 inches away from a >>>2V4000 FPGA. >>>The board impedance is said to be 50R. I used IBIS models for both >>>the transceiver and the FPGA (LVCM316S), and simulated one wire using >>>PSPICE. The line is not terminated in any way. >>>I get serious overshoot (>4V at 3.3V VCCO) and undershoot (-1V) >>>at the (tri-stated) input of the FPGA. Current reaches 100mA during a >>>short spike, otherwise some 50mA. >>>My question: is this tolerable? >>>Doc for VII-Pro states that the FPGA would suffer damage (gate oxide >>>breakdown). >>>Could it be that the simulation is too pessimistic in these cases? >>> >>>Thanks for any help >>>Gunter >>> >>> > >Article: 75653
Ian, MGTs for V4 are 622 Mb/s to 10 Gb/s each. They are similar to the already shipped and working 10 Gb/s transcievers in Virtex II Pro-X. They can be channel bonded together for even higher aggregate data rates. Austin Ian Dedic wrote: > I'm looking ahead to an application in the future which will need a > lot of DSP power but more importantly a huge amount of I/O bandwidth > (interfacing to multiple ultra-high-speed DAC/ADCs). Up to now we've > used parallel LVDS buses at up to 1Gs/s for this, but this eats lots > of pins and is a PCB nightmare, so we plan to switch to serial I/O for > which we have on-chip transceivers available. > > I've been trying to work out what total serial I/O capability is > available on the latest (and near future!) FPGAs, but it's not always > easy. In the timescales I'm looking at I guess that the likely > candidates are Virtex-4 (for which little information is available on > the MGTs), and whatever the "next-generation" Altera device is > (Stratix-II doesn't have serial I/O, Stratix GX does but may be > lacking in processing power) -- can anyone at Altera give any clue > about this? > > For Virtex-4 I'm confused about what the actual serial data rate on > each pin pair is for the MGT -- I understand that there are up to 20 > MGT, and that these can be "up to 12GB/s", but I assume that this is > done by bonding together 4 physical 3Gb/s channels into 1 virtual > 12Gb/s channel -- is this correct? > > In that case each block of 4 MGTs can do 12Gb/s; if not then this is > the rate for each MGT, but I think this is extremely unlikely -- 300ps > bit period is OK since it needs rise/fall times of about 80ps which is > achievable in this technology, but 80ps bit period needs 20ps tr/tf > which is not! > > So it seems that both Altera and Xilinx are similar here; both use > blocks of 4 transceivers at 3.125/3.25Gb/s per channel, or 12.5/13Gb/s > per block. Both have a maximum of 5 blocks (20 channels) per chip. > > Is this correct? > > What's coming in the next couple of years as far as serial I/O is > concerned? > > Cheers > > Ian Dedic > Chief Engineer > Mixed Signal Division > Fujitsu Microelectronics Europe > > P.S. If there are things which can only be revealed under NDA, please > contact me off-list since we have NDAs with both Xilinx and Altera.Article: 75654
Jim Granville wrote: > > To update this, for a topical example of SoC design to vary Both CLK and > VCC, I see this : > > Synopsys, UMC, join ARM, National for low-power SoC demo > http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=ABWJJD3VJ1Z2IQSNDBGCKHSCJUMEKJVN?articleID=52500027 > > It states: > > "The demonstrator is set to use adaptive voltage scaling as well as > frequency scaling. The system is expected to make use of the lowest > voltage and frequency required to meet software deadlines while > maintaining user quality." > > So, sometime in 2005, we might see a 'like process' comparison between > the above and this Async alternative > http://www.arm.com/news/6936.html > > and maybe the FPGA vendors will start to follow this ? I seriously doubt that FPGA vendors are looking at async design as anything other than a far out possibility. The big problem is not any of the technical issues, but one of tools, support and training. This is not unlike the problems of using hydrogen powered cars. There is no support mechanism for distributing the H2, no repair shops than can work on it, emergency services are not prepared to deal with it... Just having chips and a tool to support async design would only be a part of the problem. It would be a *MAJOR* paradigm shift which will not come until some huge pressure is forced upon them. In other words, don't hold your breath... -- 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: 75655
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cmvum3$ici$1@news.cs.tu-berlin.de>... > Dear newsgroup community, > > recently I came across the following challenge. There are several digital > values which I want to convert to analog signals. Ok then, no problem. > Simply D/A conversion! But after converting the signals the general set up > requires that these values should be held for about - let's say - a period > of 5 minutes with practically no droop (decay of the analog value) at best! > The D/A conversion itself takes place in a 1 MHz period, the values to be > set have to pend for about 5 minues. I guess a hold-element (capacitor and > op-amp) would be the obvious choice. But how should I dimension the > capacitance and how can I affect the droop? Is it realistic to expect > virtually no droop assuming an optimal configuration ? Isn't it, that with a > large time constant the charging time would be endless, too? Please help me, > if you can. I am almost become desperate. I need this for my graduation > report. > > Thank you in advance and many greets > Veronica You might investigate the use of serial DAC's. Depending on the requirements, they have a small footprint and are relatively cheap. You could use one for each channel, and it should hold the value until you change it. Keep up the faith, NewmanArticle: 75656
The first, uh, second, uh, the lower question is easier to answer. Use a testbench to describe the environment the chip is working in. All of your IOs are ports at the top level, right? Instantiate the chip in the testbench module and connect the clock in/out with a signal. If you already have a testbench, what is it doing? As to the second, I have not done that before. I expect you can instantiate two modules (chips) in one test bench. You may not even have to do anything special. Try just adding the files for the second module to the simulator project and instantiate the second chip in the test bench. "vax, 9000" wrote: > > A somehow related question is, how do we simulate an interconnected two-chip > design in Xilinx Webpack? My design fits in two XC95144XL CPLD's and I'd > like to simulated the post-fit design. Thanks. > > vax, 9000 wrote: > > > Hi group, > > Sorry to bother you again. I am developing code for a hobby project and > > I > > need to simulate my design with some off-chip-connected-pins. For example, > > I generate a secondary clock on chip, output it from a pin, and feed it > > into another pin (dedicated clock pin). How do I simulate it? Where do I > > tell the simulator that the two pins are connected? I guess one possible > > place is the test bench vhdl source file, and another possible place is > > the simulator command lines where I 'force' the input pins. I googled and > > it seemed that I could not find a good combination of words to dig out the > > answer. I am reluctant to rewrite the code and connect the signals on > > chip, because I want to use the dedicated clock pin. > > Thank you. > > > > vax, 9000 -- 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: 75657
Henk van Kampen wrote: > Francesco: > Your compiler assumes memory is attached to the I/O port, which is > usually not. When it is, it is mostly special purpose read or write > only memory (registers) not fit for storing variables. The idea with a > C compiler for Picoblaze is to have an intelligent use of the > registers. In your example all variables should be registers. Only if > needed you should offload variables to some scratchpad. The > Picoblaze-3 core (KCPSM3.vhd) has a 64 byte scratchpad for that, with > its own set of I/O instructions FETCH and STORE. Of course you must > also be able to declare references to the I/O ports to control your > attached hardware, which will then use INPUT and OUTPUT. A problem > with Picoblaze in relation to a, say C, compiler is its inability to > work with constant arrays (lookup tables, constant strings) and > computed jumps, often you end up with lists of compare/branch lists. > Otherwise Picoblaze is tiny yet powerful core to control all sorts of > things in an FPGA design. Your C compiler, if more focussed on the > typical use of Picoblaze, could nevertheless be very useful in using > the core. > Henk van Kampen I would also look at the HLA, here http://webster.cs.ucr.edu/AsmTools/HLA/hla2/0_hla2.html There is an opening for more portable assemblers, call it a "Structured Assembler", or a C-Syntax Assembler, if you will. These will always be subsets, but if they implement a common preprocessor, and in-line asm, for example, then it will be possible to have one source file that is portable. Eg A design could start on a PC, to develop the algorithm, and then be re-coded/optimised as needed, to target tiny cores, like the PicoBlaze, et al. -jgArticle: 75658
weizbox wrote: > > Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com> wrote in message news:<41932cc1$0$20382$ba620e4c@news.skynet.be>... > > What about the Avnet Virtex-4 kit ? > > > > http://www.em.avnet.com/evk/home/0,4534,CID%253D16863%2526CCD%253DUSA%2526SID%253DNoNav%2526DID%253DDF2%2526LID%253D4746%2526BID%253DDF2%2526CTP%253DEVK,00.html > > > > > > 299$ For a virtex 4 sounds ok. It's only 3x the price of the spartan3 starter kit and has lots of stuff. > > > > > > > > Sylvain > > That definetly has been the best priced thing ive seen so far. Thank > you very much for that link, I beleive I will be getting that. Wow! That really *is* a special price. Their Spartan 3 board is $400 with an XC3S400! -- 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: 75659
rickman wrote: > Jim Granville wrote: > >>To update this, for a topical example of SoC design to vary Both CLK and >>VCC, I see this : >> >> Synopsys, UMC, join ARM, National for low-power SoC demo >>http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=ABWJJD3VJ1Z2IQSNDBGCKHSCJUMEKJVN?articleID=52500027 >> >>It states: >> >> "The demonstrator is set to use adaptive voltage scaling as well as >>frequency scaling. The system is expected to make use of the lowest >>voltage and frequency required to meet software deadlines while >>maintaining user quality." >> >> So, sometime in 2005, we might see a 'like process' comparison between >>the above and this Async alternative >>http://www.arm.com/news/6936.html >> >> and maybe the FPGA vendors will start to follow this ? > > > I seriously doubt that FPGA vendors are looking at async design as > anything other than a far out possibility. The big problem is not any > of the technical issues, but one of tools, support and training. This > is not unlike the problems of using hydrogen powered cars. There is no > support mechanism for distributing the H2, no repair shops than can work > on it, emergency services are not prepared to deal with it... Just > having chips and a tool to support async design would only be a part of > the problem. It would be a *MAJOR* paradigm shift which will not come > until some huge pressure is forced upon them. > > In other words, don't hold your breath... The new example I gave was NOT async; it was intended to show how some of the advantages of Async design (Vcc and Clk scaling) can be used in sync designs. In Async, the 'clock' scales with Vcc automatically, in Sync you need to adjust both Vcc and Clk, and probably add some HW support so you can (using their words) "make use of the lowest voltage and frequency required to meet software deadlines while maintaining user quality." ie it would be nice to have some deadline margin feedback, for better system behaviour than 'slow it down until it crashes' :) What UMC/ARM/Natsemi are doing, COULD be applied to FPGAs with not much effort. To show how the FPGA vendors are following the power problems, look at http://www.xilinx.com/products/spartan3/spartan3l.htm The detail is more disappointing than the headline, but it IS a simple first step. ie calling a device with all power but IO's removed, IO tri-stated, and needing a re-config for startup, 'quiescent' is a bit of a stretch. Smarter design would allow the IO state to preserve, maybe that will come in newer families. -jgArticle: 75660
How did you get the T-Shirt? I would like to get one! HendraArticle: 75661
Try the Virtex II datasheet. It shows a block diagram where even the two data bits don't connect to the "DDR MUX" so it works with no inputs! If you go into the FPGA editor you see something similar and while you hold your mouse over the mux the popup description includes the words black box. I think Xilinx is trying to simplify the diagram to reduce clutter. The mechanism must have the clocks because it has to switch on the rising edge of each input clock (after the programmable inversion). If I had to code this in Verilog it would look like: always @ (posedge FF1CLK) muxout <= FF1Q; always @ (posedge FF2CLK) muxout <= FF2Q; although I doubt the synthesizer would infer a DDR flop from this code. hmurray@suespammers.org (Hal Murray) wrote in message news:<WIudnfKZPqlYVQ_cRVn-vw@megapath.net>... > I'm looking at the IOB diagram for Spartan3. The output > path has a block labled "DDR MUX" that seems like it should > do the obvious thing. > > It's got two inputs - the data bits. > > How does it know when to switch? Does it get both clocks > too, through some path that isn't shown?Article: 75662
On Thu, 11 Nov 2004 10:06:05 +0100, Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote: >> What's the part number? > >I think it was A100 and/or A110. > > Jan A121 rings a bell, vaguely. It was a fast 2D DCT processor rather than general purpose image processing, probably aimed at the MPEG market. Come to think of it, the core may live on in SGS digital TV chips. On the original topic, there are good notes on computer arithmetic and ALU design around. Best online introduction I have found was some course notes from Reto Zimmermann at ETH Zurich, downloadable from this page. http://www.iis.ee.ethz.ch/~zimmi/arith_lib.html For CORDIC, also see Ray Andraka's page, I think www.andraka.com And for a VHDL starter, google for Peter Ashenden's "VHDL Cookbook" ... his paper book is also recommended. - BrianArticle: 75663
Hi,
I have a design targeting V2P7 chip, in PAR there is an error saying
that my design uses more global buffers than it can be allowed, and
stating that each region can only have 1 global buffer, either primary
ot secondary.
V2P7 has in total 16 global buffers. In this design I have 10 global
buffers used, but I have another design using 9 buffers and works great.
Both designs use 4 DCM, and the only difference between the two design
is I use one more global buffer to connect the 4th DCM clk0.
I am trying to lock down the DCM and global buffers manually in UCF,
but got bad luck. In FPGA editor I can see that in 9-buffer-design, the
4th DCM is at X0Y0 and on the same side of the FPGA, global buffer 7S,
6P and 5S are unused. So what I do is like this in UCF:
1) lock all 4 DCM and 9 buffers as they are done in 9-buffer-design
2) lock the 10th buffer to 6P.
But I get the same error from PAR, then I tried 7S, still same.
I wonder if it is right of my doing this way, although I will try 5S.
Thanks so much.
Article: 75664Hello John, The restriction is that each primary and secondary clock buffer pair can not drive clock loads within the same clock region. This translates to eight possible clocks per clock region. The DCMs count as clock loads so this rule applies to them too. Perhaps you have two DCMs LOC'd such that there is a primary secondary clock conflict? One way to debug this issue is to load the mapped NCD in FPGA Editor where it will display all LOC'd logic as already placed. By hi-lighting each clock net in turn, you'll be able to see which clock regions each clock net is using. You can tell where the clock region boundaries are by turning on the long line display and noting where the long lines are partitioned. If this doesn't help, please post the complete PAR error message. Your description doesn't correspond to any message I would expect to see from the clock placer. Thanks, Bret John Black wrote: > Hi, > I have a design targeting V2P7 chip, in PAR there is an error saying > that my design uses more global buffers than it can be allowed, and > stating that each region can only have 1 global buffer, either primary > ot secondary. > > V2P7 has in total 16 global buffers. In this design I have 10 global > buffers used, but I have another design using 9 buffers and works great. > Both designs use 4 DCM, and the only difference between the two design > is I use one more global buffer to connect the 4th DCM clk0. > > I am trying to lock down the DCM and global buffers manually in UCF, > but got bad luck. In FPGA editor I can see that in 9-buffer-design, the > 4th DCM is at X0Y0 and on the same side of the FPGA, global buffer 7S, > 6P and 5S are unused. So what I do is like this in UCF: > 1) lock all 4 DCM and 9 buffers as they are done in 9-buffer-design > 2) lock the 10th buffer to 6P. > > But I get the same error from PAR, then I tried 7S, still same. > > I wonder if it is right of my doing this way, although I will try 5S. > > Thanks so much. > >Article: 75665
I had a similar problem with an Actel ProAsic. I just wanted to test the PLL before using it in my design, so I just connected the inputs and outputs of the PLL to pins on the FPGA. It didn't synthesize. I contacted tech. support and this person found out that I needed to drive some logic with the PLL for it to synthesize. (could be any dummy logic). And this seemed to be a peculiarity of this ProAsic+ devices, because apparently there wasn't a problem with other families (I don't know, I just have the ProAsic+) Good luck. ALuPin wrote: > ALuPin@web.de (ALuPin) wrote in message > news:<b8a9a7b0.0411110211.457ecd58@posting.google.com>... >> Hi newsgroups users, >> >> maybe someone has experienced the following problem: >> >> >> I have a HDL design in which a PLL is instantiated (QuartusII). >> >> To test the functionality of the PLL I made a smaller design >> containing exactly the same PLL. >> For the small design I have found out that the PLL does work. >> >> When I compile my original design I can see that the PLL does not >> work. >> >> As I said the pin assignments and pll assignments are exactly the same. >> >> Where could be the problem? >> >> Unused pins are set to ground. >> There are also defined input pins which are not used. Could it be >> that the fitter does produce some strange combintation of >> setting the unused input pins to ground so that some driver >> conflict exists ? > > Something additional: > > I have found out that when I reserve all unused pins > 1. as inputs, tri-states --> PLL does not work > 2. as outputs, driving ground --> PLL does not work > > 3. as output, driving an unspecified signal --> > The PLL works > > I do not understand why this has an influence on the PLL. > I would appreciate your opinion. > > Rgds > AndréArticle: 75666
Hello all, I have a microcontroller running at 40 MHz that performs asynchronous bus transfers, and I have an FPGA running at 100 MHz. With talk of metastability and all I would conclude that sending some of the control signals through flip flops (say 2 levels) would eliminate any metastability. The question then becomes how do I keep the bus transfers short enough without incurring significant delays between registering a read command (for example) and then responding to it and placing the data on the bus to be read. This would have 2 clock cycles to eliminate the metastability on the read signal (and address lines if I want to worry about metastability with those lines) and then at least one more for the data to be placed on the bus, a total of three clock cycles. That is too much time to get the data on bus (if I'm trying to keep the bus cycles short). I would appreciate some advice on how others have handled transferring data between an asynchronous device and an FPGA. Would it not be acceptable to make an asynchronous interface block for the FPGA, and then pull it into the synchronous world inside the chip? This seems to go against the metastability thoughts that I've come across. Any and all comments would be appreciated.. Thanks, JasonArticle: 75667
Jason: It would be nice to have more specifics on your problem. Inherently ther is no difference between an FPGA (which one) and anything else. Which kid of metastability? Which kid of microcontroller? Do you use the same clock, and derive one from another ? (I guess no). Here having somewhat synchronous clocks simplify the problem, but async transfers are ok... as long as you do not violate any timing requirement (mostly cpu/memory). I would suggest to derive one clock from another if you could. The somewhat brute force way to resolve this issue would be to use of FIFO's between busses but you probably can do better. There is no way you can avoid a proper assessment of timing closure! -- All the luck. Jason Berringer wrote: > Hello all, > > I have a microcontroller running at 40 MHz that performs asynchronous bus > transfers, and I have an FPGA running at 100 MHz. With talk of > metastability and all I would conclude that sending some of the control > signals through flip flops (say 2 levels) would eliminate any > metastability. The question then becomes how do I keep the bus transfers > short enough without incurring significant delays between registering a > read command (for example) and then responding to it and placing the data > on the bus to be read. This would have 2 clock cycles to eliminate the > metastability on the read signal (and address lines if I want to worry > about metastability with those lines) and then at least one more for the > data to be placed on the bus, a total of three clock cycles. That is too > much time to get the data on bus (if I'm trying to keep the bus cycles > short). I would appreciate some advice on how others have handled > transferring data between an asynchronous device and an FPGA. > > Would it not be acceptable to make an asynchronous interface block for the > FPGA, and then pull it into the synchronous world inside the chip? This > seems to go against the metastability thoughts that I've come across. > > Any and all comments would be appreciated.. > > Thanks, > > JasonArticle: 75668
Jason Berringer wrote: > Hello all, > > I have a microcontroller running at 40 MHz that performs asynchronous bus > transfers, and I have an FPGA running at 100 MHz. With talk of metastability > and all I would conclude that sending some of the control signals through > flip flops (say 2 levels) would eliminate any metastability. The question > then becomes how do I keep the bus transfers short enough without incurring > significant delays between registering a read command (for example) and then > responding to it and placing the data on the bus to be read. This would have > 2 clock cycles to eliminate the metastability on the read signal (and > address lines if I want to worry about metastability with those lines) and > then at least one more for the data to be placed on the bus, a total of > three clock cycles. That is too much time to get the data on bus (if I'm > trying to keep the bus cycles short). I would appreciate some advice on how > others have handled transferring data between an asynchronous device and an > FPGA. > > Would it not be acceptable to make an asynchronous interface block for the > FPGA, and then pull it into the synchronous world inside the chip? This > seems to go against the metastability thoughts that I've come across. > > Any and all comments would be appreciated.. Does the FPGA not have DualPort RAM blocks ? -jgArticle: 75669
Jason, If seems you have to either use speed buffer with FIFO or you have to do handshake between two clock domains. Hope somebody else can suggest other approaches. If you know the relationship between 2 clock domains, you may simplify your circuit a little. ChingArticle: 75670
"vax, 9000" <vax9000@gmail.com> wrote in message news:<cmvomm$2ah$1@charm.magnus.acs.ohio-state.edu>... > suntthekid wrote: > > > I simulate vhdl code in modelsim and then it is correct. but, when i > > burn this code into FPGA chip (Stratix S25F672C6) it's wrong (i saw a > > signal in signaltap and found it 's wrong) > > so i want everybody who know this problem help me to solve this > > problem > > thank you > > Did you simulate the circuit after you fit it into the chip? > > vax, 9000 No, i simulated code before fit it into the chipArticle: 75671
Hello,
I have a problem about set up inout port when i simulate vhdl code It
is not work
so i want to know how to write vhdl code ( set pin to inout and
it is work) also i try to use tristate but It is not work too. maybe i
miss something in the code and i don't know. help me please
thank you
Article: 75672"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message news:6rl7p01cr1fkdf0b3i2ptsvoil6ck5akoc@4ax.com... > On Thu, 11 Nov 2004 10:06:05 +0100, Jan Vorbrüggen > <jvorbrueggen-not@mediasec.de> wrote: > >>> What's the part number? >> >>I think it was A100 and/or A110. : > A121 rings a bell, vaguely. It was a fast 2D DCT processor rather than > general purpose image processing, probably aimed at the MPEG market. Checking the databook: A100: Cascadable signal processor A110: Image and signal processing sub system A121: 2-D discrete Cosine transform image processor B009: DSP system evaluation board D703: DSP development system People might want to check out the videocore processor at http://www.alphamosaic.com/ 8 billion ops at 50 mW. I've seen it do real time video processing that used to need a Quantel multi-transputer system costing tens of thousands. Now it is in mobile phones at a few quid per chip...Article: 75673
Jim Granville wrote:
> Does the FPGA not have DualPort RAM blocks ?
...or a PLL to generate both clocks?
-- Mike Tresleler
Article: 75674"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:cmvum3$ici$1@news.cs.tu-berlin.de... > Dear newsgroup community, > > recently I came across the following challenge. There are several digital > values which I want to convert to analog signals. Ok then, no problem. > Simply D/A conversion! But after converting the signals the general set up > requires that these values should be held for about - let's say - a period > of 5 minutes with practically no droop (decay of the analog value) at best! > The D/A conversion itself takes place in a 1 MHz period, the values to be > set have to pend for about 5 minues. I guess a hold-element (capacitor and > op-amp) would be the obvious choice. But how should I dimension the > capacitance and how can I affect the droop? Is it realistic to expect > virtually no droop assuming an optimal configuration ? Isn't it, that with a > large time constant the charging time would be endless, too? Please help me, > if you can. I am almost become desperate. I need this for my graduation > report. > > Thank you in advance and many greets > Veronica > > Write the DAC once and stop clocking it. Other than noise pick-up through the power-supply, reference and any other analog signal conditioning, the value should remain static. This is assuming you aren't using some kind of bizarre AC coupled output DAC. Rob Young
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