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
We are looking at doing a small number of products for the FMC standard. We have reservations that this standard is expensive and inflexible use of FPGA I/O. The first module we are doing is an adaptor module to go from FMC to our own DIL module standard. Several of our standard module range to be used together in a FMC socket giving the user more options than a normal "fixed function" FMC card. You can see an example of our DIL Headers on our Spartan-6 based Drigmorn3 http://www.enterpoint.co.uk/drigmorn/drigmorn3.html. John Adair Enterpoint Ltd. On 2 Apr, 06:30, luudee <rudolf.usselm...@gmail.com> wrote: > Hi, > > so I want ahead and placed the order with Avnet, and they are telling > both boards > are on back order. No shipping date is given ... > > See, that's why I hate doing business with Avnet ! Now that they are > sole distributor, > I suspect things will get even worth ... > > Cheers, > rudiArticle: 146926
ISE10.1 ISE11.х
"libfontconfig" mast be compile with "libexpat" (as in RH, Centos and so on), but not with "libxml2".
take|compile libfontconfig with libexpat (take from CentOS) and copy in ~/lib.
In ISE/settings64.sh(settings32.sh) rewrite
LD_LIBRARY_PATH=${XILINX}/lib/${PLATFORM}:${LD_LIBRARY_PATH}
with
LD_LIBRARY_PATH=<your place with new "libexpat">:${XILINX}/lib/${PLATFORM}:${LD_LIBRARY_PATH}
---
frmsrcurl: http://compgroups.net/comp.arch.fpga/Xilinx-XPS-crash-on-Linux
Article: 146927Prerelease information on our Spartan-6 based Raggedstone2 PCI Express board is available http://www.enterpoint.co.uk/raggedstone/raggedstone2.html. For those of going to ESC in San Jose later this month this board will be showing, along with our extensive range of other boards, at our stand there. We have maintained as much of the Raggedstone1 features and DIL Headers as practical so as to offer our Raggedstone1 customers a migration path so they can use their own existing add-on modules in the new board. The Raggedstone2 headers are 34 ways high versus the 20 way high Raggedstone1 has allowing more add-on module options to be fitted, If demand is sufficient we can also offer DIL Headers with the middle rows that Raggedstone1 has but with a reduced header height. Any of our OEM customers interested in this possible option should contact us. We are expecting that this board will ship in limited numbers this month and significant quantities in May/June onwards. John Adair Enterpoint Ltd.Article: 146928
>the most beautiful and memorable hardware structure in a CPU You mean like <http://en.wikipedia.org/wiki/Chip_art>?Article: 146929
On Apr 1, 7:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net> wrote: > On 4/1/2010 11:07 AM, glen herrmannsfeldt wrote: > > > In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-n...@patten-glew.net> =A0wro= te: > > (snip) > > >> I never really knew how the 360/91 did register renaming. > >> I don't think it used a RAM style map. =A0I think it used CAMs. > > >> I actually asked Tomasulo this, but he never really answered > >> the question. > > > Never having had anyone to ask, but only read about it in books, > > that sounds about right. > > All I know is that I proposed having a separate pipestage to rename regis= ters, using a RAM (SRAM) table indexed by > logical register number returning physical register number, in 1986 or 19= 87 - in Wen-mei Hwu's microprocessor design > class - after he had taken us through Tomasulo and HPSm. > > I.e. I proposed eliminating the CAMs, replacing them by a RAM and an addi= tional pipestage. > > The idea seemed new to everyone who encountered it. It was not universall= y accepted as good. =A0Indeed, I remember arguing > with Tom Olson of AMD (if memory serves), who said that spending an extra= pipestage was not a good idea. > > I also talked to Mitch about it at around that time, although he was preo= ccupied with spreadsheets for the > > > The explanation I have seen for the CDB, common data bus, was > > that results come out broadcast to all possible destinations. > > Those destinations expecting a result from that source accept it. > > Possible destinations are registers, reservation stations > > (for adders or mutliply/divide), or to be written to main memory. > > Sources are results from arithmetic units, or data read from > > (750 ns, 16 way interleaved) main memory. > > Many people say that the CDB was an important invention. =A0I think it wa= s a bad idea - long wires, CAMs. > > Conceptually it is elegant, but implementation wise it is a bad idea. > > The important thing is taking that conceptually elegant CAM-ful idea, and= implementing it in an efficient non-CAM manner. > > The modern style of register renaming accomplishes this - certainly for t= he registers, but also, depending on the > system, for the reservation stations (if those are still being used). > > > Among the not so obvious ones, if you store to memory and then > > refetch, register renaming will detect the same address is > > being used and go directly to the source. =A0(No cache on the > > 360/91, it originated on the 360/85.) > > I'd love to see a reference for this. > > I believe that a UWisc patent on this was one of the things that resulted= in a big payment from Intel to UWisc. > > Myself, I thought it was obvious. Hi Andy, Your opinion is bright. Can you tell me UWisc patent number or its title? I have a design which is expected to work in a core of modern multiprocessors in more than 3GHz world, and the output drives one target. The design can have two implementations: 1. One source always drives the one target and it uses a lot of power; 2. 16 sources can selectively use a common output bus to drive the target with much less power. The output must be finished within 1 clock cycle. Which implementation is more wise in real world? In another words, a 16 sources selectively drives a common output bus with one target is implementation wise in more than 3GHz world? Thank you. Weng Thank you. WengArticle: 146930
>> Altera's Quartus II does not include a free simulator. Is >> there >> a free VHDL or Verilog simulator that is reasonalbly good? >> Google shows a few but I would prefer a recommendation. >> > Depends what you mean by "include" - you can download a > completely free > version of Modelsim from the Altera Website, > Alan Fitch Good. That appears to be brand new. Last time I looked Modelsim was available only with a subscription. My bdf to C# generator is now working but Modelsim is a backup. Thanks, GaryArticle: 146931
On Apr 1, 11:15=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Apr 1, 7:13=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On Apr 1, 10:54=A0am, austin <aus...@xilinx.com> wrote: > > > > Syms, > > > > Peak to peak is peak to peak. =A0You can take as many (or as few) cyc= les > > > as you wish, but do not exceed the peak to peak jitter specification. > > > (p-p says nothing about jitter spectral content) > > > > Of course if you move the clock edges (with respect to a perfect > > > mythical mathematical reference) over billions of clock cycles, you > > > can tolerate more than specified, but the specification is the > > > specification, and as such, it applies to the cycle to cycle can not > > > exceed the p-p, and the cycle to the 15th cycle can not exceed the p- > > > p, etc. =A0The p-p bounds any cycle to any cycle. > > > > Austin > > > Hmmm, do I understand what you are saying? =A0If I take you literally, > > then the frequency would have to be spot on, right? =A0The accumulated > > drift would add up over many cycles and violate any p-p jitter spec if > > you state as being "any cycle to any cycle". =A0I guess it depends on > > what you are using as a reference. =A0So what is the reference for > > measuring jitter over many cycles? =A0Do you assume the nominal rate or > > do you use the actual average clock period of the signal? > > > Rick > > Bottom line, in my humble opinion: the PLL jitter spec STINKS. =A0The > PLL may be palatable, but the spec isn't. =A0Like comm systems, there's > a high frequency peak-to-peak jitter that should probably apply and a > 20dB/decade climb to lower frequencies beyond a specific frequency > point. =A0This corresponds to a maximum phase comparator error when the > loop is trying to follow the significantly jittering signal. =A0"Wander" > is what they call jitter below 10 Hz in some comm systems. =A0We *can't* > be talking about peak-to-peak jitter down to 10 Hz. =A0That's just > ludicrous and points out specifically why this value needs to be more > properly specified. I agree 100%. The spec should relate to how the device works and not just some interface standard that requires you to operate far away from the actual testable limits of the device. Is this an issue of testing the chips to the spec? RickArticle: 146932
A lot of the signals are defined as 'reg buffer' , .oe=0, .clk=clk_0 (clk_0 being one of the global clocks). Then for any of these signals (e.g. call them AD0 to AD15) there is some logic, which takes two product terms only (just one #, and I write things in a way the optimization can't do much, in fact I would be a lot happier if I could switch that off). Well, after wasting hours in trial and error, I still cannot make the compiler use **1** macrocell per signal, it invents a second one and leaves the one with the oe=0 and clk=clk_0 unused. The stupid thing even warns me about that IIRC. IOW, I am trying to do what I have been doing numerous times with my compiler previously on the oldest Coolrunner: assign a pin as always tristated, use it as an input signal, and use its macrocell to process some signals, the macrocell being fed back to the array as well (pin and macrocell don't have to be related at all, although they could be - in this case they are). I use the xilinx software ver. 6.3i. Any ideas how to make it work? I was ignoring the issue until now, I need more of the chip - a 128 cell coolrunner, there is plenty of area in it but the stupid compiler uses twice the necessary macrocells, please help if possible. I hope I can manage it somehow without implementing the xpla3 in my compiler, reviving the effort (which was for the original Philips Coolrunner) will take more time than I have for this. Thanks for any help. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/Article: 146933
Is it possible to interface DDR2 memory to a Microblaze processor by not using the MPMC. I have my own DDR controller that I want to use. Cheers Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146934
On 2 Apr, 19:57, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > Is it possible to interface DDR2 memory to a Microblaze processor by not > using the MPMC. I have my own DDR controller that I want to use. > Yes - but you might need to write CoreConnect PLB Interface to sit between the two. JonArticle: 146935
On Apr 2, 9:19=A0pm, Didi <d...@tgi-sci.com> wrote: > A lot of the signals are defined as 'reg buffer' , .oe=3D0, .clk=3Dclk_0 > (clk_0 being one of the global clocks). > Then for any of these signals (e.g. call them AD0 to AD15) there is > some logic, which takes two product terms only (just one #, and I > write things in a way the optimization can't do much, in fact I would > be a lot happier if I could switch that off). > Well, after wasting hours in trial and error, I still cannot make the > compiler use **1** macrocell per signal, it invents a second one > and leaves the one with the oe=3D0 and clk=3Dclk_0 unused. The stupid > thing even warns me about that IIRC. > IOW, I am trying to do what I have been doing numerous times with > my compiler previously on the oldest Coolrunner: assign a pin as > always tristated, use it as an input signal, and use its macrocell > to process some signals, the macrocell being fed back to the array > as well (pin and macrocell don't have to be related at all, although > they could be - in this case they are). > I use the xilinx software ver. 6.3i. > Any ideas how to make it work? I was ignoring the issue until now, =A0I > need > more of the chip - a 128 cell coolrunner, there is plenty of area in > it > but the stupid compiler uses twice the necessary macrocells, > please help if possible. > I hope I can manage it somehow without implementing the xpla3 in > my compiler, reviving the effort (which was for the original Philips > Coolrunner) will take more time than I have for this. > > Thanks for any help. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff =A0 =A0 =A0 =A0 =A0 =A0 =A0 Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Got it somehow. Defining the pins as inputs - and then using their macrocells (under the same name) did it, uses 1 cell per signal now. Given these were 48 signals (and some more I won't bother to go after unless I need them) this is quite a saving, problem solved. Now why it would interpret me this and not the other way is probably known only by the person who wrote the abel -> vhdl thing - and probably it is more precise to say "has been known", this must have been written some 10 years or so ago :-). DimiterArticle: 146936
On Tue, 30 Mar 2010 10:47:40 -0500, "gaurang4040" wrote:
>`define str1 posedge
>`define str2 negedge
>`define ACTIVE_ISO_EDGE(a) ( a ? `str1 : `str2 )
>..
>module abc ( ...);
>..
>..
>bit [3:0] sences='{1, 0, 0, 1};
>..
>..
>generate
>genvar j;
>
> for(i=0; i<NO_OF_DOMAINS; i++)
> begin
> always @( `ACTIVE_ISO_EDGE( sences[i]) isolation_ctrl[i] )
> if(isolation_ctrl[i]==ISO_SENSE[i])
> power_iso_flag[i]=0;
> end
>
>endgenerate
No, you can't do that.
Remember that macros do source text replacement. They don't
change the source code dynamically.
If "sences" (sic) were a parameter, you could use it to control
a generate statement - far nicer than using a macro:
parameter [3:0] senses = 4'b1001;
generate
genvar i;
for (i=0; i<NO_OF_DOMAINS; i++) begin : mixed_polarities
if (senses[i]) begin : here_is_the_choice
always @(posedge isolation_ctrl[i])
power_iso_flag[i] <= 0;
end
end
endgenerate
Your original macro was generating source code that looks like...
always @(sences[i]? posedge : negedge something) ...
Clearly this is gobbledeygook and will never get through compilation.
--
Jonathan Bromley
Article: 146937I'm doing a design in a XC3S250E, using ISE 10.1.03. For some reason my generic dual-port RAM (with synchronous read) seems to be inferred as distributed. I'm fairly sure that a slightly earlier version of the design worked OK, but I don't know what has changed. I have "RAM extraction" checked, and "RAM Style" set to "Auto". [I can't set "RAM Style" to "Block" because the design also has a small register file with asynchronous read.] I tried the ram_style attribute, but can't work out what syntax ISE is expecting. I tried: attribute ram_style: string; attribute ram_style of my_ram : ram_dp_s is "block"; in the architecture that used the ram_dp_s, but it didn't like that (or any other variants I tried). Any thoughts? Thanks PeteArticle: 146938
On Apr 2, 6:55=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > I'm doing a design in a XC3S250E, using ISE 10.1.03. > For some reason my generic dual-port RAM (with > synchronous read) seems to be inferred as distributed. > I'm fairly sure that a slightly earlier version of the design > worked OK, but I don't know what has changed. > > I have "RAM extraction" checked, and "RAM Style" > set to "Auto". [I can't set "RAM Style" to "Block" > because the design also has a small register file with > asynchronous read.] > > I tried the ram_style attribute, but can't work out what > syntax ISE is expecting. > > I tried: > > attribute ram_style: string; > attribute ram_style of my_ram : ram_dp_s is "block"; > > in the architecture that used the ram_dp_s, but it didn't > like that (or any other variants I tried). > > Any thoughts? The XST manual has working examples of dual port RAM. I usually start with one of those and incrementally change it to what I want, backing up if it breaks. One thing to be wary of is that (at least some versions of ISE) do not like both the RAM ports to be in the same always block. Regards, PatArticle: 146939
> Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ? Our company, Epiq Solutions, will be releasing a broadband RF tuner card with integrated A/D converters in an FMC form-factor this summer. The RF tuner covers 300 MHz to 4 GHz, supports RF channel bandwidths up to 50 MHz, and will include dual 105 MSPS A/D converters. It is targeted at receiving and processing a variety of current and future radio waveforms, including 2G, 3G, and 4G cellular waveforms. More details can be found here: http://www.epiq-solutions.com/product_detail.php?line=Bitshark&product=Bitshark%20FMC We'll be selling directly from our website when the production units are ready this summer. Regards, John Orlando CEO/System Architect Epiq SolutionsArticle: 146940
I have re-listed it at just GBP 99 http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=290418994535Article: 146941
On Fri, 02 Apr 2010 23:48:48 +0100, Jonathan Bromley wrote:
[evidently, whilst half asleep]
> parameter [3:0] senses = 4'b1001;
> generate
> genvar i;
> for (i=0; i<NO_OF_DOMAINS; i++) begin : mixed_polarities
> if (senses[i]) begin : here_is_the_choice
> always @(posedge isolation_ctrl[i])
> power_iso_flag[i] <= 0;
> end
> end
> endgenerate
Oh dear.
(1) the parameter needs to be the right size:
parameter [NO_OF_DOMAINS-1:0] senses = ...;
(2) I forgot the "else" branch of the flipflop generate:
> for (i=0; i<NO_OF_DOMAINS; i++) begin : mixed_polarities
> if (senses[i]) begin : here_is_the_choice
> always @(posedge isolation_ctrl[i])
> power_iso_flag[i] <= 0;
> end
else begin
always @(negedge isolation_ctrl[i])
end
Oops.
--
Jonathan Bromley
Article: 146942On 4/2/10 11:30 AM, Abby Brown wrote: >>> Altera's Quartus II does not include a free simulator. Is >>> there >>> a free VHDL or Verilog simulator that is reasonalbly good? >>> Google shows a few but I would prefer a recommendation. >>> >> Depends what you mean by "include" - you can download a >> completely free >> version of Modelsim from the Altera Website, >> Alan Fitch > > Good. That appears to be brand new. Last time I looked > Modelsim was available only with a subscription. My bdf to C# > generator is now working but Modelsim is a backup. > The free versions of Modelsim have been available for years (also through xilinx - look for "starter edition") but are really usable for small designs. Once your design goes over a certain number of statements (I think 500 or something like that) execution slows to a crawl. -JeffArticle: 146943
Jeff Cunningham wrote: > The free versions of Modelsim have been available for years (also > through xilinx - look for "starter edition") but are really usable for > small designs. Once your design goes over a certain number of statements > (I think 500 or something like that) execution slows to a crawl. there are also free (as free beer or as a gnu) simulators for VHDL : http://symphonyeda.com/ quite nice http://ghdl.free.fr/ quite awesome in certain aspects (yes i'm biased because I use it and it can do things others can't) > -Jeff yg -- http://ygdes.com / http://yasep.orgArticle: 146944
On 4/1/2010 7:48 PM, MitchAlsup wrote:
> On Apr 1, 9:05 pm, "Andy \"Krazy\" Glew"<ag-n...@patten-glew.net>
> wrote:
>> I also talked to Mitch about it at around that time, although he was preoccupied with spreadsheets for the
>
> Any chance you could complete this sentance?
>
> Perhaps from {88100, 88110, 88120, crazy, insane, Asilomar
> participants, Hot Chips participants, all of the preceeding?}
Got distracted, forgot to finish. Wasn't exactly sure I remembered what you were working on.
Remember the first time I met you, Mitch, and Willie Anderson? What were you working on? Memory bandwidth spreadsheets
for the 88110? SIMD vectors? I remember we talked about DRAM bank structure, and you made your usual "If DRAMs were
designed the way I want them to be designed..." speech. I remember that you were interested in Linpack, while I was
interested in OOO and GCC.
Article: 146945On 4/1/2010 9:31 PM, glen herrmannsfeldt wrote: > In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-news@patten-glew.net> wrote: > (snip) > >> All I know is that I proposed having a separate pipestage >> to rename registers, using a RAM (SRAM) table indexed by >> logical register number returning physical register number, >> in 1986 or 1987 - in Wen-mei Hwu's microprocessor design >> class - after he had taken us through Tomasulo and HPSm. > >> I.e. I proposed eliminating the CAMs, replacing them by a >> RAM and an additional pipestage. > > With the 360/91 system, though, values can easily have more than > one destination. I suppose that could be done other ways, > too, but it is especially convenient that way. That's basically why P6 both renamed to physical registers, and had an RS with CAMs. RAM style indexing for the big data structure. CAMs for the relatively smaller RS, broadcast. I've always regretted not totally eliminating the CAMs in the RS. Always meant to get around to it in P6 v2.0, but that never happened. (BTW, no, Willamette did not eliminate the CAMs The bitmap scheduler is CAMs, but decoded CAs rather than encoded CAMs. Many people think that the term "CAM" only apples to encoded CAMs, but don't really have a name for the decoded CAMs, e.g. 1-hots. Me, I think encoded vs. decoded is just a circuit trick.) >> The modern style of register renaming accomplishes this - >> certainly for the registers, but also, depending on the >> system, for the reservation stations (if those are still >> being used). > > Logic was much more expensive then, than now, so the > tradoffs are likely different. If you used RAM tables > with more than one entry for each source, you could do > multiple destinations easily. Right The problem then has always bee "how may destinations", and "how do you handle exceeding the number of destinations without (a) falling of a cliff, and (b) complexity". > >>> Among the not so obvious ones, if you store to memory and then >>> refetch, register renaming will detect the same address is >>> being used and go directly to the source. (No cache on the >>> 360/91, it originated on the 360/85.) > >> I'd love to see a reference for this. > > There is an issue of the IBM Journal of Research and > Development pretty much devoted to the 91. I believe > it is in there. The 91 is pretty much a favorite for > books on pipelined processor design, mostly referencing > that journal issue. I practically memorized that issue. Not there that I remember. Likely we are talking about different things.Article: 146946
On Apr 3, 12:19=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net>
wrote:
> On 4/1/2010 7:48 PM, MitchAlsup wrote:
>
> > On Apr 1, 9:05 pm, "Andy \"Krazy\" Glew"<ag-n...@patten-glew.net>
> > wrote:
> >> I also talked to Mitch about it at around that time, although he was p=
reoccupied with spreadsheets for the
>
> > Any chance you could complete this sentance?
>
> > Perhaps from {88100, 88110, 88120, crazy, insane, Asilomar
> > participants, Hot Chips participants, all of the preceeding?}
>
> Got distracted, forgot to finish. =A0Wasn't exactly sure I remembered wha=
t you were working on.
>
> Remember the first time I met you, Mitch, and Willie Anderson? What were =
you working on? =A0Memory bandwidth spreadsheets
> for the 88110? SIMD vectors? =A0I remember we talked about DRAM bank stru=
cture, and you made your usual "If DRAMs were
> designed the way I want them to be designed..." speech. =A0I remember tha=
t you were interested in Linpack, while I was
> interested in OOO and GCC.
Willie was on 88110
Sounds like I was already on 88120
As to DRAM see USPTO 5367494
It was not so much that I was concentratng on Linpack, We (shebanow
and I) were trying to build a machine that could perform as if it were
a vector machine on vectorizable codes (without vector instructions::
i.e. native 88100 instructions at 6 per cycle) and also perform well
on GCC-like spaghetti codes. Linpack (Matrix 300) was simply the
vector code expample.
Mitch
Article: 146947Hello, I need to do some DSP operations preferably with Spartan 3. I need to divide output of a fast DDS by a variable but XST says it can only implement a divider with constants of power of 2. One way would be to recursively subtract divisor from dividend but that needs many cycles which is not suitable for me. I prefer to do this digitally within FPGA. Is there any digital solution preferably with Spatan ? ThanksArticle: 146948
In comp.arch.fpga MitchAlsup <MitchAlsup@aol.com> wrote: (snip) > It was not so much that I was concentratng on Linpack, We (shebanow > and I) were trying to build a machine that could perform as if it were > a vector machine on vectorizable codes (without vector instructions:: > i.e. native 88100 instructions at 6 per cycle) and also perform well > on GCC-like spaghetti codes. Linpack (Matrix 300) was simply the > vector code expample. The 360/91 was also designed to perform well on non-vectorized code. Well, on the code generated for other 360's. Among others is loop mode where for a small enough loop it stops fetching instructions from memory (they are in a special cache). The goal was one instruction per cycle. (With 750ns core it wasn't likely to do more than that.) The 360/91 even had to handle self-modifying code, including instructions that might have already been fetched. The IBM Fortran library for OS/360 did use some self-modifying code. (No recursion in Fortran 66 so it wasn't so hard to do.) -- glenArticle: 146949
PureSine <Green.Tech.Coder@gmail.com> wrote: > Hello, I need to do some DSP operations preferably with Spartan 3. I > need to divide output of a fast DDS by a variable but XST says it can > only implement a divider with constants of power of 2. > One way would be to recursively subtract divisor from dividend but that > needs many cycles which is not suitable for me. I prefer to do this > digitally within FPGA. Is there any digital solution preferably with > Spatan ? Pipeline it, one stage per quotient bit. In software terms, unroll the divide loop with a register between each cycle. Not having actually tried to implement one recently, my thought is for separate comparator and subtractor, possibly with a separate pipeline stage for each. It will still take a lot of cycles, but once the pipeline is full you get one result per cycle. -- glen
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