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
Muthu, You'll need to assign all top level components to an Area Group and then constrain this area group. Or if everything is related by clock, you can use the TIMEGRP function of the area group to group the logic and then assign the Area. Another way to look at this is to use the PROHIBIT constraint and prohibit areas undesired. Regards, Wei Muthu wrote: > Hi, > > The syntax for the area constrains is like this. > > INS "sub_Module_A" = X10Y10:X20Y20; > > Here sumb_Module_A is instantiated with in the Module_Top. If i want > to give area contrain for a top module which is has no sub-Module, > then how should the instantiation name will be .???? > > Thanks in advance > > Regards, > MuthuArticle: 50426
Especially if you are doing this design mainly as a hack/hobby project do not worry to much about the electrical part of the PCI spec. If I remove the timing constraints from my PCI design I violate Tsu and Thold by about 7ns and the design still runs fine on all computers that I have available for testing, including some pretty old board. Also, you should have no problems using even a two layer board. Just be careful that the ground path to any signal source remains as short as possible (this will require many vias on a two layer board) and use plenty of small decoupling capacitors. THe power supply of such a board does not look to good, so you will experience noise issues especially on any analog circuits that you have on the same board, but PCI should work fine. Of course the board design becomes easier with four layers. Between the PCI-Bus and the PQFP case you will only need one routing layer (at least after the first 3mm) so you can have 3 power planes on a 4-layer board.Article: 50427
I'm looking at the issue of how to best assign I/O given what is known about an application. Obviously, before you can have a target prototype board made you must make some assumptions and hope they are on target. In my particular case I have the following: Device: XC2V1000-FG456 Input bus #1, 150MHz, 20 bits + clock + synchronous control signals Input bus #2, 150MHz, 20 bits + clock + synchronous control signals Input busses 1 and 2 will always run at the same rate, but the clocks might not be edge aligned. Output bus #1, 155MHz, 24 bits + clock + synchronous control signals Bidirectional bus #1, 133MHz interface to external SDRAM, 80 bit + 14 address + control My current assignment of the above is as follows: Input bus #1, Bank 7, clock pin = A11 Input bus #2, Bank 6, clock pin = AA11 Output bus #1, Bank 3, clock will be generated using DDR mechanism SDRAM interface, Banks 0, 1 and 2, not sure about best clock approach Bank 7, 6 and 3 pin assignments are such that the LSB's are towards the bottom of the device. Signal flow on this design is from input busses 1 and 2 into SDRAM and out of SDRAM to the output bus. I'm not sure I understand the tradeoffs made when assigning banks/pins. For example, take the input busses. Would it be better to straddle banks 6 and 7 with both busses as opposed to trying to confine each bus's signals to a specific bank? I could almost use the outermost pins for bus #1 data and the next column in for bus #2 data. Control signals would take the remaining pins. The other approach might be to fit all data signals (both busses) to one bank (say 6) and stuff the control signals into bank 7. The SDRAM bus generates similar concerns. I have no choice but to straddle three banks. But, how does one decide where to place data, address and control lines within those banks? Split them up or keep them grouped? Obviously the exact sequencing of the pin assignments has to take into account PCB layout in order to minimize vias, lenght, etc. Given that, how does one approach this whole issue? Thanks, -- Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 50428
On Tue, 10 Dec 2002 13:30:07 -0500, rickman <spamgoeshere4@yahoo.com> wrote:
>But I can't remember seeing an existing ADC design around 40 MHz that
>was so carefully done. But then perhaps these were not good jobs.
It all depends on the requirements. I have a 40 MS/s design now
on which I took extreme care on the clocks. All LVPECL, and doesn't
touch the FPGA. This is for 12-bits (and I feel lucky when I get
10 non-noise bits) with a 50 MHz input, so my clock jitter sensitivity
is roughly five times the "usual". OTOH, when the ADC analog input
bandwidth is 1 GHz (not a misprint), it practically cries out to be
used in this manner, and I think a lot of people do.
- Larry
Article: 50429rickman <spamgoeshere4@yahoo.com> wrote: : Martin Schoeberl wrote: : There is not much point in starting early with a part like this. You : will need the tools and they can be in worse shape than the hardware : with early releases. There are lots of other parts available from both : Altera and Xilinx. At this point in time I would recommend the Spartan : II parts from Xilinx. They are real, low cost and the latest announced : members go up to 600K gates. I am sure you can find already designed : boards with these parts. I don't consider the SpartanII400-600 devices already "out in the wild". Look at the avaiability check from the distributors, e.g. the nuhorizons webpage. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 50430
Thanks for the responses, but I just want to make a functional simulation not postplace&route so why is not possible to use wait for statements (not synthesizable). My purpose was to simulate the design not to implement it. So is it possible to make a functional simulation and build a test bench or am I still wrong? Thanks a lot for your quick answers, Javi Ray Andraka <ray@andraka.com> wrote in message news:<3DF60EA9.5918A7D4@andraka.com>... > Wait for is not a synthesizable construct. Think about it, how would you > build digital hardware that would 'wait for 40 ns'? They key do doing > good VHDL designs is to visualize the hardware you need to accomplish your > task, then write the VHDL to produce that hardware. Trying to start at a > program type description and putting the intelligence to make hardware out > of it on the synthesizer is at best going to give you poor results, or as > you found out produce something unsynthesizable. > > javid wrote: > > > Hello, > > > > I have made a simple VHDL program that have three VHDL modules > > (WAVE_GEN, CONTROLLER, RAM512). I have in my WAVE_GEN code "wait for > > 40 ns;". The problem is that when I try to generate a symbol ISE tells > > me " Wait for statement unsupported". I also have made a "TOP" VHDL > > module that instantiate the three previous modules and interconnects > > them with signals. This "TOP" module is for conecting the waves > > generated by WAVE_GEN to the other VHDL modules. My problem here is > > that when I simulate this TOP module I don't see any signal, etc. in > > Modelsim window because this "TOP" module doesn't have ports. How can > > I see the internal signals?? > > > > Thanks a lot and regards, > > > > Javi > > -- > --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, 1759Article: 50431
I've been interested in stack-based processors for years. I've often thought that today's FPGA technology offers a neat avenue to implementing one, but I've never had an opportunity to try it out. The FPGAs that have internal RAM blocks would support program caching. Since Forth programs are traditionally very compact, you'd wind up with a *awful* lot of your code in the cache, so you could get some very high performance. Later, Kip Ingram -- Get daily news and analysis from the FPGA market for pennies a day. Subscribe to The FPGA Roundup today: http://www.KipIngram.com/FPGARoundup.html -- "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote in message news:%CdJ9.48188$_h6.635965@news.xtra.co.nz... > I have been thinking about a tiny stack based processor in verilog, much > like the KPSM (Pico Blaze). > > It seems like a stack based machine would be more suitable for this kind of > application because the instruction size is smaller, allowing more compact > code, there should be less multiplexing required leading to a smaller size > in a limited amouint of memory. You could program it in forth, which gives > you a fairly nice language to work in and easy to develop tools. > > Does anyone know of any existing designs like this - or work done on any? > Or is this an unfilled niche, or perhaps there is some fundamental error in > my thinking on the suitability of a tiny forth processor for these kind of > tasks. > > Thanks for any insights / ideas / pointers > > Ralph > > >Article: 50432
B16 looks like a really nice design and the paper very well describes the design and what you are trying to accomplish. Very nice but I can't get the simulator to work as the serial port code is missing from the download file, could you please update. Thanks -mark Bernd Paysan <bernd.paysan@gmx.de> wrote in message news:<erj4ta.s94.ln@miriam.mikron.de>... > Roelf Toxopeus wrote: > >> Yes, there has been much work done on Forth processors, both in custom > >> chips and in FPGAs. You can find some info on this at > >> > >> http://www.ece.cmu.edu/~koopman/./stack_computers/index.html > >> > >> and maybe > >> > >> http://www.taygeta.com/forth.html > >> > >> I am crossposting this to the forth newsgroup where you will likely get > >> a lot better response. > >> > > > > http://www.UltraTechnology.com/chips.htm > > I made a tiny Forth processor to fit into a small FPGA, you can find it on > > http://www.jwdt.com/~paysan/b16.html > > There's also Gerber data for a demonstration board with an Altera Flex > 10K30E. Today, I suggest using the new Cyclones, because the smallest one > is very cheap, and the configuration devices are also not that expensive > anymore.Article: 50433
I've seen modulation of the IOB input thresholds by outputs on the same bank
introduce on the order of 500 ps jitter to an incoming clock. That puts it around
1/50th of a 40 MHz clock cycle, which for a 20 MHz input is a noise level between 6
and 7 bits under your signal. Not much SNR there. You can substantially improve
things by not putting single ended outputs on the same bank as the clock, using a
differential clock, and putting virtual grounds on either side of the clock pin(s).
BTW, the jitter tolerance for the ADC is based on your input frequencies rather than
on the ADC clock itself. The problem comes about by the sampling time uncertainty.
The faster your signal changes, the less jitter you can handle at a given noise
level. It is not trivial to design an ADC circuit that meets the part specs even at
40 MHz, jitter can make the effective size of the converter quite a bit smaller if
you are not careful.
There are a number of commercial boards out with FPGAs and ADCs on them. I can't
think of even one that isn't driving the ADC clock from the FPGA. That doesn't mean
it is the right way to do it, just that the designer either didn't know better or
didn't want to give up the 'flexibility'.
rickman wrote:
> Ray Andraka wrote:
> >
> > Even without the DLL, I would caution against doing the divider in the FPGA.
> > First, the FPGA can induce a fairly significant jitter even without the DLL
> > due to shifting input thresholds from changing I/O currents. Second, at 120
> > MHz, you virtually need to use the DLL in the FPGA to get reasonable control
> > of your I/O setup, hold and clock to Q times. Without the DLL, the prop delay
> > to get a signal off the chip and then back on can greater than the clock
> > period it the DLL is not used to compensate for the clock distribution. You
> > are better off using an external 40 MHz clock, feeding it to the ADC and the
> > FPGA and then multiplying it up inside the FPGA with the clkDLL. At 40 MHz, a
> > decent clock buffer chip will keep you at single source-single destination
> > distribution of the clock and the induced skews will not be a big problem. At
> > higher rates, I'd use an ADC with a DR output and use that to clock the fpga
> > as I mentioned before.
>
> Maybe I am confused, but I don't remember anyone saying that the 120 MHz
> clock was being used to handle the data from the ADC. I had the
> impression that the OP simply wanted a 40 MHz clock for the ADC. I was
> not aware that the FPGA would add significant jitter to clocks passing
> through the chip. I guess if the jitter sensitivity of the ADC is that
> critical, then the clocking needs to have very special attention paid.
> But I can't remember seeing an existing ADC design around 40 MHz that
> was so carefully done. But then perhaps these were not good jobs.
>
> --
>
> 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 FAX
--
--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: 50434I've had a good bit of experience with Forth (written several Forth-based systems for various CPUs, wrote a fair bit of Forth code, etc.) I think that one issue here is that good Forth code can be very very good, and bad Forth code can be *horrible*. A poorly written Forth program can be horrendously inefficient, and writing a good Forth program requires careful thought. I agree with Ralph, though, that a properly implemented Forth solution should run faster than almost anything else given the same set of "lowest level" hardware capabilities. A carefully written Forth program brings onto the stack exactly the data that makes sense. Traditional processors have cache memories that try to keep frequently used stuff in fast memory, but the decision regarding what to fetch and what not to fetch is a heuristic. It's good, but it can't be as good as human reasoning that knows what the program is all about and implements it accordingly. Having said that, I'll also say that we may be beating a dead horse; I rather think that Forth is out of the running as far as the mainstream world is concerned. I suppose one should never say never, but Forth would have a *long* uphill climb to get back into mainstream use. I still like it, though. :-) Kip Ingram -- Get daily news and analysis from the FPGA market for pennies a day. Subscribe to The FPGA Roundup today: http://www.KipIngram.com/FPGARoundup.html -- "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote in message news:1cqJ9.50070$_h6.658037@news.xtra.co.nz... > "William Tanksley Google" <wtanksley@bigfoot.com> wrote in message > news:de3fc1ef.0212100859.e954eee@posting.google.com... > > "Martin Schoeberl" <martin.schoeberl@chello.at> wrote: > > >>It seems like a stack based machine would be more suitable for this kind > > >>of application because the instruction size is smaller, allowing more > > >>compact > > > > > Thats perfectly rigth. Things are a lot easier with a stack architecture > > > (but also slower since you need more cycles for basic operations than on > a > > > RISC CPU). > > > > Why would that be? The simulation I built as a college project was faster > > than any of my classmates', so I'm a bit sceptical. > > A stack machine will require more cycles per instruction. So by the cycles > per interction metric they are slower. > > But perhaps a stack machine is simple enough that it can have a faster cycle > time, or perhaps the instructions give a higher computation yeilld than risc > instructions. > >Article: 50435
> > Thats perfectly rigth. Things are a lot easier with a stack architecture
> > (but also slower since you need more cycles for basic operations than on
a
> > RISC CPU).
>
> Why would that be? The simulation I built as a college project was faster
> than any of my classmates', so I'm a bit sceptical.
It's slower in terms of cycles/instructions for the same statement:
A simple example: a = b + c;
On a RISC CPU the chance is high, that local variables are allocated to
registers. So this statement compiles to somthing like:
add r0, r1, r3
On a stack machine (like the JVM) this will compile to:
load a
load b
add
store c
> The advantage of Forth is that it's well-suited as-is for running
> hardware, and once you have it running Java can be implemented on top. I
would
> rather use Forth as a machine language than Java bytecodes.
Isn't Forth a 16 bit system? Building a 32 bit JVM on top of this would be
not very efficient.
Martin
--
JOP - a Java Optimized Processor for FPGAs.
http://www.jopdesign.com
Article: 50436> A carefully written Forth program brings onto the stack exactly the data > that makes sense. Traditional processors have cache memories that try to > keep frequently used stuff in fast memory, but the decision regarding what > to fetch and what not to fetch is a heuristic That's a point I like about stack machines. See the stack as a better, more efficient cach. And it's better predictable when it comes to real time systems. MartinArticle: 50437
Ray, I looked at Altera datasheets, and APEX II, Mercury, Stratix, and Cyclone have more than one FF per IOE, but APEX20K family (APEX20K, 20KE, and 20KC) have only one FF per IOE. However, 20KE and 20KC allows the IOE FF to be asynchronously preset which is important for PCI control signals because most of them are active low (i.e., FRAME#). Kevin Brace (If you want to respond to what I wrote, I prefer if you will do so within the newsgroup.) Ray Andraka wrote: > > This is only an issue for the 10K and its derivatives. 20K, mercury and stratix have 3 flip-flops > per IOE, one for each direction and one for the tristate. > > > -- > --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, 1759Article: 50438
Brooktree was one of the big ones. I don't know that they are still
around. AD also used to make them, as did TI. Check their websites.
rickman wrote:
> Thomas Buerner wrote:
> >
> > thanx for all the answers
> >
> > it seems that it is a lot more complicated than I hoped it would be.
> > we have dozens of old-fashioned isa vga cards here
> > so I thought it is a cheap way of getting a screen output
> > from an FPGA.
> > are there cheap RAMDACs that can be used for this purpose?
> > probably interfacing them is easier
>
> I can't remember company names, but RAMDACs were a dime a dozen at one
> point, and fast too! But I believe this function is integrated into the
> GPU chips now. But you might still be able to find some RAMDACs
> around. Look at your VGA boards and see what they are using. Then
> check those manufacturers web site.
>
> --
>
> 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 FAX
--
--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: 50439
ISE is an implementation tool, not a simulator. You need to use aldec, modelsim or the
like to simulate. Those tools recognize wait for.
javid wrote:
> Thanks for the responses, but I just want to make a functional
> simulation not postplace&route so why is not possible to use wait for
> statements (not synthesizable). My purpose was to simulate the design
> not to implement it. So is it possible to make a functional simulation
> and build a test bench or am I still wrong?
>
> Thanks a lot for your quick answers,
>
> Javi
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3DF60EA9.5918A7D4@andraka.com>...
> > Wait for is not a synthesizable construct. Think about it, how would you
> > build digital hardware that would 'wait for 40 ns'? They key do doing
> > good VHDL designs is to visualize the hardware you need to accomplish your
> > task, then write the VHDL to produce that hardware. Trying to start at a
> > program type description and putting the intelligence to make hardware out
> > of it on the synthesizer is at best going to give you poor results, or as
> > you found out produce something unsynthesizable.
> >
> > javid wrote:
> >
> > > Hello,
> > >
> > > I have made a simple VHDL program that have three VHDL modules
> > > (WAVE_GEN, CONTROLLER, RAM512). I have in my WAVE_GEN code "wait for
> > > 40 ns;". The problem is that when I try to generate a symbol ISE tells
> > > me " Wait for statement unsupported". I also have made a "TOP" VHDL
> > > module that instantiate the three previous modules and interconnects
> > > them with signals. This "TOP" module is for conecting the waves
> > > generated by WAVE_GEN to the other VHDL modules. My problem here is
> > > that when I simulate this TOP module I don't see any signal, etc. in
> > > Modelsim window because this "TOP" module doesn't have ports. How can
> > > I see the internal signals??
> > >
> > > Thanks a lot and regards,
> > >
> > > Javi
> >
> > --
> > --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
--
--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: 50440
I stand corrected. Couldn't remember at what point they started putting the extra ff's in the IOB
Kevin Brace wrote:
> Ray,
>
> I looked at Altera datasheets, and APEX II, Mercury, Stratix, and
> Cyclone have more than one FF per IOE, but APEX20K family (APEX20K,
> 20KE, and 20KC) have only one FF per IOE.
> However, 20KE and 20KC allows the IOE FF to be asynchronously preset
> which is important for PCI control signals because most of them are
> active low (i.e., FRAME#).
>
> Kevin Brace (If you want to respond to what I wrote, I prefer if you
> will do so within the newsgroup.)
>
> Ray Andraka wrote:
> >
> > This is only an issue for the 10K and its derivatives. 20K, mercury and stratix have 3 flip-flops
> > per IOE, one for each direction and one for the tristate.
> >
> >
> > --
> > --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
--
--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: 50441It's quite possible to use "wait for..." in a *testbench*. But that testbench is not (intended to be) synthesisable, so you don't process it with ISE. The usual way is to create a component (symbol) of your target device, using only synthesisable constructs. That *should* work under ISE. Then build a testbench, which calls up that symbol, and feeds it waveforms. The testbench is not synthesisable, & never goes near ISE. You simulate it with (in the Xilinx toolset) ModelSim. ModelSim will handle "wait for..." javodv@yahoo.es (javid) wrote: :Thanks for the responses, but I just want to make a functional :simulation not postplace&route so why is not possible to use wait for :statements (not synthesizable). My purpose was to simulate the design :not to implement it. So is it possible to make a functional simulation :and build a test bench or am I still wrong? :Article: 50442
> At the end of the configuration, when all data bits have been shifted into > the FPGA, through which channel? >there is something happen called startup sequence. They has 6 (8?) > phases, during which various global signals will be switched. > > GSR (global set/rest for FlipFlops) will be released > GTS (global tristate for IOs) will be released why this signal is sent? > GWE (global write enable for FlipFlops /RAMS) will be released why this signal is sent? > DONE goes active/tristate > > The order can be configured, also the sequence can wait for the DLL(s) to > achieve lock. The clock for clocking the startup-sequence can be choosen > between CCLK, JTAG clock (TCK) and a user clock. ok during those sequences will the logic be clocked or no? can i do all those configuration and later input the clock?Article: 50443
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:VtuJ9.115181$A9.1351706@news.chello.at... > > > Thats perfectly rigth. Things are a lot easier with a stack architecture > > > (but also slower since you need more cycles for basic operations than on > a > > > RISC CPU). > > > > Why would that be? The simulation I built as a college project was faster > > than any of my classmates', so I'm a bit sceptical. > > It's slower in terms of cycles/instructions for the same statement: > > A simple example: a = b + c; > > On a RISC CPU the chance is high, that local variables are allocated to > registers. So this statement compiles to somthing like: > > add r0, r1, r3 > > On a stack machine (like the JVM) this will compile to: > > load a > load b > add > store c Acutally I'm currently looking at implemeting a stack based architecture along with a RISC architecture. I think you miss the point a bit with your example. You say that local varaiables are allocated to registers for the RISC example, but then force the stack based design to load to the stack. Giving the stack based architecture the same advantage, that both operands are available at the top of the stack surely the optimised code would be :- add A single opcode. This opcode may then only require 8-bits of instruction length, an advantage it would seem over your RISC instruction that needs to specify the instruction opcode and 3(or 2) registers. This would surely require a 16-bit or 32-bit instruction length. Further you might say that the stack access must be slower than a register file, since you require to access to the stack plus write-back. But in any of the stack based chips design, they cache the top of the stack, or x number of top-of-stack (TOS) elements. Now your stack chip is executing that add in a single instruction, similar to RISC, but without the need for pipeline stages etc. I'm not saying the stack based designs are by any means perfect, but at least we could try for a fair set of comparison conditions? (This is no way meant to be a slight on you or anyone in general) -- Tim Simpson, Ph.D Design Engineer (reply to address is not valid remove _xx_ to reply)Article: 50444
"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote in message news:<%CdJ9.48188$_h6.635965@news.xtra.co.nz>... > I have been thinking about a tiny stack based processor in verilog, much > like the KPSM (Pico Blaze). > > It seems like a stack based machine would be more suitable for this kind of > application because the instruction size is smaller, allowing more compact > code, there should be less multiplexing required leading to a smaller size > in a limited amouint of memory. You could program it in forth, which gives > you a fairly nice language to work in and easy to develop tools. > > Does anyone know of any existing designs like this - or work done on any? > Or is this an unfilled niche, or perhaps there is some fundamental error in > my thinking on the suitability of a tiny forth processor for these kind of > tasks. > ST has a new 8-bit microcontroller family STFive 508, see http://us.st.com/stonline/prodpres/five/five508.htm. It is not a dedicated Forth processor, however, it has two stacks (System Stack and Data Stack). Regards AlexArticle: 50445
>> >> In the case that started this discussion, he wanted to make a 40 MHz >> clock for the A/D, but he was starting with a 120 MHz clock. Seems >> obvious that he could just throw away 2 out of 3 samples. There >> may be something better to do, but I'm not smart enough to see it. >> Might be something like you can get rid of some noise if you run >> through a filter that throws away the bandwidth you don't need. > > Actually in this case downsampling is a poor alternative to running the > ADC at the correct rate with an analog filter. It is *much* more > difficult to run an ADC at 120 MHz than it is at 40 MHz. The ADC will > use much more power at 120 MHz as well. > If I understood correctly, the OP wanted a variable sampling rate, with a max of 40 MHz. Running the DSP at the final frequency is not always possible in this case because 1) you have to adapt the analog LPF, which is expensive and 2) the ADC design is not necessarily static, esp. in this frequency domain. In that case, I would use the following acq chain ( I suppose this is a baseband system) : -> Analog LPF (fcut~16MHz) -> ADC, fixed 40MHz clk directly from cristal -> Downsampling in FPGA ( which, btw, gets its clock from the ADC or direclty from the osc) my 2 (euro)cents Sylvain YonArticle: 50446
Ray Andraka <ray@andraka.com> writes: > Brooktree was one of the big ones. I don't know that they are still > around. IIRC, Brooktree was acquired by Rockwell, then Rockwell's semiconductor business was spun off as Conexant.Article: 50447
--------------DF9C9FC021FDA2642B9FAE31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Dear Friends. I hope my message may be interesting for this group. (If it isn't then just ignore it.) Our company started to produce very small size FPGA and microcontroller boards. The sizes are small enough to drop all in your "overloaded" notebook's bag. All boards powered from USB, so no external power source need. It's really convenient when you are going to demonstrate your design with your laptop only. You can use them as evaluation board or fit them on your own boards as a component. Also you can buy universal prototyping board and low price JTAG cable for downloading XILINX FPGA's and flash ROM. See our web site. www.seytronix.com Some details and design examples will come soon. (I've just started to setup the site and any suggestion is appreciated!) Thanks! Seiran Petikian seiran@seytronix.com petikian01@rogers.comArticle: 50448
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:VtuJ9.115181$A9.1351706@news.chello.at... > > Why would that be? The simulation I built as a college project was faster > > than any of my classmates', so I'm a bit sceptical. > > It's slower in terms of cycles/instructions for the same statement: > > A simple example: a = b + c; > > On a RISC CPU the chance is high, that local variables are allocated to > registers. So this statement compiles to somthing like: > > add r0, r1, r3 > > On a stack machine (like the JVM) this will compile to: > > load a > load b > add > store c I'm not quite sure you have a level playing field here. It *is* possible that both would be in registers on the risc CPU - esp the kind I am looking at that only has register storage. But in a stack machine, one would hope that the operands you were working on would be right on the top of the stack, thus the instruction is only add All the registers are implicit, thereby giving a more compact instruction size. The Flipside for the Risc design is LD R1, SomeAddr LD R2.,SomeAddr Add R3,R2,R1 ST SomeAddr,R3 The slowness comes in because of the work the stack machine must do to perform that add Fetch op one from stack (dec sp ) Fetch op two from stack (dec sp) Add ops Push result to stack ( inc sp) By my count this is 4 cycles, although I suppose you could use a dual port stack and pop the arguments in one cycle. Although this increases the area of the design, which doesn't fit with what I want to acheieve. It doesn't look like it lends itself well to any kind of pipelining either. Basically I want to make something that is 1. very small (in area) 2. As useful as possible (eg can fit lots of code) 3. Powerful enough (how's that for scientific) 4.Is easy to make a good development tool And my thinking was, perhaps a stack machine meets these requirements better than a risc type machine. RalphArticle: 50449
I'm going to second Paul's suggestion about just computing the the correlation sequentially, its just too easy not to do. And also, I don't think a single correlation is going to give you your time delay, I think you're going to have to slide the 2 data sets across each other and keep computing that correlation until it peaks. President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message news:<3df51449$0$237$cc9e4d1f@news.dial.pipex.com>... > Don't forget to look at the www.opencores.org site for a pleasant surprise! > There is an FFT project there - check the mailing list for some recent > discussions and English translations of the documentation as well. > > I thought that FFT complexity was proportional to log N??? > > I don't think you are right as I often see people using radix 2 or radix 4 > butterfly sta2ges. > > You could always do the cross-correlation directly at those speeds in a MAC > serial structure couldn't you? > > Paul > > "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message > news:at322s$201c$1@msunews.cl.msu.edu... > > Hi, > > It has been a while since my last digital signal processing class. I > > have a question reguarding FFTs in an FPGA. I need a 4096 point > > cross-corelation. To do so if I recall correctly one can use an FFT on > both > > inputs and then multiply and then do an IFFT on the result to get the time > > delay in samples. If I recall corectly one of the inputs has to be > reversed > > in time initially. Now for the real question... I have a 32 point FFT/ > > IFFT core available. I would like to use this to calculate a 4096 point > FFT > > (or inverse FFT). If I recall correctly, a 64 point FFT requires 4 32 > point > > FFTs) thus a 64 point FFT would take 4 times as long using 4 32 bit FFTs > as > > the original 32 bit FFT. Following that logic train, the 4096 point FFT > > will require 16384 times as long as the original 32 point FFT. (4^7) Is > > that correct? Am I missing anything important here? I know that I could > > use a real DSP, but I am already much more familiar with FPGA's than with > > DSP chips. Any other comments would be appreciated. Note: speed is not > > real critical to my application. If I can get a cross-correlation every > 100 > > milliseconds that will be quite sufficient. The application requires > being > > able to recognize the time difference between the first and second echo > from > > a 220KHz ping every 100 milliseconds. Sample frequency is about 10MHz. > The > > echo time delay is kept within a 400 microsecond window including the > > duration of the echo. > > > > Thanks, > > Theron > > > >
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