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 all, Thanks for the help. Yes, my purpose for now is to run experiments on partial reconfiguration. For that I am looking at commonly occuring large modules (that take up lot of slices) even if their implementation is not optimal. I will look into the DSP implementation of multiplier to see if it serves my purpose as well. I figured out a way to separate the logic of various components (like multipliers, adders, etc.) from each other. This could be done by using pblocks in Planahead. Planahead does hierarchical placement as well so it is better suited to do component-based placement. I am also trying to figure out a way to provide relative placement constraints for each component. I guess one way would be to floorplan the component alone and then export its floorplan as RPM. The RPM can then be used for the placement of the common components in the bigger design by putting the RPM in the ucf file.. Regards, Love Singhal http://www.ics.uci.edu/`lsinghalArticle: 97951
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> escribió en el mensaje news:du3dop$cq1$1@emma.aioe.org... > > > You can instantiate FOUR rams and implement a valid bit for each location > in a register. > PortA can write to RAM0,RAM1 and read from RAM0 and RAM2 > PortB can write to RAM2,RAM3 and read from RAM1 and RAM3 > > When PortA writes to address position 17, both RAM0[17] and RAM1[17] are > updated and the > VALID_BIT[17] is set to 0 indicating that RAM0,1 are valid instead of > RAM2,3. > > When PortB reads address position 17, both RAM1 and RAM3 are read. > A multiplexer on the output is controlled by the selected VALID_BIT, > and since VALID_BIT[17] is zero, it will select the output of RAM1 over > RAM3. > > Obviously this is going to use some gates,so it is not practical for large > SRAMs. > Running the RAM at 2 x frequency is going to cost a lot less. > > Following the previous example, I fail to see how can I read PortB address 17 (last time written through portA) while PortA is writing adddress (say) 22. Am I missing something ? Regards Josep DuranArticle: 97952
> Placement for some variables used at the top of the pci process created > some longer combinatorial chains than I had expected. Placing them at > the bottom of the function will remove the deep combinatorials, and > leave that path much shorter from the registered version of the > variables. You've had to understand the target architecture and what's causing your timing constraint to fail, then re-jig your HDL to reduce the number of levels of logic to achieve timing closure. I thought that one of the arguments for using a C based HDL was you can avoid this level of design implementaion detail? (Serious question, I'm not being facetious). Nial.Article: 97953
fpga_toys@yahoo.com wrote: [snip] > Most of the early computers I worked with in Dr. Dicky's lab with > tubes, were bit serial executing directly off multi-channel read/write > from the drums (head per track, and several concurrent channels). It > would literally be fetching instruction, data, operating on the data, > and writing all at the same time. Track down the schematics for the > Bendix G15 - I saw them on the web somewhere last fall. It's a tube > based drum computer, but was simple, and they made a lot of them. > There is probably some software kicking around for it as well. http://members.iinet.net.au/~dgreen/ The Australian Computer Museum (WA Branch) is rebuilding one. > [snip] > > Being really retro would be taking a hand full of floppy drives apart > for their heads, collecting some 1" mag tape and glue to a cylinder, > and building a drum. Or salvage some hard drives (the older the better: bigger tracks, larger bit sizes, generally less precision required). Mount the spin motor on a base, spin it up, then use a crystal oscillator & dividers to get a 3-phase supply. Fit up a single platter on the motor, with some additional weight (ie unused platters) as a flywheel, unless you have a truly sinusoidal 3-phase supply (the torque will flutter otherwise). Mount the heads on a fixed platform around the periphery, as head per track. You need a few 10's of mA to drive those heads. You will need some arrangement to lift the heads off the disk when it stops, else the combined stiction of all those heads will see it doesn't start again. Best if you do this by flexing the spring mounting (a fraction of a mm is enough), rather than bodily moving the head mounts; that will upset registration. > > Or maybe machine up a nice drum, and have it > nickle plated, for the real thing :) > It's not too hard (if you have access to a lathe) to make up the drum, & there's usually a chrome plater's around who will nickel it (that's a prerequisite for chrome plating, anyway). The hard part is making the heads. (Yes, I have done the above things...)Article: 97954
"Love Singhal" <lovesinghal@gmail.com> wrote in message news:1141290150.815684.165950@v46g2000cwv.googlegroups.com... > Hi Xun, > Planahead 8.1 supports partial reconfiguration in Virtex 4. > Check out this recent article: > http://www.us.design-reuse.com/news/news12519.html > > -Love > http://www.ics.uci.edu/~lsinghal > Hi Singhal, has the partial reconfig evolved since last time the Virtex 2 nightmare? I did partial reconfig with V2 FPGAs, and it was really buggy and inflexible.Article: 97955
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1141291017.772189.223140@j33g2000cwa.googlegroups.com... > you dont need password but the board #serial number, but I think it is > printed on piece of paper and not on the board, so you are possible out > of luck, I have downloaded with robot all the content of memec RDC so > the pdf you are looking is also there, if you email me in private I can > send it to you > > antti > That would very kind of you. I have sent an email to Antti.Lukats@xilant.com, hope to hear from you soon. Regards, FrankArticle: 97956
Marco, MII stands for Media Independent Interface and is supported, but without the PHY management interface (MDIO, MDCLK) you can get away without the PHY management because the PHY will auto negotiate the fastest link available with the other end of the connection. So you can still force a different connection speed/type by forcing the PHY settings at the other end, re-negotiation will start in the case of a carrier loss (in theory ) witout user intervention over the management interface. Aurash Marco T. wrote: > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1141285512.377077.5290@e56g2000cwe.googlegroups.com... > >>hard_temac.pdf page 23: >> >>"The MII management interface is not implemented in this release" !!!! >> >>so that it doesnt matter what you do with mdc and mdio as the core >>doesnt support management interface anyway ! >> >>the connection details can be derived from temac.vhd from xapp807.zip >>if you want >>to my surprise the management clk in is set to GND! >>hm, maybe the Management interface is not working in xapp807 either ? >> >>Antti >> > > > I read this morning the datasheet and I discovered what you said. > > I don't understand why MII is supported in ll_temac core and not into hard > temac. > > So, I think I will use ll_temac. > > Marco > >Article: 97957
Vic Vadi wrote: > The Virtex4 hardware supports partial reconfiguration and includes a lot > of special hooks intended to increase the flexibility of usage of > Partial Reconfig. Unfortunately the tools haven't quite caught up yet. > This should improve with the new Plan Ahead 8.1 and future Software > releases. This is exactly what I've been hearing since I started out with partial reconfiguration, and that was with ISE4.2. "Will be fixed in the next service pack", "should work in the next release", "This is not supported yet, but well be later on.", "This is a known issue that is scheduled to be fixed in a future software release.". Kind of reminds me of GNU/Hurd, which is always scheduled to be usable "next year", or "Duke Nukem Forever", which has been scheduled to be released for the past 9 years. Now it's 4 major releases and probably a dozen service packs later, and the bottom line is: It has never worked properly, it still doesn't, and in the past few years support in the tools hasn't even gotten a little better, because all the problems seem to be re-introduced with every major release all over again. And of course, as soon as a new FPGA family is introduced (Spartan 3, Virtex 4), all the effort seems to be going (understandably) into implementing partial reconfiguration for these new devices, not into fixing bugs in the existing support for older devices. The high-point of all of this was with the release of ISE7.1, when partial reconfiguration was completely disabled until SP4. > Some applications like Software Defined Radio and > Reconfigurable Computing are driving this. Nice to hear that now *finally* there seem to be applications for the mass market that make the whole subject "interesting" to Xilinx. In past years the whole thing was more or less academic in nature, and I totally understand that priorities are low when there's only little or no money behind it. This is all perfectly reasonable and understandable. But the thing that bugs me is that Xilinx has been using partial reconfiguration to promote their parts for years, and as soon as you really dive into the subject you find out that the parts do indeed support it, but the software does not, or has only very buggy or rudimentary support. So when you ask someone from Xilinx you usually get a link to some marketing press release which states "Yes, partial reconfiguration works, we're better than all of our competitors!", which is obviously only part of the truth... cu, SeanArticle: 97958
Hi, Actually i am using rocketio wizard 7.1.I want to do conversion of 8 bit parallel data into serial stream using rocketio mgt for 3.125 gbps. What frequency i have to apply on refclk,rxusrclk,rxusrclk2,txusrclk,txusrclk2?? I do not want to use crc and 8b10b module of rocketio mgt. Please suggest me any simple application for that.Article: 97959
I have generated a DP ram core in webpack 8.1, and it creates the VHDL files and templates. When I synthesize a file that instantiates a core component it creates a 'black box' as I believe it should. When I try to implement the file, however, it complains" ERROR:NgdBuild:604 - logical block 'DPRAM' with type 'wrapped_dpram' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'wrapped_dpram' is not supported in target 'spartan2'. evidently because it can't find the .edn file (edif netlist) even thopugh it's right there in the directory. Help!!!! Anybody know what's going on? BTW I am a relative newcomer to Webpack, although I have used previous versions successfully, but never with cores.Article: 97960
Have you set the macro path setting (Translate option) to where your edif or ngc file is located? John Adair Enterpoint Ltd. - Home of Raggedstone1. The £50 Spartan-3 Development Board. http://www.enterpoint.co.uk "ascaples" <scott.caples@verizon.net> wrote in message news:I9Odncp6IvXycpvZRVn-pg@giganews.com... >I have generated a DP ram core in webpack 8.1, and it creates the VHDL > files and templates. When I synthesize a file that instantiates a core > component it creates a 'black box' as I believe it should. When I try to > implement the file, however, it complains" > ERROR:NgdBuild:604 - logical block 'DPRAM' with type 'wrapped_dpram' could > not > be resolved. A pin name misspelling can cause this, a missing edif or > ngc > file, or the misspelling of a type name. Symbol 'wrapped_dpram' is not > supported in target 'spartan2'. > > evidently because it can't find the .edn file (edif netlist) even thopugh > it's right there in the directory. Help!!!! Anybody know what's going > on? > > BTW I am a relative newcomer to Webpack, although I have used previous > versions successfully, but never with cores. > >Article: 97961
Hi to all Newsgroup, I need of your little help. With an 8 bit microcontroller I must to calculate the AD9558 DDS input data, with the formula: Data = (2^48/Fclk)*Fout i.e. : Fclock =100MHz Fout = 11300000 Hz Data = 1CED 9168 72B0 or 31,806,672,368,304 With an 16 bit processor I don't have any problem, but with an 8bit processor I don't find/know the right way to calculate the *exact* Data. Have you an solution?? Thanks in advance and sorry for bandwidth... -- 73's de IZ5FCY RobertoArticle: 97962
But. Any editor I select must be included in my %PATH%. Where do I set the Path? RaymondArticle: 97963
Right click on my computer. Select properties Select the advanced tab Click the Environment Variables button at the bottom. PATH can be defined in either the user variables (top list) or the system variables (bottom list). User variables only will affect you. If there are other users on the system, adding a path to the system PATH could affect them. If you're the only user, it doesn't matter. Either way, find the PATH variable in the list of choice. If it's not there, click the New button under the list of choice and add the path to Ultra Edit to that path. The values are semi-colon separated. Example: System variables: Path %SystemRoot%\system32 Will become after edit Path %SystemRoot%\system32;C:\Program Files\Ultra Edit That path may not be correct (I use other editors and I don't bother to integrate with ISE). It is still an example. Good luck, ArlenArticle: 97964
Hello Marco, > I don't understand why MII is supported in ll_temac core and not into hard > temac. The hard temac supports the MIIM (MII Managment Interface, MDC, MDIO) but the PLB_TEMAC don't. The PLB_TEMAC uses the hard temac host interface without DCR but don't have access to the MIIM registers. The host interface signals are a little bit different between temac registers and MIIM registers. Now you can expand the PLB_TEMAC for MIIM register access (it is not very difficult) or you can use the DCR host interface which is also used in XAPP807. XAPP807 is a very good template to use the MIIM. Have fun, FlorianArticle: 97965
Roberto IZ5FCY wrote: > Hi to all Newsgroup, > > I need of your little help. > > With an 8 bit microcontroller I must to calculate the AD9558 DDS input > data, with the formula: > Data = (2^48/Fclk)*Fout > > i.e. : > Fclock =100MHz > Fout = 11300000 Hz > Data = 1CED 9168 72B0 or 31,806,672,368,304 > > With an 16 bit processor I don't have any problem, but with an 8bit > processor I don't find/know the right way to calculate the *exact* Data. > Have you an solution?? > Thanks in advance and sorry for bandwidth... If you're using an 8-bit microprocessor, simply translate doing long division by hand into steps of subtract, store if positive/jump if negative, shift and bring in new bits. If you can't do long division by hand, you're hosed.Article: 97966
"Florian" <comp_arch_fpga@47110815.com> wrote in message news:1141310968.882094.153050@i39g2000cwa.googlegroups.com... > Hello Marco, > >> I don't understand why MII is supported in ll_temac core and not into >> hard >> temac. > > The hard temac supports the MIIM (MII Managment Interface, MDC, MDIO) > but the PLB_TEMAC don't. > The PLB_TEMAC uses the hard temac host interface without DCR but don't > have access to the MIIM registers. The host interface signals are a > little bit different between temac registers and MIIM registers. > Now you can expand the PLB_TEMAC for MIIM register access (it is not > very difficult) or you can use the DCR host interface which is also > used in XAPP807. > XAPP807 is a very good template to use the MIIM. > > Have fun, > Florian > I'll look for xapp807. Many Thanks to everyone! Marco ToschiArticle: 97967
Hi, I think than actually the PR is well-supported in Virtex-II. This family is the reference device for all PR documents. But it depends of the complexity of your design. The question is if new families will be supported, particularly Virtex-4, because the new architecture appears to be incompatible with the actual PR methodology. PlanAhead should be the solution. However it is necessary to evaluate if it works well for all kind of applications, because simple PR design works perfectly in all devices: Spartan-II, Virtex, Virtex-II, etc... as Javier Castillo said. Regards, Ivan Frank wrote: > "Love Singhal" <lovesinghal@gmail.com> wrote in message > news:1141290150.815684.165950@v46g2000cwv.googlegroups.com... >> Hi Xun, >> Planahead 8.1 supports partial reconfiguration in Virtex 4. >> Check out this recent article: >> http://www.us.design-reuse.com/news/news12519.html >> >> -Love >> http://www.ics.uci.edu/~lsinghal >> > > Hi Singhal, > > has the partial reconfig evolved since last time the Virtex 2 nightmare? > I did partial reconfig with V2 FPGAs, and it was really buggy and > inflexible. > > >Article: 97968
> If you're using an 8-bit microprocessor, simply translate doing long > division by hand into steps of subtract, store if positive/jump if > negative, shift and bring in new bits. If you can't do long division by > hand, you're hosed. Thanks John, but in "C" language....?? -- 73's de IZ5FCY RobertoArticle: 97969
Roberto IZ5FCY <iz5fcy_NOSPAMPLEASE_@arrl.net> wrote: > Hi to all Newsgroup, > I need of your little help. > With an 8 bit microcontroller I must to calculate the AD9558 DDS input > data, with the formula: > Data = (2^48/Fclk)*Fout > i.e. : > Fclock =100MHz > Fout = 11300000 Hz > Data = 1CED 9168 72B0 or 31,806,672,368,304 > With an 16 bit processor I don't have any problem, but with an 8bit > processor I don't find/know the right way to calculate the *exact* Data. > Have you an solution?? > Thanks in advance and sorry for bandwidth... If you use a C compiler, it probably knows how to do math with long values... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 97970
Can you post the error, so we can take a look ? Aurash nezhate wrote: > Hi all, I want to use a small cricuit (written in verilog and was > designed using ISE 3) in an other project using ISE 8.1. the problem is > that under ISE 3 the circuit worked perfectly, and under ISE 8.1 the is > an error. why this occur ? >Article: 97971
Hi, your comments reveal that you are very annoyed about PR. I think it is a hard work to make use of it, but actually there are a lot of interesting applications and research works when PR has been applied successfully. Of course these good results have been obtained at present. When ISE 4.2 was released, the PR was well-supported by the JBits tool. You chose the wrong tool :( Regards, Ivan Sean Durkin wrote: > Vic Vadi wrote: >> The Virtex4 hardware supports partial reconfiguration and includes a lot >> of special hooks intended to increase the flexibility of usage of >> Partial Reconfig. Unfortunately the tools haven't quite caught up yet. >> This should improve with the new Plan Ahead 8.1 and future Software >> releases. > This is exactly what I've been hearing since I started out with partial > reconfiguration, and that was with ISE4.2. "Will be fixed in the next > service pack", "should work in the next release", "This is not supported > yet, but well be later on.", "This is a known issue that is scheduled to > be fixed in a future software release.". > Kind of reminds me of GNU/Hurd, which is always scheduled to be usable > "next year", or "Duke Nukem Forever", which has been scheduled to be > released for the past 9 years. > > Now it's 4 major releases and probably a dozen service packs later, and > the bottom line is: It has never worked properly, it still doesn't, and > in the past few years support in the tools hasn't even gotten a little > better, because all the problems seem to be re-introduced with every > major release all over again. And of course, as soon as a new FPGA > family is introduced (Spartan 3, Virtex 4), all the effort seems to be > going (understandably) into implementing partial reconfiguration for > these new devices, not into fixing bugs in the existing support for > older devices. > > The high-point of all of this was with the release of ISE7.1, when > partial reconfiguration was completely disabled until SP4. > >> Some applications like Software Defined Radio and >> Reconfigurable Computing are driving this. > Nice to hear that now *finally* there seem to be applications for the > mass market that make the whole subject "interesting" to Xilinx. > > In past years the whole thing was more or less academic in nature, and I > totally understand that priorities are low when there's only little or > no money behind it. This is all perfectly reasonable and understandable. > > But the thing that bugs me is that Xilinx has been using partial > reconfiguration to promote their parts for years, and as soon as you > really dive into the subject you find out that the parts do indeed > support it, but the software does not, or has only very buggy or > rudimentary support. > > So when you ask someone from Xilinx you usually get a link to some > marketing press release which states "Yes, partial reconfiguration > works, we're better than all of our competitors!", which is obviously > only part of the truth... > > cu, > SeanArticle: 97972
> If you use a C compiler, it probably knows how to do math with long values... No dear Uwe, the 8bit PIC or AVR don't have 16bit math library.... -- 73's de IZ5FCY RobertoArticle: 97973
Roberto IZ5FCY wrote: > Thanks John, but in "C" language....?? What about "long long"? Depends on your compiler, but if it is available, it may be 64 bits wide. If there is no suitable data type, then you need to handle the carry-out manually. Unfortunately C does not let you access a carry flag inside the CPU. So you got two choices: Make the most significant bit the carry-out and handle it manually or use inline assembly. Inline assembly is quite easy to handle for GCC. But I think, we are very off-topic! RalfArticle: 97974
Uwe, I actually had a real problem finding something that would deal with 48 bit long words for integer division...and multiplication. I like John's approach: write a program to do what you would do by hand (in whatever language you like). 2E48 is only ~ 2.8E14. It isn't the scientific notation value that is large (or small), it is the fact that you really want 48 digits of accuracy so that you are +/- 1/2 lsb, or within 3.6E-15 * fclk of the frequency you want. 100 Micro-hertz resolution in this case? I think for Ham radio, 2E48 is a bit overkill, unless you are doing coherent detection... Austin AB6VU Uwe Bonnes wrote: > Roberto IZ5FCY <iz5fcy_NOSPAMPLEASE_@arrl.net> wrote: > >>Hi to all Newsgroup, > > >>I need of your little help. > > >>With an 8 bit microcontroller I must to calculate the AD9558 DDS input >>data, with the formula: >>Data = (2^48/Fclk)*Fout > > >>i.e. : >>Fclock =100MHz >>Fout = 11300000 Hz >>Data = 1CED 9168 72B0 or 31,806,672,368,304 > > >>With an 16 bit processor I don't have any problem, but with an 8bit >>processor I don't find/know the right way to calculate the *exact* Data. >>Have you an solution?? >>Thanks in advance and sorry for bandwidth... > > > If you use a C compiler, it probably knows how to do math with long values... >
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