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
I am implementing BMD design as explained in xapp1052(v2.5). Have implemented the design on Avnet V5LXT/SXT PCIe Development Board using the PCIe. Have generated the Endpoint Block plus for PCIe 1.9 using ISE 10.1. I have been successful in running the BMD design with both the legacy interrupts and Message signal interrupts using single vector. The application which I am working on generates multiple interrupts in the RTL to the host application. So far I have assigned only one vector to the all the interrupts in the RTL design due to which after receiving the interrupt at the application end I have to go and check a register to see which interrupt has occurred. I don=92t want my application to go and read the register rather it should know which interrupt has occurred. Now as per the understanding developed through the document of PCIe endpoint, there are interrupts vectors that need to be generated at the time of PCIe core generation in order to assign each interrupt a different vector. The questions I need to ask are as follow: =95 How to link the multiple interrupts in the RTL with the multiple vectors of the MSI? =95 Are there any changes need to be made in the RTL design? =95 Is there any reference material that could help me doing this ?Article: 146901
On Apr 1, 12:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ? > > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD > > > Buying Xilinx products now means going through Avnet, which is a > > nightmare and HUGE lead times ... > > > Thanks, > > rudi > > While the XM104 is listed with a 8 week lead time on the Avnet site, I > know that we have these available in inventory and they will ship > promptly after the order is placed. =A0The XM105 is listed with a 2 week > lead time. > > There are a number of other companies releasing FMC cards, just be > sure that the cards support a VADJ of 2.5V and there shouldn't be a > problem. > > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/ > > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com/0/6= 2/651.html > > And Xilinx has a number of other boards in pipeline to be released > next quarter.http://www.xilinx.com/fmc > > Ed McGettigan > -- > Xilinx Inc. Thanks Ed ! I was hoping to find an alternative distributor for those boards, but I guess I have to deal with Avnet :( Thanks, rudiArticle: 146902
John, 3E was its own animal, with a completely different and unique DCM design, unlike all of the others. I immediately posted that the 256 steps was a mistake in my original post. 3E DCM had some real advantages, but we went back to the "old" DCM design. The experience gained in the design of PLLs for the MGTs, led to some very intense 'digitally calibrated PLL' to the point where in V6, they are not called DCM nor PLL...as they are not really either (MMCM). AustinArticle: 146903
Syms, Peak to peak is peak to peak. You can take as many (or as few) cycles 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. The p-p bounds any cycle to any cycle. AustinArticle: 146904
On 3/30/2010 9:15 PM, glen herrmannsfeldt wrote: > In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-news@patten-glew.net> wrote: >> The two hardware datastructures supporting out of order execution: > >> Reservation stations. > >> And, less beautifully, the register renaming map. > > Both from the IBM 360/91, as far as I know. > > S/360 has only four floating point registers, so register > renaming was pretty important for out-of-order execution. > > OK, how about imprecise interrupts? > > -- glen I never really knew how the 360/91 did register renaming. I don't think it used a RAM style map. I think it used CAMs. I actually asked Tomasulo this, but he never really answered the question.Article: 146905
> In article<houi8s$rdm$1@naig.caltech.edu>, >> OK, how about imprecise interrupts? Not a good idea.Article: 146906
I have a System Generator design and I have build it to ""HDL Netlist", and
select the "Create testbench" in Sys Gen. Then I use ISE to do the
post-route simulation. My Enviroment:
ISE 10.1.03 with service pack 3
Modelsim XEIII with pre-compiled library.
Now I have following errors:
# Loading simprim.x_buf(x_buf_v)
# Loading simprim.x_obuf(x_obuf_v)
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(1487: No default
binding for component at 'gateway_out_10_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_10_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14886): No default
binding for component at 'gateway_out_11_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_11_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14894): No default
binding for component at 'gateway_out_12_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_12_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14902): No default
binding for component at 'gateway_out_13_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_13_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14910): No default
binding for component at 'gateway_out_14_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_14_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(1491: No default
binding for component at 'gateway_out_15_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Loading simprim.x_dsp48e(x_dsp48e_v)
# Loading simprim.x_srlc16e(x_srlc16e_v)
# Loading simprim.x_ckbuf(x_ckbuf_v)
# Loading simprim.x_roc(x_roc_v)
# Loading simprim.x_toc(x_toc_v)
# Loading instances from ./netgen/par/test_cw_timesim.sdf
# Loading timing data from ./netgen/par/test_cw_timesim.sdf
# Error loading design
# Error: Error loading design
# Pausing macro execution
# MACRO ./pn_postpar.do PAUSED at line 15
Note that my pn_postpar.do file is generated by Sys Gen automatically as
follows, the line 15 is the vsim command.
-- If you see error messages concerning missing libraries for
-- XilinxCoreLib, unisims, or simprims, you may not have set
-- up your ModelSim environment correctly. See the Xilinx
-- Support Website for instructions telling how to compile
-- these libraries.
vlib work
vcom -93 -nowarn 1 -novopt
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/hdl/conv_pkg.vhd"
vcom -93 -nowarn 1 -novopt
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/hdl/xlclkprobe.vhd"
set env(PERL5LIB) {}
exec "D:/Xilinx/10.1/ISE/bin/nt/unwrapped/xilperl.exe"
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/scripts/probeclk.pl" -f
/netgen/par/test_cw_timesim.vhd
vcom -nowarn 1 -novopt ./netgen/par/test_cw_timesim.vhd
vcom -93 -nowarn 1 -novopt test_tb.vhd
vsim -novopt -L work -t ps -sdftyp
/sysgen_dut=./netgen/par/test_cw_timesim.sdf test_tb
view wave
add wave *
view structure
view signals
run 6875.000000 ns
Anybody have ideas?
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 146907In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote: (snip) > I never really knew how the 360/91 did register renaming. > I don't think it used a RAM style map. I 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. 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. 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.) -- glenArticle: 146908
On Apr 1, 10:49=A0am, austin <aus...@xilinx.com> wrote: > John, > > 3E was its own animal, with a completely different and unique DCM > design, unlike all of the others. =A0I immediately posted that the 256 > steps was a mistake in my original post. > > 3E DCM had some real advantages, but we went back to the "old" DCM > design. > > The experience gained in the design of PLLs for the MGTs, led to some > very intense 'digitally calibrated PLL' to the point where in V6, they > are not called DCM nor PLL...as they are not really either (MMCM). > > Austin Thanks and my apologies. I see now what you meant with your correction. The language wasn't clear on what you meant through this text medium, the newsgroup. I'm sure I would have known what you meant if we were discussing verbally. As tough as the S3E variable phase was for the middle of that project, I really liked the feature and was impressed by the performance. One fun experiment: feed the output of the DCM to a carry chain (using a toggle flop) and clock the output of the chain with the original reference clock, marking the recovered transition point in the carry chain with an XOR. Visualize the result with LEDs. One spot is typically lit up along the carry chain. Every increment of the phase isn't always a visible change, but the average I saw was 4 phase increments to move one position on the carry-chain readout if it's between slices, 2 phase increments to see the transition move if it's within a slice. I think I did this on the Spartan3E starter kit using the 8 LEDs and the rotary dial. Fun, fun to see it in action. The controllability was solid, the results pretty darned pristine.Article: 146909
i wrote an xsvf player bridged across a pc and an fx2lp to deliver the program code to a prom through a gpio port on the fx2lp. it works fine and will reprogram a system and will program a new system. but when it is an encrypted sourcefile the key has to already be in the system, and i cannot program it from the player. there are no new commands that i can see which are not in the regular program file, though the xsvf does show some strange duplication of commands, im guessing to send the device into the special programming mode. point is i can program 7+MB of data over this player just fine, but 700bytes wont work? theres obviously something there that i cant find in any documentation, as the key is programmed fine when i use impact and the cable to play the xsvf file. i cant exactly find out what is different bit by bit as xilinx has their cable set to pseudo random delays so a scope is just a pain. has anyone gotten through this mess before? whats the problem with writing a key through the xsvf? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146910
Hello, I would like to know if XST v11.5 supports any predefined MACRO's. We are particularly interested in a MACRO for the version of XST being used. Thanks in advance, Vikram. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146911
John, No apology necessary. I posted something half-way "right" and then followed with a terse correction. The phase control in 3E was pretty neat, but it was a "solution looking for a problem" (no one could think of any way to really exploit it...). I recently used a DCM with phase shift to measure the delay of a critical path. I use this information to control the supply voltage. Although voltage scaling is not supported, one can save ~50% of the power (static + dynamic) in the Virtex 5 1v core, by lowering the voltage and keeping the voltage just where the device still works. If you have a fast corner part, you really save a lot of power. If you have a slow corner part, then the static power is very low, and even at 1.0v you are still saving power (over the data sheet which has to be set at the fastest part that could be shipped). I control the power supply with a single IO pin, using a 5 bit PWM to adjust the Vccint from 0.8 v to 1.04v (31 steps used, I don't use 00000). So, a few LUTS, a few DFF, the logic runs off any clock you have in your design, and the DCM, and one IO pin, some resistors and a single capacitor to smooth out the PWM, and the supply goes up and down as needed to keep the device happy (just meeting the TILO of the speeds file), and saving power. Now, I think that is useful, but I can't really get any traction around here for the idea... One of the down-sides is that below .95v, we do not specify anything (nothing is guaranteed below 0.95v), so we would have to do a lot more characterization. AustinArticle: 146912
On Apr 1, 1:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > The explanation I have seen for the CDB, common data bus, was > that results come out broadcast to all possible destinations. Do you realize that the length of this bus and the number of destination nodes was one of the reasons the IBM machine topped out at 60ns while the CDC machines topped out at 27.5ns and could deliver 4 result (and one load) per cycle (as catch-up bandwidth). MitchArticle: 146913
On Apr 1, 1:45=A0pm, "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > I would like to know if XST v11.5 supports any predefined MACRO's. We are > particularly interested in a MACRO for the version of XST being used. > > Thanks in advance, > Vikram. =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com XST is a VHDL and Verilog synthesizer and will synthesis any HDL that it is provided. The term MACRO has its orgins in schematic design. What are you really looking for? Ed McGettigan -- Xilinx Inc.Article: 146914
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: (snip) > XST is a VHDL and Verilog synthesizer and will synthesis any HDL that > it is provided. The term MACRO has its orgins in schematic design. > What are you really looking for? It sounds like he is looking for something similar to what the way the C preprocessor is used in C. I believe that MACRO has been used a lot longer than computerized schematic design, back to the beginnings of assembly programming. I believe that verilog has something similar to the C preprocessor, I am not so sure about VHDL. -- glenArticle: 146915
On Apr 1, 3:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > (snip) > > > XST is a VHDL and Verilog synthesizer and will synthesis any HDL that > > it is provided. =A0The term MACRO has its orgins in schematic design. > > What are you really looking for? > > It sounds like he is looking for something similar to what > the way the C preprocessor is used in C. =A0I believe that MACRO > has been used a lot longer than computerized schematic design, > back to the beginnings of assembly programming. > > I believe that verilog has something similar to the C preprocessor, > I am not so sure about VHDL. > > -- glen I almost struck the comment about schematics in my reply and I probably should have. I was thinking that the original poster might be referring to the old Xilinx LogiBlox schematic macros that would be automatically expanded by the Xilinx tools. Ed McGettigan -- Xilinx Inc.Article: 146916
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) cycles > 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? If I take you literally, then the frequency would have to be spot on, right? The 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". I guess it depends on what you are using as a reference. So what is the reference for measuring jitter over many cycles? Do you assume the nominal rate or do you use the actual average clock period of the signal? RickArticle: 146917
On Apr 1, 4:02=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Apr 1, 3:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > (snip) > > > > XST is a VHDL and Verilog synthesizer and will synthesis any HDL that > > > it is provided. =A0The term MACRO has its orgins in schematic design. > > > What are you really looking for? > > > It sounds like he is looking for something similar to what > > the way the C preprocessor is used in C. =A0I believe that MACRO > > has been used a lot longer than computerized schematic design, > > back to the beginnings of assembly programming. > > > I believe that verilog has something similar to the C preprocessor, > > I am not so sure about VHDL. > > > -- glen > > I almost struck the comment about schematics in my reply and I > probably should have. =A0I was thinking that the original poster might > be referring to the old Xilinx LogiBlox schematic macros that would be > automatically expanded =A0by the Xilinx tools. > > Ed McGettigan > -- > Xilinx Inc. I think I know what the original poster is asking after... I have found some things that "just don't" synthesize properly with ISE-11. By that I mean that there are NO errors or additional warnings, but the resulting chip is dead, where it wasn't dead with version 10. By having a synthesize-time flag, one could create two different codes, and "if-def" according to which version of XST is being used. eg: `ifdef L.70 // this is 11.5 foo <=3D ~bar; `else foo <=3D !bar; `endif Then again, I'm only guessing about what the OP was asking after... RKArticle: 146918
On 4/1/2010 11:07 AM, glen herrmannsfeldt wrote: > In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-news@patten-glew.net> wrote: > (snip) > >> I never really knew how the 360/91 did register renaming. >> I don't think it used a RAM style map. I 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 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. The idea seemed new to everyone who encountered it. It was not universally accepted as good. Indeed, 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 preoccupied 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. I think it was 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 the 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. (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.Article: 146919
On Apr 1, 10:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net> wrote: > Myself, I thought it was obvious. There's your problem right there, Andy. Everyone else will say: 1. It's already been done (heard way too many times in this forum). 2. It was obvious (emphasis on the past tense). People answering either (1) or (2) assume that everything that can be thought of is already in textbooks. That's how they got to where they are. Robert.Article: 146920
On Apr 1, 9:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net>
wrote:
> I also talked to Mitch about it at around that time, although he was preo=
ccupied 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?}
Mitch
Article: 146921On 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) cycle= s > > 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. The PLL may be palatable, but the spec isn't. Like 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. This corresponds to a maximum phase comparator error when the loop is trying to follow the significantly jittering signal. "Wander" is what they call jitter below 10 Hz in some comm systems. We *can't* be talking about peak-to-peak jitter down to 10 Hz. That's just ludicrous and points out specifically why this value needs to be more properly specified.Article: 146922
On Apr 1, 10:20=A0pm, Robert Myers <rbmyers...@gmail.com> wrote: > On Apr 1, 10:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net> > wrote: > > > Myself, I thought it was obvious. > > There's your problem right there, Andy. =A0Everyone else will say: > > 1. It's already been done (heard way too many times in this forum). > > 2. It was obvious (emphasis on the past tense). > > People answering either (1) or (2) assume that everything that can be > thought of is already in textbooks. =A0That's how they got to where they > are. > Textbooks? Didn't you get the memo? Everything that can be thought of is on Google...or should I say Topeka ;) KJArticle: 146923
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. > The idea seemed new to everyone who encountered it. It was > not universally accepted as good. Indeed, I remember arguing > with Tom Olson of AMD (if memory serves), who said that > spending an extra pipestage was not a good idea. > Many people say that the CDB was an important invention. > I think it was a bad idea - long wires, CAMs. If the wires are too long, then add more pipeline stages along the way. With 750ns 16way interleaved core, though, the 91 wasn't going to get much faster than 60ns. > 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 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. >> 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 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. -- glenArticle: 146924
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, rudi
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