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
wanwan wrote: > I'm looking into buying the fpga and/or cpld starter kits. I was > wondering if the logic chips can be taken out of the development board > after they are programmed. If you look at the DigiLab Picomax from El Camino (see http://www.elcamino.de/Products/prod dpicomaxe.html) you will see that it uses a PLCC socket. Thus, with the right tool (a small teaspoon or a horribly expensive PLCC removal thingie) you should be able to remove the CPLD from the board. I don't know of any other eval boards where the device can then be taken off the board. Best regards, BenArticle: 113076
MicroBlaze will utilize the byte-write capability of the new BRAMs in S3A for caches and for local memory. Göran Bilski "Antti Lukats" <antti@openchip.org> wrote in message news:el4idi$l3b$1@online.de... > "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> > schrieb im Newsbeitrag > news:1165347583.878327.14740@80g2000cwy.googlegroups.com... >> Antti Lukats wrote: >>> "Antti" <Antti.Lukats@xilant.com> schrieb im Newsbeitrag >>> news:1165318595.041905.299450@80g2000cwy.googlegroups.com... >>> > Antti schrieb: >>> > >> [... snip ...] >>> > and, I really really wonder how Xilinx has managed to get >>> > a MicroBlaze to fit into 75% of Spartan-3A !!! >>> >>> UUUUUUUPS my BAD! >>> >>> the 75% LUT useage of Microblaze SoC in S3A-50 is truly correct >>> >>> test design for S3-50 shows (Microblaze 4, LMB RAM, OPB UART) >>> >>> Number of Slice Flip Flops: 335 out of 1,536 21% >>> Number of 4 input LUTs: 842 out of 1,536 54% >>> >>> S3A-50 has 1408 LUTs so it means 59,8 % of LUT's nt 75! >>> >>> sorry for my bad statement, I have had recently trouble fitting >>> MB systems into S3e-100 so I somehow assumed the 75% of >>> s3a-50 just cant be possible. >>> >>> Antti >> >> While I haven't tried this myself, I expect that the difference is the >> enhanced 18K block RAMs on Spartan-3A FPGAs. >> >> Essentially, all Spartan-3, Spartan-3E, and Spartan-3A FPGAs have the >> same 18 Kbit block RAM. However, Spartan-3A FPGAs add byte-level write >> enables for the 1Kx18 and the 512x36 organizations. See pages 153-154 >> in the Spartan-3 Generation User Guide. >> http://www.xilinx.com/bvdocs/userguides/ug331.pdf >> >> The MicroBlaze controller uses byte-level write operations. These are >> emulated in Spartan-3 and Spartan-3E FPGAs with additional logic. On >> Spartan-3 FPGAs, the entire design is simplified and more optimal. >> >> --------------------------------- >> Steven K. Knapp >> Applications Manager, Xilinx Inc. >> General Products Division >> Spartan-3/-3E FPGAs >> http://www.xilinx.com/spartan3e >> E-mail: steve.knapp@xilinx.com >> --------------------------------- >> The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. >> > Hi Steve, > > you are nottop at MicroBlaze tech details - the byte enables on BRAMs > are NEVER emulated by the current EDK tools, thats why the minimum > BRAM size for S-3 s 8K, all BRAM blocks are required to have minimum > 4 BRAMs so each bytelane has its own BRAM and no emulation is necessary > > surprisingle the open-source OpenFire MicroBlaze clone DOES support byte > writes to single BRAM, because of that OpenFire is useable with S3A with > current EDK tool versions that do not support yet S3A byte write feature - > this > prevents EDK 8.2 to be used to target S3A-50 because it has only 3 BRAMs > > not to mention that DATA2MEM doesnt support S3A at all, here again the > OpenFire includes methods to retrive the BRAM locate info from .LL files > post implementation so using that method and custom bitfile patch program > a MicroBlaze design in S3A would be possible even today - even before > Xilinx releases full support for S3A in their tools. > > Antti > > >Article: 113077
Peter, You can always try to look at it from the other side: Altera might be spending their money by taking the prices from their devices down. As for Xilinx and Actel, well, they will probably be more expensive? And you didn't mention Lattice nor Quicklogic. They must be the cheapest as they don't advertise... :o)) Luc On 5 Dec 2006 14:05:00 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >Antti, regarding Electronica (the biggest electronic component show in >the world): > >the Actel booth was indeed surprisingly large and flat, and fairly >empty. >The Xilinx booth was more vertical and more crowded, also more crowded >with customers and with serious conferences with customers. So we are >quite happy (I was there). >I am however amazed that Actel finds the money for such a large number >of square meters... >Altera, by the way, was hiding in a tiny cubicle next to some >automotive guys, in a different hall. >Everybody has different ideas about spending effort and money at >shows... >Peter Alfke, Xilinx > >On Dec 5, 11:31 am, "Antti Lukats" <a...@openchip.org> wrote: >> "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.kn...@xilinx.com> >> schrieb im Newsbeitragnews:1165346298.454531.194840@16g2000cwy.googlegroups.com... >> >> > Antti wrote: >> >> Antti schrieb: >> >> >> > as Xilinx PR ES samples are available, and tools support for S3A also, >> >> >> as usual - the documentation is not complete :( >> >> > [... snip ...] >> >> >> Antti >> >> > Hi Antti, >> >> > There was about a 2-3 hour span last night when the Spartan-3A >> > technical documentation wasn't yet available on the Xilinx web site. >> > The nearly 1,000 pages of documentation all went live about 11 PM >> > Pacific time on 4-DEC-2006.[..] >> no problems, I actually found all i was looking for, but I had already >> posted before >> >> > You may also be interested in the associated article discussing how to >> > use the Device DNA. >> >> > How to implement high-security in low-cost FPGAs >> >http://www.pldesignline.com/howto/showArticle.jhtml?articleID=196601422 >> >> > --------------------------------- >> > Steven K. Knapp >> > Applications Manager, Xilinx Inc. >> > General Products Division >> > Spartan-3/-3E FPGAs >> >http://www.xilinx.com/spartan3e >> > E-mail: steve.kn...@xilinx.com >> > --------------------------------- >> > The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Steven - you arent working for Altera? >> >> I clicked on the link to plddesignline and got a big flashing Altera >> Stratix-III AD flyer !! >> ok, well its beyound your control, but was amusing. >> similarly as it was amysing to come to Xilinx booth at Electronica2006, all >> it was to >> see was a big Actel Logo as their booth was just befor Xilinx and way more >> visible. >> >> AnttiArticle: 113078
G=F6ran Bilski schrieb: > MicroBlaze will utilize the byte-write capability of the new BRAMs in S3A > for caches and for local memory. > > G=F6ran Bilski > sure - in EDK 9.1 and MB 6.0 with the current EDK 8.2 I asssume the LMB memory for S3A MB would have to be handcrafted AnttiArticle: 113079
Hi, I see it. Thanks so much, your guys. Regards, ChengArticle: 113080
Ben Twijnstra wrote: > wanwan wrote: > > >>I'm looking into buying the fpga and/or cpld starter kits. I was >>wondering if the logic chips can be taken out of the development board >>after they are programmed. > > > If you look at the DigiLab Picomax from El Camino (see > http://www.elcamino.de/Products/prod dpicomaxe.html) you will see that it > uses a PLCC socket. Thus, with the right tool (a small teaspoon or a > horribly expensive PLCC removal thingie) you should be able to remove the > CPLD from the board. > > I don't know of any other eval boards where the device can then be taken off > the board. The Atmel ATF15xx-DK3 has daughter cards, with ZIF sockets [ so you can leave the teaspoon in your coffee :) ] http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3868 The different ZIF's support PLCC44, TQFP44, TQFP100 etc Kits are on Digikey for $112, and IIRC that gives 1 x TQFP44 Zif, and the Parallel Port - 10W ISP cable + SW. ( these support the new ATF1502BE / ATF1504ASL ) These starter kits do not support vector Testing, for that you need a device programmer. The Zif sockets are $$$ and rare, so we are making an adaptor PCB that morphs a -DK3 ZIF into a Programmer ZIF. -jgArticle: 113081
Microblaze v5.00.b is using the S3A's byte-enables for the caches. I need to check what the local memory does for Spartan3A. Göran "Antti" <Antti.Lukats@xilant.com> wrote in message news:1165392839.645440.267760@f1g2000cwa.googlegroups.com... Göran Bilski schrieb: > MicroBlaze will utilize the byte-write capability of the new BRAMs in S3A > for caches and for local memory. > > Göran Bilski > sure - in EDK 9.1 and MB 6.0 with the current EDK 8.2 I asssume the LMB memory for S3A MB would have to be handcrafted AnttiArticle: 113082
Apart from the fact, that Xilinx-based starterkits appear to be cheaper, I recommend to go with a e.g. S3D kit which is here around 134,- and has really more than necessary to start with FPGA. There is also no need to "take out" the FPGA to place in another system. ou can drop the entire EVAL-board into a prototype system :-) (not really kidding, I am doing this currently) But If you intend to stay with Altera, you should have a look at the cycloneII board named "HPE AC II mini" from "Gleichmann Research" in Austria. It starts from =80299,- (avnet-price) and is ready for large uc-based designes especially with the bundled LEON 32bit-soft core. It has SRAM Socket and a large and fast FPGA, so this board is hard to exceed with start up design. (Spartan is much smaller)Article: 113083
G=F6ran Bilski schrieb:
> Microblaze v5.00.b is using the S3A's byte-enables for the caches.
> I need to check what the local memory does for Spartan3A.
>
> G=F6ran
>
Hi G=F6ran,
I have been really disappointed that Xilinx claims Virtex-5 and
Spartan-3A software tool support being available today, while the
latest Data2mem does not support Spartan3A at all, and only supports
LX50 from the Virtex-5
based on that I also assumed (without checking) that EDK 8.2 does not
yet support S3A RAMB16BWE base block ram elaboration, but here I was
wrong - it does, here is utilization report targetting S3-50A 2KB LMB
RAM (must use Byte write enables!) and OPB UART
Total Number 4 input LUTs: 1,195 out of 1,408 84%
Number used as logic: 848
Number used as a route-thru: 5
Number used for Dual Port RAMs: 256
(Two LUTs used per Dual Port RAM)
Number used as Shift registers: 86
Number of bonded IOBs: 4 out of 108 3%
IOB Flip Flops: 2
Number of GCLKs: 1 out of 24 4%
Number of DCMs: 1 out of 2 50%
Number of RAMB16BWEs: 1 out of 3 33%
the LUT utilization is is 84% not 75% Xilinx claims, but maybe MB ver
6=2E0 brings some more size reduction, this report is with MB v 4.00.b
Antti who still hopes to see ISE 8.2 SP4 released this year with fixed
DATA2MEM supporting V5 and S3A
Article: 113084Ed, What are you doing? Do not try to change anything of the MPMC2 core! If there is no connection to NPI port, just it coment it in MHS: # BUS_INTERFACE MPMC2_PIM_4 = npi I created NPI peripherals with single write (64bits), 4 words (2x 64bits) cacheline write and 64 words write (the fastest xfer). The declaration of NPI port should look like in MPMC2 MPD. The NPI port is very handy bus to connect peripherals that require fast and simple DMA access - huraa for the Xilinx MPMC2 team. Cheers, Guru ed_h wrote: > HI Antti, > > First and foremost, thank you for the reply! > > I tried your suggestion at first, but when I go to build the netlist > in EDK after connecting the ports using your suggested method, I get > this error: > > ERROR:MDT - mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t > (mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t_0) - > C:\projects\test_single_npi\system.mhs line 235 - transparent bus > interface > connector 'npi_4' is only referenced once! > > That is why I started editing the MPD and started removing the > transparent bus parameters and the like. I should have been a little > clearer in my initial post, but just let me blame that on my > inexperience with EDK :) . > > When I remove the transparent bus types from the MPD, I get this > warning when I generate the block diagram : > > WARNING:MDT - Bridge mpmc2_ddr_idponn_100mhz_x16_mt46v16m16_6t_0 is > connected to > more than two busses > WARNING:MDT - This condition is not handled by layout algorithm > > Now I am starting to wonder if "layout" means layout of the block > diagram.....for whatever stupid reason, I associated "layout" with > "place and route" since I used to "layout" ASICs for a living a long, > long time ago :)! If all this means is that my block diagram is > incorrect (which it is after I remove the transparent bus), I can most > definitely live with that... > > Again, many thanks! I'll be sure to post the solution to my > problem should I figure it out :)! > > Ed > > > > > > Antti Lukats wrote: > > "ed_h" <ehenciak@gmail.com> schrieb im Newsbeitrag > > news:1165351478.866080.261170@80g2000cwy.googlegroups.com... > > > Hi all, > > > > > > Has anyone ever had success routing an NPI port of the MPMC2 > > > controller to an External Port of a PPC based system component in EDK > > > > 1) dont change the MPD > > 2) in EDK set port visible filter "all" > > you should see all ports of all cores, and you can make any of then exertnal > > > > AnttiArticle: 113085
On Tue, 5 Dec 2006 16:51:24 +0000 (UTC), Andreas Ehliar <ehliar@isy.liu.se> wrote: >I'm just wondering if anyone here has seen the same problem I'm >running into. I have a design where I'm playing around a bit with >RLOC. The layout of the design should be something like this: > > > AAAA BBBB > AAAA BBBB > AAAA BBBB > AAAA BBBB > > > CCCC DDDD > CCCC DDDD > CCCC DDDD > CCCC DDDD > >However, when I look in the floorplanner, the modules look >something like the following after place & route: > > > AAAA BBBBB > A AAAA BBBBB > A AA BBBB > AAAA BB > > D > CCCC DDD > CCCCC DDDD > CCC C DD DD > CCC DDDD > >The funny thing is that everything is still one giant RPM according >to the floorplanner. I don't think that I've made a mistake in the >RLOC placement since I should get the same shape for all of the >module instantiations in that case if I've understood things >correctly. In addition to the documented weirdnesses as described by Ray Andraka, the floorplanner certainly used to have problems with hierarchical RLOCs. I raised several Webcases regarding them, and was told either yes they are bugs; or yes they are bugs, scheduled to be fixed in ISE 7.1. See (from circa Jan 2005, a thread called "ISE Toolflow : hardmacro, incremental or modular") http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/692df66024ec546e/a07c273f4568ddc8?tvc=1&q=comp.arch.fpga+floorplanner+Brian+Drummond#a07c273f4568ddc8 http://www.shapes.demon.co.uk/files/crashme.zip contains a demo using RLOC and RLOC_ORIGIN in which only one of eight RPMs was correctly placed in 6.1sp3 floorplanner. (Admittedly two of them had illegal placements for some of the reasons Ray mentioned) There were at least two tool bugs then; I wonder if they were fixed buit came back, or if new ones have appeared in this area. I gave up then, and haven't had time (or an excuse) to try the test case on newer tools. I'm going to try this test case on 7.1 today; I don't plan to install 8.x until the current project is complete. >So I'm wondering if anyone has an idea of what could be wrong. I've >had an issue with ISE 8.2 (SP3) where some RLOCs just disappeared >if I instantiated the same module several times so I've gone back >to ISE 8.1 (SP3). > >Are the tools allowed to move individual parts of an RPM? If so, >what can I do to avoid this issue? At one time, they certainly did things they weren't supposed to. Either all these issues have been fixed, or you will have to find out how to work around the current crop of bugs. - BrianArticle: 113086
What I really need to do is to program a chip to have a logic circuit, so that I can use it elsewhere. I am considering this approach rather than building with an IC circuit. Can anyone give me suggestions please?Article: 113087
wanwan schrieb: > What I really need to do is to program a chip to have a logic circuit, > so that I can use it elsewhere. I am considering this approach rather > than building with an IC circuit. Can anyone give me suggestions > please? http://www.oho-elektronik.de/index.php?c=1&s=product1 plugin DIP modules with CPLD or FPGA on itArticle: 113088
Shela wrote: > I realize that the LCD i/o is connected to the GPIO so is there any way > i can use the on board LCD? Yes, but it requires some work. There is a controller chip on the LCD. I don't know which one it is on the ML403, but most of the time it's something like the HD44780 (just google for the datasheet). You'll have to look in the ML403 User Guide, the kind of LCD controller should be mentioned there. After power-up, you have to initialize the LCD first. The neccessary initialization sequence is shown in the datasheet. Basically that means you have to toggle the IOs that connect to the LCD in a specific way with specific pauses in between, i.e. you need a little state machine that performs the startup sequence. After that you again need to send a specific sequence for every character you want to display (i.e. send a "print charcter"-command to the LCD). The alternative is to do it in software, e.g. include a PowerPC or MicroBlaze in the design and write a C-program to do it. There are probably example designs for the ML403 that do this. cu, Sean -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 113089
If the logic circuit is not too complex, you can concider any CPLD ranging from 32 macrocells to 1000 MC (in some cases). Another approach would be to use Altera's MaxII or Lattice's MachXO. Unfortunately you will have to deal with BGA packages for the larger devices and high IO count. If I'm not mistaken both MaxII and MachXO have a TQFP100 package for the whole range. The last approach is a non volatile FPGA. Only Lattice's XP and Actel's ProASIC3 provide a practical solution. The functions you can implement in these devices can be very big. All devices mentioned are in system programmable. Regards, Luc On 6 Dec 2006 04:47:59 -0800, "wanwan" <ericwan78@yahoo.com> wrote: >What I really need to do is to program a chip to have a logic circuit, >so that I can use it elsewhere. I am considering this approach rather >than building with an IC circuit. Can anyone give me suggestions >please?Article: 113090
Brian Drummond wrote: > See (from circa Jan 2005, a thread called "ISE Toolflow : hardmacro, > incremental or modular") > > http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/692df66024ec546e/a07c273f4568ddc8?tvc=1&q=comp.arch.fpga+floorplanner+Brian+Drummond#a07c273f4568ddc8 > > http://www.shapes.demon.co.uk/files/crashme.zip contains a demo using > RLOC and RLOC_ORIGIN in which only one of eight RPMs was correctly > placed in 6.1sp3 floorplanner. (Admittedly two of them had illegal > placements for some of the reasons Ray mentioned) > > There were at least two tool bugs then; I wonder if they were fixed buit > came back, or if new ones have appeared in this area. I gave up then, > and haven't had time (or an excuse) to try the test case on newer tools. > > I'm going to try this test case on 7.1 today; I don't plan to install > 8.x until the current project is complete. > > > > At one time, they certainly did things they weren't supposed to. Either > all these issues have been fixed, or you will have to find out how to > work around the current crop of bugs. > > - Brian > The floorplanner bugs are still there, which makes it hard to use as a placer. Instead, I have been placing the RPMs in a UCF and using floorplanner to view the placements. It has been this way for a while with Xilinx promising to fix it next release. I'm not holding my breath. There is another reason the RPMs will do this that is related to the mapper. The mapper has a bug that does not account for the columns correctly when an RPM straddles a non-LUT column (DSP48, BRAM or BRAM/MULT18 column). The net result is it winds up causing the same problem I described in my earlier post even if you have the RPM constructed properly. It is a real problem for RPMs in a V4SX family part since it practically limits the size of your RPM to 4 slice columns.Article: 113091
wanwan wrote: > What I really need to do is to program a chip to have a logic circuit, > so that I can use it elsewhere. I am considering this approach rather > than building with an IC circuit. Can anyone give me suggestions > please? If you don't mind using a Xilinx device, check out XESS website (http://www.xess.com) their boards can be placed in circuit and last I knew, worked with Xilinx's web pack distribution. I've seen these integrated in low volume commercial products and prototypes.Article: 113092
Hi! I have two desings here, both use the same generic processor interface which includes a DLL. The input pin for the DLL is constrained in the ucf-File: NET "pciclk" TNM_NET = "clk"; TIMESPEC "TS_clk" = PERIOD "clk" 30.3 ns HIGH 50 %; With ISE 8.1.02i this worked fine, the result looked something like this: -------------------------------------------------------------------- TS_clk = PERIOD TIMEGRP "clk"| 30.300ns | 5.199ns | 1 | 25.101ns | 0 30.3 ns HIGH 50% | | | | | -------------------------------------------------------------------- Now I upgraded to ISE 8.2.03i and the constraint is ignored: -------------------------------------------------------------------- TS_clk = PERIOD TIMEGRP "clk"| N/A | N/A | N/A | N/A | N/A 30.3 ns HIGH 50% | | | | | -------------------------------------------------------------------- No changes in the design were made. It is used on a Spartan3 and runs well in spite of the ignored constraint. I've found, read and (I think) understood http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=6905 but I don't get the stated error and I think I meet the conditions: "clk" is only used in these two lines in the ucf "pciclk" is only used here and in BEFORE/AFTER constraints. I also found /Xilinx/doc/usenglish/books/docs/cgd/cgd.pdf but as I didn't understand it very well and what I did didn't tell me anything new. Any hints what goes wrong here? - PhilipArticle: 113093
phoenix wrote: > When I make the readback on the Spartan II concerning a configuration's > bitstream which changes the state of some flip flop, the returned > bitstream is not the current one but starting bitstream whitout changes. How are you reading the bitstream? Do you use iMPACT? How do you know the bitstream hasn't changed? Is it your own comparison software or iMPACT "verify"? If you use "verify" in iMPACT you should realize that the bitstream is masked with the .msk file generated along with the .bit file in your project. Once masked, the resulting verify operation will not compare the bits corresponding to the changing state. It only uses bits such as LUT functions and routing that do not change once the design starts running.Article: 113094
Alright....here we go. I was working with an EDK 8.2 project that had both an MDM module and ChipScope connected. ChipScope was working fine. I then tried to go debug some software and started XMD. It failed to connect. Since this was just an EDK 7.1 ported project (that was known to work) I started to look in the Answer Database for clues. It ends up there was an Answer that said to update the mdm core to 2.01.a (it had a link) and change the '.opt' file associated with the XMD (that opt file is in the /.../etc folder). Ok, my mdm core was 2.00.a so I thought at least I am on the right track since I am upgrading. So I rebuild the project. Lo and behold, XMD connects and I am able to debug software. After figuring out software I wanted to start ChipScope and look at some stuff. Unfortunately, ChipScope no longer detected any cores. WTF?!? It was working fine!! So I end up setting the mdm core back to 2.00.a and rebuilding. After that, ChipScope worked fine as before. XMD connects no problem. However, the debugger does NOT work now. It opened and I hit 'Run'. It started, but never hit any breakpoints. And it SHOULD have. So basically, I cannot get to a point where ChipScope and the mdm work together. I looked in the Answer Database again, but could not find anything that would address both these issues. In older software versions there was no problem with this as long as you remembered to tell ChipScope that an mdm module was in the system. This parameter is now 'Auto Computed' in the EDK 8.2 (which I can not stand compared to 7.1!). In the process of all of this I installed the latest Service Pack, so I am as updated as possible. My team is getting VERY TIRED and FRUSTRATED using these Xilinx tools that seem to break things left and right when there is an upgrade. Why in the hell was the EDK basically redesigned when it just be nicer to have software that works? Seriously, I could see people jumping ship on Xilinx products with all the pain and hassle of getting known good projects back up and running whenever there is a software upgrade. I am using an ML401 eval board that uses the Virtex4 LX25 FPGA. Thanks.Article: 113095
Hi, Is it possible to initiate 32 bit burst transactions on IPIF interface in Xilinx PLB-IPIF ? I am currently using 64 bit burst transactions on IPIF interface. If anybody has worked or know such design then please let me know. Thank You AshishArticle: 113096
motty schrieb: > Alright....here we go. > > I was working with an EDK 8.2 project that had both an MDM module and > ChipScope connected. ChipScope was working fine. I then tried to go > debug some software and started XMD. It failed to connect. Since this > was just an EDK 7.1 ported project (that was known to work) I started > to look in the Answer Database for clues. It ends up there was an > Answer that said to update the mdm core to 2.01.a (it had a link) and > change the '.opt' file associated with the XMD (that opt file is in the > /.../etc folder). Ok, my mdm core was 2.00.a so I thought at least I > am on the right track since I am upgrading. So I rebuild the project. > Lo and behold, XMD connects and I am able to debug software. > > After figuring out software I wanted to start ChipScope and look at > some stuff. Unfortunately, ChipScope no longer detected any cores. > WTF?!? It was working fine!! So I end up setting the mdm core back to > 2.00.a and rebuilding. After that, ChipScope worked fine as before. > XMD connects no problem. However, the debugger does NOT work now. It > opened and I hit 'Run'. It started, but never hit any breakpoints. > And it SHOULD have. So basically, I cannot get to a point where > ChipScope and the mdm work together. I looked in the Answer Database > again, but could not find anything that would address both these > issues. > > In older software versions there was no problem with this as long as > you remembered to tell ChipScope that an mdm module was in the system. > This parameter is now 'Auto Computed' in the EDK 8.2 (which I can not > stand compared to 7.1!). In the process of all of this I installed the > latest Service Pack, so I am as updated as possible. My team is > getting VERY TIRED and FRUSTRATED using these Xilinx tools that seem to > break things left and right when there is an upgrade. Why in the hell > was the EDK basically redesigned when it just be nicer to have software > that works? Seriously, I could see people jumping ship on Xilinx > products with all the pain and hassle of getting known good projects > back up and running whenever there is a software upgrade. > > I am using an ML401 eval board that uses the Virtex4 LX25 FPGA. > > Thanks. if you have LX25-ES then you can not use chipscope and MDM due to the silicon errata, as only USER1 is working so MDM and chipscope just can not co-exist in LX25-ES silicon Antti PS on your comments about software quality I stand your side fully. FRUSTRATIONArticle: 113097
Hi, I need to phase shift (180 deg) an output clock(100MHz) , I have an option of using DCM and with this it is possible. Is there any alternative way of implementing clock shift by using any ready component to implement phase shift.(Xilinx Virtex 4 FPGA). I wish to avoid using a DCM resource. I have used IDELAY component while phase shifting an incoming clock but need similar alternative for o/p clock. Any suggestions /comments welcome. Thank you AshishArticle: 113098
Gabor ha scritto: > phoenix wrote: > > When I make the readback on the Spartan II concerning a configuration's > > bitstream which changes the state of some flip flop, the returned > > bitstream is not the current one but starting bitstream whitout changes. > > How are you reading the bitstream? Do you use iMPACT? How > do you know the bitstream hasn't changed? Is it your own comparison > software or iMPACT "verify"? > > If you use "verify" in iMPACT you should realize that the bitstream is > masked with the .msk file generated along with the .bit file in your > project. Once masked, the resulting verify operation will not compare > the bits corresponding to the changing state. It only uses bits such > as LUT functions and routing that do not change once the design > starts running. Dear Gabor thank you for the info. I do not use "IMPACT" but I have implemented a class library in java for the "readback" using the JTAG TAP . When I read bitstream i obtain the starting bitstream not the actually.Article: 113099
Ashish wrote: > Hi, > > I need to phase shift (180 deg) an output clock(100MHz) , I have an > option of using DCM and with this it is possible. > > Is there any alternative way of implementing clock shift by using any > ready component to implement phase shift.(Xilinx Virtex 4 FPGA). I wish > to avoid using a DCM resource. > > I have used IDELAY component while phase shifting an incoming clock but > need similar alternative for o/p clock. > > Any suggestions /comments welcome. > > Thank you > Ashish > > Use an inverter?
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