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
Hi, MicroBlaze is a load/store machine, not a stack based processor. MicroBlaze have as most 32-bit RISC - 32 Register - 32 bit data path - 32 bit instruction words with 3 operand instructions - most instructions takes 1 clock cycle to execute MicroBlaze will perform as most other 32-bit RISC at the same clock frequency. Göran ssy wrote: > Hi all > > Microblaze actually run so fast(150Mhz) , but I do not think they are > high performence, > > because they are base on stack, not load/store structure in real risc, > so they must use more instruction's to do the same thing, > > Goran Bilski <goran.bilski@xilinx.com> wrote in message news:<3D2EF70C.A9DFC27@xilinx.com>... > >>Hi, >> >>A good start point for CPU on a FPGA is www.fpgacpu.org >> >>Since I design the MicroBlaze it's very possible to do high performance 3 >>2-bit >>RISC in fpga. (150 MHz in VIIPro) >>The distributed RAM in xilinx FPGA make it easy to do a register file. >> >>G?an >> >>res19j1c wrote: >> >> >>>Hi, >>>I'm new to FPGAs. I just have a few questions. I'm sure some of these h >>> >> ave >> >>>been asked already but I've been using the google archive to search old >>> >> >> >>>posts and couldn't find anything. >>> >>>1.) Is it correct that I could design a CPU on a FPGA? >>> >>>2.) It seems that the ability to create a certain design is measured in >>> >> >> >>>gates. So the more complex the design, the more gates it needs. Is this >>> >> >> >>>true, or at least partly true? >>> >>>3.) If so, how many gates would it take to implement a CPU with >>>functionality about equivalent to an Intel IA-32 style chip (80386 - 80 >>> >> 686). >> >>>4.) About how many MHz would this run at on a newer FPGA such as the >>>Virtex-II? >>>Article: 45176
MICHAEL ALEX wrote:
>
> Back in early June, Kevin Brace (I think) noted that one can generate an
> EDIF netlist in Webpack if you run XST from a batch file. I tried it
> back then, and indeed it worked. I recently upgraded my hard drive,
> reinstalled WebPack, and have been using Webpack and ModelSIM. However,
> now when I try to generate an EDIF netlist using the XST command as
> Kevin specified, I get an error message saying "XILINX environment
> variable not set." I didn't have this problem before, and XST still
> generates the (groan) NGC netlist from the Webpack IDE. There is
> probably a simple solution, but I can't find it. Any pointers?
>
> Thanks,
> Michael
Someone else found out that, in addition to running XST from the
command line, in case you are using ISE WebPACK 4.2, you can add the
"-ofmt EDIF" option from ISE's GUI.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=ad2sbv%248u0%2401%241%40news.t-online.com
The only problem I found with this method is that ISE's GUI won't update
the status of the design flow (i.e., Usually when the synthesis is done,
an exclamation mark or a check mark appears next to "Synthesize".)
because apparently ISE's GUI is monitoring for a .NGC file.
I don't know how to get ISE to monitor a .EDN file instead of a .NGC
file. (I will like to know that.)
Anyhow, it appears, the difference between an EDIF netlist and an NGC
encrypted netlist is only that the design gets encrypted with NGC, so
what I usually do is that when I want an EDIF netlist, I add "-ofmt
EDIF", and when I want ISE's design flow to work correctly, I remove
that option.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 45177On 14 Jul 2002 15:16:38 -0700, jdl1291@njit.edu (Joe Lawrence) wrote: >Greetings all, I am a newbie to FPGA & VHDL (currently a junior CoE at >NJIT). I have a Xess XSA-50 protoboard with a XC2S50 FPGA and am >using the latest Xilinx Webpack to create simple VHDL models like >comparators, d-q FFs, carry bit adders, etc to get a feel for things. >I run into trouble when I try to assign a signal in a process >sensitivity list to various FPGA locations such as buttons, parallel >port locations, etc. With my d-q FF, for example, I had wanted to use >the push button as a 'clock' input. My code seems straightforward and >simple enough: > >process (clk) >begin > > if (clk'EVENT) AND (clk = '1') THEN > -- flip flop code here > end if; > >end process; > >However, if I assign clk to pin 93, the pushbutton, I receive the >following error during the "Map" stage of "Implement Design": > >ERROR:MapLib:93 - Illegal LOC on symbol "clk" (pad signal=clk) or >BUFGP symbol > "clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should only be >LOCed to > GCLKIOB site. > In FPGAs, the clock tree is already built-in and the input pin to it can only be made from a limited set of pins. The mapper is telling you that the pin you chose is not one of these. Also using the output of a mechanical button as a clock is probably not a good idea. It would be better to properly debounce the button input and use it as an enable to the flop. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 45178
Yep it's true that the I/O bufs were assigned in an IO Interface module but not at the top level. Flattening the design fixed this problem. Thanks. "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:agi523$qa2$1@newsreader.mailgate.org... > > > Anthony Ellis wrote: > > > > Hi, > > > > I am struggling with a post map simulation of a Xilinx design with a > > bidirectional I/O port. The I/O port has an output register, input register > > and tristate control all defined with the IOB attribute. Looking at the map > > results the I/O implementation seems match what I expect. However, the > > mapping processes does issue warnings that IOBUF's are being added and that > > a simulation mismatch may occur - and my testbench does just this. > > > > Looking at the simprims logic it seems that the I/O port is implemented > > internally to the device as the pullup primitive, input register, output > > register are connected one level in from the actual chip I/O signal. This > > chip I/O signal has an X-BUF and X-TRI buf inserted before the output pin - > > making it now purely an output? > > > > I can't see why this is as the registered input is used all over (so cannot > > be removed) and the functional simulation works fine. > > > > Anthony. > > > I am not sure what exactly is going on, but my guess will be > that you might have tri-state buffers buried inside a submodule (i.e., > Tri-state buffers are not on the top module.), and also you are keeping > the design hierarchy during synthesis (i.e., Not flattening the design > hierarchy during synthesis.) > Assuming what I said is the case which I am not sure, what you can do is > you can flatten the design hierarchy during synthesis which will result > in tri-state buffers and associated registers getting "bubbled up" to > the top module which will get automatically converted to IOBUF or OBUFT > by XST. > The only problem of flattening design hierarchy during synthesis in XST > is that, if you have blackboxes in your design (i.e., Mixed language > design or using IP cores supplied in a netlist format.), XST will likely > mess up the synthesis (I have observed valid FFs getting mysteriously > disappearing from the netlist generated.). > In case you cannot flatten the design hierarchy because you are using IP > cores that requires you to keep the design hierarchy or to avoid the > fatal bug of XST I just mentioned, all you can do is to instantiate I/O > pad library primitives like OBUFT or IOBUF in your code. > If the design hierarchy is not flattened during synthesis in XST, XST > cannot seem to "bubble up" regular tri-state buffers (i.e., In Verilog > "assign My_Signal = My_Signal_OE ? 1'bz : My_Signal_Output;") unless you > use OBUFT or IOBUF. > Xilinx seems to have been aware of this problem of XST, but has done > nothing for years . . . > Another thing you may want to try before simulating your design > will be to take a look at the netlist generated by XST. > There you should be able to see if XST is indeed inferring IOBUFs. > (Synthesis report will also mention it, too.) > If you are using ISE 3.x's XST, you should have no problem reading the > EDIF netlist. > However, if you are using ISE 4.x's XST, Xilinx will tell (lie to) you > that all XST can do is it can only generate an encrypted netlist (.NGC) > and not an EDIF netlist. > I posted a posting in this newsgroup a few months ago that ISE 4.x's XST > can actually generate an EDIF netlist. > > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aceeac%249fj%241% 40newsreader.mailgate.org&rnum=1&prev=/groups%3Fq%3DKevin%2BBrace%2BXST%2BED IF%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Daceeac%25249fj%25241%2540newsread er.mailgate.org%26rnum%3D1 > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 45179
Hi, Without instantiating the component how does one force XST to use a global buffer driver (for spartan II) for a reset signal that is generated within the device. I have tried all the VHDL attributes that look possible. On some of the XST acknowledges their presence but still only reports the use of 2 BUFGP cells for the other two clocks in my design. Why would XST not do this type of thing automatically? AnthonyArticle: 45180
I'll take a stab at this one. Looks like you're tying to hook a push button to your clock (bad idea by the way, I'll explain later), the clock pins on the flops have driven by a special net which can only be driven by certain pins, and your push button on your proto board isn't one of those. If you really want to make something happen when you press the button, run the clock at a fized frequancy, and use your push button as an input to a state machine (after passing through 2 synchronizing flops) that does what you want to do like increment a counter or whatever. Another reason why you wouldn't drive a flop clock from a button is that it most likely isn't debounced, do it would trigger dozens of times as the contacts bounce. Regards jdl1291@njit.edu (Joe Lawrence) wrote in message news:<2f44ef64.0207141416.a5d6c61@posting.google.com>... > Greetings all, I am a newbie to FPGA & VHDL (currently a junior CoE at > NJIT). I have a Xess XSA-50 protoboard with a XC2S50 FPGA and am > using the latest Xilinx Webpack to create simple VHDL models like > comparators, d-q FFs, carry bit adders, etc to get a feel for things. > I run into trouble when I try to assign a signal in a process > sensitivity list to various FPGA locations such as buttons, parallel > port locations, etc. With my d-q FF, for example, I had wanted to use > the push button as a 'clock' input. My code seems straightforward and > simple enough: > > process (clk) > begin > > if (clk'EVENT) AND (clk = '1') THEN > -- flip flop code here > end if; > > end process; > > However, if I assign clk to pin 93, the pushbutton, I receive the > following error during the "Map" stage of "Implement Design": > > ERROR:MapLib:93 - Illegal LOC on symbol "clk" (pad signal=clk) or > BUFGP symbol > "clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should only be > LOCed to > GCLKIOB site. > > To correct the situation, I simply assigned clk to the FPGA's internal > oscillator. (As the error message suggests). Being new to both VHDL & > FPGAs I am curious, what if my design required me to act upon a change > in those other locations? Do I need some sort of work-around, or am I > simply missing something obvious? > > Thanks, > > > Joe Lawrence > -- jdl1291@njit.eduArticle: 45181
Better is what way? Speed? Area? Ease of design/maintenance? Why can't you just code the HDL and let the tools worry about the implimentation? Regards "Hristo Stevic" <hristostev@yahoo.com> wrote in message news:<19654150d84919e93d2b683758967185.52609@mygate.mailgate.org>... > Hello, > i have 6 inputs of 12-bit wordlength to multiplex. > i can use muxes using LUts. > Is there any better way (TBUF?) to do it? > target Xc4k or Virtex > > RegardsArticle: 45182
Ray Andraka wrote: > > > Unfortunately, we've found the floorplanner to be nearly useless in 4.1/4.2 > because it drops all the G/Y elements when try to place an RLOC'd macro. The > only work around is to let it do an autoplace, then constrain from placement, > then unbind and bind all the RPMs. Unfortunately, in a dense design (with large > RPMs), PAR gives up with no placement solution so that workaround isn't > available when you need it the most. I've also tried using RLOC_ORIGINs in the > ucf to help the placer out, but those seem to get ignored as often as used (the > weird thing there is the floorplanner recognizes the RLOC origin and puts the > decimated RPM in the right place, but the placer just blows them off). Part of > the reason we do so much RLOCed logic in the code is to avoid the customer > having to spend lots of timein floorplanner when he goes to change stuff in the > design, but the bigger reason is because we don't want to spend weeks on end in > the floorplanner. > Ray, Do you have cases open with Xilinx 'cos I can't see any mention of these bugs in the answers database ? I would have thought that something that worked in 3.3 but got broken in 4.1 should be fixed at the urgent/hot level ... but maybe I'm being naive.Article: 45183
I seem to remember reading somewhere (IIRC a comment on this NG from Austin Lesea) that, unlike previous families, the V-2 checks that the bit stream being loaded corresponds to the device beign configured. The only thing I can find in the configuration chapter of the V-2 UG is this comment on pg. 52 ``The fourth packet header writes to the ID register. This ensures the correct bitstream for the correct Virtex-II familiy member'' Can anyone confirm this means what I think it does?Article: 45184
Duane Clark wrote: > Yep, the black box declaration tells XST to just put a placeholder into > the edif/ngc file (I think it is the ngc file that XST builds). Then > ngdbuild will fill it in correctly. I get ya, this is actually beginning to make sense. > > The same process is used for any other non primitive modules supplied as > edif files. The edif file just needs to be where ngdbuild can find it. I > notice that Xilinx has some modules on their website, such as a UART, > available only in edif form. I was hoping to avoid learning that part :-) I guess I'll just wait a bit and get to it later! Patience, persistence, truth, Dr. mike -- Mike Rosing www.beastrider.com BeastRider, LLC SHARC debug toolsArticle: 45185
Manfred Kraus wrote: > You can route your design manually and control > every single bit if you use the Xilinx " FPGA editor". > You need detailed kwnowledge of the FPGA internal > architecture to do so. > > ... but this was done many years ago. > > Today you describe your design in a "high level" language > like VHDL and let the tools map, place and route everything. > > The design editor is still useful to check the results. Yes, I'm getting a better handle on how VHDL works, and how it feeds into all the place and route stuff. I was thinking that I'd need to be pretty specific on how things are called out to do what I'm after. It turns out the correct question should have been "what are the available primitives". By using the right primitive in VHDL I can do most of the work at very high level, and not worry about where it actually gets placed. I have found all the basic models on the Xilinx web site, so it's just a matter of digging my way thru them to find the right way to call them to get the primitive that will work for my application. I'll have a lot more questions as things fail :-) Patience, persistence, truth, Dr. mike -- Mike Rosing www.beastrider.com BeastRider, LLC SHARC debug toolsArticle: 45186
Hello there
I'm working on getting some FPGA images into a daisy chain of
three Spartan 250s. This is loaded in byte serial mode via the
parallel port pins of a Motorola coldfire processor.
This is a relatively simple extension of the sort of loading we've
done successfully in the past (eg. we've loading two devices, not
three), but we've had a _lot_ of trouble getting this running on our
new hardware.
Our current fix is to put a small cap (22pF) from the CLK line to
ground. We cannot see the effect of this cap on the 'scope, but it
definitely makes a difference to the loading.
Our concern is that even without the cap all the timing constraints
for programming the Xilinx parts appear to be being met. the CLK line
is slew-rate limited to ~10nS, and there appears to be no coupling
between the CLK and PROGRAM pins. We believe that we are ensuring that
the various details mentioned in app notes etc. are being adhered to.
The board is very well decoupled and we are confident of the DC
supplies to the processor and FPGAs. The general purpose pins on the
Motorola Parallel port are supposedly well capable of driving these
loads, and we're not running at any great speed (CLK about 1usec high,
4usec low).
My question is - is there any 'lore' out there about programming
Xilinx parts, or Spartan 2s in particular, that might shed light on
this problem? Any pointers very gratefully received!
Thanks
Jon Nicoll
Alembis Ltd.
Article: 45187Hi, I'm currently trying to spec a project that needs to do some serious video processing (mpeg2 encoding or similar) in a mobile (wearable) environment. i.e. battery powered. Does anyone have any opinion on what dsp platform would be suitable. People have been talking about xilinx chips or something similar. However, I'm most familiar with DSP programming on ti processors (such as C67xx) but would an implementation using ti processors take too much power and be too slow. Ideally I would like to reuse the c-code that I have already for the mpeg2 codec but with xilinx chips this would not be possible. Any ideas anyone? Paul HillArticle: 45188
Because the BUFGP is a clock buffer, not intended for other signals.
Anthony Ellis wrote:
> Hi,
>
> Without instantiating the component how does one force XST to use a global
> buffer driver (for spartan II) for a reset signal that is generated within
> the device. I have tried all the VHDL attributes that look possible. On some
> of the XST acknowledges their presence but still only reports the use of 2
> BUFGP cells for the other two clocks in my design.
>
> Why would XST not do this type of thing automatically?
>
> Anthony
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45189
Yes, I have open cases with xilinx on these, and no, there is nothing in the answers
data base that even suggests a problem other than one mention of the carry chain
placement. I too would have thought that these issues would be issues for other users,
as I think it would also affect RPM'd coregen macros. The 3 cases I had open regarding
decimation of the RLOC'd macros by the floorplanner (297939 Floorplanner: VIrtexE
floorplanner RPMs incorrectly instantiated , 409579 4.1i Floorplanner incorrectly
handles carry chains, 431465 4.2.03i Virtex- II RPM drops Y parts in floorplanner) were
closed with the workaround I mentioned and a "will be fixed in the next MAJOR release"
comment. Unsatisfactory in my opinion, but what is one to do. The remaining one
regarding the RLOC_ORIGIN is open (433792 RLOC_ORIGIN ignored by PAR ).
The point is, floorplanning has always been regarded by Xilinx as the unwanted
stepchild. Apparently, floorplanner bugs are regarded as not affecting the average
user so it is automatically relegated to a backburner issue.
Rick Filipkiewicz wrote:
> Ray Andraka wrote:
>
> >
> >
> > Unfortunately, we've found the floorplanner to be nearly useless in 4.1/4.2
> > because it drops all the G/Y elements when try to place an RLOC'd macro. The
> > only work around is to let it do an autoplace, then constrain from placement,
> > then unbind and bind all the RPMs. Unfortunately, in a dense design (with large
> > RPMs), PAR gives up with no placement solution so that workaround isn't
> > available when you need it the most. I've also tried using RLOC_ORIGINs in the
> > ucf to help the placer out, but those seem to get ignored as often as used (the
> > weird thing there is the floorplanner recognizes the RLOC origin and puts the
> > decimated RPM in the right place, but the placer just blows them off). Part of
> > the reason we do so much RLOCed logic in the code is to avoid the customer
> > having to spend lots of timein floorplanner when he goes to change stuff in the
> > design, but the bigger reason is because we don't want to spend weeks on end in
> > the floorplanner.
> >
>
> Ray,
>
> Do you have cases open with Xilinx 'cos I can't see any mention of these bugs in the
> answers database ?
>
> I would have thought that something that worked in 3.3 but got broken in 4.1 should
> be fixed at the urgent/hot level ... but maybe I'm being naive.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45190I wish to use a stable crystal based oscillator to clock a Spartan IIE, preferably either at 200MHz, or if not possible then at 100MHz. The design also includes a DDS and ADC which need to be clocked at 200MHz, so I intend to use the same oscillator connected directly to these peripherals. I also need to drive a PLL with a reference frequency less than 40MHz to create an RF output at 2.4GHz which should be phase coherent with the stable oscillator. I hoped to use a DLL on the FPGA to divide the clock by 4 or 8 to create a 25MHz clock output, but the propagation delay is about 8ns which is highly significant at this frequency. Can the clock mirroring technique be used with clock division in order to create an output clock which is phase coherent with the master clock? (aside from the jitter created by the DLL which should hopefully be small). Thanks TomArticle: 45191
Hi, I would like to know if one can launch the SOPC builder from Altera (NIOS) as a standalone programm, without the use of quartus ? For information : I'm using a sun version of quartus. Thanks a lot for your help. StephaneArticle: 45192
Accept that. So how does one generate a global reset from an internal signal. "Ray Andraka" <ray@andraka.com> wrote in message news:3D32B59E.AC71B00C@andraka.com... > Because the BUFGP is a clock buffer, not intended for other signals. > > Anthony Ellis wrote: > > > Hi, > > > > Without instantiating the component how does one force XST to use a global > > buffer driver (for spartan II) for a reset signal that is generated within > > the device. I have tried all the VHDL attributes that look possible. On some > > of the XST acknowledges their presence but still only reports the use of 2 > > BUFGP cells for the other two clocks in my design. > > > > Why would XST not do this type of thing automatically? > > > > Anthony > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 45193
On a PC you can run "qmegawiz.exe" from the /bin directory to start a standalone version of the MegaWizard and SOPC builder. You should check whether something similar exists in your Solaris installation. - Wolfgang http://www.elca.de "Stéphane Mancini" <stephane.mancini@inpg.fr> schrieb im Newsbeitrag news:pan.2002.07.15.14.58.51.52561.3246@inpg.fr... > Hi, > I would like to know if one can launch the SOPC builder from > Altera (NIOS) as a standalone programm, without the use of quartus ? > For information : I'm using a sun version of quartus. > > Thanks a lot for your help. > > StephaneArticle: 45194
Rick, Yes it does. Virtex II added a device type field to the configuration bitstream (which is not present in Virtex) so that the device can not be configured by a valid bitstream for the wrong part. The ID register is that device type information. There is also an ID code register, which is the mask revision, that is not in the bitstream for configuration, but can be read out. Austin Rick Filipkiewicz wrote: > I seem to remember reading somewhere (IIRC a comment on this NG from > Austin Lesea) that, unlike previous families, the V-2 checks that the > bit stream being loaded corresponds to the device beign configured. > > The only thing I can find in the configuration chapter of the V-2 UG is > this comment on pg. 52 > > ``The fourth packet header writes to the ID register. This ensures the > correct bitstream for the correct Virtex-II familiy member'' > > Can anyone confirm this means what I think it does?Article: 45195
Tom, All of the DLL outputs are phase locked to the CLKIN of the DLL. Thus the CLKDV will also be phase aligned with the rising edge of CLKIN. The jitter of the DLL should be attenuated well by the external PLL creating the 2.4 GHz, as all of the power in the jitter spectrum of a DLL are at high frequencies (updates to taps are made every 6 times the "jitter filter" register values number of input clocks), which get attenuated well by frequency multipliers. It is low frequency jitter that can not be attenuated well by a frequency multiplier. To shift the jitter power spectral density up in frequency, set the jitter filter to 0xFFFFh (2's complement number, or every 6 input clocks a tap is updated). Jitter on the CLKDV output will be ~ 200 -> 300 ps P-P, which should not be a problem for the reference to the frequency multiplier. Use of a master oscillator which then goes to the DDS, the ADC, and the FPGA fed from a clock buffer that drives all three using LVDS or LVPECL is highly recommended. Integrated Circuits Systems, Inc (ICST.com) has a lot of good parts just for this purpose. Their 8745 PLL is also great for attenuating jitter (tested in the FPGA Lab). Austin Tom D wrote: > I wish to use a stable crystal based oscillator to clock a Spartan IIE, > preferably either at 200MHz, or if not possible then at 100MHz. The design > also includes a DDS and ADC which need to be clocked at 200MHz, so I intend > to use the same oscillator connected directly to these peripherals. > > I also need to drive a PLL with a reference frequency less than 40MHz to > create an RF output at 2.4GHz which should be phase coherent with the stable > oscillator. I hoped to use a DLL on the FPGA to divide the clock by 4 or 8 > to create a 25MHz clock output, but the propagation delay is about 8ns which > is highly significant at this frequency. Can the clock mirroring technique > be used with clock division in order to create an output clock which is > phase coherent with the master clock? (aside from the jitter created by the > DLL which should hopefully be small). > > Thanks > > TomArticle: 45196
--------------60A4AAB7F51DC89BDD3ABFC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jon, This is a classic signal integrity SI) problem. The clock frequency isn't the issue, it is the rise and fall times, which are incredibly fast (< 1 ns). Thus with a 10 Gs scope with 3 GHz fet probes, you might be able to see what is happening (impedance mis-match). Seeing it won't help you though. I would simulate your PCB and drivers and receivers using IBIS models, and the extracted pcb trace impedances and other transmission line characteristics using an IBIS simulator (Hyperlynx, Cadence SpectraQuest, Mentor, Innoveda, etc). This way you can layout the board, place terminations, adjust the impedances of the lines, etc. The idea is that if you simulate it, you can fix it before you build the boards, and save spinning the pcb due to SI issues three to seven times (typical of what happens if you don't simulate!). When the boss complains about the price of the simulator, I think the idea of no more board spins for SI, and no more wasted time playing with unreliable bandaids (ie caps) will win the argument forever. Innoveda's Hyperlynx costs less than spinning the pcb even once. Austin Jon Nicoll wrote: > Hello there > I'm working on getting some FPGA images into a daisy chain of > three Spartan 250s. This is loaded in byte serial mode via the > parallel port pins of a Motorola coldfire processor. > > This is a relatively simple extension of the sort of loading we've > done successfully in the past (eg. we've loading two devices, not > three), but we've had a _lot_ of trouble getting this running on our > new hardware. > > Our current fix is to put a small cap (22pF) from the CLK line to > ground. We cannot see the effect of this cap on the 'scope, but it > definitely makes a difference to the loading. > > Our concern is that even without the cap all the timing constraints > for programming the Xilinx parts appear to be being met. the CLK line > is slew-rate limited to ~10nS, and there appears to be no coupling > between the CLK and PROGRAM pins. We believe that we are ensuring that > the various details mentioned in app notes etc. are being adhered to. > > The board is very well decoupled and we are confident of the DC > supplies to the processor and FPGAs. The general purpose pins on the > Motorola Parallel port are supposedly well capable of driving these > loads, and we're not running at any great speed (CLK about 1usec high, > 4usec low). > > My question is - is there any 'lore' out there about programming > Xilinx parts, or Spartan 2s in particular, that might shed light on > this problem? Any pointers very gratefully received! > > Thanks > Jon Nicoll > Alembis Ltd.Article: 45197
I was wondering which is the best way to make some register with settable and clearable bits in VHDL. Suppose I have an embedded processor and a host controller. Host controller sets a flag in a register, which causes in interrupt at the embedded one. When the interrupts is processed the embedded one clears the flag. This means that both sides must have access to the same flag. This can be solved with an asyncrhonous clear of the flipflop, but I was wondering which is most commonly done in this kind of situations. Any suggestions ? MarcelArticle: 45198
isn't that just a j-k flip flop?
host controller is always setting
processor is always resetting
--or something like this
interrupt_register : process (clock, reset)
if Reset = RESET_ACTIVE then
Interrupt <= '0';
elsif rising_edge (clock) then
if Host_Controller_Interrupt = '1' then
Interrupt <= '1';
elsif Processor_Interrupt_acknowledge = '1' then
Interrupt <= '0';
end if;
end if;
end process interrupt_register;
"Marcel" <marcelgl@hatespam.xs4all.nl> wrote in message
news:3d32f623$0$12305$e4fe514c@dreader4.news.xs4all.nl...
>
> I was wondering which is the best way to make some register with settable
> and clearable bits in VHDL.
>
> Suppose I have an embedded processor and a host controller. Host
controller
> sets a flag in a register, which causes in interrupt at the embedded one.
> When the interrupts is processed the embedded one clears the flag.
>
> This means that both sides must have access to the same flag. This can be
> solved with an asyncrhonous clear of the flipflop, but I was wondering
which
> is most commonly done in this kind of situations.
>
> Any suggestions ?
>
>
> Marcel
>
>
>
>
>
>
Article: 45199>"Marcel" <marcelgl@hatespam.xs4all.nl> wrote in message news:3d32f623$0$12305 > Suppose I have an embedded processor and a host controller. Host controller > sets a flag in a register, which causes in interrupt at the embedded one. > When the interrupts is processed the embedded one clears the flag. Marcel, I'm no expert, but I've been using a fairly simple scheme sucessfully in my designs. You use two flipflops, one in each clock domain. The output flag is the xor of the two ff Q outputs. What you connect to the D's of each ff determines their function. For example, for the clock of each ff to toggle the output, configure the ff's as toggles. For one to set and the other reset (as in your case), connect [not Q2 => D1] for the setter and [Q1 => D2] for the reseter. There may be problems with this with which I am unaware, but it has worked for me well both in simulation and hardware. Jim
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