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 Fatih Gunes You didn't supply enough information, I assume that your xmp project is a subsystem. Please look inside you xps project folder/implementation/ system_stub.bmm.(this file must be added to your ise project)please verify that the instantiation of the processor there (system_i), mateches the one in the system's hdl top level. Hope i was clear enough. anyway please check the following link, http://www.xilinx.com/publications/xcellonline/xcell_52/xc_synplify52.htm Pay a special attnetion to "ProjNav ISE Flow".. Hope I was clear enough, if not then do not hesitate to reply.. Regards, Guy Zur Hardware Engineer.Article: 122501
>> 3 GB is a practical limit because the PCI bus and other memory-mapped >> devices typically occupy some hundred megabytes of address space. So you >> can't use this memory space to access RAM. > These are usually not mapped into the address space of a user process. Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + the userspace RAM if implementation of stuff like file reading, etc is to be efficient (without juggling with pages)...Article: 122502
Err I only have 3 registers that I must have a reset state for. This should fit well with what you have described. I am trying to code that up at the moment. The point of this exercise is to get a cycle accurate operation for a register version and a dual port ram version. After that I will look at gate count and or speed. The issues that I had with not being able to create small dual port rams was selft inflicted. I put the source code into the library when I didn't intend to. OOps. -- Andy Jonathan Bromley wrote: > On Sat, 28 Jul 2007 19:06:06 -0500, Ben Jackson <ben@ben.com> wrote: > > >>On 2007-07-28, Jonathan Bromley wrote: >> >>>HOWEVER, you *can* initialise the contents of any Xilinx >>>RAM at configuration >> >>But then you can't just 'reset' your design. You have to >>reconfigure from the bitstream to truly reset. > > > Yes. But the solution I offered - one "I have been written" > register bit per RAM location - doesn't scale well; it's fine > for up to a few dozen locations, no more. > > If you can arrange that the RAM locations whose initial value > matters to you are all in a small piece of address space, you > can easily modify the "I have been written" trick so that > it applies only to the small part of the memory that has the > initialisation requirement. > > More generally, it is not unreasonable to consider modifying > your system's control state machine so that its first action > after reset is to scribble the initialisation values into RAM, > maybe by block-copy out of another memory configured as ROM > with the reset values in it. > > As Peter said, it's not practical to reset a big memory, > and people have lived with this for ever.Article: 122503
On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote: > They used Icarus Verilog for synthesis. Synthesis capability has been > removed from icarus Verilog (though the author hopes to reintegrate it > one day) since it was very broken and buggy. That's excessively harsh, and equally said of vendors tools with all the bugs they have. There have been enough threads go thru here about those too. So if this is just more open source bashing, please be more specific, and things will get fixed. Steve (the author of icarus Verilog) does admit that synthesis in the current 0.9 development branch is broken right now, due to some major internal changes in progress, but will be fixed after the 0.9 release is done. During that transition he expects people can continue to use 0.8 synthesis until it's fixed for 0.9. I'm sure that if you actually report what you think is "very broken and buggy" problems, fixes will appear when he (or others) have time. That that much time between fixes we see for vendors tools which appear at major release cycles. Steve reports there are others, besides him, working on synthesis backends, and when he gets fixes, he generally applies them to the release tree.Article: 122504
On Jul 29, 9:54 am, fpga_t...@yahoo.com wrote: > On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote: > > > They used Icarus Verilog for synthesis. Synthesis capability has been > > removed from icarus Verilog (though the author hopes to reintegrate it > > one day) since it was very broken and buggy. > Steve (the author of icarus Verilog) does admit that synthesis in the > current 0.9 development branch is broken right now, due to some major > internal changes in progress, but will be fixed after the 0.9 release > is done. During that transition he expects people can continue to use > 0.8 synthesis until it's fixed for 0.9. Oh ... two other notes ... at least in progress development trees are visible and available with open source projects, and you can certainly fix problems you find and contribute to the project when you have the skills and time. Like vendors tools, when releases show up with major bugs, you do the same thing ... keep using the previous release until another major release rolls that you can use (or a patch/update appears).Article: 122505
On 2007-07-29, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: > On Sat, 28 Jul 2007 19:06:06 -0500, Ben Jackson <ben@ben.com> wrote: > >>On 2007-07-28, Jonathan Bromley wrote: >>> HOWEVER, you *can* initialise the contents of any Xilinx >>> RAM at configuration >> >> But then you can't just 'reset' your design. You have to >> reconfigure from the bitstream to truly reset. > > As Peter said, it's not practical to reset a big memory, > and people have lived with this for ever. I just wanted the OP to realize the significant tradeoff he's making by using preloaded blockrams. If you 'reset' a design that uses them you'll be surprised if you expected the reset values to appear in the RAM again! For something like a processor, I might just require a certain instruction sequence at initialization that sets up the RAMs the way I want. You'd be in good company -- good luck executing anything on a modern Intel processor without following 100 steps in a thick databook... -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 122506
Hello. I have just started working with a Virtex 4 board, and I need to make an application which will be connected on a Gigabit LAN using its hard TEMAC, collect some data transmitted to it (at highest data rate possible), store/manipulate them, and the forward them to a predefined network address. I will be using UDP protocol for the transmissions, to obtain the simplest/fastest possible communication. To give myself a headstart, I started by changing the TCP echo server provided by my board`s supplier ( www.files.em.avnet.com/files/181/279/fx12_lc_temac_lwip_echo_server_edk9_1_01.zip). It`s using Socket API, for which while it`s supposed to be simpler than Raw (i guess), I couldn`t find much information on the internet to help me work with. After many attempts, I have removed all my additional code from the example, and the only modifications left in \echo_sockets\src\socket.c is: line 244: sock = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); I compile everything and download it to the board with no problem, up to the point I send UDP data to the board. Nothing happens. After placing some breakpoints, I discovered that the code doesn`t appear to manage go through line 262. line 262: s = accept(sock,(struct sockaddr*)&rem,&len); I just need to change this small example for now to have something working to begin with. I believe there is a very easy solution to the problem that will make me feel stupid. Any help/suggestions are welcome. Thank youArticle: 122507
Hi All, I'm beginner for Microblaze. I use Spartan3E eval kit. I want to create custom ip and use interrupt. 1 - I create custom ip, connect it to OPB then I connect ports. I'm trying my ip on the board and it is ok. My ip is working without a problem. 2 - I create a line in mhs file (there is no another interrupt, there is no interrupt controller on the system) in microblaze block PORT INTERRUPT = microblaze_0_INTERRUPT also custom_ip block contains PORT IP2INTC_Irpt = microblaze_0_INTERRUPT. 3 - I type interrupt handler function name (Software Platform Setting > Interrupt Handler > Interrupt Handler > MyIntHandler. After this step I can't build applications and give a message to me ./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/ cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/ microblaze_interrupts_g.c: undefined reference to `IntHandler' collect2: ld returned 1 exit status make: *** [TestApp_Memory/executable.elf] Error 1 any body can help me? what are my missing steps? thanksArticle: 122508
I would like to use Odelay primitive to delay a signal generated in the virtex5 fpga fabric. For this I am hoping to use IODELAY as shown below. mlinit_in_l is the signal I would like to delay it in 75 ps resolution using odelay as it goes out to the fpga. mlinit_l is supposed to be the delayed signal but the output stays low. Thus it is not working. I would like to know how I tell the IODELAY primitive about using it as ODELAY and specify 75 ps resolution? The user's guide does not seem to have a lot of inofrmation about this. module linit_delay(mlinit_in_l, mlinit_l); input mlinit_in_l; output mlinit_l; IODELAY linit_dly1(.DATAOUT(mlinit_l), .C(1'b0), .CE(1'b0), .DATAIN(mlinit_in_l), .IDATAIN(mlinit_l), .INC(1'b0), .ODATAIN (mlinit_in_l), .RST(1'b0), .T(1'b0) ); endmoduleArticle: 122509
PFC wrote: > >>> 3 GB is a practical limit because the PCI bus and other memory-mapped >>> devices typically occupy some hundred megabytes of address space. So you >>> can't use this memory space to access RAM. > >> These are usually not mapped into the address space of a user process. > > Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + > the userspace RAM if implementation of stuff like file reading, etc is > to be efficient (without juggling with pages)... Anandtech ran an article which does quite a good job in explaining the 2 and 3 GB barriers. http://www.anandtech.com/gadgets/showdoc.aspx?i=3034Article: 122510
I don't see what parameters you are using when you instantiate the primitive. Those are very important. And also: If the V5 ODELAY is anything like the V4 IDELAY (which it probably is pretty close to), the 75ps resolution is NOT GUARANTEED on a per-tap basis. Basically, the delay over all the taps is fixed at some number. For the V4 IDELAY that value is 5ns (200 MHz ref clock period). Dividing that by 64 (number of taps) gives you 78.125 ps per tap. There is an equation to use for the V4 IDELAY that takes into account the variable nature of the individual tap delays. You'd be suprised at how much +/- there is in each tap. There is a document that describes this in detail. It is XAPP707. I do NOT know if there is a similar document for the V5 IDELAY/ODELAY. It may be that the V5 components don't behave like the V4. I just don't know. There is an equation in the V5 Switching Characteristics Guide, but it may not give the most accurate answers. But if they are similar to the V4 primitives, then you can't just use one tap and be assured that you are getting an exact delay. You can always check it on a scope and verify it fits your design. Then you are fine...at least for that particular part.Article: 122511
Eddie H wrote:
> I have multiple clock domains so I am hoping that it will provide multiple Fmax values.
I would make separate entities for each
clock domain and run STA separately for each.
Then work out synchronization
between the domains.
-- Mike Treseler
Article: 122512On 30 Jul., 00:01, icegray <iceg...@gmail.com> wrote: > Hi All, > I'm beginner for Microblaze. I use Spartan3E eval kit. I want to > create custom ip and use interrupt. > 1 - I create custom ip, connect it to OPB then I connect ports. I'm > trying my ip on the board and it is ok. My ip is working without a > problem. > > 2 - I create a line in mhs file (there is no another interrupt, there > is no interrupt controller on the system) in microblaze block > PORT INTERRUPT = microblaze_0_INTERRUPT > also custom_ip block contains > PORT IP2INTC_Irpt = microblaze_0_INTERRUPT. > > 3 - I type interrupt handler function name (Software Platform Setting> Interrupt Handler > Interrupt Handler > MyIntHandler. > > After this step I can't build applications and give a message to me > ./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/ > cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/ > microblaze_interrupts_g.c: undefined reference to `IntHandler' > collect2: ld returned 1 exit status > make: *** [TestApp_Memory/executable.elf] Error 1 > > any body can help me? what are my missing steps? thanks try: 1 did you write the code for te inteterrupt handler? 2 start with some demo examples that already use interrupts 3 connect the interrupt from your ip to intc AnttiArticle: 122513
Hi Guy Zur, Firstly,thank you for your reply.I want to add xmp file to ISE project as a sub module.I looked for system_stub but couldnt find.Then i create it and i paste the content of "system.bmm" to system_stub.So i have to instantiate microblaze manually. Have a nice dayArticle: 122514
Hi Guy Zur, Firstly,thank you for your reply.I want to add xmp file to ISE project as a sub module.I looked for system_stub but couldnt find.Then i create it and i paste the content of "system.bmm" to system_stub.So i have to instantiate microblaze manually. Have a nice dayArticle: 122515
On 28 Jul, 12:58, "Symon" <symon_bre...@hotmail.com> wrote: > "colin" <colin_toog...@yahoo.com> wrote in message > > news:1185552810.842102.166100@k79g2000hse.googlegroups.com...>I read this thread with great interest and have a very closely related > > question. > > > As of May 07 Altera recommend putting their pll gnd pins in a split > > plane. The arguments in this thread make a lot of sense for seperate > > analog circuits being on the same plane because one can physically > > seperate them, but how about pll gnds which are 3mm (3 balls) away > > from a standard GND pin. > > > Any advice appreciated as this will end an argument in our office. > > > Colin > > Hi Colin, > Do you have a link to Altera's recommendation? A picture of what they're > suggesting would be nice. > > Anyway, without having read TFA, I'll spout on regardless! > > For there to be noise injected into the supply of the PLL, it would need to > have noise current from the digital stuff or whatever passing through the > ground plane between where the PLL ground via(s) attach(es) and where the > PLL supply bypass capactitor ground via(s) attach(es). Clearly the smaller > this distance the less voltage is induced in the PLL supply. Bear in mind > that ground planes have very low impedance. > > Now, if the separation between the bypass caps and the PLL ground vias is a > lot, there might be a problem. However, I'm a skeptic until someone prove > otherwise. I bet the noise on the supplies is a lot bigger problem than > noise on a ground plane. (I bet they say to use LDO regs on the supplies, > even though the B/W of such regs. are a best a few hundred kHz. A passive > filter is much better!) > > HTH., Syms. > p.s. What's the deal on your office argument? Can you post the opinions? Syms Altera's recomendation is on page 27 of http://www.altera.com/literature/hb/stx2/stx2_sii52012.pdf There are three options floating around here 1) Just tie the pll gnds down to the plane. 2) Split the plane in 1) 3) Route out the net and tie it to the plane at the decoupling capacitor. A guy here reckons on 3) regardless of how close one can get the cap. What he says doesn't feel right but I have no idea what sort of frequencies flow through a pll gnd pin and therefore whether the inductance on the net matters. ColinArticle: 122516
"colin" <colin_toogood@yahoo.com> wrote in message news:1185780545.905561.144730@57g2000hsv.googlegroups.com... > On 28 Jul, 12:58, "Symon" <symon_bre...@hotmail.com> wrote: >> "colin" <colin_toog...@yahoo.com> wrote in message >> >> news:1185552810.842102.166100@k79g2000hse.googlegroups.com...>I read this >> thread with great interest and have a very closely related >> > question. >> >> > As of May 07 Altera recommend putting their pll gnd pins in a split >> > plane. The arguments in this thread make a lot of sense for seperate >> > analog circuits being on the same plane because one can physically >> > seperate them, but how about pll gnds which are 3mm (3 balls) away >> > from a standard GND pin. >> >> > Any advice appreciated as this will end an argument in our office. >> >> > Colin >> >> Hi Colin, >> Do you have a link to Altera's recommendation? A picture of what they're >> suggesting would be nice. >> >> Anyway, without having read TFA, I'll spout on regardless! >> >> For there to be noise injected into the supply of the PLL, it would need >> to >> have noise current from the digital stuff or whatever passing through the >> ground plane between where the PLL ground via(s) attach(es) and where the >> PLL supply bypass capactitor ground via(s) attach(es). Clearly the >> smaller >> this distance the less voltage is induced in the PLL supply. Bear in mind >> that ground planes have very low impedance. >> >> Now, if the separation between the bypass caps and the PLL ground vias is >> a >> lot, there might be a problem. However, I'm a skeptic until someone prove >> otherwise. I bet the noise on the supplies is a lot bigger problem than >> noise on a ground plane. (I bet they say to use LDO regs on the supplies, >> even though the B/W of such regs. are a best a few hundred kHz. A passive >> filter is much better!) >> >> HTH., Syms. >> p.s. What's the deal on your office argument? Can you post the opinions? > > Syms > > Altera's recomendation is on page 27 of > http://www.altera.com/literature/hb/stx2/stx2_sii52012.pdf > > There are three options floating around here > > 1) Just tie the pll gnds down to the plane. > 2) Split the plane in 1) > 3) Route out the net and tie it to the plane at the decoupling > capacitor. > > A guy here reckons on 3) regardless of how close one can get the cap. > What he says doesn't feel right but I have no idea what sort of > frequencies flow through a pll gnd pin and therefore whether the > inductance on the net matters. > > Colin > Hi Colin, Thanks for the link. Sadly, it's yet another "[Our company] recommends using separate analog and digital power [and ground] planes." without any explanation or justification. I guess because they have no explanation or justification. Except for the "monkeys hose water ladder banana" one. ;-) (Google it!) Of course, separate (or non-overlapping) power planes are a good idea, but that doesn't mean that separate ground planes are. I also read http://www.altera.com/literature/hb/sgx/sgx_sgx53001.pdf page 31, where they at least mention that there are supporters of the solid ground method. They then proceed to do some (IMO) bogus experiment where they build a board with ground islands separated by ferrite beads. They then repeat the expeiment with the beads "shorted to a wire" (sic). What? They apparently claim that the ferrites are better than wire, although they publish no data except that "The tests showed a jitter improvement of approximately 10% when isolating the ground planes.", implying that bits of wire here and there are equivalent to a continuous ground plane. What a crock! What sort of jitter? Pk-pk? RMS? Why don't they build a board with a proper ground plane? OK, now on to your colleague's idea. In order for his solution (3) to be better than (1), there has to be aggressor current flowing through the ground plane in (1) between the vias that connect to the ground ball and the decoupling capacitor to generate noise on the supply. Note that the ground plane has a very low impedance, so you'd need a lot of current for a little noise. Also, in order for this current to be in this region of the ground plane, the trace carrying the return current would need to be adjacent. This noise has to be worse than the drop in performance from the increased power supply inductance you have in solution (3). If this inductance wasn't important, you could make the traces as long as you wanted. (I'd guess the inductance due to the traces doubles, in (3) compared to (1), although it depends, of course, on how it's routed.) Also, solution (3) could suffer from crosstalk from traces that travel near this ground trace. Indeed, all things being equal, the aggressor current in the ground plane and the adjacent return path that was the problem with (1) can crosstalk* into the (3) ground trace. Anyway, _IMO_ the reason these madcap schemes persist is that, done properly**, they all work. However, the problem with modern FPGA circuits isn't noise in the ground planes, it's noise in the supplies. I concentrate my efforts on this supply noise, leaving my rock hard ground planes to take care of business at zero volts, halving my problem. HTH., Syms. * Here's an article about crosstalk. download.intel.com/education/highered/signal/ELCT762/class19_Crosstalk_overview.ppt ** NB. Split plane or routed ground systems are much easier to to wrongly than a solid ground plane.Article: 122517
fpga_toys@yahoo.com schrieb: > On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote: >> They used Icarus Verilog for synthesis. Synthesis capability has been >> removed from icarus Verilog (though the author hopes to reintegrate it >> one day) since it was very broken and buggy. > > That's excessively harsh, and equally said of vendors tools with all > the bugs they have. There have been enough threads go thru here about > those too. So if this is just more open source bashing, please be more > specific, and things will get fixed. > > Steve (the author of icarus Verilog) does admit that synthesis in the > current 0.9 development branch is broken right now, due to some major > internal changes in progress, but will be fixed after the 0.9 release > is done. During that transition he expects people can continue to use > 0.8 synthesis until it's fixed for 0.9. I remembered 463A2014.7040400@icarus.com, where Steve said: "CAVEAT: Synthesis in the devel trunk is broken, and has been temporarily abandoned. There was until very recently precious little interest in synthesis, so I didn't let it get in the way of the other tasks I've been working on. Getting synthesis back on line with the devel branch should be a big job. Therefore, for now I recommend using the 0.8 branch for synthesis work, at least for a proof of concept. If there is interest in putting serious work into it, then getting 0.9 synthesis together can be worked out later." > [...] > Steve reports there are others, besides him, working on synthesis > backends, and when he gets fixes, he generally applies them to the > release tree. > This is good news, I didn't know that people are working on synthesis backends. Was there a post on geda-user about it? PhilippArticle: 122518
On 30 Jul., 12:28, Philipp Klaus Krause <p...@spth.de> wrote: > fpga_t...@yahoo.com schrieb: > > > On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote: > >> They used Icarus Verilog for synthesis. Synthesis capability has been > >> removed from icarus Verilog (though the author hopes to reintegrate it > >> one day) since it was very broken and buggy. > > > That's excessively harsh, and equally said of vendors tools with all > > the bugs they have. There have been enough threads go thru here about > > those too. So if this is just more open source bashing, please be more > > specific, and things will get fixed. > > > Steve (the author of icarus Verilog) does admit that synthesis in the > > current 0.9 development branch is broken right now, due to some major > > internal changes in progress, but will be fixed after the 0.9 release > > is done. During that transition he expects people can continue to use > > 0.8 synthesis until it's fixed for 0.9. > > I remembered 463A2014.7040...@icarus.com, where Steve said: > > "CAVEAT: Synthesis in the devel trunk is broken, and has been > temporarily abandoned. There was until very recently precious > little interest in synthesis, so I didn't let it get in the way > of the other tasks I've been working on. Getting synthesis back > on line with the devel branch should be a big job. > > Therefore, for now I recommend using the 0.8 branch for synthesis > work, at least for a proof of concept. If there is interest in > putting serious work into it, then getting 0.9 synthesis together > can be worked out later." > > > [...] > > Steve reports there are others, besides him, working on synthesis > > backends, and when he gets fixes, he generally applies them to the > > release tree. > > This is good news, I didn't know that people are working on synthesis > backends. Was there a post on geda-user about it? > > Philipp there are or have been sure a while ago I think I got some working AT94K bistream made using the iverilog front AnttiArticle: 122519
On Jul 30, 8:08 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 30 Jul., 00:01, icegray <iceg...@gmail.com> wrote: > > > > > > > Hi All, > > I'm beginner for Microblaze. I use Spartan3E eval kit. I want to > > create custom ip and use interrupt. > > 1 - I create custom ip, connect it to OPB then I connect ports. I'm > > trying my ip on the board and it is ok. My ip is working without a > > problem. > > > 2 - I create a line in mhs file (there is no another interrupt, there > > is no interrupt controller on the system) in microblaze block > > PORT INTERRUPT = microblaze_0_INTERRUPT > > also custom_ip block contains > > PORT IP2INTC_Irpt = microblaze_0_INTERRUPT. > > > 3 - I type interrupt handler function name (Software Platform Setting> Interrupt Handler > Interrupt Handler > MyIntHandler. > > > After this step I can't build applications and give a message to me > > ./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/ > > cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/ > > microblaze_interrupts_g.c: undefined reference to `IntHandler' > > collect2: ld returned 1 exit status > > make: *** [TestApp_Memory/executable.elf] Error 1 > > > any body can help me? what are my missing steps? thanks > > try: > 1 did you write the code for te inteterrupt handler? > 2 start with some demo examples that already use interrupts > 3 connect the interrupt from your ip to intc > > Antti- Hide quoted text - > > - Show quoted text - thanks AnttiArticle: 122520
On Jul 28, 8:17 pm, Neil Steiner <neil.stei...@vt.edu> wrote: > I'm working with a custom verilog core that accepts a small number of > parameters, and I'm having a hard time pushing them through XST properly > under EDK 8.1. > > For example, I include the following line in my .mpd file: > > PARAMETER C_DCR_BASEADDR=0b0001000000, DT=STD_LOGIC_VECTOR, BITWIDTH=10, > MIN_SIZE=2, BUS=SDCR > > But XST happily reports: > > C_DCR_BASEADDR = 32'b00000000000000000000000001000000 > > Does anybody know how to ensure that my C_DCR_BASEADDR parameter is not > initialized to something wider than 10 bits? Did you try C_DCR_BASEADDR=10'b0001000000 Normally verilog assumes integer (32-bit) type for unspecified bit-widths. On the other hand are you sure that this matters? If you assigned the parameter to a 10-bit vector as in wire [9:0] addr; assign addr = C_DCR_BASEADDR; you'd just get the 10 LSB's of the parameter anyway. HTH, GaborArticle: 122521
On Jul 28, 6:34 am, Subroto Datta <sda...@altera.com> wrote: > On Jul 27, 1:25 am, "X.Y." <Xieyu1...@gmail.com> wrote: > > > > > > > On Jul 27, 5:37 am, Subroto Datta <sda...@altera.com> wrote: > > > > Hi X.Y, > > > > The Incremental Compilation flow currently does not allow the > > > imported .qxp to be "stamped" onto different instances. This is > > > coming. One workaround is to have a different HDL file and name for > > > each instance. Admittedly, this is not ideal but in many cases is an > > > easy solution. (If you're making changes on the top-level file, it's > > > painful to repeat in multiple files. But if the changes are in the > > > HDL files beneath that entity, then it all works smoothly after the > > > initial set-up.) > > > > One flow Iused often, mainly because it works and is easy, is the > > > pseudo-bottom up flow. This basically involves putting partitions on > > > the hierarchies that are in the same level as the one/s you are > > > interested in and set them to Empty(so they have no logic, but nothing > > > gets removed). I then work on the partitions I want with quick > > > compiles. Then, when I get what I want, I set that partition to post- > > > fit and either set the other partitions to Source or delete them > > > altogether(making everything else one big partition). It's quick and > > > easy without creating sub-projects, making sure their layout fits into > > > the top-level, etc. Also, in Q7.1 you can export a .qxp from sub > > > partitions, so you can always save off your results. This works with > > > multiple instances of the same thing, since they now have different > > > instances(and locations). > > > > What end goal are you using Incremental Compilation flow for? Are you > > > trying to reduce compile times, are you trying to preserve > > > performance, or something else? > > > > - Subroto Datta > > > Altera Corp. > > > Thanks for your reply! My end goal is trying to preserve performance. > > In our project, I use one Cyclone II FPGA to process four groups of > > image signal which comes from four cameras. The processing algorithms > > of the four groups of image signal are all the same. As a result, I > > plan to build a subproject implementing the processing of one of the > > four signals and export it as a partition. Then, I build a top level > > project and import it four times. Certainly, I will do four different > > pin assignments for the four partitions. > > It appears that LogicLock can do it also, am I right?- Hide quoted text - > > > - Show quoted text - > > I would recommend against using LogicLock for preserving > performance(which is done through back-annotation of location > assignments). LogicLock is excellent for floorplanning, but can have > issues with these back-annotated assignments. That portion of the > LogicLock flow is really meant to be replaced by the Incremental > Compilation flow. > > One thing I want to make sure of, does your design not meet timing > when run flat? Also, is it large portions of your design or just a > small sub-section that continually fails timing? I'm assuming it > doesn't meet timing when put together, and it's not just a single > block, as the strategy for these flows can be slightly different. > > Do your four equal blocks connect to each other? Is there some > central, common logic? Do they connect to pins? The problem I've > seen with what you're trying to do is a good placement of a single > block isn't good everywhere. For example, let's say you put them into > the four quadrants of the device. In the lower-level you optimize one > for the top-left corner, so the connections it makes to pins are all > placed along the top-and-left side, and the connections you make to > internal logic are on the bottom and right sides. Now, if you try to > keep that placement but move it to an instantiation on the bottom- > right, your pin and logic connections are reversed, and if these paths > are critical at all, they can fail timing. > > Just to go over the pseudo-bottom up flow again, take your top-level > design and: > > 1) Put a partition on all four instances, and any thing else you want > to put a partition on. > > 2) Floorplan the partitions(most likely into quadrants) (This is can > be optional) > > 3) Set three of the four to empty and let the fitter work on the > fourth one(say top-left region.) > > 4) Set the top-left region to Post-Fit and set a second partition to > Source(or Post-Synthesis) and fit it > > 5) Repeat onto the third and fourth partition > > 6) If any of them still doesn't make timing, you can back and refit > that one while leaving the rest post-fit. > > The nice thing about this flow is each region is aware of pin > locations, as well as any logic that is not set to empty. So if there > is some central block of logic, it can optimize placement to connect > to that. If the pin assignments have a different layour for all four > instances, the fitter can optimize for that. > > Hope this helps, > Subroto Datta > Altera Corp.- Hide quoted text - > > - Show quoted text - Hi, Subroto, Thanks for your reply, I have tried the pseudo-bottom up flow you recommend. It works well! Once I fit a partition, I can find its Floorplan Region in Timing Closure Floorplan. At last, there are four regions for the four partitions. There are some answers for your questions as flow, 1, My design doesn't meet timing when run flat. 2, In my design, the four equal blocks connect to each other. 3, There is some central, common logic and they connect to pins. And Besides, there are some questions I want to ask you: 1, What do you mean by "The problem I've seen with what you're trying to do is a good placement of a single block isn't good everywhere." 2, Actually, in your method, we need to put all the design partitions in a single Quartus project. The different thing is the compiling flow you told me. It is not a real bottom up flow (because it involves sub projects), so you call it pseudo- bottom up flow, am I right? 3, You have ever said " Also, in Q7.1 you can export a .qxp from sub partitions, so you can always save off your results. This works with multiple instances of the same thing, since they now have different instances (and locations). " in your first letter. Do you mean, we can import one sub partition multiple times in Q7.1, however, not in Q6.0? Best regards. Yours sincerely, X. Y.Article: 122522
Do I need to use the IDELAYCTRL primitive? Currently I have instantiated the IODELAY primitive only to be used as output delay type. Just using the IODELAY primitive, I am able to do the functional simulation.
But I have a confusion about using the IDELAYCTRL primitive. Is this needed for ODELAY? Or is this only for IDELAY?
I have updated the verilog code based on your input as shown but I am not sure what to do with the IDELAYCTRL primitive
module linit_delay(mlinit_in_l, mlinit_l);
input mlinit_in_l; output mlinit_l;
IODELAY # ( .DELAY_SRC("O"), .IDELAY_TYPE("FIXED"), .IDELAY_VALUE(0), .ODELAY_VALUE(2), .REFCLK_FREQUENCY(200.0) )
linit_dly1 (.DATAOUT(mlinit_l), .C(1'b0), .CE(1'b0), .DATAIN(1'b0), .IDATAIN(1'b0), .INC(1'b0), .ODATAIN(mlinit_in_l), .RST(1'b0), .T(1'b0) ); endmodule
Article: 122523Antti, Again,I need to apologize for the website problems over the weekend. Please be patient. AustinArticle: 122524
Hi all, I am trying to tell the ISE tools to place DSP48s belonging to a complex multiplier (generated with coregen) close together in a V4FX chip with the following line in my UCF: INST "DUC_BL.DUC_INST/CPL_MPLY_INST/*/mult_2/m18x18/dsp48_?" RLOC_RANGE=X1Y1:X1Y3; I am getting the following error: ------------------ ERROR:Map:10 - RLOC_RANGE attribute on DSP48 symbol "DUC_BL.DUC_INST/CPL_MPLY_INST/BU2/U0/mult_2/m18x18/dsp48_0" (output signal=DUC_BL.DUC_INST/CPL_MPLY_INST/BU2/U0/p_cout_2<47>) must be on the start of a set. I must admit I have not used RLOC_RANGE before... Thanks, /Mikhail
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