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
Gary, It seems you are thinking as if you were writing software. VHDL is a hardware description language. You need to understand what hardware you are trying to create. You have a separate write and read processes, which essentially describe behaviour of a bunch (because you have more than a single bit) of D flip-flops. The write process describes what is applied to the D input and the read process what happens to the Q output. Thus, when you see slv_reg in the write process on the left side of the assignment it represents the D-input of the flip-flop, while when you see it on the right side in the read process it represents the Q output of the same flip-flop, i.e. stored content of the register. /Mikhail "gary" <rgarik@yahoo.com> wrote in message news:3LWdnRqUwL34_zHZnZ2dneKdnZydnZ2d@giganews.com... > >Gary, > > > >h doesn't have a source in your code. You need to add something like > this: > >h <= slv_reg0; > >Or just use slv_reg0 instead of h as input to your inverter and in the > read > >process. > > > >/Mikhail > >hey, > In user_ip.vhd file i used the following instantation in user logic > implementation > h<=slv_reg0; > k<=slv_reg1; > again synthesis is going on well but the same errors what i posted in my > first message are coming again. > > And in the second method i disabled h & k signals directly i assigned > portmap(slv_reg0,slv_reg1) in following way > ------------ > component inverter > port( s : in std_logic_vector(0 to 31); > t : out std_logic_vector(0 to 31)); > end component; > > ---attribute box_type : string; > --attribute box_type of inverter : component is "black_box"; > > begin > > we: inverter > port map(slv_reg0,slv_reg1); > ---------------------------- > while synthesis following errors are generated.... > > ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal <slv_reg1<9>> > Sources are: > Output signal of OBUF instance <we/t_9_OBUF> > Output signal of FDRE instance <slv_reg1_9> > > ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal > <slv_reg1<13>> > Sources are: > Output signal of OBUF instance <we/t_13_OBUF> > Output signal of FDRE instance <slv_reg1_13> > > ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal > <slv_reg1<21>> > Sources are: > Output signal of OBUF instance <we/t_21_OBUF> > Output signal of FDRE instance <slv_reg1_21> > > ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal > <slv_reg1<27>> > Sources are: > Output signal of OBUF instance <we/t_27_OBUF> > Output signal of FDRE instance <slv_reg1_27> > ----------------for all 0 to 31---------------------------- > /gary > > > > >Article: 104776
Hi, Can I find a website that lists the time for sorting 1 million 64-bit/32-bit random data using the fastest software sorting algorithm in a PC? Thank you. WengArticle: 104777
Weng Tianxiang said: > Hi, > Can I find a website that lists the time for sorting 1 million > 64-bit/32-bit random data using the fastest software sorting algorithm > in a PC? Apparently not. Note that, even if you could, such results would be highly hardware-dependent (although the /relative/ ordering of various sorting algorithms should be fairly consistent on any given platform). PCs vary wildly in performance characteristics. The first PC I used was an Atari ST, running at - what was it, 8 MHz? The first IBM-compatible I used was an 8088 running at - er, I forget, but it was in the 8-12MHz range, I think. The first PC I /owned/ was an 80386-SX running at 20MHz. Whoa, that baby was *fast*. Currently, I'm using a PIII which is probably a brazillion times faster than the 386. The term "a PC" doesn't mean a lot when it comes to benchmarking. I suggest you just write up the algorithms yourself, or grab them off the Net, and try them on your own hardware. Beware of the results being corrupted by caching. Do not measure I/O times. Do each test a few hundred times. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at above domain (but drop the www, obviously)Article: 104778
Mike Lewis wrote: > "mk" <kal*@dspia.*comdelete> wrote in message > news:2iqma2the96cnlaujjgi40c5fv4tngc05o@4ax.com... > > On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote: > > > >>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in > >>the reset ckt. I am afraid, it vilaotes the basic rule of > >>controllability of DFT. I should be able to control the state of all > >>the FFs from a single reset pin out side the chip. is not it true ? > > > > You can always insert control points after your reset logic so that > > when you enable test the flops become externally controllable again. > > It's easy to do this with current scan insertion tools. > > I thought we were talking about FPGAs ... the DFT logic for the FPGA is > already in the FPGA and is completely independant of the design that you put > in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC > land. > > Mike Yes Mike, you are right. There is no point in talking abut DFT logic in the FPGAs. Even I have mentioned this point in my post. I was expecting some comment on the first point that I had mentioned (regarding the Reset). 1) Here, I assume that the reset we are talking about is the Power ON Reset which is connected to a switch (or equivalent ckt) in the board. If this is the case, then the reset period is much more higher than some miliseconds. In case the dcm lock pin is being used as the core reset, then also we should not be much worried about the reset pulse width. As the DCM needs number of clock cycles before getting locked. any expert comments on this is highly appreciated. Regards, SaumyajitArticle: 104779
Hi All, I'm trying to get a DDR controller fo r the Micron MT46V16M16TG-75 up and running on a Memec V2MB1000 dev board but not having much luck so far. I initially tried the Opencores ddr_sdr which seemed to be sending the correct signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written - presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail. In the last couple of days I've been trying a similar thing in EDK 8.1 - I downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated. Thanks, DavidArticle: 104780
The length of the asynchronous signal is not the issue. Make it several minutes long, and you still face the issue of asynchronous de-assertion, which can laeve some flip-flops being reset longer than others. And potentially several clock ticks longer than others if the system clock rate is high. So, use SRL16 to avoid that problem... Peter Alfke, Xilinx (from home) ========= saumyajit_tech@yahoo.co.in wrote: > Mike Lewis wrote: > > "mk" <kal*@dspia.*comdelete> wrote in message > > news:2iqma2the96cnlaujjgi40c5fv4tngc05o@4ax.com... > > > On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote: > > > > > >>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in > > >>the reset ckt. I am afraid, it vilaotes the basic rule of > > >>controllability of DFT. I should be able to control the state of all > > >>the FFs from a single reset pin out side the chip. is not it true ? > > > > > > You can always insert control points after your reset logic so that > > > when you enable test the flops become externally controllable again. > > > It's easy to do this with current scan insertion tools. > > > > I thought we were talking about FPGAs ... the DFT logic for the FPGA is > > already in the FPGA and is completely independant of the design that you put > > in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC > > land. > > > > Mike > > Yes Mike, you are right. There is no point in talking abut DFT logic > in the FPGAs. Even I have mentioned this point in my post. > > I was expecting some comment on the first point that I had mentioned > (regarding the Reset). > > 1) Here, I assume that the reset we are talking about is the Power ON > Reset which is connected to a switch (or equivalent ckt) in the board. > If this is the case, then the reset period is much more higher than > some miliseconds. > > In case the dcm lock pin is being used as the core reset, then also we > should not be much worried about the reset pulse width. As the DCM > needs number of clock cycles before getting locked. > > any expert comments on this is highly appreciated. > > Regards, > SaumyajitArticle: 104781
Weng Tianxiang wrote: > Can I find a website that lists the time for sorting 1 million > 64-bit/32-bit random data using the fastest software sorting algorithm > in a PC? Given that you can't even find the relevant usenet newsgroup to ask this question... I highly doubt it. That aside... The "fastest" algorithm is going to depend on a few things; for example the actual 'randomness' of the data (its distribution), the format of said data and the results (e.g. do you need to sort in-place?), and the implementation of the algorithm (by which I mean, is the algorithm optimal for implementation in a typical PC?). You definitely won't find any answers on the absolute time required by a "PC" - whatever that is. And even if you did, the answer would be obsolete in about a week's time. You really need to find one or two candidate algorithms and then implement them on your chosen platform to get any meaningful solution to your problem. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 104782
Jim Wu wrote: > You may have already done this, but I thought to point it out anyway: > > Make sure that the core netlist (edn, etcc) is in the directory like > this > > pcores/your_core_v_1_00a/netlist > > And the bbd file should have lines like below: > FILES > your_netlist_names > > HTH, > Jim > http://home.comcast.net/~jimwu88/tools/ > > > Guru wrote: >> Hi folks, >> >> I have a problem and I need a clean solution: >> I created an OPB peipheral which includes AsyncFIFO (created with FIFO >> generator). I have included the edn (tried also with ngc) in bbd file >> and a VHDL wrapper (original, created by CoreGen). During build I get >> the following error: >> ERROR:NgdBuild:604 - logical block 'imam_0/imam_0/FIFO' with type >> 'async_fifo' 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 >> 'async_fifo' is not supported in target 'virtex4'. >> I did managed to overcome the problem somehow several times by changing >> bbd and netlist filenames, but the problem comes to the surface every >> time I clean all the EDK project files. >> >> Guru > Hi Guru, I solved that problem (when I experienced it) by adding the line OPTION STYLE = MIX to my mpd file. /Johan -- ----------------------------------------------- Johan Bernspång, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 104783
Ok, thanks. If linux wont work, what about ECOS, VxWorks,....? Do You have an Idea? Eric Antti schrieb: > eric schrieb: > >> Is there an implementation of Linux for the >> Live Design Eval Board(Xilinx). May be a version of >> uCLinux for Mircoblaze? >> >> Thx >> >> Eric > > Hi Eric, > > The Live Design Eval Board has only 1MB of RAM, there are some reports > getting mb-uclinux working with small (less than 4MB) memory but there > is no 'get it working in 1MB solution' - this is one problem. > > You can make a Microblaze design that is 'uclinux ready' and test it on > livedesign board, but you should use EDK for that in order to have the > supported peripheral in place (OPB_INTC, OPTB_Timer, OPB_UARTLITE) > > An interesting thing would of course be microblaze uclinux system > design without EDK using Altium Designer as SoC tool - unfortunatly > such a design does not exist - well the SDRAM support was added to > Altium Designer only in the release 6.3 (from 26 June 2006?), so there > is defenetly no uclinux that would work on system made with Altium > Designer. > > Antti > http://antti-brain.com >Article: 104784
In addition to the above options, I have some more in my mind. 1) Try using the guided file. If you have the old set up( Which meets the timing), then use it as a guided file for the new set -up. You will have various modes of using guided file, like exact, ....You have to choose the proper option. 2) The next option that comes to mind is "give proper constarint to the path which is failing". Regards, Saumyajit Gabor wrote: > JL wrote: > > Hello, > > > > I am using Xilinx ISE 7.1 and VHDL for a project deployed in a Virtex2 > > FPGA. I place&route and then I run the static timing analyzer. Results > > throw a timing constrain not met (see below). The weird thing is that > > it happens after I removed some logic from the project, without adding > > anything new. My understanding is that adding new logic could make > > place&route harder, but removing logic would give us more room to find > > a better allocation of resources. Any hints? > > Depending on how much you constrain the internals of a design, you > may see improvement when the design becomes smaller. However in > a relatively unconstrained placement, the placer starts with a seed and > pseudorandomly starts to place the components. Because of the nature > of this placement, any change can affect the timing in any direction. > > My suggestion if you have a design that once met the timing and > then does not after removing logic, is to try a different setting for > the "Starting Placer Cost Table" under the properties for place&route. > You may need to select Advanced properties display to see this. > This number is the seed for starting the pseudorandom placement. > Changing it can often help your results. If after one or two tries you > still don't meet timing, you can use multipass place&route, which > automates the process of "Cost Table" selection. > > Good Luck, > GaborArticle: 104785
eric schrieb: > Ok, thanks. If linux wont work, > what about ECOS, VxWorks,....? > Do You have an Idea? > > Eric > 1 VxWorks only supports PPC not MicroBlaze 2 eCos is not ported to MicroBlaze either so both of them will not work on the live design eval board uC/OS would defenetly work, for some while ago I tested it on Microblaze, I think I got it all fitted into BRAMs, with 1MB SRAM you should have no problems Antti http://antti-brain.comArticle: 104786
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:uocla2t93lffghk9705huv57gviq6gega9@4ax.com... > "rickman" <spamgoeshere4@yahoo.com> wrote: > >>What feature about the CMOS latch makes it impossible to oscillate? My >>understanding is that there are two nodes with logic driving them to >>opposite polarities. If the FF is driven into metastability the two >>nodes can be driven to the same state which due to the logic, is >>unstable. since there is a delay from the input to the output of each >>node, it should be possible for each node to drive the other to the >>opposite state, then both nodes will be in the other state and drive >>the other node to the original state, etc. What prevents this in CMOS >>logic? > > Disclaimer: naive understanding exposed herein, without benefit > of clear understanding of control theory :-) > > Roughly, I think it's because the CMOS latch circuit has only 2 gain > stages in its loop, and both of them have delays that are dominated > by an RC effect (first-order) and, by comparison, its time delays are > negligible. So the whole thing is quite highly damped. By contrast, > TTL latch circuits often had rather more gain stages, I think. If you > simply cross-couple a pair of bipolar transistors you get an > embarrassingly slow circuit; TTL used all kinds of tricks to make > it faster - remember that NPN transistors were cheap, but just > about any other kind of component on TTL was troublesome > to make. > > If you use an ordinary digital simulator to model a two-inverter > feedback loop, and give each inverter a pure time delay, it's > easy to make the thing oscillate by prodding it appropriately. > But if the two inverting gain stages have a first-order RC-type > lag that swamps their propagation delay, an analog simulation > will show the thing settling monotonically after any disturbance from > its metastable "balance point". > If you have studied Op-amps, which have negative feedback instead of positive feedback, you are probably familiar with the bode plot. http://en.wikipedia.org/wiki/Bode_plot The key to stabilizing the op-amp is to insure that the feedback gain (open loop gain/closed loop gain) drops below unity before the additional phase shift reaches 180 degrees. For instance, take a look at the Open Loop Gain and Phase plots on page 7: http://cache.national.com/ds/LM/LMH6624.pdf In this case, the phase shift reaches 180 degrees at about 250 MHz while the gain is still 10dB. If you use this op-amp in a unity gain application, it will oscillate (hence the recommendation to use it for gains of 10 or greater). A similar analysis applies to flip-flops. The main difference is that here the feedback is positive (-360 degrees) and so latching to one side or the other is a stable state. If you get an additional -360 degrees of phase shift before the open loop gain reaches zero, the device can oscillate at that freqency if stimulated properly. 2 gain stages with single pole RC roll-off will have a maximum additional phase shift of -180 degrees. Cascading 4 or more gain stages will usually ensure that the phase shift exceeds -360 degrees before unity gain is reached due to the presence of higher order poles & wire delays. Daniel LangArticle: 104787
Daniel Lang <invalid@invalid.caltech.edu> wrote: >If you have studied Op-amps, which have negative feedback instead >of positive feedback, you are probably familiar with the bode plot. Yup. Studied, used, taught about :-) >The key to stabilizing the op-amp is to insure that the feedback >gain (open loop gain/closed loop gain) drops below unity before >the additional phase shift reaches 180 degrees. Indeed. That's a nice simple explanation that's often missing from the textbooks. >A similar analysis applies to flip-flops. The main difference >is that here the feedback is positive (-360 degrees) and so >latching to one side or the other is a stable state. If >you get an additional -360 degrees of phase shift before >the open loop gain reaches zero, the device can oscillate >at that freqency if stimulated properly. OK, thanks for that insight - the (rather obvious) point I'd missed was that you need an extra *360deg* of phase shift to get the thing to oscillate, not 180deg. >2 gain stages with single pole RC roll-off will have a maximum >additional phase shift of -180 degrees. Cascading 4 or more >gain stages will usually ensure that the phase shift exceeds >-360 degrees before unity gain is reached due to the presence >of higher order poles & wire delays. OK. Thanks for the nice and appropriate description. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 104788
David wrote: > Hi All, > > I'm trying to get a DDR controller fo r the Micron MT46V16M16TG-75 up and running on a Memec V2MB1000 dev board but not having much luck so far. > > I initially tried the Opencores ddr_sdr which seemed to be sending the correct signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written - presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail. > > In the last couple of days I've been trying a similar thing in EDK 8.1 - I downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated. > > Thanks, > > David If DQS is not being strobed during the read cycle, then a number of things may be wrong: 1. Clocks completely wrong relative to command. If this were the case, the initial setup of the mode and extended mode registers in the DDR would fail. 2. Address/data/command/clock skew. You already alluded to this and it would easily cause even the setup to fail. Something that is unknown is whether your writes are succeeding - and that's not possible to know if you don't get a read strobe. I would suggest, however, that if you don't even get a read strobe, the DDR is either : a. Not properly connected (check your UCF pin locations) b. Defective. c. Not being given a proper read cycle command d. Not being properly initialised. e. Not getting precharged (some DDR won't respond with read strobes unless precharge has been done in the last n cycles). See a typical DDR datasheet (micron does the best ones) for details. For d, make sure you are actually initialising the device Others could implicate clock/data/address/command skew. I do not know your level of knowledge with DDR itself, but I can assure you (having laid down DDR on my own boards, using chips as well as using sticks) that the slightest thing wrong in connectivity will render it useless. Cheers PeteSArticle: 104789
Actually I have done all of that that what you suggested. The problem is actually that during synthesis async_fifo.ngc is not copied to project/implementation/my_peripheral_0_wrapper directory. If I copy it manually the it works, otherwise not - weird behaviour. Maybe synthesis on the fly can help, since Xilinx peripherals are done that way (fifo in opb_ddr for instance). GuruArticle: 104790
OK, so if I've understood this properly, instead of registering the inputs by differing amounts in order to account for the PREG cascade at the outputs, everything is getting (pointlessly) registered by the same amount at the input, and then summed together combinatorily at the output of DSP48s, followed by some more pointless registering occurs at the output? My interest in this is fairly academic really... The design from which this question arose has a 35x35 multiplier generated using CoreGen, so it works fine. It would be useful from a design methodology perspective to have the ability to infer the DSP48s in such a simple manner. It would make autogenerating VHDL for different pipelined multiplier structures a walk in the park. I'm not necessarily of the opinion that this should be possible today, just that it would be really nice and when I came across sources that suggested it was possible to do this in a high performance manner I decided to try it. (XtremeDSP for Virtex-4 FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf & Philippe Garrault, Accelerate design performance with HDL coding practices) I've been really impressed with both the informal (via Ben Jones) and formal (via tech support) reaction to me bringing this up with Xilinx, so even if this has all come from me being a bit naive about the capabilities of XST, there seem to be people in Xilinx who believe that we should be able to be so naive and expect good performance at the same time. Still very much a beginner, Robin >Ray Andraka wrote: > Robin Bruce wrote: > > > Martin, > > > > > >>Have you had a look in FPGA editor to see what's going on? > > > > > > This is where I myself look dim: I did open up the NCD file in the FPGA > > Editor. I didn't really know what to do to tell if the right > > registering was occurring. All I could see was that all 4 DSP48s were > > instantiated together in a little row. I've never used FPGA editor > > before. I'm more familiar with PlanAhead for looking at that sort of > > thing, but I don't have that on my laptop, my current working platform. > > > > > >>Is it actually this bit of code that limits the timing? > > > > > > Well, all I can say is that I don't think so. It could very well be > > though, but I've tried writing the VHDL in very different ways, guided > > by things I've found in one or two guides to instantiating the DSP48s > > in VHDL. Every way I write the VHDL, the same performance is obtained. > > The thing is that I can see that the synthesis tool is making some kind > > of effort to pipeline the thing. > > > > This is the critical path that comes out of the synthesis report if > > this means anything to anyone: > > > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35 > > Gate Net > > Cell:in->out fanout Delay Delay Logical Name (Net Name) > > ---------------------------------------- ------------ > > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001 > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47) > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > mult_inst/Mmult__n00002 > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47) > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > mult_inst/Mmult__n00003 > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47) > > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004 > > (mult_inst/Mmult__n0000_s_69) > > FD:D 0.391 mult_inst/Mmult__n0000_0 > > ---------------------------------------- > > Total 12.320ns (11.786ns logic, 0.534ns route) > > (95.7% logic, 4.3% route) > > > > Cheers, > > > > Robin > > > > Your design is not inferring the P register, so the adders are > combinatorial. The adders get connected in a daisy chain. You may have > to recode your RTL to reflect that, as the synthesizer is not really > smart enough to push around the registers to the degree necessary to > deal with differing latencies among the adder inputs.Article: 104791
Hi, I am using the DDR controller(generated by MIG1.5) for the ddr MT46V32M16 -6 for the board V4MBlx60. I am getting the expected result in simulation with the hdl code generated by the MIG.But when i tried to simulate the post-par model of the code all interfaces to the ddr are driven with x.Any idea. thanks in advance subinArticle: 104792
Weng Tianxiang schrieb: > Hi, > Can I find a website that lists the time for sorting 1 million > 64-bit/32-bit random data using the fastest software sorting algorithm > in a PC? That depends on a lot of parameters, but I can give you one datapoint as an example: - Sorting 16777216 pair wise different 24-bit numbers takes no time at all. Kolja SulimmaArticle: 104793
Hi, Actually I read the related article in a website that lists the timing run by the author, but I couldn't find it again. For example, he lists times in parallel with number of data, the frequency of his computer and all related parameters that may affect the performance, he also lists the performances using different algorithms to do a comparison and made some conclusions. Thank you. WengArticle: 104794
Jim Granville wrote: > rickman wrote: > > But you have not responded as to why the FF can not oscillate. The FF > > is more than just a penl standing on end or a ball on a hill. A FF is > > a dynamic system with feedback and delays. My schooling taught me that > > with the right combination of delay and gain (or the wrong combination) > > it can oscillate. What makes these FFs different? > > > > The pen analogy is not a lot different from the pendulum. Yet a > > pendulum can be chaotic! I think the pen is only good as a first order > > approximation. For this sort of issue, the analogy requires further > > scrutiny. > > Put this into a Spice pgm, and try it. Two reasons why I can't... 1) I don't have Spice 2) I don't have "this". > In fact, (good) spice should be able to show the settling-time-extension > effects of metastability quite well. It would need carefull sweep > of the drive voltage, at the instant the clock does the hand-over. I am sure it can, but several posts here claim that CMOS FFs can't oscillate and I am asking how people know this is a true fact. Obviously simulating it or hooking up a test circuit can't prove it won't oscillate. That can only prove it won't oscillate under those conditions. > The FF I am used to, is Analog transmission gates, around single > CMOS INV/OR gates - two forming the regenerative latch. > > These simple 'unbuffered' CMOS structures have finite analog gain, even > at their peak, in the linear region. (unlike TTL ones ) Why do you call this "unbuffered"? Don't the gates create gain and delay? The more I think about this, the more I am starting to believe that a FF is capable of chotic behavior. > To build an oscillator, you must hold them in the linear region (DC), > and provide phase shift at some other frequency, where the loop > gain is still over unity. I don't think that is true. The TTL FFs (or coupled inverters) that oscillate don't remain in the linear region. They peg the rails and the delays cause them to peg to the other rail when the feedback takes effect. > Yes, there are parasitics all around, but the FF lacks the linear-bias > mechanism, so it cannot sustain oscillation. > > I am sure some would look pretty knarly, as they settled, and may not > be monotonic, but these times will be very short. > During this settling time, they will also be at their most sensitive to > crosstalk effects.Article: 104795
The FPGA and RAM datasheet are very good starting points. The interface, well, the IO pins are there just for that purpouse. You may try google, opencores, hamburg hdl archive... Regards, Alex escreveu: > Thanks to everyone who has replied. > > Can anyone point me to a good resource on learning to interface the > FPGA with a RAM chip? I'm using VHDL for everything in the FPGA. The > more example VHDL I can see, the better. > > This is a project that landed in my lap that I'm having to learn a lot > for as I go. The more resources I have to learn how to use this FPGA > and VHDL, the better. > > Thank you. > > Alex McHaleArticle: 104796
Hi everyone! I write here, after having googled for some days, because I'm looking for some advices. I'm working, for my thesi, on a lowpass FIR filter for its implementation in a Altera FPGA (my tutor is on holiday and I haven't idea of exact model of this, but I think it is a very good board). Now, I choose to design an Interpolated filter, with a cascade of 2 FIR with symmetric transposed structure. I've discard direct form structure because the filter is long (about 100taps) and I need a clock frequency of about 50MHz. I know there are others structures, like second order cells, or bufferized direct form, but I think transposed choice is better for area occupation and pipeline improvements. Is it correct? Then, the filter is a base band filter, with 2 input signals, real part and imaginary part. I think to develop the filter for real part and replicate it for the imaginary part. Are there better ways to do this? And, last but not least, I would use RADn or other algorithm for avoiding multiplicators, because the filter is with constant coefficients. Did some of you use any of these algorithms? Thank you very much to all the people to answer this message. Best regards Dario PS: I'm sorry for my written English...Article: 104797
Peter, You were right, I had to go thru the FAE to get the files. I received them today and started comparing them with what was on the original CD included with the board. There appears to be a few extra files on the CD, but most of the files seem the same. If I load FPGA 4 into ISE 7, it still errors out in the mapper. I had tried to build this with version 6 last summer as well when we first purchased the board. Is there an inside verion of the projects for all four FPGAs that will build without errors and work(exorcise the memory) or was this similar to the LCD display / memory test?Article: 104798
Guys, Given feedback I've had from Xilinx, It seems that this is something that should be possible today but isn't. Apparently a bugfix has been made that should fix this and it will be released with ISE 9.1 Robin Robin Bruce wrote: > OK, > > so if I've understood this properly, instead of registering the inputs > by differing amounts in order to account for the PREG cascade at the > outputs, everything is getting (pointlessly) registered by the same > amount at the input, and then summed together combinatorily at the > output of DSP48s, followed by some more pointless registering occurs at > the output? > > My interest in this is fairly academic really... The design from which > this question arose has a 35x35 multiplier generated using CoreGen, so > it works fine. It would be useful from a design methodology perspective > to have the ability to infer the DSP48s in such a simple manner. It > would make autogenerating VHDL for different pipelined multiplier > structures a walk in the park. I'm not necessarily of the opinion that > this should be possible today, just that it would be really nice and > when I came across sources that suggested it was possible to do this in > a high performance manner I decided to try it. (XtremeDSP for Virtex-4 > FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf > & Philippe Garrault, Accelerate design performance with HDL coding > practices) > > I've been really impressed with both the informal (via Ben Jones) and > formal (via tech support) reaction to me bringing this up with Xilinx, > so even if this has all come from me being a bit naive about the > capabilities of XST, there seem to be people in Xilinx who believe that > we should be able to be so naive and expect good performance at the > same time. > > Still very much a beginner, > > Robin > > >Ray Andraka wrote: > > Robin Bruce wrote: > > > > > Martin, > > > > > > > > >>Have you had a look in FPGA editor to see what's going on? > > > > > > > > > This is where I myself look dim: I did open up the NCD file in the FPGA > > > Editor. I didn't really know what to do to tell if the right > > > registering was occurring. All I could see was that all 4 DSP48s were > > > instantiated together in a little row. I've never used FPGA editor > > > before. I'm more familiar with PlanAhead for looking at that sort of > > > thing, but I don't have that on my laptop, my current working platform. > > > > > > > > >>Is it actually this bit of code that limits the timing? > > > > > > > > > Well, all I can say is that I don't think so. It could very well be > > > though, but I've tried writing the VHDL in very different ways, guided > > > by things I've found in one or two guides to instantiating the DSP48s > > > in VHDL. Every way I write the VHDL, the same performance is obtained. > > > The thing is that I can see that the synthesis tool is making some kind > > > of effort to pipeline the thing. > > > > > > This is the critical path that comes out of the synthesis report if > > > this means anything to anyone: > > > > > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35 > > > Gate Net > > > Cell:in->out fanout Delay Delay Logical Name (Net Name) > > > ---------------------------------------- ------------ > > > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001 > > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47) > > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > > mult_inst/Mmult__n00002 > > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47) > > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > > mult_inst/Mmult__n00003 > > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47) > > > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004 > > > (mult_inst/Mmult__n0000_s_69) > > > FD:D 0.391 mult_inst/Mmult__n0000_0 > > > ---------------------------------------- > > > Total 12.320ns (11.786ns logic, 0.534ns route) > > > (95.7% logic, 4.3% route) > > > > > > Cheers, > > > > > > Robin > > > > > > > Your design is not inferring the P register, so the adders are > > combinatorial. The adders get connected in a daisy chain. You may have > > to recode your RTL to reflect that, as the synthesizer is not really > > smart enough to push around the registers to the degree necessary to > > deal with differing latencies among the adder inputs.Article: 104799
It may take a little effort and time to infer complex things using RTL, but the simulation performance has always been well worth the effort for me. Simulating the instantiated primitives is _very_ slow compared to RTL. Andy MM wrote: > Robin, > > IMHO, trying to get inferring of anything more complex than a flip-flop, or > perhaps an adder, to work is a waste of time. Just instantiate what you > need... > > /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