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
After some investigation with the design files provided by the OP, it
seems that the design files were created for a different part, that
will explain why MAP errors out.
It's a good practice, if the user change the targeted part, to clean the
project files (form menu Project -> Cleanup Project Files) and of course
take care of the UCF file which will not match the new target part.
Aurash
methi wrote:
>Hi..
>I am currently working with Xilinx ISE 6.3i ..The design is in VHDL..I
>tried adding some extra inputs and outputs to the top level entity and
>hence made the corresponding changes to the UCF file.
>But when I try implementing the design, it shows errors in the Map
>process as follows:
>1) The extra inputs I added in the UCF file are shown as invalid
>
>I have just used the format
>
>for example:
>
>NET "my_input_name" LOC = "P34" ;
>
>2)Should I also add INST?
>
>If so how should I do that and is it for all the component
>instantiations?
>
>3)When should I use | IOSTANDARD = LVTTL | PULLDOWN ?
>
>I then removed the unused inputs and outputs but it still shows the
>same error...
>
>Any suggestions are welcome..
>
>Thanks in advance,
>
>Methi
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 84726Thank you very much. I made the changes to my %path% variable and it works like a charm. Jim TuilmanArticle: 84727
How should I connect a single-ended clock source the PLL inputs of a
Cyclone?
In the manual there are some examples of differential clock inputs and a
note,
that PLL can also accept single-ended inputs, but no example is provided.
So what should I do -- connect the positive PLL_CLK input to the oscillator
and the negative input to GND (directly or through a capacitor?)?
Best regards
Piotr Wyderski
Article: 84728You don't need to connect the negative input to GND. Just connect your single ended clock to one of the CLK[3..0] inputs. Easy as that. For example, I connected CLK0 to a clock and CLK1 to a system reset.Article: 84729
kurapati wrote: > hi Ed, > > I found I/O expansion header port with JTAG pins. Can I use it for my > JTAG PC-3 cable instead of having PC-4. If so how can I do that and > what kind of jumper settings I have to do on my ML403 board. > > Even I am trying to use compact flash but I found some problem in > converting .bit file to.ace file. I used iMPACT to convert the file > format but when I want to configure the device with the new .ace file > the Err led lights on with red. What could be the problem. > > Please do u suggest me the best way to configure the device on ML403 > board. > > regards > No, that is for downstream use for configure a device on a daughter card. If you tried to use this you would have contention on the TDI, TCK and TMS pins from System ACE. You have to go in through the 1mm PC-4 header. EdArticle: 84730
"Jon Beniston" <jon@beniston.com> wrote in message news:1116594118.303249.206940@g49g2000cwa.googlegroups.com... > Check out Synplicity's Synplify Proto. > > Cheers, > Jon > If the modules are encrypted ... which synopsys likes to do for its designware IP ... you will have to use a synopsys synthesis product such as fpga compiler. MikeArticle: 84731
Hi Thomas, > So a mix of VHDL and schematic design (top-level: schematic, with > sub-modules that may also be in VHDL) would be perfect. I've been doing exactly that for many years. > Is there any good > tool out there that can convert such a graphic/VHDL-mixture into a > vendor-independent VHDL-design? Well, kind of...ViewDraw is capable of doing exactly that, but it is currently not supported by Xilinx. You simply set the schematic symbol to point to, well, pretty much any HDL, even Abel. Not sure how this flow works with the new tools though...file formats have changed since I've done this. On the issue of vendor independance, my libraries ARE vendor independant. Only the lowest level elements are vendor depeandant. Of course, some elements aren't available in some technologies...so no matter what, you are still vendor dependant in most designs. But, I've also never ever ever in the many dozens of dozens of designs I've done had to convert from one FPGA vendor to another. I have converted say, a 4k design to a Spartan (big deal, their the same ;-), or 2k to 3k... Regards, AustinArticle: 84732
I have made a powerpc system with a user peripheral connected to the plb bus. The user peripheral has an address range from 0xffffff00 - 0xffffffff. At startup the powerpc starts executing from 0xfffffffc, so my peripheral is accessed at startup. In case of a plb bus read action, it always returns "4BFF7FE4" which is a jump to my boot0 section laid in bram. In the linkerfile I forced the boot0 section to a specified address, so the jump should be correct anytime. However, the system is not starting (no output from my uart port). Should the described method work, or do I forget something? If it should work, what could be wrong (I already tried to return "E47FFF4B" in case the byte order may be incorrect, but it gave the same result). TIA, FrankArticle: 84733
hi when I generate systemACE file in EDK I am getting the following error. Anyone can give me some tip how I can get rid of it. I am working on ML403 board. thanks ********************************************* Creating system ace file ********************************************* xmd -tcl genace.tcl -jprog -hw implementation/download.bit -elf dcr_test/dcr_test.elf -ace implementation/system.ace Xilinx Microprocessor Debug (XMD) Engine Xilinx EDK 7.1 Build EDK_H.10.4 Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. Executing user script : genace.tcl ####################################################################### XMD GenACE utility. Generate SystemACE File from bit/elf/data Files ####################################################################### GenACE Options: Board : ml403 Target : ppc_hw Elf Files : dcr_test/dcr_test.elf Data Files : HW File : implementation/system.bit ACE File : implementation/system.ace JPROG : true ############################################################ Converting Bitstream 'implementation/system.bit' to SVF file 'implementation/system_bit.svf' Executing 'impact -batch bit2svf.scr' Copying implementation/system_bit.svf File to implementation/system.svf File ############################################################ Converting ELF file 'dcr_test/dcr_test.elf' to SVF file 'dcr_test/dcr_test.svf' E02 Cannot Open Cable. Unable to connect to PowerPC target. Make sure the PPC405 JTAG signals are Connected to JTAGPPC primitive and Cable Connections are Correct #$ Error: ERROR: Unable to create SVF file 'dcr_test/dcr_test.svf' for ELF file : dcr_test/dcr_test.elf Done.Article: 84734
Thomas Entner wrote: > > So a mix of VHDL and schematic design (top-level: schematic, with > sub-modules that may also be in VHDL) would be perfect. Is there any good > tool out there that can convert such a graphic/VHDL-mixture into a > vendor-independent VHDL-design? > There have been many tools in the past. I would guess that 5-10 years ago, quite a few true schematic programs allowed this. I used one of them for a number of years. It would output VHDL code and also xnf files, so that I would simulate in Modelsim and then incorporate the various bits and pieces during ngdbuild. Another kind of tool was the HDL graphic tools, which were good for the block diagrams you talk about, along with generally providing graphical state diagram creation. I also used one of these in the past. I prefer the schematic/graphic input tools. I generally find that they are easier to look back at and figure out what is going on. They are generally quick and easy to use, especially as mentioned once a library has been developed. But I have completely abandoned all the graphical tools for the tedious process of coding in VHDL directly. In general, industry expects HDLs. I had a reviewer for a customer complement a design, and then make an offhand comment about it being done schematically, in a tone that conveyed his surprise at that. But really the main reason was that I have seen far too many schematic/graphical tools come and go. In a previous employment incarnation, we had to keep around an old Windows 3.1 machine gathering dust in a corner, just to support the schematics from an old but still active project. And the schematic package mentioned above that I used for mixed schematic VHDL designs is now also obsolete, and I am once again keeping an old schematic program around to support old designs. Well no more! ;) That is a problem that is far less likely to happen with HDLs. And while I still consider VHDL tedious, I have come to appreciate the strengths of doing designs this way. Not least of which are the many very simple methods available for doing source control.Article: 84735
Austin Franklin wrote: > Hi Dave, > > >>VHDL makes >>designing complex and/or large hardware very easy compared to schematic >>entry... > > > A tool is only as capable as the person using it. For the same "function", > some can easily create schematics as fast as anyone can code in HDL, if that > schematic person knows what they are doing. The key is symbol libraries, > and better yet, tested libraries (thank you Philip ;-)...which allows > hierarchical, basically, drag and drop, schematics. This can be done with > datapaths, as well as state machines, functions etc. It's as good (or as > poor) as you want it to be, depending on how much work you put into your > libraries. > Well yes and no. Schematic design and data entry pre-date HDLs. The place and purpose of schematics is well known. They will always exist. I do however believe you are flawed in thinking that the time taken to type multi-layer package/module replications is longer compared with cut/load/insert and paste, then linking the wires manually. But hey, I use the Altera MAX/Quartus schematic entry tools; there are better tools available. > Of course, it takes time to build up a good library, but not *that* much > time, and the time it saves in the long run can be huge. People seem to > like to draw gates...why I don't know. Again, I think you are comparing HDL starting from scratch with schematic libraries. You can also have VHDL libraries. > My schematics are like block > diagrams, and alleviate the "need" that people have to turn HDL code into > block diagrams to understand what it does. > This is the key area were schematic entry beats HDL entry hands down, schematic entry is automatically self documenting. However, there are tools to do this. Developers I have met can visualise the schematic just from reading the HDL. > I won't contend that if starting from scratch, HDLs will typically have an > edge on time to completion, and the tools today are far better than a decade > ago, but that does not diminish my point. IF someone had come out with a > library that was publicly available, schematics would have been quite a bit > more popular. > k.... > This capability (having a large library of pre-built schematic modules) was > a huge advantage I had for many years being an independant contractor. I > was able to do designs that met performance goals of speed and resource > utilization, as well as do them very quickly and cost effectively. > But, basically, schematics for FPGAs, at least Xilinx FPGAs, are dead today, IMO. > You prefered schematics, others have HDLs. Like I said to Gary who started the thread: Diagramatic description, design and management will always have a place with humanity, we prefer pictures. New methods and new tools have their place, but they don't always make old methods and old tools redundant. I am reminded of a comedian who told a story of a visit to the Opticians. After putting on his new varifocals he found it very difficult press lift buttons, walk off/on street edges, judge the distance from cars etc. Eventually he got to a phone booth and called his wife at home. He describing the disturbing events, his fear and desperation and begged her to pick him up. Down the phone she snapped: "Stupid! Take off your new glasses and come home!" > But, without schematics, I could not have done the designs I did in the > earlier Xilinx series parts (2k, 3k & 4k), as the synthesis tools were > rather poor back then, and required far more work to get the results to come > close to the speeds (and densities) achievable with schematics. Using an > HDL simply as a netlister is not a very good use of the tool IMO...but now, > that is the only way to get every Hz out, is to instantiate what you need to > using HDL. Sigh. > FPGA/CPLD/PLDs will always implement binary constructions to provide the desired application function(s). > There is not a thing wrong with schematics compared to HDLs, and schematics > even have many advantages, but today, they just aren't popular. HDLs are. > It has not a wit to do with schematics lack of ease or capabilities. > IMHO: HDLs will become hidden within purely diagramatic design tools, much the same way software development is about module reuse and UML/SSADM diagramatic tools now. Not the case back when I started. > Regards, > > Austin > >Article: 84736
My last IC design job in CA at MMI, I had to spend a few months doing just that with mask plots on a light table, with millions of geometries. Very big waste of time, the Dracula system was well able to do the xor difference job but I wasn't allowed to use that. What happens when the schematic gets rearranged but is still the exact same netlist, time for SW analyzer. Still graphics can be alot quicker to grok design intent for many situations. johnjakson at usa dot comArticle: 84737
I thought the deal with Proto was that it provides its own version of lots of designware modules... Maybe I'm wrong. Cheers, JonArticle: 84738
amyler@eircom.net wrote:
> You don't need to connect the negative input to GND.
> Just connect your single ended clock to one of the
> CLK[3..0] inputs.
What should I do with the unused inputs?
Just leave them floating in the air?
Best regards
Piotr Wyderski
Article: 84739Hi, I'm using Quartus 4.1 Web Edition to program a MAX7000S CPLD. I'm using an lpm_counter as a programmable divider with data[] and sload inputs, and cout output. I'm not using the q[] outputs. Originally, I connected cout directly back to sload, but I had intermittent problems. I routed cout to an I/O so I could look at it on the 'scope, and it was oscillating at very high frequency. To fix this, I had to put a DFF between the cout and the sload. This works, but now I need two dividers, and I can't spare another DFF. Is there another way to do it?Article: 84740
I don't see the behavior of the cout and the sload documented. I would expect your tools would report a race condition if the cout IS dependent on the sload. But, assume for the moment the sload affects the cout such that an sload with a data[] value of all ones would force a cout even if the original count was less. To get around the problem, tie sload to "the q[] value of all ones" to eliminate the cout dependence on sload. "Andrew Holme" <andrew@nospam.com> wrote in message news:d72fsf$p9v$1$8302bc10@news.demon.co.uk... > Hi, > > I'm using Quartus 4.1 Web Edition to program a MAX7000S CPLD. > > I'm using an lpm_counter as a programmable divider with data[] and sload > inputs, and cout output. I'm not using the q[] outputs. Originally, I > connected cout directly back to sload, but I had intermittent problems. I > routed cout to an I/O so I could look at it on the 'scope, and it was > oscillating at very high frequency. To fix this, I had to put a DFF between > the cout and the sload. This works, but now I need two dividers, and I > can't spare another DFF. Is there another way to do it?Article: 84741
Hi Andrew, There was a problem with Q II 4.1 which didn't synthesize lpm_counter correctly, but not when targetting this device. Still, you might want to check it out: http://www.altera.com/support/kdb/2004/09/rd09092004_7423.html -- Pete Andrew Holme wrote: > Hi, > > I'm using Quartus 4.1 Web Edition to program a MAX7000S CPLD. > > I'm using an lpm_counter as a programmable divider with data[] and sload > inputs, and cout output. I'm not using the q[] outputs. Originally, I > connected cout directly back to sload, but I had intermittent problems. I > routed cout to an I/O so I could look at it on the 'scope, and it was > oscillating at very high frequency. To fix this, I had to put a DFF between > the cout and the sload. This works, but now I need two dividers, and I > can't spare another DFF. Is there another way to do it?Article: 84742
i'm not using a DLL/PLL because they can't divide the clk that low ... and i'm already using a clk buffer ... "donghun" <kim.donghun@gmail.com> wrote in message news:1116978770.187785.227440@f14g2000cwb.googlegroups.com... > What kind of Xilinx FPGA do you use? Most Xilinx FPGA device, Spartan > and Vertex, have DLL(PLL). If you want to divide clk, you should use > internal DLL to reduce skew and easy use. If else, you should use > IBUFG(clock input buffer) for input and OUBF(output buffer) for output. >Article: 84743
Peter Sommerfeld wrote: > Andrew Holme wrote: >> Hi, >> >> I'm using Quartus 4.1 Web Edition to program a MAX7000S CPLD. >> >> I'm using an lpm_counter as a programmable divider with data[] and >> sload inputs, and cout output. I'm not using the q[] outputs. >> Originally, I connected cout directly back to sload, but I had >> intermittent problems. I routed cout to an I/O so I could look at >> it on the 'scope, and it was oscillating at very high frequency. To >> fix this, I had to put a DFF between the cout and the sload. This >> works, but now I need two dividers, and I can't spare another DFF. >> Is there another way to do it? > Hi Andrew, > > There was a problem with Q II 4.1 which didn't synthesize lpm_counter > correctly, but not when targetting this device. Still, you might want > to check it out: > > http://www.altera.com/support/kdb/2004/09/rd09092004_7423.html Hi Peter, Thanks, I came across that article myself. I didn't think it applied because the MAX7000S isn't listed - as you point out, and also I'm not using synchronous clear or asynchronous set. It does sound spookily similar though. Perhaps I should try it anyway...Article: 84744
Andrew Holme wrote: [snip] I should've mentioned - 1. I'm using the lpm_counter as a down counter. 2. I think (fairly sure, but not 100%) the problem goes away if you add a clock enable input - this forces it to use a different template or something.Article: 84745
Hi Krzysztof, In the EDK documentation section, http://www.xilinx.com/ise/embedded/edk_docs.htm, there is a PDF that can help with your queries: PPC Block Ref. Manual -- http://www.xilinx.com/bvdocs/userguides/ug018.pdf, which details the signals. The Debug Interface, Trace Interface and RISCWatch sections are the most helpful section. I do not think they have waveforms, but do have the descriptions of the different signals and their roles. PPC Reference Manual --http://www.xilinx.com/ise/embedded/ppc_ref_guide.pdf, which has a Debugging section that you may want to skim through as well. Good luck, NN Krzysztof Szczepanski wrote: > Hello! > > Is there any hardware documentation to RISCWatch of PPC405 in Xilinx > devices? I look for waveforms describe the signals of the interface. > Is there any JTAG vendor specific commands used to debug the processor? > > Thanks!!! > > krzysiekArticle: 84746
Greetz, don't use the DLL or PLL, their division rate is much too small. You seem to concatenate several SRL16s, each dividing by 16, so that 5 LUTs divide by over a million. That probably means that you ripple the clock, and end up with a very slow (=low-frequency) output that has no clear phase relationship with your original 100 MHz. Depending on your application that may or may not be acceptable. You can also re-synchronize after each SRL16 and thus keep a tighter phase relationship. I worry about the functional stability of a 1-of-16 SRL16. Theoretically it will recirculate a single1 forever. But what if it loses its token, or what if it picks up another stray 1? There seems to be no mechanism that fixes that automatically. I prefer circuits that recover from a disaster. I once looked at a 32-bit divider consisting of two SRL16s as LFSR counters, and a 5-bit counter that detects the unique pattern of 32 zeros. I think it fits into one CLB (4 slices = 8 LUT-FFs) Peter Alfke, Xilinx ApplicationsArticle: 84747
Hi Dave, "dave" <dave@dave.dave> wrote in message news:d7290g$mnj$1@news7.svr.pol.co.uk... > Austin Franklin wrote: > > Hi Dave, > > > > > >>VHDL makes > >>designing complex and/or large hardware very easy compared to schematic > >>entry... > > > > > > A tool is only as capable as the person using it. For the same "function", > > some can easily create schematics as fast as anyone can code in HDL, if that > > schematic person knows what they are doing. The key is symbol libraries, > > and better yet, tested libraries (thank you Philip ;-)...which allows > > hierarchical, basically, drag and drop, schematics. This can be done with > > datapaths, as well as state machines, functions etc. It's as good (or as > > poor) as you want it to be, depending on how much work you put into your > > libraries. > > > Well yes and no. I'm not sure what you could be saying "no" to, they are simply statements of fact. > Schematic design and data entry pre-date HDLs. The > place and purpose of schematics is well known. They will always exist. > > I do however believe you are flawed in thinking that the time taken to > type multi-layer package/module replications is longer compared with > cut/load/insert and paste, then linking the wires manually. No thinking involved, so no possible flaw in it ;-) I speak from nearly two decades of direct experience with FPGAs, and three decades of direct experience with ASICs. I know exactly what it takes to use both methodologies, as well as a combination of both. Also, pins aren't "linked" entirely manually. And, hooking wires is typically quite a bit faster than typing things in. I have not found this issue to be a significant part of the process, on either end. > > Of course, it takes time to build up a good library, but not *that* much > > time, and the time it saves in the long run can be huge. People seem to > > like to draw gates...why I don't know. > Again, I think you are comparing HDL starting from scratch with > schematic libraries. No, not at all. > You can also have VHDL libraries. Of course, I have plenty of them, but the time savings is far less significant, than it is for schematic libraries. Especialy for elements such as muxes/counters/registers/IO, things that are multi-bit, that in HDLs are one liners. People who draw FPGA/ASIC schematics without such libraries surely will take longer to implement the same than than someone will using HDLs. > > My schematics are like block > > diagrams, and alleviate the "need" that people have to turn HDL code into > > block diagrams to understand what it does. > > > This is the key area were schematic entry beats HDL entry hands down, > schematic entry is automatically self documenting. I would disagree. To repeat my self again, the tools are only as capable as the person using them. I have not seen many schematics drawn that well, IMO. The same goes with commenting HDL code, I see little of it actually commented well...but if someone is skilled at communicating in this regard, s/he can do a stupendous job. I include ASCII block diagrams and timing diagrams in my HDL. It helps me remember what it is I was trying to do, much less anyone else! > However, there are > tools to do this. > > Developers I have met can visualise the schematic just from reading the HDL. To me, that's kind of a "so what". I can certainly visualize the dataflow of HDL code, as I believe any good coder would be able to, but what good is that excpt for the immediate point in time? It doesn't help anyone else, and doesn't help me the next time I go to look at it. A block diagram of some kind, at least for the datapath, I believe is far more useful. > > I won't contend that if starting from scratch, HDLs will typically have an > > edge on time to completion, and the tools today are far better than a decade > > ago, but that does not diminish my point. IF someone had come out with a > > library that was publicly available, schematics would have been quite a bit > > more popular. > > > k.... ? > > This capability (having a large library of pre-built schematic modules) was > > a huge advantage I had for many years being an independant contractor. I > > was able to do designs that met performance goals of speed and resource > > utilization, as well as do them very quickly and cost effectively. > > But, basically, schematics for FPGAs, at least Xilinx FPGAs, are dead > today, IMO. > > > You prefered schematics, others have HDLs. Actually, no. I prefer the tool that gets the job done in the least amount of time, including making it work...which means making timing, and making the design fit. HDLs were not capable of getting the job done. Now, they are far more capable (for varied reasons), and therefore useful. Not only are the synthesizers better but IMO the biggest bonus to HDLs is that FPGAs are larger and faster. The same thing happened to high level software programming languages and CPUs/memory/disk drives. People don't need to be as skilled, in general, these days as they used to have to be to get a majority of the FPGA jobs done. This is a good thing for the industry IMO. > Like I said to Gary who > started the thread: Diagramatic description, design and management will > always have a place with humanity, we prefer pictures. New methods and > new tools have their place, but they don't always make old methods and > old tools redundant. Of course. > > But, without schematics, I could not have done the designs I did in the > > earlier Xilinx series parts (2k, 3k & 4k), as the synthesis tools were > > rather poor back then, and required far more work to get the results to come > > close to the speeds (and densities) achievable with schematics. Using an > > HDL simply as a netlister is not a very good use of the tool IMO...but now, > > that is the only way to get every Hz out, is to instantiate what you need to > > using HDL. Sigh. > > > FPGA/CPLD/PLDs will always implement binary constructions to provide the > desired application function(s). I don't see how that relates to my comment... > > There is not a thing wrong with schematics compared to HDLs, and schematics > > even have many advantages, but today, they just aren't popular. HDLs are. > > It has not a wit to do with schematics lack of ease or capabilities. > > > IMHO: HDLs will become hidden within purely diagramatic design tools, > much the same way software development is about module reuse and > UML/SSADM diagramatic tools now. Not the case back when I started. Possibly, but one of the arguments is that makes them tool specific and non-portable. This is an arguement that has been around for decades. Regards, AustinArticle: 84748
Yttrium wrote: > Hey, > > I want to make a very low frequency signal from a 100Mhz clk signal (since > the rest of the logic has to work on this frequency) and i thought using a > SRL16E as on-hot-signal shifter and then by placing them right i could > easily divide the 100Mhz clk to very low frequencies and then bring it in a > global clk net by using a clk buffer but when i do it i get the following > warning (it works so this is just because i want to know what they mean with > this warning): > > WARNING:Route - CLK Net:clk_pwm_OBUF > > may have excessive skew because 1 NON-CLK pins > > failed to route using a CLK template. > > > What do they mean with clk template? > This means that the global net (output of your BUFG or BUFGMUX) is routed to something other than the clock input of a slice or IOB. If you are using the buffered global signal to directly drive a LUT input (gate), or the D of a flip-flop, or the I of an OBUF you will get this warning which indicates that the route uses some potentially high-skew routing resources. A common cause for this is when routing a clock off the chip. On Virtex 2 and Spartan 3 you can use DDR output flip-flops to avoid the warning. My guess is that your signal is too slow for the routing to matter unless external signals are sampled on the same edge of the clock as they are produced on.Article: 84749
Frank, here is how to debug the setup. First of all, an opcode 4BFF7FE4 at address -4 (aka 0xfffffffc) as (gdb) x/x -4 0xfffffffc: 0x4bff7fe4 will resolve to the following instruction (gdb) x/i -4 0xfffffffc: b 0xffff7fe0 In other words, assuming your boot peripheral is correct, the processor will jump to 0xffff7fe0. That's where you need to map the .boot0 section or more correctly _boot0. Now, to see what's happening you should bring the DEBUG_HALT signal of the PPC to a user IO pin, for example one of the push buttons on the board. The DEBUG_HALT signal allows stopping the processor, i.e. keep it at the reset vector after a reset or after loading the FPGA bitstream. Assert the DEBUG_HALT signal and load the bitstream. Connect with XMD. Deassert DEBUG_HALT. The PPC is still stopped because of the debugger. Single-step the processor. By following the PC you will be able to see what the PPC is doing. If something in your setup is wrong you will most likely end up at address 0x????0700, the exception vector address for an invalid instruction exception. To monitor the bus transactions instantiate ChipScope (BTW, instead of bringing the DEBUGH_HALT signal above to a user IO pin you could hook it up to a Virtual IO port) and trigger on the PLB request signal. If you try to minimize the boot code, i.e. not use a BRAM at the reset vector, you might want to have a look at application note XAPP571 (http://www.xilinx.com/bvdocs/appnotes/xapp571.pdf). - Peter Frank van Eijkelenburg wrote: > I have made a powerpc system with a user peripheral connected to the plb > bus. The user peripheral has an address range from 0xffffff00 - 0xffffffff. > At startup the powerpc starts executing from 0xfffffffc, so my peripheral is > accessed at startup. In case of a plb bus read action, it always returns > "4BFF7FE4" which is a jump to my boot0 section laid in bram. In the > linkerfile I forced the boot0 section to a specified address, so the jump > should be correct anytime. However, the system is not starting (no output > from my uart port). Should the described method work, or do I forget > something? If it should work, what could be wrong (I already tried to return > "E47FFF4B" in case the byte order may be incorrect, but it gave the same > result). > > TIA, > Frank > >
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