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
In the cyclone devices, How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS or DSP blocks.I am using for LE_FF timing and LVTTl standards.I am not using fast corner analysis.I have to fix up hold violations of no 96 I referred cyclone II device data sheet DC and timing characteristics page 106-135.How to set this paramters.There are no examples for this.Can you provide examples for this.If you provide examples for this in assignment editor ,it will be useful for users kumarArticle: 112351
In the cyclone devices, How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS or DSP blocks.I am using for LE_FF timing and LVTTL standards.I am not using fast corner analysis.I have to fix up hold violations of no 96 I referred cyclone II device data sheet DC and timing characteristics page 106-135.How to set this paramters.There are no examples for this.Can you provide examples for this.If you provide examples for this in assignment editor ,it will be useful for users kumarArticle: 112352
Mind posting a sample you used to access the LEDs or switches? On Oct 26, 5:17 pm, Neil Steiner <neil.steiner@vt.edu> wrote: > Ah, I see. The functionality is supported through ioctl() and struct > ibm_gpio_ioctl_data. A little strange, but okay.Article: 112353
fl wrote: > Info: Selected device EP1C12Q240C6 for design "filtref" > Info: Fitter is performing a Standard Fit compilation using maximum > Fitter effort to optimize design performance > Error: Can't place node "clk" -- illegal location assignment PIN_G1 > Error: Can't fit design in device > Error: Quartus II Fitter was unsuccessful. 2 errors, 0 warnings Well I haven't used Altera for a while, but it looks like an EP1C12Q240C6 is a 240 pin PQFP and doesn't have a pin G1. Either you need to change the part or you need to change the pin. Alan NishiokaArticle: 112354
Kolja Sulimma wrote: >> >> >>Let me guess an Acam part? We did have some experience with Acam. > > Could also be from MSC in Darmstadt, but as he has a CERN email address > I am sure he is using the HPTDC developed at CERN. The HPTDC homepage > has vanished, but we use it in one of our TDC boards: > http://cronologic.de/products/time_measurement/hptdc/ Exactly! > > >>>Can anyone say something about this? Does it sound reasonable? > > > Slow input slopes create crosstalk in the HPTDC. Therefore it makes > sense to have extremely fast LVDS input buffers in front of the chip > anyway. If you use buffers with enable (or an AND-gate) you can control > that from the FPGA to mask the signals. No need to route the signals > through the FPGA. The big problem is that, as in all time measurements in physics, there will be a "trigger" configuration which will allow the time conversion. This will need to be implemented in an FPGA, because different "trigger" configurations will be needed. Because of that all the signals will come from an FPGA or from a combinational logic anyway. After that we can use all the drivers we want to minimize later sigma increase on the measurement, but still the source will jitter. My initial question was about the jitter increase due to the presence of a clock signal running through the FPGA, not that this clock source will have anything logically related to the output signals to be measured. We are getting signals from PMTs (PhotoMultiplierTubes), so they are single ended signals and there is no such a gain to convert them in LVDS signal and then convert them again to TTL inside the HPTDC. All these intermediate stages will drammatically add their sigma worsening the overall measurement. I saw your PCI board with the HPTDC installed, wich type of LVDS drivers did you inserted in between NIM and HPTDC? We are using a configuration such that to use the TTL port of the HPTDC and a fast comparator with a configurable threshold and an amplitude-time correction algorithm to correct the time-walk errors on different amplitude signals. Regards Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112355
http://www.freemodelfoundry.com/ www.hynix.com http://www.qimonda.com/ Bye Helmut Vangelis wrote: > Does anynone know where can I find VHDL models for DDR modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR model will do the job.Article: 112356
Austin Lesea wrote: > Al, > > Passing a signal through an FPGA, and then expecting to resolve 25 ps is > not a good idea. > > The FPGA may add as much as thousands (yes thousands) of picoseconds of > jitter: it all depends on the number of clocks running, their > frequencies, if they are asynchronous or not, the number of CLB flip > flops toggling (internal simultaneous switching), and the number of > external IOs switching (SSO noise). > > Additionally, since jitter is caused by anything being less than > perfect, this also includes the power distribution network, and the > signal integrity of all the traces (rise times, fall times, reflections, > etc.). > > The jitter floor for a FPGA that is doing nothing at all (signal in,, > signal out) is probably around 35 picoseconds peak to peak. A > completely synchronous design with everything done perfectly will > probably come in at around 150 picoseconds, peak to peak jitter. I'm sorry Austin I didn't get your point at all. I'm not talking about delay (and I think you got this), so how can a signal-in signal-out add 35 picoseconds jitter? You said peak to peak but maybe I didn't explain what jitter is to me: Given a fixed source that we know is stable in time (no matter how) and a signal produced from this source with some combinational logic and delay (like cables and I/O delay), the output distribution will be gaussian if we have a white-noise environment. The jitter I'm talking about will be (basically) the sigma of this distribution. > > An ASIC is probably the last thing I would choose to do jitter > measurement. As I have said, you do anything wrong (at all), and you > will fail. Is that mean that all these ASIC TDC you find around are just junk? They are ASIC, nothing more, just dedicated device to measure Time. There are basically two types of TDC AFAIK: 1) time expantion based: which is an amplitude measurement that is proportional to a time measurement 2) Calibrated standard-cell delay to shift in the value. In the latest the measurement is quite more precise because typically the time-expansion circuitry is an analogue circuit which has a much worse stability then an integrated standard-cell delay. Sorry I didn't understand this as well, what do you mean by > Jitter is the result of converting amplitude variations into > phase variations .. > > To resolve the time you desire, it requires very high speed design > (PECL), and virtually perfect power distribution, and signal integrity. I do agree power distribution has a major effect on the time measurement, but that's why "calibration procedures" have been invented. You basically subtract (is a deconvolution operation to be precise, even though many physicists deny it) the environment noise from the meauserements. This operation is quite complicated because you need to insure that power consumption doesn't vary so that will affect the measurement. > > I hope others here on the newsgroup will provide you with some better > guidance, as all I have done is explained the problems. Explaining problems is a great guidance, but I think I misused the word jitter and maybe I failed explaining my problem. > > Austin > > > > Al wrote: > >>Hi to everyone, >>I'm developing some electronics to make a time measurement with a >>resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving >>the signals to the ASIC through an FPGA. >>The way is very simple, basically I have some signals coming to my fpga >>which I will mask with some combinatorial logic and a configurable >>register so that I can allow some measurements or some others. The >>output of this "masking" will go to the ASIC. >>They assert (and here is the question) that a clocked device as an FPGA >>may add some jitter to the signals due to the substrate current >>overload (for the presence of the clock) that will lead to some 15 ps >>jitter over the signals. I don't know how they could resolve this value >>but I'm assuming they were telling the truth about numbers (at least, >>while I have some doubts about explanation of those numbers). >>Can anyone say something about this? Does it sound reasonable? >> >>Al >> -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112357
nospam wrote: > > Let me guess an Acam part? > I have some experience with Acam product, but eventually we are using HPTDC developped at CERN. > > If you are trying to measure signals with 25ps resolution you have to be > extremely careful with *everything* those signals pass through. > > Passing them through as little as possible would be a good starting > approach. I know, but unfortunately you need to pass through some logic to be able to mask some signals and to be able to recognize the correct logic combination you want to measure (i.e. the trigger configuration). To do that either you use discrete components (a lot of them if you are talking about hundreds of signals) or you use an FPGA to select the correct combination. After all that, depending on how your system is done, you need to distribute these signals to different boards, placed in different places, so you will need a TTL-LVDS and an LVDS-TTL conversion (maybe you can get rid of the second conversion if you are using LVDS input on your TDC). These pass-through are necessary to the logic of the measurement. Of course all this logic is a combinational logic and has nothing to do with clock, but is it true that this logic cell delay will be changed by the presence of the clock inside the chip? even if this clock will not be connected to the combinational cell? Thanks for your warning Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112358
radarman wrote: > This is all well and good, but even with smart compilation turned on, > things don't work quite as well as they should. I'm designing my own > CPU core, so I'm not using NIOS, but I still need to be able to update > BRAM's with new program code. > > I've already worked around (sort of) the fact that for some reason, > Quartus won't properly update a BRAM from a .hex file. (.hex files work > fine for compilation, but not a mif/hex update. So, I bring my .hex > file into Quartus, and save it as a .mif file. This is annoying, since > I can no longer automate the whole build process. At some point, when I > get irritated enough, I'll write a program that converts hex to mif > correctly, but I haven't had the time for much extra programming > lately. > > However, the MORE irritating problem I've run into is that if I repeat > the mif/hex update process a second time, changing only the .mif file, > Quartus launches into a full recompile anyway. This is a bit > frustrating, since the "hardware" is stable at this point. I just need > to test software. Perhaps I've missed something, but I've yet to find a > way to avoid the full recompile on the second update. > > Maybe this works correctly in the NIOS flow, but I don't have that tool > available. I did try the NIOS eval, though, and I didn't see any new > tools in it that looked like they would solve my problem. What version of Quartus? Service pack? Critical update? Sounds like you were hit by that: http://www.altera.com/support/kdb/solutions/rd03062006_72.html BTW, if you want to minimize troubles please store you .hex files in Quartus project directory.Article: 112359
Ray Andraka wrote: > Jon Elson wrote: > > > Some people have way too much time on their hands! I want to use the transistor board set as part of a possible computer kit / electronics trainer. I have just completed the Altair Kit reproduction that I've been working on for 9 months as a hobby. If I can stick with it and get that done on my time off, I think a transistor 8080 would be easy. ;) http://www.altairkit.com http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250052265051 Any way, I guess I would be happy if the transistor computer were instruction set compatible AND timing compatible. I really am not concerned about how the computer is constructed at the transistor level, but I want the status signals the same and the instruction set cycle count to be the same. If a program depends on a software delay loop, I would want it to be equal. Maybe I'm trying to attempt too much. I think my best bet is to reasearch the 9080 emulator by AMD and duplicate that. Its possible I could rewrite the microcode to include status bit states. Who knows... With this new information, does anyone see a different easier path? Or am I still just plain crazy? :) I won't be making any transistor 8080s until I'm out from under all the investments in the Altair project! GrantArticle: 112360
PeteS wrote: > > For time measurements of this order, you'll need a *very* stable and low > jitter clock source. I would suggest a PECL differential, or even > perhaps a truly stabilised (thermally) oscillator. For any type of measurement of this order I will defenetely not use any clock source for different reasons: 1) power consumption, it is not reasonable to have a 20 GHz clock to measure 25 ps bin resolution, there are several other solutions which are quite less expensive in terms of power dissipation 2) low jitter clock source are very expensive and very difficult to verify. How would you trust your low jitter clock? from datasheet? and what if your clock has a bigger jitter because has a defect? BTW thermal problems are not that issue, as long as you have the cure to measure temperature along your time measurement. With this information you can correct your values with a correct calibration procedure. > Keep in mind that you will have jitter introduced for: > > 1. Clock / signal input indeterminacy. At some point, you have to > capture your signal. The FF will switch somewhere in the indeterminate > region. The slower your input source, the worse this is. You can't > expect a FF to switch at the same level two consecutive times either, > although usually adjacent clocks will switch at a close level. > Estimation of that jitter depends on the technology you are using. > > 2. Oscillator jitter. There will always be jitter on an oscillator. It > might be low, but you can't get rid of it. > > 3. Possible metastability. This afflicts all FFs, and although it can be > worked around, you should be aware of it. (It's not a high level issue, > but it does exist - there was a thread on it recently) All these warnings are related to a synchronous logic approach, which is not what I will use, and which is not desirable at all in any time measurement to me. > > 4. PCB routing. All PCBs will exhibit deterministic jitter (which can be > calculated). This will be made worse if you have vias on highspeed nets > (which can be alleviated somewhat with differential techniques I won't > go into here). Unless you are using waveguide or optical techniques (and > even they suffer from jitter too) you'll have a low pass filter > introducing jitter. Then there's track adjacency, impulse response of > the power etc. PCB routing is not a major issue because with a good calibration procedure you can live with it. > > I have seen a single via add 50ps of deterministic jitter on fast > signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB > material you are using or intend to use, but keep this in mind. Could you better explain what do you really mean by deterministic jitter in this case? > > Another issue of importance is which form of jitter is your biggest > issue: Cycle to cycle? rms? peak to peak? long term (sometimes known as > frequency drift) > > Some food for thought. The more food we have the better results we get! > > Cheers > > PeteS -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112361
"Al" <alessandro.basili@cern.ch> wrote in message news:ejugts$gj9$1@cernne03.cern.ch... > > Could you better explain what do you really mean by deterministic jitter > in this case? > C'mon Al, CERN invented the WWW! :-) The first hit from Google explains it all! I think the problem with FPGAs is that the leakage and thermal noise together with the internal single ended signals all conspire to add jitter to your signal. It doesn't help that the output rise time is, I guess, at best 500ps depending on what you're driving. You might like to consider a crosspoint switch solution. I think Mindspeed and Vitesse might have something you could use. e.g. http://www.commsdesign.com/new_products/showArticle.jhtml?articleID=16503342 These parts are used in SONET (SDH where you are!) systems which have very tight jitter specs. Right up your street! Good luck, Syms.Article: 112362
lecroy7200@chek.com wrote: > I can't seem to find a document that calls out the XY locations for the > IDELAYCTRL. Where is this information found? Try Jim Wu's free ADEPT-Tool: http://home.comcast.net/~jimwu88/tools/adept/ There's a view where you can see the IDELAYCTRL-locations and the pins that are controlled by this specific IDELAYCTRL. This tools is really handy for other stuff as well (like seeing which IOs belong to which IO-Clock-Region and regional clock and things like that), and doesn't cost anything. cu, SeanArticle: 112363
Hi, In the ug230.pdf (user guide for Spartan-3E Starter Kit) page.76, figure 10-4 the timing caracteristics of the SPI interface of the LTC6912-1 pre-amplifier are the following: - SPI_SCK LOW=50ns - SPI_SCK HIGH=50ns - AMP_CS LOW to SPI_SCK=30ns - SPI_MOSI VALID to SPI_SCK SETUP=30ns - AMP_DOUT OUTPUT DELAY=85ns When I look at the schematics of the ADC/DAC part of the board (ug230.pdf, p.151) I see than V+=3.3V and V-=0V for the pre-amplifier. I took a look at the LTC6912-1 datasheet (got from the link on page 79 in ug230.pdf) and on page 11 in the section "SERIAL INTERFACE SPECIFICATION" I see that for V+=2.7V~4.5V the following timing parameters should be used: - CLK (== SPI_SCK) LOW=100ns - CLK (== SPI_SCK) HIGH=100ns - CS/LD (==AMP_CS) LOW to CLK (== SPI_SCK)=30ns - DIN VALID to CLK (== SPI_SCK) SETUP=60ns - DOUT (== AMP_DOUT) OUTPUT DELAY=125ns Can anyone (preferably from Xilinx) explain me if it's some miscomprehension from me or if there is some error in the documentation and if so than please tell me which parameters should I take into consideration. Best Regards Mehdi TAILEBArticle: 112364
Symon wrote: > > C'mon Al, CERN invented the WWW! :-) The first hit from Google explains it > all! > So what? didn't get it. > I think the problem with FPGAs is that the leakage and thermal noise > together with the internal single ended signals all conspire to add jitter > to your signal. It doesn't help that the output rise time is, I guess, at > best 500ps depending on what you're driving. Rise time doesn't involve jitter, as long as it is fixed. Maybe we should agree on what does jitter mean. > You might like to consider a crosspoint switch solution. I think Mindspeed > and Vitesse might have something you could use. Maybe this is a good alternative, which maight have been used. Unfortunately the power consumption is something like 2.5 Watts for a 500 MHz BW chip. Consider that our DSP boards which holds 2 FPGAs, a DSP, a Ram chip and a Flash chip and run with 4 simultaneous link at 100 Mbits each will reach up to 1.2 Watts only. Unfortunately power budget is mandatory in our case, moreover we need have 5 channels per board and 20 boards, so it will soon reach a power budget that is not really acceptable. Another main problem with this stuff is to find out reliability in a radiation environment, how will they behave? how long will they last? Maybe someone have some experience and did some rad-hard test with these type of chips. Thanks for the suggetion anyway! Cheers Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112365
"Al" <alessandro.basili@cern.ch> wrote in message news:ejul8l$iv7$1@cernne03.cern.ch... > Symon wrote: >> >> C'mon Al, CERN invented the WWW! :-) The first hit from Google explains >> it all! >> > So what? didn't get it. > Well, actually you mightn't need to understand it; as Kolja posted, if your application is one-shot, so there's no ISI which would produce deterministic jitter in your system. Seriously, there's plenty of stuff online that explains the differences and sources between the different types of jitter. > > Rise time doesn't involve jitter, as long as it is fixed. OK, think about the receive end, as the signal rises through the switching threshold. Voltage noise adds more time jitter to a slow rising signal than to a fast rising one. That's my point and is why rise time is important. > > Maybe we should agree on what does jitter mean. > Google gives:- The deviation from the ideal timing of an event. HTH, Syms.Article: 112366
Download the MIG tool from xilnx to generate the DDR SDRAM controller .. subin Vangelis wrote: > Does anynone know where can I find VHDL models for DDR-I SDRAM modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR-I SDRAM model will do the job.Article: 112367
Symon wrote: > Well, actually you mightn't need to understand it; as Kolja posted, if your > application is one-shot, so there's no ISI which would produce deterministic > jitter in your system. Seriously, there's plenty of stuff online that > explains the differences and sources between the different types of jitter. > >>Rise time doesn't involve jitter, as long as it is fixed. > > OK, think about the receive end, as the signal rises through the switching > threshold. Voltage noise adds more time jitter to a slow rising signal than > to a fast rising one. That's my point and is why rise time is important. > Thinking about receiving end, what is easier to have: a much stable voltage or a faster signal? How much power will you need to have a faster signal? Then if you are worried about voltage noise, then I ensure you that time induced jitter is easily evaluated with the following formula: T-noise = V-noise/rise-time reducing rise-time has the same gain of reducing V-noise. Moreover a faster rise-time can easily come with a variable propagation-delay, just because you moved the critical point on another component, which still has a voltage-reference to be crossed and an input stage to be loaded. > > >>Maybe we should agree on what does jitter mean. >> > > > Google gives:- > The deviation from the ideal timing of an event. > I don't think is quite an explanation, what does "ideal" means? Does it mean with "ideal" components? Still there will be a "jitter" depending on how you produce the signal and depending on how you "sample" the signal, ever heard about digitization noise? What "deviation" means? I hope this deviation will have a distribution, otherwise is not a deviation, but is better to call it delay. If all the components in the measurement chain will have a "deviation from the ideal timing of an event" you can still have an "ideal timing of the event" if all the "deviations" turns out to be delays. The reference you pick this definition from is most likely the same one which says: "Jitter is composed of both deterministic and Gaussian" well, this is much more confusing than other definition. Does deterministic jitter has a distribution? no? so why don't you just call it delay. Still if something _has_ a distribution it _can_ be deterministic the same, have you ever heard about notch filters? Aren't they cutting off a deterministic range of a noise spectra? To my point of you I still believe we are not talking about the same thing. > HTH, Syms. > > -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112368
A correction to my previous post Al wrote: > The reference you pick this definition from is most likely the same one > which says: > "Jitter is composed of both deterministic and Gaussian" > I didn't read the whole document (http://wavecrestcorp.com/technical/VISI_6_Getting_Started_Guides/6understanding.PDF), but still it goes through data and clock receiving matters which are far away this topic (InterSymbol interference, duty cycle distorsion, etc.). Sorry about that Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112369
Grant Stockly wrote: > Ray Andraka wrote: > > Jon Elson wrote: > > > > > > Some people have way too much time on their hands! > > I want to use the transistor board set as part of a possible computer > kit / electronics trainer. I have just completed the Altair Kit > reproduction that I've been working on for 9 months as a hobby. If I > can stick with it and get that done on my time off, I think a > transistor 8080 would be easy. ;) > > http://www.altairkit.com > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250052265051 > > Any way, I guess I would be happy if the transistor computer were > instruction set compatible AND timing compatible. I really am not > concerned about how the computer is constructed at the transistor > level, but I want the status signals the same and the instruction set > cycle count to be the same. If a program depends on a software delay > loop, I would want it to be equal. > > Maybe I'm trying to attempt too much. I think my best bet is to > reasearch the 9080 emulator by AMD and duplicate that. Its possible I > could rewrite the microcode to include status bit states. Who knows... > > With this new information, does anyone see a different easier path? Or > am I still just plain crazy? :) I won't be making any transistor > 8080s until I'm out from under all the investments in the Altair > project! If you are just trying to build a trainer of some sort, wouldn't it be easier to build a simulation that could show all the internal states? It has got to be easier to do a simulation than a construction project from transistors or even from CPLDs.Article: 112370
Al wrote: > Hi to everyone, > I'm developing some electronics to make a time measurement with a > resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving > the signals to the ASIC through an FPGA. > The way is very simple, basically I have some signals coming to my fpga > which I will mask with some combinatorial logic and a configurable > register so that I can allow some measurements or some others. The > output of this "masking" will go to the ASIC. > They assert (and here is the question) that a clocked device as an FPGA > may add some jitter to the signals due to the substrate current > overload (for the presence of the clock) that will lead to some 15 ps > jitter over the signals. I don't know how they could resolve this value > but I'm assuming they were telling the truth about numbers (at least, > while I have some doubts about explanation of those numbers). > Can anyone say something about this? Does it sound reasonable? > > Al If you pass your trigger through the FPGA, your measurement can be off by +/- hundreds of picoseconds from one measurement to the next. Over many measurements your gaussian jitter will be increased by a substantial amount only because of the jitter. Using a complex trigger condition through an FPGA doesn't mean you have to measure the signal coming out of the FPGA. Generate the mask in the FPGA and use it to gate the original (always on) trigger signal the measurement is performed on. You chooses the edge(s) to analyze but through a very clean external gate unaffected by the jitter-laden mask signal coming from the FPGA. If you insist on analyzing the signal leaving the FPGA, please let me know the company you're working for so I can avoid considering your products for any future needs.Article: 112371
"Al" <alessandro.basili@cern.ch> wrote in message news:ejul8l$iv7$1@cernne03.cern.ch... > Symon wrote: > >> You might like to consider a crosspoint switch solution. I think >> Mindspeed and Vitesse might have something you could use. > > Maybe this is a good alternative, which maight have been used. > Unfortunately the power consumption is something like 2.5 Watts for a 500 > MHz BW chip. Consider that our DSP boards which holds 2 FPGAs, a DSP, a > Ram chip and a Flash chip and run with 4 simultaneous link at 100 Mbits > each will reach up to 1.2 Watts only. > Unfortunately power budget is mandatory in our case, moreover we need have > 5 channels per board and 20 boards, so it will soon reach a power budget > that is not really acceptable. > Hi Al, Well, after thinking about your requirements, I guess the best solution to you is to switch the signals with PIN diodes. Like this:- http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php The diode's resistance when it's on is of the order of an ohm or two, so they're very low noise, much better than GaAs fets. (My microwave engineer buddy has a big downer on GaAs switches, they blow up too easily and they're more noisy.) You can probably get away with connecting a whole bunch of PIN diode switches together as you're only looking for a one shot type deal, so reflections aren't too big a problem. As only one diode will be on at any one time, the others being reverse biased, it'll be the only one using current, so you only need about 5ma or so. I guess PIN diodes are good at radiation, what's to go wrong? HTH, Syms.Article: 112372
Hi, Sorry for the delay in replying, I'm juggling a couple of projects and had to leave this for a few days. Thank you for your excellent advice, I now have a booting kernel -- thanks! > not sure why, but it sounds like the Makefile in the > arch/ppc/platforms/xilinx_ocp directory didn't get regenerated after > you modified xilinx_syms.c Hmmm, I don't understand either but the Makefile was clearly at fault. The Makefile seems to be part of the source tree. A modified makefile should maybe be part of the BSP(?) but it isn't. > you could try making the modification to a virgin copy of the source > tree before running make menuconfig, make dep, etc... the Makefile > should look something like this: I actually did a make distclean then modified the makefile by hand. make dep did not seem to touch the makefile, I gues it uses it(?) I only had one slight issue with the Makefile, I don't have any of the xdmav* targets, should I? > # Makefile for the Xilinx On Chip Peripheral support code > # > > list-multi := xilinx_ocp.o > > # Linux file to EXPORT_SYMBOL all of the Xilinx entries. > export-objs += xilinx_syms.o > xilinx_ocp-objs += xilinx_syms.o > > # The Xilinx OS independent code. > xilinx_ocp-objs += xbasic_types.o xdma_channel.o > xdma_channel_sg.o \ > xdmav3.o xdmav3_intr.o xdmav3_selftest.o > xdmav3_sg.o \ > xipif_v1_23_b.o xpacket_fifo_v2_00_a.o \ > xpacket_fifo_l_v2_00_a.o xversion.o > > obj-$(CONFIG_XILINX_OCP) := xilinx_ocp.o > > xilinx_ocp.o: $(xilinx_ocp-objs) > $(LD) -r -o $@ $(xilinx_ocp-objs) > > include $(TOPDIR)/Rules.make I confess that I had one more issue when building, it appears that the functions XIic_Recv and XIic_Send (from drivers/i2c/xilinx_iic/xiic_l.c) now have one more parameter. I had to modify the calls in arch/ppc/boot/simple/embed_config.c to include this extra parameter which I specified as XIIC_STOP (instructs the I2C driver to release the bus after the transaction). Not sure if this is right (I know nothing about I2C) but it seems to work... ;) Thanks again, and I hope this post is of some use to others out there attempting the same thing, -- PeterArticle: 112373
already5chosen@yahoo.com wrote: > radarman wrote: > > > This is all well and good, but even with smart compilation turned on, > > things don't work quite as well as they should. I'm designing my own > > CPU core, so I'm not using NIOS, but I still need to be able to update > > BRAM's with new program code. > > > > I've already worked around (sort of) the fact that for some reason, > > Quartus won't properly update a BRAM from a .hex file. (.hex files work > > fine for compilation, but not a mif/hex update. So, I bring my .hex > > file into Quartus, and save it as a .mif file. This is annoying, since > > I can no longer automate the whole build process. At some point, when I > > get irritated enough, I'll write a program that converts hex to mif > > correctly, but I haven't had the time for much extra programming > > lately. > > > > However, the MORE irritating problem I've run into is that if I repeat > > the mif/hex update process a second time, changing only the .mif file, > > Quartus launches into a full recompile anyway. This is a bit > > frustrating, since the "hardware" is stable at this point. I just need > > to test software. Perhaps I've missed something, but I've yet to find a > > way to avoid the full recompile on the second update. > > > > Maybe this works correctly in the NIOS flow, but I don't have that tool > > available. I did try the NIOS eval, though, and I didn't see any new > > tools in it that looked like they would solve my problem. > > > What version of Quartus? Service pack? Critical update? > Sounds like you were hit by that: > http://www.altera.com/support/kdb/solutions/rd03062006_72.html > > BTW, if you want to minimize troubles please store you .hex files in > Quartus project directory. I first noticed the problem in 5.1 SP2, but have since updated to 6.0 SP1. I already store the init files in the project folder - it's automatically copied as part of the build scripts. Note, my projects aren't failing (they run properly), I just have to sit through a full recompile every second update. However, this might explain some curious behavior I was seeing before I upgraded to 6.0. My processor would occasionally hang on the first JSR instruction after doing an incremental compilation. I suspected that the memory wasn't workiing correctly, but it never occurred to me that the tool might be at fault. I thougt that perhaps I had set something up incorrectly - since the ROM appeared to be working just fine. (my design has a 16kB instruction ROM, and 32kB data RAM - both megawizard created) That support answer appears to explain what was going on.Article: 112374
Symon wrote: > Hi Al, > Well, after thinking about your requirements, I guess the best solution to > you is to switch the signals with PIN diodes. Like this:- > > http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php > > The diode's resistance when it's on is of the order of an ohm or two, so > they're very low noise, much better than GaAs fets. (My microwave engineer > buddy has a big downer on GaAs switches, they blow up too easily and they're > more noisy.) You can probably get away with connecting a whole bunch of PIN > diode switches together as you're only looking for a one shot type deal, so > reflections aren't too big a problem. As only one diode will be on at any > one time, the others being reverse biased, it'll be the only one using > current, so you only need about 5ma or so. > I guess PIN diodes are good at radiation, what's to go wrong? > HTH, Syms. > > I think that could be a good solution too, maybe next project! Regards Al -- Alessandro Basili CERN, PH/UGC Hardware Designer
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