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
On Aug 7, 3:40=A0am, fmostafa <fatma.abouele...@ugent.be> wrote: > hi all; > > I have a question about the system clk in EDK project, my processor > clk is 100 Mhz and my bus clk is 25Mhz , i tried to increase =A0the bus > clk to =A050 Mhz , i did this by changing in the DCM , as i changed > the =A0CLKDV divisor to 2 instead of 4 , which means as i thought > (100/2) instead of (100/4), and cleaned the hardware and i stared to > generate the netlist and the bitstream but i don't know the uart is > not working in a right way , and of course i couldn't examine the rest > of the system . > i don't know if what i did is right or there is something missed or > there is another way to change the frequency. > > thanks > fatma There are several cores that need to have their parameters updated when you change the OPB/PLB bus speed. The UART lite is one of these cores. It has a parameter C_CLK_FREQ that needs to be set to the new frequency. You can change it in the MHS file, or from the Configure IP GUI window under system/OPB. There are other cores that need to be updated as well. I don't have a complete list of the, but serial IO cores, such as the UART and SPI cores, tend to generate baud rates or external clocks from the bus clock. Regards, John McCaskill www.FasterTechnology.comArticle: 134351
On Thu, 07 Aug 2008 11:29:43 +0200, Johann Glaser wrote: >Hi! > >My PhD thesis deals with coarse-grained reconfigurable logic. Therefore >the RTL schematic synthesis result is one major input for my work. > >I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both >tools provide this RTL netlist (before implementing it to the technology >netlist), but both in encrypted file formats. Yes, but every synth tool can write out a post-synthesis netlist in VHDL or Verilog ready for functional simulation. Sure you don't get a schematic, but I would have thought that a VHDL or Verilog netlist of primitives would be just as good. -- 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. From glaser@ict.tuwien.ac.at Thu Aug 07 05:59:43 2008 Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!news-fra1.dfn.de!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.arch.fpga Subject: Re: RTL Schematic as EDIF From: Johann Glaser <glaser@ict.tuwien.ac.at> In-Reply-To: <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com> References: <1218101383.15335.13.camel@glaser> <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1218113983.15335.25.camel@glaser> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Date: Thu, 07 Aug 2008 14:59:43 +0200 Lines: 36 NNTP-Posting-Host: pc53.ict.tuwien.ac.at X-Trace: 1218113849 tunews.univie.ac.at 11868 128.131.80.53 X-Complaints-To: abuse@tuwien.ac.at Xref: prodigy.net comp.arch.fpga:147118 X-Received-Date: Thu, 07 Aug 2008 08:57:36 EDT (nlpi059.nbdc.sbc.com) Hi! Am Donnerstag, den 07.08.2008, 13:31 +0100 schrieb Jonathan Bromley: > On Thu, 07 Aug 2008 11:29:43 +0200, Johann Glaser wrote: > > >Hi! > > > >My PhD thesis deals with coarse-grained reconfigurable logic. Therefore > >the RTL schematic synthesis result is one major input for my work. > > > >I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both > >tools provide this RTL netlist (before implementing it to the technology > >netlist), but both in encrypted file formats. > > Yes, but every synth tool can write out a post-synthesis netlist > in VHDL or Verilog ready for functional simulation. Sure you > don't get a schematic, but I would have thought that a VHDL > or Verilog netlist of primitives would be just as good. The schematic itself is not important for me, the netlist is the thing I want. For my research project I need the RTL netlist because it holds "higher level" information, like e.g. counters, MUXes, ... A technology mapped netlist is of no use for me, because the "interesting" things have already gone there. The HDL netlist is quite nice for me, but unfortunately a bit hard to work with. I'd have to implement a complex parser and as well as some "small synthesis" algorithms. Do you know if there is a reason, why synthesis tools refuse the user to get the RTL netlist as EDIF? Thanks HansiArticle: 134352
On Aug 7, 2:14 pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Aug 7, 3:40 am, fmostafa <fatma.abouele...@ugent.be> wrote: > > > hi all; > > > I have a question about the system clk in EDK project, my processor > > clk is 100 Mhz and my bus clk is 25Mhz , i tried to increase the bus > > clk to 50 Mhz , i did this by changing in the DCM , as i changed > > the CLKDV divisor to 2 instead of 4 , which means as i thought > > (100/2) instead of (100/4), and cleaned the hardware and i stared to > > generate the netlist and the bitstream but i don't know the uart is > > not working in a right way , and of course i couldn't examine the rest > > of the system . > > i don't know if what i did is right or there is something missed or > > there is another way to change the frequency. > > > thanks > > fatma > > There are several cores that need to have their parameters updated > when you change the OPB/PLB bus speed. > > The UART lite is one of these cores. It has a parameter C_CLK_FREQ > that needs to be set to the new frequency. You can change it in the > MHS file, or from the Configure IP GUI window under system/OPB. > > There are other cores that need to be updated as well. I don't have a > complete list of the, but serial IO cores, such as the UART and SPI > cores, tend to generate baud rates or external clocks from the bus > clock. > > Regards, > > John McCaskillwww.FasterTechnology.com hi John; thanks for your reply , but i have another question in the plb_bram_if_cntlr i think that i have to change the c_plb_period_ps, i can't understand how to change this parameter. BEGIN plb_bram_if_cntlr PARAMETER INSTANCE = plb_bram_if_cntlr_1 PARAMETER HW_VER = 1.00.b PARAMETER c_plb_clk_period_ps = 20000 PARAMETER c_baseaddr = 0xfffe0000 PARAMETER c_highaddr = 0xffffffff BUS_INTERFACE SPLB = plb BUS_INTERFACE PORTA = plb_bram_if_cntlr_1_port END thanks fatmaArticle: 134353
On Aug 6, 10:21 am, John McCaskill <jhmccask...@gmail.com> wrote: [snip] > > Don > > Since you state that you run out of slices, I know that your design is > larger than the FPGA can hold, but I would still point out that the > slice utilization is a pessimistic view of how much of the FPGA you > are using, the mapping stage spreads the logic out by default instead > of packing it as tightly as possible. The Register and LUT > utilization is an optimistic measure of how much of the FPGA you have > left. You need to watch all of them to get a good idea of how full > your design really is. [snip] > Regards, > > John McCaskillwww.FasterTechnology.com On a related note, I had a design with about 60% LUT and flip-flop utilization (Spartan 2) that would not fit until I checked "Disable Register Ordering" in the mapping options. If you're not exceeding the capacity of the device by too much you can look at tuning the tools a bit to help fit the design. Regards, GaborArticle: 134354
Hi, You might want to take a look at http://www.eecs.berkeley.edu/~alanmi/abc/ you can download the source, for research purposes this might be what you need. --SandeepArticle: 134355
Johann Glaser wrote:
> The schematic itself is not important for me, the netlist is the thing I
> want. For my research project I need the RTL netlist because it holds
> "higher level" information, like e.g. counters, MUXes, ...
What's wrong with the source code?
That's the highest level I have,
and the easiest object to simulate.
An RTL schematic shows collections of gates and flops.
Some of the gate collections are drawn as MUXes and
others are drawn as boxes:
http://mysite.verizon.net/miketreseler/uart.pdf
I use these interactively to see what my source
code looks like to synthesis, and for documentation.
However, for simulation or making a synthesis image,
the source is the thing.
> Do you know if there is a reason, why synthesis tools refuse the user to
> get the RTL netlist as EDIF?
Because such a netlist is at a lower level
than the source code that created it, and is
not useful for synthesis.
Back before A+X offered RTL views,
I used to roll my own using Leo to map my design
to a simple FPGA architecture like an Actel 1010.
The resulting technology view looked very much
like today's RTL views.
You could make an edif file of something like that.
-- Mike Treseler
Article: 134356On Aug 6, 8:05=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Aug 6, 12:31=A0pm, eromlignod <eromlig...@aol.com> wrote: > > > > > > > On Aug 6, 11:50=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > > > > If you can map this onto a block ram, you will save quite a bit of > > > registers. Whether or not you can do this depends on if you can write > > > the vectors in one (or a few) at a time, and process them sequentiall= y > > > in the time you have available. =A0How much time do you have to proce= ss > > > the vectors? Ns, us, ms ? > > > Ah, I think I'm following along now. =A0Are you talking about sending > > the numbers over a single 8-bit vector wire one-at-a-time? =A0Hmmm. > > > The vectors are actually independent from each other and refresh at > > various random rates, so a few usec here or there shouldn't make a > > difference. =A0I'll give it a try! > > > Don > > You are asking good questions, so there are multiple people here that > will be happy to help you out. However, you are asking for some low > level suggestions without giving enough high level detail. =A0The best > optimizations are the ones that you apply at the high level where you > have the most leverage. > > If you can tell us more about what you are trying to do you will get > better responses. You said that you have almost 100 high speed > channels. > > How many channels are there? > How fast are the pulses arriving on average? > Over what time is the average? > What is the air speed of an unladen swallow? > What is the minimum spacing between pulses? > How fast does your central processing module need to compare the > channels? > > As Jim Granville pointed our, the various time bases of your problem > have a major impact on the potential solutions. > > Regards, > > John McCaskillwww.FasterTechnology.com- Hide quoted text - > > - Show quoted text - Well, I'm being a little cryptic because there are new patent applications involved and I don't want to give too much away. I can tell you those things that are already covered in the first patent though. The device is a self-tuning piano. You can read/listen about it here... New York Times: http://query.nytimes.com/gst/fullpage.html?res=3D9800E1D8133FF931A35752C0A9= 659C8B63 NPR: http://www.npr.org/templates/story/story.php?storyId=3D878091 New Scientist Magazine: http://www.newscientist.com/article/dn3143-hotwired-piano-tunes-itself.html The incoming signals are square waves at the fundamental frequency of each of the 219 strings in the piano that are being magnetically sustained (vibrate forever). I only read 44 strings at a time, tune them, then go on to the next 44, etc. So there are 44 counting modules and an output address signal to instruct the sustainer circuits when to vibrate the next string. I first convert the wave to a "period" wave that has an "on" time equal to one period of the string's vibration. I then use this wave to enable counting of the 50-MHz system clock. So I get a count of how many clock ticks of the system clock occur for one period of string vibration. This takes up to 21 bits for the low strings. I average 32 of these numbers and calculate an error based on a stored setpoint. Currently I'm using a theoretical setpoint, but eventually I will want to add the feature whereby a piano tech can hand-tune the piano and then "store" his tuning numbers for subsequent use. The output of each of these modules is a 16-bit, signed "error" vector. All 44 errors go to an "evaluation" module where it is decided how much warmth needs to be applied to each string to tune it, in the form of 219 PWM duty cycles (0 to 256 each). These numbers are sent to another two modules and translated to a synchronous serial output where a separate power circuit decodes and uses them to produce the individual PWM control lines. Once the "in tune" value of PWM is found for each string, it is simply maintained until the system is switched off. Actual adjustments only occur when the system is first turned on. Currently I can tune each set of 44 strings in about 20 to 30 seconds. The whole system does indeed work just fine so far. I'm just running out of FPGA space, ostensibly because of my poorly-written code. I would like to add code to refine the tuning accuracy and time and possibly add the "store" option, so I need all the space I can get. Thanks for all of the excellent help so far! Don A. Gilmore Kansas CityArticle: 134357
Johann Glaser <glaser@ict.tuwien.ac.at> wrote: >Hi! > >My PhD thesis deals with coarse-grained reconfigurable logic. Therefore >the RTL schematic synthesis result is one major input for my work. > >I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both >tools provide this RTL netlist (before implementing it to the technology >netlist), but both in encrypted file formats. > >Xilinx ISE 10.1 saves the file as NGR file. Unfortunately there is no >ngr2edif tool provided (while an ngc2edif is available). > >Synplicity Synplify Pro 9.2 saves a SRS file and provides an edf2srs >tool, but no reverse. > >Could you please point me to tools which can convert these files formats >to open formats (especially EDIF) or to synthesis tools (not necessarily >for FPGA, a tool from an ASIC flow is ok too), which save the RTL >schematic as open file formats. Why not export to VHDL? It can be regarded as some sort of netlist and probably converted to EDIF as well. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 134358
Hi folks, I could need some help with my board's network setup (hardware and Linux and U-Boot drivers). This is my situation: I currently have a Xilinx ML403 board (With Virtex4 FX12) sitting on my desk. I have an EDK 10.1 system which already worked with simple standalone applications. I managed to use crostool to build a working cross toolchain (with gcc-4.2.4 and glibc-2.3.6). Then I downloaded vanilla Linux 2.6.25.11 from kernel.org. It took me a while to get the kernel run on my system. I also had to do some little changes to get the whole thing together. I now have a running Linux 2.6.25.11 kernel in an ace file together with the design. I can mount a root filesystem from systemace and play around via serial (ns16550) console. That's it. What I want is a full-featured box with ethernet support in Linux and U-boot (which I like and want to use as well). I found some linux ethernet drivers in the EDK directory: emac_v1_00_e emac_v1_00_f emac_v1_01_a emac_v1_11_a gemac_v1_00_f lltemac_linux_2_6_v1_00_a temac_linux_2_6_v1_00_a temac_linux_2_6_v2_00_b temac_linux_2_6_v2_00_c EDK offers me the following ethernet related modules: xps_ll_temac xps_ethernetlite hard_temac U-Boot (latest git snapshot) comes with xilinx_emac.c xilinx_emaclite.c I also remember that I once used an xps_ethernetlite or emaclite (sone "light" thing) with µCLinux on microblaze (Petalinux). Now the questions: Might there be a software compatibility between different emac and temac modules? What should I use? How do things plug together? How do I correctly set up the FX12's Tri-mode Emac with Linux and U-Boot? Are there drivers readily available? Or do I have to combine something new? I appreciate every hint, link, information, clarifying question and so on! Thanks a lot! Best wishes, Philipp :-) -- You have to reboot your computer after powerfail? Haha! http://h316.hachti.deArticle: 134359
Johann Glaser wrote: > > The schematic itself is not important for me, the netlist is the thing I > want. For my research project I need the RTL netlist because it holds > "higher level" information, like e.g. counters, MUXes, ... A technology > mapped netlist is of no use for me, because the "interesting" things > have already gone there. > > The HDL netlist is quite nice for me, but unfortunately a bit hard to > work with. I'd have to implement a complex parser and as well as some > "small synthesis" algorithms. > > Do you know if there is a reason, why synthesis tools refuse the user to > get the RTL netlist as EDIF? > > Thanks > Hansi Lieber Hansi, The intermiate (RTL) netlist is usually proprietary. I don't think companies want to give this away. It sounds like you would really like a tool like Verific, which is an HDL parser that a lot of companies are buying as a front end for their own synthesis (and simulation) tools. It outputs an RTL-type netlist, with high level primitive blocks. I don't know how expensive this would be for an individual user to buy, though. I can think of good reasons why the RTL netlist isn't in a standard format. Assume that you really liked the Xilinx synthesizer, because it was so great at inferring structures from behavioral code. You could then get that tool (cheap, since it is subsidized), and then take the RTL netlist and synthesize it with a poorer synthesizer using another part as a target. -KevinArticle: 134360
John_H wrote: > If you can't increase the processing frequency, you could still count > the LSbits and cycle through the counters, adding and clearing the > LSbits to a BlockRAM worth of counter values. To cycle through 255 > 32-bit counters, you'd need 8-bit counters for each signal and a > read-add-write cycle (using the dual-port mode) for each entry in your > list. You end up only using half the BlockRAM for this extreme number > of counters. > > It's more housekeeping but you use a fraction of the count resources. I once did something very much like this, but in reverse. I needed to generate 63 PWM outputs with a repetition rate of 1 kHz and 16-bit resolution (which implies a master clock frequency of 65.536 MHz) on a fairly modest FPGA. Obviously, the brute-force way to do this is to have a 16-bit master counter, 63 16-bit registers to hold the duty cycle values, and 63 16-bit comparators to drive the outputs. This would not have fit into the chip. So, rather than having 63 16-bit comparators, I used 6-bit comparators. The duty-cycle values were stored in a 64x16 block RAM (actually 128x16 so that updates to the values could be double-buffered), and I scanned through that RAM at the master clock rate (1024000 scans/second) and did the MSB comparison with one common 10-bit comparator. Each of the 6-bit comparators was "enabled" for fine timing when the MSBs matched for that channel. IIRC, used about 40% of the chip. -- Dave TweedArticle: 134361
hi http://nibz.googlecode.com processor ith VHDL just put up. Fully generic design. 16 bit version is 472 ltera LEs MAX II. There is still some optimization to be done. Wishbone master interface is primary interface. SEL_O all set to ones no matter what generic word size is used. cheers jackoArticle: 134362
eromlignod wrote: > The incoming signals are square waves at the fundamental frequency of > each of the 219 strings in the piano that are being magnetically > sustained (vibrate forever). I only read 44 strings at a time, tune > them, then go on to the next 44, etc. So there are 44 counting > modules and an output address signal to instruct the sustainer > circuits when to vibrate the next string. > > I first convert the wave to a "period" wave that has an "on" time > equal to one period of the string's vibration. I then use this wave > to enable counting of the 50-MHz system clock. So I get a count of > how many clock ticks of the system clock occur for one period of > string vibration. This takes up to 21 bits for the low strings. I > average 32 of these numbers and calculate an error based on a stored > setpoint. Currently I'm using a theoretical setpoint, but eventually > I will want to add the feature whereby a piano tech can hand-tune the > piano and then "store" his tuning numbers for subsequent use. Ah, this makes what you are doing much clearer. One immediate suggestion would be this: Rather than using 44 separate 50-MHz counters, use just one counter and 44 registers that capture the value of that counter when the rising edge of the input occurs. Then, you have a module that scans those 44 latches, and each time one is updated, you subtract the previous value from the current value (mod 2**21) to get the period for that string. This should save a lot of chip resources, converting lots of slice flip-flops into block RAM. The "previous values" can be stored in block RAM, the calibration periods can be stored in block RAM, the PWM values can be stored in block RAM, etc. Everything except for the 44 latches can be processed sequentially rather than in parallel. -- Dave TweedArticle: 134363
On Aug 7, 1:44=A0pm, David Tweed <dtw...@acm.org> wrote: > eromlignod wrote: > > The incoming signals are square waves at the fundamental frequency of > > each of the 219 strings in the piano that are being magnetically > > sustained (vibrate forever). =A0I only read 44 strings at a time, tune > > them, then go on to the next 44, etc. =A0So there are 44 counting > > modules and an output address signal to instruct the sustainer > > circuits when to vibrate the next string. > > > I first convert the wave to a "period" wave that has an "on" time > > equal to one period of the string's vibration. =A0I then use this wave > > to enable counting of the 50-MHz system clock. =A0So I get a count of > > how many clock ticks of the system clock occur for one period of > > string vibration. =A0This takes up to 21 bits for the low strings. =A0I > > average 32 of these numbers and calculate an error based on a stored > > setpoint. =A0Currently I'm using a theoretical setpoint, but eventually > > I will want to add the feature whereby a piano tech can hand-tune the > > piano and then "store" his tuning numbers for subsequent use. > > Ah, this makes what you are doing much clearer. > > One immediate suggestion would be this: Rather than using 44 separate > 50-MHz counters, use just one counter and 44 registers that capture > the value of that counter when the rising edge of the input occurs. > > Then, you have a module that scans those 44 latches, and each time > one is updated, you subtract the previous value from the current value > (mod 2**21) to get the period for that string. This should save a lot > of chip resources, converting lots of slice flip-flops into block RAM. > > The "previous values" can be stored in block RAM, the calibration > periods can be stored in block RAM, the PWM values can be stored in > block RAM, etc. Everything except for the 44 latches can be processed > sequentially rather than in parallel. > > -- Dave Tweed > > - Show quoted text - I like this idea. But how do I handle the case when the counter rolls back to zero inside a period measurement? Excuse my thickheadedness, but I'm actually an ME by trade and just taught myself HDL a few months ago. DonArticle: 134364
David Tweed wrote: > eromlignod wrote: > >> The incoming signals are square waves at the fundamental frequency of >> each of the 219 strings in the piano that are being magnetically >> sustained (vibrate forever). I only read 44 strings at a time, tune >> them, then go on to the next 44, etc. So there are 44 counting >> modules and an output address signal to instruct the sustainer >> circuits when to vibrate the next string. >> >> I first convert the wave to a "period" wave that has an "on" time >> equal to one period of the string's vibration. I then use this wave >> to enable counting of the 50-MHz system clock. So I get a count of >> how many clock ticks of the system clock occur for one period of >> string vibration. This takes up to 21 bits for the low strings. I >> average 32 of these numbers and calculate an error based on a stored >> setpoint. Currently I'm using a theoretical setpoint, but eventually >> I will want to add the feature whereby a piano tech can hand-tune the >> piano and then "store" his tuning numbers for subsequent use. > There is flaw in this approach, which is the Signal to Noise of a SINGLE cycle. With 44 going off at once, you will have crosstalk. That 21 bits will be mostly an illusion. > Ah, this makes what you are doing much clearer. > > One immediate suggestion would be this: Rather than using 44 separate > 50-MHz counters, use just one counter and 44 registers that capture > the value of that counter when the rising edge of the input occurs. > > Then, you have a module that scans those 44 latches, and each time > one is updated, you subtract the previous value from the current value > (mod 2**21) to get the period for that string. This should save a lot > of chip resources, converting lots of slice flip-flops into block RAM. > > The "previous values" can be stored in block RAM, the calibration > periods can be stored in block RAM, the PWM values can be stored in > block RAM, etc. Everything except for the 44 latches can be processed > sequentially rather than in parallel. Even simpler, since you KNOW what frequency you want, set up a pair of Loadable counter, close together as MIN as MIX and generate a TuneUP and TuneDOWN signal from when outside this error band. - drive those into LEDS and your Tune motors. Then your datapaths are just the error signals. Read up on reciprocal Frequecy counters, these give higher precisions by counting a time for a certain WHOLE number of cycles. To do that, you would preload 3 numbers, the Min/Max counts, and the cycles to total over. Much better signal to noise. You might even get the whole thing working in a Block Ram, as you can lower the 50MHz... You don't want the pianist saying your system is crap do you ;) -jgArticle: 134365
Below you will find a list of Altera product that is left over from builds. I need to move this product ASAP and should be able to be able to supply far below factory direct. All product is new in original factory packaging. I have supported several members of this users group and they have all be very happy with product and level of service. I thank you all for your support. If interested I also have plenty of LCD's,SRAM and DDR memory. Regards, Jon E. Hansen (949)864-7745 direct jon@pyramidemail.com www.pyramidtechnologiesinc.com EP2C35F672C6N EP1S80F1020C5 EP20K600EFC672-3 EP1S80F1020C5N EP20K400EFC672-2X EP20K100FC324-2 EP2S60F1020C5N EP1S60F1020C5N EP2S60F672C5N EP1S60F1020C5 EP1S40F780C6 EPF10K100ARC240-3 EP1S40F780C5N EPF10K100EQC240-1 EP2SGX90FF1508C3N EPF10K10QC208-3 EP1K50QI208-2 EPM9400RC208-15 EP1C20F400C6 EP2S180F1020C3N EP2C20F484C8N EP2A40B724C8 EP20K400EBC652-1 EP20K400BC652-1V EP20K300EFC672-1 EP20K200EQC240-1N EP20K200EFC672-3 EP20K200CF484C9Article: 134366
eromlignod wrote: > I like this idea. But how do I handle the case when the counter > rolls back to zero inside a period measurement? Modular arithmetic -- what I was alluding to with the "mod 2**21" comment -- takes care of that automatically. As long as you treat the difference as a positive number, it will always be correct, even if the counter rolls over. Actually, I can think of many refinements to this basic idea. Since you have a system clock of 50 MHz, you can easily scan your 44 input channels in well under 1 us, which means you really only need a 6-bit latch for each channel, along with an "edge happened" flag. Everything else can be handled with resources that are shared among all of the channels. To be honest, this is a system that really begs for a microcontroller. The only hardware that should be in the FPGA are the latches for your 44 period measurement channels and your 219 PWM output channels. Everything else -- the difference logic for the period calculation, the calibration algorithm, the preset tuning numbers, user interface features -- should be microcontroller firmware. > Excuse my thickheadedness, but I'm actually an ME by trade and just > taught myself HDL a few months ago. Really? The press announcments about this system that you linked to date from 2002-03 or so. Has it really taken that long to begin an implementation? -- Dave TweedArticle: 134367
On Aug 7, 2:57=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > David Tweed wrote: > > eromlignod wrote: > > >> The incoming signals are square waves at the fundamental frequency of > >> each of the 219 strings in the piano that are being magnetically > >> sustained (vibrate forever). =A0I only read 44 strings at a time, tune > >> them, then go on to the next 44, etc. =A0So there are 44 counting > >> modules and an output address signal to instruct the sustainer > >> circuits when to vibrate the next string. > > >> I first convert the wave to a "period" wave that has an "on" time > >> equal to one period of the string's vibration. =A0I then use this wave > >> to enable counting of the 50-MHz system clock. =A0So I get a count of > >> how many clock ticks of the system clock occur for one period of > >> string vibration. =A0This takes up to 21 bits for the low strings. =A0= I > >> average 32 of these numbers and calculate an error based on a stored > >> setpoint. =A0Currently I'm using a theoretical setpoint, but eventuall= y > >> I will want to add the feature whereby a piano tech can hand-tune the > >> piano and then "store" his tuning numbers for subsequent use. > > There is flaw in this approach, which is the Signal to Noise > of a SINGLE cycle. With 44 going off at once, you will have crosstalk. > That 21 bits will be mostly an illusion. > > > Ah, this makes what you are doing much clearer. > > > One immediate suggestion would be this: Rather than using 44 separate > > 50-MHz counters, use just one counter and 44 registers that capture > > the value of that counter when the rising edge of the input occurs. > > > Then, you have a module that scans those 44 latches, and each time > > one is updated, you subtract the previous value from the current value > > (mod 2**21) to get the period for that string. This should save a lot > > of chip resources, converting lots of slice flip-flops into block RAM. > > > The "previous values" can be stored in block RAM, the calibration > > periods can be stored in block RAM, the PWM values can be stored in > > block RAM, etc. Everything except for the 44 latches can be processed > > sequentially rather than in parallel. > > Even simpler, since you KNOW what frequency you want, set up > a pair of Loadable counter, close together as MIN as MIX and generate a > TuneUP and TuneDOWN signal from when outside this error band. > > - drive those into LEDS and your Tune motors. > > Then your datapaths are just the error signals. > > Read up on reciprocal Frequecy counters, these give higher > precisions by counting a time for a certain WHOLE number > of cycles. > To do that, you would preload 3 numbers, the Min/Max counts, and > the cycles to total over. Much better signal to noise. > You might even get the whole thing working in a Block Ram, > as you can lower the 50MHz... > > You don't want the pianist saying your system is crap do you ;) > > -jg- Hide quoted text - > > - Show quoted text - An ordinary frequency counter is not an option in this application. The lowest note A0 in a piano is 27.5 Hz and I need an accuracy of less than one "cent" (1/100th of a musical semitone). One cent sharp at 27.5 Hz is 27.5 * (2**(1/1200)) =3D 27.5159 Hz That's a difference in frequency of .0159 Hz. To be able to count with this accuracy would require that I count for at least a minute to get each reading. This is unacceptable. Also, please read the publicity I posted the links to, or the patent (6,559,369). I do not use any moving parts to control the string's pitch. Don Kansas CityArticle: 134368
On Aug 7, 3:38=A0pm, David Tweed <dtw...@acm.org> wrote: > eromlignod wrote: > =A0> Excuse my thickheadedness, but I'm actually an ME by trade and just > =A0> taught myself HDL a few months ago. > > Really? The press announcments about this system that you linked to > date from 2002-03 or so. Has it really taken that long to begin an > implementation? > > -- Dave Tweed All of this was originally supposed to be prototyped by an electronics firm in Florida, starting in the summer of 2002. I had a five-year royalty contract with Story & Clark Pianos (QRS) to build it. After the five years was up, they still hadn't got around to starting the project. They kept putting it on the back burner as other projects and financial concerns took priority. I refused to renew their contract in 2007 and am using the minimum royalty money that they had paid me, to build the prototype myself. I thought about a microcontroller for the main processing, but decided that I could probably do it all with the FPGA...and did so, except for this size problem. But I think by implementing some of your ideas, I can considerably reduce the number of slices. Thanks. Don Kansas CityArticle: 134369
eromlignod wrote: > I like this idea. But how do I handle the case when the counter rolls > back to zero inside a period measurement? Excuse my thickheadedness, > but I'm actually an ME by trade and just taught myself HDL a few > months ago. Normally you capture the value, and simply subtract Newest-Previous. IF newest < previous then overflow occured, and you replace as Newest+(MAX-Previous). -jgArticle: 134370
Ray D. wrote: > but I want to add a MicroBlaze core and connect my > hardware LCD module to the FSL bus instead of implementing software > drivers. That seems like a non sequitur to me. Surely you need some kind of "software drivers" for the LCD regardless of whether the LCD is conencted to FSL or to a GPIO peripheral on an OPB or PLB bus? The use of FSL vs. another bus only changes the method the driver would use to write to the LCD module.Article: 134371
That error is given by the DOS shell when it can't find the command you've typed.....are you using the default options for ISE (i.e. not using a batch script)? I know the commands they use aren't prefixed with the xilinx directory which could create issues with the path...but that seems screwy that it would hard code the map command to a seperate directory like that...that's why I ask if you're using a batch script...check your projects .cmd_log file, and your paths...sorry if that doesn't help, as I'm a beginner as well to ISE.Article: 134372
> If you want a low-cost board to experiment with both a Xilinx FPGA and > a Cypress PSoC, try this $39 kit: > > www.em.avnet.com/spartan3a-evl > Yeah, I just ordered it...but 10-12 week backlog though :( Must be popular....Article: 134373
eromlignod wrote: > On Aug 7, 2:57 pm, Jim Granville <no.s...@designtools.maps.co.nz> >> >>Even simpler, since you KNOW what frequency you want, set up >>a pair of Loadable counter, close together as MIN as MIX and generate a >>TuneUP and TuneDOWN signal from when outside this error band. >> >>- drive those into LEDS and your Tune motors. >> >>Then your datapaths are just the error signals. >> >>Read up on reciprocal Frequecy counters, these give higher >>precisions by counting a time for a certain WHOLE number >>of cycles. >>To do that, you would preload 3 numbers, the Min/Max counts, and >>the cycles to total over. Much better signal to noise. >>You might even get the whole thing working in a Block Ram, >>as you can lower the 50MHz... >> >>You don't want the pianist saying your system is crap do you ;) >> >>-jg- Hide quoted text - >> >>- Show quoted text - > > > > An ordinary frequency counter is not an option in this application. > The lowest note A0 in a piano is 27.5 Hz and I need an accuracy of > less than one "cent" (1/100th of a musical semitone). One cent sharp > at 27.5 Hz is > > 27.5 * (2**(1/1200)) = 27.5159 Hz Read what I wrote carefully. "Read up on reciprocal Frequecy counters" A Reciprocal Frequecy counter is not an ordinary frequency counter :) It counts in two domains: Whole cycles and time. Your values above are a dT of 17.05us. Suppose you measure 3 whole cycles, giving ~9 readings a second then a (relatively low) 1MHz reciprocal Counter will give a 63 count difference on your 15.9mHz dF example. - so is about 6 bits more precise than you need. You can change the sample time, to improve noise filtering, or the Mhz to give you more FPGA time. 500KHz is 100 cycles at 50MHz, (which sounds useful) and still gives 5 bits precision headroom at 9 samples/second. (more at lower samples/sec) eg at a 1-2us timebase, you can edge count 25-50 channels in block ram, with a simple state engine. Interleave the INC and Decision cycles for simplicity. > > That's a difference in frequency of .0159 Hz. To be able to count > with this accuracy would require that I count for at least a minute to > get each reading. This is unacceptable. > > Also, please read the publicity I posted the links to, or the patent > (6,559,369). I do not use any moving parts to control the string's > pitch. Wow - what is your power budget ? <paste> > I thought about a microcontroller for the main processing, but decided > that I could probably do it all with the FPGA...and did so, except for > this size problem. But I think by implementing some of your ideas, I > can considerably reduce the number of slices. Thanks. A fpga is a good development vehicle. Good luck. -jgArticle: 134374
eromlignod wrote: > On Aug 6, 8:05 pm, John McCaskill <jhmccask...@gmail.com> wrote: >> On Aug 6, 12:31 pm, eromlignod <eromlig...@aol.com> wrote: >> >> >> >> >> >>> On Aug 6, 11:50 am, John McCaskill <jhmccask...@gmail.com> wrote: >>>> If you can map this onto a block ram, you will save quite a bit of >>>> registers. Whether or not you can do this depends on if you can write >>>> the vectors in one (or a few) at a time, and process them sequentially >>>> in the time you have available. How much time do you have to process >>>> the vectors? Ns, us, ms ? >>> Ah, I think I'm following along now. Are you talking about sending >>> the numbers over a single 8-bit vector wire one-at-a-time? Hmmm. >>> The vectors are actually independent from each other and refresh at >>> various random rates, so a few usec here or there shouldn't make a >>> difference. I'll give it a try! >>> Don >> You are asking good questions, so there are multiple people here that >> will be happy to help you out. However, you are asking for some low >> level suggestions without giving enough high level detail. The best >> optimizations are the ones that you apply at the high level where you >> have the most leverage. >> >> If you can tell us more about what you are trying to do you will get >> better responses. You said that you have almost 100 high speed >> channels. >> >> How many channels are there? >> How fast are the pulses arriving on average? >> Over what time is the average? >> What is the air speed of an unladen swallow? >> What is the minimum spacing between pulses? >> How fast does your central processing module need to compare the >> channels? >> >> As Jim Granville pointed our, the various time bases of your problem >> have a major impact on the potential solutions. >> >> Regards, >> >> John McCaskillwww.FasterTechnology.com- Hide quoted text - >> >> - Show quoted text - > > > Well, I'm being a little cryptic because there are new patent > applications involved and I don't want to give too much away. I can > tell you those things that are already covered in the first patent > though. > > The device is a self-tuning piano. You can read/listen about it > here... > > New York Times: > http://query.nytimes.com/gst/fullpage.html?res=9800E1D8133FF931A35752C0A9659C8B63 > > NPR: > http://www.npr.org/templates/story/story.php?storyId=878091 > > New Scientist Magazine: > http://www.newscientist.com/article/dn3143-hotwired-piano-tunes-itself.html > > The incoming signals are square waves at the fundamental frequency of > each of the 219 strings in the piano that are being magnetically > sustained (vibrate forever). I only read 44 strings at a time, tune > them, then go on to the next 44, etc. So there are 44 counting > modules and an output address signal to instruct the sustainer > circuits when to vibrate the next string. > > I first convert the wave to a "period" wave that has an "on" time > equal to one period of the string's vibration. I then use this wave > to enable counting of the 50-MHz system clock. So I get a count of > how many clock ticks of the system clock occur for one period of > string vibration. This takes up to 21 bits for the low strings. I > average 32 of these numbers and calculate an error based on a stored > setpoint. Currently I'm using a theoretical setpoint, but eventually > I will want to add the feature whereby a piano tech can hand-tune the > piano and then "store" his tuning numbers for subsequent use. > > The output of each of these modules is a 16-bit, signed "error" > vector. All 44 errors go to an "evaluation" module where it is > decided how much warmth needs to be applied to each string to tune it, > in the form of 219 PWM duty cycles (0 to 256 each). These numbers > are sent to another two modules and translated to a synchronous serial > output where a separate power circuit decodes and uses them to produce > the individual PWM control lines. Once the "in tune" value of PWM is > found for each string, it is simply maintained until the system is > switched off. Actual adjustments only occur when the system is first > turned on. Currently I can tune each set of 44 strings in about 20 to > 30 seconds. > > The whole system does indeed work just fine so far. I'm just running > out of FPGA space, ostensibly because of my poorly-written code. I > would like to add code to refine the tuning accuracy and time and > possibly add the "store" option, so I need all the space I can get. > > Thanks for all of the excellent help so far! > > Don A. Gilmore > Kansas City > Don, That's quite fascinating. Are you concerned about the 600W of heat drying out the piano wood? I know some pianos have humidifiers inside them so it seems like a potential issue. -Jeff
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