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
Kolja Sulimma wrote: > > rickman wrote: > > > This has been discussed > > many, many times here and I still don't see any open source tools that > > are worth using. > > You probably use a lot of open source tools allready > - spice > - espresso (which is part of ISE, IIRC) > - gcc (which is part of EDK) > - tcl (which is part of allmos every EDA tool around that does not use a > lisp dialect instead) I find that I have to pay a lot of money for most of my tools and they don't provide any source. In fact, they expressly forbid me from reverse engineering the tools. Are those the tools that you meant? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76726
Stephen Williams wrote: > > I believe I know the answer to this, but I just want to check around > in case I missed something. > > I have an FPGA design where I'm taking an existing frame grabber > board that we make and turning it around to make a CameraLink > camera simulator. It works and I can even select the camera clock > speed from a set of 8 values I precompiled. > > However, I find I now want to be able to gradually ramp up the > clock speed to see where our receiver boards start failing. My > set of 8 frequencies span 85MHz to 16MHz. I would really rather > be able to select frequencies from the range of 20-85MHz in 1MHz > increments. The duty cycle of the output clock must be no worse > then 60/40 for the ChannelLink transmitter chip, which has a PLL > to think of. > > I think I'm SOL and the best I can do is use as many DCM devices > as I can, divide the results by 1/2/3/4 and use lots of BUFGMUX > devices to select from that set of clocks and divided clocks. In > other words, extend what I've already done until I run out of > applicable resources. Besides being icky, that doesn't actually > get me many clocks, not to mention the limited number of BUFGMUX > devices to make a mux tree of clocks. > > So is there a way that I'm missing for getting a single software- > selectable output clock with a nearly 50/50 duty cycle ranging > from 20 to 85MHz? On an XC2V3000-4? I don't know much about the DCMs, but if you can use a 1 MHz ref, you should be able to use a PLL with a divider in the feedback loop to generate any multiple of 1 MHz between 43 and 85 MHz. Then the output can be divided down to many other frequencies including all the multiples of 1 MHz below 43 MHz. Will the DCM accommodate a 1 MHz ref and 43 to 85 MHz output? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76727
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:41B75EE9.91C61428@yahoo.com... > markets. This results in lots of updates and lots of bugs. (BTW > Mentor, are you *ever* going to fix the bug where Modelsim crashes > randomly for no special reason???) Sorry I can't resist it :-), but have you send them a testcase? do they know what is causing it? can you reproduce the crash? have you tried 6.0b? I am not trying to give a lecture since I have been cursing some of their &^£%=&( tools as well but I do know that debugging a piece of code as complex as Modelsim/NCSim/Aldec etc must be an absolute pig. Most if not all EDA companies will quickly bring out a patch release if you find a serious bug since this is their bread and butter. Your Modelsim can't be crashing randomly for no reason unless your PC is being hit by high energetic particles :-) If you can't send your source code them consider sending them an obfuscated version, and/or a compiled version (using the -nodebug if required) and/or set up and NDA, run your code on another PC, another OS, try using the command line version (vsim -c). Write a bit of Tcl which loops around your testbench repeatedly, then during the test read your mail, play some MP3 etc and see if this might be affecting Modelsim. Alternatively, get one of the Modelsim FAE's to visit you and sit next to you for a day while you re-run your testbench, you are(?) paying maintenance for it :-) Back to debugging my code :-( HansArticle: 76728
Dave wrote: > I'd like to create a sound synthesizer along the lines of a *very* > simplified Commodore SID chip. Any tips on how to get started? <http://www.fpga.nl/index.html?jester.html> -- | Mark McDougall | "Electrical Engineers do it | <http://to be announced> | with less resistance!"Article: 76729
BTW, has anybody compiled a bibliography on hardware evolution? I'd like to read through a big stack of papers on it all at once to try to get up to speed. - a Thomas Womack <twomack@chiark.greenend.org.uk> writes: > In article <N7r*F0IBq@news.chiark.greenend.org.uk>, > Thomas Womack <twomack@chiark.greenend.org.uk> wrote: >>In article <ljy8g7r1ho.fsf@troy.dt.e-technik.uni-dortmund.de>, >>Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote: >> >>>What is missing, in my opinion, is not 1 million lines of code with a >>>half-assed, half-open license. We need complete and unencumbered >>>documentation of the hardware, the way we have it for general purpose >>>CPUs like IA-32, PowerPC, etc. If there is a need for Free Software, >>>it will then appear. Maybe GOSPL provides these docs. >> >>We had something quite close to that, I _believe_, for the XC4000 >>series; I believe that's why those were the chips used in the amazing >>evolution-of-hardware experiments in 1996 or so. > > Sorry, I meant XC6216 here. The December 1996 paper describes the device > used as a prototype; I'm not sure what became of that range. > > http://www.cogs.susx.ac.uk/users/adrianth/ices96/node2.html > > is the paper, worth reading. > > Tom -- I wrote my own mail server and it still has a few bugs. If you send me a message and it bounces, please forward the bounce message to megacz@gmail.com. Thanks!Article: 76730
There are several good threads on comp.lang.verilog A book I've found useful as a reference is: The Verilog Hardware Description Language by Thomas & MoorbyArticle: 76731
"Dave" <apple2ebeige@yahoo.com> wrote in message news:1102617329.116082.44050@c13g2000cwb.googlegroups.com... > I'd like to create a sound synthesizer along the lines of a *very* > simplified Commodore SID chip. Any tips on how to get started? > Thanks. > > -Dave > There's an article floating around somewhere on the Net describing the implementation details of the SID (an interview with the original designer). Basically, it's very simple. First, you need a NCO (Numerically Controlled Oscillator) to produce a waveform. A NCO is nothing but a simple counter that's incremented with a constant at a fixed rate. By changing this constant you can change the frequency of the waveform. Usually the counter is 24 bits, and the waveform is created from the top 8 bits, which can be used as an index to a sample-table (a crude form of resampling). In the SID, for a square wave, the top bit is used as output; for a saw wave, the top 8 bits; for a triangle wave 7 of the 8 topbits are used, and these are followed by a XOR gates to invert the bits when the top bit is set. After these, a simple R2R ladder that acts as DAC which is followed by an amplifier and a filter. This same NCO approach can also be used for the envelopes, but I think in the SID, this was all analogue stuff using resistor, capacitors and comparators. I believe the amplifiers were simple CMOS switched resistor ladders, as were the filters. I think you could all the digital stuff in a smallish FPGA; coupled with some analogue components it would make a well reverse-engineered SID. Forget all noise defying PCB practises for the final touch. Attempting to it do it completely digitally means you have to design-in its flaws too. But you don't want to do a complete SID; all you need is a simple NCO, which is only a few lines of VHDL. What will it interface to? JeroenArticle: 76732
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:41B8C572.661C916@yahoo.com... > PFD means Phase-Frequency-Detector? Ayup. > I believe you said that the digital phase detectors are not very > linear. Are you saying that there are *no* good detectors? What if a > digital phase detector were connected to analog current sources so that > the pullup and pulldown were balanced? Would that be linear enough? I > don't think that would be hard to design. One example of a linear phase detector is an XOR to provide a center level at 90 degree phase shift with nonlinearities as one approaches +/- 0.25 UI of jitter with the circuit giving up in the "other" 180 degrees of phase. I'd worry about implementing an XOR-type PFD in an FPGA because of problems not only with jitter but with feedthrough from other frunctions in the FPGA on the Voh and Vol levels. One PFD I used about 10 years ago that appeared to have good specs was the Analog Devices AD9901 which also produced a voltage output rather than the charge pumps we tend to be more familiar with.Article: 76733
Hans wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:41B75EE9.91C61428@yahoo.com... > > markets. This results in lots of updates and lots of bugs. (BTW > > Mentor, are you *ever* going to fix the bug where Modelsim crashes > > randomly for no special reason???) > > Sorry I can't resist it :-), but have you send them a testcase? do they know > what is causing it? can you reproduce the crash? have you tried 6.0b? I am > not trying to give a lecture since I have been cursing some of their > &^£%=&( tools as well but I do know that debugging a piece of code as > complex as Modelsim/NCSim/Aldec etc must be an absolute pig. Most if not all > EDA companies will quickly bring out a patch release if you find a serious > bug since this is their bread and butter. Your Modelsim can't be crashing > randomly for no reason unless your PC is being hit by high energetic > particles :-) If you can't send your source code them consider sending them > an obfuscated version, and/or a compiled version (using the -nodebug if > required) and/or set up and NDA, run your code on another PC, another OS, > try using the command line version (vsim -c). Write a bit of Tcl which loops > around your testbench repeatedly, then during the test read your mail, play > some MP3 etc and see if this might be affecting Modelsim. Alternatively, get > one of the Modelsim FAE's to visit you and sit next to you for a day while > you re-run your testbench, you are(?) paying maintenance for it :-) You are making a lot of assumptions. This has been a problem I have seen personally for the last four years on many different versions of Modelsim and many different computers. My coworkers in another company also saw this problem and explained to me that it was a known bug in Modelsim that was caused by a memory leak. I am just a dumb engineer who finds that one in 30 times as I recompile a design and start to reload it, the Modelsim window disappears and I have to open a new one only to find my last edited modules need to be recompiled again. I seriously doubt that it is related to my design in any way (unless my style is really that bizarre) or my computer(s) or if it has to do with how long the window has been open or how many times I have reloaded the same files. I just know it crashes more than I would prefer. Has no one else seen this? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 76734
"Antti Lukats" <antti@case2000.com> wrote in message news:cp8vfm$vo$04$1@news.t-online.com... > "Hendra" <u1000393@email.sjsu.edu> wrote in message > news:1102573360.598385.97830@c13g2000cwb.googlegroups.com... >> Has anyone seen Atari 10-in-1 Joystick? >> www.walmart.com/catalog/product.gsp?product_id=2233972 > as those products are deep low priced they do have an ASIC inside not > FPGA. > made in china. > at 18.77USD end user price it is not possible to have FPGA based product. > not yet, the FPGA prices are not so down! > BTW in Germany the same thing costs 34 EURO !! > > I think the Atari in joystick is made by that guy who had a webpage about > the 2600 in FPGA, he never released any design files and went commercial. > The commodore-in-joystick is designed by and girl named Jeri who also > designed C1 reconfigurable computer, but then obviously decided there is > more money in joystick business. Is this a 2600 in a joystick or an 800? The 800 is a descendant of the 2600 in many ways, but significantly different in others. I suspect from the number of other gaming things-on-sticks that they may have produced a platform that can emulate many others, i.e. an emulator on-a-stick. This is practical in today's technology. If it only has to emulate one machine, and doesn't have to run under a bloated OS like windows, it gets a lot easier as a task. An ARM chip would probably be up to the job, since they are used in some Intel's latest embedded CPU chips (under a new name to save Intel's pride). For example,a mate of mine ported a game boy emulator onto a mobile phone CPU. The amount of work involved in designing 20 such gaming products individually in FPGA would be enormous. I'm finding it plenty of work getting the 800 alone into an FPGA. Currently dual-porting the system bus between the CPU and the VDU sections. Originally it was just the RAM bus, but the ANTIC may need to access ROM as well. K.Article: 76735
glen herrmannsfeldt wrote: > > > Stephen Williams wrote: > > (snip) > >> However, I find I now want to be able to gradually ramp up the >> clock speed to see where our receiver boards start failing. My >> set of 8 frequencies span 85MHz to 16MHz. I would really rather >> be able to select frequencies from the range of 20-85MHz in 1MHz >> increments. The duty cycle of the output clock must be no worse >> then 60/40 for the ChannelLink transmitter chip, which has a PLL >> to think of. > If you start from a higher frequency, and use the divide by 1.5, 2.5, > etc. circuits that Peter Alfke has shown in some Xilinx notes, you > should be able to get pretty many frequencies in that range. > Do the frequencies need to be integer multiples of 1MHz? > > -- glen > Can you point me to those APP notes? Fast divide by N.5 may help indeed, but I can't find a da[r]ned thing on the Xilinx web site. I figure that if I used clock dividers to get 85MHz and 84MHz, I would need a phase accumulator accurate to 140pS. i.e. 7.14GHz / 84 == 85MHz, 7.14GHz / 85 == 84MHz, ... which gets me the precision I want at the high end (and more then I need at the low end) but an absurd FX frequency. Or if I started with 340MHz (Which is still more then I can get out of a -4 DCM) 340MHz / 4 == 85.0MHz, 340MHz / 5 == 68.0MHz, 340MHz / 6 == 56.7MHz 340MHz / 7 == 48.6MHz 340MHz / 8 == 42.5MHz 340MHz / 9 == 37.8MHz 340MHz /10 == 34.0MHz 340MHz /11 == 30.9MHz, ... I can get more accuracy then I have now (which I can fill in with another DCM and dividers) but 255MHz is more realistic: 255MHz / 3 == 85.0MHz 255MHz / 4 == 63.8MHz 255MHz / 5 == 51.0MHz 255MHz / 6 == 42.5MHz 255MHz / 7 == 36.4MHz 255MHz / 8 == 31.9MHz 255MHz / 9 == 28.3MHz, ... which makes a large gap of frequencies in the high end of my desired range. I should be able to fill in these gaps with more DCM devices with different (without common integer multiple!) frequencies divided down. This was my original plan. With 3 DCMs and some frequency dividers, I can get pretty good coverage at the low end, with sparse (but adequate) coverage at the high end. I guess I was hoping for a mathematical miracle to clean up my tangled web of DCMs, BUFGMUX's and frequency dividers. Boy, would a software controllable DCM be nice here. Unfortunately, I ain't got a V4, I got what I got, a VirtexII, and the slow speed grade at that. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 76736
Stephen Williams wrote: (snip regarding generating a variety of different clocks from a small number of DCMs.) > Can you point me to those APP notes? Fast divide by N.5 may help > indeed, but I can't find a da[r]ned thing on the Xilinx web site. http://www.xilinx.com/xcell/xl33/xl33_30.pdf > I figure that if I used clock dividers to get 85MHz and 84MHz, > I would need a phase accumulator accurate to 140pS. i.e. > > 7.14GHz / 84 == 85MHz, > 7.14GHz / 85 == 84MHz, ... > > which gets me the precision I want at the high end (and more > then I need at the low end) but an absurd FX frequency. > Or if I started with 340MHz (Which is still more then I can get > out of a -4 DCM) But only 170MHz with the half frequency dividers. > 340MHz / 4 == 85.0MHz, > 340MHz / 5 == 68.0MHz, > 340MHz / 6 == 56.7MHz > 340MHz / 7 == 48.6MHz > 340MHz / 8 == 42.5MHz > 340MHz / 9 == 37.8MHz > 340MHz /10 == 34.0MHz > 340MHz /11 == 30.9MHz, ... So they don't need to be integers. Note that the relative frequency difference is smaller at the higher frequencies if you keep the 1MHz increment. 20MHz to 21MHz is a 5% increase, so is 80MHz to 84MHz. If you only need steps that are at most 5%, and not required to be integers then I think it works with a reasonable number of dividers and DCMs. -- glenArticle: 76737
You can speed it up a bit more by keeping the adders close together and pipelining
the inputs from the BRAMs. Carry chains are typically the worst case paths, so
the trick is to put the ff's driving the carry chain physically as close to the
carry chain as you can get them. Put the adders in every other slice column and
the pipeline registers in the columns in between for the maximum performance.
Kevin Neilson wrote:
> Ray Andraka wrote:
> > Well, if you must use a tree (more on that in a minute), then your best bet
> > is to include RLOCs for the adders. You get reasonable performance by
> > placing the first level in every other slice column and then placing the
> > next levels in every other vacant column until you reach the root.
> > "Reasonable" depends on the depth of the tree and your clock speed of
> > course. It starts losing performance at 3 levels or so, because of the
> > progressively longer routes. You can make up the speed by adding pipeline
> > registers at the cost of real-estate.
> >
> > In the case of an FIR filter, however, you don't need a tree. Instead, push
> > part or all of the tap delay through the coefficient multiplies so that you
> > can connect the adders in a linear array (ie daisy chained), absorbing the
> > delays into the adder registers. That gives you all nearest neighbor
> > connections, and if you do it right, the latency is actually less than a
> > tree. The cost is if you need to clock enable it, your control task is much
> > more complicated.
> >
> Your suggestion on tree layout is exactly what I was looking for. It
> seems my tree that is floorplanned like a tree isn't the best plan.
>
> You are right about the transpose FIR architecture, though. I have
> become convinced that that is the best choice because of the ease of
> layout. I will be able to place the adders right next to the BRAMs in
> the column and the datapaths will be nice and short.
> -Kevin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 76738Hello, I also want to use Block RAM with data2mem tool without success. I uses Spartran-3 Development Kit with ISE webPack. > If you have processor code in the ROM, you can also use > a .bmm file > and the data2mem tool to let you change the code without > recompiling > the whole design Would you please instruct more detail? I made a .bmm file as: ADDRESS_BLOCK mainmem MEMORY [0x000:0x7ff] BUS_BLOCK mainMem_Mram_mcell_inst_ramb_0 [7:0] OUTPUT=mcell.mem; END_BUS_BLOCK; END_ADDRESS_BLOCK; I made 2kb of mcell.mem start with @00 c3 3d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 ... After then, I invoked data2bram with: data2bram -bm mcell.bmm -bt swsystem.bit -bd mcell.mem -o b new It generate new.bit without any error messages but new.bit is just the same as swsystem.bit. Then it may not updated at all but just copied, I think. The name in the BUS_BLOCK is extracted from floorplan editor, and I generated the name in ADDRESS_BLOCK. Would anybody give me any suggestion? Regards, NaohikoArticle: 76739
Jeroen wrote: > > Basically, it's very simple. First, you need a NCO (Numerically Controlled > Oscillator) to produce a waveform. A NCO is nothing but a simple counter > that's incremented with a constant at a fixed rate. By changing this > constant you can change the frequency of the waveform. Usually the counter > is 24 bits, and the waveform is created from the top 8 bits, which can be > used as an index to a sample-table (a crude form of resampling). In the SID, > for a square wave, the top bit is used as output; for a saw wave, the top 8 > bits; for a triangle wave 7 of the 8 topbits are used, and these are > followed by a XOR gates to invert the bits when the top bit is set. After > these, a simple R2R ladder that acts as DAC which is followed by an > amplifier and a filter. > ... > > But you don't want to do a complete SID; all you need is a simple NCO, which > is only a few lines of VHDL. What will it interface to? > > Jeroen Thank you, Jeroen, that was very helpful. The synthesizer will interface to a homebrew CPU in my FPGA. Do I recall SID had a noise source as well? Would a LFSR be suitable? Thanks. -DaveArticle: 76740
In the extreme DSP slice there are two registers before the multiplication on each of the A and B inputs. Does anyone know why you would need 2 registers before the multiplication? At first I thought it may be a register similar to the one in a MULT18x18s, but changing the number of registers on A and B from 1 to 2 had no effect on timing. Also it wouldn't make sense since A and B are individually selectable to have 0,1, or 2 registers. -KevinArticle: 76741
Moti,
There are a couple things you can do. First off, if you look closely at
an accumulator, the feedback from a particular bit only affects that bit
and bits with greater significance. That suggests that you can perform
partial sums and then combine the results. One simple trick that takes 2x
the resources of the straight accumulator is to break your 32 bit
accumulator into two 16 bit accumulators. The carry out of the first gets
registered and fed into the carry in of the second. Note that by doing
that, the second follows the first by a clock cycle, so you need to delay
the upper half of the addend (the new value getting added, not the
feedback value) by a clock cycle using a register so that it arrives at
the upper half of the accumulator at the same time as the registered carry
from the lower half. Likewise, the lower half sum output (but not the
feedback) has to be delayed by a clock cycle to align it with the upper
half sum. On the surface, that would seem to permit almost double the
clock speed (and it did in older Xilinx devices), however in Virtex
devices the propagation time to get on and off the carry chain is an order
of magnitude larger than the bit to bit propagation times, so in reality
the gain from this trick is rather small until you get into truely huge
accumulator widths.
A more usable trick requires a little more attention to the design
implementation. The carry chains are typically the critical path (mostly
because the times to get on and off the chain are on par with the LUT
delay). You can't do much anything about the delay in the carry chain or
the intrinsic delay for getting on and off the chain. You can, however,
minimize the delays on the signal connecting to the carry chain input.
This means making sure that you only have one level of logic (ie,
flip-flops are directly driving the LUTs that feed the carry chain), and
you need to make sure those flip-flops are placed in close proximity to
the carry chain (ideally either in the same CLB, or on an adjacent CLB so
you can use the direct connect wires). Note that the automatic placement
is not particularly good at making sure those flip-flops are placed this
way. The accumulator feedback doesn't need to be pipelined because it is
connecting back around to the same bit (assuming you've reduced the logic
to 1 level), which means it is already pipelined as much as it could be.
You may need to pipeline the new addend path in order to achieve the one
level of logic at the accumulator and keep the driving flip-flops in
adjacent slices, but that is OK as it doesn't affect the accumulator
operation.
You normally should use active high resets because that is what is native
to the fpga. In this case, I don't think it is affecting your timing
however, because it is an asynchronous reset. Had it been a syncrhonous
reset, some synthesizers would have inserted a gate between the carry
chain and the register, which would have added an extra LUT delay to the
input path rather than inverting the resetn signal.
Hope this helps
Moti Cohen wrote:
> Hello all,
> I've a design that contains a NCO (Numerically controlled oscillator).
> The NCO consists of a 32'bit accumulator. when i write the accumulator
> straight forward like this -
>
> process (clk,resetn)
> begin
> if resetn = '0' then
> accumulator <= (others =>'0');
> elsif clk'event and clk ='1' then
> accumulator <= accumulator + inc_value;
> end if;
> end process;
> Fout <= accumulator (accumulator'high);
>
> the maximum frequency I can achive for 'clk' is ~ 150 MHz (spartan 3).
> I need it to work in ~200 MHz so I figured out that some pipelining is
> needed but I dont know how to do it because of the accumulator
> feedback. Maybe someone here can explain it to me or even give me a
> code example (which will be great).
>
> Thanks in advance, Moti.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 76742
Moti,
Another trick for NCO's that will double the speed, assuming you are careful
about how you update the tuning word (phase increment) is to use two
accumulators running clock enabled on every other clock. One is initialized
with 0, the other is initialized with the phase increment value, and then both
are incremented by 2x the phase increment on every other clock. This allows
two clock periods for the accumulator carry to propagate, and you get the
current and next phase out at the same time on every other clock. A 2:1 mux
switching at the clock rate selects the output from the two accumulators on
alternate clocks.
I've used this trick also for cases where the mixer it is driving can't run at
the full clock rate (I usually use a CORDIC rotator there, see my XCELL
article about that). In that case, you use duplicate copies of the mixer, one
for even samples and the other for odd samples. The phase for both is
incremented by 2x the sample phase increment, with one offset by 1x the phase
increment.
I don't think you'll have to resort to this to get to 200MHz with a
Spartan3,however. I'm pretty sure careful floorplanning combined with making
sure you have just one level of LUT logic in the critical path (new addend
through carry chain to accumulator register) will get you 200MHz with a very
comfortable margin at 32 bits.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 76743"Dave" <apple2ebeige@yahoo.com> wrote in message news:1102637374.894620.303250@c13g2000cwb.googlegroups.com... > Jeroen wrote: > > > > Basically, it's very simple. First, you need a NCO (Numerically > Controlled > > Oscillator) to produce a waveform. A NCO is nothing but a simple > counter > > that's incremented with a constant at a fixed rate. By changing this > > constant you can change the frequency of the waveform. Usually the > counter > > is 24 bits, and the waveform is created from the top 8 bits, which > can be > > used as an index to a sample-table (a crude form of resampling). In > the SID, > > for a square wave, the top bit is used as output; for a saw wave, the > top 8 > > bits; for a triangle wave 7 of the 8 topbits are used, and these are > > followed by a XOR gates to invert the bits when the top bit is set. > After > > these, a simple R2R ladder that acts as DAC which is followed by an > > amplifier and a filter. > > > ... > > > > But you don't want to do a complete SID; all you need is a simple > NCO, which > > is only a few lines of VHDL. What will it interface to? > > > > Jeroen > > Thank you, Jeroen, that was very helpful. The synthesizer will > interface to a homebrew CPU in my FPGA. > > Do I recall SID had a noise source as well? Would a LFSR be suitable? > Thanks. Actually, the SID used a LFSR for that :))Article: 76744
Thomas Womack wrote: > The VGA interfaces I've seen all have something of the form > > --pin1 -- R --| > | > --pin2 -- 2R --+---monitor > | > --pin3 -- 4R --| > > so maybe something like that would produce a really, really cheap > DAC for the output stage. Xilinx has an app note for a sigma-delta converter design that just requires an external R and C. Also companies like AKM and Crystal have CD quality converters that are just a couple bucks and pretty easy to use. JeffArticle: 76745
My design is mixed, Microblaze in VHDL and the application in verilog with CORE memory FIFOs and Dual Ports. I used CORE Gen for the memory blocks. XPS cannot link my memory blocks when doing a bit stream generate. If I do a place and route in ISE for just my app (verilog) it runs just fine. Anybody else having this problem? ThanksArticle: 76746
rickman wrote: > I am just a dumb engineer who finds that one in 30 times as I recompile > a design and start to reload it, the Modelsim window disappears and I > have to open a new one only to find my last edited modules need to be > recompiled again. I seriously doubt that it is related to my design in > any way (unless my style is really that bizarre) or my computer(s) or if > it has to do with how long the window has been open or how many times I > have reloaded the same files. I just know it crashes more than I would > prefer. > > Has no one else seen this? I've used modelsim PE for about 5 years and XE for about 3 under windows and I've found them to be rock solid reliable. I can't ever remember them crashing out from under me like you describe. JeffArticle: 76747
Hi - On Fri, 10 Dec 2004 03:51:03 GMT, Jeff Cunningham <jcc@sover.net> wrote: >rickman wrote: >> I am just a dumb engineer who finds that one in 30 times as I recompile >> a design and start to reload it, the Modelsim window disappears and I >> have to open a new one only to find my last edited modules need to be >> recompiled again. I seriously doubt that it is related to my design in >> any way (unless my style is really that bizarre) or my computer(s) or if >> it has to do with how long the window has been open or how many times I >> have reloaded the same files. I just know it crashes more than I would >> prefer. >> >> Has no one else seen this? > >I've used modelsim PE for about 5 years and XE for about 3 under windows >and I've found them to be rock solid reliable. I can't ever remember >them crashing out from under me like you describe. > >Jeff I've used ModelSim PE for about 5 years, too, and I get semi-frequent (one time in, say, 50 seems about right) crashes, too. The simulation starts running normally, but at some point all of the ModelSim-related windows disappear. I restart the simulator, run the very same simulation, and everything's jake. This has happened across multiple versions of the simulator and on at least two different PCs, under W2K. It's not a show-stopper, but it is very annoying. I haven't reported it to ModelTech because I have no reliable way of reproducing it. Bob Perlman Cambrian Design WorksArticle: 76748
On Thu, 09 Dec 2004 23:14:49 GMT, "John_H" <johnhandwork@mail.com> wrote: >"rickman" <spamgoeshere4@yahoo.com> wrote in message >news:41B8C572.661C916@yahoo.com... >> PFD means Phase-Frequency-Detector? > >Ayup. > >> I believe you said that the digital phase detectors are not very >> linear. Are you saying that there are *no* good detectors? What if a >> digital phase detector were connected to analog current sources so that >> the pullup and pulldown were balanced? Would that be linear enough? I >> don't think that would be hard to design. > >One example of a linear phase detector is an XOR to provide a center level >at 90 degree phase shift with nonlinearities as one approaches +/- 0.25 UI >of jitter with the circuit giving up in the "other" 180 degrees of phase. >I'd worry about implementing an XOR-type PFD in an FPGA because of problems >not only with jitter but with feedthrough from other frunctions in the FPGA >on the Voh and Vol levels. > >One PFD I used about 10 years ago that appeared to have good specs was the >Analog Devices AD9901 which also produced a voltage output rather than the >charge pumps we tend to be more familiar with. I made an error earlier - the mixer type phase detectors only have a sinusoidal PD characteristic when fed with sine waves. When fed with square waves (such as from the output of an FPGA or divider) they have performance basically identical to that of an XOR gate, with a triangular PD characteristic. An XOR gate is much cheaper and easier to use than a multiplier, of course. One can work around the Voh & Vol problems by using an external CMOS gate fed from filtered supplies. One disadvantage of the XOR gate (apart from the lack of frequency discrimination) is that, at lock, at has a square wave on its output. This results in reference spurs at the PLL output that can be difficult to remove. Since the square wave is predictable, it is possible to come up with compensation schemes (e.g. by adding a fixed duty cycle square wave of opposite phase) to reduce the level of the spurs. The AD9901 is basically an XOR gate with an added frequency discriminator. Regards, AllanArticle: 76749
rickman wrote: > Mentor, are you *ever* going to fix the bug where Modelsim crashes > randomly for no special reason???) I dont' see open source tools fixing > any of this. The current open source front end tools are still far You need a testcase, fixing a bug where the description is "it crashes sometimes" is impossible. Yes, Modelsim has bugs, but every one of the ones I have found have been fixed in a reasonable time (usually optimisation bugs). They have even added some optimisations for new classes of structures just by asking and providing a good testcase. It should not be impossible to do a testcase. I have done some testcases even from 5+M gate designs where something is wrong in the SDF timing model. Those are really hard bugs to debug. For example no testbench is needed for a testcase, just use "vcd dumpports" functionality. There are also engineering builds of Modelsim that can be used to debug the crashes. I have not seen any random crashes and I use Modelsim in quite a big cluster for regression runs etc. And have been using M for many years. One place where modelsim at least had problems was restart command. After many restarts when the design structure changes enough it at least crashed in the past. Also if wave window was used heavily during simulation in versions <5.7 it quite often crashed. But I have had similiar experiences with other simulators. Some of them are even more crash prone. But they usually crash during the compilation already :) Nothing is perfect. --Kim
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