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
mfgunes wrote: > I'm trying to implement a basic data reading > and writing to bram with microblaze. http://www.xilinx.com/bvdocs/ipcenter/data_sheet/FSL_V20.pdfArticle: 122151
> I might have 2 > inches of space below the chip on one machine, but can't even have a > quarter inch worth of overhang in that same place on another. > > Now, I do realize that an especially small package chip means that I > won't be able to have a high gate count or as many io pins, but I > don't believe my project even needs that. Links ;) http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=3D122-148= 4-ND http://enterpoint.co.uk/component_replacements/craignell.html http://www.opencores.org/projects.cgi/web/t65/overview In a Spartan3E 500 you can fit a complete microblaze system...Article: 122152
I've found only the complete UCF file for ML506 board. but not for the ML501. What solution do you suggest me, please? Callisto.Article: 122153
"HT-Lab" <hans64@ht-lab.com> wrote in message news:Z8kni.12$SI5.4@newsfe2-gui.ntli.net... > I have [a Mersenne Twister] on my website if you need an example, > > http://www.ht-lab.com/freecores/mt32/mersenne.html Thanks. That worked beautifully. I felt guilty destroying the histogram by limiting or scaling the range to 601 limits, but it's fine for my purposes. The original paper is a bit beyond me, but I couldn't see any obvious way to restrict the number range. Once again, thanks. Pete From removethisthenleavejea@replacewithcompanyname.co.uk Fri Jul 20 13:33:06 2007 Path: newsdbm05.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!news.netfinity.fr!club-internet.fr!feedme-small.clubint.net!feeder1-1.proxad.net!proxad.net!feeder2-2.proxad.net!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!proxy02.news.clara.net From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> Newsgroups: comp.arch.fpga References: <1184943452.134851.300550@d55g2000hsg.googlegroups.com> Subject: Re: Xilinx fpgas... Date: Fri, 20 Jul 2007 21:33:06 +0100 Lines: 53 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-RFC2646: Format=Flowed; Original X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 23c4e1312e00852466040311d67282822330300a17a135e13332293846a11c0c NNTP-Posting-Date: Fri, 20 Jul 2007 21:33:16 +0100 Message-Id: <1184963596.17722.0@proxy02.news.clara.net> Xref: prodigy.net comp.arch.fpga:134030 John Our Craignell modules use the small CP132 package giving a choice of XC3S100E, XC3S250E or XC3S500E on these. There are very similar to what you want to do. Some pictures here http://www.enterpoint.co.uk/component_replacements/craignell.html. There is a derivative of these boards coming shortly called Drigmorn1 that I am hoping will be the cheapest development board in the market and maybe the smallest as well. John Adair Enterpoint Ltd. "John Oyler" <john.m.oyler@gmail.com> wrote in message news:1184943452.134851.300550@d55g2000hsg.googlegroups.com... > I've been looking at the Spartan 3an's mostly, because of the built-in > config flash, but I've yet to settle on them as the preferred chip for > my project. As it turns out, another chip I'm wanting to use is bga, > and since it's unavoidable I've been looking for the same in the fpga. > It would be really nice if there was a bga chip at or around 10-12mm > in size... but I can't seem to find any such. Only the larger gate > count fpga's are bga package, and most of those seem to come in at > around 20mm in size... which means the board I'm working on would be > wider than the dip chip that it's replacing. Something I'm willing to > live with, but certainly more challenging because the chip is in > several machines that each have their own board layout. I might have 2 > inches of space below the chip on one machine, but can't even have a > quarter inch worth of overhang in that same place on another. > > Now, I do realize that an especially small package chip means that I > won't be able to have a high gate count or as many io pins, but I > don't believe my project even needs that. > > So, does anyone have any suggestions? I'm not married to Xilinx, an > Altera or Lattice chip that made things easier here would really rock. > > > Slight topic change: What do you guys think of this board for a > learner's first fpga? > > http://www.digilentinc.com/Products/Detail.cfm?Prod=BASYS&Nav1=Products&Nav2=Programmable > > It's well within my price range, I could afford more, and I don't want > to get something so weak it can't even teach me anything. Is 100 > kgates enough to implement an 8bit cpu? Would I be able to implement > an ethernet core or usb with it? Etc. Just want an opinion. > > > Thanks, > John O. >Article: 122154
At power-up, I need to run the Virtex GTP at 400Mbps and then after the initialization, I need to run the V5 GTP at 3.2 Gbps. In order to keep it simple, I am thinking about running the V5 GTP at 3.2 Gbps all the time - even at power-up. Thus to achieve the lower data rate of 400Mbps, I plan to write the same data 8 times (3200Mbps/400Mbps). The FPGA fabric state machine will write the data to be sent to the GTP into a deep dual port fifo. The logic on the GTP side will retrieve the data from the fifo and write to the GTP parallel data input 8 times. Please let me know if there is a better way to do this then this. Thanks. Eddie.Article: 122155
<Eddie H> wrote in message news:eea822f.-1@webx.sUN8CHnE... > At power-up, I need to run the Virtex GTP at 400Mbps and then after the > initialization, I need to run the V5 GTP at 3.2 Gbps. > > In order to keep it simple, I am thinking about running the V5 GTP at 3.2 > Gbps all the time - even at power-up. > > Thus to achieve the lower data rate of 400Mbps, I plan to write the same > data 8 times (3200Mbps/400Mbps). The FPGA fabric state machine will write > the data to be sent to the GTP into a deep dual port fifo. The logic on > the GTP side will retrieve the data from the fifo and write to the GTP > parallel data input 8 times. > Looks like you are thinking that you would be transmitting user data at the line rate. This is hardly possible and not required in any case. If you use Aurora IP core all you need to do is to choose your line rate slightly higher than the actual throughput required for the application (do some reading on Aurora to find out the details). At that point you can pass data at any speed not surpassing the maximum throughput available at the chosen line rate. From a user point of view Aurora channel looks like a FIFO. You write data into it at the transmit side and you read from it at the receive side.... As simple as that. /MikhailArticle: 122156
Mikhail, On powerup, I would like to transmit the 400 Mbps data using GTPs conifigured to run at 3.2 Gbps. This is because after the training I need to run the data at 3.2 Gbps. Basically I am curious if GTP has oversampling capability on the transmit side so that I can transmit 3.2 Gbps configured GTP at 400Mbps. Thanks. Eddie Eddie.Article: 122157
On Jul 9, 3:41 am, naude.j...@gmail.com wrote: > On Jul 8, 4:08 am, "cwoodring" <cwoodr...@cox.net> wrote: > > > > > Hi, > > I've been working on a simulink model built using the Xilinx Blockset to > > try to verify the function of an interplation filter made from the MacFir > > Core. The full working VHDL version of the complete data path where the > > input data goes into a fifo and is read out to the filter as it is ready for > > data. The filter does a simple up by 2 interpolation and the output data is > > written to another fifo for eventual output. This filter actually handles 64 > > channels. The input rate for the data is 100KHz and the Output rate is to be > > 200KHz. > > In my simulink model I read the data for a input signal consisting of 2 > > sine waves, one well within the filters passband and one in the stop band, > > from the MATLAB workspace. I then multiplex that same data to 28 channels > > and feed the filter which is intantiated in the Simulink model as a black > > box as per Matlab's help file for inserting a Xilinx core into a model. > > I've had a lot of confusion about sample rates and how to deal with them > > in Simulink, but I think I'm finally getting the hang of them. The output > > rate is 2x the input rate for the complete system - fifo in to fifo out but > > the filter runs very fast compared to the actual data rate in and out. > > The Modelsim simulation of the whole VHDL coded system seems to be > > working- I get 2 samples out for every one in on all the channels and the > > data is written to the output fifos ok. Since the data is fixed point I > > wanted to verify my output values with what I get in the Simulink model > > which uses the fixed point blockset etc. The biggest issue I have is that > > the Modelsim simulation goes very fast and outputs data from the filter > > every usec or less while the Simulink model using the Modelsim output block > > takes milliseconds to produce an output data. It does give me 2 values for > > every one in and the filter model appears to be working ok, but the clocking > > of the whole model is running at a sample rate of 100KHz. . I use modelsim > > under the control of Simulink to run the simulation and the fastest clock in > > the simulation is 200KHz. The system clock in the "real" VHDL system is > > 80MHz. When I try to increase the system clock in the SystemGenerator block > > to anything faster than 1MHz I get some error about an unresolved Boolean > > value and the simulation doesn't run. > > Has anyone matched what an actual synthesizable system to a Simulink > > model at the actual clock rates used in the VHDL simulation? When I look at > > all the example files for simulink it seems they always use sample rates of > > 1sec which seems ridiculous when trying to match clock rates in an FPGA > > system. Am I really off the mark here or to I just have to run my Simulink > > model for 45 minutes to match what the VHDL model gives me in 2 seconds? > > > Totally dazed and confused, > > > CTW > > There are different ways to handle the clocks in System Generator. It > can be confusing. > > If your real clock is going to be 80MHz, create a variable > T_system_clock = 1/80e6 in your Matlab workspace. Use this variable in > your System Generator token. Now make sure that the clock rates in > your system are all integer multiples of this clock. For example, if > your FIR input runs at 100kHz, set the sample period of the filter = > (1/100e3)/T_system_clock. This will be an integer multiple of the > system clock. Now in the Simulink 'Simulation Stop Time' you put > N*T_system_clock where N is the number of clock cycles which you want > to run the simulation for. The times shown in a scope window for > example will match the actual time related to the 80MHz clock in > hardware. > > Basically the clock that is specified in the System Generator token > must be equal to the fastest clock in your system, the slower clocks > will all be generated with CE's by System Generator and you will not > get errors about clocks that are not integer clock cycles of the > system clock. > > One more thing, use the FIR Compiler and not the MAC FIR as it will be > replaced by the FIR Compiler. > > Hope this helps Hi all, I'm using sysgen to implement my design. I've already designed a group of 5 filters, using sysgen, which I'm using to pre-process my data, which works fine. However I still have some confusion with it. The input to these filtering stages is a file which contains data sampled at 200 hertz(samples per second). If I enter the simulink system period in the xilinx block to a value between 0.2s to 2s, the design works. However, for any value lower than 0.3s the design fails completely. I donno what this sytem period implies in actual terms, but it doesn't make any sense to me at all, given that the sampling period of my data should be 1/200, which doesn't work. This is one part of the problem. In the second phase I added 4-5 black box modules to my current design, which basically plays with the pre-processed data obtained from the above filtering stages. Now, When I connected everyting together, I got an error that there's some problem with the sample rate and types in the feed back loops between the modules. I used the hints given with the errors, by introducing assert and delay block, to get rid of these nagging errors and I specifically provided the sample rate to be equal to that of the output from the filtering stages. Now this helped me in getting rid of all the errors involving algebraic errors in the loops etc. However, the output that I get is pretty crappy. Something doesnt seem to be right, with the sample rates as I already tested my vhdl code in modelsim, and they worked fine. Long story short, Can anybody please help me solve this issue of specifying the sample rate in sysgen both in the sysgen block and black boxes. I followed the instructions given on this page too, however, just like the cwoodring, even I couldn't get it to work. The filter behaves in a weird manner and doesn't look like its giving the right output unless the simuling sample time is set to 1, which is ridiculous. Please respond if you have any clue as to what's goin wrong. Thanx in advance.Article: 122158
Symon,John_H : Thank you for your help, I still have several questions to ask you. 1)If two signal layers share the same reference gnd plane, will their return currents react each other? 2) I see a ten-layer stack recommended by ‘High-speed digital design’ (Johnson) P220 >From top to bottom: ------------------------- signal(horizontal routing) signal(vertical routing) gnd signal (horizontal routing) signal(vertical routing) signal (vertical routing) signal( horizontal routing) power signal (horizontal routing) signal(vertical routing) ------------------------- I don’t think it is good especially for a mixed-signal board. For example, it uses a power plane as a reference, at the same time if I split it into several mini-planes, that will cause EMI, right? 3)I plan to make my board as a six-layer one, what is best layer-stack you think? (In my board, there are 3 volt levels: 3.3V for FPGA,ADV7181,ADV7123;1.8V for ADV7181; 1.2V for FPGA ) Could [Top--gnd(integral :))--signal--power--gnd(integral :))--bottom] be the best?Article: 122159
commone wrote: > Symon,John_H : > Thank you for your help, I still have several questions to ask you. > > 1)If two signal layers share the same reference gnd plane, will their > return currents react each other? > > 2) > I see a ten-layer stack recommended by ‘High-speed digital design’ > (Johnson) P220 > From top to bottom: > ------------------------- > signal(horizontal routing) > signal(vertical routing) > gnd > signal (horizontal routing) > signal(vertical routing) > signal (vertical routing) > signal( horizontal routing) > power > signal (horizontal routing) > signal(vertical routing) > ------------------------- > I don’t think it is good especially for a mixed-signal board. For example, > it uses a power plane as a reference, at the same time if I split it into > several mini-planes, that will cause EMI, right? > > 3)I plan to make my board as a six-layer one, what is best layer-stack you > think? (In my board, there are 3 volt levels: 3.3V for > FPGA,ADV7181,ADV7123;1.8V for ADV7181; 1.2V for FPGA ) > Could [Top--gnd(integral :))--signal--power--gnd(integral :))--bottom] be > the best? You can get two kinds of crosstalk for signals that are within several dielectric thicknesses of each other: forward and reverse crosstalk. The signal integrity tools are wonderful if you have signals where crosstalk is critical our edges outrageous. If the signals are further apart or the edge rates are low, the crosstalk tends to be minimal. PC board manufacture might affect your choice. I understand it's less desirable to have the ground/power planes asymmetric for handling the board-stack as it's pieced together. Talk to your PC fab house. I'm a fan of good grounds but it's hard to avoid overkill. We had a board that was S-G-P-G-S-S-G-P-G-S. The board only sported four signal layers but they were all referenced to ground! I think this was a prototype stackup that made it into production. If I had my own board to do again at my own risk - no other engineers to review the work - I think I'd go with S-G-S-S-G-S but use power pours (with appropriate filtering) in one signal plane and/or one ground plane only in an island around the chip. With bypassing that's appropriate to a ferrite-isolated island, the power-surge jostling of the ground plane is reduced. The signals are all referenced to ground outside the island with appropriate decoupling at the edge of the chip to keep return current paths short, keeping EMI in check. With power pours, the power can be routed on signal layers through lines sized to carry the raw current without a significant voltage drop or temperature rise. The ferrite isolation keeps these power distribution routes from causing problems with nearby signals by reducing the edge rates for surges that get past local decoupling. You may consider beefing up your grounding scheme only in the region where the analog circuitry is critical and go with a more standard S-G-S-S-P-S stackup where the power and ground planes are well bypassed, especially where signals switch layers (for that "ever popular" return current path thing). I like to keep my signal impedances to a specific design level, balancing the dielectric thicknesses to give me the impedances based on my routing rules for internal/external signals. There are so many ways to come up with an acceptable board that I wouldn't lose sleep over finding the "right" stackup. Just make sure your PC board fab thinks the stackup sounds good. - John_HArticle: 122160
Why were you looking at the non-volatile chips of Xlinx? Only because of the on chip flash - or is it because you want to replace an older assp? If so, and you are not restricted to 'Xilinx only' than you can have a look at Lattice XP, XP2 and MachXO. All these are non-volatile - have on board config flash and available in small 8x8 csBGA packages. The latter being the smallest LUT count. Hope this helps, Luc On Fri, 20 Jul 2007 14:57:32 -0000, John Oyler <john.m.oyler@gmail.com> wrote: >I've been looking at the Spartan 3an's mostly, because of the built-in >config flash, but I've yet to settle on them as the preferred chip for >my project. As it turns out, another chip I'm wanting to use is bga, >and since it's unavoidable I've been looking for the same in the fpga. >It would be really nice if there was a bga chip at or around 10-12mm >in size... but I can't seem to find any such. Only the larger gate >count fpga's are bga package, and most of those seem to come in at >around 20mm in size... which means the board I'm working on would be >wider than the dip chip that it's replacing. Something I'm willing to >live with, but certainly more challenging because the chip is in >several machines that each have their own board layout. I might have 2 >inches of space below the chip on one machine, but can't even have a >quarter inch worth of overhang in that same place on another. > >Now, I do realize that an especially small package chip means that I >won't be able to have a high gate count or as many io pins, but I >don't believe my project even needs that. > >So, does anyone have any suggestions? I'm not married to Xilinx, an >Altera or Lattice chip that made things easier here would really rock. > > >Slight topic change: What do you guys think of this board for a >learner's first fpga? > >http://www.digilentinc.com/Products/Detail.cfm?Prod=BASYS&Nav1=Products&Nav2=Programmable > >It's well within my price range, I could afford more, and I don't want >to get something so weak it can't even teach me anything. Is 100 >kgates enough to implement an 8bit cpu? Would I be able to implement >an ethernet core or usb with it? Etc. Just want an opinion. > > >Thanks, >John O.Article: 122161
I use Xilinx PCSPMA GTP IP core to connect SFP interface. But how to connect the signal_detect signal of PCSPMA GTP core to indicate presence of optical input?Article: 122162
"John_H" <newsgroup@johnhandwork.com> wrote in message news:PLgoi.267$7V6.134@trnddc03... ...a lot of excellent advice! No much to add from me, the SGSSGS stack up suggested by John would be my favourite also. BTW., I like to include ground vias next to where signals via from layer 1 to layer 6. (In fact whenever the signal's reference plane changes.) This reduces the loop area for the current travelling in the trace. Remember, the signal in this case will go from being referred to one ground plane to being referred to the other. The ground via makes sure there is a current path where this swap happens. Thinking as if single ended signals are actually differential signals, one side of which just happens to be ground helps make this clearer. Here's an article I found online that explains this. http://www.ce-mag.com/archive/02/Spring/kimmel.html As John says, there are many ways to make an acceptable board. The advantage of the SGSSGS stack up is that it's very unlikely to have problems. It may not be optimal depending on your system requirements, but it'll work well, especially with a liberal sprinkling of ground vias. John Larkin (who regularly posts here) has a different approach to his boards with more power planes that, as he's fond of reminding us ;-), work very well for his products. "We use one ground plane, between the power planes, maybe 3=power, 4=gnd, 5=power." My thoughts are that if there are splits in any of the power planes, you have to be careful with signal routing. John L is clearly expert so can avoid traps that somebody at the start of their design career might fall into. The SGSSGS setup allows you to route with gay abandon! Cheers, Syms.Article: 122163
Very interesting thread ;) I'm trying to apply all this data to my design. OK, so I have a FPGA module which will be connected to a motherboard via a connector, which also provides the power supply. It's a Hirose 100 pin connector ; I dedicate 25 pins to ground so both boards will have good ground plane continuity. However, the +3.3V power supply also comes through this connector, so I made a little drawing of the two options, with or without choke on the main power supply. It appears I need to put a choke if I don't want my power supply to act as a return path ; this would be problematic since the power supply has much less pins on the connector than ground. http://home.peufeu.com/nik/fpga/board_v04/choke.png So, I put a choke. The end result is this : http://home.peufeu.com/nik/fpga/board_v04/layout.png I use 4 layers : Signal Ground Power Signal. Ground plane is over the entire board (except RJ45 and mounting holes), and is not shown. Power planes are in yellow : the largest one is the +3.3V ; the small one (bottom left) is the supply for the analog part of the LAN chip. Anyway, I tried to contour the power plane so that the decoupling caps between GND and +3.3V are on the edge of the plane, so signals exiting the module will have their return path either through GND plane or through the decap. I put a choke to block off the VCC that comes through the connector from becoming a return path. How does it look ? I'd like this thing to radiate as little EMI as I can manage...Article: 122164
In article <f7ik0f$ft$1@aioe.org>, Symon <symon_brewer@hotmail.com> wrote: > http://www.amazon.com/Aveda-Hand-Relief-4-2-oz/dp/B000FAMUIU > I went into an Aveda store somewhere in silicon valley once and demanded > this product. I half expected to be arrested, but apparently the UK meaning > hasn't travelled the Atlantic yet. My mates back in the UK were delighted to > have gifts of 'Hand Relief' for xmas! I'm glad your story had a happy ending. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 122165
Dear Using BRAM (for example, RAMB16_S36_S36), I do need to implement "synchronous WRITE, asynchronous READ" FIFO. >From the following previous discussion: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/e184eada249cb9d4/687ae3ae38695b67?lnk=gst&q=Synchronous+write+Asynchronous+read&rnum=1&hl=en#687ae3ae38695b67 I still do not get to solution. My FIFO module has following I/O. ------------------------------ clk : in std_logic; -- common clock for "read/write" rst : in std_logic; -- reset wr_data : in std_logic_vector(32 downto 0); -- write 'data' write_in : in std_logic; -- want to 'write' read_in : in std_logic; -- want to 'read' rd_data : out std_logic_vector(32 downto 0); -- read 'data' write_out : out std_logic; -- data 'written' (or can be written) read_out : out std_logic; -- data 'read' (or can be read) -------------------------------- In my implementation, always one cycle for 'write' and one cycle for 'read' occur !! By the way, "Synchronous write, asynchronous read" was possible, when we use "look-up tables" (or slices). I wish to use BRAM to have such a behavior. It seems that some people have this experience. Please give me more hints.Article: 122166
PFC wrote: > > Very interesting thread ;) > > I'm trying to apply all this data to my design. > OK, so I have a FPGA module which will be connected to a motherboard > via a connector, which also provides the power supply. > It's a Hirose 100 pin connector ; I dedicate 25 pins to ground so > both boards will have good ground plane continuity. > > However, the +3.3V power supply also comes through this connector, > so I made a little drawing of the two options, with or without choke on > the main power supply. It appears I need to put a choke if I don't want > my power supply to act as a return path ; this would be problematic > since the power supply has much less pins on the connector than ground. > > http://home.peufeu.com/nik/fpga/board_v04/choke.png > > So, I put a choke. > > The end result is this : > > http://home.peufeu.com/nik/fpga/board_v04/layout.png > > I use 4 layers : Signal Ground Power Signal. > Ground plane is over the entire board (except RJ45 and mounting > holes), and is not shown. > Power planes are in yellow : the largest one is the +3.3V ; the > small one (bottom left) is the supply for the analog part of the LAN > chip. Anyway, I tried to contour the power plane so that the decoupling > caps between GND and +3.3V are on the edge of the plane, so signals > exiting the module will have their return path either through GND plane > or through the decap. I put a choke to block off the VCC that comes > through the connector from becoming a return path. > > How does it look ? I'd like this thing to radiate as little EMI as I > can manage... The drawing shows chokes on both sides of the connector. Only one choke (or simple ferrite) should be needed. I'm not sure where the signals are on your board relative to the power pour and ground layer. When vias swap your signal between signal layers, your EMI will be affected by the distance to the closest capacitors, through the cap to the ground plane, and back to your signal. The closer the caps are, the better. If your signals are referenced to the far ground plane then pass over the power pour, the reference to ground is lost and the return current path needs to find a capacitor path (including very minor power-to-ground plane capacitance) between ground and the new power reference. If any of those signals are pristine analog signals, there will be crosstalk with other signals through the shared current path through the decoupling. It's hard to tell what you're doing with the regulated supply as well. It looks like you have plenty of capacitors, but you need to make sure that the overall capacitance will stand up to your largest current step over the frequency range blocked by the choke. If you have circuits with rather steady draw, capacitors aren't much of an issue; if you slew amps at one clock edge, the situation is very different. Only you can know what your power levels may do. It's a small enough board (small enough return paths) that EMI probably wouldn't be a major concern even with any reference crossings. The bigger issue may be if you have the need for some pristine analog signals that must be kept free of crosstalk. It looks like it was a fun to do. Are you hand assembling this? If not, you may want to reconsider those few passive components that are at an angle. If you're hand soldering it, who cares? Also - beware of vias that might be awfully close to the metal shield of your PULSEJACK since you could inadvertently short the case to an unexpected plane or signal. - John_HArticle: 122167
On Jul 21, 11:09 am, Pasacco <pasa...@gmail.com> wrote: > Dear > > Using BRAM (for example, RAMB16_S36_S36), I do need to implement > "synchronous WRITE, asynchronous READ" FIFO. > > >From the following previous discussion: > > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/e1... > > I still do not get to solution. > > My FIFO module has following I/O. > ------------------------------ > clk : in std_logic; -- common clock for "read/write" > rst : in std_logic; -- reset > wr_data : in std_logic_vector(32 downto 0); -- write 'data' > write_in : in std_logic; -- want to 'write' > read_in : in std_logic; -- want to 'read' > rd_data : out std_logic_vector(32 downto 0); -- read 'data' > write_out : out std_logic; -- data 'written' (or can be written) > read_out : out std_logic; -- data 'read' (or can be read) > -------------------------------- > > In my implementation, always one cycle for 'write' and one cycle for > 'read' occur !! > > By the way, "Synchronous write, asynchronous read" was possible, when > we use "look-up tables" (or slices). > I wish to use BRAM to have such a behavior. > It seems that some people have this experience. > Please give me more hints. Well, you quoted the previous discussion... The BlockRAM absolutely needs a clock edge to read data. No ifs or buts. If you have a read clock, or a common write/read clock, you have no problem, just use the Enable inputs to control the operation. It also helps to read the data sheet and the user guide... Peter AlfkeArticle: 122168
>> http://home.peufeu.com/nik/fpga/board_v04/choke.png > > The drawing shows chokes on both sides of the connector. Only one choke > (or simple ferrite) should be needed. Yes, actually the drawing shows an IC on the "motherboard" and an IC on the module, both being powered from the same power supply, and both IC's having their own choke (a bit extreme, it was for the example). > I'm not sure where the signals are on your board relative to the power > pour and ground layer. Like this : - signal (top layer) - prepreg - ground plane - FR4 core - power plane - prepreg - signal (bottom layer) Actually, I don't think there is any other way with 4 layers considering components have to be put on the board (!) and I'll use no BGA here, the signal layers have to be outside... > When vias swap your signal between signal layers, your EMI will be > affected by the distance to the closest capacitors, through the cap to > the ground plane, and back to your signal. The closer the caps are, the > better. I may then add a decoupling cap in the middle of my cluster of vias where the bus changes layers, to reduce the loops. > If your signals are referenced to the far ground plane then pass over > the power pour, the reference to ground is lost and the return current > path needs to find a capacitor path (including very minor > power-to-ground plane capacitance) between ground and the new power > reference. If any of those signals are pristine analog signals, No analog in this board (it will be on the other side of the connector) except the ethernet chip... I am just concerned about this board emitting enough crap that it may affect the analog circuits on the "mainboard"... > there will be crosstalk with other signals through the shared current > path through the decoupling. > > It's hard to tell what you're doing with the regulated supply as well. > It looks like you have plenty of capacitors, but you need to make sure > that the overall capacitance will stand up to your largest current step > over the frequency range blocked by the choke. I'll rethink this one. > If you have circuits with rather steady draw, capacitors aren't much of > an issue; if you slew amps at one clock edge, the situation is very > different. Only you can know what your power levels may do. > > It's a small enough board (small enough return paths) that EMI probably > wouldn't be a major concern even with any reference crossings. I also tried to keep the signal paths as short as possible, mostly between SDRAM, FPGA and MAC chip. The SDRAM will probably run at 50 MHz which shouldn't pose problems. > It looks like it was a fun to do. Yes !! > Are you hand assembling this? Yeah, I'll build one or two for starters, so I can rotate my resistors ;) > If not, you may want to reconsider those few passive components that > are at an angle. If you're hand soldering it, who cares? > > Also - beware of vias that might be awfully close to the metal shield of > your PULSEJACK since you could inadvertently short the case to an > unexpected plane or signal. Good one !!! I'll correct this ! Thanks !Article: 122169
To check incoming clock at lower freq. rate, the best way would be to bring it out on a FPGA I/O pin and probe it with a scope (assuming you have some test pins available). Otherwise, if you have access to the differential clock traces on the board, then probe the differential input clock. Scope would show if you have a clean clock with low jitter. -VikramArticle: 122170
I have been trying to write a watchdog interrupt handler and have not
been successful in coming up with a working code. I would like to use
watch-dog timer on OPB bus of microblaze system to count the number of
clock cycle each phase of your software code takes.
A specific application code running on microblaze and I would like to
quantify my code by finding out the number of clock cycles spent
executing it.
I would appreciate to you if you can send me an example of software
code using the watchdog timer to measure the number of clock cycles
spent for performing a certain section of code.
Regards,
Aziz
p.s. I have been figured out that the code might look like the
following. but I am struggling to find out the right SYNTAX to
execute it
//using base system builder, the WDT has been configured in enable-
once mode.
unsigned rollover_count;
wdt_interrupt_handler{
clear the MSB bit of the register;
rollover_count++;
}
int main(){
int start;
int end;
rollover_count = 0;
read the time base register;
software code;
read the time base register again;
//assuming that the watch dog counter has a 30 bit counter
total_number_of_clock_cycles_spent = (rollover_count)*(2^30) + (end-
start);
return 0;
}//end of main
Article: 122171Hi, I updated the GTKWave for Win32 port I am maintaining. It's at 3.0.29 now. http://www.dspia.com/gtkwave.htmlArticle: 122172
Dear,
I'd like to learn programming FPGAs for HPC applications. I am,
however, a newbie in this field. I do have a software engineering
background.
Does anyone want to be so kind to suggest a development platform to
start with?
What do you think of solutions like:
- http://www.drccomputer.com/drc/products.html
- http://www.xtremedatainc.com/
- http://www.mitrionics.com/
Thanks,
Bart
Article: 122173Well, I used wrong term "asynchronous read". Actually I have read clock. So, what I need is to implement 'prefetch' first word, before read pulse and synchronous 'read' for consecutive words.Article: 122174
On Jul 22, 6:24 am, Pasacco <pasa...@gmail.com> wrote: > Well, I used wrong term "asynchronous read". > Actually I have read clock. > So, what I need is to implement > > 'prefetch' first word, before read pulse > and > synchronous 'read' for consecutive words. So you're looking for a fall through mode? http://groups.google.com/group/comp.arch.fpga/search?group=comp.arch.fpga&q=fall+through
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