Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Tue, 07 Feb 2006 09:28:47 -0600, "Karel" <karel@gemidis.be> wrote:
>Hey all,
>
>I was wondering how to write a software reset in C-code for
>the Xilinx Microblaze.
>
>Regards
>
>Karel
>
>
pseudo-code:
disable interrupts
jump to address 0
assembly:
mts MSR,R0
bra R0
REgrads,
Zara
Article: 96701
Peter Alfke wrote:
> I call that dc current. there isn't even any reversal of the current
> direction.
> Isn't that pretty basic?
Well sorta .... it's all about definitions. Reversal is one component
of
the definition of things that are not pure DC current.
http://en.wikipedia.org/wiki/Direct_current
http://www.school-for-champions.com/science/dc.htm
Continuous is the other. The models for steady continuous DC are
different than modeling transient (plused DC) and AC circuits, are they
not? When does a high voltage RF AC waveform with a high DC offset,
become DC? The rapid changes in fields, and interactions of fields,
produces the effects of unbalancing the currents in the ball array do
they not? Very low current, low voltage, steady continuous DC should,
as suggested, not have much of an imbalance at all since the field
strengths will be low.
And, one of the problems about pulsed DC, is that it frequently turns
into AC due to ringing,
aka undershoot.
The fact here is, part of the discussion here is how much the current
distribution is influenced by traditional continuous DC effects, and
how much the distribution is influenced by the transient effects
(pulses), is it not?
Isn't that pretty basic?
Article: 96702fpga_toys@yahoo.com wrote: > Jim Granville wrote: > >>Please do, we can agree there is an effect, my antennae just question >>how much of an effect at DC ?. >> >> You still have to satisfy ohms law, so any push effects that favour >>flow, have to model somehow as mV(uV) generators.... >> To skew Ball DC currents 7/8 or 15/16, frankly sounds implausible, and >>maybe the models there forgot to include resistance balancing effects ? >> [ ie do not believe everything you are 'told' ] > > > The problem is that there may not be ANY DC component. Two issues there: i) This discussion ( with Austin) was explicitly about DC current spread and what splitting effects there may, or may not be, and their values. ii) You have seen the latest FPGA data sheets :) ? I see the 90nm device from lattice, can draw 1.5 AMPS, at 105'C Tj That's just static Icc. Thus, the latest FPGAs are a long way from your classic CMOS... DC current is there, and at not insignificant levels... -jgArticle: 96703
Peter Alfke wrote: > fpga_toys@yahoo.com wrote: > >>The problem is that there may not be ANY DC component. > > > Well, well. It does not take a genius to find out that all current (or > power) consumption ends up as a (pulsating) DC current through the > chip, from Vcc to ground. > Just imagine the transistors as simple switches, and the loads as > capacitors. When driving High, charge (current) flows in from Vcc. When > driving low, that same charge gets dumped into the ground leads. > I call that dc current. there isn't even any reversal of the current > direction. > Isn't that pretty basic? Probably dangerously basic, if you are talking with a novice :) An expert would warn the novice that this basic DC current, actually has many elements : - The average value determines the average voltage, via the IR drop. - The RMS value, determines the heating in the PCB traces - The AC component, superimposed on the DC, is what causes the inductive ringing effects, via V = -LdI/dT, and the skin effects, that further increase the resistance... The AC component also determines the decoupling cap sizes, to prevent local short-term supply sag. -jgArticle: 96704
it should trace through to the clock pin this allows better us in the FPGA fabric, we have applied this to our development boards so that the PCI clock can be used as the system clock if the user so wishes REGARDS IAN Enterpoint Ltd: Home of the Low-Cost development board RAGGEDSTONE1 Website: www.enterpoint.co.uk "eehinjor" <eehinjor@163.com> wrote in message news:1139408642.434006.277270@g43g2000cwa.googlegroups.com... > Thanks all. >>From the datasheet of cyclone,it is compatible with pci-5v by diode and > risistors. > > Can somebody help me to solve the first question? >Article: 96705
HI, Leow Yuan Yeow wrote: > Thanks for all your patience! I have never used the command line before, and > the gui seems to only allow a project to have files of the same type: vhdl > source files, schematic, edif, or ngc/ngo. > Is this what I should be doing? > 1. compile vhdl file into ngc file >> say myngc.ngc > 2, "nbdbuild myedif.edf myngc.ngc" to combine the edif file and the ngc > file into a single .ngd file > 3. use xst on the ngd file? > > I have looked at the XST manual for command line...but it looks like greek > to me. Am I supposed to learn how to do it my trial and error and figure it > out myself here or is there any some better tutorial out there? > Thanks! I would suggest that you use the ISE GUI and its workflow. /michaelArticle: 96706
Pardon me, but I don't understand your question, are you saying its impossible? I was trying to make a edif file from my vhdl file, and synthesize it with Xilinx together with another external edif file which uses my vhdl component. I have tried to get Synplify and LeonardoSpectrum evaluation version which reportedly can change vhdl to edif, but the trial license is taking so long to arrive and I'm running out of time. YY "Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message news:44ueg2F423kvU1@individual.net... > HI, > > Leow Yuan Yeow wrote: >> Hi, may I know whether there is any free program that is able to convert >> a vhdl file to a .edf file? I am unable to find such options in the >> Xilinx ISE Navigator. I have tried using the Xilinx ngc2edif convertor >> but when I tried to generate a bit file from the edf file its says: >> >> ERROR:NgdBuild:766 - The EDIF netlist 'synthetic2.edf' was created by the >> Xilinx >> NGC2EDIF program and is not a valid input netlist. Note that this >> EDIF >> netlist is intended for communicating timing information to >> third-party >> synthesis tools. Specifically, no user modifications to the contents >> of >> this >> file will effect the final implementation of the design. >> ERROR:NgdBuild:276 - edif2ngd exited with errors (return code 1). >> ERROR:NgdBuild:28 - Top-level input design file "synthetic2.edf" cannot >> be >> found >> or created. Please make sure the source file exists and is of a >> recognized >> netlist format (e.g., ngo, ngc, edif, edn, or edf). >> >> Any help is appreciated! >> YY > Hmm is it possible to embedd VHDL constructs in EDIF really? > > Then who will do the syntheses? > > /michaelArticle: 96707
Michael Schöberl wrote: > Thomas Stanka wrote: >> I see no clocking of the inputs, only the output and state are clocked. ... >> So you should think about synchronising mechanisms for the paralell >> input > > this is one solution - the source of the problem is a little deeper ... > > > When you specify a timing constraint for you clock then the tools make > sure that the delays between the flipflops are within the limit. Your > input delay is still unspecified and the tools do not care about it! > > > - you could specify input delays of your signal as a timing constraint > and make sure that it is met ... > > - you could use input flipflops (this is easier) ... > just register your input signals (with the same clock!) and make sure > that those flipflops get placed at the IO block ... > the delay from the pad to that first flipflop is fixed as there is only > one possible and short route > after that you should open your fpga editor and make sure that the input > FFs are used (there may be some settings in your synthesis tool to make > this happen) > As Thomas implied, asynchronous parallel inputs are plain *broken*. If they work at all, it's pure luck. You need some kind of strobe (a single bit), which is known to go active only after all the other lines are stable. Then you synchronise that strobe, and use the synchronised version to enable an input register for the other lines. Of course, all this may take several clocks to complete: during which your inputs are not allowed to change. Otherwise, given the parallel lines will not transition at the same instant, it's always possible to have a clock edge fall between them. This is true, regardless of the actual clock frequency. Synchronisation is a notoriously intractable problem: you can reduce the probability of errors to an arbitrarily small value, but not to zero. Your synchroniser should ideally use at least 2 flipflops, but at just 5MHz, you can probably get away with 1.Article: 96708
Peter, You need to get the MSB out of the FPGA, right? Look at using the double data rate FFs in the IOBs. I think the FF is called FDDRCPE in the libraries guide. This will let you get data out of the FPGA at twice your clock rate, one bit on the riding edge, one on the falling edge. This is probably the fastest, certainly the easiest and most reliable way to mux data out of the part. Also, use a DCM for your clock to make sure you have a 50% duty factor on the clock. Check out XAPP265. That guy gets 840 Mbps out of an LVDS output. HTH and good luck, Syms.Article: 96709
hi, Ya, i have used the OVLs for one of my projects Its good for verification if you have ample time ... You need to write all the possible assertions for a block and yet at later some point you will notice that there are some more to be written ...... Try system Verilog assertions ,they are smart but a bit difficult to learn.... regards, Anupam JainArticle: 96710
Theres one library in VHDL too like in verilog .... regards, Anupam JainArticle: 96711
Hi there, As far as I know (and I may be wrong, though I've never really investigated this) getting a vcd file with bus value changes instead of individual bit changes isn't possible. Check the modelsim documentation to be sure... You could write a program to parse the VCD file and translate individual bit changes into changes on a bus. Parsing the file isn't difficult, but if you're in a hurry this might not be the best way to spend your time! As for an option in the GUI in modelsim to generate vcd files, I've not seen one either... You may find that the FPGA vendor tools you are using will do this for you though - I think there's an option in Xilinx ISE to generate a ".do" file for modelsim with the vcd stuff included. Sorry I haven't been very specific, but I hope that's useful. JonArticle: 96712
Thank you.Ian Muncaster. By the way, In the spec:the length of CLK is 2.5inches +-0.1inch. if there is a qs3861 or resistor between connector and fpga,how can I calculator the length of PCB-trace?Article: 96713
RIGHT this is some calculation: Wouldn't advise using a resistor? For the QS381 the maximum propagation is 250ps, using a signal propagation of 1ns equals 12inches for lightly loaded line or 3inches for a loaded line (using bus switch most likely means lightly loaded) we can work out the equivalent trace length the bus switch would represent. Doing this you would find that this fails the PCI spec, we have seen no problems if you just make sure your clock trace is longer than your worst case for the rest of the bus. This means that the setup and hold times are met. "eehinjor" <eehinjor@163.com> wrote in message news:1139485190.614959.181580@o13g2000cwo.googlegroups.com... > Thank you.Ian Muncaster. > By the way, > In the spec:the length of CLK is 2.5inches +-0.1inch. > if there is a qs3861 or resistor between connector and fpga,how can I > calculator the length of PCB-trace? >Article: 96714
Thank you for your response so soon. 250ps is about 3inches,but the length of clk can not be longer than 2.5+0.1inches. how can that meet the spec?Article: 96715
It doesnt meat the spec thats what im saying, this area is one of the major problems with PCI and 3.3v systems such as your FPGA, as i said in our development boards we make sure the rest of the PCI bus meets there specification and then make sure the trace lengths of the clock signal either side of the bus switch is longer than your worst case by 0.5inches or greater. This works for our systems and we have seen no problems, making the trace longer ensures you meet the set up and hold times for the rest of the bus. This is no given thing it what we have seen working. REGARDS IAN "eehinjor" <eehinjor@163.com> wrote in message news:1139487456.386069.198790@g47g2000cwa.googlegroups.com... > Thank you for your response so soon. > 250ps is about 3inches,but the length of clk can not be longer than > 2.5+0.1inches. > how can that meet the spec? >Article: 96716
Hi all, I have some questions regarding the PLB and OPB busses used in EDK. 1) Is it true that a bus arbiter is needed only if there are 2 masters and up..(is there another scenario for using an arbiter) ? 2) Do I need to instantiate a bus arbiter manually or does the tool does it for me ? 3) PLB is said to be able to perform read/write in the same cycle - how it is accomplished (I saw only one master address bus) ? 4) What does a bus-split / decoupled address terms stand for ? I know that those are a lot of questions but I hope that someone will be able to help me with those. Thanks in advance, Mordehay.Article: 96717
Hi
I just created a design with a µBlaze and some LEDs for testing and a OPB
Busmaster device created with the xps helper with "User Logic SW Register
Support" and "User Logic Master Support". The device has one register
mapped to the OPB. The base adress of the device is 0x7d600000. If i
understand the description in the user_logic.vhdl from the obp_busmaster
device correcly the following instructions of the µBlaze should trigger an
bus transfer from the device to the LED port:
#define XPAR_OPB_BUSMASTER 0x7d600000
int main (void) {
int i,j;
for(i=0;i<10000;i++) {
WriteToGPOutput(XPAR_OPB_BUSMASTER,i);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x100,0x040);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x104,XPAR_OPB_BUSMASTER);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x108,XPAR_LEDS_8BIT_BASEADDR);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x10c,0x04);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x10e,0x0f);
WriteToGPOutput(XPAR_OPB_BUSMASTER+0x10F,0x0A);
for(j=0;j<10000;j++); //delay loop
}
return 0;
}
Any hints of whats wrong with my assumtions are welcome.
Thanks
S.T.
Article: 96718Jerome wrote: > Hi expert fellows :) , > I would like to get some advices on making a cheap usb analyzer with an > cheap FPGA board : > -i only target loww speed / full speed at the moment > - i woudl proceed like this : > * cut an existing USB cable, insert a breakoutinteh middle > * connect D+ & D- (and GND) to the FPGA pins (i guess impedance aspects > are OK since FPGA pin input Z is ~ infinite...) > * build the analyzer design using the opencore's USB PHY Core & USB 1.1 > Function Core > * the design would intercept all USB trafic and would store it onchip , > with the possibility of retrieving it on the PC > > The main Questions concerns > - electric level : i plan to only use D+ using LVTTL but .... > - NRZI tackle : how can i rebuild the USB clock from it ? > > Any advice welcome ! > > Have a nice day. I'm curious as to what your trying to achieve, I might be completely wrong about this but I feel some dongle cracking in the works!Article: 96719
"PeterC" <peter@geckoaudio.com> schrieb im Newsbeitrag news:1139454506.414529.307760@g47g2000cwa.googlegroups.com... > > Gurus, > > I have built and tested a numerically-controlled oscillator (clock > generator) using a simple phase accumulator (adder) and two registers. > One register contains the tuning word (N), and the other is used in > the > feedback loop into the second input of the adder. > > I take the MSB of the feedback register as my synthesised clock. I am > generating sub 50kHz clock frequencies, by clocking the feedback > register at 100 MHz. The accumulator is a 32 bit adder as is the > feedback register (of course). Works nicely on a board (my tuning word > comes from a processor chip, and my spectrum analyzer tells the truth > when I look at my MSB generated clock). > > To reduce the jitter I would like to run two or more phase > accumulators > in parallel which are clock-enabled on every-other clock cycle (as per > Ray Andraka's suggestion from the "how to speed up my accumulator" > post > by Moti in Dec 2004) and then switch between the MSBs of each > accumulator using a MUX on the MSBs. What about going analog ? This means: Build a R2R DAC with 2 CAT16 Respacks from 4 output's and then anti alias filter it. I use this approach to generate a high spectral purity 27MHz +-1% clock with a 48Bit DDS running at 100MHz. I generate a 5 Bit sine value out of a 16 entry ROM, dither this to 4 Bit at 200MHz (with help of the DDR IOB FF's). I connect the output node of the R2R DAC to a LC Parallel Resonant ciruit (the Filter) at 27MHz. This filter has the additional advantage to filter out more than the aliasing frequencies (also the quantization noise away from the 27MHz filter center) than a multiple order low-pass _and_ being much simpler and cheaper. This is then fed to the "receiving gate", a LVDS transmitter in my case making the analog sine wave a good digital signal. The spectral purity can get quite high. And there is still room for additional improvement. Raymund HofmannArticle: 96720
We've been waiting for these for a while now, but looks like it may be worth the wait... http://www.latticesemi.com/products/fpga/sc/index.cfm?jsessionid=ba30eea77baArticle: 96721
Hey Quartus automatically during compile promotes the CLK signal to a global. I tried manually doing it where you instructed and its not as you describe. I have quartus II 5.0. I have the design working with both the -10 and -15 part now. I would probably be more cautious with timing if the output wasnt going to a bank of LEDs. If it glitches every so often, it will be undifferentiated by a human right?? I dont see any glitches or issues with the system running right now. Now when it comes time to do the 32 buttons, I might be in for trouble, although it worked when it was breadboarded too. Thanks matt "ernie" <ernielin@gmail.com> wrote in message news:1139442128.267458.119770@z14g2000cwz.googlegroups.com... > Hi, > > One thing I would try is to declare "CLK" as a global wire. You can do > this in Quartus by opening the assignment editor, entering "CLK" as the >>From name, and then selecting "Global Signal" under Assignment name. > > Cheers. >Article: 96722
"Antti Lukats" <antti@openchip.org> wrote in message news:dsdg4k$hja$1@online.de... > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag > news:43ea38ea$1@clear.net.nz... > > been trying to setup CoLinux several times, always casued network issues, > tried 0.6.3 from free downloads, did not work, then purchased Open Colinux > tha is supposedly easy install version of CoLinux, but this easy install > installed without asking a VNC server and made all my email and networking > not working. Hi Antti, I also had some issues with CoLinux and the TAP network driver. I found out that under Win2K the trick is to start CoLinux first and then set up the bridge, it fails if you do it the other way around. On my laptop (WinXP) it worked out of the box, you just have to enable the share for the TAP driver (don't use the bridge option) and adjust your firewall, it is quite nice to have a "Cygwin type of DOSbox" which can run Linux binaries :-) I have documented the procedure here although as one would say, YMMV, http://www.ht-lab.com/howto/colinux_win.htm Hans www.ht-lab.comArticle: 96723
Symon wrote: > Peter, > You need to get the MSB out of the FPGA, right? Look at using the double > data rate FFs in the IOBs. I think the FF is called FDDRCPE in the libraries > guide. This will let you get data out of the FPGA at twice your clock rate, > one bit on the riding edge, one on the falling edge. This is probably the > fastest, certainly the easiest and most reliable way to mux data out of the > part. Also, use a DCM for your clock to make sure you have a 50% duty factor > on the clock. > Check out XAPP265. That guy gets 840 Mbps out of an LVDS output. > HTH and good luck, Syms. The DCM for 50% duty cycle correction is great. I'd add two things: 1) the phase accumulator can be staged so you have 4 8-bit adders instead of 1 32-bit adder allowing higher accumulator speeds, and 2) don't implement the full phase accumulator for the multiple NCO copies; use one phase accumulator but add different phase values (N/4, N/2, 3N/4, N) for different MSBs. This way your accumulators will never be mis-syncronized. If your frequency range is always tight (e.g., 25-50kHz) you can even reduce the resolution of the non-accumulating adders (N/4, N/2, 3N/4). For real *fun* you can use bit-serial arithmatic do to a 32-bit NCO then do a bit-serial divider to figure out what fraction of N the accumulator had when (and only when) it rolled over. While this isn't your typical 30-minute design session, it can be a great learning experience! I designed a bit-serial NCO a while back and know how to do nice pipelined dividers but haven't yet implemented those as bit-serial elements. Since your 50kHz or lower speed gives 2k cycles at 100MHz (or 8k cycles at 400MHz) you could use the technique to give you the maximum achievable DDR output rate the chip can support. Bit-serial is really amazing in this respect. In any case, the speed of the MUX you choose shouldn't be the limiting factor in your design. With the DDR IO register and pipelining, the MUX functionality can be 1 LUT of logic between registers at the maximum chip speed.Article: 96724
Hi, I am currently working on generating digital video using an FPGA. I am using VHDL to generate color bars and other test signal patterns. I am having a problem with the color bar video. When I look at the vector diagram of this video using a digital video analyzer, I see that the color vectors are curved and not straight. My Fpga also gets a reference video signal as input and my output video is timed horizontally and vertically according to the reference. What could possibly be the reason for the curved vectors. Any idea as to how I can make it straight. Any feedback is greatly appreciated. Thank you, Methi
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