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 everyone, I'm trying to understand how the frame addresses have to be decoded for a Virtex-4 FPGA from Xilinx. So far I could find documentation about the configuration for VI and VII FPGAs, but there seem to be small modifications between these models frame addresses and the new Virtex-4. Has anyone already tried to understand frame addresses in Virtex-4? Thanks BertrandArticle: 96901
On Mon, 13 Feb 2006 10:52:11 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >"Mike Harrison" <mike@whitewing.co.uk> wrote in message >news:tin0v1hh1b8c01eoi9tif20elqsh3treio@4ax.com... >> >> Here's another way : >> The ground is the nearest to the solder side of the inner planes so it's >> possible to dremel down to >> it & add more grounds.. >> http://www.redremote.co.uk/electricstuff/ektapr61.jpg >> >Mike, >You butcher! VG! >I wonder if there's a lesson here for the prototype board product guys. >After all, these boards are often bodged up for proof-of-concept projects. >Put a ring of exposed ground all the way around the edge of the board to >help SI design. Carefully stiched to the gnd plane, of course. What about >it, Mr. Adair? One neat feature of his Raggedstone 1 board is the provision of solder-bridges to reassign IOs to ground.Article: 96902
Oh we have done better than that on some of the RF boards we have done for customers. How about exposed earth bond(0V) both side and mounting screw holes every 20mm. On a simpler note you might what we have done on Hollybush1 but you will have to wait until DATE to see it. John Adair Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan-3 Development Board. http://www.enterpoint.co.uk "Symon" <symon_brewer@hotmail.com> wrote in message news:43f06463$0$15791$14726298@news.sunsite.dk... > "Mike Harrison" <mike@whitewing.co.uk> wrote in message > news:tin0v1hh1b8c01eoi9tif20elqsh3treio@4ax.com... >> >> Here's another way : >> The ground is the nearest to the solder side of the inner planes so it's >> possible to dremel down to >> it & add more grounds.. >> http://www.redremote.co.uk/electricstuff/ektapr61.jpg >> > Mike, > You butcher! VG! > I wonder if there's a lesson here for the prototype board product guys. > After all, these boards are often bodged up for proof-of-concept projects. > Put a ring of exposed ground all the way around the edge of the board to > help SI design. Carefully stiched to the gnd plane, of course. What about > it, Mr. Adair? > Cheers, Syms. >Article: 96903
this week Embedded in Nurnberg, Halle 12, Standnummer: 12-338 (TQC): FPGA module with MicroBlaze uClinux on display, not much to see but it has some MicroWindows demos loaded Antti PS I will be around that stand, hm 1500 on tuesday if someone wants to say helloArticle: 96904
Antti <Antti.Lukats@xilant.com> wrote: > this week Embedded in Nurnberg, Halle 12, Standnummer: 12-338 (TQC): > FPGA module with MicroBlaze uClinux on display, not much to see but > it has some MicroWindows demos loaded > Antti > PS I will be around that stand, hm 1500 on tuesday if someone wants to > say hello What a pitty. I will be there wednesday... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 96905
I *might* be around on wednesday too, so just drop by at the same time, if I am there Im there AnttiArticle: 96906
"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote in message news:1139841784.24768.0@doris.uk.clara.net... > Oh we have done better than that on some of the RF boards we have done for > customers. How about exposed earth bond(0V) both side and mounting screw > holes every 20mm. > Hi John, Trouble is, _every_ board with a modern FPGA on it is an 'RF' board these days!! Cheers, Syms.Article: 96907
Jerome wrote: > NO NO , i'm NOT trying to crack anything > I just want to make USB devpt (using libusb) and i need an usb analyzer > I'm sure it is feasible with a $200 FPGA which is 1/3 price of the cheapest > USB analyser Have you ruled out software analyzers? There's something that plugs in partway through the windows USB stuff and monitors traffic between the driver and the device...Article: 96908
Allan Herriman wrote: > Please bear in mind that most comms interfaces (e.g. Ethernet) are > synchronous in nature (at least at the physical layer). One has real > time requirements to meet. > Synchronous design makes a lot of sense for a hardware router or > switch, etc. (As it does for the products we design here, but I won't > bore you with the details.) Hmm. Wasn't the whole point of the DRACO microprocessor that it was actually designed for, and used in, telecoms systems? The whole idea being that an asynchronous design was used because of the requirement for good EMC. Why would such a design not also "make a lot of sense"? MartinArticle: 96909
rickman wrote: > Likewise, I don't see any reason to belive that async clocked logic > design has significant advantages over standard sync clocked logic > design for most applications. Proponents of async state that async designs automatically adjust performance and power consumption across the entire range of environmentals (temp, voltage, thermal gradients, etc) as long as the underlying hardware is still performing correctly. They state that this reduces hardware costs by allowing higher variances in temp, voltage, thermal gradient, etc while extending the operating range past what is achievable with traditional sync design at lower costs. This is clearly useful in a wide range of applications from hand held battery operated devices, to harsh industrial/automotive environments. By removing the global clock, they also obtain EMC benifits that are critical to many applications, which also lower shielding, packaging, filtering and other EMC mitigation costs. That tools like the Phased Logic conversion utilities, semiautomatically take existing designs, convert them to async, and achieve part or all of these benifits. You state that YOU can do better (IE lower costs and improve performance for the same applications) by adding hardware and extensive testing to determine the correct margins so that the system can automatically adjust clock speeds and other factors to obtain the same extended operation ranges, at the same or better performance, and the same or lower closts. You fail to explain just how you can do this -- at the same or better performance, at a lower cost. You fail to offer a similar conversion tool which takes existing designs and lowers it's power, while extending it's operating range and reducing EMC requirements without additional hardware costs or allowing equivalent lower cost components, packaging, and other environmental controls. Until you can enlighten the world about your claims, you are just insulting a lot of people which believe they are doing genuine state of the art research and product development to better man kind and our industry.Article: 96910
hello the ise7.1 had the mig1.4 for memory interface generator does it work on the ise 8.1? if not is there any newer version for ise 8.1? thanks guyArticle: 96911
I have been waiting to get the spartan 3e starter kit from xilinx for awhile now, but it doesn't seem to be out yet. Does anyone know if they are still look at releasing it this month as they mention on their website?Article: 96912
Hi, I'm trying to implement rocketio on xilinx fpga. Is there a way to simulate it using modelsim XE. I know for the PE, SE version its using smartmodels or generating libraries. Also is there any basic programs using rocketio, architect (wizard can't simulate, core generator can't compile libraries for modelsim, and the program that came with the eval board uses multiple buses, memory and the PPC). RobArticle: 96913
On Mon, 13 Feb 2006 15:38:29 +0000, Martin Ellis <me_ncl@hotmail.com> wrote: >Allan Herriman wrote: >> Please bear in mind that most comms interfaces (e.g. Ethernet) are >> synchronous in nature (at least at the physical layer). One has real >> time requirements to meet. >> Synchronous design makes a lot of sense for a hardware router or >> switch, etc. (As it does for the products we design here, but I won't >> bore you with the details.) > >Hmm. Wasn't the whole point of the DRACO microprocessor that it was >actually designed for, and used in, telecoms systems? The whole idea being >that an asynchronous design was used because of the requirement for good >EMC. Is DRACO popular in commercial designs? Google only seems to find academic links. There are better ways to "avoid" EMC, BTW, but they are off topic for this thread. >Why would such a design not also "make a lot of sense"? The point I was making is that most comms interfaces are fundamentally synchronous at their lowest levels. Consider a popular interface like 100Base-Tx Ethernet. This pushes out a byte of data every 80ns, and this timing must come from an accurate clock. Asynchronous logic has no place here. Some parts (e.g. control plane in a Ethernet switch) are "best effort" rather than "exact timing" in nature, and asynchronous logic might be feasible. This type of function is often performed in a microprocessor. Regards, AllanArticle: 96914
I am trying to create a MicroBlaze system with 8K instruction memory and 16K data memory. So I use includes a 8K Bram in my system and connected to the ilmb bus and a 16k Bram connected to the dlmb bus and give them non-overlapped address range. When I tried to debug my program by connecting it to the virtual system, it gives me the error " Vpconnect mb i, dlmb address maps should match VP target failed. I understand that ilmb dlmb actually are using the same lmb_bram_if_cntlr and LMB bus. Different address should be the only way to tell the difference. But how can I tell where should the data be stored in my high level C program. It seems that the MicroBlaze will automatically store data after the instruction section. Similarly, if I want to use a shared memory place for two MicroBlaze, where can I give the information in the high level C program where the shared memory is. Thanks a lot for your reply.Article: 96915
On 12 Feb 2006 23:16:08 -0800, "Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote: > Hello folks. > > I would like to let you know that I have made a new release of >PacoBlaze (2.0b). Some bugs noticed by users were fixed and the modules >were modified a bit to ease implementation, as suggested by a friend. >As usual, you can find the files in the 'PacoBlaze' section of my web >site, http://bleyer.org/. > > Wow, it is almost two years since I wrote the first version of >PacoBlaze. Thanks for all the people who have found the module and the >Java assembler useful (in ways that I never anticipated!) and have sent >encouraging words despite the fact that my replies have been terribly >slow ;o) Thanks! Do you have a detailed description of the actual bugs fixed? Regards, AllanArticle: 96916
"fpga" <hy34@njit.edu> schrieb im Newsbeitrag news:1139862868.498078.295090@f14g2000cwb.googlegroups.com... >I am trying to create a MicroBlaze system with 8K instruction memory > and 16K data memory. So I use includes a 8K Bram in my system and > connected to the ilmb bus and a 16k Bram connected to the dlmb bus and > give them non-overlapped address range. When I tried to debug my > program by connecting it to the virtual system, it gives me the error > " > Vpconnect mb > i, dlmb address maps should match > VP target failed. > > I understand that ilmb dlmb actually are using the same > lmb_bram_if_cntlr and LMB bus. Different address should be the only way > to tell the difference. But how can I tell where should the data be > stored in my high level C program. It seems that the MicroBlaze will > automatically store data after the instruction section. Similarly, if > I want to use a shared memory place for two MicroBlaze, where can I > give the information in the high level C program where the shared > memory is. > > Thanks a lot for your reply. > you can place code and data in any place you want by writing proper linker scripts the virtual platform possible isnt supporting the case where the ilmb and dlb addresses don match as it is very seldom the case AnttiArticle: 96917
Allan Herriman wrote: > The point I was making is that most comms interfaces are fundamentally > synchronous at their lowest levels. Consider a popular interface like > 100Base-Tx Ethernet. This pushes out a byte of data every 80ns, and > this timing must come from an accurate clock. Asynchronous logic has > no place here. The external interface logic for comms, memory, and most things real world are clearly not async. However, placing an async to sync dual ported fifo at the chip pads, allows all internal control and data path logic to become async, with at most a small sync state machine for control.Article: 96918
Thank you very much.Article: 96919
For the most part, I'm right with you on your comments. However ... <sigh> ... there's always a however ... sometimes someone hands you a schematic and says, "THIS is what I want, and THIS is what I'll pay you to recreate in programmable logic," and that's where the fun begins. I've had little trouble getting "transcriptions" of SSI/MSI designs to work in CPLD's, with the exception of one-shots, which can, but shouldn't, be implemented in CPLD's with SCHMITT inputs. However, some "TTL" library parts didn't work quite right when taken directly from the XILINX library, and some had extra or omitted signals, the justification for which was seldom available. If someone wants THIS generated in CPLD/FPGA hardware, you have to give it your best effort, but if you do it in HDL, it's unlikely anybody will be able to review it to their satisfaction. If you present a 100 modules of VHDL to a group of guys my age, who went to college when transistor radios were just becoming commonplace, all you'll get is "what's this?" and maybe fired, unless, say, you can plug our device in an application for what you've got to replace, and demonstrate it works as well as the original. Reviews are a problem. If you have a well-designed, well-documented, fully verified logic design implemented on a device that's working to your satisfaction, you still have to go through the review process. If the senior engineers, and I don't mean those kids who don't even remember back before there was a NASA, are presented with a single-page schematic, they can grasp what's going on in the design, at least to their own satisfaction, with the help of the documentation, in about a half an hour. If you hand them a stack of HDL listings, and especially if you've presented them with a block diagram that represents a bunch of HDL-implemented blocks, you're in for a rough ride, and a week of being raked over the coals, at great expense to someone, since all that engineering horsepower has to be paid, and the buy who signs their checks probably signs yours, too. If you show them a schematic, they know what it means and can interpret it as well as they need. If you substitute synchronous for asynchronous logic, they'll understand why you did that. Support it with block schematics and simulations and they'll bite. If you support it with HDL blocks and simulations, they'll fight. You'll be accused of bait-and-switching on them. That, BTW, is why I'm so upset over the fact that both XILINX and ALTERA have made their schematic capture software a distant, neglected, and indadequately documented stepchild. RichardArticle: 96920
On 13 Feb 2006 13:04:27 -0800, fpga_toys@yahoo.com wrote: > >Allan Herriman wrote: >> The point I was making is that most comms interfaces are fundamentally >> synchronous at their lowest levels. Consider a popular interface like >> 100Base-Tx Ethernet. This pushes out a byte of data every 80ns, and >> this timing must come from an accurate clock. Asynchronous logic has >> no place here. > >The external interface logic for comms, memory, and most things real >world are clearly not async. However, placing an async to sync dual >ported fifo at the chip pads, allows all internal control and data path >logic to become async, with at most a small sync state machine for >control. Consider a store-and-forward Ethernet switch or router. A packet comes in on one synchronous interface, gets written to synchronous ram, gets read out of synchronous ram and sent to another synchronous interface. One could put sync-to-async and async-to-sync fifos in between those blocks, but why would you? Where is the benefit for a data plane application which requires accurate timing? I can see that async logic might help in something like a microprocessor (where you often don't care about exact execution times), but the arguments don't seem compelling for any of the tasks I meet in my work. Regards, AllanArticle: 96921
I've recently noticed that the schematic software that's included with XILINX' ISE WebPack and with Altera's Quartus WebEdition software is pretty lame. It looks as though the folks who generate, maintain, and repair this stuff have never had to make their living with it. I recently abandoned the last two releases of XILINX' WebPack stuff because there were problems making it nearly unuseable. Release 7 was apparently written in VB or JAVA, hence, was so slow I couldn't use it, and release 8 was not only slow but "broken" in a number of ways that I couldn't use it either. Several bugs that I reported in 2002 still can be found, including a problem aligning bus taps with nets drawn on the grid that aligns with the symbol pins, translation/netlist errors, random breakdown in sequential signal-numbering (tell it to increment, and it decrements, and vice-versa, but not always) ... I could go on, and will in a note to the local sales rep ... The release 3 and 4 of Quartus wouldn't display whole text strings on any of our HP desktops. That meant that, for a year, no Altera development could be done, except with MaxPlus-II. The current Quartus doesn't associate net names between net segments, i.e. if I put a right angle in a "wire," it loses its net-name property. There are cases wherein a net name can't be deleted from a sheet, even if the net's gone, where a net name=>pin assignment won't work because the assignment editor doesn't allow editing of the net name, and busses ... well ... So, are any of you guys seeing the same sorts of problems? Doesn't it make sense to have a half-hour review of a schematic rather than a week-long review of a ream of HDL listings? RichardArticle: 96922
richard wrote: > If > the senior engineers, and I don't mean those kids who don't even > remember back before there was a NASA, are presented with a single-page > schematic, they can grasp what's going on in the design, at least to > their own satisfaction, with the help of the documentation, in about a > half an hour. Good luck fitting a modern design on a single schematic sheet. Unless, of course, that sheet is Z size, or whatever. > That, BTW, is why I'm so upset over the fact that both XILINX and > ALTERA have made their schematic capture software a distant, neglected, > and indadequately documented stepchild. Seems to me that Altera and Xilinx (and Lattice, and Actel and QuickLogic) are putting their efforts where it's needed (and wanted), which is to say in better synthesis tools. -aArticle: 96923
richard wrote: > I've recently noticed that the schematic software that's included with > XILINX' ISE WebPack and with Altera's Quartus WebEdition software is > pretty lame. It looks as though the folks who generate, maintain, and > repair this stuff have never had to make their living with it. > > I recently abandoned the last two releases of XILINX' WebPack stuff > because there were problems making it nearly unuseable. Release 7 was > apparently written in VB or JAVA, hence, was so slow I couldn't use it, > and release 8 was not only slow but "broken" in a number of ways that I > couldn't use it either. > > Several bugs that I reported in 2002 still can be found, including a > problem aligning bus taps with nets drawn on the grid that aligns with > the symbol pins, translation/netlist errors, random breakdown in > sequential signal-numbering (tell it to increment, and it decrements, > and vice-versa, but not always) ... I could go on, and will in a note > to the local sales rep ... > > The release 3 and 4 of Quartus wouldn't display whole text strings on > any of our HP desktops. That meant that, for a year, no Altera > development could be done, except with MaxPlus-II. > > The current Quartus doesn't associate net names between net segments, > i.e. if I put a right angle in a "wire," it loses its net-name > property. There are cases wherein a net name can't be deleted from a > sheet, even if the net's gone, where a net name=>pin assignment won't > work because the assignment editor doesn't allow editing of the net > name, and busses ... well ... > > So, are any of you guys seeing the same sorts of problems? Doesn't it > make sense to have a half-hour review of a schematic rather than a > week-long review of a ream of HDL listings? > > Richard For most of us, the days of schematics are long gone but they still remain useful for high level views and for floorplanning. The best schematic tool I ever used was VLSI/Compass for ASIC design, it got most everything right and even allowed true edit in place of symbols within a live schematic but VLSI Inc developed that for their ASIC biz some 20yrs ago. When it garbage collected though it died for 20mins. Once synthesis & HDLs took over, all these schematic tools went south, there is no revenue model for them. My big gripe has been the uselessness of the synthesized schematics from code, if the code is trivial to understand, the schematics can be passable but not of much real help. If the code is too complex to understand, the software has no way to know how to reconstruct a decent looking schematic. Since these are constructed each & every time from synthesis, the slightest change to source code means a complete regeneration of synthesized schematic. Much of the code wouldn't really translate well to schematics as it looks more like C expression code than object instances. I would like to see a mechanism where by the synthesized schematic could be somewhat edited for good presentation and that the result be reused for the next pass without the tool getting confused by small changes. The biggest joke is when you build datapaths n bits wide, and these tools usually just consider these bit paths as just more soso giving mostly random placements that are easily made non linear by smaller edge details. If a draftsman created these machine like schematics, they be out the door pronto. In the ASIC world they have $$$ software that can take flattened mass of logic with regular hierarchy removed and refind the natural hierarchy and put it back in for more regular layout, but that wouldn't work too well over FPGA fabric. Don't expect too much from unpaid software. end of rant, John JaksonArticle: 96924
On Mon, 13 Feb 2006 14:14:37 -0500, ndt <info@ndt.ca> wrote: >Hi, I'm trying to implement rocketio on xilinx fpga. Is there a way to >simulate it using modelsim XE. I know for the PE, SE version its using >smartmodels or generating libraries. I don't think so. Even PE needs a $1K option to understand the encrypted smartmodels. I'd be glad if I was wrong here :-) regards, Gerhard
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